Grundlegende NFS-Sicherheit – NFS, no_root_squash und SUID

Ich bin auf viele weit geöffnete NFS-Server gestoßen, die mit ein paar schnellen Änderungen ein wenig sicherer und sicherer gemacht werden könnten. Dies ist eine schnelle Anleitung, um die Dinge ein bisschen sicherer zu machen. Dies ist keineswegs eine vollständige Anleitung zum Sichern von NFS, aber es kann die Dinge ohne großen Aufwand ein wenig sicherer machen. Um zu einer anderen Ebene zu gelangen, sollten Sie sich die Implementierung von NFSv4 und Kerberos ansehen.

Zu den grundlegenden Optionen für den Export können gehören:

• no_all_squash :Diese Option deaktiviert jegliches Squashing.
• w :Diese Option ermöglicht es dem NFS-Server, sowohl Lese- als auch Schreibanforderungen auf einem NFS-Volume zu verwenden.
• ro :Diese Option ermöglicht es dem NFS-Server, schreibgeschützte Anfragen auf einem NFS-Volume zu verwenden.
• synchronisieren :Diese Option ermöglicht es dem NFS-Server, Anfragen erst zu beantworten, nachdem die Änderungen in den stabilen Speicher übertragen wurden.
• asynchron :Diese Option ermöglicht es dem NFS-Server, gegen das NFS-Protokoll zu verstoßen und auf Anfragen zu antworten, bevor Änderungen an den stabilen Speicher übertragen wurden.
• sicher :Diese Option erfordert, dass Anfragen von einem Internet-Port stammen.
• unsicher :Diese Option akzeptiert beliebige oder alle Ports.
• wdelay :Diese Option ermöglicht es dem NFS-Server, eine Schreibanfrage auf eine Disc zu verzögern, wenn er vermutet, dass eine andere zugehörige Schreibanfrage im Gange ist oder bald eintreffen wird.
• no_wdelay :Mit dieser Option kann der NFS-Server zulassen, dass mehrere Schreibanforderungen innerhalb eines einzigen Vorgangs auf die Disc übertragen werden. Diese Funktion kann die Leistung verbessern, aber wenn ein NFS-Server viele kleine Anfragen erhält, kann dieses Verhalten die Leistung beeinträchtigen. Sie sollten sich darüber im Klaren sein, dass diese Option keine Wirkung hat, wenn auch async eingestellt ist.
• subtree_check :Diese Option aktiviert die Teilbaumprüfung.
• no_subtree_check :Diese Option deaktiviert die Teilbaumprüfung, die einige implizite Sicherheitsprobleme mit sich bringt, aber die Zuverlässigkeit verbessern kann.
• anonuid=UID :Diese Optionen legen ausdrücklich die uid und gid des anonymen Kontos fest; Dies kann nützlich sein, wenn Sie möchten, dass alle Anfragen so aussehen, als ob sie von einem einzigen Benutzer stammen.
• anongid=GID :Diese Option deaktiviert anonuid=UID.

Was ist root_squash?

root_squash erlaubt dem Root-Benutzer auf dem Client, als Root auf den NFS-Server zuzugreifen und Dateien auf dem NFS-Server zu erstellen. Technisch gesehen zwingt diese Option NFS dazu, das Root-Konto des Clients in eine anonyme ID zu ändern, was die Sicherheit erhöht, indem verhindert wird, dass der Besitz des Root-Kontos auf einem System auf das andere System migriert. Dies ist erforderlich, wenn Sie Root-Dateisysteme auf dem NFS-Server hosten (insbesondere für plattenlose Clients); In diesem Sinne kann es für ausgewählte Hosts (sparsam) verwendet werden, aber Sie sollten no_root_squash nicht verwenden, es sei denn, Sie sind sich der Konsequenzen bewusst.

SUID und NFS

suid ist eine Methode, bei der ein Benutzer die Rechte des Eigentümers einer Datei annimmt, wenn sie vom Benutzer ausgeführt wird. Warum interessiert mich das? Stellen Sie sich vor, ein Benutzer wäre in der Lage, eine Datei auf das NFS-Volume zu kopieren, das Suid-Bit auf der Datei zu aktivieren und das dann auf dem NFS-Server oder -Client auszuführen, wodurch er sich selbst effektiv zum Root erhebt?

Hier ist ein Beispiel, das die Risiken demonstriert.

Der Hostname des NFS-Servers ist server, der Hostname des NFS-Clients ist client. Das Subnetz im Beispielnetzwerk ist 192.168.1.0/24. Dieses Beispiel geht auch davon aus, dass auf beiden Systemen dieselben Betriebssystemversionen ausgeführt werden (d. h. beide sind RHEL 7 oder beide SLES 12), solange die Hauptversionen des Betriebssystems übereinstimmen.

1. Erstellen Sie auf einem NFS-Server ein temporäres Verzeichnis (/export/test) und exportieren Sie es mit den folgenden Optionen (ersetzen Sie 192.168.1.0/255.255.255.0 durch Ihr eigenes Netzwerk/Ihre eigene Netzmaske):

server# vi /etc/exports
/export/test  192.168.1.0/255.255.255.0(no_root_squash,insecure,rw)

2. Starten Sie den NFS-Server neu. Dies hängt von der Linux-Variante ab.

RHEL:

server# systemctl restart nfs

SUSE:

server# systemctl restart nfsserver

3. Mounten Sie auf dem Client-Rechner den Export:

client# mkdir /mnt/nfstest
client# mount -t nfs server:/export/test /mnt/nfstest

4. Kopieren Sie auf dem Client als Root-Benutzer die vi-Binärdatei in den NFS-Mount.

client# which vi
—— output ———
/usr/bin/vi

client# cp /usr/bin/vi /mnt/nfstest

5. Setzen Sie das Suid-Bit auf die kopierte Binärdatei.

client# chmod u+s /mnt/nfstest/vi

6. SSH auf dem NFS-Server als nicht privilegierter Benutzer. Führen Sie als nicht privilegierter Benutzer das vi aus, das sich im exportierten Mount auf dem Server befindet:

server$ /export/test/vi /etc/passwd

7. Suchen Sie das nicht privilegierte Konto in der Kennwortdatei und ändern Sie die UID auf 0, speichern Sie, melden Sie sich ab und melden Sie sich dann als nicht privilegierter Benutzer an. Der Benutzer ist jetzt root.

Dasselbe funktioniert auf dem Client, wenn Sie das vi vom NFS-Mount als normaler Benutzer ausführen, können Sie es auf jede Datei auf dem Host verweisen und als root bearbeiten. Es funktioniert mit jeder erdenklichen Binärdatei.

Wie vermeide ich das?

1. Löschen Sie zuerst die vi-Datei aus dem Exportverzeichnis :), dann aktivieren Sie root_squash auf den nfs-Export. Bearbeiten Sie auf dem Server erneut /etc/exports und ändern Sie no_root_squash in root_squash:

server# vi /etc/exports
/export/test  192.168.1.0/255.255.255.0(root_squash,insecure,rw)

2. Starten Sie den NFS-Server neu, mounten Sie das Dateisystem auf dem Client neu:

server# systemctl restart nfs

client# umount /mnt/test
client# mount -t nfs server:/export/test /mnt/nfstest

3. Erstellen Sie vom Client aus als Root einige Dateien auf dem NFS-Mount und überprüfen Sie die Berechtigungen:

client# touch /mnt/nfstest/{test1,test2,test3}

Abhängig von den auf /export/test eingestellten Berechtigungen wird Ihnen entweder die Berechtigung verweigert oder wenn das Verzeichnis weltweit beschreibbar ist, sehen die Berechtigungen für die Dateien ähnlich aus wie:

-rw-r--r--  1 65534  65534     0 Nov  6  2015 test1
-rw-r--r--  1 65534  65534     0 Nov  6  2015 test2
-rw-r--r--  1 65534  65534     0 Nov  6  2015 test3

root_squash ordnet die Root-UID der UID eines anonymen Benutzers zu. Diese UID ist in der Exportdatei konfigurierbar, man /etc/exports für weitere Informationen. Kopieren Sie den vi-Befehl erneut (falls zulässig) als root auf dem Client auf das nfs-Volume und wiederholen Sie die obigen Schritte (ssh to server run vi on /etc/passwd). Dieses Mal haben Sie keine Berechtigung zum Speichern der Datei, die Berechtigungen werden auf ein nicht privilegiertes Konto erhöht.

Das ist etwas sicherer, aber wir sind noch nicht fertig. Ein weiterer Schritt, den Sie unternehmen können, besteht darin, das exportierte Dateisystem mit der Option nosuid auf dem NFS-Server einzuhängen.

server# vi /etc/fstab

4. Suchen Sie den Einhängepunkt für /export/, ändern Sie die Standardwerte der Optionsspalte in.

/dev/mapper/sys_vg-export_lv     /export    ext3    defaults      0       0
/dev/mapper/sys_vg-export_lv     /export    ext3    nosuid        0       0

5. Montieren Sie die Halterung erneut:

server# mount -o remount /export

6. Speichern Sie die vi-Datei auf dem Mount, setzen Sie das suid-Bit, wechseln Sie zu einem nicht privilegierten Konto und versuchen Sie es erneut:

server# cp /usr/bin/vi /export/test; chmod u+s /export/test/vi

server# su - someuser
server$ /export/test/vi /etc/passwd

Nachdem Sie eine Änderung an der übergebenen Datei vorgenommen haben, können Sie die Änderung nicht speichern.

7. Springen Sie als nicht privilegierter Benutzer auf den Client und versuchen Sie dasselbe:

client$ /export/test/vi /etc/passwd

Es funktioniert immer noch, der Client muss auch mit der nosuid-Option neu gemountet werden:

client# mount -t nfs -o nosuid server:/export/test /mnt/nfstest

Testen Sie es erneut mit dem nicht privilegierten Konto, es sollte fehlschlagen.

Es gibt ein paar andere Optionen, die auf dem Einhängepunkt angegeben werden können, um weiter einzuschränken, was von ihnen ausgeführt werden kann, sehen Sie sich noexec (keine ausführbaren Dateien) und nodev (keine Gerätedateien) an. Wenn weitere Sicherheit erforderlich ist, sehen Sie sich Kerberos und NFSv4 an.