背景

3月1日早上9点起,我的个人博客收到反馈打不开,开始排查。

已知信息

  • 尝试ssh连接,连接时超时,看来 host 已经几乎失去响应
  • http、https 连接全部表现为超时
  • 半小时后,后端的 MySQL 数据库出现 OOM(数据库和 nginx 分布在2台 host 上)
  • 阿里云页面监控得知机器指标如下,CPU 被打满,TCP OUT 被打满
  • 偶然连上 host 后发现占用率较高的进程为 nginx 和 memcached
  • 已知博客使用的 WordPress 在当下版本 4.9.4 有一个未修复的 DoS 漏洞 CVE-2018-6389(详见参考资料)

初步判断

nginx 被 DoS 攻击,具体目标未知,疑似使用上述漏洞(实际并不对,于是下面开始走弯路)。

错误路径

  1. 重启服务器,尝试连上 ssh,然而连上不超过 30 秒又失去响应,观察监控发现 CPU 和 TCP OUT 再次被打满
  2. 再次重启服务器,在 ssh 失去连接前修复了 CVE-2018-6389(详见参考资料),然而2分钟不到 host 再次失去响应,即攻击者使用的不是这个漏洞
  3. 想到我的博客从来没有配置过 CDN 防护,遂一股脑配置了 cloudflare。DNS 生效后发现 TCP OUT和 CPU 占用陡然降低,web 恢复访问,欣慰中
  4. 约 20 分钟, TCP OUT和 CPU 占用又全部打满,心想难道通过 cloudflare 缓存了一层后打到服务器的量还有这么大?遂给 host 临时增加带宽,加完后也是无济于事,立即又是打满
  5. 10分钟发现使用阿里云 web 上提供的控制台勉强可以连上,但是操作很卡,但是对排查问题是利好,便打开 nginx 的访问日志,旨在寻找来源。等待5分钟后,用此统计来源 IP:
    awk '{print $1}' nginx_access.log |sort |uniq -c|sort -n

    但是并没有找到有某个 IP 有异常的大量登录,开始怀疑攻击不是冲着 nginx 来的

  6. 为了证实不是冲着 nginx 来的,从系统层面统计连接数
    #80端口连接数
    netstat -anp | grep :80 | grep ESTABLISHED | wc -l
    #443端口连接数
    netstat -anp | grep :443 | grep ESTABLISHED | wc -l
    

    发现连接数都不高,且和正常时候差不多,也就是坐实了猜测。问题来了,流量是冲着哪儿来的呢?正想再看下其他端口的连接情况,发现 web 控制台也死了

再次思考

  1. 重新盘了一下现有已知信息,最终落在了占用率较高的 Memcache 上,突然想到几个月前因为Memcache 性能不足,做了 Memcache 到 redis 的改造,讲道理应该没有用到 Memcache 啊?何来的占用?
  2. code review,确定 Memcache 已经完全不依赖,此时 Google 了几个 Memcache 莫名占用变高的故障,大多由机器时间不准引起,也不符合我的场景。
  3. 想到 Memcache 代码中已经不再使用,但是服务我是没有关闭。再次重启服务器,争分夺秒关掉了 Memcache
  4. TCP OUT 和 CPU 正常,观察了 1 小时没有问题。但是心中还是有疑惑,为啥关了 Memcache 就好了?

结果

  1. 隔日,发现报道有利用 Memcache 进行 DRDoS 进行攻击的新闻(见参考资料),昨日表现与之完全符合,这才知道发生了什么
  2. 由于没有保留攻击现场的连接数和开发端口详情,被攻击时机器能登上去都是万幸了,shell 几乎就是卡死状态,没法很清楚的复盘。遗憾

复盘

  1. 在第一次把博客部分迁移到 cloudflare 的时候,导致 DNS 变更,也就是域名直接指向的 IP 由 host 的公网 IP 改为了 cloudflare CDN 的 IP,指使一部分流量打空了,得到了20分钟的喘息的机会
  2. 攻击者发现使用域名失效后,可以采用二级域名的方式,如 ftp.xxx.com,得知实际的 host 地址,继续实施攻击
  3. 为了防止同样的问题再发生,nmap 扫描所有开放的 TCP 和 部分 UDP
    nmap -sS -sU -T4 -A -v 121.42.169.248
    nmap -p 1-65535 -T4 -A -v 121.42.169.248

    用 iptable 关闭不需要暴露到公网的端口,将标准端口换成非标准端口(如 FTP 的 21 换为 10000以上的一个自定义端口),如果是必须暴露出的做好 iptable 的白名单配置,并做好服务器相关指标的报警

  4. 从易用性来看,实施这样的攻击成本很低。5 万倍放大的反射型 DDOS 又如同 DDOS 中的一颗核弹,也是反射型 DDOS 放大系数中高的极其少见的。攻击者只要做针对 11211 端口的扫描(TCP UDP皆可),然后用 5 万被的放大四两拨千斤就可以干趴 host,攻击难度低,这也是从监控图表上看 TCP IN 很低但是 TCP OUT 很高的原因。而且使用 PHP 语言的站点又极多且默认环境中都配有 Memcache 且默认对外监听,可以说危害性极大。类似的攻击在当日甚至影响了 GitHub 这样的站点
  5. 服务表现上看,很像是 CC 攻击,要不是由于我没有用到 Memcache 帮助我定位到了问题,否则不知还要走多少弯路。而后端 MySQL 服务器的 OOM,在排查时给我了误导,也说明当一个 host load 极高的时候,是能影响上游的
  6. 由于未找到 POC,对于攻击具体技术细节未知。如有麻烦给我学习一下~

参考资料

留下一个答复

Please enter your comment!
Please enter your name here