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/