被攻击的一周

2016年11月26日，网站被攻击整整一周了，现在还有没有停止的迹象，真是哔了狗了。

不得不说一周之前我过于乐观。当时以为能凭借后台本身的错误检查机制和限制直接扛下来攻击，但是我错了。主要是因为网站本身调用了很多第三方服务，比如短信，当初写程序的时候偷懒，并没有在发短信之前加上图形验证码的验证。黑客攻击一天之后，更改了策略，疯狂发请求刷短信，分分钟导致我们被运营商封掉了。我立马加了更多硬性的限制，但是没啥用，重新上线短信功能之后，依然两个小时之内就被刷爆（虽然短信费损失非常小。。。），此时不得已必须得加上图形验证码。

所以，奉劝大家不要有侥幸心理，被黑客盯上了，就乖乖上验证码吧，其他的措施往往很容易绕开的（或者太严格就会妨碍到真实的用户）。

另外，除了验证码，我还是按上一篇文件说的方法，找到了异常的ip并且加到了nginx的配置里，让nginx直接拒掉这些ip比后台api server验证高效很多。

nginx要拒绝这些ip的请求有很多方法，比如用map、deny等。
用deny方式的话，简单示例如下：

deny 11.11.11.11;

如果你的nginx直接接受用户的请求的话，这样子是没问题的。但是如果nginx在load balancer后面的话，这样deny没用。因为在nginx本身看来，所有请求ip都是来自于load balancer的。这个时候，需要告诉nginx真正的ip在哪，方法如下：

set_real_ip_from 110.110.110.0/24;
real_ip_header X-Forwarded-For;
deny 11.11.11.11;

这就是告诉nginx：nginx啊，你的请求来自己于110.110.110.0/24这个网段（load balancer所在的网段），不要怀疑，相信它就好了，然后从X-Forwarded-For这个http头去查真正的地址，查到之后拒绝11.11.11.11这个小婊砸。（注意，别忘了在load balancer的上设置好http头）

我找到了1k多可疑ip，直接放在这个配置里面，会导致这个配置不容易维护，解决办法是：

include block.conf;

然后在block.conf里面写上deny语句。这样，也方便直接用脚本（awk和sed可以搞定)生成block.conf。

最后，贴张图表达我对攻击者的感受：

狗带