rpcbind (früher Portmap, Port 111) sicherer machen

Einleitung:

Ich verwende häufig das NFS-Dateisystem zwischen Servern desselben internen Netzwerks. Aber weil es als unsicher angesehen wird, rpcbind für das Internet offen zu haben, musste ich es schützen. Ich hätte dies auch mit der Firewall machen können, aber da ich den einzigen Dienst, den ich vor Internetzugriffen schützen wollte, nicht mit der Firewall beschäftigen wollte, entschied ich mich dafür, stattdessen die guten alten System-TCP-Wrapper zu verwenden: hosts.allow und hosts.deny Dateien.

Methode:

– Allen Zugriff auf rpcbind verweigern (ausgeführt in /etc/hosts.deny )
– 2 Ausnahmen zulassen:Hosts in meinem lokalen Netzwerk (ausgeführt in /etc/hosts.allow )

Annahmen:

Der NFS-Server ist mit dem Internet und unserem internen LAN (192.168.100.0/24) verbunden und hat die IP:12.34.56.78 (nur ein Beispiel) und 192.168.100.1.
Die 2 Hosts, die ich zulassen möchte Verbindung zum NFS-Server sind 192.168.100.2 und 192.168.100.3
Ich habe einen weiteren Server (192.168.100.4) in diesem privaten LAN, der sich nicht mit dem NFS-Server verbinden darf.

Schritte:

Bearbeiten (oder erstellen Sie falls nicht vorhanden) die Datei /etc/default/rpcbind und fügen Sie die folgende Zeile hinzu:
OPTIONS="-w -l -h 192.168.100.1"
Bearbeiten Sie die Datei /etc/hosts.allow und fügen Sie die folgende Zeile hinzu:
rpcbind: 192.168.100.2 192.168.100.3
Bearbeiten Sie die Datei /etc/hosts.deny und fügen Sie die folgende Zeile hinzu:
rpcbind: ALL

Überprüfen der Konfiguration:

Melden Sie sich bei einem beliebigen anderen Server im selben lokalen LAN-Netzwerk an (keinen der oben erlaubten Server), sagen wir von 192.168.100.4, und geben Sie den folgenden Befehl ein:
rpcinfo -p 192.168.100.1
Ausgabe:
rpcinfo: can't contact portmapper: rpcinfo: RPC: Authentication error; why = Client credential too weak
Melden Sie sich dann bei einem beliebigen Internetserver an (z. B. bei 45.67.78.89) und versuchen Sie den Befehl:
rpcinfo -p 12.34.56.78
Ausgabe:
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
Melden Sie sich jetzt bei einem der 2 zugelassenen Server an (z. B. 192.168.100.3) und geben Sie den Befehl ein:
rpcinfo -p 192.168.100.1
Ausgabe:
rpcinfo -p 192.168.100.1
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 49123 status
100024 1 tcp 55198 status
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
....... and so on

Good news: Wir können sehen, dass 192.168.100.4 und andere Internetserver keine Verbindung zu rpcbind herstellen dürfen, aber 192.168.100.3 ist erlaubt.

Zusätzliche Informationen:

Lassen Sie uns nur zum Spaß die Protokolle überprüfen:
grep rpcbind /var/log/auth.log
Ausgabe:
Oct 7 20:51:30 nfsserver rpcbind: connect from 192.168.100.4 to dump(): request from unauthorized host
Oct 7 20:51:56 nfsserver rpcbind: connect from 45.67.78.89 to dump(): request from unauthorized host
Oct 7 20:53:24 nfsserver rpcbind: connect from 192.168.100.3 to dump()
Überprüfen wir nun die TCP-Wrapper-Konfiguration für den Host 192.168.100.2
tcpdmatch rpcbind 192.168.100.2
Ausgabe:
client: address 192.168.100.2
server: process rpcbind
access: granted

Ergebnis:
rpcbind Der Dienst ist jetzt geschützt und nur von den 2 Servern zugänglich, die mit unserem internen LAN verbunden sind.