分布式拒绝服务攻击(DDoS)原理及防范(二)

日期: 2007-12-26 作者:徐一丁 来源:TechTarget中国

        DDoS攻击实例 – SYN Flood攻击

 

        Syn Flood原理 – 三次握手

        Syn Flood利用了TCP/IP协议的固有漏洞。面向连接的TCP三次握手是Syn Flood存在的基础。

        TCP连接的三次握手

图二 TCP三次握手

        如图二,在第一步中,客户端向服务端提出连接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法,需要检查。客户端在TCP报头的序列号区中插入自己的ISN。服务端收到该TCP分段后,在第二步以自己的ISN回应(SYN标志置位),同时确认收到客户端的第一个TCP分段(ACK标志置位)。在第三步中,客户端确认收到服务端的ISN(ACK标志置位)。到此为止建立完整的TCP连接,开始全双工模式的数据传输过程。

        Syn Flood攻击者不会完成三次握手

图三 Syn Flood恶意地不完成三次握手

        假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源—-数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃—即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称做:服务器端受到了SYN Flood攻击(SYN洪水攻击)。

         下面是我在实验室中模拟的一次Syn Flood攻击的实际过程

        这一个局域网环境,只有一台攻击机(PIII667/128/mandrake),被攻击的是一台Solaris 8.0 (spark)的主机,网络设备是Cisco的百兆交换机。这是在攻击并未进行之前,在Solaris上进行snoop的记录,snoop与tcpdump等网络监听工具一样,也是一个很好的网络抓包与分析的工具。可以看到攻击之前,目标主机上接到的基本上都是一些普通的网络包。

……           ? ->
 (broadcast)  ETHER Type=886F (Unknown),
size = 1510 bytes           ? ->
(broadcast)  ETHER Type=886F (Unknown),
size = 1510 bytes           ? ->
 (multicast)  ETHER Type=0000 (LLC/802.3),
size = 52 bytes           ? ->
(broadcast)  ETHER Type=886F (Unknown),
 size = 1510 bytes192.168.0.66 ->
192.168.0.255 NBT Datagram Service
Type=17 Source=GU[0]192.168.0.210 ->
192.168.0.255 NBT Datagram Service Type=17
Source=ROOTDC[20]192.168.0.247 ->
192.168.0.255 NBT Datagram Service Type=17
Source=TSC[0]           ? ->
 (broadcast)  ETHER Type=886F (Unknown),
size = 1510 bytes192.168.0.200 ->
 (broadcast)  ARP C Who is 192.168.0.102, 192.168.0.102 ?
          ? -> (broadcast)  ETHER Type=886F (Unknown),
size = 1510 bytes           ? ->
(broadcast)  ETHER Type=886F (Unknown),
 size = 1510 bytes192.168.0.66 ->
192.168.0.255 NBT Datagram Service Type=17
 Source=GU[0]192.168.0.66 ->
192.168.0.255 NBT Datagram Service Type=17
 Source=GU[0]192.168.0.210 ->
192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20] 
         ? -> (multicast)
 ETHER Type=0000 (LLC/802.3),
size = 52 bytes           ? -> (broadcast)
 ETHER Type=886F (Unknown), size = 1510 bytes    ? ->
(broadcast)  ETHER Type=886F (Unknown),
 size = 1510 bytes……
 

        接着,攻击机开始发包,DDoS开始了…,突然间sun主机上的snoop窗口开始飞速地翻屏,显示出接到数量巨大的Syn请求。这时的屏幕就好象是时速300公里的列车上的一扇车窗。这是在Syn Flood攻击时的snoop输出结果:

…… 127.0.0.178 ->
lab183.lab.net AUTH C port=1352  127.0.0.178 ->
lab183.lab.net TCP D=114 S=1352 Syn Seq=674711609
Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=115 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
 lab183.lab.net UUCP-PATH C port=1352  127.0.0.178 ->
lab183.lab.net TCP D=118 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net NNTP C port=1352  127.0.0.178 ->
lab183.lab.net TCP D=121 S=1352 Syn
Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=122 S=1352 Syn
Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
 lab183.lab.net TCP D=124 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
 lab183.lab.net TCP D=125 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=126 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=128 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=130 S=1352
 Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=131 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=133 S=1352
Syn Seq=674711609 Len=0 Win=65535 127.0.0.178 ->
lab183.lab.net TCP D=135 S=1352 Syn
Seq=674711609 Len=0 Win=65535……

        这时候内容完全不同了,再也收不到刚才那些正常的网络包,只有DDoS包。大家注意一下,这里所有的Syn Flood攻击包的源地址都是伪造的,给追查工作带来很大困难。这时在被攻击主机上积累了多少Syn的半连接呢?我们用netstat来看一下:

# netstat -an | grep SYN ……192.168.0.183.9      127.0.0.79.1801        
 0      0 24656    
 0 SYN_RCVD192.168.0.183.13  
  127.0.0.79.1801      
   0      0 24656    
 0 SYN_RCVD192.168.0.183.19 
   127.0.0.79.1801          0    
 0 24656      0 SYN_RCVD192.168.0.183.21 
   127.0.0.79.1801          0 
    0 24656      0 SYN_RCVD192.168.0.183.22
    127.0.0.79.1801          0
     0 24656      0 SYN_RCVD192.168.0.183.23 
   127.0.0.79.1801          0   
  0 24656      0 SYN_RCVD192.168.0.183.25
    127.0.0.79.1801          0   
  0 24656      0 SYN_RCVD192.168.0.183.37  
  127.0.0.79.1801          0 
    0 24656      0 SYN_RCVD192.168.0.183.53
    127.0.0.79.1801          0   
  0 24656      0 SYN_RCVD……

        其中SYN_RCVD表示当前未完成的TCP SYN队列,统计一下:
# netstat -an | grep SYN | wc -l
5273
# netstat -an | grep SYN | wc -l
5154
# netstat -an | grep SYN | wc -l
5267

        共有五千多个Syn的半连接存储在内存中。这时候被攻击机已经不能响应新的服务请求了,系统运行非常慢,也无法ping通。

        这是在攻击发起后仅仅70秒钟左右时的情况。

        DDoS的防范

        到目前为止,进行DDoS攻击的防御还是比较困难的。首先,这种攻击的特点是它利用了TCP/IP协议的漏洞,除非你不用TCP/IP,才有可能完全抵御住DDoS攻击。一位资深的安全专家给了个形象的比喻:DDoS就好象有1,000个人同时给你家里打电话,这时候你的朋友还打得进来吗?

        不过即使它难于防范,也不是说我们就应该逆来顺受,实际上防止DDoS并不是绝对不可行的事情。互联网的使用者是各种各样的,与DDoS做斗争,不同的角色有不同的任务。我们以下面几种角色为例:

        企业网管理员 
        ISP、ICP管理员 
        骨干网络运营商

        企业网管理员

        网管员做为一个企业内部网的管理者,往往也是安全员、守护神。在他维护的网络中有一些服务器需要向外提供WWW服务,因而不可避免地成为DDoS的攻击目标,他该如何做呢?可以从主机与网络设备两个角度去考虑。

        主机上的设置 

        几乎所有的主机平台都有抵御DoS的设置,总结一下,基本的有几种:

  • 关闭不必要的服务
  • 限制同时打开的Syn半连接数目
  • 缩短Syn半连接的time out 时间
  • 及时更新系统补丁

        网络设备上的设置

        企业网的网络设备可以从防火墙与路由器上考虑。这两个设备是到外界的接口设备,在进行防DDoS设置的同时,要注意一下这是以多大的效率牺牲为代价的,对你来说是否值得。

        1.防火墙

  • 禁止对主机的非开放服务的访问
  • 限制同时打开的SYN最大连接数
  • 限制特定IP地址的访问
  • 启用防火墙的防DDoS的属性
  • 严格限制对外开放的服务器的向外访问

        第五项主要是防止自己的服务器被当做工具去害人。

        2.路由器 
        以Cisco路由器为例

  • Cisco Express Forwarding(CEF)
  • 使用 unicast reverse-path
  • 访问控制列表(ACL)过滤
  • 设置SYN数据包流量速率
  • 升级版本过低的ISO
  • 为路由器建立log server

        其中使用CEF和Unicast设置时要特别注意,使用不当会造成路由器工作效率严重下降,升级IOS也应谨慎。路由器是网络的核心设备,与大家分享一下进行设置修改时的小经验,就是先不保存。Cisco路由器有两份配置startup config和running config,修改的时候改变的是running config,可以让这个配置先跑一段时间(三五天的就随意啦),觉得可行后再保存配置到startup config;而如果不满意想恢复原来的配置,用copy start run就行了。

        ISP / ICP管理员

        ISP / ICP为很多中小型企业提供了各种规模的主机托管业务,所以在防DDoS时,除了与企业网管理员一样的手段外,还要特别注意自己管理范围内的客户托管主机不要成为傀儡机。客观上说,这些托管主机的安全性普遍是很差的,有的连基本的补丁都没有打就赤膊上阵了,成为黑客最喜欢的"肉鸡",因为不管这台机器黑客怎么用都不会有被发现的危险,它的安全管理太差了;还不必说托管的主机都是高性能、高带宽的-简直就是为DDoS定制的。而做为ISP的管理员,对托管主机是没有直接管理的权力的,只能通知让客户来处理。在实际情况时,有很多客户与自己的托管主机服务商配合得不是很好,造成ISP管理员明知自己负责的一台托管主机成为了傀儡机,却没有什么办法的局面。而托管业务又是买方市场,ISP还不敢得罪客户,怎么办?咱们管理员和客户搞好关系吧,没办法,谁让人家是上帝呢?呵呵,客户多配合一些,ISP的主机更安全一些,被别人告状的可能性也小一些。

        骨干网络运营商

        他们提供了互联网存在的物理基础。如果骨干网络运营商可以很好地合作的话,DDoS攻击可以很好地被预防。在2000年yahoo等知名网站被攻击后,美国的网络安全研究机构提出了骨干运营商联手来解决DDoS攻击的方案。其实方法很简单,就是每家运营商在自己的出口路由器上进行源IP地址的验证,如果在自己的路由表中没有到这个数据包源IP的路由,就丢掉这个包。这种方法可以阻止黑客利用伪造的源IP来进行DDoS攻击。不过同样,这样做会降低路由器的效率,这也是骨干运营商非常关注的问题,所以这种做法真正采用起来还很困难。

        对DDoS的原理与应付方法的研究一直在进行中,找到一个既有效又切实可行的方案不是一朝一夕的事情。但目前我们至少可以做到把自己的网络与主机维护好,首先让自己的主机不成为别人利用的对象去攻击别人;其次,在受到攻击的时候,要尽量地保存证据,以便事后追查,一个良好的网络和日志系统是必要的。无论DDoS的防御向何处发展,这都将是一个社会工程,需要IT界的同行们来一起关注,通力合作。

作者简介:徐一丁,北京玛赛网络系统有限公司方案设计部高级工程师,从事IT工作多年。目前主要进行国内外安全产品评测与黑客攻击的研究。有丰富的网络安全设计与实施经验,并给各大电信公司如中国电信、吉通公司、联通公司等进行过系列安全培训。

        SYN-Flood是目前最流行的DDoS攻击手段,早先的DoS的手段在向分布式这一阶段发展的时候也经历了浪里淘沙的过程。SYN-Flood的攻击效果最好,应该是众黑客不约而同选择它的原因吧。那么我们一起来看看SYN-Flood的详细情况。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐