The german government wants me to secure portmapper/rpcbind (:111) on my proxmox host

Operating Systems & Open Source Linux
, , ,
1

Hi!

I recently setup a Proxmox host on Hetzner and I’m pretty happy with how its going. The security basics like disabling root ssh, only public key login over ssh, fail2ban, etc seem to be working nicely so far (more hardening suggestions always welcome).

Today Hetzner forwarded me an email by the “German Federal Office for Information Security” informing me about an open port 111 on my server, which could potentially be used for reflection DDoS attacks.

First of all, I’m pretty impressed, that there’s a German ministry checking for things like this. Pretty cool.

Second, how do I remedy this?

From what I can tell, NFS is the only thing that really needs it (am I missing something?). currently i am not using NFS, but I’ll probably need it at some point to permanently mount a storage box.

For now tho I’ve tried stopping & disabling portmap.service with systemctl, but it seems to start right back up for some reason…

Any advice on this would be greatly appreciated! I don’ really need another scary looking email from a German ministry hitting my inbox :smiley:

Here's the full email for anyone interested

Dear Sir or Madam,

the Portmapper service (portmap, rpcbind) is required for mapping RPC
requests to a network service. The Portmapper service is needed e.g.
for mounting network shares using the Network File System (NFS).
The Portmapper service runs on port 111 tcp/udp.

In addition to being abused for DDoS reflection attacks, the
Portmapper service can be used by attackers to obtain information
on the target network like available RPC services or network shares.

Over the past months, systems responding to Portmapper requests from
anywhere on the Internet have been increasingly abused DDoS reflection
attacks against third parties.

Please find below a list of affected systems hosted on your network.
The timestamp (timezone UTC) indicates when the openly accessible
Portmapper service was identified.

We would like to ask you to check this issue and take appropriate
steps to secure the Portmapper services on the affected systems or
notify your customers accordingly.

If you have recently solved the issue but received this notification
again, please note the timestamp included below. You should not
receive any further notifications with timestamps after the issue
has been solved.

Additional information on this notification, advice on how to fix
reported issues and answers to frequently asked questions:
https://reports.cert-bund.de/en/

This message is digitally signed using PGP.
Information on the signature key is available at:
https://reports.cert-bund.de/en/digital-signature

Please note:
This is an automatically generated message. Replies to the
sender address <[email protected]> will NOT be read
but silently be discarded. In case of questions, please contact
<[email protected]> and keep the ticket number [CB-Report#…]
of this message in the subject line.

Affected systems on your network:

Format: ASN | IP | Timestamp (UTC) | RPC response
24940 | | 2024-10-29 06:07:36 | 100000 4 111/udp; 100000 3 111/udp; 100000 2 111/udp; 100000 4 111/udp; 100000 3 111/udp; 100000 2 111/udp;

Mit freundlichen Grüßen / Kind regards
Team CERT-Bund

Bundesamt für Sicherheit in der Informationstechnik
Federal Office for Information Security (BSI)
CERT-Bund
Godesberger Allee 87, 53175 Bonn, Germany

Cheers,
K1ngjulien

2

netstat -planut | grep 111

Investigate service and remedy.

3

BSI used to be a joke back in the days, but they’re doing good stuff in the last years. Doing standards for datacenter security for small businesses to get a baseline certification. Not perfect, but I like their work (which is rare when talking about federal agencies)

Don’t know much about that Port 111, sorry.

2 Likes
4

no more netstat on debian 12…

[louis ~ (130)]: sudo ss -a src :111
Netid                State                 Recv-Q                Send-Q                                 Local Address:Port                                   Peer Address:Port                Process
udp                  UNCONN                0                     0                                            0.0.0.0:sunrpc                                      0.0.0.0:*
udp                  UNCONN                0                     0                                               [::]:sunrpc                                         [::]:*
tcp                  LISTEN                0                     4096                                         0.0.0.0:sunrpc                                      0.0.0.0:*
tcp                  LISTEN                0                     4096                                            [::]:sunrpc                                         [::]:*

Heres rpcinfo:

[louis ~ (130)]: sudo rpcinfo
   program version netid     address                service    owner
    100000    4    tcp6      ::.0.111               portmapper superuser
    100000    3    tcp6      ::.0.111               portmapper superuser
    100000    4    udp6      ::.0.111               portmapper superuser
    100000    3    udp6      ::.0.111               portmapper superuser
    100000    4    tcp       0.0.0.0.0.111          portmapper superuser
    100000    3    tcp       0.0.0.0.0.111          portmapper superuser
    100000    2    tcp       0.0.0.0.0.111          portmapper superuser
    100000    4    udp       0.0.0.0.0.111          portmapper superuser
    100000    3    udp       0.0.0.0.0.111          portmapper superuser
    100000    2    udp       0.0.0.0.0.111          portmapper superuser
    100000    4    local     /run/rpcbind.sock      portmapper superuser
    100000    3    local     /run/rpcbind.sock      portmapper superuser
5

Have a read at this two year old post on the official forums. It mentions several ways from disabling the listening service, to installing a firewall and also removal of the affected packages. I, personally, would do both, disable the service and install the ufw firewall.

2 Likes
6

ahh there was a socket starting the service again… i should have read the output more closely lmao

this seems to have done the trick of finally stopping the service

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

certainly a good idea, thanks. i have opnsense+wireguard running as a vm but while tunneling the host ip through the virtual firewall is certainly possible, i’ve already locked myself out a few times lol

ufw to block everything but ssh seems simple enough

Also found this serverfault thread confirming that portmapper isnt even needed for an nfsv4 client, so I’ll see if i can get that running when i need it

2 Likes
7

BTW a useful thing to have bookmarked or even printed might be the useful commands tables in the Debian manual - systemd.

EDIT: since you use Hetzner DE you might consider subscribing to the various Computer Emergency Response Teams (CERT) or have their pages bookmarked. I tend to have a tab open with the German CERT one all the time…

Gruss aus England!

8

Always and everywhere firewall. Block all traffic except what you absolutely need. If you can, even limit IP addresses that can connect per port per protocol.

Leaving a server that is online 24/7/365 to the touch of the entire internet without restrictions is a bad idea.

A loose example of a working service in a situation where we do not control traffic with a firewall.