洪流来袭 - 剖析拒绝服务攻击

一、洪水—大自然对人类的报复

　　每一年，自然界都要用各种方式去报复人们对它做的一切，例如洪水。
　　每一年，人们都要为洪水后满地的狼籍和可能造成的人员伤亡和财产损失而发愁。
　　为了抵抗洪水，人们砍伐树木挖采岩石建造更高的堤坝；为了破坏这些堤坝，大自然发起更猛烈的洪水冲垮这些防护措施。
　　在大自然与人类抗衡的同时，网络上也有人与人之间的抗衡。
　　每一年，有些人总要不断试验各种令某些网站长时间无法访问的攻击方法。
　　每一年，投资者都要因为这些网站被恶意停止所造成的经济损失头痛。
　　为了抵抗这些人的攻击，技术人员研究各种方法让这些攻击造成的损失降低；为了各种目的，攻击者们研究更多的攻击方法让网站再次瘫痪。
　　这种攻击被称为“Denial of Service(DoS)”，臭名昭著的“拒绝服务”攻击。
　　它通常使用不只一台机器进行攻击，攻击者能同时控制这些机器，这种结构就是“Distributed”，分布式。所以，我们要讨论的拒绝服务，默认都是指“Distributed Denial of Service(DDoS)”，分布式拒绝服务。

　　二、面对洪水……

　　1.洪水以外的东西——被滥用的SYN拒绝服务（Synchronize Denial of Service）

　　当一个地区即将发生洪水（或者已经发生）的时候，当地居民的表现很少有镇定的：东奔西跑的、收拾财物的、不知所措的……整个城镇乱成一锅粥，造成的后果就是街道交通混乱，谁也跑不了。

　　这个问题到了网络上，就变成了一堆数据包只能在服务器外面乱撞而不入。

　　为什么会这样？因为攻击者使用了SYN攻击。

　　要明白SYN攻击的原理，要从连接建立的过程开始说起。从我们输入一个网址到我们能看到这个网页，机器在非常短的时间内为我们做了三件重要的事情：

　　1.机器发送一个带有“ SYN”（同步）标志的数据包给服务器，请求连接；

　　2.服务器返回一个带有SYN标志和ACK（确认）标志数据包给机器；

　　3.机器也返回一个ACK确认标志数据包给服务器，数据传输建立。

　　这三步就叫做“三次握手”。

　　那么所谓的SYN攻击是什么呢？让我们再看第二步，服务器返回数据后，并不会跑开，而是等待对方再次返回确认，问题就出在这里。如果一台计算机发送SYN数据包后由于意外断开了网络，服务器返回的ACK就得不到回应，而规范标准规定它必须“不见不散”，所以服务器就痴痴的等到夕阳下山，这期间内它拒绝其他机器的连接请求。于是在其它机器看来，它们开不了某个服务器的页面了。幸好在服务器的时间里，“夕阳下山”不过一瞬间，所以偶尔意外的一两台机器不回答它也很少影响大局。可是对于恶意攻击者来说，这不是问题——他们使用一些特殊工具大量产生这种导致服务器等待的虚假IP地址的SYN数据包，由于这个IP地址根本没有机器存在，自然不会有任何回应，所以服务器只有傻乎乎的为这些数据包做了个列表，然后一个一个等下去！这些等待花去的时间累加起来就变成了影响正常数据传输的原因，因为攻击者不停发送SYN数据包，服务器就无限的等下去，其他数据包就进不去服务器了，于是，一切都完了。这是最常见最滥用的拒绝服务模式，现成的攻击工具也很多，例如流行的Lion SYN Flood、xdos、独裁者等，这些工具几乎不需要什么高深知识就能用，因此SYN成为服务器和网络管理员最恨最怕的攻击。

　　其实SYN攻击的出现与系统自身设计的疏忽有关，首先，SYN是利用了TCP协议规范的疏忽；其次，是系统做的后台！*nix和Win2000/XP的网络架构允许用户通过编程手动设置IP头部，包括源IP、目标IP等，这是产生虚假SYN包的关键。Win9x/Me的网络架构不允许用户这样做，因此别指望Win9x/Me下使用这些工具能对服务器构成威胁了。

　　目前依然没有任何有效的软措施能抵挡SYN攻击，唯一的办法只有使用硬件防火墙，它从物理线路上直接过滤掉虚假的SYN数据包，但是价格昂贵，很多人只能痛心的看着他们的服务器被SYN数据包折磨得CPU持久不下100%……

　　有人说了，“难怪我的机器经常慢，原来有人SYN我！”等等等等，先听我说完。SYN攻击因为数据包很小，不能造成阻塞网络的危害，对没有开任何TCP服务的用户是不起作用的，即使有人正在SYN攻击你，你也察觉不到异常情况，除非你开了WEB服务之类。

　　记得有句话怎么说来着？慌乱的人群比灾难本身更可怕。

　　2.洪水来了——常见的各种报文洪水攻击（Flood DoS）

　　任何东西都会有个极限，人类做的防御工事也一样。再坚固的石头在流水猛烈的撞击下也会破裂，洪水瞬间溢了出来，淹没了所有东西。

　　嗜好拒绝服务攻击的集体们当然没理由不用洪水攻击，SYN不是万能药。某些时候阻止对方正常通讯要比SYN有用些，于是一种攻击方式又诞生了，这就是报文洪水。

　　网络中传输的数据都以一定的速度和大小传输着，用过拨号的朋友都知道，当你下载几个文件的时候，网页打开的速度会变得很慢，这是因为下载文件数据已经占满了你得到的网络带宽，就和公路塞车一样，所以其他数据只能挤进来。“报文洪水”因此产生，攻击者用工具不停向受害者发送一堆数据包，它们通常体积很小，所以速度很快，这些无用数据包迅速塞满了你的网络带宽，于是网络就慢下来了，如果数据包很多很快或者你的网络速度比较慢，这时候对你而言就是你已经和网络断开了。在这种攻击模式里，ICMP报文是最佳首选，因为它没有流量控制，几乎是横冲直撞！防火墙无法防止这种攻击，因为它阻塞的是防火墙前面那条信息公路，而不是要进入机器。制造洪水的工具也多，如蜗牛炸弹、AnGryPing等。早期的洪水只是单纯的塞路而已，现在某些特殊报文已经能达到让CPU满负荷的效果，例如ICMP的时间戳洪水。报文洪水不仅危害到服务器，个人用户更受其害——带宽更小。

　　通常，报文洪水的内容并没有什么实际意义，它们只是为了每一个数据包的大小而已，十六个A和十六个顺序字母的作用是一样的。。

　　阻止报文洪水的方法只有两个：增大自己的网络带宽或者在数据传输的路上截断它（在路由器上禁止符合某些条件的数据包通过）。

　　3.泥石流——反射式拒绝服务（Reflection Denial of Service）

　　你见过泥石流吗？这是大自然最可怕的报复之一。以吨计算的泥在水的帮助下向前卷动着，势力非常大，轻易能卷断一棵树苗和地上的一切不牢固的东西。这些被卷入的物品又成了泥石流加大攻击力的武器。面对泥石流中的动物尸体，我们很难说清楚它是被水窒息死的，还是被泥浆包裹是的，甚至是被里面的杂物撞死的——泥土和杂物应该都是无辜的，可是洪水却让它们变成了凶器。

　　当SYN和一般的报文洪水都不好用后，研究者们把眼光放在了协议规范和正常工作的服务器上……

　　反射式拒绝服务（RDoS），其实它也是洪水方式的拒绝服务，同样以阻塞带宽为目的，但是它用了借刀杀人的方法，就如水混合了泥沙而变得更可怕一样，RDoS攻击借用了正常的服务器来做武器。我们都知道，网络最重要是交互，就是“你问我答”，如果有人不遵守规则，变成“我冒充他问你”，你当然会要求被冒充的人回答，那个被冒充的就麻烦了。RDoS就是这样不守规矩的典型之一：它冒充受害者给各大服务器发送一个请求回复的数据包，那些服务器可不知道这些是骗局，就老实回复数据包到受害者那里，终于，这条路又塞车了。在受害者那里开嗅探抓到的是从正常服务器发过来的洪水，不能找到真正的攻击者。反射式拒绝服务在国内的应用还比较少，但也不是没有，一些工具如R-Series、DRDOS就能做到。

　　当然，反射拒绝服务应用比较少的最大原因就在于它的特殊性：它的攻击数据是进入正常服务器，再由正常服务器出来，首先速度就慢了一点；然后被利用的服务器（反射源）有可能无法那么快做出回应，那么攻击者的愿望实现反而更远；最后，它把SYN报文改成了反射源回复的ACK报文，性质马上相差十万八千里，相对可怕的SYN变成了报文洪水性质的ACK询问……

　　不过，反射式拒绝服务攻击的优点也不得不提，它使攻击者的隐蔽性更上一层楼，在这个猫抓老鼠的世界里还是好用的。

　　三、与洪水抗争

　　人类不会屈服于洪水，无论大自然发起多大的攻击，人类都会用各种手段去对抗；网络管理员也不会屈服于拒绝服务攻击，于是各个厂商和技术人员一起致力研究抵抗DoS的方法。如同抵抗洪水一样，对DoS也只能抵抗，因为DoS往往都是用虚假的IP地址在被入侵的机器上发起的，所以很难找得到源头。就和洪水一样，人们总不可能在它没发生之前就知道哪个地方会决堤吧。

　　2003年初发生的SQL蠕虫充分说明了这一点。全球13台根域名服务器一天内被超过几万台电脑发出的洪水淹没，整个世界网络瘫痪。没有人能预测到这事件，虽然它仅仅是一次单纯的UDP报文洪水。

　　SYN攻击最可怕的一点是它无法用软件手段阻挡，只能靠硬件防火墙，可是硬件防火墙实在太昂贵；报文洪水虽然不能达到降低机器性能的程度，可是它把通讯的道路阻塞了；反射式服务攻击力相对比较弱，尤其是反射ACK，它要求反射源的物理位置和受害者很近，否则攻击效率会大大降低。不要试图在受害机器上嗅探IP，没用的，几乎都是假的，只有原始数据通过的节点能暴露，可是不是任何人都有权力去查看这些设备里的记录的。所以，要找到发起拒绝服务的人很困难。

　　抵抗洪水方式的拒绝服务只有增大自己的带宽，让洪水不能阻塞完整个通道。或者在它到达之前“引流”——让它打空。

　　对付SYN只能用硬件防火墙从线路上直接消去SYN数据包。但是，最重要的是价格问题。修改协议规范是最好的方法，可是我们的专家不得不面对整个世界的网络结构都要改动所带来的麻烦。

　　要有效对抗拒绝服务攻击，我们还有很长的路要走……