问题是

服务器资源很快耗尽，连SSH都很难连上，连上去之后用top发现内存基本耗光，全部被Apache的进程占满。

好吧虽然本站的服务器是AWS小霸王，应该也不至于跑个Apache就挂了，并且本来也没什么人会访问。

并不是GFW的锅

实际上AWS EC2小霸王一直很稳定，所以一开始并没有注意到是资源问题，只是半天打不开网页。这种时候，作为一个业余时间发点闷骚没人看文章的小白，根本没想到有那么无聊的人会攻击我。同时作为一个天朝网民，敏锐的感觉到这一定是GFW的锅。

然而并不是，的确对于所有境外服务器因为GFW的关系都会有QoS的劣化，不过拿俩VPN验证过了之后发现并不是被ban了。

临时救火

当SSH也连不上去的时候也没什么能做的事情，AWS提供了主机镜像功能，所以当服务器被攻击到彻底瘫痪的时候，就只能启用另一个镜像，并且停掉原来的instance。然而存储是收钱的，所以这种方式实际上有额外支出。更重要的是：以镜像顶DoS，由抱薪救火，薪不尽火不灭。

所以做的第一件事就是把影响控制在80端口上，也就是说即使网页不能访问，只要后台能登陆上服务器，就能继续想办法。通过限制Apache的访问量，限定其能使用的最大内存量。

配置/etc/httpd/conf/httpd.conf文件，将Apache进程数和最大接受的request减小到内存可以容忍的程度。

<IfModule prefork.c>
#StartServers 8
#MinSpareServers 5
#MaxSpareServers 20
#ServerLimit 256
#MaxClients 256
#MaxRequestsPerChild 4000
StartServers 4
MinSpareServers 2
MaxSpareServers 7
ServerLimit 16
MaxClients 16
MaxRequestsPerChild 1000

这样即使攻击者突破了后面设置的防火墙，也只能瘫痪掉web服务，不会把整个服务器瘫痪掉。

如何攻击

用netstat看一下连接状态，并且统计一下每个状态下连接的数量。

netstat -anl | awk '/^tcp/ {t[$NF]++}END{for(state in t){print state, t[state]} }'

大量的连接在SYN_RECV和CLOSE_WAIT状态 (对于我来说几十个就是大量了)这就是典型的flood攻击了。虽然有一些配置可以缓解，比如配置/etc/sysctl.conf或者用sysclt -w修改下面几个内核参数。

net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_synack_retries = 2
net.core.somaxconn = 1023

这个对SYN Flood有点用，但没法彻底解决问题。

如何缓解

对于这种又小又穷的站，基本上只能缓解，没法彻底解决DoS。当然攻击也是有成本的，所以又小又穷的站也有个优势，就是攻击者一般不会长时间用大量的资源发动DDoS，否则基本我也只能看着了，最多装个可视化网络流量的小玩意自娱自乐一下。

要找出攻击者或者攻击者的肉鸡，只需要用netstat |grep CLOSE看到是哪些源地址制造了这些连接。

总体来说还是俄罗斯和东欧的IP比较多，不愧是黑客大国。

查到之后比较原始的办法就是iptables直接抛掉所有这些源对80端口的请求。

iptables -A INPUT -s  195.2.0.0/16  -p tcp   --destination-port 80 -j DROP

作为一个又小又穷的破站，还有一个好处，就是我完全不关心是不是会误伤到其他从这个网段过来的正常请求，所以这里就直接ban掉整个B类地址了。

如果源是一个服务商的域名，也可以用字符串去匹配。

iptables -A INPUT -p tcp --destination-port 80 -m string --string "Host: static.spheral.ru" --algo bm -j DROP

但是字符匹配的准确率不太好，所以即使试下来，用netstat -n直接获取IP，然后Ban整个网段更加有效。

以上的方案可以写成一个脚本自动执行，而且如果手工加的量太大的话，我也考虑这么做。

而正常的方式应该是买CDN或者防火墙之类的，目前感觉完全没必要在这上面大动干戈。所以虽然现在这种方法还属于地毯式轰炸的粗糙方案，但也就先如此吧。