Linux应急响应实战：从入侵检测到根除的完整排查指南

1. 项目概述：从“玄机”靶场看Linux应急响应的实战起点

最近在安全圈子里，一个叫“玄机”的靶场平台挺火的，特别是它的第一章“应急响应-Linux入侵排查”。这名字起得挺有意思，“玄机”意味着里面藏着门道和线索，而“应急响应”则是我们安全从业者，尤其是蓝队和安服工程师的日常核心工作。说白了，这就是一个高度模拟真实入侵场景的实战环境，让你扮演“数字侦探”，去一台已经被攻陷的Linux服务器里，从蛛丝马迹中还原攻击路径，找到攻击者留下的“后门”和“罪证”。

我花了些时间把这一章通关了，整个过程下来，感觉它确实是一个非常好的入门和练手材料。它没有一上来就堆砌各种高深莫测的APT攻击手法，而是聚焦于Linux系统被入侵后，一个响应人员最应该、也最先去做的那一套标准排查流程。对于刚接触安全运维、想了解应急响应具体要干什么的新手，或者想系统化梳理自己知识体系的同行，这个靶场提供了一个绝佳的“沙盘”。接下来，我就结合这次实战，把Linux入侵排查的那些核心环节、常用命令以及容易踩的坑，掰开揉碎了和大家聊聊。你会发现，应急响应不是玄学，而是一套有章可循的逻辑推理过程。

2. 应急响应核心流程与思路拆解

2.1 应急响应的核心目标：遏制、根除、恢复

在动手敲命令之前，我们必须先明确目标。应急响应不是漫无目的地翻看日志，它遵循一个清晰的流程：准备、检测、遏制、根除、恢复、总结。在“玄机”这类单机排查场景中，我们主要聚焦于“检测”和“根除”阶段。

• 检测（Detection）：确认系统是否真的被入侵，入侵点在哪，攻击者做了什么。这是排查的起点，也是最考验基本功的地方。
• 根除（Eradication）：找到并清除攻击者植入的所有恶意程序、后门账户、异常进程等，消除安全隐患。

整个排查思路可以概括为：由外及内，由表及里，顺藤摸瓜。先从最明显、最易获取的线索入手（如异常进程、可疑网络连接），再深入到文件系统、日志、计划任务等持久化位置，最后将所有线索串联，还原攻击链。

2.2 Linux入侵排查的“三板斧”

根据经验，Linux系统被入侵后，攻击者通常会进行以下几类操作，我们的排查也主要围绕这些方面展开：

1. 权限维持：创建后门账户、提升现有账户权限、设置SUID/SGID特殊权限文件。
2. 持久化驻留：植入恶意启动项（rc.local, systemd服务，crontab计划任务）、修改动态链接库。
3. 信息收集与外联：窃取敏感文件、建立反向Shell、开放可疑端口进行监听。
4. 痕迹清理：删除或篡改系统日志（如/var/log/下的auth, secure, messages等），试图掩盖行踪。

“玄机”靶场的题目设计，基本上覆盖了以上所有常见手法。我们的任务就是使用系统自带的或常用的工具，像梳子一样把这些异常点找出来。

3. 核心排查环节与命令详解

3.1 用户与权限排查：谁在系统里“开了后门”

这是排查的第一步，因为攻击者往往需要一个新的立足点。

• 检查用户账户：

  # 查看/etc/passwd，关注UID为0（root）的用户和最后新增的用户 cat /etc/passwd | grep -E “(^root|:0:)” cat /etc/passwd | tail -n 10 # 查看/etc/shadow的权限，正常情况下应为root只读，防止被篡改 ls -l /etc/shadow

  注意：重点关注UID为0的非root用户（如将普通用户UID改为0），以及/etc/passwd中登录shell为/bin/bash或/bin/sh的非人类用户（如www-data, mysql等服务账户突然有了登录shell）。

• 检查sudo权限：

  # 查看/etc/sudoers文件以及/etc/sudoers.d/目录下的所有文件 cat /etc/sudoers ls -la /etc/sudoers.d/

  攻击者可能会给某个普通用户添加ALL=(ALL) NOPASSWD: ALL这样的规则，使其可以无密码执行任何sudo命令。

• 检查历史命令：

  # 查看root和当前用户的历史命令，攻击者可能忘记清理 history cat ~/.bash_history sudo cat /root/.bash_history

  这里可能会发现攻击者使用的下载命令（wget,curl）、提权命令（sudo su,find -perm）等。

3.2 进程与网络排查：系统里正在运行什么“鬼东西”

这是发现实时威胁的关键。

• 检查网络连接：

  # netstat传统但有效，注意-p显示进程名 netstat -antlp | grep -E “(LISTEN|ESTABLISHED)” # ss是netstat的现代替代，速度更快 ss -antlp # lsof查看特定端口被谁占用 lsof -i :<端口号>

  排查要点：

  1. 异常监听端口：检查所有LISTEN状态的端口，对比netstat -tulnp或ss -tulnp的结果，找出不在常规服务列表（如22, 80, 443, 3306）中的端口。攻击者可能开启了后门端口。
  2. 异常外联IP：检查ESTABLISHED状态的连接，看是否有连接到陌生或恶意IP地址（可通过威胁情报平台初步判断）。反向Shell通常会保持一个到攻击者控制端的稳定连接。

• 检查系统进程：

  # 以树状形式查看进程，清晰显示父子关系 pstree -p # 全面查看进程信息，包括CPU、内存占用、启动命令等 ps aux --sort=-%cpu | head -20 ps aux --sort=-%mem | head -20 # 查找隐藏进程（进程名被篡改或包含特殊字符） ps -ef | grep -E “(\./|\[|tmp|dev\/shm)”

  排查要点：

  1. 资源占用异常：CPU或内存占用率异常高的进程可能是挖矿木马。
  2. 进程路径可疑：进程执行路径在/tmp、/dev/shm、/var/tmp等临时目录，或者直接是./xxx（当前目录），这非常可疑。
  3. 进程名伪装：进程名看起来像系统进程（如kthreadd/0，多了一个斜杠），或者包含[等字符企图伪装成内核线程。

3.3 文件系统与启动项排查：攻击者如何“赖着不走”

攻击者为了持久化，会在文件系统各处留下“种子”。

• 检查计划任务：

  # 系统级计划任务 ls -la /etc/cron* cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ etc. # 用户级计划任务 crontab -l # 查看当前用户的 sudo crontab -l -u root # 查看root用户的 ls -la /var/spool/cron/crontabs/ # 所有用户的crontab文件存放处

  注意：这是攻击者最常用的持久化手段之一。仔细检查每一行任务，看是否有从远程下载脚本（curl | bash）、执行可疑路径脚本的命令。

• 检查系统启动项：

  # 老式SysVinit系统 ls -la /etc/rc.local ls -la /etc/init.d/ # 现代systemd系统 systemctl list-unit-files --type=service | grep enabled systemctl list-units --type=service --state=running # 检查新增或可疑的service文件 find /etc/systemd/system/ /lib/systemd/system/ -name “*.service” -type f -mtime -7

  攻击者可能会创建一个自定义的systemd服务，实现开机自启。

• 检查SUID/SGID特殊权限文件：

  # 查找系统中所有SUID权限的文件 find / -perm -4000 -type f 2>/dev/null # 查找系统中所有SGID权限的文件 find / -perm -2000 -type f 2>/dev/null # 查找任何人都可写的文件（极度危险） find / -perm -o+w -type f 2>/dev/null

  SUID文件执行时，会以文件所有者的身份运行。如果/bin/bash被设置了SUID，那么任何用户执行它都能获得root shell。这是经典的提权后门。

• 检查最近修改的文件：

  # 查找7天内被修改过的文件，从根目录开始，排除/proc等虚拟文件系统 find / -type f -mtime -7 2>/dev/null | grep -v “/proc/” | head -50 # 查找今天被修改过的文件 find / -type f -mtime 0 2>/dev/null | grep -v “/proc/”

  这有助于发现攻击者上传的工具包、生成的输出文件等。

3.4 日志分析：追踪攻击者的“足迹”

日志是还原攻击时间线的关键，但高手往往会清理日志。

• 关键日志文件：

  • /var/log/auth.log或/var/log/secure：认证相关日志，记录SSH登录成功/失败、sudo使用等。重点查看！
  • /var/log/syslog或/var/log/messages：系统通用日志。
  • /var/log/apt/history.log：记录软件包安装历史，看是否被安装了恶意软件。
  • /var/log/wtmp、/var/run/utmp、/var/log/btmp：分别记录当前登录用户、历史登录和失败登录尝试。使用last、who、lastb命令查看。
  • Web日志：如/var/log/apache2/access.log、/var/log/nginx/access.log，用于分析Web攻击。

• 常用分析命令：

  # 查看最近的成功登录记录 last # 查看最近的失败登录尝试（暴力破解） lastb # 实时监控认证日志 tail -f /var/log/auth.log | grep -E “(Failed|Accepted|Invalid user)” # 在syslog中搜索特定关键词，如‘reverse shell’， ‘python’， ‘perl’等 grep -i “python\|perl\|bash -i\|/dev/tcp” /var/log/syslog

  实操心得：如果发现日志文件被清空（文件大小为零）或者关键时间段的日志缺失，这本身就是一个强烈的入侵信号。此时需要转向文件系统排查和内存分析。

4. “玄机”靶场实战通关与线索串联

现在，让我们把上面的命令和思路，应用到“玄机”第一章的具体场景中。假设我们通过SSH登录了靶机，第一件事不是乱翻，而是按照流程来。

4.1 初步感知与信息收集

登录后，我习惯先快速看一眼系统状态，建立基线。

# 查看系统基本信息，内核版本、主机名等 uname -a hostname # 快速看一眼进程和网络，有没有特别扎眼的东西 ps aux --sort=-%cpu | head -5 ss -tulnp | grep LISTEN

在“玄机”里，你可能一开始发现不了特别明显的异常，因为题目设计得比较隐蔽。这时就需要开始系统性排查。

4.2 顺藤摸瓜：从一条线索到完整攻击链

通常，我会从网络或进程找到一个突破口。比如，用ss -antlp发现了一个陌生的端口（例如31337）在监听，并且关联到一个奇怪的进程名。

# 假设发现端口31337 ss -ltnp | grep 31337 # 输出可能显示进程PID和名字 LISTEN 0 128 :::31337 :::* users:((“suspicious_pro”，pid 1234))

拿到PID 1234后，我们可以深挖这个进程：

# 查看进程的详细信息，包括完整命令行 cat /proc/1234/cmdline | xargs -0 echo # 查看进程打开的文件 ls -la /proc/1234/fd # 查看进程的可执行文件路径 ls -l /proc/1234/exe

假设发现这个进程的可执行文件在/tmp/.hidden_backdoor。接下来就围绕这个文件展开：

# 检查文件属性 ls -l /tmp/.hidden_backdoor # 检查文件内容（如果是文本脚本） head -c 100 /tmp/.hidden_backdoor # 查找还有哪些地方引用了这个文件 grep -r “/tmp/.hidden_backdoor” /etc/ 2>/dev/null

很可能，在/etc/crontab或者某个用户的crontab里，你会发现一行定时任务，每分钟执行一次这个后门文件，这就是持久化机制。同时，检查/etc/passwd，可能会发现攻击者添加了一个UID为0的后门用户。检查auth.log，可能会发现大量来自某个IP的SSH暴力破解记录，最终成功的登录时间点，与后门文件创建时间接近。

这就是线索串联：攻击者通过暴力破解（日志）获得初始权限 -> 上传后门文件（/tmp/.hidden_backdoor） -> 添加定时任务（crontab）实现持久化 -> 创建后门用户（/etc/passwd）备用 -> 开启监听端口（31337）等待连接。一个完整的攻击链就清晰了。

4.3 根除与加固建议

找到所有问题后，就是清理工作：

1. 终止恶意进程：kill -9 1234
2. 删除恶意文件：rm -f /tmp/.hidden_backdoor
3. 清理计划任务：编辑/etc/crontab或crontab -e删除对应行。
4. 删除后门用户：userdel -r backdoor_user(谨慎操作，-r会删除家目录)。
5. 修复权限：如果发现/etc/shadow权限不对，用chmod 600 /etc/shadow修复。
6. 更改密码：为所有可能被泄露的账户（尤其是root）更改强密码。
7. 更新与打补丁：apt update && apt upgrade(根据系统)。

5. 高级排查工具与技巧延伸

除了基础命令，掌握一些高级工具能让排查事半功倍。

5.1 文件完整性校验

如果系统有提前做基线，比如用AIDE或Tripwire记录了关键文件的哈希值，那么入侵后可以通过对比快速发现被篡改的系统文件。

# 使用AIDE进行检查（假设已初始化数据库） aide --check

如果没有基线，可以手动对关键命令（如/bin/ls,/bin/netstat,/bin/ps）进行哈希校验，与干净系统对比，以防攻击者替换了这些命令来隐藏自己。

# 计算文件的SHA256哈希 sha256sum /bin/ls

5.2 内存分析

对于高级威胁，恶意进程可能只存在于内存中（无文件落地）。这时就需要内存分析工具。

• LiME：一个Linux内存提取工具，可以将内存转储到本地或通过网络发送。
• Volatility：经典的内存取证框架，可以对内存镜像进行分析，提取进程列表、网络连接、加载的内核模块等。虽然Volatility 3对Linux的支持在完善中，但这仍是高级应急响应必须了解的技能。

5.3 Rootkit检测

Rootkit会深度隐藏进程、文件和网络连接。可以使用专门的检测工具：

• chkrootkit：一个经典的Rootkit检测脚本。
• rkhunter：另一个常用的Rootkit扫描工具。

# 安装并运行rkhunter sudo apt install rkhunter sudo rkhunter --check --skip-keypress

需要注意的是，这些工具本身也可能被Rootkit篡改，最可靠的方式是使用一个干净、可信的Live CD/USB启动系统，挂载受害磁盘进行离线检查。

6. 常见问题排查与避坑指南

在实际应急响应中，经常会遇到一些棘手的情况，这里分享几个常见的坑和解决思路。

6.1 命令输出被篡改或命令本身被替换

这是攻击者隐藏行踪的常见手法。比如，你执行ps aux看不到恶意进程，执行netstat看不到恶意端口。

• 排查方法：
  1. 使用静态编译的二进制工具包（如BusyBox）放到U盘里，挂载到受害系统上执行。这些工具独立于系统环境。
  2. 使用绝对路径调用命令，如/bin/ps，而不是直接ps（因为$PATH环境变量可能被修改）。
  3. 检查常用命令的哈希值是否与官方一致。
  4. 尝试使用其他替代命令，比如用ss代替netstat，用/proc文件系统查看进程（ls /proc/[0-9]*/exe）。

6.2 日志被清空或轮转过快

看不到日志怎么办？

• 排查方法：
  1. 检查日志配置文件（如/etc/rsyslog.conf,/etc/logrotate.conf），看是否有异常配置导致日志被立即覆盖。
  2. 查看是否还有日志备份文件，如auth.log.1,auth.log.2.gz等。
  3. 重点转向文件系统时间线分析和网络流量分析（如果之前有抓包）。使用find命令结合-atime,-ctime,-mtime参数，围绕入侵发生的大致时间点，查找被访问、创建或修改的文件。
  4. 检查其他可能记录信息的来源，如Shell历史（.bash_history）、Web服务器日志、数据库日志等。

6.3 如何区分“正常异常”和“恶意异常”

系统里有很多进程和文件，怎么判断哪个是恶意的？

• 经验准则：
  1. 位置异常：系统关键进程（如sshd,nginx）的可执行文件通常位于/usr/sbin/,/usr/bin/等标准目录。出现在/tmp,/dev/shm,/var/tmp等临时目录或用户家目录下的可疑度极高。
  2. 行为异常：一个/bin/bash进程的父进程是Web服务（如apache2），这很可能是一个Web Shell触发的。一个进程持续高CPU占用但无明确服务功能，可能是挖矿木马。
  3. 名称伪装：进程名模仿系统进程但略有不同（如kthreadddvskthreadd），文件名以.开头（隐藏文件），或带有systemd,init等迷惑性名称。
  4. 网络通信异常：连接到非常用端口（如4444, 5555, 31337等传统后门端口），或连接到已知的恶意IP、矿池地址。
• 辅助手段：将可疑文件的哈希值（MD5, SHA256）提交到VirusTotal等在线扫描平台，或者内部威胁情报平台进行比对。

6.4 应急响应过程中的操作禁忌

1. 不要立即重启系统：重启会丢失内存中的关键证据（如进程列表、网络连接状态、未落地的恶意代码）。应在完成内存转储和易失性数据收集后再考虑。
2. 不要在受害系统上安装未知工具：从互联网下载新的工具到受害系统，可能会覆盖证据，甚至引入新的风险。优先使用系统自带工具或事先准备好的可信静态工具。
3. 避免直接修改或删除：在完全确认攻击链和影响范围之前，避免直接删除恶意文件或终止进程，这可能会影响后续分析或导致攻击者察觉。可以先重命名、移动或使用chattr +i锁定文件。
4. 详细记录每一步操作：从登录系统开始，所有执行的命令、看到的结果、时间戳，都要详细记录。这既是后续撰写报告的需要，也是保证操作可追溯、避免自己操作出错的关键。

通关“玄机”第一章，更像是一次标准化的流程演练。它把Linux应急响应中那些零散的知识点，串成了一条清晰的线索。真正面对真实入侵时，情况会更复杂，噪音会更多，攻击者的手段也会更隐蔽。但万变不离其宗，扎实掌握这套基础排查流程，养成由外及内、顺藤摸瓜的分析习惯，同时保持对系统正常状态的“敏感度”，就能在混乱中快速找到头绪。最后记住，应急响应不仅是技术活，更是体力活和细心活，每一个看似不起眼的细节，都可能是破案的关键。平时多练练手，像“玄机”这样的靶场就是最好的模拟考场。