DDOS反击浅谈
但到底怎么样才能自动区分正常的网站访问流量和DDOS的网络流量，而同时又不根据IP源地址保存网络流量的状态呢?张大民知道思考到现在，他已经几乎抓到了问题的本质，但就是找不到解决的方法。
“他奶奶的，老子想不出来解决方法，今天就不睡觉了!”，张大民的狠劲儿上来了。但作为工程师的他同时也知道，对一个问题，如果没有解决方法，是因为对这个问题的本质还是没有一个清晰的认识，没有找到问题的根本原因，而被围绕在问题外部的一些表明现象所迷惑。
“不要想网络流量，也不要想什么DDOS的”，张大民强迫自己，“应该想一下一个正常的网站访问过程和一个异常的网站访问过程的不同之处”。毕竟，DDOS的网络流量不是要实现一个正常的网页访问过程，而只是要占用服务器的资源。“那我先分析一下一个正常网站访问的过程”，张大民想。 正常网站访问过程
.客户：TCP SYN
.服务器：TCP SYNACK
.客户：TCP ACK
.客户：HTTP GET／POST网站网页
.服务器：HTTP网页
那么异常网站的访问过程呢?在通常情况的TCP SYN洪水攻击时，过程如下:
.客户：TCP SYN
.服务器：TCP SYNACK
.服务器：TCP SYNACK
.服务器：TCP SYNACK
.服务器：TCP SYNACK
.服务器：TCP RST
而且张大民注意到，在大多数的DDOS攻击，攻击服务器主机都是被OWN的肉鸡。攻击的工具在这些肉鸡上并不建立一个有效的TCP状态，它们只是拼命向服务器发送TCP SYN的单一报文。所以当服务器发过来TCP SYN ACK时，这些肉鸡上根本没有相应的TCP连接来接收这个服务器发回来的报文，并根据这个报文找到相应的TCP连接状态而发任何有效的报文回去。
“有点意思”，张大民想，张大民敏锐的意识到对TCP状态的理解对于确定是否是有效的TCP链接的重要性。他开始后悔当初在学校读书是没有把TCP的状态图好好理解透彻。
张大民赶紧下载了TCP的状态表。而且在下载过程中，他又发现了一个非常有效的技术，来保存TCP的状态信息在TCP的系列号(SEQUENC NUMBER)中，叫TCP COOKIE。TCP COOKIE是一个特别的TCP序列号。服务器通过这个序列号，可以恢复这个TCP链接的整个状态信息。这这个发现让张大民有点大喜过望了。这正是他所要的。一个可以判断TCP是否是有效的链接，但又不必保存TCP的状态信息。这样，一个系统可以验证一个TCP链接是否是有效的链接，但同时又不保存任何TCP的状态信息，等系统验证这个TCP链接是有效的，它可以把这个COOKIE转发给WEB服务器，让WEB服务器从这个COOKIE里面构建原始的TCP状态信息，完成有效的TCP链接。“而且也可以用某种方法让客户端从新建立一个新的TCP链接，如果客户端肯建立的话，那就说明客户端是一个有效的TCP链接，遵循TCP或者HTTP的协议。而不是一个被OWN的主机，拼命向一台WEB服务器发送TCP SYN报文而不保存任何状态”，张大民思考到这里，感觉到他已经离一个解决方案不远了。通过对TCP和HTTP的近一步分析，在天色蒙蒙亮的时候，张大民终于拿出了第一个验证远程客户端有效性的方案。
javascript:DrawImage(this); border=0>
图 3
首先，一个保护层需要放在客户端和WEB服务器之间，来拦截所有的从客户端发来的TCP SYN报文。在接到TCP SYN报文后，这个保护层要发一个TCP SYNACK回去，TCP的序列好是计算好的TCPSYN COOKIE，根据这个COOKIE，一个完整的TCP状态可以恢复出来。注意这时这个保护层并不保存任何TCP的状态，它在等着客户端是否能送一个TCPACK回来。如果回来，就证明远程客户是一个有效的客户，因为远程客户也和WEB服务器一样，在保存这个TCP的状态。而且通过对HTTP的分析，张大民在此基础上又加了一道防御。保护层会送回一个HTTP重定向的TCP报文。根据HTTP的RFC的规定，当一个HTTP收到HTTP重定向报文后，它应该中断HTTP和TCP的链接。根据HTTP重定向报文中的内容重新建立新的TCP链接。这样，保护层也验证了HTTP是否是一个有效的HTTP，如果是，就应该遵守HTTP的规定，中断TCP链接，并重新向WEB服务器发布新的TCPSYN链接。
当一台肉鸡向WEB服务器发布TCP SYN洪水工具时，它是不会送任何TCP ACK回来的。如果保护层没有收到这个TCP ACK，就发现了这个源地址来的报文不是正常的报文，以后也不会让这个源地址来的报文通过了。从而达到了过滤DDOS网络流量的目的。
尝到了胜利的喜悦后，张大民也顾不上睡觉，又好好分析了TCP的状态装换图。这次，他主要是找有什么报文能使客户端自动终止一个TCP链接，然后在自动重试的。他发现，大部分应用层的协议，当一个TCP链接出现异常后，通常情况下都要进行重试，在建立新的TCP链接，直到三到四次。这样，当服务生敲门送上早饭的时候，黑客张大民又有了另一个TCP客户有效性验证方案。
javascript:DrawImage(this); border=0>
图 4
这次，当保护层拦截到客户端发布来的TCP SYN报文后，保护层送一个TCPACK，而不是TCP SYNACK回去。根据TCP的状态转换图，当客户端接收到这个TCP ACK报文时，客户端认为TCP的链接出了问题，会向服务器端发一个TCP RST的报文来中断目前的TCP链接。而使用TCP的应用层协议，如HTTP通常情况下会重试。如果是一个有效的HTTP客户，而不是一个发送DDOS网络流量的肉鸡，这个客户会重试。保护层会让这个重试的报文通过，而到达正常的WEB服务器。
张大民已经有点崇拜自己了。这个想法就更天才了，这个办法只是拦截TCPSYN，然后送一个TCP ACK回去，如果收不到客户端发回来的TCP RST，那么客户端就肯定是发送DDOS网络流量的肉鸡。如果不是，客户端自己会重新建立另一个TCP链接。而保护层在收到这个客户发来的TCP RST后，会让这个客户的新的TCP链接通过。保持肉鸡的网络流量被掐断，也保证了有效的客户可以正常访问网站。
如果我是做市场的，我就把这个中间层叫作“智能Anti—DDOS防火墙”沾沾自喜的想。
DDOS防护方案的系统实现思路
这个系统设计最核心的思想就是保护层不保留任何TCP的状态信息。正是因为这样，保护层才能比一般的WEB服务器接收流量大的多的TCP网络流量。而且保护层也做到了对正常的网络流量和DDOS的网络流量的区分，保证让正常的网络流量通过，而拒绝DDOS的网络流量到达WEB服务器，从而保证了WEB服务器的资源只服务于正常访问网站的客户。
张大民一边想， 一边理顺着自己的思路
那么在一个实际运行的网站中，这个系统应该放在哪里呢?最直接的想法就是把这个保护层放在网站服务器的前面，就像一般的企业网把防火墙放在企业网的前面一样。这样，当没有DDOS攻击网站服务器时，保护层就让正常访问网站的网络流量通过。当有DDOS攻击网站服务器时，保护层就启动反击装置，把DDOS的网络流量过滤掉。
这样的设计应该是可行的。张大民想。但问题是，在打多数情况下网站都不会遭到DDOS的攻击，把这个保护层一直放在网站服务器前面，接收网络流量，是否有点太浪费了?最好的方法是，通过路由来指导网络流量，当没有DDOS网络流量攻击网站服务器时，让所有的网络流量都不经过保护层，直接到达网站服务器。一旦遭到攻击，就通过路由把所有的网络流量都现转到保护层，让保护层看一下，把DDOS的网络流量过滤掉。
这样的设计应该是比较优化的。张大民在想张大民知道，通过路由自动转移网络流量的方向不是什么困难的技术问题。当网络流量的建模和预警装置发现DDOS网络流量时，象网络中自动插入静态路由或者BGP路由来指导网络流量的方向，这些在现代网络中已经是很常用的技术了。
javascript:DrawImage(this); border=0>
图 5
在这个方案中，保护层首先要对网站的流量进行统计建模。然后保护层一直监视着网络的流量状况，当流量出现异常时，保护层进入反击状态，首先改变访问网站服务器的网络流量的方向，让这些网络流量都首先都经过保护层。保护层就用源地址验证的方法对这些访问流量进行过滤，过滤掉DDOS的网络流量，让正常的网络流量传过保护层，正常访问网站服务器。
“他奶奶的，老子想不出来解决方法，今天就不睡觉了!”，张大民的狠劲儿上来了。但作为工程师的他同时也知道，对一个问题，如果没有解决方法，是因为对这个问题的本质还是没有一个清晰的认识，没有找到问题的根本原因，而被围绕在问题外部的一些表明现象所迷惑。
“不要想网络流量，也不要想什么DDOS的”，张大民强迫自己，“应该想一下一个正常的网站访问过程和一个异常的网站访问过程的不同之处”。毕竟，DDOS的网络流量不是要实现一个正常的网页访问过程，而只是要占用服务器的资源。“那我先分析一下一个正常网站访问的过程”，张大民想。 正常网站访问过程
.客户：TCP SYN
.服务器：TCP SYNACK
.客户：TCP ACK
.客户：HTTP GET／POST网站网页
.服务器：HTTP网页
那么异常网站的访问过程呢?在通常情况的TCP SYN洪水攻击时，过程如下:
.客户：TCP SYN
.服务器：TCP SYNACK
.服务器：TCP SYNACK
.服务器：TCP SYNACK
.服务器：TCP SYNACK
.服务器：TCP RST
而且张大民注意到，在大多数的DDOS攻击，攻击服务器主机都是被OWN的肉鸡。攻击的工具在这些肉鸡上并不建立一个有效的TCP状态，它们只是拼命向服务器发送TCP SYN的单一报文。所以当服务器发过来TCP SYN ACK时，这些肉鸡上根本没有相应的TCP连接来接收这个服务器发回来的报文，并根据这个报文找到相应的TCP连接状态而发任何有效的报文回去。
“有点意思”，张大民想，张大民敏锐的意识到对TCP状态的理解对于确定是否是有效的TCP链接的重要性。他开始后悔当初在学校读书是没有把TCP的状态图好好理解透彻。
张大民赶紧下载了TCP的状态表。而且在下载过程中，他又发现了一个非常有效的技术，来保存TCP的状态信息在TCP的系列号(SEQUENC NUMBER)中，叫TCP COOKIE。TCP COOKIE是一个特别的TCP序列号。服务器通过这个序列号，可以恢复这个TCP链接的整个状态信息。这这个发现让张大民有点大喜过望了。这正是他所要的。一个可以判断TCP是否是有效的链接，但又不必保存TCP的状态信息。这样，一个系统可以验证一个TCP链接是否是有效的链接，但同时又不保存任何TCP的状态信息，等系统验证这个TCP链接是有效的，它可以把这个COOKIE转发给WEB服务器，让WEB服务器从这个COOKIE里面构建原始的TCP状态信息，完成有效的TCP链接。“而且也可以用某种方法让客户端从新建立一个新的TCP链接，如果客户端肯建立的话，那就说明客户端是一个有效的TCP链接，遵循TCP或者HTTP的协议。而不是一个被OWN的主机，拼命向一台WEB服务器发送TCP SYN报文而不保存任何状态”，张大民思考到这里，感觉到他已经离一个解决方案不远了。通过对TCP和HTTP的近一步分析，在天色蒙蒙亮的时候，张大民终于拿出了第一个验证远程客户端有效性的方案。
javascript:DrawImage(this); border=0>图 3
首先，一个保护层需要放在客户端和WEB服务器之间，来拦截所有的从客户端发来的TCP SYN报文。在接到TCP SYN报文后，这个保护层要发一个TCP SYNACK回去，TCP的序列好是计算好的TCPSYN COOKIE，根据这个COOKIE，一个完整的TCP状态可以恢复出来。注意这时这个保护层并不保存任何TCP的状态，它在等着客户端是否能送一个TCPACK回来。如果回来，就证明远程客户是一个有效的客户，因为远程客户也和WEB服务器一样，在保存这个TCP的状态。而且通过对HTTP的分析，张大民在此基础上又加了一道防御。保护层会送回一个HTTP重定向的TCP报文。根据HTTP的RFC的规定，当一个HTTP收到HTTP重定向报文后，它应该中断HTTP和TCP的链接。根据HTTP重定向报文中的内容重新建立新的TCP链接。这样，保护层也验证了HTTP是否是一个有效的HTTP，如果是，就应该遵守HTTP的规定，中断TCP链接，并重新向WEB服务器发布新的TCPSYN链接。
当一台肉鸡向WEB服务器发布TCP SYN洪水工具时，它是不会送任何TCP ACK回来的。如果保护层没有收到这个TCP ACK，就发现了这个源地址来的报文不是正常的报文，以后也不会让这个源地址来的报文通过了。从而达到了过滤DDOS网络流量的目的。
尝到了胜利的喜悦后，张大民也顾不上睡觉，又好好分析了TCP的状态装换图。这次，他主要是找有什么报文能使客户端自动终止一个TCP链接，然后在自动重试的。他发现，大部分应用层的协议，当一个TCP链接出现异常后，通常情况下都要进行重试，在建立新的TCP链接，直到三到四次。这样，当服务生敲门送上早饭的时候，黑客张大民又有了另一个TCP客户有效性验证方案。
javascript:DrawImage(this); border=0>图 4
这次，当保护层拦截到客户端发布来的TCP SYN报文后，保护层送一个TCPACK，而不是TCP SYNACK回去。根据TCP的状态转换图，当客户端接收到这个TCP ACK报文时，客户端认为TCP的链接出了问题，会向服务器端发一个TCP RST的报文来中断目前的TCP链接。而使用TCP的应用层协议，如HTTP通常情况下会重试。如果是一个有效的HTTP客户，而不是一个发送DDOS网络流量的肉鸡，这个客户会重试。保护层会让这个重试的报文通过，而到达正常的WEB服务器。
张大民已经有点崇拜自己了。这个想法就更天才了，这个办法只是拦截TCPSYN，然后送一个TCP ACK回去，如果收不到客户端发回来的TCP RST，那么客户端就肯定是发送DDOS网络流量的肉鸡。如果不是，客户端自己会重新建立另一个TCP链接。而保护层在收到这个客户发来的TCP RST后，会让这个客户的新的TCP链接通过。保持肉鸡的网络流量被掐断，也保证了有效的客户可以正常访问网站。
如果我是做市场的，我就把这个中间层叫作“智能Anti—DDOS防火墙”沾沾自喜的想。
DDOS防护方案的系统实现思路
这个系统设计最核心的思想就是保护层不保留任何TCP的状态信息。正是因为这样，保护层才能比一般的WEB服务器接收流量大的多的TCP网络流量。而且保护层也做到了对正常的网络流量和DDOS的网络流量的区分，保证让正常的网络流量通过，而拒绝DDOS的网络流量到达WEB服务器，从而保证了WEB服务器的资源只服务于正常访问网站的客户。
张大民一边想， 一边理顺着自己的思路
那么在一个实际运行的网站中，这个系统应该放在哪里呢?最直接的想法就是把这个保护层放在网站服务器的前面，就像一般的企业网把防火墙放在企业网的前面一样。这样，当没有DDOS攻击网站服务器时，保护层就让正常访问网站的网络流量通过。当有DDOS攻击网站服务器时，保护层就启动反击装置，把DDOS的网络流量过滤掉。
这样的设计应该是可行的。张大民想。但问题是，在打多数情况下网站都不会遭到DDOS的攻击，把这个保护层一直放在网站服务器前面，接收网络流量，是否有点太浪费了?最好的方法是，通过路由来指导网络流量，当没有DDOS网络流量攻击网站服务器时，让所有的网络流量都不经过保护层，直接到达网站服务器。一旦遭到攻击，就通过路由把所有的网络流量都现转到保护层，让保护层看一下，把DDOS的网络流量过滤掉。
这样的设计应该是比较优化的。张大民在想张大民知道，通过路由自动转移网络流量的方向不是什么困难的技术问题。当网络流量的建模和预警装置发现DDOS网络流量时，象网络中自动插入静态路由或者BGP路由来指导网络流量的方向，这些在现代网络中已经是很常用的技术了。
javascript:DrawImage(this); border=0>图 5
在这个方案中，保护层首先要对网站的流量进行统计建模。然后保护层一直监视着网络的流量状况，当流量出现异常时，保护层进入反击状态，首先改变访问网站服务器的网络流量的方向，让这些网络流量都首先都经过保护层。保护层就用源地址验证的方法对这些访问流量进行过滤，过滤掉DDOS的网络流量，让正常的网络流量传过保护层，正常访问网站服务器。
0
相关文章
关注我们
