一次 Nginx Lua 木马应急响应实录：从移动端跳转博彩站到 root 级入侵溯源

3.1 首次入侵（约一个月前）#

HIDS 记录到一条真实的 root SSH 会话，该会话执行了以下操作：

关键判断：这不是端口扫描或爆破尝试，而是「已认证」的入侵行为——攻击者拥有合法的 root 凭据。

3.2 第二次落地（事发当天凌晨）#

系统出现第二段落地行为：

• 服务启动脚本 /etc/init.d/nginx 被植入恶意回灌逻辑
• 出现可疑的 .so 动态库文件
• 出现隐藏标记文件，内容为木马版本标识
• 内核日志出现 Nginx worker 进程的段错误

关键判断：这不是临时文件误报，而是服务重启级的持久化链路——即使当前恶意文件被删除，重启 Nginx 后木马会自动复活。

3.3 应急响应窗口#

从用户反馈到完整处置，应急响应推进路径如下：

1. 复现移动端 UA 与桌面端访问表现差异
2. 对比应用层日志和 Nginx 访问日志
3. 确认异常 302 重定向出现在 Nginx 层而非 PHP 应用层
4. 通过 nginx -T 导出全量配置，顺 Lua 加载路径定位恶意模块
5. 先备份证据，再替换为 no-op 空壳
6. 深挖持久化点，确认 init.d 脚本回灌逻辑
7. 清理认证面、隔离残留样本、打包证据并记录哈希
8. 复测移动端、桌面端、支付接口和关键服务状态

4.1 区分问题层级#

用户报障后，首先要判断异常发生在哪一层：

本次通过移动端 UA 请求复现了 302，并发现跳转参数中包含原始域名和设备类型，说明跳转逻辑在 HTTP 请求入口层——也就是 Nginx 层被劫持。

4.2 访问日志分析#

访问日志中出现了关键特征：

1
正常路径如 /、/item/1、/products → 间歇性 302，与正常 200 混杂

这个特征非常关键：

• 正常业务跳转通常有稳定规则（如未登录跳登录页）
• 恶意流量劫持常按设备类型、流量比例、来源 Referer 或时间随机触发
• 本次恶意 Lua 中确实存在移动端比例控制逻辑——只在部分移动端请求中触发跳转

4.3 定位 Nginx Lua 加载链#

审计 nginx -T 全量配置后，重点排查以下位置：

• lua_package_path — Lua 模块搜索路径
• rewrite_by_lua / access_by_lua — 请求阶段 Lua 钩子
• include luawaf.conf — WAF 配置文件
• Nginx Lua 库目录
• WAF 脚本目录
• 反向代理配置文件

最终确认活跃恶意模块是一个伪装成正常模块名的 .lua 文件，内容包含：

• 外部博彩风格跳转域名
• 移动端 UA 识别和比例触发逻辑
• 远程配置拉取功能
• ngx.redirect() 跳转实现

与线上表现完全一致。

4.4 先取证再处置#

本次没有直接删除任何可疑文件。 原因：

1. 直接删除会破坏法证链，无法回溯入侵过程
2. 直接删除 Lua 文件可能导致仍存在的调用点把 Nginx 打挂
3. 攻击者使用了 chattr +i、时间戳伪造和重启回灌，单点删除不能解决持久化

处置策略：

• 将恶意原件保留到证据备份目录
• 生产路径中的恶意 Lua 替换为同名 no-op 空壳模块
• 保留导出函数签名，避免隐藏调用点异常
• 执行 nginx -t 验证配置后再 reload

4.5 追踪持久化机制#

仅替换当前活跃恶意模块后，不能认为修复完成。后续检查发现 init.d 服务脚本已被改造：

• 从外部 URL 拉取远程载荷
• 向 Nginx 配置文件写入 Lua 钩子
• 操作 lua_package_path 确保模块加载
• 操作 ld.so.preload 预加载共享库
• 配合 chattr +i 保护植入文件

这就是木马的复活机制——只要 Nginx 服务重启，远程载荷会重新落地，配置会被重新注入。清理当前文件而不处理服务脚本，等于什么都没修。

4.6 用 HIDS 建立根因证据链#

系统日志和 shell history 被清空后，常规取证手段失效。本次的关键证据来自 HIDS（主机入侵检测系统）的日志：

• HIDS 中保留了 root SSH 会话记录及命令样本
• 能证明约一个月前已发生真实入侵
• 这个证据比猜测 IP 来源、猜测插件漏洞有价值得多

教训：HIDS 日志是日志清洗后唯一可信的证据源，必须保证不被同机单点覆盖，最好外送或异地备份。

4.7 扩展扫描残留#

切断已知攻击链后，继续检查：

最终确认并隔离了三个残留工件：隐藏标记文件、恶意动态库、异常数据文件。

4.8 认证面收敛（避免自锁）#

发现 root 已泄露后，凭据轮换必须做，但不能为了「看起来更安全」直接关闭当前唯一的远程入口。

本次策略：

1. 清空 root 的 authorized_keys
2. 隔离未确认但仍需使用的 SSH 密钥
3. 确认没有其他 uid=0 账户或异常用户的认证文件
4. 暂时保留 root 密码登录，等待新管理员入口就绪后再关闭

这是安全和可运维之间的必要取舍——没有替代入口时直接关闭 root 登录，只会把正常运维锁在外面。

4.9 四层验证#

只看服务状态 active 不等于业务可用；只看页面返回 200 也不等于木马已清理。必须四层同时验证。

已执行操作#

• 将恶意 Lua 模块替换为 no-op 安全空壳
• 将恶意 WAF 脚本替换为安全空壳
• 移除 init.d 服务脚本中的恶意回灌逻辑
• 移除 Nginx 全局配置中的异常 lua_package_path
• 去除攻击者遗留在相关文件上的 immutable 属性
• 隔离隐藏标记文件、恶意动态库、异常数据文件
• 清理 root 本机 SSH 私钥驻留
• 归档完整事件证据并生成 SHA256 校验值
• 恢复 Docker bridge 网关，修复支付反代超时问题

后续动作#

24 小时内：

• 持续观察 Nginx 访问日志中的异常状态码
• 持续观察内核日志中的 worker 崩溃
• 观察支付链路的稳定性
• 保存 CDN 安全事件和访问日志

1-3 天内：

• 新建非 root 管理员用户并配置公钥
• 验证新入口可用后，关闭 root 密码直接登录
• 轮换面板密码、API key、部署密钥和数据库密码
• 将关键日志外送或定时同步到异地

中期：

• 评估系统重装和业务迁移窗口
• 用干净系统重新部署服务栈
• 只迁移业务数据，不迁移旧系统脚本和二进制
• 建立上线后基线：端口清单、文件哈希、日志保留策略

1. 偶发跳转必须优先怀疑请求入口层#

移动端跳转博彩站、桌面端偶发正常——这是典型的按 UA 或比例触发的流量劫持特征。不能只从前端缓存或应用路由找原因，必须第一时间查 Nginx 层的异常。

2. CDN 520 可能是源站进程崩溃#

CDN 的 520 错误表示源站连接异常。本次 520 与恶意 .so 文件导致的 Nginx worker 进程崩溃直接相关。排查 CDN 错误时必须同时看源站内核日志和 worker 状态。

3. 单点删除木马不等于修复#

攻击者使用了：

• 服务脚本持久化（重启复活）
• chattr +i 文件不可变属性（防删除）
• 时间戳伪造（掩盖时间线）
• 日志清洗（销毁证据）

只替换一个恶意文件会留下重启复活的风险，必须深挖持久化链。

4. 证据保存必须早于清理#

先打包证据、记录哈希、保留备份，再清理生产路径。否则后续无法解释完整的入侵链，也无法判断是否存在第二阶段攻击。

5. 安全加固不能盲目锁死#

关闭 root 密码登录是正确方向，但前提是有可验证的新管理员入口。没有替代入口就直接关闭，等于把自己也锁在门外。

6. HIDS 是日志清洗后唯一的可信证据源#

系统日志被清空后，HIDS 日志成为了唯一能证明入侵时间点和攻击行为的关键证据。后续必须保证 HIDS 日志异地存储，不能被同机攻击者一并清理。

7. 运行态问题要和入侵事件分层处理#

本次排查中发现的支付反代超时问题，经分析是 Docker 网络配置问题，与 Lua 木马无关。应急响应中必须严格区分：

• 安全事件（入侵、木马、持久化）
• 运行态故障（网络、配置漂移、资源耗尽）
• 业务 Bug（代码逻辑、支付流程）

混为一谈会误导排查方向，浪费时间。