登录
  • 人们都希望被别人需要 却往往事与愿违
  • 读书是在别人思想的帮助下建立自己的思@尼古拉。鲁巴金 (俄国作家)

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

建站运维 Benny小土豆 5850次浏览 1820字 7个评论
这篇文章在 2023年03月15日08:04:33 更新了哦~

最近这段时间,我的人人影视分享站不怎么太平,不是被恶意爬虫就是被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. 遇到问题不要慌,记得先撸猫再解决问题

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

 


文章版权归原作者所有丨本站默认采用CC-BY-NC-SA 4.0协议进行授权|
转载必须包含本声明,并以超链接形式注明原作者和本文原始地址:
https://dmesg.app/yyets-hack.html
喜欢 (12)
分享:-)
关于作者:
If you have any further questions, feel free to contact me in English or Chinese.
发表我的评论(代码和日志请使用Pastebin或Gist)
取消评论

                     

去你妹的实名制!

  • 昵称 (必填)
  • 邮箱 (必填,不要邮件提醒可以随便写)
  • 网址 (选填)
(7)个小伙伴在吐槽
  1. 为什么会有这样的坏家伙🥵
    mmn2023-08-15 18:11 回复
  2. 太可怕了,希望博主接下来能好好撸猫( 感谢博主分享~ 今天又增加了一个案例经验
    Misaka_Clover2023-03-18 12:41 回复
  3. 槽点太多, 不知道该从哪里吐槽 仅限cloudflare访问可以从NGINX配置阻挡 allow xxxx/x; cloudflare的网段 allow 127.0.0.1; deny all; 防IP检索可以通过开一个default的网页随便挂一个SSL证书阻挡 更安全可以在default站点直接加一个 ssl_reject_handshake on; 直接不让获取SSL证书
    adfsfas2023-03-14 07:33 回复
    • 现在只开一个22了🤪
      --本评论由Telegram Bot回复~❤️
      Benny小土豆2023-03-14 07:49 回复
    • 为了防止别人在 CF worker 上部署扫描,还应当启用 CF 的“经过身份验证的源服务器拉取”,并给 Nginx 加上如下配置: ssl_client_certificate /PATH/TO/CF/CERT; ssl_verify_client on;
      Vifly2023-03-14 12:54 回复
      • 现在根本都不监听80和443端口了,扫吧把腿扫断也没结果🤪
        --本评论由Telegram Bot回复~❤️
        Benny小土豆2023-03-14 13:02 回复
  4. 好可怕,源站 IP 被找出来确实没救了
    Vifly2023-03-13 13:00 回复