背景

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，对于攻击具体技术细节未知。如有麻烦给我学习一下~

参考资料

相关文章该作者更多文章

2 意见

留下一个答复

Please enter your comment!
Please enter your name here