Nginx 隐藏 Lua 后门：手机访问自动跳转恶意域名的排查与修复实录
近期世界杯期间，遇到一种非常隐蔽的网站劫持现象：电脑端访问网站完全正常，但手机端访问时会自动 301 重定向到诸如 `anaox.xyz` 之类的恶意域名。经过排查发现，这并非传统的运营商链路劫持，而是 Nginx 被植入了深层的 Lua 后门。
本文完整复盘了本次定位、深挖与修复的过程，供运维同行参考避坑。
## 一、故障现象与初步判定
本次入侵精准规避了常规排查手段，具有极强的迷惑性：
* **PC 端访问**：网站正常打开，返回 200 状态码，无任何异常。
* **移动端访问**：立即触发 301 重定向，随机跳转至 `hpgzr.anaox.xyz/dh` 等恶意域名池。
初期排查彻底排除了运营商链路劫持（本机回环可复现）、浏览器代理与缓存问题以及前端 JS 恶意跳转。最终确认：劫持逻辑根植于服务器本地 Nginx，由服务端主动返回恶意 301 响应头。
## 二、受影响服务器范围
本次入侵波及三台业务服务器，入侵层级深浅不一：
* **业务前端机A**：`21X.xxx.xxx.19:8100`
* **内网转发机B**：`1X.0.0.2:8XX8`
* **后端接口机C**：`10X.xxx.1xx.xx:8xx8`（入侵最严重，底层被篡改）
## 三、深度根因分析：双层恶意入侵架构
后门并非单一脚本，而是分层持久化驻留，分为两种入侵等级：
### 1. 普通入侵（如业务前端机A）
* **核心恶意文件**：`/www/server/nginx/lib/lua/ngxd.lua`
* **恶意逻辑**：内置设备识别函数，通过 `http_user_agent` 区分设备；配置 `android_ratio`、`iphone_ratio` 跳转概率精准控制移动端劫持比例；匹配手机 UA 后通过 `ngx.redirect` 强制跳转。
* **隐蔽特性**：后门文件被执行 `chattr +i` 锁定，普通删除失效；仅 reload Nginx 无法修复，Lua 脚本常驻内存。
### 2. 深度入侵（如后端接口机C）
该机器已被完全控制，属于多层持久化入侵：
* 系统启动脚本 `/etc/init.d/nginx` 被篡改，开机自动远程拉取后门脚本 `https://pull.969a.xyz/ngxd.lua`。
* 自动生成恶意配置文件 `_.conf`，注入 `rewrite_by_lua_block` 强制加载劫持逻辑。
* Nginx 二进制程序被篡改，MD5 哈希与官方纯净版本不一致，存在底层后门污染。
## 四、完整排查流程（通用方案）
针对此类隐性 Lua 后门，整理了一套标准化排查步骤：
**1. 本地回环复现（锁定问题根源）**
通过 curl 模拟不同设备 UA 访问本机，彻底排除外网链路干扰：
```bash
# 模拟 PC 访问
curl -I "http://127.0.0.1:9000/index.html"
# 模拟苹果手机访问
curl -I -A "Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1" "http://127.0.0.1:9000/index.html"
```
**2. 确认端口监听状态**
```bash
ss -ltnp | grep ':9000'
ss -ltnp | grep ':8088'
```
确认端口由原生 Nginx 监听，无伪装进程劫持端口。
**3. 排查明文配置**
```bash
nginx -T 2>&1 | grep -E "return 301|rewrite"
```
若配置无跳转规则，但 Nginx 编译参数开启了 `lua_nginx_module`，则大概率是 Lua 脚本入侵。
**4. 精准检索后门特征**
通过后门专属关键字全局检索，定位恶意脚本：
```bash
find /www/server/nginx -type f -name "*.lua" -exec grep -HniE 'android_ratio|iphone_ratio|ngx.redirect|official_site|anaox' {} \; 2>/dev/null
```
**5. 检查文件锁定属性**
```bash
lsattr /www/server/nginx/lib/lua/ngxd.lua
```
若结果出现 `----i-----------`，确认文件被强制锁定。
## 五、分层修复方案（精准根治）
针对不同入侵等级的机器，采用对应修复方案。**核心重点：仅 reload 无效，必须完全重启进程。**
### 方案一：修复普通入侵机器
1. **解除文件锁定**
```bash
chattr -i /www/server/nginx/lib/lua/ngxd.lua
```
2. **备份恶意文件（留存取证）**
```bash
cp -a /www/server/nginx/lib/lua/ngxd.lua /root/ngxd.lua.bak.$(date +%F-%H%M%S)
```
3. **彻底废掉劫持逻辑**
编辑 `ngxd.lua`，清空恶意配置：将跳转域名置空，劫持概率归零，并将所有 `ngx.redirect` 替换为 `return false`。
4. **清理恶意缓存文件**
```bash
rm -f /tmp/tcxnig.txt /tmp/tronse.txt /tmp/timestamp.txt
```
5. **完全重启 Nginx（关键步骤）**
```bash
nginx -t
nginx -s quit
sleep 2
/www/server/nginx/sbin/nginx -c /www/server/nginx/conf/nginx.conf
```
### 方案二：修复深度入侵机器
在方案一基础上，额外清理底层持久化后门：
1. **还原启动脚本**：替换被篡改的 `/etc/init.d/nginx`，删除远程拉取后门及恶意生成配置的代码。
2. **修复污染的二进制**：对比纯净版本 MD5，备份异常文件，从健康同版本服务器拷贝纯净程序覆盖。
3. **批量清理残留后门文件**：
```bash
rm -f /www/server/panel/vhost/nginx/_.conf
rm -f /www/server/panel/vhost/nginx/tcp/_.conf
rm -f /www/server/nginx/lib/lua/ngxd.lua
rm -f /www/server/btwaf/lib/ngxd.lua
rm -f /www/server/free_waf/ngxd.lua
rm -f /tmp/tcxnig.txt /tmp/tronse.txt /tmp/timestamp.txt
```
4. **恢复正常 Lua 依赖配置**：
```bash
lua_package_path "/www/server/nginx/lib/lua/?.lua;;";
```
5. **重启验证**：完全重启 Nginx 后双向测试设备访问，确保劫持彻底解决。
## 六、安全加固与预防建议
单纯修复问题远远不够，必须全面排查加固，清除残留后门：
1. **扫描全网锁定可疑文件**：
```bash
find /www/server/nginx -type f -exec lsattr {} \; 2>/dev/null | grep -- '----i'
grep -RniE 'pull\.969a\.xyz|ngxd|anaox|rewrite_by_lua_block' /etc /www /usr/local /opt /home 2>/dev/null
```
2. **排查定时任务木马**：检查 `crontab -l` 及 `/var/spool/cron/`。
3. **检查 SSH 持久化后门**：查看 `/root/.ssh/authorized_keys` 及 `/var/log/secure` 登录日志。
4. **全量密码重置**：强制修改 root 服务器密码、宝塔面板密码、数据库密码及业务后台密码。
5. **终极建议**：若二进制篡改且多层持久化，最稳妥方案为**整机重装系统**，仅迁移确认干净的业务配置。若无 Lua WAF 业务需求，建议直接移除 Nginx Lua 模块。
## 七、运维经验总结
本次后门具备极强的隐蔽性，属于黑灰产主流劫持手段。后续排查同类问题，优先遵循：本地复现 → 排除链路劫持 → 检查 Lua 模块 → 排查系统启动项 → 清查锁定文件。
**防范补充提醒：**
* 高度怀疑此次入侵与宝塔面板漏洞有关，务必及时升级至最新版本；非必要时段建议直接关闭面板端口，使用时再放行。
* 关注并处理云服务器提供方下发的安全警告方案。
* 站点尽量配置域名并启用 HTTPS（443 端口）进行加密传输，提升安全性。
本文完整复盘了本次定位、深挖与修复的过程，供运维同行参考避坑。
## 一、故障现象与初步判定
本次入侵精准规避了常规排查手段，具有极强的迷惑性：
* **PC 端访问**：网站正常打开，返回 200 状态码，无任何异常。
* **移动端访问**：立即触发 301 重定向，随机跳转至 `hpgzr.anaox.xyz/dh` 等恶意域名池。
初期排查彻底排除了运营商链路劫持（本机回环可复现）、浏览器代理与缓存问题以及前端 JS 恶意跳转。最终确认：劫持逻辑根植于服务器本地 Nginx，由服务端主动返回恶意 301 响应头。
## 二、受影响服务器范围
本次入侵波及三台业务服务器，入侵层级深浅不一：
* **业务前端机A**：`21X.xxx.xxx.19:8100`
* **内网转发机B**：`1X.0.0.2:8XX8`
* **后端接口机C**：`10X.xxx.1xx.xx:8xx8`（入侵最严重，底层被篡改）
## 三、深度根因分析：双层恶意入侵架构
后门并非单一脚本，而是分层持久化驻留，分为两种入侵等级：
### 1. 普通入侵（如业务前端机A）
* **核心恶意文件**：`/www/server/nginx/lib/lua/ngxd.lua`
* **恶意逻辑**：内置设备识别函数，通过 `http_user_agent` 区分设备；配置 `android_ratio`、`iphone_ratio` 跳转概率精准控制移动端劫持比例；匹配手机 UA 后通过 `ngx.redirect` 强制跳转。
* **隐蔽特性**：后门文件被执行 `chattr +i` 锁定，普通删除失效；仅 reload Nginx 无法修复，Lua 脚本常驻内存。
### 2. 深度入侵（如后端接口机C）
该机器已被完全控制，属于多层持久化入侵：
* 系统启动脚本 `/etc/init.d/nginx` 被篡改，开机自动远程拉取后门脚本 `https://pull.969a.xyz/ngxd.lua`。
* 自动生成恶意配置文件 `_.conf`，注入 `rewrite_by_lua_block` 强制加载劫持逻辑。
* Nginx 二进制程序被篡改，MD5 哈希与官方纯净版本不一致，存在底层后门污染。
## 四、完整排查流程（通用方案）
针对此类隐性 Lua 后门，整理了一套标准化排查步骤：
**1. 本地回环复现（锁定问题根源）**
通过 curl 模拟不同设备 UA 访问本机，彻底排除外网链路干扰：
```bash
# 模拟 PC 访问
curl -I "http://127.0.0.1:9000/index.html"
# 模拟苹果手机访问
curl -I -A "Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1" "http://127.0.0.1:9000/index.html"
```
**2. 确认端口监听状态**
```bash
ss -ltnp | grep ':9000'
ss -ltnp | grep ':8088'
```
确认端口由原生 Nginx 监听，无伪装进程劫持端口。
**3. 排查明文配置**
```bash
nginx -T 2>&1 | grep -E "return 301|rewrite"
```
若配置无跳转规则，但 Nginx 编译参数开启了 `lua_nginx_module`，则大概率是 Lua 脚本入侵。
**4. 精准检索后门特征**
通过后门专属关键字全局检索，定位恶意脚本：
```bash
find /www/server/nginx -type f -name "*.lua" -exec grep -HniE 'android_ratio|iphone_ratio|ngx.redirect|official_site|anaox' {} \; 2>/dev/null
```
**5. 检查文件锁定属性**
```bash
lsattr /www/server/nginx/lib/lua/ngxd.lua
```
若结果出现 `----i-----------`，确认文件被强制锁定。
## 五、分层修复方案（精准根治）
针对不同入侵等级的机器，采用对应修复方案。**核心重点：仅 reload 无效，必须完全重启进程。**
### 方案一：修复普通入侵机器
1. **解除文件锁定**
```bash
chattr -i /www/server/nginx/lib/lua/ngxd.lua
```
2. **备份恶意文件（留存取证）**
```bash
cp -a /www/server/nginx/lib/lua/ngxd.lua /root/ngxd.lua.bak.$(date +%F-%H%M%S)
```
3. **彻底废掉劫持逻辑**
编辑 `ngxd.lua`，清空恶意配置：将跳转域名置空，劫持概率归零，并将所有 `ngx.redirect` 替换为 `return false`。
4. **清理恶意缓存文件**
```bash
rm -f /tmp/tcxnig.txt /tmp/tronse.txt /tmp/timestamp.txt
```
5. **完全重启 Nginx（关键步骤）**
```bash
nginx -t
nginx -s quit
sleep 2
/www/server/nginx/sbin/nginx -c /www/server/nginx/conf/nginx.conf
```
### 方案二：修复深度入侵机器
在方案一基础上，额外清理底层持久化后门：
1. **还原启动脚本**：替换被篡改的 `/etc/init.d/nginx`，删除远程拉取后门及恶意生成配置的代码。
2. **修复污染的二进制**：对比纯净版本 MD5，备份异常文件，从健康同版本服务器拷贝纯净程序覆盖。
3. **批量清理残留后门文件**：
```bash
rm -f /www/server/panel/vhost/nginx/_.conf
rm -f /www/server/panel/vhost/nginx/tcp/_.conf
rm -f /www/server/nginx/lib/lua/ngxd.lua
rm -f /www/server/btwaf/lib/ngxd.lua
rm -f /www/server/free_waf/ngxd.lua
rm -f /tmp/tcxnig.txt /tmp/tronse.txt /tmp/timestamp.txt
```
4. **恢复正常 Lua 依赖配置**：
```bash
lua_package_path "/www/server/nginx/lib/lua/?.lua;;";
```
5. **重启验证**：完全重启 Nginx 后双向测试设备访问，确保劫持彻底解决。
## 六、安全加固与预防建议
单纯修复问题远远不够，必须全面排查加固，清除残留后门：
1. **扫描全网锁定可疑文件**：
```bash
find /www/server/nginx -type f -exec lsattr {} \; 2>/dev/null | grep -- '----i'
grep -RniE 'pull\.969a\.xyz|ngxd|anaox|rewrite_by_lua_block' /etc /www /usr/local /opt /home 2>/dev/null
```
2. **排查定时任务木马**：检查 `crontab -l` 及 `/var/spool/cron/`。
3. **检查 SSH 持久化后门**：查看 `/root/.ssh/authorized_keys` 及 `/var/log/secure` 登录日志。
4. **全量密码重置**：强制修改 root 服务器密码、宝塔面板密码、数据库密码及业务后台密码。
5. **终极建议**：若二进制篡改且多层持久化，最稳妥方案为**整机重装系统**，仅迁移确认干净的业务配置。若无 Lua WAF 业务需求，建议直接移除 Nginx Lua 模块。
## 七、运维经验总结
本次后门具备极强的隐蔽性，属于黑灰产主流劫持手段。后续排查同类问题，优先遵循：本地复现 → 排除链路劫持 → 检查 Lua 模块 → 排查系统启动项 → 清查锁定文件。
**防范补充提醒：**
* 高度怀疑此次入侵与宝塔面板漏洞有关，务必及时升级至最新版本；非必要时段建议直接关闭面板端口，使用时再放行。
* 关注并处理云服务器提供方下发的安全警告方案。
* 站点尽量配置域名并启用 HTTPS（443 端口）进行加密传输，提升安全性。
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞