搜索到
1
篇与
流量劫持后门修复
的结果
-
服务器被植入流量劫持后门(跳转世界杯赌球网站)的排查与解决方案 前言这两天遇到一个非常头疼的问题：我的一台云服务器上部署的网站，访问时会有很大概率跳转到赌球网站（刚好世界杯期间，什么牛鬼蛇神都出来了）。更诡异的是，哪怕我放一个纯空白 HTML 页面上去，依然会被劫持。折腾了好几天，最终定位到是一套精心伪装的 rootkit 后门。本文记录完整的排查、分析和清理过程。一、症状描述先说环境：三台云服务器，同一家服务商出问题的这台：Ubuntu 系统另外两台正常的：CentOS 系统所有网站运行在 Nginx 上，通过 宝塔面板 管理症状：手机端（PC端没发现症状）访问网站（无论哪个域名），浏览器有很高概率跳转到 https://dd0a000h4orvt.cloudfxxxt.net/?cid=8214805 （域名已做了无害处理）这个赌球网站即使是刚上传的空白 test.html（内容就一句 hello），依然会跳转开启 Cloudflare 小黄云（代理模式）无效，关闭小黄云（DNS only）也无效从服务器上 curl 访问页面，返回正常，没有任何跳转另外两台 CentOS 服务器完全正常二、初步分析2.1 排除 ISP/DNS 层面因为只有这一台服务器有问题，而三台机器用的是同一家云服务商，所以排除了"运营商线路劫持"的可能。如果是 ISP 层面的劫持，三台服务器应该都会中招。2.2 为什么 Cloudflare 无效Cloudflare 的代理模式会将用户流量先经过 Cloudflare 节点再转发到源服务器。如果劫持发生在源服务器发出响应之后（比如浏览器执行时），那么 Cloudflare 也救不了。2.3 核心疑点：curl 正常但浏览器跳转这说明劫持不是发生在 Nginx 配置层面（因为 curl 返回的是原始响应），而是在更上层——要么是浏览器端被注入 JavaScript，要么是网络传输层被篡改。三、深入排查3.1 先看 Nginx 配置nginx -T 2>/dev/null | grep -i "redirect\|rewrite\|return 302\|sub_filter"输出中除了正常的 rewrite 规则外，没有发现明显的恶意配置。3.2 检查进程——发现重大线索lsof -i :443输出赫然出现了三个可疑进程：defunct 812 root 3u TCP spk.laws.ms:33018->ec2.us-east-2.amazonaws.com:https (ESTABLISHED) iptable6 817 root 4u TCP spk.laws.ms:54498->ec2-13-57-38-185.us-west-1.compute.amazonaws.com:https (ESTABLISHED) iptable6 28789 root 4u TCP spk.laws.ms:54498->ec2-13-57-38-185.us-west-1.compute.amazonaws.com:https (ESTABLISHED)defunct——这个名字看起来像是进程状态（<defunct> 表示僵尸进程），实则是恶意程序iptable6——伪装成系统工具（正确名称是 ip6tables），拼写故意只差一点点这两个进程都在向外部的 AWS EC2 服务器建立 HTTPS 连接。3.3 定位二进制文件file /usr/bin/defunct /usr/bin/iptable6 ls -la /usr/bin/defunct /usr/bin/iptable6/usr/bin/defunct: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped /usr/bin/iptable6: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header两个文件都是静态链接、strip 去符号，显然是恶意软件标准做法。defunct 的文件日期被伪造为 2003-09-08，而 iptable6 的日期是 2026-04-28，说明是近期才植入的。lsof -i -P -n | grep -E "defunct|iptable6"defunct 812 root TCP 127.0.0.1:33018->212.132.98.170:443 (ESTABLISHED) iptable6 817 root TCP 127.0.0.1:54498->13.57.38.185:443 (ESTABLISHED)两个二进制分别连接不同的 C2 服务器，形成两条指挥通道。3.4 找到自启动持久化机制grep -r "iptable6\|defunct" /etc/init.d/ /lib/systemd/ 2>/dev/null结果令人震惊——几乎每个 /etc/init.d/ 下的脚本都被注入了 /bin/iptable6：/etc/init.d/keyboard-setup.sh:/bin/iptable6 /etc/init.d/apparmor:/bin/iptable6 /etc/init.d/docker:/bin/iptable6 /etc/init.d/open-vm-tools:/bin/iptable6 /etc/init.d/postfix:/bin/iptable6 ...（共 20+ 个文件）更隐蔽的是 systemd 层面：/lib/systemd/system/defunct.service: ExecStart=/bin/bash -c "GS_ARGS='-k /lib/systemd/system/defunct.dat -ilq' exec -a '[kswapd0]' '/usr/bin/defunct'"这里使用了 exec -a '[kswapd0]' 技巧——将进程名伪装成 Linux 内核线程 [kswapd0]，用 ps aux 根本看不到它。3.5 查看登录记录——找到攻击来源last -10root pts/2 212.132.98.170 Mon Jun 1 02:40 - 04:41 (02:01)6月1日凌晨，一个来自 212.132.98.170 的 IP 通过 SSH 登录了这台服务器，持续了整整两个小时——这就是攻击者。3.6 Docker 容器的问题还发现服务器上运行了两个可疑的 Docker 容器：docker ps -atraffmonetizer/cli_v2 ← 带宽贩卖工具 earnfm/earnfm-client:latest ← 同类流量变现服务这两个容器将服务器作为代理出口节点，虽然不是导致劫跳转的直接原因，但它们进一步消耗服务器资源且可能引来更多攻击。四、根因总结完整的攻击链如下：攻击者 SSH 登录 (212.132.98.170) ↓ 植入 /usr/bin/defunct 和 /usr/bin/iptable6 ↓ 创建 defunct.service (伪装成 [kswapd0] 内核线程) ↓ 在所有 /etc/init.d/* 脚本中注入 /bin/iptable6 ↓ defunct 连接 C2 (212.132.98.170:443) iptable6 连接 C2 (13.57.38.185:443) ↓ 作为透明代理层，对进出流量做中间人攻击 ↓ 在 HTTP 响应中注入 JavaScript 跳转代码 ↓ 用户浏览器访问 → 赌球网站跳转五、清理过程5.1 停止并删除恶意服务systemctl stop defunct.service systemctl disable defunct.service rm -f /lib/systemd/system/defunct.service rm -f /lib/systemd/system/defunct.dat systemctl daemon-reload5.2 杀进程kill -9 $(pgrep -x defunct) 2>/dev/null kill -9 $(pgrep -x iptable6) 2>/dev/null kill -9 $(pgrep -f "\[kswapd0\]") 2>/dev/null5.3 删除恶意二进制rm -f /usr/bin/defunct /usr/bin/iptable6 /bin/defunct /bin/iptable65.4 清理 init.d 注入sed -i '/\/bin\/iptable6/d' /etc/init.d/*5.5 清理 Dockerdocker rmi traffmonetizer/cli_v2 earnfm/earnfm-client:latest -f5.6 修改所有密码passwd root # 改 root passwd mysql # 改数据库 宝塔面板中修改面板密码5.7 重启并验证reboot重启后多次刷新访问网站，确认不再跳转。六、事后加固建议6.1 SSH 安全# 编辑 /etc/ssh/sshd_config PasswordAuthentication no # 关闭密码登录 PubkeyAuthentication yes # 启用密钥登录 Port xxxxx # 修改默认端口目前 authorized_keys 是空的，等于密码开着但钥匙没配——这是最危险的状态。6.2 防火墙在云服务商安全组中仅放行业务端口（80/443），SSH 端口仅允许你的 IP 访问。建议屏蔽攻击者 IP 段 212.132.98.0/24。6.3 安全扫描apt install chkrootkit -y chkrootkit定期扫描，及时发现异常。6.4 软件来源这次攻击很可能是因为安装了来路不明的软件或脚本（比如"挂机赚钱"类工具）。不要在任何生产服务器上安装非官方的、来路不明的软件。6.5 日志审计# 定期检查登录记录 last -10 # 检查失败的登录尝试 lastb -10七、经验和教训进程伪装越来越高级：exec -a '[kswapd0]' 这种把进程名伪装成内核线程的手法，如果不是用 lsof 查看网络连接，光靠 ps 根本发现不了curl 正常 ≠ 网站正常：从服务器本地 curl 看到的是原始响应，但用户浏览器可能已经被中间人注入多维度排查顺序很重要：先看 Nginx 配置 → 再看系统进程 → 检查网络连接 → 找自启动脚本 → 看登录日志，这种由表及里的排查思路值得记住生产服务器不要装来路不明的软件，这可能是最根本的一条记录于 2026 年 6 月 13 日PS:真羡慕韩国球迷啊！祝国足本期世界杯“夺冠”！！！
