19 10 月 2026
发现服务器可能被入侵的那一刻,人的本能是慌+乱试。这篇给你一套标准的应急响应流程:遏制 → 取证 → 清除 → 恢复 → 复盘。每一步该做什么、不该做什么,都写清楚。日常防护见服务器安全基线清单。

一、第一条铁律:先遏制,别急着"查清楚"

被入侵时最大的错误是一边让攻击者继续在里面,一边慢慢排查。正确顺序:

  1. 遏制(分钟级):切断攻击者的持续访问
  2. 取证(保留现场,别急着删)
  3. 清除(清后门、堵漏洞)
  4. 恢复(从干净状态重建)
  5. 复盘(怎么进来的,怎么防下一次)

特别注意:如果攻击者还在线(有活跃会话、进程在跑),你改密码、清文件都是在打草惊蛇——先断网隔离,再动手。

二、怎么发现被入侵:异常信号清单

大多数入侵不是"发现"的,是"撞见"的。这些信号出现一个就要警惕:

类别信号
性能CPU/带宽无缘无故持续飙高(挖矿、被当跳板)
进程ps aux 有不认识的名字,或系统进程路径不对(/tmp/xxx)
登录/var/log/secure 有陌生 IP 的成功登录记录
文件网站目录多出可疑 webshell、首页被篡改
网络ss -tnp 有连往陌生 IP 的出站连接
计划任务crontab -l 和 /etc/cron.* 有没写过的任务
账号/etc/passwd 多出陌生用户,或已知用户被改过

主动发现靠监控:资源异常告警 + 登录失败告警 + 文件完整性监控。监控部署见Prometheus 监控入门,日志集中见Loki 日志体系。

三、遏制:把损失控制在现在

1. 网络隔离(第一优先)

# 方案 A:云控制台直接加安全组,只放行你的 IP(最彻底)
# 方案 B:本机防火墙全拒,只留你的管理 IP
ufw default deny incoming
ufw allow from 你的IP to any port 22

# 方案 C:极端情况——云控制台直接关机,保住磁盘现场

注意顺序:先收紧访问,再排查。别让排查的半小时里攻击者又拖走一批数据。

2. 冻结凭据

  • 改掉所有可能泄露的密码: root、数据库、面板、API Key
  • 禁用可疑账号(先禁用别删,留着取证):usermod -L 可疑用户
  • 撤销可疑 SSH 公钥(~/.ssh/authorized_keys 逐行核对,不认识的删)

3. 保全证据(要报警/复盘就做)

# 关键日志先拷贝出来(内网/本地,别放被入侵机器上)
tar -czf /tmp/incident-$(date +%F).tar.gz \
  /var/log/secure /var/log/syslog /var/log/nginx/ \
  /var/spool/cron/ ~/.bash_history 2>/dev/null

# 内存和进程快照(有进阶需求时)
ps auxf > /tmp/ps-snapshot.txt
ss -tnp > /tmp/ss-snapshot.txt

四、排查:攻击者从哪进来的

按"入口 → 痕迹 → 目的"三步:

1. 找入口

# 暴力破解成功记录(失败几十次后成功的那条)
grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
grep "Accepted" /var/log/secure | grep -v "你的IP"

# Web 漏洞入口:Nginx 日志里找可疑请求
grep -E "union|select|/\.env|phpinfo|eval\(|base64_decode" /var/log/nginx/access.log | head

常见入口:SSH 弱密码/密钥泄露(见SSH 加固)、Web 漏洞(Web 漏洞防护)、Redis/MongoDB 未授权访问(Redis 未授权访问)、泄露的 API Key。

2. 找痕迹

# 后门进程与自启
systemctl list-unit-files --state=enabled
ls -lt /etc/systemd/system/           # 最近改动的服务文件
cat /etc/rc.local
# 网站目录里的 webshell(近期修改的 PHP)
find /var/www -name "*.php" -mtime -7 | xargs grep -l "eval\|assert\|system(" 2>/dev/null
# 计划任务后门
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u $u 2>/dev/null; done
cat /etc/cron.d/* /var/spool/cron/*

详细的入侵痕迹排查见Linux 入侵检测工具实战。

3. 判断目的

  • 挖矿:CPU 飙高 + 陌生矿池连接 → 清进程 + 堵入口
  • 变跳板:出站连接到陌生 IP + 新账号 → 删账号 + 收紧出口
  • 偷数据:大量出站流量 + 数据库访问记录 → 评估泄露范围,走通报流程
  • 挂马/挂黑页:网站文件被改 → 清理 + 修漏洞(网站木马清理)

五、清除与恢复:干净重建胜过擦澡

核心决策:擦屁股还是重装?

情况建议
入口明确、痕迹少、你熟悉系统针对性清除(删后门、堵洞、改密码)
入侵深、时间长、说不清改了多少重装系统,从干净备份恢复数据

重装不可耻——你不确定干净,就是不确定。攻击者留的后门可能比你找到的多一个。重装流程见重装系统保留数据。

恢复时的纪律:

  1. 数据从"入侵发生前"的备份恢复,恢复后先扫描再上线
  2. 先堵入口再恢复——洞不补,恢复完再进一次
  3. 恢复后观察 48 小时(登录记录、进程、出站连接),确认干净再正常运维

数据泄露的应对:如果涉及用户数据泄露,按《个人信息保护法》履行通知义务(通知用户 + 报告监管部门),别心存侥幸。预案框架见数据泄露响应指南。

六、复盘:让这次入侵成为最后一次

事件平息后 48 小时内,写一份复盘,回答四个问题:

  1. 入口是什么?(弱密码?未修漏洞?泄露的 Key?)
  2. 为什么没早点发现?(监控缺哪块?日志没看?)
  3. 响应卡在哪?(备份旧?流程不熟?缺工具?)
  4. 下次怎么防?(具体到可执行的改进项)

改进项对照表:

根因修复动作
SSH 弱密码被爆改密钥登录 + 禁密码 + fail2ban(SSH 加固、fail2ban)
Web 漏洞更新程序、上 WAF(WAF 实战)
数据库未授权绑本地 + 强密码(数据库加固)
发现太晚补监控告警(Prometheus)
备份太旧提高备份频率 + 异地
恢复太慢写恢复文档 + 季度演练

七、平时就该有的应急包

别等出事才找东西,提前备好:

  • [ ] 云控制台入口书签(SSH 挂了唯一通道)
  • [ ] 最近的干净备份(异地,且验证过能恢复)
  • [ ] 改密码清单:哪几处密码必须一起改
  • [ ] 排查命令小抄:本文第三、四节的命令存一份
  • [ ] 联系渠道:商家技术支持、必要的报警/上报路径
  • [ ] 恢复文档:重装后怎么把服务跑起来,写给三个月后的自己

结语

安全应急响应的十六字诀:先断后查、留证再清、不确定就重装、事后必复盘。被入侵不是世界末日——有备份、有流程、有预案,它是运营中的一次插曲;没备份、没流程,它才是终章。把本文的流程走一遍,把应急包备好,然后希望永远用不上。

跑关键业务的服务器,稳定和安全压倒一切——可以看看财富云计算:NAT 型云服务器 SSD 系统盘 + 快照、支持热升级,价格比独立 IP 机型省一半以上——省下的成本,正好投入备份、监控和安全加固。

延伸阅读
  1. Homepage 个人仪表盘:把散落各处的服务收进一个首页
  2. SSL 证书完全指南:免费证书、自动续期与不过期监控
  3. 数据备份体系完全手册:从随手拷到 3-2-1,让数据永远丢不了
  4. 压测与容量规划:上线前就知道你的服务器能扛多少人
  5. AdGuard Home 内网 DNS:全家去广告、防劫持、内网解析一站解决
  6. Hugo 静态博客搭建:秒开的博客,部署只要一个目录
  7. 游戏服运营完全手册:从开服到停服,把一台服务器运营成百年老店
  8. Loki 日志体系搭建:轻量级日志聚合,Grafana 里查遍所有服务器
更多阅读
  1. 上一篇:游戏服运营完全手册:从开服到停服,把一台服务器运营成百年老店
  2. 下一篇:Hugo 静态博客搭建:秒开的博客,部署只要一个目录
发表评论 2

取消回复