从应急响应靶机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 -202. 恶意进程与隐藏后门深度分析在/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_null3. 定时任务与持久化机制排查攻击者常用的持久化手段之一就是恶意定时任务。在WhereIS中我们通过检查系统定时任务发现了反弹shellcat /etc/crontab ls -la /etc/cron.*更全面的定时任务检查清单检查位置命令示例说明系统crontabcat /etc/crontab系统级定时任务用户crontabcrontab -l当前用户的定时任务cron目录ls -la /etc/cron.*按小时/日/周等配置的任务anacroncat /etc/anacrontab针对非24小时运行系统的任务高级技巧检查最近修改的定时任务文件find /etc/cron* -type f -printf %T %p\n | sort -r4. Docker环境安全审计与容器逃逸防御WhereIS靶机中暴露的Docker安全问题非常典型。我们先检查Docker服务状态# 查看所有容器包括停止的 docker ps -a # 检查容器资源使用情况 docker stats --no-stream在发现的容器中thinkphp容器风险最高。进入容器检查docker exec -it thinkphp_container_id sh容器逃逸是WhereIS中的关键攻击路径。攻击者利用的错误配置包括危险的docker.sock权限ls -la /var/run/docker.sock典型错误配置srw-rw---- 1 root dockerdocker组用户可写特权容器# 在容器内检查是否特权模式 cat /proc/self/status | grep CapEff敏感目录挂载# 检查容器挂载点 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. 综合排查流程与自动化工具应用完整的应急响应应该遵循系统化流程。以下是我在实际工作中总结的检查清单用户与认证检查/etc/passwd和/etc/shadow异常可疑SSH密钥~/.ssh/authorized_keys最近登录记录last、lastb网络与防火墙检查iptables -L -n -v firewall-cmd --list-all自动化工具辅助Lynis系统安全审计lynis audit systemchkrootkit/rkhunterrootkit检测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案例中通过综合分析多个线索历史命令、隐藏文件、容器配置我们最终还原出攻击路径通过thinkphp漏洞入侵容器利用docker.sock不当配置实现容器逃逸植入system_null后门实现持久化访问设置定时任务维持权限这种关联分析能力才是应急响应的核心价值。记住没有单一证据能说明全部问题安全工程师需要像侦探一样拼接各种线索碎片。