前情提要

LZ的一台Debian 12小鸡安装了iperf3工具，因为误开启了iperf3的自启动服务，5201端口长期暴露在公网，在昨晚被陌生人刷了1.5TB的出向流量。由于iperf3默认不带鉴权，因此只要服务端口开放，就能被任何人使用。LZ有幸观察到了异常的端口速率和cpu占用，才做到了及时止损。希望本文可以帮助读者避免类似的问题。

刷流量的来源ip是38.135.25.225（AS27284）。

背景

为了进行便捷的vps间网络测速，我在数月前重装这台小鸡时安装了iperf3工具。在安装的过程中，会跳出这样一个提示弹窗：

我当时以为是一些iperf3运行必备的后台驱动（实际含义是开机时自动启动iperf3 server，监听端口5201），所以选择了这里的“Yes”，为昨晚的事件埋下了隐患。

时间过得很快，一转眼已经近6个月了。尽管从7月中开始了持续时间颇长的“香港大战”，但是异常流量也并未参与这里的统计，直到昨天——

异常的发现

昨天晚间老板在tg群里提示：JP.CO电信回程已接入163pp，作为COP上线前的抢鲜测试。

我在大约23:40左右登陆了vps，挂了会机后简单测了下路由，看到这里的状态提示栏后，突然发现了不对。

好家伙，我明明既没测速也没安装代理工具，端口速率和cpu占用率居然都是近满的（图片为事后所截，当时后台的iperf3进程已经连跑了近2小时，cpu占用率长期保持在85%+）？我看到cpu占用率排第一的是一个iperf3进程，明明没有主动开启iperf3 server，它的占用率为何会如此之高？

我首先想到的是我装的一个lg项目，毕竟它可以在web端启动iperf3服务器。于是，我立即停止了相应的docker容器，却发现那个iperf3进程依然在持续运行中。那就怪了，反正先kill掉那个iperf3进程要紧——

sudo pkill -INT iperf3

运行这行命令后，世界终于清净了，那接下来就是找“后门”的过程了。

运行命令：

# 显示当前处于“运行态(R)”的进程(按 CPU 使用率降序排列)ps -eo pid,stat,pcpu,pmem,cmd --sort=-pcpu | awk '$2 ~ /R/'

运行结果：

141050 Rs 0.7 0.5 /usr/bin/iperf3 --server --interval 0 160499 R+ 0.0 0.4 ps -eo pid,stat,pcpu,pmem,cmd --sort=-pcpu

接下来查看pid=141050的进程相关信息：

# 1) 详细进程信息（用户、启动时间、父进程）ps -p 141050 -o pid,ppid,user,lstart,etime,cmdpstree -aps 141050# 2) 监听端口与地址（默认应是 TCP 5201）ss -lntp | awk 'NR==1 || /iperf3|5201/'# 3) 是否被 systemd 管理/自启动systemctl status iperf3 2>/dev/null || truesystemctl list-unit-files | grep -i iperf3

最终的结果

运行了前面的这些指令后，我找到了这样一个iperf3的自启动服务：

位置：

/etc/systemd/system/multi-user.target.wants/iperf3.service

具体内容：

[Unit]Description=iperf3 serverDocumentation=man:iperf3(1)After=network.target auditd.service[Service]Type=simpleRestart=alwaysRestartSec=15User=iperf3ExecStart=/usr/bin/iperf3 --server --interval 0SuccessExitStatus=1[Install]WantedBy=multi-user.target

接着查看了一下此服务的历史日志输出，发现十分触目惊心：

运行命令：

sudo journalctl -u iperf3 --since "2025-10-08 19:00"

运行结果：

可见来源ip是38.135.25.225，在2个多小时的时间里，它通过iperf3刷了我1.46TB的出向流量，开启的10线程足以表明其恶意，而非意外

之后，我直接拉黑了此ip所属的ASN，并移除了iperf3的自启动服务，这场闹剧总算也是告一段落了，可惜流量已经回不来了，哎。