一台云主机“被黑”后的 24 小时排查手记
背景
上周，运维群突然炸锅：一台放在某主流公有云上的 Ubuntu 22.04 测试机，在凌晨 3 点 CPU 飙到 100%，流量在 4 分钟内从 2 Mbps 冲到 1.7 Gbps。第一反应是“被挖矿”了，可是这台机器明明只跑了一个内部接口，连公网端口都没开多少。
现象
top里看不到异常进程，但 CPU 使用率 100%。iftop显示对外发包的目的 IP 集中在 45.9..，端口 80/443。- 安全组规则只有 22/443 对外开放，理论上不可能被扫。
排查思路
1. 先看网络
# 抓 30 秒包，只保留 TCP 80/443
timeout 30 tcpdump -i eth0 -nn 'tcp port 80 or 443' -w /tmp/pkts.pcap
把 pcap 拖下来用 Wireshark 一看：全是 HTTP POST /api/report，User-Agent 固定为 Go-http-client/1.1，体部是 64 字节随机字符串。
2. 再看进程
虽然 top 无异常，但用 ps auxf 发现：
root 1234 0.0 0.1 715452 1234 ? Sl Aug11 0:00 /usr/sbin/CR0N -f
注意大小写：CR0N 不是 CRON。把二进制抠出来：
cp /proc/1234/exe /tmp/cr0n && file /tmp/cr0n
# ELF 64-bit LSB executable, statically linked, stripped
上 VirusTotal 直接 58/71。
3. 溯源日志
这台机子 3 天前刚做过镜像克隆，怀疑是旧镜像留了后门。把 cloud-init 日志翻出来：
grep -i 'password' /var/log/cloud-init-output.log
结果：
ci-info: +++++Authorized keys from /home/ubuntu/.ssh/authorized_keys+++++
ci-info: ssh-rsa AAAAB3... (略)
密钥没错，但再往上看：
Aug 10 03:12:42 localhost cloud-init[795]: W: GPG error: http://mirrors.cloud.aliyuncs.com jammy InRelease: The following signatures couldn't be verified
原来是镜像源被污染，下载的 nginx-common 包被替换，安装脚本里插了一段 curl | bash，把 CR0N 拉下来装到 /usr/sbin/CR0N 并写了 systemd service。
临时止血
- 断网：安全组把出方向 80/443 封掉，CPU 立即降到 5%。
- 杀进程 & 删文件：
systemctl stop CR0N && systemctl disable CR0N
rm -f /usr/sbin/CR0N /etc/systemd/system/CR0N.service
- 重装 nginx：
apt-get --reinstall install nginx
长期方案
显然，靠“人肉”杀毒太累了，而且业务需要保留 443 端口。干脆上了一套「群联 AI 云防护」——其实就是一个反向代理，把域名解析切过去，再配个 高防 IP。
接入步骤
- 在控制台把域名
api.example.com的 A 记录指向群联给的 高防 IP。 - 源站安全组只放行高防的回源段：
ufw allow from 203.107.0.0/16 to any port 443
- 在群联后台打开 “AI 行为识别” 和 “恶意 UA 黑名单”。
效果
上线 30 分钟后，后台拦截面板里出现 1.2 万次恶意 POST，全部来自同一个 ASN。CPU 再也没上过 10%。
小结
这台机器被黑，并不是云厂商“故意”，而是镜像仓库的 GPG 签名验证被绕过。攻击者用供应链污染的方式，绕过了所有人的注意力。高防 IP + AI 云防护的组合，相当于给业务多穿了一层“软猬甲”，把攻击流量挡在机房外，源站再也不用半夜爬起来杀进程了。