服务器带宽莫名跑满、CPU 空转但网站访问量没涨、云厂商发来安全告警——这些现象很多时候指向同一个问题：服务器被植入了木马，成了攻击者手里的肉鸡，正在对外发起 DDoS 攻击或挖矿。本文用 9 个问答讲清肉鸡的判定信号、出向流量自查命令、恶意进程与持久化排查、应急处置顺序，以及怎么加固防复发。
Q：服务器怎么会变成肉鸡？
三扇门最常被撬开：
- 弱口令与未授权服务：SSH 开着密码登录，Redis、MongoDB、Docker API、Elasticsearch 暴露在公网且无认证，扫描器十几分钟就能找到。
- Web 应用漏洞：文件上传、反序列化、命令注入等 RCE 类漏洞，直接从 Web 服务拿到 shell。
- 凭据泄露：代码仓库里硬编码的 SSH 私钥、云 API 密钥被泄露，攻击者用合法凭据登录，日志里看不到暴力破解痕迹。
进来之后的目的通常有三类：把服务器当 DDoS 发源或反射节点、跑挖矿程序、做代理跳板或发垃圾邮件。前两种会直接体现为出向流量异常，也是站长最早能感知到的。
Q：怎么判断服务器已经被当肉鸡了？
五个信号，出现两个以上就该排查：
- 出向流量明显大于入向——
iftop里出向曲线拉满，而你的站点是给人看的，正常应该相反。 - 云厂商安全中心告警或工单：异常外连、异常端口、IP 被判定为攻击源。
- CPU 与网络不匹配：CPU 高但自家业务请求量没变；或者 CPU 不高、带宽却跑满。
- 网站访问日志正常，带宽却异常，说明流量不是你的业务产生的。
- 收到外部投诉：IP 被列黑名单、被机房限速、被其他站长举报。
核心判据一句话：看流量的方向，而不只是看流量的多少。
Q：出向流量到底怎么查？
# 1. 实时看总流量与方向
cat /proc/net/dev # 累加计数，取两次差值
sar -n DEV 1 5 # 每秒收发速率
# 2. 按连接看外连
ss -antp state established | grep -v "127.0.0.1"
# 3. 按进程看谁在发包（需安装 nethogs）
nethogs eth0
# 4. 按远端 IP 聚合，找出被打的目标
ss -antp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head若 ss 里出现大量指向同一批外网 IP 的 ESTABLISHED 连接（尤其 80、443、53 等端口），基本可以确认服务器正在对外发起攻击。反过来，如果只是 UDP 出向暴涨，多半是被利用做了反射放大。
Q：怎么锁定具体是哪个进程在发包？
# 从连接反查进程
ss -antp state established | grep "远端IP"
# 看进程对应的可执行文件
# 若显示 deleted，说明真实文件已被删除、进程仍在运行
ls -l /proc/PID/exe
ls -l /proc/PID/cwd
# 看进程打开的文件与网络连接
lsof -p PID | head -30常见手法是删掉木马文件但让进程继续运行，所以不能只看文件是否存在，而要按进程反查。发现 (deleted) 标记时，说明清理工作必须结合进程终止一起做，否则重启前的清理都是假象。
Q：恶意程序一般藏在哪？持久化怎么查？
# 常见落地目录
ls -la /tmp /dev/shm /var/tmp /root
# 计划任务三处，漏一处就清不干净
crontab -l
cat /etc/crontab
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily
ls -la /var/spool/cron/crontabs/
# 动态库劫持（rootkit 常用，正常应不存在该文件）
cat /etc/ld.so.preload
# 开机自启与 systemd
systemctl list-units --type=service --state=running
ls -la /etc/rc.local /etc/systemd/system/另外别忘两处：~/.ssh/authorized_keys（攻击者会留自己的公钥，用于长期回连）和 /etc/passwd 里新增的 UID 为 0 的账号。这两项是最容易被忽略的后门。
Q：确认被当肉鸡后，第一步应该做什么？
顺序很关键：先断外网，再留证据，最后清理。
- 收紧云安全组出方向，不要只封入方向；只放行必要的 80、443 与受限源 IP 的管理端口。
- 不要立刻 kill 进程或重启：先记录 PID、可执行文件路径、网络连接、文件哈希，这些是后续报案与溯源的材料。
- 有条件先打包
/proc/PID/相关目录与关键日志（/var/log、auth.log、站点日志）。 - 若必须停机，先把证据复制到站外（另一台机器或对象存储），避免随系统重装一起丢失。
顺序颠倒的代价很直接：先重启再排查，内存里的进程信息与连接状态全部消失，木马还会因持久化配置自启动。
Q：本机怎么限制对外发包？
# 出向默认拒绝 + 白名单放行（危险操作，先在本机控制台验证再保存）
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -P OUTPUT DROP
# 限制单 IP 出向并发，防单一进程刷满带宽
iptables -A OUTPUT -p tcp --syn -m connlimit --connlimit-above 50 -j REJECT注意 iptables -P OUTPUT DROP 会把出向全部阻断，包括你 SSH 会话的响应包，操作不当会把自己锁在门外。更稳妥的做法是在云安全组层面收紧出方向，或者先用 iptables-save 备份、设一条定时回滚任务再动手。
Q：清理完怎么防止再次被入侵？
- 轮换全部凭据：SSH 密钥、数据库与服务口令、云 API AK/SK 一起换，只改 root 密码是不够的。
- 关掉用不到的暴露面：Redis、MongoDB、Docker API 不暴露公网；必须暴露就设认证、绑内网、安全组限源。
- 禁用 SSH 密码登录，改用密钥、非默认端口与登录源限制。
- 上主机安全 agent / HIDS，开启文件完整性监控与出向流量告警。
- 被 rootkit 感染时优先重装：清理不彻底等于没清，重装系统并只恢复数据文件（不恢复可执行文件与配置）最稳妥。
Q：还有什么补充建议？
- 给出向流量设基线告警：超过正常日均出向的 2 到 3 倍就报警，比等云厂商工单来得早。
- UDP 出向要单独看：被利用做 DNS、NTP、memcached 反射放大时，表现就是 UDP 出向流量暴增。
- 只封入向是不够的：被当肉鸡时你是攻击发起方，必须主动切断出向通道，别让同机房的邻居继续被打。
- 被投诉后主动上报：保留处置记录与时间线，说明已完成清理与加固，避免被机房直接下架。
一句话总结：判断被当肉鸡看的是流量方向，处置顺序是断出向、留证据、再清理，加固的落脚点则是关掉暴露面并轮换全部凭据。