Die Serverdienste NFS und NIS

(3022 Worte insgesamt im Text)
(15280 mal aufgerufen)  Druckerfreundliche Ansicht [1]

Inhalt

Was ist NFS?

NFS, das "Network File System", ist eine Client-/Server-Applikation, welche entfernte Laufwerke (von einem Server) für den lokalen Rechner (den Client) transparent zur Verfügung stellt. Der Nutzer bekommt im Normalfall überhaupt nicht mit, das er seine Daten gar nicht "lokal" speichert oder läd sondern sie über das Netzwerk zum Server übertragen und von dort geladen werden. Dafür werden verschiedene Programme genutzt, die für eine konsistente Dateiübertragung sorgen.

NFS basiert auf dem RPC (remote procedure call) Protokoll, welches ursprünglich 1980 (!) von Sun Microsystems entwickelt wurde, um Filesharing auf Unix-Plattformen zu ermöglichen.

Was ist die Gefahr von NFS?

Normalerweise benutzen die von NFS eingesetzten Programme keine weiteren Mittel um die Authentizität der Benutzer zu überprüfen. Das macht das System so gefährlich.

Einerseits ist hierfür sicherlich das benutzte Übertragungsprotokoll UDP verantwortlich, welches als "zustandsloses" Protokoll keine Möglichkeit bietet, die Verbindung zwischen zwei Stationen zu überprüfen. Das macht das UDP-Protokoll zwar wesentlich schneller als das heute sehr bekannte TCP Protokoll und war seinerzeit sicherlich auch der Hauptgrund für Sun Micosystems auf diese Übertragungstechnik zu setzen (weniger "Protokoll" = weniger Serverbelastung) - allerdings mussten so auch zusätzliche Sicherungsmassnahmen eingeführt werden, um auch nur eine sichere Übertragung der Pakete sicherzustellen: so versucht NFS für jeden ausgesendeten Befehl eine Anwort zu bekommen. Bleibt diese aus, so wird der Befehl immer wieder wiederholt. (Anmerkung: bei TCP ist das Verfahren zwar ähnlich - setzt aber schon auf "Protokollebene" an; der das Protokoll nutzende Dienst braucht sich darum nicht zu kümmern.)

Inzwischen gibt es auch NFS über TCP - aber dennoch bleibt die Tatsache bestehen, dass es bei NFS am Server keine Möglichkeit gibt, die Authentizität des Clients und noch weniger dessen Nutzer zu überprüfen. In Umgebungen, in welchen keine unbekannten Clients "Zutritt" haben und in welchen allein der Administrator Vollzugriff (root-Rechte) auf den Clients hat, ist das Problem evtl. noch überschaubar. Aber auch hier läßt sich die Sicherheit von NFS umgehen, wenn etwa ein Client über CD oder USB gebootet werden kann.

Was für Programme enthält NFS?

NFS ist nicht nur ein Protokoll für Dateiübertragungen im Netzwerk - es enthält zusätzlich ein "Mount"-Protokoll, welches auf Serverseite mehrere Programme nutzt:

Auf der Client-Seite kommen ebenfalls mehrere Programme zum Einsatz:

Wie wird NFS konfiguriert?

Serverseite:

Die zentrale Konfigurationsdatei für NFS ist hier die Datei exports, welche sich überlicherweise im Verzeichnis /etc befindet.

Dort wird genau definiert, welche Verzeichnisse des Servers von welchem Client wie gemountet werden dürfen. Dies kann durch eine Namensangabe geschehen oder durch einen IP-Adressbereich. Das "wie" beschreibt, wie der Client das Verzeichnis nutzen kann. Mögliche Formen sind hier z.B. "read-only" oder "read-write". Zusätzlich lassen sich noch einige Sicherheitsattribute setzen:

async Diese Option ermöglicht es dem NFS-Server, das NFS-Protokoll zu verletzen, indem er dem Client auf Anfragen antwortet, befor diese wirklich geschrieben worden sind. Wenn also ein Client die Anfrage stellt, eine Datei zu schreiben, speichert der NFS-Server die Daten in RAM und schreibt diese erst dann auf die Festplatte(n), wenn er genügend Zeit dafür hat. Auf diese Weise wird der Durchsatz auf Kosten der Sicherheit gesteigert. Denn schließlich kann der Server plötzlich ausfallen - und damit sind die Daten im RAM verloren.
Bis zur Version 1.0.0 war diese Option Standardmäßig aktiviert. Ab Version 1.0.1 jedoch wurde Zugungsten der Datensicherheit die Alternative sync als Standard gesetzt. Um Systemadministratoren auf diese Änderung hinzuweisen, gibt der NFS-Server ab Version 1.0.1 eine Warnung aus, wenn überhaupt keine dieser beiden Optionen gesetzt ist.
secure Hier werden nur Anfragen von einem hohen Port an einen niedrigeren (und damit priviligierten) Port erlaubt. Damit wird die Gefahr verringert, dass ein normaler Nutzer einen NFS-Server aufsetzt und diesen dann mit ihrem Server "unter gleichen" reden läßt. Diese Einstellung ist zwar Standard - Sie ausdrücklich zu setzen beruhigt aber auf jeden Fall das Gewissen.
rw Hier wird das Verzeichnis für Lese- und Schreibzugriffe freigegeben. Standardeinstellung ist ro - also "Nur Lesen".
noaccess Mit diesem Parameter können Unterverzeichnisse eines exportierten Verzeichnisses gesperrt werden.
link_relative Hiermit werden vorhandene Links relativ zum eigentlichen Root-Verzeichnis des Servers gesetzt. Sollte der Server z.B. mit einer Chroot-Umgebung laufen, sonst würden Links auf das reale Dateisystem des Servers sonst ins Leere zeigen.
link_absolute Hier werden die Links im exportierten Verzeichnis absolut gesetzt. Ein "relativer" Link auf dem Server wird dem Client also als "absolut" vorgegaukelt.
root_squash Standardeinstellung: Hier wird der Nutzer root des entfernten Systems behandelt, als wäre er nobody. Damit bekommt ein Hacker von einem fremden Rechner keine Möglichkeit sich auszubreiten.
no_root_squash Hier hat der Nutzer "root" des fremden Systems dieselben Rechte wie der lokale root.
squash_uids und squash_gids Mit dieser Option können bestimmte UIDs und GIDs vom fremden System behandelt werden, als wären sie "nobodys" - was sich besonders bei Systemaccounts als nützlich erweist. Beispiel: squash_uids=0-499 Läßt alle Anfragen von Nutzern mit einer ID kleiner als 500 nur als "nobodys" zu.
all_squash Alle UIDs werden "gesquasht", d.h. dem Nutzer nobody angerechnet. Damit haben alle fremden Nutzer die geringsten Rechte.
map_daemon Damit werden UIDs und GIDs vom entfernten System dynamisch an die im lokalen System vorhandenen angepasst. Ein Nutzer "lars" auf dem entfernten System bekommt dann dieselben Rechte wie der lokale "lars" - auch wenn dieser eine andere Nutzer-ID hat. Allerdings muß dazu auf beiden Systemen der rpc.ugidd laufen.
map_static Hiermit wird ein statisches Mapping eingeführt. Dazu muss eine Datei mit den entsprechenden Zuweisungen vorhanden und als Parameter angegeben sein. Ein Beispiel: map_static=/etc/nfs/foobar.map Die Datei /etc/nfs/foobar.map könnte dann so aussehen:
# Mapping for client foobar:
# remote local
uid 0-99 - # squashen - also eigentlich keine Rechte
uid 100-500 1000 # Mappe die UIDs von 100-500 nach 1000-1400
gid 0-49 - # Gruppen squashen
gid 50-100 700 # Mappe Gruppen mit IDs von 50-100 nach 700-750
map_nis Eine schöne Funktion: hier werden die Rechte von einem NIS-Server bezogen und entsprechend angewendet. Dazu muss der NFS-Server nur wissen, in welcher Domain sich die Clients befinden. Dies geschieht so: map_nis=<domainname></domainname>
anonuid and anongid Hiermit werden die UIDs und GIDs für den Nutzer nobody und die entsprechende Gruppe festgelegt.
no_exec Das Dateibit für ausführbare Dateien wird im entfernten System nicht gestattet: aus diesem exportierten Verzeichnis heraus dürfen keine Programme aufgerufen werden.
no_suid Das setzen des "User-ID"-Bits wird nicht gestattet. Dateien können nur mit den Rechten des jeweils angemeldeten Benutzers ausgeführt werden.
no_sgid Das setzen des "Group-ID"-Bits wird nicht gestattet. Dateien können nur mit den Gruppen-Rechten des angemeldeten Benutzers ausgeführt werden.

Tip: Sollte es bei vielen Clientzugriffen auf eine Datei oder ein Verzeichnis zu "Engpässen" also zu Wartezeiten kommen und die Daten im betreffenden Verzeichnis sind nicht so wichtig (oder das Verzeichnis wird sowieso nur Read-Only exportiert), dann hilft wahrscheinlich die Option async weiter. Damit werden asynchrone Dateizugriffe von Clients erlaubt.

Clientseite:

Ein Client kann das entfernte Dateisystem entweder temporär einbinden - dazu genügt (als root) das Kommando:

mount -t nfs <server>:/<verzeichnis> /<lokaler mountpoint="mountpoint"></lokaler></verzeichnis></server>

oder er kann es bei jedem Booten automatisch einbinden. Dafür ist ein entsprechender Eintrag in der Datei /etc/fstab nötig.

Was ist NIS?

Der "Network Information Service", welcher früher unter dem Begriff "Yellow Pages" also "Gelbe Seiten" bekannt war, ist ein System, welches die zentralen Zugriffs-Konfigurations-Dateien eines Servers in einer speziellen Datenbank (die Informationen werden hier in sog. Maps gespeichert) zusammenfasst und anderen Rechnern zur Verfügung stellen kann.

Dabei behält der "Master-Server" diese Datenbank (und ist somit ein "Central Point of Administration" - ein zentraler Administrationspunkt) und stellt die in ihr enthaltenen Informationen den anderen Rechnern über das Netzwerk zur Verfügung. Um bei einem Ausfall des Servers noch weiterarbeiten zu können und diesen zusätzlich zu entlasten kann es auch "Slave Server" geben, welche eine eigene Datenbankdatei erstellen, die aber bei einer Veränderung der Datenbank des "Master Servers" automatisch aktualisiert werden. Änderungen in der Datenbank werden also immer nur am Master-Server durchgeführt und dann von diesem weiterverteilt.

Konfiguration von NIS

Serverseite:

Der NIS-Server wird vorwiegend über die Datei "ypserv.conf" administriert, welche sich überlicherweise im Verzeichnis /etc befindet. Die Datenbankdateien befinden sich im Verzeichnis /var/yp und entsprechenden Unterverzeichnissen, welche den Namen des entsprechenden Netzwerks erhalten.

Im Verzeichnis /var/yp befinden sich aber auch noch die Dateien "securenets" und die Konfigurationsdatei für das Erzeugen der Datenbanken: das "Makefile". Auf Inhalte dieser Dateien gehen wir später noch genauer ein.

Clientseite:

Ein Client bekommt durch einen zusätzlichen Eintrag der Form "+" am Ende seiner Zugangsdateien (überlicherweise /etc/passwd und /etc/shadow - siehe weiter unten) und über Einträge in der Datei "nsswitch.conf", welche sich überlicherweise im Verzeichnis /etc befindet, mit, dass er sich zur Authentifizierung zusätzlich an einen NIS-Server wenden soll.


Wo liegen die speziellen Probleme beim Einsatz von NIS und NFS?

Da beide Programme auch auf den sogenannten unpriviligierten Ports des Netzwerks laufen können, d.h. durch normale Nutzer gestartet werden können, braucht ein Angreifer nur die normalen Dienste durch seine "eigenen" zu ersetzen und kann so eine ganze Domain übernehmen.

Sie sollten beide Dienste daher auf jeden Fall nur in einem durch eine Firewall geschützten Netzwerk anbieten. Immerhin können Sie dann - bei unversehrter Firewall - den Täterkreis bei einem Einbruch doch enorm eingrenzen.

NFS

Während der nunmehr über 20 jährigen Existenz der beiden Dienste kam es des öfteren zu Sicherheitsproblemen, welche inzwischen auf deren grundsätzliches Design zurückgeführt werden.

So vertraut der NFS-Server grundsätzlich den UIDs und GIDs, welche im vom Client übertragen werden, und gewährt die entsprechenden Zugriffsrechte. Ein gehackter Client (oder gar ein zusätzlich im Netzwerk platzierter Rechner) kann so den Server ebenfalls kompromittieren.

Wie um dieses schwerwiegende Problem noch zu übertreffen, traten bei den eingesetzten Serverprogrammen auch immer wieder BufferOverflows auf, die es einem Angreifer ermöglichten, auf dem Server selbst root-Rechte zu erlangen.

NIS

NIS war schon oft Opfer von DOS-Attacken (Denial of Service). Hier wird durch übermäßig häufige Anfragen des Angreifers der Server daran gehindert, weitere Anfragen von normalen Clients zu beantworten. Auch BufferOverflows sind in den eingesetzten NIS-Servern - wie übrigens auch in den von ihnen verwendeten Hilfsprogrammen - immer wieder bekannt geworden.

Zusätzlich gab es auch Probleme, wenn von einem kompromittierten Client Anfragen an den NIS-Server gestellt wurden, dieser "zu lasch" konfiguriert war und so seine NIS-Maps - zur späteren Auswertung durch den Angreifer - an den Client als potentiellen Slave-Server übertrug. Dazu brauchte der Angreifer nur den Domain-Namen zu erraten, sich mit seinem Client an die Domäne zu binden und mit "ypcat" eine entsprechende Auskunft einzuholen.

Ein simples Beispiel gefällig?
Angenommen, ein Client ist NIS-Client eine Domain und hat für die am Server registrierten Benutzer deren Homeverzeichnisse über NFS eingebunden. Nun versetzen wir uns in die Rolle des lokalen (Client-)Administrators, der einen bestimmten Nutzer nicht besonders mag...

Was macht dieser Admin? Er meldet sich normal als root auf "seinem" Client an und wird anschließend mit dem Befehl "su <benutzer></benutzer>" zu seinem Lieblingsnutzer. Dazu braucht er als Admin noch nicht einmal das Passwort dieses Benutzers. Nun kann er aber sämtliche über NFS eingebundenen Daten dieses Nutzers lesen und bearbeiten, da er dem NFS-Server gegenüber die "richtige" Nutzerkennung hat.

Gegen einen solchen "Angriff" hilft nur ein komplett sicheres System - da kann auch der Server allein nicht mehr weiterhelfen. Ist erst einmal ein Rechner kompromittiert, kann u.U. das gesammte System gefährdet sein.


NFS absichern

Im Folgenden wollen wir nun versuchen, eine "Checkliste" zu erstellen, die den NFS-Server zumindest ein wenig sicherer macht:

  1. Verwenden Sie die aktuellste Version von NFS mit allen Patches. Im Internet werden immer wieder Exploids veröffentlicht. Zum Glück ist Sun sehr schnell dabei, die Lücken in den Programmen zu schließen.
  2. überprüfen Sie die Konfigurationsdatei. Sind alle Einträge von exportierten Verzeichnissen und erlaubten Rechner aktuell?
  3. überprüfen Sie die Zugriffsrechte auf freigegebene Verzeichnisse. Auch diese finden Sie in der exports-Datei. Sie sollten immer ein paar Rechte für ein exportiertes Verzeichnis gesetzt haben. Ist das nicht der Fall, ist dieses Verzeichnis für alle freigegeben - überall! Sie sollten sich also rechtzeitig Gedanken darüber machen, ob Sie ein Verzeichnis z.B. nur einem bestimmten Rechner (bitte mit vollem Rechnernamen, also z.B. rechner1.irgendwo.net), oder vielleicht einer bestimmten Gruppe von Nutzern (diese können Sie in der Datei /etc/netgroups definieren) freigeben - oder es nur read only exportieren. Das dürfte Hackern, die aus irgend einem Grund Zugriff auf ihren NFS-Server erlangt haben, das weitere Vorgehen zumindest erschweren. Noch ein abschließendes Wort zum Server selbst: bitte beachten Sie, dass der Server sich selbst nicht ein Verzeichnis freigibt - weder mit seinem Rechnernamen noch als localhost.
  4. Der nächste Schritt ist das Beachten der 256-Zeichen Grenze in der exports-Datei. Prüfen Sie zusätzlich mit "showmount -e", was genau vom Server exportiert wird. Noch einmal: gehen Sie auf Nummer sicher, dass der Server auch nur genau das mit den passenden Rechten exportiert, was Sie wirklich haben wollen!
  5. überprüfen Sie die Dateirechte der Dateien exports und netgroups. Beide Dateien sollten die Rechte 644 haben und im Besitz des Nutzers "root" und der Gruppe "root" oder der Gruppe "sys" sein.
  6. überprüfen Sie regelmäßg (z.B. mit dem Programm "netstat"), ob der NFS-Server auf einem priviligierten Port läuft.

NIS absichern

Auch für NIS wollen wir nun eine kleine Checkliste aufstellen, um einen NIS-Server zumindest ein wenig abzusichern:

  1. Auch hier gilt: verwenden Sie immer die aktuellste Version! Ebenso wie bei NFS sind recht schnell Updates zur Hand, wenn ein neuer Bug gefunden wurde.
  2. überprüfen Sie die Struktur ihrer NIS-Domain. Sie sollten versuchen, immer einen einzigen NIS-Server für ein Netzwerk zu haben. Wenn sie z.B. einen Server für zwei Domains haben, dann sollten Sie für jede Domain einen eigenen Server aufsetzen. Ansonsten kann es leicht passieren, dass ein Nutzer aus der einen Domain die Daten der anderen Domain anfordert und so an ihre gesammten NIS-Maps kommt.
  3. Als nächstes sollten Sie überprüfen, ob Sie die NIS Maps von der lokalen Passwortverwaltung des Servers trennen können. Das erschwert einem Angreifer, der die Maps "geknackt" hat das Kompromittieren des Systems. Besonders die "root"- und "System"-Passwörter sollten nicht in den Maps auftauchen! Das können Sie im Makefile einstellen, welches sich im allgemeinen im Verzeichnis /var/yp befindet.

    Alles ab der UID 500 und der GID 100 sollte in Ordnung gehen. Für alle anderen Werte gilt: nicht in die Map-Datenbank! Suchen Sie im Makefile zusätzlich nach dem Wert für YP_SECURE - ist diese Variable vorhanden und entsprechend gesetzt, beantwortet der Server nur Anfragen eines Clients auf einem priviligiertem Port.
  4. überprüfen Sie regelmäßig mit einem Tool wie z.B. "john" die Passwörter der Benutzer: sind sie leicht zu knacken? Wenn das so ist, kann ein Angreifer leicht das Paswort eines Benutzers knacken und sich so auf ihrem System austoben. (Das gilt natürlich nicht nur für NIS.)
  5. überprüfen Sie ihr System auf "Null"-Passwörter, also Accounts, die ohne Passwort genutzt werden können.
  6. überprüfen Sie die Einstellungen ihrer Clients! In mancher Konfiguration kann sich der Nutzer "+" (s.o.) auf einem Client ohne Passwort einloggen! Dazu setzen Sie bitte in der Datei /etc/passwd oder besser (falls vorhanden) /etc/shadow an die zweite Stelle ein "*", was dem Benutzer "+" ein einloggen nicht mehr erlaubt. Die Zeile für die Einrichtung von NIS-Accounts müßte korrekt also so aussehen: "+:*:0:0:::"
  7. überprüfen Sie die Datei "securenets" auf ihrem Server. Diese befindet sich üblicherweise im Verzeichnis /var/yp und enthält diejenigen Netzwerke, denen der Server seine Maps zur Verfügung stellt.

Netgroups

Mit Netgroups können Sie bestimmten Gruppen den Zugriff nur von bestimmten Rechnern erlauben, können NFS-Zugriffe nur bestimmten Rechnern gewähren und bestimmten Nutzern einer bestimmten Domain Administrator-Rechte gewähren. Allerdings können Netgroups dem Admin auch viele Probleme bescheren... icon_wink

Wie auch immer - wenn Sie möglichen Angriffen auf Ihr NIS- und NFS-Netzwerk vorbeugen möchten, sind Netgroups eine gute Möglichkeit.

Wenn Sie Netgroups verwenden möchten, beachten Sie bitte die folgenden Richtlinien:

  1. Schalten Sie die Nutzung von rlogin und rsh komplett ab. Dazu brauchen Sie meist nur die Datei "inetd.conf" im Verzeichnis /etc editieren und vor die entsprechenden Dienste ein "#" zu setzen. Ein Neustart des Inet-Servers mit dem Befehl "rcinetd reload"sorgt dann für Ruhe und Sicherheit.
  2. Sollte das nicht möglich sein, schränken Sie den Zugriff auf diese Dienste zumindest für bestimmte Rechner durch entsprechende Einträge in der Datei ".rhosts" ein.
  3. überprüfen Sie die Datei /etc/netgroups auf Schreibfehler! Leerzeichen stehen als Platzhalter für ALLE, falsch geschriebene Rechner- oder Nutzernamen können ebenfalls größe Löcher reißen...
  4. Testen Sie den Zugang für in "netgroups" definierte Gruppen. Stellen Sie sicher, das die definierten Gruppen nur Zugang zu den ihnen gestatteten Diensten haben - und nicht zusätzlich zu anderen Sachen!

Alternativen

Für NIS gibt es seit einigen Jahren schon Alternativen: NIS+ oder LDAP [10].

NIS+ ist der Nachfolger von NIS - leider steht er (noch) nicht als Servervariante für Linux zur Verfügung. Wenn Sie allerdings einen Server besitzen, der auch als NIS+-Server fungieren kann, können Sie Linux-Clients problemlos an ihn anbinden.

LDAP wird wohl zukünftig eine immer größere Rolle in diesem Bereich spielen: der ldap-Server bildet einerseits die Möglichkeit zur sicheren Anbindung von Clients und kann andererseits durch seine hierarchische Struktur (im Gegensatz zur "flachen" Struktur einer NIS-Domain) die Verhältnisse in einem Netzwerk übersichtlicher abbilden.

Für NFS tritt seit kurzem das CFS als Alternative an. Das von Matt Blaze geschriebene "Cryptographic File System" soll eine Verschlüsselungsebene in die Dateisystemebene integrieren. Dazu gehört ein ausgefeiltes Schlüsselmanagment, Zugangs- und Transportschutz sowie eine höhere Skalierbarkeit und Portabilität.

Zusätzlich lassen sich freigegebene NFS-Verzeichnisse auch über einen SSH-Tunnel nutzen. Diese letzte Möglichkeit ist derzeit wohl die populärste, da SSH im Serverbereich sowieso schon lange Einzug gehalten hat. Hier muß aber sowohl der Client als auch der Server die zusätzliche Belastung durch die Verschlüsselung der Daten verkraften.


Zusammenfassung

NIS und NFS sind definitiv unsicher. Sie beinhalten die ständige Gefahr eines unauthorisierten Zugangs zum Netzwerk. Allerdings lassen sich - durch einige zusätzliche Sicherungsmaßnahmen, die in diesem Artikel beschrieben werden - die Sicherheitsbedenken auf ein erträgliches Maß reduzieren, wenn man seinem eigenen Netzwerk traut.




  

[ zurück zu Serverprogramme [11] | Index [12] ]

Kommentare

Einen Kommentar hinzufügen


Links
  [1] http://www.linux-schulserver.de/index.php?name=Sections&req=viewarticle&artid=6&allpages=1&theme=Printer
  [2] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=1
  [3] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=2
  [4] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=3
  [5] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=4
  [6] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=5
  [7] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=6
  [8] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=7
  [9] http://www.linux-schulserver.de/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=6&page=8
  [10] http://de.wikipedia.org/wiki/LDAP
  [11] http://www.linux-schulserver.de/index.php?name=Sections&req=listarticles&secid=1
  [12] http://www.linux-schulserver.de/index.php?name=Sections