Introduction to THE PROBLEM :
rpcbind TCP/UDP port 111 automatically starting itself out of nothing on CentOS 7 Linux
For server environments that are being monitored regularly for CVI security breaches based on opened TCP / UDP ports with like Qualys (a proprietary business software that helps automate the full spectrum of auditing, compliance and protection of your IT systems and web applications.), perhaps the closest ex-open source equivallent was Nessus Security Scanner or the more modern security audit Linux tools – Intruder (An Effortless Vulnerability Scanner), OpenVAS (Open Vulnerability Assessment Scanner) or even a simple nmap command port scan on TCP IP / UDP protocol for SunRPC default predefined machine port 111.
[root@centos~]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
[root@centos~]# grep -i rpcbind /etc/services
sunrpc 111/tcp portmapper rpcbind # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper rpcbind # RPC 4.0 portmapper UDP
Note! For those who don't know it or newer to Linux
/etc/services file
used to be a file with predefiend well known services and their ports in Linux as well as other UNIXes for years now.
So once this scan is triggered you might end up in a very strange situation that the amount of processes on the CentOS Linux server misterously change with +1 as even though disabled systemctl rpcbind.service process will appear running again.
[root@centos~]# ps -ef|grep -i rpcbind
rpc 100 1 0 Nov11 ? 00:00:02 /sbin/rpcbind -w
root 29099 22060 0 13:07 pts/0 00:00:00 grep –color=auto -i rpcbind
[root@centos ~]#
By the wayit took us a while to me and my colleagues to identify what was the mysterious reason for triggering rpcbind process on a gets triggered and rpcbind process appears in process list even though the machine is in a very secured DMZ Lan and there is no cron jobs or any software that does any kind of scheduling that might lead rpcbind to start up like it does.
[root@centos ~]# systemctl list-unit-files|grep -i rpcbind
rpcbind.service disabled
rpcbind.socket disabled
rpcbind.target static
There is absoultely no logic in that a service whose stopped on TCP / UDP 111 on a machine that is lacking no firewall rules such as iptables CHAINs or whatever.
[root@centos~]# systemctl status rpcbind
● rpcbind.service – RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; disabled; vendor preset: enabled)
Active: inactive (dead)
A you can see the service after all seems to have been disabled originally but after some time this output auto-magically was turning to rpcbind.socket enabled:
root@centos ~]# systemctl list-unit-files|grep -i rpcbind
rpcbind.service disabled
rpcbind.socket enabled
rpcbind.target static
Hence to prevent the rpcbind.socket to automatically respawn itself and lead to resurrection of the dead and disabled /sbin/rpcbind
1. Disable listener in /usr/lib/systemd/system/rpcbind.socket file
And comment all Listen* rows there
[root@centos ~]# vi /usr/lib/systemd/system/rpcbind.socket
[Unit]
Description=RPCbind Server Activation Socket
[Socket]
ListenStream=/var/run/rpcbind.sock
# RPC netconfig can't handle ipv6/ipv4 dual sockets
BindIPv6Only=ipv6-only
#ListenStream=0.0.0.0:111
#ListenDatagram=0.0.0.0:111
#ListenStream=[::]:111
#ListenDatagram=[::]:111
[Install]
WantedBy=sockets.target
2. Mask rpcbind.socket and, sure /etc/systemd/system/rpcbind.socket links to /dev/null
Mute completely rpcbind.socket (this is systemd option "feature" to link service to /dev/null)
[root@centos ~]# systemctl mask rpcbind.socket
…
Hence, the link from /etc/systemd/system/rpcbind.socket must be linked to /dev/null
[root@centos ~]# ls -l /etc/systemd/system/rpcbind.socket
lrwxrwxrwx 1 root root 9 Jan 27 2020 /etc/systemd/system/rpcbind.socket -> /dev/null
Voila ! That should be it rpcbind should not hang around anymore among other processes.