攻击的解决方案.docVIP

当网站遭遇DDOS攻击的解决方案及展望 当网站遭遇DDOS攻击的解决方案及展望 更多：HYPERLINK // 一、事件发生春节长假刚过完，WEB就出现故障，下午1点吃完回来，立即将桌面解锁并习惯性的检查了Web服务器。通过Web服务器性能监视软件图像显示的向下滑行的红色曲线看到WEB出现问题了。根据上述的问题，我马上开始核查Web服务器的日志，试试是否能检测到问题究竟什么时候开始，或者发现一些关于引起中断的线索。正当查询线索过程中。公司首席运营官(CIO)告诉我，他已经接到客户的投诉电话，报告说无法访问他们的网站。于是从台式机中敲入网站地址,试着从台式电脑访问他们的网站，但是看到的只是无法显示此页面的消息。回想前几天也未对Web服务器做了任何改变也未对Web服务器做过任何改变，服务器曾经出现过的性能问题。在Web服务器的日志文件中没有发现任何可疑之处，因此接下来我去仔细查看防火墙日志，和路由器日志。仔细查看了防火墙日志，打印出了那台服务器出问题时的记录。并过滤掉正常的流量并保留下可疑的记录。表中显示了打印出来的结果。 源IP地址 目的IP地址 源端口号 目的端口号 协议 75 7843 7 17 66 75 19 7 17 75 34511 7 17 66 75 19 7 17 11 75 1783 7 17 66 75 19 7 17 75 29589 7 17 2 75 17330 7 17 66 75 19 7 17 31 75 8935 7 17 75 22387 7 17 66 192.768.0.75 19 7 17 75 6588 7 17 1 192.768.0.75 21453 7 17 66 75 19 7 17 9 75 45987 7 17 4 75 65212 7 17 75 52967 7 17 5 75 8745 7 17 66 75 19 7 17 表一 防火墙日志 之后在路由器日志上做了同样的工作并打印出了看上去异常的记录。攻击期间的路由器日志 图一 解释：IP packet sizedistribution这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：98.4%的数据包的大小在33字节到64字节之间（注意红色标记）。参数解释：IP packet sizedistribution这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：98.4%的数据包的大小在33字节到64字节之间。Protocol协议名称Total Flows 自从最后一次清除统计信息后，这种协议的信息流的个数。Flows/Sec 每秒钟时间内出现这种协议的信息流的平均个数，它等于总信息流数/综合时间的秒数。Packets/Flow遵守这种协议的信息流中平均的数据包数。等于这种协议的数据包数，或者在这段综合时间内，这种协议的信息流数。Bytes/Pkt 遵守这种协议的数据包的平均字节数(等于这种协议总字节数，或者在这段综合时间内，这种协议的数据包数)。B/Pkt，这一信息流中每个数据包的平均字节数Packets/Sec 每秒钟时间内这种协议的平均数据包数(它等于这种协议的总数据包)，或者这段综合时间的总秒数。Active(Sec)/Flow从第一个数据包到终止信息流的最后一个数据包的总时间(以秒为单位，比如TCP FIN，终止时间量等等)，或者这段综合时间内这种协议总的信息流数。Idle(Sec)/Flow从这种协议的各个非终止信息流的最后一个数据包起，直到输入这一命令时止的时间总和(以秒为单位)，或者这段综合时间内信息流的总时间长度。正常路由日志 图二 IP packet sizedistribution这个标题下的两行显示了数据包按大小范围分布的百分率。这里显示的内容表明：2%的数据包的大小在33字节到64字节之间。注意网站的访问量直线下降。很明显，在这段时间没人能访问他的Web服务器。我开始研究到底发生了什么，以及该如何尽快地修复。二、事件分析我的Web服务器发生了什么？很有可能攻击，那么受到什么样的攻击呢？从这一攻击是对回显端口看，即是端口7，不断发送小的UDP数据包来实现。攻击看似发自两个策源地，可能是两个攻击者同时使用不同的工具。在任何情况下，超负荷的数据流都会拖垮Web服务器。然而攻击地址源不确定，不知道是攻击源本身是分布的，还是同一个地址伪装出许多不同的IP地址，这个问题比较难判断。假如源地址不是伪装的，是真实地址，则可以咨询ARIN I美国Internet号码注册处，从它的“whois”数据库查出这个入侵1P地址属于哪个网络。接