这是人人影视分享站被黑的最惨的一次

最近这段时间，我的人人影视分享站不怎么太平，不是被恶意爬虫就是被CC攻击。不知道是遭遇了竞争对手还是怎么的。

3月7日中午，收到cloudflare邮件说服务器无法连接

SSH看一下日志，果然，有很多莫名其妙的搜索，

这些请求主要有如下特点：

40秒内200多个请求，分布在60个不同的IP地址上，还全都是中国民用家宽的IP。

1. 使用中国各个地区、各个运营商的民用家宽IP，比如上图40秒内200多请求，分布在60个不同的IP地址上
2. 同一个IP的UA还会变，一会是Chrome一会是Firefox，这看起来很不正常
3. 即使到了下半夜也还在大量请求，正常人都是要睡觉的
4. 搜索内容大致为某些综艺的名字+集数或演员名字，没有referer，正常搜索浏览器是一定会带referer的，因此应该是机器人直接发出的请求
5. 他直接请求的！要是跑的selenium我也就认啦，就当给我点广告了

我尝试了如下解决方案：

1. 根据IP去cloudflare上拉黑，结果发现IP太多，根本拉不过来
2. 用Cloudflare的 rate limit去限制请求频率，结果因为他们IP实在是太多了，全都分散开了，没用
3. 开cloudflare的DDoS 防护规则也没用，因为IP太多了，在cf 看来基本就是正常请求，至少免费版来看是这样的

发现以上办法似乎都没有什么用，于是开了三秒墙，所有用户在打开网站的时候都会有浏览器检查，大概这样

机器人自然无法完成JS challenge，于是这一波下来稳了。

我的数据库是公开的，这么爬很不地道，动了这么多IP也一定没少破费。何必呢？我也不是什么竞争对手，我只不过是开了一个很普通的个人站，全靠网友贡献。挺累的。

几天之后星期五，我发现网站竟然又挂了！开着三秒墙也能被打挂？看了一眼日志……

Vultr的美国机，竟然用这种随机无意义的字符串来搜索，竟然还绕过了三秒墙，也绕过了rate limit。🤣于是MongoDB炸了，nginx也基本要炸了。

去cloudflare上添加了黑名单，并没有效果。哦豁？难道是cloudflare又bug了……想了一下，不对，是我的源站IP被找到了，怪不得三秒墙和rate limit都没效果😓

这种情况下只能去机器上添加防火墙，或者机器的供应商那里添加安全组之类的了。不幸的事情来了：

1. 没有安全组可用
2. 我的nginx是docker启动的，这也就意味着一般的在INPUT链拉黑IP的办法不管用
3. 在尝试调解docker和nginx的过程中，一不小心写错了iptables规则。出门没带钥匙嘛。
4. 我不知道SSH的密码是什么，应该是16位的hex，去grub改init然后修改密码很麻烦毕竟是VNC

不幸之外还有一些好消息：

1. 我没有持久化iptables规则，意味着只要去控制面板重启一下，我刚刚写错的规则就会消失了！
2. 我可以换IP，至少能够暂时化解这种情况

于是问题就这么解决了。这是我做这个小破站被黑的最惨的一次。在这次经历中，我学习到了如下经验教训：

1. 爬虫死全家，尤其是45.32.227.75 😄
2. docker会破坏基于iptables为后端的防火墙。Docker跑的应用，如果绑定了端口，那么会给iptables打洞，意味着常规堵INPUT链的办法不管用，要PRE ROUTTING、改DOCKER-USER或者让docker和ufw一起工作，巨麻烦，心智负担非常大。
3. 网站躲在cloudflare后也可能被抓到源站IP，比如说censys，全网扫IP+443然后找证书，或者IP+80比对特征
4. 应该拒绝全部非cloudflare IP对80和443的请求，甚至直接通过argo tunnel之类的来解决，连nginx都用不上
5. 保护好自己的IP，毕竟只要IP被抓到了，14亿中国人一人一个ping你也受不了🇨🇳
6. 在MongoDB中使用正则模糊查询，如/.*keyword.*/是非常慢的，全文检索的话，我记得是Atlas专有，而且一旦涉及到CJK，也有可能完犊子
7. 容器如果一直不停地yyetsbot_web_1 exited with code 137，记得检查下是不是有什么奇奇怪怪的保活监测脚本
8. 配置路由表、iptables规则时务必小心，务必给自己留后门。我之前留的后门是只能通过console登录的root权限用户，密码不是很复杂，通过VNC之类的东西输入还是可以的
9. MongoDB的aggregation很强大，可以做到跨集合查询，自定义查询字段名称等等
10. 遇到问题不要慌，记得先撸猫再解决问题