从应急响应靶机WhereIS入手，手把手教你排查Linux后门与容器逃逸（附完整命令）

从应急响应靶机WhereIS入手：Linux后门排查与容器逃逸防御实战指南

当你面对一台疑似被入侵的Linux服务器时，那种"侦探破案"般的紧张与兴奋感是其他工作难以比拟的。WhereIS靶机正是这样一个精心设计的实战环境，它模拟了攻击者留下的各种蛛丝马迹——从异常进程到隐藏文件，从恶意定时任务到危险的Docker配置。本文将带你亲历完整的应急响应流程，掌握那些真正在企业环境中用得上的排查技巧。

1. 初始环境分析与攻击痕迹定位

拿到一台可疑服务器，第一步永远是建立基准线。在WhereIS靶机中，我们以普通用户zgsf（密码同为zgsf）登录后，首先要做的是收集系统基础信息：

# 查看系统基本信息 uname -a cat /etc/*-release # 检查当前用户权限 id groups

历史命令分析是发现攻击者行为的金矿。切换到root账户查看命令历史：

sudo su - history

在WhereIS案例中，历史记录暴露出几个关键线索：

• 可疑脚本upgrade.sh（内容被故意破坏）
• 对system.log文件的操作
• 后台执行的nohup ./system_null命令

提示：真实环境中，攻击者往往会清空历史记录。此时需要检查/var/log/auth.log、/var/log/secure等日志文件。

使用find命令定位关键文件：

# 查找system.log文件（忽略权限错误） find / -name 'system.log' 2>/dev/null # 查找最近修改过的文件（按时间排序） find / -type f -printf '%T+ %p\n' | sort -r | head -20

2. 恶意进程与隐藏后门深度分析

在/home/.system_config/目录中，我们发现了可疑的system_null程序及其日志。这种将后门隐藏在"点文件"（以.开头的隐藏文件）中的手法非常常见。使用下列命令全面检查隐藏目录：

ls -la /home/* ls -la /etc/.*

进程分析是识别后门的关键步骤：

# 查看所有进程（带完整命令） ps auxf # 检查网络连接 netstat -tulnp ss -tulnp # 检查异常监听端口 lsof -i :8899

在WhereIS案例中，system_null是一个Go语言编写的定制后门，具有以下特征：

• 监听非标准端口（8899）
• 使用nohup实现持久化
• 日志文件伪装成系统日志
• 沙箱难以检测（体积8MB含混淆代码）

取证技巧：遇到可疑二进制文件时，先进行基础分析：

# 检查文件类型 file system_null # 查看字符串信息 strings system_null | less # 计算哈希值（后续可进行威胁情报比对） md5sum system_null sha1sum system_null

3. 定时任务与持久化机制排查

攻击者常用的持久化手段之一就是恶意定时任务。在WhereIS中，我们通过检查系统定时任务发现了反弹shell：

cat /etc/crontab ls -la /etc/cron.*

更全面的定时任务检查清单：

高级技巧：检查最近修改的定时任务文件：

find /etc/cron* -type f -printf '%T+ %p\n' | sort -r

4. Docker环境安全审计与容器逃逸防御

WhereIS靶机中暴露的Docker安全问题非常典型。我们先检查Docker服务状态：

# 查看所有容器（包括停止的） docker ps -a # 检查容器资源使用情况 docker stats --no-stream

在发现的容器中，thinkphp容器风险最高。进入容器检查：

docker exec -it thinkphp_container_id sh

容器逃逸是WhereIS中的关键攻击路径。攻击者利用的错误配置包括：

1. 危险的docker.sock权限：

ls -la /var/run/docker.sock

典型错误配置：srw-rw---- 1 root docker（docker组用户可写）

2. 特权容器：

# 在容器内检查是否特权模式 cat /proc/self/status | grep CapEff

3. 敏感目录挂载：

# 检查容器挂载点 docker inspect --format='{{.Mounts}}' container_id

防御建议：

• 遵循最小权限原则，不要将用户加入docker组
• 定期审计容器配置：

# 检查特权模式容器 docker ps --quiet --all | xargs docker inspect --format '{{.Id}}: Privileged={{.HostConfig.Privileged}}' # 检查危险挂载 docker inspect --format='{{.Name}} {{.HostConfig.Binds}}' $(docker ps -aq)

5. 综合排查流程与自动化工具应用

完整的应急响应应该遵循系统化流程。以下是我在实际工作中总结的检查清单：

1. 用户与认证检查：

   • /etc/passwd和/etc/shadow异常
   • 可疑SSH密钥（~/.ssh/authorized_keys）
   • 最近登录记录（last、lastb）

2. 网络与防火墙检查：

   iptables -L -n -v firewall-cmd --list-all

3. 自动化工具辅助：

   • Lynis：系统安全审计

   lynis audit system

   • chkrootkit/rkhunter：rootkit检测

   chkrootkit rkhunter --check

日志分析黄金命令：

# 查看最近失败的登录尝试 grep "Failed password" /var/log/auth.log # 检查sudo提权记录 grep sudo /var/log/auth.log # 分析SSH登录IP awk '/Accepted/{print $11}' /var/log/auth.log | sort | uniq -c | sort -nr

在WhereIS案例中，通过综合分析多个线索（历史命令、隐藏文件、容器配置），我们最终还原出攻击路径：

1. 通过thinkphp漏洞入侵容器
2. 利用docker.sock不当配置实现容器逃逸
3. 植入system_null后门实现持久化访问
4. 设置定时任务维持权限

这种关联分析能力才是应急响应的核心价值。记住，没有单一证据能说明全部问题，安全工程师需要像侦探一样拼接各种线索碎片。