当网站DDOS的解决方案及展望 (2

　　TotalFlows自从最后一次清除统计信息后，这种协议的信息流的个数。

　　Flows/Sec每秒钟时间内出现这种协议的信息流的平均个数，它等于总信息流数/综合时间的秒数。

　　Packets/Flow遵守这种协议的信息流中平均的数据包数。等于这种协议的数据包数，或者在这段综合时间内，这种协议的信息流数。

　　Bytes/Pkt遵守这种协议的数据包的平均字节数（等于这种协议总字节数，或者在这段综合时间内，这种协议的数据包数）。B/Pkt，这一信息流中每个数据包的平均字节数

　　Packets/Sec每秒钟时间内这种协议的平均数据包数（它等于这种协议的总数据包），或者这段综合时间的总秒数。

　　Active（Sec）/Flow从第一个数据包到终止信息流的最后一个数据包的总时间（以秒为单位，比如TCPFIN，终止时间量等等），或者这段综合时间内这种协议总的信息流数。

　　Idle（Sec）/Flow从这种协议的各个非终止信息流的最后一个数据包起，直到输入这一命令时止的时间总和（以秒为单位），或者这段综合时间内信息流的总时间长度。

　　正常由日志

　　图二

　　IPpacketsizedistribution这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：2%的数据包的大小在33字节到64字节之间。

　　注意网站的访问量直线下降。很明显，在这段时间没人能访问他的Web服务器。我开始研究到底发生了什么，以及该如何尽快地修复。

　　二、事件分析

　　路由器地址查询我的Web服务器发生了什么？很有可能，那么受到什么样的呢？从这一是对回显端口看，即是端口7，不断发送小的UDP数据包来实现。看似发自两个策源地，可能是两个者同时使用不同的工具。在任何情况下，超负荷的数据流都会拖垮Web服务器。然而地址源不确定，不知道是源本身是分布的，还是同一个地址伪装出许多不同的IP地址，这个问题比较难判断。假如源地址不是伪装的，是真实地址，则可以咨询ARINI美国Internet号码注册处，从它的“whois”数据库查出这个入侵1P地址属于哪个网络。接下来只需联系那个网络的管理员就可以得到进一步的信息。

　　那么假如源地址是伪装的，追踪这个者就麻烦得多。若使用的是Cisco由器，则还需查询NetFlow高速缓存。NetFlow是Cisco快速转发（CEF）交换框架的特性之一。为了追踪这个伪装的地址，必须查询每个由器上的NetFlow缓存，才能确定流量进入了哪个接口，然后通过这些由器一次一个接口地往回一追踪，直至找到那个IP地址源。然而这样做常难的，因为在WebServer和者的发起pc之间可能经由许多由器，而且属于不同的组织。另外，必须在正在进行时做这些分析。

　　经过分析之后，将防火墙日志和由器日志里的信息关联起来，发现了一些有趣的相似性，如表黑色标记处。的目标显然是Web服务器192.68.0.175，端口为UDP7，即回显端口。这看起来很像服务（但还不能确定，因为的分布很随意）。地址看起来多多少少是随意而分散的，只有一个源地址是固定不变的，其源端口号也没变。这很有趣。接着又将注意力集中到由器日志上。

　　立刻发现，发生时由器日志上有大量的64字节的数据包，而此时Web服务器日志上没有任何问题。他还发现，案发时由器日志里还有大量的“UDP-other”数据包，而Web服务器日志也一切正常。这种现象与基于UDP的服务的假设还是很相符的。

　　者正是用许多小的UDP数据包对Web服务器的回显（echo7）端口进行洪泛式，因此他们的下一步任务就是这一行为。首先，我们在由器上堵截。快速地为由器设置了一个过滤规则。因为源地址的来源很随机，他们认为很难用某个地址或某一块范围的地址来，因此决定所有发给192.168.0.175的UDP包。这种做使服务器某些功能，如DNS，但至少能让Web服务器正常工作。