9月18日

    晨，网站访问突然变得非常困难，最初怀疑机房的路由出问题（曾经出过一次），和机房联系后更换了路由，但问题仍旧。

    中午，偶然发现有大量处于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/

建议继续学习：

1. 本周扑火之 http client 慢连接问题    (阅读：2706)