应急响应
在攻击发生后，第一个现象是我们的
网站上不去了，但是依然可以访问到管理界面，我们登陆上去简单执行了命
令：
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 等协议都禁止掉即可