应急响应

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