Sichern von NFS gegen SSH-Tunneling

Ich habe müßig http://nfs.sourceforge.net/nfs-howto/ar01s06.html gelesen und versucht zu verstehen, warum Localhost-Exporte schlecht waren, als ich zum Abschnitt "6.4. Tunneln von NFS durch SSH" kam. Alles in diesem Abschnitt darüber, dass es sich um eine mögliche Sicherheitslücke beim Exportieren von localhost handelt, da es anderen ermöglicht, den SSH-Port weiterzuleiten und auf die Freigabe zuzugreifen, war sinnvoll.

Hier ist meine Frage: Wie kann man verhindern, dass SSH-Tunnel die Sicherheit eines Systems untergraben, wenn Benutzer SSH auf einem Computer ausführen können, der eine Verbindung zu einem NFS-Server herstellen kann? Stellen Sie sich zum Beispiel die Computer A ( 192.168.1.1), B ( 192.168.1.2) und C ( 192.168.1.3) vor. Sei A der Server mit der folgenden Exportdatei:

/home 192.168.1.2(rw)

Wie Sie sehen können, erteilt A B die Erlaubnis, die Freigabe / home zu verwenden. Lassen Sie nun C ssh in B mit:

$ ssh 192.168.1.2 -L 250:192.168.1.1:2049  -f sleep 60m
$ ssh 192.168.1.2 -L 251:192.168.1.1:32767 -f sleep 60m

Es scheint, dass die nach B exportierten Anteile von A für jeden anfällig sind, der in B ssh kann. Ist dies der Fall? Gibt es eine andere Möglichkeit, sich dagegen zu schützen, als nur sicherzustellen, dass jeder, der sich bei B anmelden kann, ein sehr vertrauenswürdiger Benutzer ist?

Das ist ein sehr altes Dokument, in dem Sie über die Kernel-Version 2.4 sprechen, die 2001 veröffentlicht wurde. In den letzten 12 Jahren haben sich viele Änderungen ergeben. Obwohl einige Dinge gleich bleiben.

Ich habe nur CentOS 6.x-Boxen zum Spielen, die standardmäßig nfsv4 verwenden. Um die Verbindung über einen Zwischencomputer zu ermöglichen, musste ich das Dateisystem mit insecureset exportieren .

Um Ihre Frage zu beantworten, verwenden Sie nfsv4 und den Standardmodus secure. Wenn Sie über ausreichende Berechtigungen für B verfügen, können Sie diese auch festlegen

AllowTcpForwarding no

in seiner / etc / ssh / sshd_config.

Wie immer, wenn Sie mit Sicherheit Menschen Privilegien gewähren, müssen Sie ihnen vertrauen.

Das Problem, das Sie hervorheben, ist kein Fehler, sondern eine Funktion! Ja, es ist eine Funktion des SSH-Protokolls und die Tatsache, dass ein falsch konfigurierter SSH-Dienst für eine Vielzahl von Exploits verwendet werden kann, wie z.

• Host-Firewalls umgehen
• IP-Einschränkungen umgehen
• Fernzugriff auf Dienste, die nur auf 'localhost'-Schnittstellen lauschen [ mysql?]

Als Beispiel für häufige Fehlkonfigurations- und Sicherheitsprobleme verhindert das Festlegen der /sbin/nologinShell für einen Benutzer nicht, dass SSH-Tunnel mit den meisten Standardkonfigurationen für den OpenSSH-Dämon erzeugt werden!

Gemäß Ihrer Frage sollten Sie NFSv2 / NFSv3 vermeiden und sich für das sicherere NFSv4 entscheiden, das sich in Richtung eines anderen Sicherheitsmodells verschiebt, bei dem einzelne Benutzer anstelle der Hostcomputer authentifiziert werden. Alternativ können Sie das SSH-Tunneln für normale Benutzer verbieten, indem Sie den OpenSSH-Dienst ordnungsgemäß konfigurieren.

Dieses Dokument ist ziemlich alt (2006!). Wenn keine besseren Sicherheitsmechanismen (z. B. NFSv4 + GSS) vorhanden sind, bedeutet das Hinzufügen eines Hosts zu Exporten, dass Sie diesem Host, seinen Benutzern und Prozessen implizit vertrauen.

SSH-Portweiterleitung ist nicht Ihr einziges Problem, Sie können es nicht zulassen (sshd's AllowTcpForwarding no), aber wie sshd_config(5)gesagt

Beachten Sie, dass das Deaktivieren der TCP-Weiterleitung die Sicherheit nur verbessert, wenn Benutzern auch der Shell-Zugriff verweigert wird, da sie jederzeit ihre eigenen Weiterleitungen installieren können.

So fügen Sie die Liste socat, netcat, SOCKS (OpenSSH unterstützt das auch, obwohl nur TCP), OpenSSH - tunTunneling und sogar bashmit seiner /dev/tcpUnterstützung und Sie das Problem nicht ... zu viele , um Liste.

Wenn B über eine Host-Firewall verfügt, die Regeln pro Benutzer zulässt (z. B. Linux / iptables mit --uid-owner), können Sie B möglicherweise sperren, damit A ihm mehr vertrauen kann. Versuchen Sie andernfalls NFSv4 mit GSS und Kerberos, wodurch Sie dem Benutzer Vertrauen schenken.

Dies ist leicht zu besiegen

1. Stellen Sie sicher, dass Ihre Exporte markiert sind secure
2. Kein Zugriff von Root auf Computer B durch Computer C.

Die Manpage für exports(5)sagt:

secure
This option requires that requests originate on an internet port
less than IPPORT_RESERVED (1024). This option is on by default. 
To turn it off, specify insecure.

Beachten Sie, dass dies standardmäßig aktiviert ist.

Jeder Benutzer, der eine Verbindung von Computer C zu Computer B herstellt, stellt eine Verbindung als normaler Benutzer her. Die von Ihnen beschriebenen über SSH weitergeleiteten NFS-Verbindungen scheinen von einem Prozess zu stammen, der auf B als diesem Benutzer ausgeführt wird. Dies bedeutet, dass die Verbindung den üblichen Sicherheitskontrollen für B unterliegt, insbesondere, dass normale Benutzer keine Verbindungen von Ports unter 1024 herstellen können.

Auf einem meiner Systeme getestet, sehe ich Folgendes:

djs@tuonela:~$ sudo mount -o port=250,mountport=251,tcp localhost:/srv/users /mnt/x -t nfs
mount.nfs: access denied by server while mounting localhost:/srv/users

Natürlich kann jeder, der sein Konto auf Root auf Computer B erhöhen kann, diesen Schutz aufheben. Daher müssen Sie NFS-Client-Computer ausreichend sperren.