晨,网站访问突然变得非常困难,最初怀疑机房的路由出问题(曾经出过一次),和机房联系后更换了路由,但问题仍旧。
中午,偶然发现有大量处于SYN_RECV状态的链接,google后怀疑遭到SYN Flood攻击。
查询处于SYN状态的连接数,可以用这个命令:
netstat -atn | grep -c SYN
查询连接最多的ip:
netstat -atn | grep “SYN” | awk ‘{print $5}’ | awk -F’:’ ‘{print $1}’ | sort -nr | uniq -c | sort -nr | head
发现有若干ip的连接数在200以上,基本确定为SYN攻击。
然后开始用手工方式BAN掉这些IP:
iptables -A INPUT -p tcp -s 攻击者ip -dport 80 -j REJECT
因为在上班,没有更多时间处理,只能隔一阵子BAN一些连接数超过50的IP,勉强维持网站的访问。
9.19凌晨
在几位朋友的帮忙下,改了一个脚本,把上述工作改成了自动执行。每隔一分钟检查SYN状态下连接数过高的ip,然后BAN掉。
9月19日
脚本非常有效,除load稍高之外,访问正常。
9月20日
攻击方发现SYN无效后,改为使用WAIT状态的连接攻击。这个相对好办,只要把上述代码中的SYN改成 “SYN\\|WAIT”即可。如:
netstat -atn | grep -c “SYN\\|WAIT”
9月22日
攻击加剧,可能是攻击方调用了更多的机器发动攻击。服务器load高达800-900,ssh完全无法登录。
通知机房停掉了电信ip,对方果然不知道这机器的网通ip。电信ip停掉后,顺利地通过网通ip登入Shell。
暂时没有更好的办法,改了一些shell内核参数,包括启用syn cookie等,然后把自动BAN IP的脚本改为超过30个慢连接就BAN。
但这样很容易误杀,比如一些学校、公司和网吧用户,他们是同一网站ip的。
这样改了之后又勉强撑住。
9月23日
终于找到一个治本的办法:使用nginx当apache的反向代理。
nginx是老毛子开发的一个web服务器和反向代理,把它架在apache的前面,作为前端web服务器。
因为它本身具有防慢连接的机制(原理不说了,google一大堆),所以先把所有对80端口的访问交由nginx来处理。
对于图片/js/css等静态文件,由nginx直接返回,不交给apache。
而php文件才交给apache处理。
TIP:这么做还有一个好处,如果把nginx的connection设为keep-alive,而apache设为close,整体效率还会高很多。
这么一来,居然效果奇好。apache的进程数直接从200+降为15左右,而nginx本身的进程才2个,系统load直接下降。
而且对慢连接,即使有几个ip的WAIT状态链接高达1000+也对网站访问毫无影响。
TIP:记得把apache设为只侦听127.0.0.1的访问,以免外部直接绕过nginx冲击apache。
这里有一篇文章讲这个结构:http://kovyrin.net/2006/05/18/nginx-as-reverse-proxy/