Die Serverdienste NFS und NIS

Seite: 3/8
(3022 Worte insgesamt im Text)
(15283 mal aufgerufen)  Druckerfreundliche Ansicht

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.




Kommentare

Einen Kommentar hinzufügen



 Suchen:


 Umfrage

(Nur für angemeldete Benutzer)

Was wird hier am meisten vermisst?

[ Ergebnis | Umfragen ]

Stimmen: 621
Kommentare: 0

 Zitate

Das grosse Karthago führte drei Kriege. Es war noch mächtig nach dem ersten es war noch reich nach dem zweiten, es war nicht mehr wiederauffindbar nach dem dritten.

-- B. Brecht