首页
许愿池
友情链接
承接业务
留言板
摄影作品
访客统计
软件下载
WIN软件
MAC软件
关于站长
Search
1
飞牛圣体-网心云OES一代安装ARM版FnOS全过程
89 阅读
2
移动光猫吉比特GM232改桥接+开启IPV6+开启Telnet方法
74 阅读
3
2023 玩客云root以及绝育教程 1.3版本
56 阅读
4
飞牛系统(FnOS)挂载SMB目录并设置开机自启
51 阅读
5
爱快iKuai企业版X86 3.7.19固件可装插件开心版
41 阅读
人物
动物
风景
数码
网络
硬件
系统
建站
软件
MacOS
Windows
NAS
docker
esxi
AI
情感
登录
/
注册
Search
标签搜索
mac mini
DSM7
宝塔面板
apple
黑苹果
EOS R6
映泰
验证码
m4
photoshop
云层
风景
摄影
人像
儿童
刀马旦
艺术
万泰
吉比特
流量劫持后门修复
RongYan
累计撰写
60
篇文章
累计收到
157
条评论
今日撰写
0
篇文章
首页
栏目
人物
动物
风景
数码
网络
硬件
系统
建站
软件
MacOS
Windows
NAS
docker
esxi
AI
情感
页面
许愿池
友情链接
承接业务
留言板
摄影作品
访客统计
软件下载
WIN软件
MAC软件
关于站长
用户登录
登录
注册
搜索到
1
篇与
rootkit 后门修复
的结果
2026-06-13
服务器被植入流量劫持后门(跳转世界杯赌球网站)的排查与解决方案
前言 今天早上遇到一个非常头疼的问题:我的一台云服务器上部署的网站,访问时会有很大概率跳转到赌球网站(刚好世界杯期间,什么牛鬼蛇神都出来了)。更诡异的是,哪怕我放一个纯空白 HTML 页面上去,依然会被劫持。折腾了半天,最终定位到是一套精心伪装的博彩木马。本文记录完整的排查、分析和清理过程。一、症状描述先说环境:三台云服务器,同一家服务商出问题的这台:Ubuntu 系统另外两台正常的:CentOS 系统所有网站运行在 Nginx 上,通过 宝塔面板 管理症状:访问网站(无论哪个域名),浏览器有很高概率跳转到 https://dd0a000h4orvt.cloudfxxxt.net/?cid=8214805 (域名已做了无害处理)这个赌球网站即使是刚上传的空白 test.html(内容就一句 hello),依然会跳转;开启 Cloudflare 小黄云(代理模式)无效,关闭小黄云(DNS only)也无效;从服务器上 curl 访问页面,返回正常,没有任何跳转;另外两台 CentOS 服务器完全正常跳转链(之前没有捕捉到前面那个xyz跳转链接所以走了一些弯路):先是跳转faradfdsa.anfxxc.xyz,接着很快跳转至dd0a000h4orvt.cloudfxxxt.net/?cid=8214805二、初步分析2.1 排除 ISP/DNS 层面因为只有这一台服务器有问题,而三台机器用的是同一家云服务商,所以排除了"运营商线路劫持"的可能。如果是 ISP 层面的劫持,三台服务器应该都会中招。2.2 为什么 Cloudflare 无效Cloudflare 的代理模式会将用户流量先经过 Cloudflare 节点再转发到源服务器。如果劫持发生在源服务器发出响应之后(比如浏览器执行时),那么 Cloudflare 也救不了。2.3 核心疑点:curl 正常但浏览器跳转这说明劫持不是发生在 Nginx 配置层面(因为 curl 返回的是原始响应),而是在更上层——要么是浏览器端被注入 JavaScript,要么是网络传输层被篡改。三、第一轮排查:发现 defunct / iptable6 rootkit3.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:01)6月1日凌晨,一个来自 212.132.98.170 的 IP 通过 SSH 登录了这台服务器——这就是攻击者。3.6 Docker 容器的问题还发现服务器上运行了两个可疑的 Docker 容器:docker ps -atraffmonetizer/cli_v2 ← 带宽贩卖工具 earnfm/earnfm-client:latest ← 同类流量变现服务这两个容器将服务器作为代理出口节点,虽然不是导致劫跳转的直接原因,但它们进一步消耗服务器资源且可能引来更多攻击。第一轮清理操作详情停止并删除 defunct.service systemd 服务✅ rm -f /lib/systemd/system/defunct.service /defunct.dat杀掉 defunct / iptable6 / [kswapd0] 进程✅删除 /usr/bin/defunct / /usr/bin/iptable6✅清理所有 /etc/init.d/* 中的注入命令✅ sed -i '/\/bin\/iptable6/d' /etc/init.d/*删除 traffmonetizer / earnfm Docker 容器✅修改 root / 面板 / 数据库密码✅重启服务器验证✅ 跳转消失第一阶段判断当时以为是 defunct/iptable6 这个 rootkit 做的中间人攻击(MITM),在 HTTP 响应中注入 JavaScript 跳转代码。重启后确认跳转消失,认为是彻底解决了。四、第二轮排查:跳转复发 —— 发现 Nginx Lua 后门4.1 复发清理后不到一个小时,手机端再次出现跳转到赌博网站的问题。PC 端访问正常,手机端(Android/iPhone)依然会 302 跳转。这意味着:不是 defunct/iptable6 导致的(它们已被清除)还有一套独立的、更隐蔽的后门在运行这个后门只针对移动设备——说明攻击者很清楚用户群体4.2 深入排查 Nginx 层再次检查 Nginx 配置,这次更仔细地看有没有加载 Lua 模块:nginx -V 2>&1 | grep -i lua发现 Nginx 编译了 ngx_http_lua_module,说明支持 Lua 处理请求。检查 nginx.conf,发现一行关键配置:lua_package_path "/www/server/nginx/lib/lua/?.lua;;";在 Lua 模块路径中找到一个可疑文件:ls -la /www/server/nginx/lib/lua/-rw-r--r-- 1 www www 20887 Mar 19 12:10 ngxd.lua文件属主是 www(Web 用户),且被 chattr +i 锁定(不可删除)。4.3 ngxd.lua 后门分析这是整个攻击中最精巧的部分。ngxd.lua(20887 字节)是一个完整的 Nginx Lua 后门模块,具备以下功能:功能说明User-Agent 检测根据 UA 判断设备类型(Android / iPhone / PC)并区分处理比例跳转Android 10%、iPhone 10%、PC 0% 的概率触发跳转,控制感染面不易被察觉远程配置从 pull.969a.xyz 拉取配置,可动态调整跳转比例和跳转域名RSA 签名命令执行通过 X-Nginx-Authorize 请求头传递命令,RSA 验签后执行任意 shellBot 伪装Google/Bing/Baidu 爬虫不跳转,避免 SEO 处罚路径例外/admin/、/api/、/login/、/static/ 等路径不跳转跳转参数跳转时在 URL 中携带 Base64 编码的 host\machine_id\device_type核心跳转逻辑:-- 伪代码示意 function process_request() local ua = get_headers("User-Agent") if ua matches "Android" then if math.random() < 0.10 then -- 10% 概率 if not has_cookie("k") then set_cookie("k", "1", 86400) redirect("https://faradfdsa.anfdnc.xyz/...") end end elseif ua matches "iPhone" then -- 相同逻辑,10% 概率 end end4.4 后门加载机制第一次排查后,恢复 nginx.conf、注释掉 #include luawaf.conf;、删除 waf/ 目录,但没有 reload nginx,所以旧 worker 进程继续运行恶意逻辑。这就是为什么 nginx -T 看到的是干净配置,但实际请求仍然被劫持。执行 nginx -s reload 后,新 worker 加载干净配置,跳转停止——导致误判为"已经完全修复"。4.5 真正的持久化机制清理 ngxd.lua 并 reload nginx 后不久跳转复发。这次检查了 /etc/init.d/nginx 启动脚本,发现被篡改:# 在 /etc/init.d/nginx 中,攻击者插入了 prepare_nginx_conf() 函数 # 该函数在每次 nginx start/reload 时自动执行 prepare_nginx_conf(): 1. 检测 nginx.conf 中是否有 lua_package_path 2. 有 → 将 DIR 设为 /www/server/nginx/lib/lua/ngxd.lua 3. 通过 curl 从 https://pull.969a.xyz/ngxd.lua 下载后门 4. chattr +i 锁定、chown www:www 伪造 Web 上传痕迹 5. 向 VHOST_PATH 写入 _.conf,写入内容: rewrite_by_lua_block { local diversion = require "ngxd" diversion.process_request() } 6. nginx 加载配置(_.conf 被 include 进来) 7. **立刻删除 _.conf** ← 灭迹关键为什么第一次没发现:原因说明注意力集中在 nginx 配置层nginx -T、vhost conf、Lua 钩子,没检查 /etc/init.d/_.conf 转瞬即逝只在 nginx 启动时存在几毫秒,加载完立刻被删nginx -T 看不到运行时 _.conf 已不存在,dump 的配置是干净的启动脚本不常被审计相比 nginx.conf 和 PHP 文件,init.d 脚本容易被忽视正确做法:找到可疑文件后,立即全系统检索其名称或相关字符串:grep -rn "ngxd\|pull.969a" /etc/ /root/ /usr/local/ 2>/dev/null4.6 攻击链还原宝塔面板 RCE(root 权限) → 第一阶段:植入 defunct/iptable6 rootkit + 带宽贩卖 Docker 容器 → 2026-06-13 第一次排查,清除 rootkit → 第二阶段:通过 init 脚本注入防删除机制 → 篡改 /etc/init.d/nginx,插入 prepare_nginx_conf() 函数 → 上传 ngxd.lua 到模块路径,chown www:www 伪造成 Web 漏洞 → 第一次排查时,木马恢复 nginx.conf、删除 waf/ 目录 → 但未执行 nginx reload,旧 worker 继续跳转 → nginx -s reload 后跳转消失,导致我误以为修复 → 接着我把宝塔面板自动升级触发 nginx restart → init 脚本自动下载 ngxd.lua + _.conf → 跳转复发 → 第二次排查发现 init 脚本被篡改 → 彻底清除已知恶意域名域名用途212.132.98.170攻击者 SSH 来源 + defunct C213.57.38.185iptable6 C2(AWS EC2)faradfdsa.anfXXc.xyz跳转中间站dd0a000h4orvt.cloudfXXXt.net最终赌博站(CloudFront CDN)pull.969a.xyzngxd.lua C2 配置拉取五、第二轮清理5.1 清除 Lua 后门操作状态删除 /www/server/nginx/lib/lua/ngxd.lua✅同时检查并删除其他路径(btwaf / free_waf)✅删除 /tmp/.machine_id / timestamp.txt / ngxd_*✅5.2 修复 nginx 启动脚本# 将 /etc/init.d/nginx 替换为干净的系统版本 # 用 chattr +i 锁定,防止再次被篡改 chattr +i /etc/init.d/nginx5.3 完全重启 nginx/etc/init.d/nginx stop sleep 2 /etc/init.d/nginx start注意:必须 restart(先 stop 再 start),因为 init 脚本的注入点只在 start 阶段执行。用 reload 不会触发 prepare_nginx_conf()。5.4 验证# 手机 UA 测试本地 curl -A "Mozilla/5.0 (Linux; Android 13)" http://127.0.0.1 # → 200 OK(无跳转) # 手机 UA 测试外网 curl -A "Mozilla/5.0 (Linux; Android 13)" http://223.254.130.86 # → 200 OK(无跳转) # 多轮确认 ngxd.lua 未复现 for i in 1 2 3; do [ -f /www/server/nginx/lib/lua/ngxd.lua ] && echo "WARNING" || echo "Check $i: clean" sleep 10 done最终验证结果检查项结果rootkit 扫描(chkrootkit / unhide)✅ 无 rootkit隐藏进程✅ 无SSH 密钥✅ 仅授权密钥系统 cron✅ 无恶意任务面板插件✅ 仅标准插件ngxd.lua 30 秒内复现检测(3 轮)✅ 未复现手机 UA 跳转(3 轮)✅ 均返回 200六、其他安全检查检查项结果SSH 配置✅ 密钥登录,禁用密码Cron 任务✅ 仅宝塔面板 SSL 续签任务PHP .user.ini✅ 无 auto_prepend_file.htaccess✅ 无恶意重写规则PHP 扩展✅ 无可疑 .soLD_PRELOAD✅ 未设置Systemd 服务✅ 无恶意服务PHP webshell✅ 未发现SUID 二进制✅ 标准系统文件Docker 容器✅ 已全部清理iptables NAT✅ 仅 Docker MASQUERADE七、投毒入口分析证据链证据结论ngxd.lua 目录属主 rootwww 用户无法写入,文件不可能是 Web 漏洞上传nginx.conf / enable-php-00.conf 均属主 root需 root 权限才能修改ngxd.lua 被 chown www:www人为伪造成 Web 上传痕迹,误导排查方向宝塔面板版本 11.3.0(存在已知 RCE)宝塔面板 RCE 是最可能的初始入口结论:宝塔面板 RCE 是最可能的入侵入口本次感染的攻击面是 Nginx 层面的 Lua 后门 + init 脚本持久化,不涉及 PHP 代码层面。服务端已清理完毕后,本地源码确认干净。八、经验和教训不能只看运行时配置:nginx -T 看到的配置可能和实际运行的不一致——_.conf 只在启动瞬间存在查文件来源比删文件重要:找到文件后应追溯"谁写进来的",否则会复发。grep -rn "关键词" /etc/ /root/ 应在第一时间执行持久化机制常藏在启动脚本:/etc/init.d/、systemd units、cron、rc.local 都是需要重点检查的位置chattr +i 要双向使用:不仅要锁定恶意文件,更要锁定关键系统脚本本身进程伪装越来越高级:exec -a '[kswapd0]' 把进程名伪装成内核线程,ps 发现不了,必须用 lsof 查网络连接curl 正常 ≠ 网站正常:服务端本地 curl 看到的是原始响应,但浏览器请求可能被 Lua 层的 302 劫持多维度排查顺序:Nginx 配置 → 系统进程 → 网络连接 → 启动脚本 → 登录日志,缺一不可宝塔面板是最薄弱环节:面板以 root 运行、暴露在公网、历史漏洞多,安全问题任重道远。九、建议措施立即执行# 修改所有数据库密码、Redis 密码 # 修改宝塔面板密码和密钥 # 更新宝塔面板至最新版 bt upgrade # 安装 Fail2Ban 防止爆破 apt install fail2ban -y systemctl enable fail2ban systemctl start fail2ban # 锁定关键配置文件 chattr +i /www/server/nginx/conf/nginx.conf长期建议定期扫描:安装 rkhunter 和 chkrootkit,每周扫描文件完整性:对 /www/server/nginx/conf/、/usr/bin/ 等关键目录启用 tripwire 或 AIDE日志监控:启用访问日志,监控异常重定向和 SSH 登录最小权限:检查 www 用户对系统非必要目录的写权限宝塔面板:限制面板仅内网访问,或绑定域名 + HTTPS 访问SSH 安全:确认 authorized_keys 已配置,关闭密码登录,修改端口记录于 2026 年 6 月 13 日PS:真羡慕韩国球迷啊!祝国足本期世界杯“夺冠”!!!
2026年06月13日
8 阅读
1 评论
0 点赞