凌晨两点，告警短信把站长叫醒：服务器 CPU 100%、数据库被删、首页被改成勒索信；或者更隐蔽的——一切看起来正常，但流量账单多出几千块。服务器被入侵后，90% 的人第一反应是”赶紧把网站恢复上线”，这恰恰是应急响应最大的误区：不查清入侵路径就恢复，等于给黑客留了一扇门，第二天照样被攻破。本文按真实处置流程，把漏洞应急响应拆成四步：隔离止损、定位入口、清除修复、加固复盘，每一步都给出可直接执行的命令。
一、第一步：隔离与止损，先别急着动服务器
发现被入侵，先做三件事：断外网、保全证据、改密码。很多人一上来就 kill 进程、删文件，反而把攻击痕迹和线索全毁了。
# 1. 临时切断对外服务（云服务器优先在控制台安全组操作）
# 在云控制台"安全组"里，临时拒绝入方向流量，或用下面命令停掉 Web 服务
systemctl stop nginx
systemctl stop mysql
# 2. 保全关键证据（排查前先备份，避免误删线索）
cp /var/log/auth.log /root/evidence_auth.log.bak
cp /var/log/secure /root/evidence_secure.bak
history > /root/evidence_history.txt
ps auxf > /root/evidence_ps.txt
ss -antp > /root/evidence_conn.txt
# 3. 修改所有账号密码：root、MySQL、Redis、FTP、面板账号
passwd root
mysqladmin -u root -p password '新密码'如果是云主机，强烈建议先打快照再动手：一份快照成本很低，却是事后取证和还原的救命稻草。取证完成后，把对外端口在安全组里全部收口（只留 22 或干脆全关），缩小攻击面，再进入排查阶段。
怎么判断自己是不是真的被入侵了？常见迹象有这么几条：登录记录里出现陌生 IP 的成功登录；服务器 CPU、带宽长期异常，跑着跑着就满负荷；网站被挂黑链、页面跳转或被篡改；数据库里多出陌生管理员账号；/tmp 目录出现不明文件；进程列表里有 xmrig 等挖矿程序或异常外联连接。看到其中任何一条，都按本文流程完整走一遍，别抱着”可能只是误报”的侥幸心理——宁可白忙一场，也别错过真实入侵。
二、第二步：定位入侵入口与残留后门
入侵必有入口，后门必有痕迹。按下面顺序排查，能覆盖 90% 的常见入侵方式：
# 1. 谁登录过系统？什么时候登录的？
last -20
lastb -20 # 失败的登录记录
grep "Accepted" /var/log/auth.log | tail -20 # Ubuntu 系
grep "Accepted" /var/log/secure | tail -20 # CentOS 系
# 2. 有没有可疑进程和计划任务？
ps auxf | grep -v "^\[" | awk '$3>30 || $4>30'
crontab -l
ls -la /etc/cron.d/ /etc/cron.daily/ /var/spool/cron/
# 3. SSH 是否被植入后门公钥？（重点看修改时间在入侵时间点之后）
cat /root/.ssh/authorized_keys
find /root /home -name authorized_keys 2>/dev/null
# 4. 启动项与开机脚本是否被篡改？
ls -lt /etc/init.d/ | head -20
ls -l /etc/rc.local 2>/dev/null
systemctl list-unit-files --state=enabled | head -30重点排查对象：定时任务是黑客最爱的驻留方式，挖矿脚本、反弹 Shell 都爱挂在这里；SSH 公钥后门让黑客即使你改了密码也能随时进来。这两处一旦发现陌生条目，先完整记录路径和内容，再删除。
三、第三步：修复漏洞与加固，堵住入侵路径
找到入口后，必须把漏洞本身修掉，否则清完后门也是白搭。按常见场景对号入座：
# 场景一：Redis 未授权访问被利用
# 修复：只监听内网并设置密码（修改 redis.conf 后重启）
bind 127.0.0.1
requirepass 强密码
# 验证：redis-cli -a 密码 ping
# 场景二：SSH 弱口令被爆破
# 修复：禁用密码登录，改用密钥
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart sshd
# 场景三：Web 程序漏洞（WordPress、ThinkPHP 等）
# 修复：升级到最新版，删除可疑插件/主题
wp core update
wp plugin update --all
# 场景四：全盘杀毒清理残留
yum install -y clamav && freshclam
clamscan -r / --remove -l /root/clamav_scan.log修完漏洞统一做一遍”改密 + 换钥”：所有业务密码（数据库、FTP、面板）全部重置，SSH 全站更换新密钥对并删除旧公钥。同时安装 fail2ban 兜底暴力破解，防止同类攻击卷土重来：
yum install -y fail2ban
cat > /etc/fail2ban/jail.local <<'EOF'
[sshd]
enabled = true
port = 22
maxretry = 5
bantime = 86400
findtime = 600
EOF
systemctl enable --now fail2ban漏洞修复之外，把这几条加固项一起做掉：Nginx 关闭版本号显示（server_tokens off），避免被扫描工具识别版本后精准打点；MySQL 删除多余账号、回收 FILE 权限，防止提权后写文件；系统内核与应用保持定期升级，像近期曝光的一批内核提权漏洞，出来当天就要评估自己是否受影响。加固不是一次性动作，建议把"登录审计、进程审计、补丁更新"三项列入每周例行检查，形成习惯。
排查时记住两个原则：第一，优先看"新增"而不是"全部"，按时间排序把最近 24-72 小时变化的文件、进程、定时任务列出来，重点对象一目了然；第二，所有命令输出先落盘保存（重定向到 /root/evidence 目录），不要边查边丢——这些记录既是分析依据，也是日后向公安机关报案或向云厂商提交工单时的凭证。
四、第四步：恢复上线与复盘
确认后门清干净、漏洞已修复、日志无异常后，再从备份恢复数据、改回安全组配置上线。上线后 72 小时内，每天检查一遍进程、计划任务和登录记录。最后做一次复盘：这次是怎么进来的？弱口令、未授权服务还是 Web 漏洞？把对应项加入日常巡检清单，下次就不用再"交学费"。
如果团队没有专职安全人员，排查和修复都比较吃力，建议把防护前置：速度网络的云 WAF 与高防服务能在漏洞被利用前拦截攻击流量，其安全团队也提供入侵排查协助，把"出了事再应急"变成"事前就防住"。记住：应急响应做得再好，也不如漏洞管理做在前。
