Sicherheit bei NFS

[Steffen M.]

Hallo,

ich habe eine Frage an diejenigen von Euch, die sich schon einmal -z.B. im Rahmen eines Admin-Jobs- mit dem Network File System (NFS) unter Unix/Linux und insbesondere den Sicherheitsaspekten etwas näher befasst haben.

Folgendes Problem: Ich bin gerade dabei, an meiner alten Schule einen Linux-Fileserver für Linux-Clients fit zu machen. Bislang arbeitet er ausschließlich als Samba-Server für Windows-Clients und authentifiziert einloggende Benutzer gegen ein OpenLDAP-Verzeichnis. Dort läuft die Sache so ab: Der User gibt unter Windows Benutzername und Kennwort ein, das Kennwort wird (wenn auch nur mäßig gut) verschlüsselt zum Server geschickt, und der gibt die angeforderte Ressource (z.B. das Home-Verzeichnis des Users) frei.

Nun soll ein neuer EDV-Raum eingerichtet werden, in dem ausschließlich Linux-Clients aufgestellt werden. Um Verzeichnisse eines Linux-Servers auf Linux-Clients "zugreifbar" zu machen, gibt man sie üblicherweise auf dem Server via NFS frei und mountet sie auf auf dem Client. So wird bei den meisten fertigen Schulserverprodukten stets "/home" per NFS exportiert, das dann auf den Clients importiert wird (z.B. "mount -t nfs server:/home /home" bzw. eben über die üblichen Einträge in "/etc/fstab", damit das Mounten vollautomatisch beim Booten funktioniert oder auch über "automount"). Die Authentifikation der Benutzer (Login) würde mittels PAM am OpenLDAP-Server erfolgen. Auch soweit kein Problem (und läuft in meiner Testumgebung bereits).

Mit anderen Worten: Der User loggt sich ein, der Client erfährt nach erfolgreichem Login vom OpenLDAP-Server die numerische User-ID (z.B. 1000) und das Home-Verzeichnis des Users (z.B. "/home/steffen"). Auf Grund der gesetzten Verzeichnisrechte darf der User mit der User-ID eben nur in diesem Verzeichnis lesen und schreiben.

So weit, so gut. Zu Hause nutze ich NFS seit Langem, um von einem Linux-Rechner auf den anderen zugreifen. Mit der Performance und der Einfachheit der Konfiguration mittels "/etc/exports") bin ich auch durchaus zufrieden.

Allerdings stört mich beim Einsatz dieses Verfahrens in einem mittelgroßen Schulnetz (insgesamt ca. 100 Clients, davon zukünftig ca. 1/4 Linuxbasiert) dann doch erheblich die Tatsache, dass die eigentliche Zugriffssteuerung rein auf dem Client erfolgt. Der Client entscheidet, ob "steffen" nur in "/home/steffen" oder auch im Home-Verzeichnis von "hans" ("/home/hans") lesen und schreiben darf oder nicht. Der Client hat permanent das komplette "/home" des Servers gemountet und allein der Client muss dafür sorgen, dass nichts "Böses" passiert. Der Server kann lediglich auf IP- (und zur Not auf MAC-) Ebene regeln, an welche Clients er "/home" exportiert und an welche nicht. Mehr Steuerungsmöglichkeit hat der Server aber bei NFS bis einschl. Version 3 des NFS nicht.

Und genau da liegt der Haken: Zwar kann ich einen eigenen Client noch halbwegs brauchbar absichern. Allerdings kommt es im Zeitalter der Notebooks immer wieder vor, dass sich $beliebiger_Schüler_mit_Notebook einen Rechner im Rechnerraum aussteckt und stattdessen sein Notebook einsteckt - natürlich nicht legal, aber es ist eben trotz Aufsicht nicht immer vermeidbar. Wenn jetzt der Schüler noch die selbe IP des vorher eingesteckten Schulrechners am Notebook setzt, dann hat natürlich die Berechtigung das ganze "/home" vom Server zu mounten. Er wird aber nicht dazu gezwungen, gegen das OpenLDAP-Verzeichnis des Servers zu authentifizieren. Vielmehr legt er sich auf seinem Notebook einen lokalen User mit der User-ID 1000 an und prompt hat er Zugriff auf das vom NFS-Server gemountete "/home/steffen". Mit anderen Worten: Ein User mit eigenem Rechner (auf dem er sozusagen "root" ist) kann jederzeit sich "/home" mounten und darin machen, was er möchte.

Diese Problematik ist natürlich nicht neu, es gibt durchaus Ansätze zur Abhilfe, bekannt sind mir bislang diese:

• "NFS 4" bietet daher eine Art Berechtigungsticket-System basierend auf Kerberos an. Das ist mir aber "mit Kanonen auf Spatzen geschossen" - schließlich ist es ja auch irgendwo nur ein Schulnetz und mir fehlt die Zeit, mich jetzt noch in Kerberos einzulesen, nachdem ich mich schon in LDAP eingearbeitet habe und dort noch nicht so wirklich fertig mit der Umsetzung bin.
  
  
• Der Ansatz "SNFS" soll NFS quasi durch SSH tunneln. Hört sich nicht schlecht an, die Frage ist: Löst das mein Problem wirklich oder sichert "lediglich" die Übertragung ab, sodass diese nicht mehr im Klartext erfolgt und abhörbar ist?
  
  
• Man könnte die Linux-Clients natürlich auch via "smbclient" auf den Samba-Server zugreifen lassen. Wie gut läuft das in der Praxis? Gibt es (Locking-)Probleme mit bestimmten Anwendungen?

Fragen über Fragen. Mich würde interessieren: Hat von Euch jemand Praxis-Erfahrung in diesem Bereich? Falls ja: Kann er oder sie vielleicht etwas darüber berichten oder gibt es noch weitere Lösungsansätze, die ich übersehen habe? Oder bin ich zu paranoid? Andererseits - wenn man so leicht an alle User-Verzeichnisse rankommt, ist das schon "nicht ganz ohne".

Ich bedanke mich im Voraus für alle Tipps und Hinweise, die mich in der Sache weiterbringen!

Viele Grüße,
Steffen

[sad]

Der Server kann lediglich auf IP- (und zur Not auf MAC-) Ebene regeln, an welche Clients er "/home" exportiert und an welche nicht.

Würde eine einfache MAC Authentifizierung nicht reichen? Ist jetzt nicht sonderlich sicher, aber wäre das einfachste.


Wenn ich eine Frage stellen darf: bist du ein Schüler mit Admin Funktion, oder was anderes?

Es ist typisch für Schulen Geld für die neusten (meistens sinnlosen) Rechner auszugeben, jedoch kein deut in die Infrastruktur zu investieren.

Ich denke nicht, dass du hier sehr viel Antworten auf deine Frage bekommen wirst...

[cutie]

[*]Der Ansatz "SNFS" soll NFS quasi durch SSH tunneln. Hört sich nicht schlecht an, die Frage ist: Löst das mein Problem wirklich oder sichert "lediglich" die Übertragung ab, sodass diese nicht mehr im Klartext erfolgt und abhörbar ist?

Ich bin mir da jetzt nicht wirklich sicher, aber klingt für mich sehr nach ner reinen verschlüsselung um die Daten abhörsicher zu machen...
Müsste man wissen wie der ssh Key getauscht wird. Allein daran hängt die sicherheit!
Also wenn sich der Client nochmal mit dem Key "autorisiert" funktioniert das. Wenn der Key aber irgendwie gegenseitig erzeugt wird (z.b. via Diffie-Hellman) wovon ich eher ausgehe, isses quatsch.

Das mit dem MAC-Filter hätt ich nu auch vorgeschlagen. Is halt echt nit besonders sicher.

Wenn ich unsrem Admin an der FH übern Weg renn heut werd ich ihn ma fragen, was die nutzen.

[Steffen M.]

Würde eine einfache MAC Authentifizierung nicht reichen? Ist jetzt nicht sonderlich sicher, aber wäre das einfachste.

Das wäre durchaus eine Maßnahme, d.h. ich würde den Cisco-Switch, an dem die Clients des Raumes hängen, einfach alle Ethernet-Frames mit unbekannter MAC wegschmeißen lassen. Dass es durchaus schon Schüler gab, die wussten, wie leicht man MACs faken kann, steht auf einem anderen Blatt (die meisten wissen das, weil sie sich zu Hause WLANs einrichten). Meine Devise ist dabei aber, solchen Schülern anzubieten, in der Netzbetreuung mitzuwirken - das bringt meist mehr, als sie gegen sich zu haben.

Dennoch ärgert's mich ein wenig, dass es so direkt keine einfache Alternative zu NFS gibt - mich interessiert einfach mal, wie das z.B. in anderen Schulen oder in kleineren Firmennetzen gemacht wird.

MAC-Filter wäre dann einfach ein Notbehelf.

Wenn ich eine Frage stellen darf: bist du ein Schüler mit Admin Funktion, oder was anderes?

So fing ich an. Das war 1996, da war ich in der zehnten Klasse. Heute bin ich Student (Informatik) kurz vor dem Abschluss und betreue ehrenamtlich (gegen eine geringe Aufwandsentschädigung durch den Förderverein) das Netz (insbesondere die Server) an meiner ehemaligen Schule, das meiste geht ja dank SSH bequem remote.

Es ist typisch für Schulen Geld für die neusten (meistens sinnlosen) Rechner auszugeben, jedoch kein deut in die Infrastruktur zu investieren.

In der Tat. Das ist etwas, was ich seit Jahren kritisiere. Da ist leider aber auch bei den Schulträgern Einiges im Argen.

Ich denke nicht, dass du hier sehr viel Antworten auf deine Frage bekommen wirst...

Dem bin ich mir durchaus bewusst - ich poste das nachher auch noch im Usenet. Ich dachte einfach, dass es vielleicht auch hier den einen oder anderen geben könnte, der von der eigenen Schule oder Firma her etwas Einblick in die Infrastruktur hat und vielleicht sagen kann: "Ja, wir nutzen auch NFS, wir sind uns dessen bewusst und wir filtern auf MAC-Ebene" oder "Wegen dieser Problematik nutzen wir auch auf Unix-/Linux-Clients die Samba-Freigaben und kein NFS" oder "Huch, NFS - ist das unsicher?".

Man muss, wenn man im Usenet fragt, nämlich auch aufpassen - es gibt ein paar alte Hasen, die bei NFS das Problem nicht sehen (wollen?). Sie sagen: Ich als Admin müsste halt Kontrolle über meine Rechner und User haben - dann sei NFS sicher und performant. Dann kommen so Vergleiche wie: Ja, wenn jemand die Platte aus einem Client ausbaut, sie in einen eigenen Rechner hängt und dort ein neues "root"-Passwort setzt, sie anschließend wieder zurückbaut, dann kann derjenige auch "root" werden und hat in die fremden NFS-Verzeichnisse Einsicht. Nur, dass mal kurz ein Lehrer oder Schüler sein Notebook irgendwo einsteckt, ist einfach wahrscheinlicher als dass jemand einen Rechner zerlegt.

Ansonsten schaue ich mir mal SNFS näher an. Vielleicht kann man da ja auf den berechtigten NFS-Clients einen Schlüssel eines vom Server erzeugten Schlüsselpaars ablegen und zwar so, dass nur "root" Leserechte auf die Schlüsseldatei hat. Fährt ein Client hoch, dann wird "/home" nur gemountet, wenn eine SSH-Connection zum Server aufgebaut werden kann und dies dürfte dann nur gelingen, wenn dem Client eben der passende Schlüssel bekannt ist. Das wäre immerhin eine Maßnahme, die so lange sicher ist, bis jemand die Platte ausbaut oder den lokalen "root" irgendwie (z.B. durch Ausnutzen einer Sicherheitslücke) "hackt". Und mit dem Maß an Sicherheit könnte ich gut leben.

Auf jeden Fall einmal Danke für Deine Antwort!

Grüße,
Steffen

[Steffen M.]

Ich bin mir da jetzt nicht wirklich sicher, aber klingt für mich sehr nach ner reinen verschlüsselung um die Daten abhörsicher zu machen...
Müsste man wissen wie der ssh Key getauscht wird. Allein daran hängt die sicherheit!
Also wenn sich der Client nochmal mit dem Key "autorisiert" funktioniert das.

Genau das wäre auch meine Überlegung. Dann gibt man am NFS-Server nur für "127.0.0.1" frei und tunnelt durch SSH, lässt aber nur Clients rein, die einen Teil eines Schlüsselpaars besitzen, von dem der Server den anderen Teil hat.

Wenn ich unsrem Admin an der FH übern Weg renn heut werd ich ihn ma fragen, was die nutzen.

Cool, das wäre sehr nett! Auch Dir vielen Dank für Deine Antwort!

Viele Grüße,
Steffen

[schnuffelhase]

wir benutzen nur noch samba....aber ist natürlich auch die frage, wie sich die leute authentifizieren? hat da jeder seinen eigenen login?
so find ichs eigentlich am geschicktesten...jeder kriegt nur sein eigenes home-dir gemounted und das wars. jeder ist für seinen acc verantwortlich.

[Steffen M.]

wir benutzen nur noch samba....

Auch auf Linux-Clients, also "smbmount"?

aber ist natürlich auch die frage, wie sich die leute authentifizieren? hat da jeder seinen eigenen login?

Ja, das machen wir schon seit langem (genauer gesagt: seit 1999, wenn ich mich richtig erinnere). Kein Arbeiten mit "Platz-Accounts" und ähnlichen unsauberen Lösungen. Wir geben unseren Schülern auch Mailadressen - quasi als Abfallprodukt, wenn wir eh schon personenbezogene Accounts einrichten.

Auch Dir vielen Dank und viele Grüße,

Steffen

[schnuffelhase]

ok, falschaussage.

wir benutzen im geschäft einen automount-daemon und gleichzeitig noch auf der maschine einen samba-server...!
der samba als schnittstelle für die windows-leute und der automount-daemon für die anderen unix-maschinen mit NFS...
hört sich eigentlich auch logischer an!

(hab zwar gedacht NFS soll hier abgeschafft werden, war aber dann doch ne falschinformation)

[Steffen M.]

ok, falschaussage.

wir benutzen im geschäft einen automount-daemon und gleichzeitig noch auf der maschine einen samba-server...!
der samba als schnittstelle für die windows-leute und der automount-daemon für die anderen unix-maschinen mit NFS...
hört sich eigentlich auch logischer an!

Ah ja. Okay. Das dürfte die weitaus verbreitetere Variante sein. Gut, das "smbmounten" eines Samba-Servers müsste wohl schon auch gehen.

Ich schau mir jetzt, sobald ich dazu komme, erstmal SNFS an.

Gruß,
Steffen

[Steffen M.]

Nur als Rückmeldung für die, die mir damals geantwortet haben: Der EDV-Raum mit den Linux-Clients ist inzwischen am Laufen und wird bereits im Unterricht genutzt. Als Distribution kommt "Edubuntu" zum Einsatz (ein "Ubuntu"-Derivat für Schulen).

Wir setzten jetzt letztendlich auf SNFS für die Home-Verzeichnisse, sodass ein Schüler per Laptop eben nicht an die Home-Verzeichnisse anderer User rankommt (denn er kennt den Key zum Login als "snfs"-User auf dem Fileserver nicht).

Die Performance ist natürlich nicht so hoch wie bei NFS, da alle Nutzdaten verschlüsselt übers Netz gehen. Der Server verkraftet's aber gut (ist eine schnelle Opteron-Maschine). Dennoch haben wir SNFS auf die Home-Verzeichnisse beschränkt. Freigaben, die sowieso frei zur allgemeinen Datenablage verfügbar sind, werden per normalem NFS (und LDAP-gesteuertem Automount) abgewickelt. Dieses Risiko kann man eingehen, denn wer dort persönliche Daten ablegt, macht sie eh im Schulnetz öffentlich.

Nochmals Danke und Grüße,

Steffen