服务器被入侵拿去做攻击，第一反应不是删文件，而是先断外联、留证据、再按时间线倒查入口；漏洞没补完就重装系统，大概率过几周又被同一批人从同一个口子踩进来。下面这套流程，是按止损、排查、溯源、修复四步走的，照着做能少踩很多坑。
服务器被入侵用作攻击怎么办？先做三件止损动作
发现主机在向外发包、跑满带宽，或者云厂商发来告警说你的 IP 在扫描别人，先别慌，这个阶段最忌讳两件事：直接 rm 掉可疑文件，以及图省事关机重启，前者毁证据，后者丢内存里的进程现场。
第一步：隔离出方向，而不是直接关机
攻击者用你的机器打别人,靠的是出方向流量，你需要掐断它，同时保住现场。
- 云主机：在控制台安全组里加一条拒绝所有出方向的规则，优先级高于现有规则，比关机温和得多
- 物理机/自建：
iptables -I OUTPUT -j DROP，只保留你的管理 IP 和运维通道 - 顺手记录当前状态：
ss -antp > /tmp/net.txt、ps aux --sort=-%cpu > /tmp/ps.txt
第二步：判断攻击外溢到什么程度
主机是只发垃圾邮件,还是已经成了 DDoS 肉鸡、代理跳板，处置策略完全不同。
ss -antp | awk '{print $5}' | sort | uniq -c | sort -rn | head，看外连集中在哪些端口和目标ss -antp | grep -c ESTAB，连接数异常高通常说明在跑扫描或代理- 查
/var/log/mail.log或 postfix 队列，确认有没有被拿来发信 - 看
dmesg和监控曲线，带宽打满但 CPU 不高，多半是流量转发型木马
第三步：证据快照先打一份
在动手清理之前,把能留的都留一份，放到另一台机器上。
- 云盘做一次快照,或
dd if=/dev/vda of=/data/image.dd bs=1M备份系统盘 - 打包日志：
tar czf /tmp/logs.tgz /var/log /etc - 关键文件算哈希：
sha256sum /usr/bin/ /usr/sbin/ > /tmp/bin.sha256 - 记录进程完整信息：
for p in /proc/[0-9]; do echo $p; cat $p/cmdline | tr '\0' ' '; echo; ls -l $p/exe $p/cwd; done
很多公司会直接找外部团队接手,比如北京服务器被入侵应急响应服务商，好处是能带着取证工具进场，坏处是价格和响应时间要提前谈清楚，自己团队有 Linux 底子的，按下面顺序查基本够用。
Linux服务器被入侵怎么排查溯源？按时间线倒着查
溯源的核心思路是从结果倒推入口：先锁定恶意进程，再看它从哪来、谁启动的、什么时候进来的，最后回到日志里找那一刻的异常请求。
从异常进程和网络连接切入
恶意进程往往伪装成系统线程,名字像 kthreadd、[kworker/0:1]，但真内核线程的 cmdline 是空的、exe 指向不存在。
ls -l /proc/<pid>/exe，指向/tmp、/dev/shm、已删除文件的，基本可以定性cat /proc/<pid>/environ，看启动环境变量里有没有可疑路径ps -ef --forest，顺着父进程往上看，很多木马挂在 web 服务的子进程下- 检查
/etc/ld.so.preload，这一行非空基本等于中了用户态 rootkit
账户和登录面排查
awk -F: '($3==0){print}' /etc/passwd，UID 为 0 的非 root 账户直接处理cat /etc/shadow | grep -v '^[^:]:[!]'，有密码的账户逐个确认ls -la ~/.ssh/和/root/.ssh/authorized_keys，多出来的公钥就是后门last -F | head -30和lastb | head -30，成功登录和爆破失败对照着看/etc/sudoers和/etc/sudoers.d/里有没有给陌生用户提权
持久化位置逐项过一遍
攻击者拿到权限后一定会留后路,行业共识认为至少七成入侵事件存在两处以上持久化，只清一处等于没清。
- 计划任务：
crontab -l、ls -la /etc/cron./、/var/spool/cron/ - 服务：
systemctl list-unit-files --state=enabled，逐个对应用文件路径 - 启动项：
/etc/rc.local、/etc/init.d/、/etc/profile.d/ - SSH 配置：
/etc/ssh/sshd_config里的AuthorizedKeysCommand、ForceCommand - Web 目录：
find /var/www -type f -mtime -7 | head -50，近期被改动的脚本重点看
Web 入口和组件漏洞对照查
绝大多数 Linux 主机被拿下，入口就那几类，对照日志特征查，效率比漫无目的翻文件高得多。
| 常见入口 | 日志里的典型痕迹 | 优先查位置 |
|---|---|---|
| SSH 弱口令爆破 | secure 里大量 Failed password 后紧跟 Accepted |
last、/var/log/secure |
| 上传/反序列化 | access.log 中 POST 集中、出现新 .php/.jsp |
web 目录 mtime、上传目录 |
| Redis/数据库未授权 | 6379、3306 对公网可访问，进程外连异常 | 安全组规则、ss -antp |
| 中间件/框架漏洞 | 版本号命中已知 CVE，访问路径带 payload 特征 | nginx -v、组件版本清单 |
| 供应链投毒 | 依赖包被替换，构建产物哈希异常 | package-lock、二进制哈希比对 |
查 access.log 时按状态码和请求体大小排序更直观：awk '{print $1,$7,$9}' access.log | sort | uniq -c | sort -rn | head -30，异常 IP、异常路径一目了然。
云服务器被入侵要不要重装系统？看污染深度
这是被问得最多的问题,答案是看情况，判断标准是内核层有没有被动过、账户体系有没有失控。
建议直接重装的情况
- 发现内核模块异常：
lsmod里有陌生模块，/lib/modules下文件被改 - 多个系统账户密码被改,或 sudoers 出现未知规则
- 核心二进制被替换：
rpm -Va或debsums报出大量校验失败 - 攻击者已经提权到 root 且停留时间不明
这类情况下,就地清理的漏网概率太高，重装加数据迁移反而更省时间。
可以就地清理的情况
- 只有单个 webshell，没有提权痕迹，
last里没有异常登录 - 弱口令爆破成功但攻击者只跑了脚本,没动系统文件
- 容器环境,受影响的是容器本身，宿主未受影响
清理完必须做的动作：全量改密码（含数据库、Redis、第三方 API Key）、更换 SSH 密钥对、核对安全组和防火墙规则、把补丁打到最新。
| 判断维度 | 就地清理 | 重装系统 |
|---|---|---|
| 业务中断时间 | 较短，小时级 | 较长，需迁移和验证 |
| 残留风险 | 中高，取决于排查彻底程度 | 低 |
| 适用前提 | 无内核层改动、无提权 | 存在 rootkit 或账户失控 |
| 后续成本 | 需持续监控确认 | 一次性投入，配置重建 |
至于服务器被入侵溯源一般多少钱,市面上没有统一价，按人天计费的多，单台主机和整集群差距很大，日志越完整、留存时间越长，成本越低，日志被清空或者根本没开审计的，光取证就要多花不少工夫。
漏洞修复：补入口、断横移、补监控
清理只是把当前这波人赶走,真正决定会不会再被进的是这三件事。
- 补入口：把入侵时用的那条路径堵死，弱口令就上密钥登录加 fail2ban，组件漏洞就升级版本，未授权访问就收安全组
- 断横移：同一内网的其他主机也要查，攻击者常拿一台当跳板，内网访问按最小权限收紧，数据库不对应用层以外开放
- 补监控：开启
auditd或云厂商的主机安全 Agent，对execve、敏感文件变更、异常外连设告警，业内专家指出，入侵发现时间从平均数月缩短到小时级，靠的就是这类行为审计而不是特征扫描
修复完成后做一次回归验证：重新扫端口、跑一遍漏洞扫描器、确认没有残留的定时任务和外连。别只补被发现的那一个洞，同一批组件里的同类问题往往一起存在。
服务器被入侵用作攻击,处置的本质是证据优先、入口归因、彻底断根，把止损、溯源、加固三步走完，才算真正把主机拿回来。
关于服务器入侵排查与修复的常见问题
服务器被入侵用作攻击怎么办，第一步到底该做什么？
先隔离出方向流量,再保存现场，具体是安全组拒绝出站或 iptables -I OUTPUT -j DROP，同时导出进程列表、网络连接和关键日志到另一台机器，切忌直接关机或删除可疑文件，内存里的进程链和临时文件一旦丢失，后续溯源基本只能靠猜。
Linux服务器被入侵怎么排查溯源，日志被清空了还有办法吗？
有,日志被清不等于无迹可查，可以从这几个方向补：/proc 下仍在运行的进程信息、文件系统的 mtime/ctime/atime（用 stat 逐个看）、bash history、云厂商侧的网络流量日志和快照、以及同内网其他主机的日志，很多攻击者只清 /var/log，忘了 journalctl 的二进制日志和审计日志，这两处经常能捞到关键时间点。
云服务器被入侵要不要重装系统，怎么控制业务中断时间？
判断依据是内核层和账户体系有没有被动过,存在 rootkit、内核模块被改、多个账户失控的，直接重装，只是单点 webshell 且无提权痕迹的，可以就地清理，控制中断时间的做法是提前准备好镜像和自动化部署脚本，把重装拆成“新机拉起、数据迁移、灰度切流、旧机下线”四步，业务感知时间能压到分钟级。