Abuse Complaints for RPCBind

1

Greetings!

I have a feeling that I’m not alone on this, I get these all the time from Hetzner (and no one else). I’m wondering if any of you have any tricks to quiet these. This has been my series of steps (the first is recommended excess as I understand it):

yum install rpcbind -y
systemctl disable rpcbind
systemctl disable rpcbind.socket
systemctl stop rpcbind
systemctl stop rpcbind.socket

Yet I get another complaint the next month because the stupid thing has re-enabled itself. These are CentOS 7 servers running cPanel. I’m scratching my head, maybe one of you knows something I don’t.

1 Like
2 
systemctl disable --now rpcbind
systemctl mask rpcbind

you can also block rpcbind ports using Hetzner’s firewall

3 Likes
3

I love you

3 Likes
4

Used to get these complaints with Choopa as well. Disabling the port via iptables seems to do the trick for me.

5

I Hetzner has such an issue with those, why not block it by default on their firewall…?

Seems like an obvious step to save both sides manhours. Unless I’m missing something ?

2 Likes
6 
# cat /etc/default/rpcbind
OPTIONS="-h 127.0.0.1"
4 Likes
7

I think they have them automated so probably don’t care.

1 Like
8

Interesting!

9

tbh I only use debian - but centos can’t be that different. and limiting rpcbind to localhost worked for me so far even when running gluster (nfs) which might use or need it. can’t tell about cpanel though :wink:

10

that’s also true. they only forward these messages and don’t really care if you take action. it’s just some stupid reminder/warning about potential security issues that’s send out by some german authority that forgot to turn off port scanning in the late 90s or so :man_facepalming:

2 Likes
11

Bsi ?

1 Like
12

Aye that’s them

1 Like
13

I’ve an hypothetical question ( which is by no means to do any evil as I love my hosting company).
Let’s say I am a client of a german company who has what I rent them located geographically in let’s say… Finland.

I am not doing anything they are not aware of (my provider) but how’s that bsi come into place?

If my comment is toxic feel free to wipe it.

14

Fair question. I’m far from an expert in German law but many things do translate in basic ways. With that I’m going to pull a completely uneducated theory from no where:

German company can be held accountable for laws in Germany while they reside in Germany, even if their execution is technically outside of the borders.

I know if I buy a server in another country and violate US law on it in a way that generates attention, I’m going to be arrested at my home on US soil. That’s what I base my theory on. Whether I rented it to someone else wouldn’t stop me from being held accountable.

1 Like
15

I mean why would BSI be interested in scanning some german provider ?
Let’s say they know what I do ( web crawling / execute a client / no coding and the crawler is as legit as google bot ).

16

My guess is they have tax dollars burning a hole in their pocket

1 Like
17

It’s just a stupid complaint. No idea why they keep doing it. I simply respond them that I don’t give a shit. Even proxmox services triggers it.

2 Likes
18

masking rpcbind leads to upgrade issues.
Keep in mind to unmask when upgrading packages.

1 Like
19

I disabled it on my proxmox machines, but masking it, results in upgrade failure.
A simple disable does the job fine.

1 Like
20

I’m used to Debian as well and since today I was tinkering with a Redhat distro in a KVM, I’ve noticed that this workaround doesn’t work: rpcbind still listens on 0.0.0.0:* and [::]:*
I’ve checked the /usr/lib/systemd/system/rpcbind.service where I found

EnvironmentFile=/etc/sysconfig/rpcbind
ExecStart=/usr/bin/rpcbind $RPCBIND_OPTIONS -w -f

and in /etc/sysconfig/rpcbind I’m presented with

#
# Optional arguments passed to rpcbind. See rpcbind(8)
RPCBIND_ARGS=""

Now comes the fun! No matter if you place RPCBIND_ARGS="-h 127.0.0.1" or OPTIONS="-h 127.0.0.1" or RPCBIND_OPTIONS="-h 127.0.0.1", rpcbind will always listen on 0.0.0.0:* and [::]:*

It’s a Poettering feature, you may ask? In the same /usr/lib/systemd/system/rpcbind.service there’s also

# Make sure we use the IP addresses listed for
# rpcbind.socket, no matter how this unit is started.

And in fact we need to look at /usr/lib/systemd/system/rpcbind.socket as well, where we find

ListenStream=0.0.0.0:111
ListenDatagram=0.0.0.0:111
ListenStream=[::]:111
ListenDatagram=[::]:111

So, no matter what we do to restrict addresses in rpcbind.service, rpcbind.socket has 0.0.0.0 and [::] “hardcoded”. Is this a feature? Yes, it is a feature (btw, the suggested workaround is incomplete: you need to edit rpcbind.socket, not rpcbind; also, the --full switch should be avoided and a drop-in configuration file should be preferred)

So, the Right Way® here should be:

  • systemctl edit rpcbind.socket

  • reset the default listening addresses and replace them (you need to reset them first or you’d simply be listing new addresses to add)

    [Socket]
    ListenStream=
    ListenDatagram=
    ListenStream=127.0.0.1:111
    ListenDatagram=127.0.0.1:111

  • systemctl daemon-reload and then systemctl restart rpcbind.socket

A drop-in systemd configuration file will “survive” subsequent updates, and will prevail on whatever the mantainer chooses to do.

I’ve never experienced such failures, probably Poettering would say that the mantainers are at fault here :wink: Tried gluster, not proxmox to be honest.
Sadly on subsequent upgrades the package can re-enable itself in some cases if it’s not masked. So IMHO you either firewall it (the advantage with Hetzner’s dedis is that you can apply a template to Rule Them All), or you go and make it listening on 127.0.0.1 only (as per Falzo’s suggestion, with some adjustments as needed…), or you run unmask and mask --now before and after the updates, if those are failing.

3 Likes