服务器带宽突然跑满，机房告警“存在异常出站流量”，甚至提示服务器正在对外扫描端口、发送 UDP 数据包或发起 SYN Flood，这通常不是普通访问量增加，而是服务器已经被恶意程序控制。

很多管理员收到通知后的第一反应是重启服务器、关闭端口或者直接删除可疑文件。这样虽然可能暂时停止发包，却也容易破坏进程、连接记录和启动痕迹，导致真正的入侵入口没有被找到。几小时后，木马又可能通过定时任务或隐藏服务重新运行。

正确的处理顺序应该是：

先限制出站流量，再锁定连接进程，然后追查父进程、启动项和最初入侵入口。

一个真实业务场景：网站正常，出口带宽却突然跑满

某企业将官网、产品后台和少量 API 服务部署在一台香港服务器上，配置为：

• CPU：Intel Xeon E-2334，4 核 8 线程

• 内存：32GB DDR4-3200

• 硬盘：960GB M.2 NVMe SSD

• 带宽：15M CN2，附带 100M 国际带宽

• 系统：Ubuntu 22.04

网站访问量没有明显增加，但服务器的国际出口持续接近 100Mbps。机房监控发现，这台服务器正在向大量陌生 IP 发送 UDP 数据包。

登录服务器后，CPU 使用率只有约 30%，网站也能正常打开。如果只看 top，很容易误认为服务器没有异常。进一步检查网络连接后，才发现一个位于 /dev/shm 临时目录中的隐藏程序持续向外发包。

最终排查发现，攻击者先通过网站程序漏洞上传了 PHP 后门，再下载恶意二进制程序，并在 www-data 用户的定时任务中写入了自动启动命令。

这个案例说明：服务器被控制后，不一定会出现 CPU 100%、网站打不开等明显现象，出口流量往往才是最早暴露问题的指标。

一、先判断是“外部攻击服务器”，还是“服务器向外攻击”

这两种情况完全不同。

外部攻击服务器时，主要表现为入站流量增大、连接数暴涨、业务响应变慢，攻击流量的目标是本机。

服务器向外攻击时，表现为出站带宽增大，并向大量不同 IP 或端口持续建立连接。常见行为包括：

• 扫描公网服务器端口

• 批量尝试 SSH、数据库或远程桌面密码

• 发送 UDP、DNS、NTP 放大流量

• 发起 TCP SYN Flood

• 连接挖矿池、代理节点或远程控制服务器

• 作为代理中转其他攻击流量

需要注意，服务器自带的 DDoS 防护通常主要处理进入机房的攻击流量，并不能代替服务器内部的木马检测和出站访问控制。

二、第一步不是重启，而是快速止损

发现服务器正在恶意发包后，应优先通过机房控制台、安全组或上级防火墙限制出站流量，同时保留自己的 SSH 管理连接。

如果业务允许，可以临时关闭公网出站，只保留：

• 管理员固定 IP 的 SSH 连接

• 必要的数据库或 API 地址

• DNS、时间同步等确实需要的服务

• 业务必须访问的固定目标

不要一上来就重启服务器。重启可能导致以下信息消失：

• 当前恶意进程 PID

• 正在连接的远程 IP

• 进程父子关系

• 内存中的启动参数

• 已被删除但仍在运行的程序文件

• 临时目录中的恶意文件

条件允许时，应先创建快照或保留磁盘副本，再开始清理。

三、快速确认是哪块网卡、哪个方向在跑流量

先查看服务器网卡名称：

ip -br link

再观察各网卡累计收发数据：

ip -s link

也可以直接查看系统网络统计：

cat /proc/net/dev

需要实时观察时，可以使用：

sar -n DEV 1 10

如果服务器安装了 iftop，可以查看正在消耗带宽的目标地址：

iftop -nNP -i eth0

其中 eth0 需要替换成实际网卡名称。重点观察是否存在以下情况：

• 同时连接大量不同公网 IP

• 目标端口高度集中

• UDP 流量持续输出

• 短时间创建大量 TCP 连接

• 出站流量远大于正常业务流量

如果系统没有安装这些工具，不建议在取证前大量安装软件，可以先使用系统自带的 ss、ps 和 /proc 信息排查。

四、通过网络连接锁定恶意进程 PID

执行：

ss -antup

参数含义分别是：

• a：显示全部连接

• n：不解析域名和服务名

• t：显示 TCP

• u：显示 UDP

• p：显示对应进程

重点查看类似内容：

users:((".sysd",pid=18472,fd=8))

这说明 PID 为 18472 的 .sysd 进程正在使用该网络连接。

还可以使用：

lsof -nP -i

或者按进程查看网络文件：

lsof -nP -p 18472

如果安装了 nethogs，可以直接按照进程统计实时流量：

nethogs eth0

需要注意，有些木马会使用原始套接字、容器网络或特殊内核模块发包，此时 nethogs 不一定能显示对应进程，可以使用抓包进一步确认：

tcpdump -nn -i any 'not port 22' -c 200

这里排除了当前 SSH 管理流量，避免大量无关记录干扰判断。

五、顺着 PID 查程序位置和父进程

找到可疑 PID 后，不要立即执行 kill -9，先查看进程的完整信息：

PID=18472

ps -fp $PID
pstree -asp $PID
ls -l /proc/$PID/exe
ls -l /proc/$PID/cwd
tr '\0' ' ' < /proc/$PID/cmdline
echo

还可以查看进程环境变量：

tr '\0' '\n' < /proc/$PID/environ

重点关注以下异常：

• 程序位于 /tmp、/var/tmp 或 /dev/shm

• 文件名伪装成 sshd、systemd、kworker 等系统进程

• /proc/PID/exe 后面出现 (deleted)

• 命令行包含陌生公网 IP、下载地址或加密参数

• 当前工作目录位于网站上传目录

• 进程用户是 www-data、nginx、apache 或异常账户

父进程往往能帮助判断攻击入口：

如果恶意程序已经脱离原父进程，PPID 可能变成 1。这时需要结合网站日志、SSH 日志和文件修改时间继续追查。

六、先保存证据，再终止恶意程序

可以先建立一个事件目录，保存当前系统状态：

INC=/root/incident-$(date +%F-%H%M%S)
mkdir -p "$INC"

ps auxfww > "$INC/process.txt"
ss -antup > "$INC/network.txt"
journalctl --since "-24 hours" > "$INC/journal.txt"

如果 /proc/PID/exe 仍然可以读取，可以复制样本并计算哈希：

cp --dereference /proc/$PID/exe "$INC/suspect.bin"
sha256sum "$INC/suspect.bin" > "$INC/suspect.sha256"

为了暂时停止发包，同时保留进程现场，可以先冻结进程：

kill -STOP $PID

确认业务没有受到错误影响并完成必要信息收集后，再终止进程：

kill -9 $PID

如果恶意进程几秒钟后重新出现，说明服务器中仍有定时任务、守护服务或其他下载程序在负责拉起它，单纯杀进程无法解决问题。

七、检查定时任务和 systemd 隐藏服务

先检查常见用户的定时任务：

for USER in root www-data nginx apache; do
    echo "===== $USER ====="
    crontab -u "$USER" -l 2>/dev/null
done

然后检查系统级定时任务：

cat /etc/crontab
ls -la /etc/cron.d/
ls -la /var/spool/cron/

继续检查 systemd 服务和定时器：

systemctl list-unit-files --state=enabled
systemctl list-timers --all

查找最近修改的启动文件：

find /etc/systemd/system /etc/cron.d /var/spool/cron \
-type f -mtime -7 -ls 2>/dev/null

恶意服务经常使用接近系统服务的名称，例如：

• system-update.service

• network-check.service

• sys-monitor.service

• dbus-helper.service

不能只凭名称判断，必须继续查看服务文件中的 ExecStart、运行用户和程序路径：

systemctl cat 可疑服务名
systemctl status 可疑服务名

八、检查临时目录和网站目录中的落地文件

木马经常把程序放在可写临时目录：

find /tmp /var/tmp /dev/shm \
-xdev -type f -mtime -3 -ls 2>/dev/null

网站服务器还需要检查最近新增或修改的文件：

find /www/wwwroot /var/www \
-type f -mtime -3 -ls 2>/dev/null

针对 PHP 网站，可以搜索部分常见后门特征：

grep -RIn --include='*.php' \
-E 'base64_decode|gzinflate|shell_exec|passthru|eval\(|assert\(' \
/www/wwwroot /var/www 2>/dev/null

这些函数在正常程序中也可能存在，因此搜索结果只能作为线索，不能看到 base64_decode 就直接删除文件。

更可靠的判断方法是：

• 与官方程序包或 Git 仓库比较差异

• 检查文件修改时间和所属用户

• 查看对应时间的网站访问日志

• 判断文件是否位于上传、缓存或图片目录

• 检查代码是否接收外部参数并执行系统命令

九、从日志追查攻击者最初怎么进来的

检查 SSH 登录

Ubuntu、Debian 可以查看：

journalctl -u ssh --since "3 days ago"
grep -E "Accepted|Failed password" /var/log/auth.log

CentOS 系统通常查看：

grep -E "Accepted|Failed password" /var/log/secure

同时检查历史登录地址：

last -ai | head -50
lastb -ai | head -50

如果发现陌生 IP 成功登录，需要立即检查：

• /root/.ssh/authorized_keys

• 普通用户的 authorized_keys

• 是否新增系统账户

• sudo 权限是否被修改

• SSH 配置是否被篡改

检查网站访问日志

如果可疑进程由 PHP、Nginx 或 Apache 触发，应按照恶意文件的修改时间查询网站日志。

重点搜索：

• 上传接口的异常 POST 请求

• 对插件、后台和 API 的集中扫描

• 请求后立即返回 200 的陌生 PHP 文件

• User-Agent 为空或明显伪造的请求

• 同一个 IP 连续请求上传、执行和下载地址

例如：

grep "13/Jun/2026" /www/wwwlogs/example.com.log | grep "POST"

只有找到“攻击请求—后门文件—下载命令—恶意进程”这条完整链路，才能真正确认源头。

十、什么情况下不建议继续清理，而应直接重装

如果发现以下情况，不应再完全信任当前系统：

• 恶意程序以 root 身份运行

• root 的 SSH 密钥或密码已经泄露

• /etc/ld.so.preload 被修改

• 出现不明内核模块

• 系统命令的哈希与官方版本不一致

• 日志被删除或明显篡改

• 多个系统服务被替换

• 无法确认攻击者已经获得多高权限

此时更稳妥的方案是重新安装干净系统，只恢复经过检查的网站文件和数据库，不要把旧系统目录、旧定时任务和整个系统备份直接恢复回去。

同时必须更换：

• SSH 密码和密钥

• 数据库密码

• 网站后台密码

• 面板登录密码

• API Token

• 对象存储密钥

• Git、邮箱和第三方服务凭据

十一、清理完成后，怎样避免服务器再次向外发包

后续加固至少应包括：

1. 关闭 SSH root 密码登录，改用密钥并限制管理 IP。

2. 及时更新系统、面板、CMS、插件和应用依赖。

3. 上传目录禁止执行 PHP、Shell 等脚本。

4. Web 服务使用独立低权限用户运行。

5. 配置出站访问策略，业务服务器不应无限制访问所有公网端口。

6. 将网站日志、安全日志发送到远程日志服务器。

7. 部署文件完整性检查和进程、带宽异常告警。

8. 定期检查 systemd、cron、SSH 密钥和系统账户。

9. 备份网站代码、数据库和配置，但不要只在本机保存备份。

10. 对暴露在公网的 Docker、Redis、数据库和管理面板设置访问限制。

总结

服务器被恶意发包时，最重要的不是马上删除一个木马文件，而是建立完整的定位顺序：

异常流量 → 目标 IP 和端口 → 网络连接 → 进程 PID → 程序路径 → 父进程 → 启动项 → 入侵日志。

只杀进程、不查启动项，木马会再次出现；只删除文件、不查网站后门，攻击者可以重新下载；只封禁某个目标 IP，恶意程序还会更换新的攻击地址。

真正有效的处理，不只是让出口流量恢复正常，而是找出攻击者第一次进入服务器的入口，清除全部持久化机制，并重新建立可信的系统环境。