DoS、DDos以及DRDoS攻击手段和防范措施

 DoS

  DoS(Denial of Service,拒绝服务攻击),它的原理很简单,就是用我们手里的机器去给服务器发请求,如果我们手头的服务器各方面性能都比服务器的主机的性能好,那么当我们发送大量请求给服务器,占用服务器的资源,导致服务器没有能力去处理其他用户请求。

  为了加深大家的理解,我就详细介绍DoS攻击中最有名的实现方式:Syn-Flood攻击。在具体介绍之前,我先和大家温故一下什么是三次握手。所谓的三次握手,就是在建立TCP连接的时候,客户端和服务器需要做几次通讯,确认相互之间的信息。它是保证TCP协议可靠性的重要手段之一。下面我们就来看一下它的具体流程:

  

  1、客户端(Client)首先向服务器(Server)发送连接请求,请求内容是:SYN=1 Seq=X

  2、服务器收到这个包以后,将这个数据放入到一个队列中,这个队列叫syn_table。并且发送一个返回包,作为响应,这个返回包有自己的序列号(Seq=Y),以及一个Ack,Ack的值就是客户端发来的Seq值加一;

  3、客户端收到返回信息以后,将服务器的Seq加一作为Ack又发给服务器;

  4、服务器收到这第三个包,验证没问题以后,就将这个连接放入到request_sock_queue
,三次握手完成。

  以上就是三次握手的具体流程。看到这里大家可能会有个疑问,平时我们在和服务器建立连接的时候仅仅调用connect,我们并没有进行三次握手,实际上connect这个高层概念是对三次握手的抽象,它的具体实现完成了三次握手流程。

  面对TCP的三次握手协议,攻击者应该如何发起攻击呢?攻击者首先故意发起一个握手数据包,服务器收到以后将它放入等待队列,并返回确认。其次,攻击者不再发送第3个确认包,这样一来,服务器就会进行多次重传发送(Linux系统通过tcp_synack_retries配置重传次数),消耗了大量额外开销,以及等待队列被占用,甚至于等待队列被占满,最终导致服务器不能接收客户端的请求。这就是Syn-Flood攻击。

  目前,我们是采取何种方法来解决Syn-Flood攻击的呢?第一种方法,缩短等待时间,尽早删除在等待队列中等待非法请求数据包;第二种方法是在第一次握手报文不放入等待队列,我们将一个32位的无符号整数作为第二次握手的Seq返回给客户端,该整数通过将用户请求的参数(包括请求的地址、端口等),加上服务器的一个序列号等做了一次运算得到。如果是正常用户,它在收到这个整数之后加1作为ACK返回给服务器,服务器在拿到数据后,对这个ACK减1再进行逆运算得到各个参数,最后发出去的数据进行比对,如果完全一致,说明是一个有效的响应,存放到相应的数据结构,反之则不是。通过该方法,非法请求就不能占用系统资源了。

  DDoS

  DDoS(Distributed Denial of Service,分布式拒绝服务),它是DoS家族里很难防范的一种攻击方式,攻击者首先控制大量肉鸡,然后向目标服务器发送海量请求,导致目标服务器不可用。这里我们不禁要问攻击者是如何获取大量肉鸡的呢?攻击者会对某些APP或网站植入一些恶意代码,譬如说curl www.mukedada.com,用户在使用这款APP或网站时,会自动请求www.mukedada.com这个网站,如果这款APP或网站的活跃用户数很多,那么这个网站就会受到很多莫名的请求。这就要求我们在平时上网过程中不要浏览一些不知名的网站和下载来源不明的APP。

  针对这种攻击方式,我们该如何防御呢?首先,作为用户我们尽量从正规渠道下载APP以及文明上网,尽量不让自己做肉鸡;其次,作为服务厂家,当服务器受到DDoS攻击时,我们尽量提升服务器的处理能力,当我们服务器的处理能力大于攻击者的能力时,这些攻击对服务器就不算啥事;最后,一般情况下,我们的服务器的处理能力一般低于攻击者的能力,针对这种情况,目前有以下几种方法:1.暴力方式,譬如:设置访问频率阈值,当某个IP单位时间内访问次数超过这个阈值就拒绝;对于某个服务,如果瞬时请求过大,选择直接拒绝保证其他服务的正常工作;这种方式可能导致正常用户也无法使用。2.验证码,为了防止暴露方式带来的误伤正常用户,目前服务商在收到大量请求时,会向"用户"发送验证码,如果是真实用户则会输入验证码,而是肉鸡的话,则不会,通过该方法则分辨出真实用户和肉鸡。

  DRDoS

  通过上文介绍,DDos攻击需要获取大量的肉鸡,但是获取肉鸡也越来越困难了,那目前还有没有不用控制肉鸡还能大量攻击的呢?DRDoS((Distributed Reflection Denial of Service,分布式反射拒绝服务),攻击者将不是将请求直接发送给被攻击者,而是发送给一个第三方,通过第三方中转到被攻击者,这就是"Reflection"的体现。它的流程具体如下:攻击者将请求包的源IP篡改成要被攻击者的IP,目标IP是第三方IP,那么第三方的恢复报文的目标IP就变成被攻击者的IP,这样一来,被攻击者就会收到大量请求导致服务不可用。

  

  需要注意的是:1. 攻击者往往选择的是基于UDP协议的系统,因为UDP协议是不可靠的,能够伪造源IP; 2. 攻击者往往会选择那些响应包大于请求包的服务。基于此,一般被被攻击的服务包括DNS服务、Memcached服务等。
为了加深大家理解,我就以Memecached服务为例。首先,Memcahced运行在11211端口,支持TCP和UDP一些,也就是说攻击者能够伪造源IP,同时,Memcached支持最大键值但数据对1M存储,意味着攻击者用较小的请求包让攻击者收到变大了几十倍的数据包。

  对于这种攻击,有没有方法来防范呢?首先,扩大服务器的宽带;其次,尽可能选择TCP协议;最后,对于一些被放大的返回包直接进行丢弃。

  写在最后

猜你喜欢

转载自blog.csdn.net/wenjianfeng/article/details/90096514