服务器被入侵后怎么做：应急响应流程与实战操作清单
服务器出现异常进程、陌生登录记录或对外发起大量连接时，第一反应不应该是直接重启或重装。
正确做法是按应急响应流程与实战步骤，先隔离、再取证、后清除，避免证据丢失或攻击者二次进入。
本文按零基础运维也能照做的顺序，给出每步的命令和验证方式。
先判断是否真的被入侵
不要凭感觉操作，先收集几个客观信号。
登录服务器后依次执行：
who # 当前登录用户和来源 IP
last -n 20 # 最近登录记录
ps aux --sort=-%cpu | head -20 # CPU 占用最高的进程
ss -tunlp # 监听端口和对应进程重点看三类异常：非本人来源 IP 的登录、不认识的监听端口、CPU 或网络占用异常高的陌生进程。
如果 last 里出现大量来自同一陌生 IP 的失败或成功记录，基本可以确认需要进入应急流程。
注意：确认异常后不要立刻 kill 进程或删除文件，先完成下一步隔离，否则排查线索会断。
隔离：切断攻击者通路但保留现场
隔离的目标是让攻击者无法继续操作，同时保留可分析的数据。
推荐做法不是关机，而是限制网络访问：
# 只允许你的管理 IP 访问 SSH，其余全部拒绝
iptables -A INPUT -p tcp --dport 22 -s 你的管理IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP如果服务器在云平台，更稳妥的方式是在控制台安全组里先把 22 端口来源改成你的固定 IP。
同时做一份快速取证快照，方便后续分析：
mkdir -p /root/ir_$(date +%F)
cp /var/log/secure /root/ir_$(date +%F)/ 2>/dev/null
cp /var/log/auth.log /root/ir_$(date +%F)/ 2>/dev/null
ps aux > /root/ir_$(date +%F)/ps.txt
ss -tunlp > /root/ir_$(date +%F)/netstat.txt
crontab -l > /root/ir_$(date +%F)/cron_root.txt/var/log/secure 是 CentOS 系登录日志，/var/log/auth.log 是 Debian/Ubuntu 系登录日志，按你的系统取其一即可。
避坑：不要在这一步执行 reboot 或 shutdown。
内存中的恶意进程、临时文件、网络连接会随关机消失，很多挖矿和反弹 Shell 的证据就此丢失。
定位入口和持久化位置
攻击者通常会留下后门，常见位置有以下几个，逐个检查：
- 计划任务：
crontab -l、cat /etc/crontab、ls /etc/cron.d/ - 启动项：
systemctl list-unit-files --state=enabled，重点看陌生服务 - SSH 授权文件：
cat /root/.ssh/authorized_keys，检查是否有陌生公钥 - 用户账号：
awk -F: '$3==0{print $1}' /etc/passwd，查看是否有 UID 为 0 的额外账号 - 异常文件：
find /tmp /var/tmp /dev/shm -type f -mtime -7 2>/dev/null
如果发现陌生进程，用 ls -l /proc/PID/exe 找到它实际对应的可执行文件路径，再决定是否清除。
ls -l /proc/1234/exe # 1234 换成实际可疑 PID这样能识别出被删除但仍运行的恶意文件，避免直接 kill 后无法定位来源。
清除与加固：按顺序收尾
确认入口后按以下顺序处理，顺序反了容易反复被入侵：
- 修改所有账号密码，尤其是 root 和可登录用户
- 删除陌生账号和
authorized_keys中的陌生公钥 - 删除恶意计划任务和启动项
- 结束恶意进程并删除对应文件（先确认路径再删）
- 更新系统和软件：
yum update -y或apt update && apt upgrade -y - 关闭密码登录，改用密钥：编辑
/etc/ssh/sshd_config，设置PasswordAuthentication no，然后systemctl restart sshd
修改 SSH 配置前，务必确认密钥登录已经可用，否则重启后可能把自己锁在外面。
建议先开一个已登录的 SSH 会话不动，改完用新会话测试。
验证与复盘
处理完成后不要直接恢复业务，先做验证：
last -n 10 # 确认没有新的陌生登录
ss -tunlp # 确认没有多余监听端口
crontab -l # 确认计划任务干净
ps aux | grep -v grep | grep -E 'tmp|shm' # 确认临时目录无异常进程观察一到两天，确认没有反弹。
同时回顾入口：是弱密码、未修复漏洞还是暴露了不必要端口。
只清除不补入口，很可能再次中招。
常见疑问
服务器被入侵必须重装吗？ 不一定。
如果入口明确、后门已清理、日志能佐证，可以加固后继续使用。
但如果无法确认攻击者留下的全部后门，重装并重新部署是更省心的选择。
没有备份怎么办？ 先隔离并复制关键数据到外部存储，再决定是否重装。
不要在受感染的机器上直接打包业务数据传给生产环境。
云服务器安全组和 iptables 哪个先改？ 优先改云平台安全组，它在网络层拦截，比主机防火墙更早生效，也能防止本机规则被攻击者篡改后失效。
应急响应流程与实战的核心不是工具多，而是顺序对：先隔离、再取证、后清除、最后验证。
把这套流程走一遍，比事后反复重装更有效。
遇到不确定的文件或进程，宁可不删，先留证据再判断。
