111端口总被陌生IP连接：rpcbind是干嘛的，不用就关掉

如果你查过云服务器的监听端口，可能会发现一个奇怪的现象：111端口明明没配过什么服务，却一直在公网监听，还总有大量陌生IP来连。这多半是 rpcbind 在工作。先搞清它是什么，再决定关不关，就不会误伤业务。

rpcbind 是干嘛的

rpcbind 是 Linux 系统自带的一个小服务，叫 RPC 端口映射器，固定占 111 端口的 TCP 和 UDP。

它的工作方式像个电话总机：使用 RPC（远程过程调用）的程序，比如 NFS 网络文件共享，先来问 rpcbind，查某个服务到底在哪个端口上，再去连真正的服务。rpcbind 自己不传输业务数据，只负责查号。

为什么它默认就在公网监听

很多发行版默认就装了 rpcbind，而且开机自启，还用了 socket 激活。也就是说，哪怕你从来没用过 NFS，它也会默认在 0.0.0.0:111 上监听，等着别人来查号。

这就解释了两个现象：第一，端口是你没配过的；第二，来连的IP大多不是你的用户，而是全网扫描器。111 是公开知名的端口，扫描器会批量来问你开了哪些 RPC 服务，严重的还可能被用来做反射放大攻击。所以，不用就关掉，是常规的安全收尾动作。

关之前，先确认两件事

不要一上来就杀进程。先确认有没有服务真的靠它：

1. 查反向依赖，看有没有别的服务依赖 rpcbind：systemctl list-dependencies --reverse rpcbind
2. 查有没有 NFS 挂载：mount | grep nfs
3. 查当前监听和连接，确认 111 上是不是只有扫描流量：ss -tlnp | grep ':111 ' ； ss -ulnp | grep ':111 '

如果确实在用 NFS，那就别直接关，先评估迁移方案；如果像大多数云服务器一样根本没用 NFS，就可以往下走。

怎么关才干净

只停服务是不够的，因为 socket 激活会让它在有人来连时又被拉起来。服务和 socket 要一起停、一起禁：

systemctl stop rpcbind.socket rpcbind.service
systemctl disable rpcbind.socket rpcbind.service

关完再验三点，缺一不可：

1. 111 不再监听：ss -tlnp 和 ss -ulnp 里都没有 111，systemctl is-active rpcbind rpcbind.socket 都是 inactive，is-enabled 都是 disabled。
2. 已有 111 连接清零：之前挂着的扫描连接会在服务停掉后断开。
3. 业务端口不受影响：原来在跑的业务服务进程还在，业务监听口都还在，从外部测业务口能通、111 不通，才算收尾完成。

这样关是可逆的：以后真要用 NFS，再把服务和 socket 重新启用并启动就行，不需要重装系统，也不需要重启机器验证。

一句话总结

rpcbind 不是木马，也不是业务服务，它就是系统自带的一个查号服务。你用不上 NFS，它在公网监听就只有被扫描的份。确认没依赖、没挂载之后，停掉加禁用，再验一遍业务口，就把这扇没用的门锁上了。