在受攻击的服务器上使用netstat –an来看：

　　图

　　存在大量连接状态，来自少数的几个源。如果统计的话，可以看到连接数对比平时出现异常。并且增长到某一值之后开始波动，说明此时可能已经接近性能极限。因此，对这种攻击的判断：在流量上体现并不大，甚至可能会很小;大量的ESTABLISH状态;新建的ESTABLISH状态总数有波动。

　　3.5.2 Connection Flood防护?

　　主动清除残余连接。

　　对恶意连接的IP进行封禁。

　　限制每个源IP的连接数。

　　可以对特定的URL进行防护。

　　反查Proxy后面发起HTTP Get Flood的源。

　　3.6 HTTP Get攻击

　　3.6.1 原理

　　这种攻击主要是针对存在ASP、JSP、PHP、CGI等脚本程序，并调用MSSQLServer、MySQLServer、Oracle等数据库的网站系统而设计的，特征是和服务器建立正常的TCP连接，并不断的向脚本程序提交查询、列表等大量耗费数据库资源的调用，典型的以小博大的攻击方法。一般来说，提交一个GET或POST指令对客户端的耗费和带宽的占用是几乎可以忽略的，而服务器为处理此请求却可能要从上万条记录中去查出某个记录，这种处理过程对资源的耗费是很大的，常见的数据库服务器很少能支持数百个查询指令同时执行，而这对于客户端来说却是轻而易举的，因此攻击者只需通过Proxy代理向主机服务器大量递交查询指令，只需数分钟就会把服务器资源消耗掉而导致拒绝服务，常见的现象就是网站慢如蜗牛、ASP程序失效、PHP连接数据库失败、数据库主程序占用CPU偏高。这种攻击的特点是可以完全绕过普通的防火墙防护，轻松找一些Proxy代理就可实施攻击，缺点是对付只有静态页面的网站效果会大打折扣，并且有些Proxy会暴露攻击者的IP地址。攻击工具：

　　图

上一页  [1] [2] [3] [4] [5] [6] [7] 下一页

　　在遭受攻击的服务器上抓包，大量不同IP在请求资源。在实际情况中，也有可能使用代理地址连接。

　　3.6.2 HTTP Get防护

　　对是否HTTP Get的判断，要统计到达每个服务器的每秒钟的GET 请求数，如果远远超过正常值，就要对HTTP协议解码，找出HTTP Get及其参数(例如URL等)。

　　然后判断某个GET 请求是来自代理服务器还是恶意请求。并回应一个带key的响应要求请求发起端作出相应的回馈。如果发起端并不响应则说明是利用工具发起的请求，这样HTTP Get请求就无法到达服务器，达到防护的效果。

　　3.7 UDP DNS Query Flood攻击

　　3.7.1 原理

　　UDP DNS Query Flood攻击实质上是UDP Flood的一种，但是由于DNS服务器的不可替代的关键作用，一旦服务器瘫痪，影响一般都很大。

　　UDP DNS Query Flood攻击采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层DNS服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时。

　　根据微软的统计数据，一台DNS服务器所能承受的动态域名查询的上限是每秒钟9000个请求。而我们知道，在一台P3的PC机上可以轻易地构造出每秒钟几万个域名解析请求，足以使一台硬件配置极高的DNS服务器瘫痪，由此可见DNS 服务器的脆弱性。同时需要注意的是，蠕虫扩散也会带来大量的域名解析请求。

　　3.7.2 UDP DNS Query Flood防护

　　在UDP Flood的基础上对 UDP DNS Query Flood 攻击进行防护

　　根据域名 IP 自学习结果主动回应，减轻服务器负载(使用 DNS Cache)