首页
许愿池
友情链接
承接业务
留言板
摄影作品
访客统计
软件下载
WIN软件
MAC软件
关于站长
Search
1
飞牛圣体-网心云OES一代安装ARM版FnOS全过程
87 阅读
2
移动光猫吉比特GM232改桥接+开启IPV6+开启Telnet方法
64 阅读
3
2023 玩客云root以及绝育教程 1.3版本
54 阅读
4
飞牛系统(FnOS)挂载SMB目录并设置开机自启
45 阅读
5
爱快iKuai企业版X86 3.7.19固件可装插件开心版
38 阅读
人物
动物
风景
数码
网络
硬件
系统
建站
软件
MacOS
Windows
NAS
docker
esxi
AI
情感
登录
/
注册
Search
标签搜索
mac mini
DSM7
宝塔面板
apple
黑苹果
EOS R6
映泰
验证码
m4
photoshop
云层
风景
摄影
人像
儿童
刀马旦
艺术
万泰
吉比特
流量劫持后门修复
RongYan
累计撰写
60
篇文章
累计收到
157
条评论
今日撰写
1
篇文章
首页
栏目
人物
动物
风景
数码
网络
硬件
系统
建站
软件
MacOS
Windows
NAS
docker
esxi
AI
情感
页面
许愿池
友情链接
承接业务
留言板
摄影作品
访客统计
软件下载
WIN软件
MAC软件
关于站长
用户登录
登录
注册
搜索到
1
篇与
流量劫持后门修复
的结果
2026-06-13
服务器被植入流量劫持后门(跳转世界杯赌球网站)的排查与解决方案
前言这两天遇到一个非常头疼的问题:我的一台云服务器上部署的网站,访问时会有很大概率跳转到赌球网站(刚好世界杯期间,什么牛鬼蛇神都出来了)。更诡异的是,哪怕我放一个纯空白 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:真羡慕韩国球迷啊!祝国足本期世界杯“夺冠”!!!
2026年06月13日
1 阅读
0 评论
0 点赞