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

　　一、事件发生

　　春节长假刚过完，WEB就出现故障，下午1点吃完回来，立即将桌面解锁并习惯性的检查了Web服务器。通过Web服务器性能软件图像显示的向下滑行的红色曲线看到WEB出现问题了。

　　根据上述的问题，我马上开始核查Web服务器的日志，试试是否能检测到问题究竟什么时候开始，或者发现一些关于引起中断的线索。正当查询线索过程中。公司首席运营官(COO)告诉我，他已经接到客户的投诉电话，报告说无法访问他们的网站。于是从台式机中敲入网站地址，试着从台式电脑访问他们的网站，但是看到的只是无法显示此页面的消息。

　　回想前几天也未对Web服务器做了任何改变也未对Web服务器做过任何改变，服务器曾经出现过的性能问题。在Web服务器的日志文件中没有发现任何可疑之处，因此接下来我去仔细查看防火墙日志，和由器日志。仔细查看了防火墙日志，打印出了那台服务器出问题时的记录。并过滤掉正常的流量并保留下可疑的记录。表中显示了打印出来的结果。

　　图一

　　解释：

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

　　参数解释：

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

　　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服务器正常工作。

　　由器最初的临时DOS访问控制链表(ACL)

　　这样的做法为Web服务器减轻了负担，但仍能到达web，在一定程度上降低了网络性能。那么下一步工作是联系上游带宽提供商，想请他们暂时所有在他的网站端口7上的UDP入流量。这样做会显著降低网络上到服务器的流量。

　　三、针对DOS预防措施

　　对于预防及缓解这种带宽相关的DoS并没有什么灵丹妙药。本质上，这是一种“粗管子打败细管子”的。者能“”更多带宽，有时甚至是巨大的带宽，就能击溃带宽不够的网络。在这种情况下，预防和缓解应相辅相成。

　　有许多方法可以使更难发生，或者在发生时减小其影响，具体如下：

　　网络服务提供商应在他的下游网络上设置入口过滤，以防止假信息包进入网络(而把它们留在Internet上)。这将防止者伪装IP地址，从而易于追踪。

　　过滤掉网络不需要的流量总是不会错的。这还能防止DoS，但为了达到效果，这些过滤器应尽量设置在网络上游。

　　Ø网络流量速率一些由器有流量速率的最高。

　　这些条款将加强带宽策略，并允许一个给定类型的网络流量匹配有限的带宽。这一措施也能预先缓解正在进行的，同时，这些过滤器应尽量设置在网络上游(尽可能靠近者);

　　Ø入侵检测系统和主机工具

　　IDS能网络管理员的发生时间，以及者使用的工具，这将能协助。主机工具能管理员系统中是否出现DoS工具

　　这是CEF用于检查在接口收到的数据包的另一特性。如果源IP地址CEF表上不具有与指向接收数据包时的接口一致的由的话，由器就会丢掉这个数据包。丢弃RPF的妙处在于，它了所有伪装源IP地址的。

　　针对DDOS预防措施

　　看了的实际案例我们也了解到，许多DDoS都很难应对，因为搞的主机所发出的请求都是完全、符合标准的，只是数量太大。借助恰当的ACL，我们可以阻断ICMPecho请求。但是，如果有自己的自治系统，就应该允许从因特网上ping你。不能ping通会使ISP或技术支持团队(如果有的话)某些故障排解能力。也可能碰到具有CiscoTCP截获功能的SYN：

　　如果能采用基于上下文的访问控制(ContextBasedAccessControl，CBAC)，则可以用其超时和阈值设置应对SYN和UDP垃圾。例如：

　　：不要同时使用TCP截获和CBAC防御功能，因为这可能导致由器过载。

　　打开Cisco快速转发(CiscoExpressForwarding，CEF)功能可帮助由器防御数据包为随机源地址的。可以对调度程序做些设置，避免在的冲击下由器的CPU完全过载：

　　在做了这样的配置之后，IOS会用3s的时间处理网络接口中断请求，之后用1s执行其他任务。对于较早的系统，可能必须使用命令schedulerinterval《milliseconds》。

　　四、总结

　　无论是出于报复、、发起更大规模，DoS或DDoS都是一种不容轻视的。非同一般的DoS通常是某种不完整的漏洞利用—使系统服务崩溃，而不是将控制权交给者。防范这种的办法是及时打上来自厂商的补丁，或者对于Cisco系统，及时将操作系统升级到更新版本。同时，要关闭有漏洞的服务，或者至少要用访问控制列表访问。常规的DoS，特别是DDoS，经常不是那么有章法，也更难防范。如果整个带宽都被蹩脚的ping所耗尽，我们所能做的就很有限了。最后，必须与ISP和部门协作，尽可能从源头上。要用不同供应商、不同AS径并支持负载均衡功能的不止一条到因特网的连接，但这与应对消耗高带宽的常规DoS/DDoS的要求还相差很远。我们总是可以用CAR或NBAR来抛弃数据包或发动进攻的网络流速度，减轻由器CPU的负担，减少对缓冲区和由器之后的主机的占用。