[ 目录 ]

一 布景

二 应急响应

三 常见ddos抨击打击及防御

四 本源及反击

五 总结

一布景

在前几天，我们运营的某网站遭受了一次ddos抨击打击，我们的网站是一个公益性质的网站，为各个厂商和白帽子之间搭建一个平台以传递平安问题等信息，我们其实不清楚因为什么原因会遭遇这种无耻的抨击打击。因为我们自己其实不从事这种类型的抨击打击，这种抨击打击手艺一般也是比较粗糙的，所以讨论得比较少，可是既然产生了这样的抨击打击我们感觉分享抨击打击产生后我们在这个过程中学到得东西，以及针对这种抨击打击我们的想法才能让这次抨击打击产生真正的价值，而其实不是这样的抨击打击仅仅华侈年夜家的时间罢了。

别的，我们发现年夜型的企业都有遭受抨击打击的案例，可是年夜家遭受抨击打击之后的应对办法及学到的经验却分享都比较少，这致使各家都是自行的摸索经验，依然停留在一家企业匹敌整个互联网的抨击打击的场合排场，而对抨击打击者却是此次抨击打击针对你，下次抨击打击却是针对他了，并且抨击打击之后无论是手艺仍是资源都没有任何的损耗，这也是致使这种抨击打击频繁并且肆无顾忌的原因。

我们来测验测验做一些改变：）

二应急响应

在抨击打击产生后，第一个现象是我们的网站上不去了，可是依然可以拜候到办理界面，我们登岸上去简单执行了命令：

netstat -antp

我们看到有年夜量的链接存在着，并且都是ESTABLISHED状态，正常状态下我们的网站拜候量没有这么高，如果有这么高我们相信中国的信息平安就有希望了，对这样的情况其实措置就比较简单，这是一次四层的抨击打击，也就是所有ip都是真实的，由于目前为止只是消耗了webserver的网络毗连资源，所以我们只需要简单的将这些ip在网络层封禁便可以，很简单，用下面的命令便可：

for i in `netstat -an | grep -i ‘:80 ‘|grep ‘EST’ | awk ‘{print $5}’ | cut -d : -f 1 | sort | uniq -c | awk ‘{if($1 > 50) {print $2}}’`

echo $i

echo $i >> /tmp/banip

/sbin/iptables -A INPUT -p tcp -j DROP -s $i

done

然后作为打算任务一分钟执行一次便可，很快，iptables的封禁列表就充满了年夜量的封禁ip，我们简单的统计了下毗连数最年夜的一些ip发现都来自韩国。为了包管系统的性能，我们调年夜了系统的可接管的毗连数以及对Nginx进行了每个毗连能够进行的请求速率，系统于是恢复了正常的运行。 正常状态一直延续到第二天，可是到中午之后我们发现拜候又呈现了问题，网络很慢，使用ping发现年夜概呈现了70%左右的丢包，在艰巨的登岸到系统上之后，发现系统已经很少有TCP的正常毗连，为了查明原因，我们对系统进行了抓包：

tcpdump -w tmp.pcap port not 22

tcpdump -r tmp.pcap -nnA

我们发现抨击打击已经从应用层的抨击打击调剂到了网络层的抨击打击，年夜量的目标端口是80的udp和icmp包以极快的速度布满了网络，一个包年夜小年夜概在1k左右，这次占据的资源纯粹是带宽资源了，即便在系统上做限制也解决不了这个问题，不过也没有关系，对网络层的问题我们可以在网络层上做限制，我们只需要在网络上把达到我们ip的非TCP的所有包如UDP和ICMP等协议都制止失落便可，可是我们没有自己的办事器也缺乏对网络设备的节制权，目前是由工信部CERT提供支持的，由于姑且无法协调进行相应的操作，后果如年夜家看到，我们的办事很慢，根基上停止了办事，在一段时间之掉队犯者停止了抨击打击，办事才进行了恢复，很憋屈是么？可是同时我们取得了很多热心朋友的帮忙，取得了更好的网络和办事器资源，在网络资源方面的能力取得了很年夜的提升，减缓了这方面的问题，这里对他们暗示感激。

三常见ddos抨击打击及防御

继续秉承80sec的"Know it then hack it"，这里简单谈一下ddos抨击打击和防御方面的问题。ddos的全称是散布式谢绝办事抨击打击，既然是谢绝办事一定是因为某些原因而停止办事的，其中最重要的也是最常常使用的原因就是操纵办事端方面资源的有限性，这种办事真个资源范围很广，可以简单的梳理一个请求正常完成的过程：

1用户在客户端阅读器输入请求的地址

2阅读器解析该请求，包含阐发其中的dns以明确需要达到的远程办事器地址