结论： 服务器被攻击后的标准处置是六步法——断网隔离保全证据、定位攻击类型、封 IP 或切高防止血、加固漏洞、恢复业务、复盘改进。其中最关键的原则是：前 10 分钟先把日志与现场快照保存下来，不要急着关机或重装系统，否则会永久丢失溯源证据，也无法证明数据是否被窃取。
引言：为什么你需要一套"通用流程"，而不是一堆散装命令
服务器被攻击时的典型场景是：网站打不开、SSH 卡顿、CPU 飙到 100%、收到云厂商的流量告警短信，而你还不知道对手是谁、用了什么手段。这时候如果脑子里只有零散的命令，很容易做出两个致命动作——直接关机或直接重装系统。前者会清空内存中的网络连接、进程与未落盘的日志；后者会抹掉攻击者留下的全部痕迹。
本文讲的是通用应急响应流程与原则：不管对方用的是 DDoS、CC、暴力破解、WebShell、挖矿木马还是勒索软件，处置的骨架都是同一套六步法，改变的只是每一步里的具体动作。如果你已经判断出攻击类型、需要"针对某一种攻击的分场景处置手册"，请看本站《服务器被攻击了怎么办（分场景处置）》一文；两篇配合使用——本文决定"做什么、什么顺序"，那篇决定"这类攻击具体怎么打"。
命令以 Ubuntu 24.04 LTS 与 Rocky Linux 9 为例，截至 2026 年二者均默认使用 systemd 与 journald。
一、六步法总览：每一步的产出与禁忌
应急响应（Incident Response）的六个步骤有严格顺序，跳过任何一步都会付出代价。下表是全流程速查，建议打印贴在值班台。
| 步骤 | 目标 | 时间窗 | 关键动作 | 产出 | 禁忌 |
|---|---|---|---|---|---|
| 1. 隔离与取证 | 控制影响面、保住证据 | 0~10 分钟 | 断开公网或限制访问、打包 /var/log、保存进程与连接快照 | 证据包、影响面清单 | 关机、重装、格式化 |
| 2. 定位类型 | 搞清楚对手干了什么 | 10~30 分钟 | 查连接、进程、登录日志、Web 日志、计划任务 | 攻击类型与入侵路径结论 | 没定位就先"清理" |
| 3. 止血 | 让攻击不再继续 | 30~60 分钟 | 封 IP、切高防/CDN、限流、下架受害服务 | 攻击停止、业务可访问 | 只封 IP 不修漏洞 |
| 4. 加固 | 堵住入口 | 1~4 小时 | 改密换密钥、打补丁、收敛端口、删后门账号 | 加固清单 | 加固完不做验证 |
| 5. 恢复 | 把业务拉回正轨 | 视数据量 | 从干净备份恢复、灰度上线、验证数据完整性 | 恢复报告 | 直接用"被入侵过的机器"继续跑 |
| 6. 复盘 | 防止再发生 | 24~72 小时内 | 时间线还原、根因分析、改进项 | 复盘报告 | 没有负责人和截止日期的改进项 |
三条贯穿全程的原则：
- 先取证，后清理。 证据一旦销毁不可再生。
- 先止血，后根因。 业务在流血时，先按住伤口，再研究病因。
- 重大事件留机器，不要急着恢复。 涉及数据泄露、勒索、需要报案或走保险的场景，整台机器的磁盘镜像都是证据。
二、第 1 步：断网隔离与取证，先做哪一步？
结论：先把证据打包落盘（1 分钟内可完成），再决定要不要断网。 断网的目的是止损，取证的目的是溯源，两者不冲突——取证只需要几十秒，不要为了"赶紧断网"而跳过。
2.1 三十秒取证：把现场固定下来
# 0. 建一个证据目录，所有输出都放这里，最后打包带走
mkdir -p /root/ir-$(date +%F-%H%M) && cd /root/ir-$(date +%F-%H%M)
# 1. 网络连接与监听端口（最关键：能直接看出外连 C2、异常监听）
ss -antp > ss-antp.txt 2>&1
ss -lntp > ss-lntp.txt 2>&1
netstat -anp > netstat.txt 2>&1
# 2. 进程树与资源占用（挖矿木马 CPU 会异常）
ps auxf > ps-auxf.txt
ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -40 > ps-top.txt
top -b -n 1 > top.txt
# 3. 登录与认证日志
last -n 50 > last.txt
lastb -n 100 > lastb.txt # 失败登录，爆破的直接证据
who > who.txt; w > w.txt
# 4. 计划任务与自启动（挖矿/后门最常驻留的地方）
crontab -l > crontab-root.txt 2>&1
ls -l /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ > cron-dirs.txt 2>&1
systemctl list-timers --all > timers.txt 2>&1
ls -l /etc/rc.local /etc/profile.d/ > autostart.txt 2>&1
# 5. 近期修改过的文件（WebShell 落地会留在这里）
find / -xdev -mmin -1440 -type f \( -name '*.php' -o -name '*.jsp' -o -name '*.sh' \) \
2>/dev/null | head -100 > recent-files.txt
# 6. 打包全部日志（系统日志、Web 日志、审计日志）
tar czf logs-$(date +%F-%H%M).tar.gz /var/log 2>/dev/null注意 lastb 需要 root 权限且 /var/log/btmp 存在；Web 日志（Nginx 的 /var/log/nginx/access.log、Apache 的 /var/log/httpd/access_log）是判断 CC 攻击与漏洞利用路径的核心材料，务必一并打包。
2.2 断网的取舍：三种隔离力度
隔离不是只有"拔网线"一种做法，按影响从小到大选择：
- 限制访问（推荐首选）：在防火墙层只放行办公网 IP 与管理 IP，其余全部拒绝。业务暂时对外不可用，但你还能登录、还能取证。
- 切断出网（针对挖矿/外连 C2）：只封出站流量，保留入站。这样既阻止木马回连，又不影响对外服务。
- 完全断网/关机：只在勒索软件正在加密、或攻击导致宿主机被云厂商封停时使用。关机前必须完成取证。
# 只放行管理 IP（firewalld，Rocky Linux 9 / CentOS Stream 9）
firewall-cmd --set-default-zone=drop
firewall-cmd --permanent --zone=drop --add-source=203.0.113.10 # 办公网出口
firewall-cmd --reload
# 只封出站（iptables，Ubuntu 24.04 LTS 用 ufw 亦可）
iptables -A OUTPUT -p tcp --dport 3333 -j DROP # 常见矿池端口
iptables -A OUTPUT -d 45.33.32.156 -j DROP # 已确认的 C2 地址
# 临时封单个攻击源 IP
iptables -I INPUT -s 203.0.113.77 -j DROP
iptables -I INPUT -s 203.0.113.0/24 -j DROP # 整段封禁云服务器还有一个更快的开关：安全组。在控制台把安全组改成"只放行 22 端口且来源为办公网"，10 秒内生效，且不占用已被打满的机器资源。
三、第 2 步：定位攻击类型，用四条线索快速分诊
结论：用"资源、连接、日志、变更"四条线索交叉验证，5 分钟内可把攻击归入流量型、请求型、入侵型、破坏型四类之一。
| 线索 | 观察命令 | 指向的结论 |
|---|---|---|
| 资源 | top、iostat -x 1、free -m | CPU 100% 且进程名可疑 → 挖矿；CPU 正常但网络卡 → 流量型 |
| 连接 | ss -antp、ss -s、ss -ant state syn-recv | 数万 SYN_RECV → SYN Flood；单 IP 数千连接 → CC |
| 日志 | lastb、journalctl -u sshd、Nginx access.log | 大量失败登录 → 爆破；异常 URL 200 → WebShell |
| 变更 | find -mmin、rpm -Va、crontab -l | 新增计划任务/新文件 → 已失陷 |
# 线索一：连接数画像——三种典型攻击各有特征
ss -s # 总连接数概览
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn # 状态分布
ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 # 来源 IP TOP20
# SYN Flood 特征：SYN_RECV 堆积
ss -ant | grep -c SYN_RECV
# CC 特征：单 IP 连接数异常高
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# 线索二：异常进程——重点看 /proc/PID/exe 是否指向已删除文件
for p in $(ls /proc | grep -E '^[0-9]+$'); do
exe=$(readlink /proc/$p/exe 2>/dev/null)
case "$exe" in *"(deleted)"*) echo "PID $p -> $exe";; esac
done
# 线索三：SSH 认证日志
journalctl -u sshd --since "2 hours ago" | grep -iE "failed|accepted|invalid user" | tail -50
grep -iE "Failed password|Accepted password" /var/log/secure 2>/dev/null | tail -50
# 线索四：近期变更文件（WebShell 落地）
find /var/www -newermt "-24 hours" -type f -name '*.php' 2>/dev/null分诊结论与下一步的对应关系：
- 流量型（DDoS/ SYN Flood）：带宽打满、
SYN_RECV堆积 → 走"切高防/CDN"，不要在本机挣扎。 - 请求型（CC）：带宽不高但 QPS 极高、连接数爆表 → 走"封 IP + 限流 + 验证码/JS 挑战"。
- 入侵型（爆破成功/WebShell/挖矿）：有异常进程、异常账号、异常计划任务 → 走"加固 + 排查入侵范围"，详见《服务器被入侵怎么排查》。
- 破坏型（勒索/删库）：文件被加密、数据被删 → 立即断网 + 保全镜像 + 从离线备份恢复，不要支付赎金。
四、第 3 步：止血——封 IP、切高防、限流
结论：本机层面的封 IP 只能应对小规模攻击；大规模流量型攻击必须在上游（CDN/高防/运营商）化解，因为流量在到达你的服务器之前就已经把带宽吃满了。
止血手段按"生效位置"从远到近排列：
- 云厂商高防 / 运营商清洗：在流量进入机房前拦截，是唯一能扛住大流量攻击的手段。提前配置好高防 IP 与回源白名单，事发时改 DNS 解析即可切换（DNS 生效有 TTL，建议平时把 TTL 设为 300 秒以内）。
- CDN：隐藏源站 + 边缘节点分担，对 CC 与多数流量型攻击有效。
- 本机防火墙封 IP/限速：只能处理"少量 IP 的低强度攻击"，但响应最快，作为临时手段必备。
- 应用层限流：Nginx
limit_req/limit_conn，针对 CC 最有效。
# 临时封禁 TOP 攻击 IP（把来源 IP TOP20 里明显异常的封掉）
for ip in $(awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn \
| awk '$1>1000{print $2}'); do
iptables -I INPUT -s "$ip" -j DROP
echo "blocked $ip"
done
# 单 IP 并发连接限制（防 CC 建连）
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j REJECT
iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 50 -j REJECT
# 限速：单 IP 每秒新建连接不超过 20
iptables -A INPUT -p tcp --syn -m hashlimit --hashlimit-name synflood \
--hashlimit 20/second --hashlimit-burst 50 --hashlimit-mode srcip -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
# 保存规则（Rocky：iptables-services；Ubuntu：iptables-persistent）
iptables-save > /etc/sysconfig/iptables # Rocky Linux 9
iptables-save > /etc/iptables/rules.v4 # Ubuntu 24.04 LTS止血阶段必须同时确认一件事：你的备份还在，且没有被攻击者触及。 如果备份挂载在被入侵的机器上，或备份账号凭据已泄露，攻击者可能已经删掉了备份——这时先做快照冻结备份盘。
五、第 4 步：加固——把入口真正堵上
结论：止血只是让攻击停下来，不堵住入口对方一定会再来。 加固的动作围绕"身份、暴露面、漏洞、持久化"四方面展开。
- 身份：强制修改所有密码；重新生成 SSH 密钥对并清理
~/.ssh/authorized_keys中的陌生公钥；数据库、后台管理、云控制台、对象存储的账号全部轮换；开启 MFA。 - 暴露面：安全组只放行必要端口；数据库（3306/5432/6379）、Redis（6379）、Memcached（11211）永远不要对 0.0.0.0 开放；管理后台限制来源 IP 或加二次认证。
- 漏洞：把攻击路径上涉及的组件全部升级（Web 框架、插件、中间件、内核）；修复已确认被利用的漏洞（如文件上传、反序列化、SQL 注入）；不用的服务直接卸载。
- 持久化：删除攻击者创建的账号、计划任务、systemd 服务、WebShell；检查
/etc/cron.*、systemd timer、rc.local、~/.bashrc、/etc/ld.so.preload。
# 检查并清理可疑账号（UID 0 的非 root 账号是高危信号）
awk -F: '$3==0{print "UID0:", $1}' /etc/passwd
awk -F: '$3>=1000 && $3<65534{print $1, $3, $7}' /etc/passwd
# 检查 sudo 权限是否被塞了后门
cat /etc/sudoers | grep -vE '^#|^$'
ls -l /etc/sudoers.d/
# 清理所有用户的计划任务中的可疑项
for u in $(cut -d: -f1 /etc/passwd); do
echo "== $u =="; crontab -l -u "$u" 2>/dev/null
done
# SSH 公钥审计
for d in /root/.ssh /home/*/.ssh; do
[ -f "$d/authorized_keys" ] && { echo "== $d =="; cat "$d/authorized_keys"; }
done
# 关键系统文件完整性校验（Rocky/RHEL 系）
rpm -Va --nofiles --nodigest 2>/dev/null | head -30
# Debian/Ubuntu 系
debsums -c 2>/dev/null | head -30加固完成后必须做一次验证：从外部用漏洞扫描器或简单的手工验证确认漏洞已修复，改密后用新凭据登录一遍，确认所有业务正常。
六、第 5 步：恢复——从干净备份回到正轨
结论：确认主机已被入侵（发现 WebShell、异常账号、可疑进程）后，最可靠的恢复方式是"重装系统 + 从干净备份恢复数据"，而不是在原机上清理。 因为你无法保证自己找到了所有后门。
恢复的顺序：
- 确定恢复源：选一个确认在攻击发生之前生成的备份，并验证其完整性（校验值、
restic check）。 - 新建干净主机：用官方镜像重装系统或新建云实例，先打全补丁、加固基线，再恢复数据。
- 恢复数据：数据库用
mysql < dump.sql/pg_restore；文件用rsync或tar解压。恢复前先在隔离环境还原一份做检查，确认备份里没有混进 WebShell 或恶意计划任务。 - 验证：跑通业务冒烟测试、核对关键数据条数与金额、检查日志无异常报错。
- 切流与观察：DNS 切换或负载均衡加权，小流量灰度 30 分钟，监控无异常再全量。
- 保留旧机：把旧机器磁盘做快照后保留至少 7~30 天（涉报案或合规的保留 6 个月以上），不要立即销毁。
# 从干净备份恢复 MySQL
zcat /backup/db/mysql-appdb-2026-03-11-0200.sql.gz | mysql -u root -p appdb
# 从干净备份恢复 PostgreSQL（-Fc 格式）
pg_restore -h 127.0.0.1 -U postgres -d appdb --clean --if-exists /backup/db/pg-appdb-2026-03-11.dump
# 恢复文件（注意先解到临时目录检查，确认无 WebShell 再上线）
mkdir -p /tmp/restore && tar -xzf /backup/full-2026-03-11.tar.gz -C /tmp/restore
grep -rIlE "eval\(|base64_decode|system\(|passthru" /tmp/restore --include='*.php' | head
rsync -a /tmp/restore/data/www/ /data/www/
企业QQ咨询
