NIS / YP

Sicherheitsaspekte

Das Gerücht, NIS sei grundsätzlich unsicher und kann in einer sensitiven Umgebung nicht eingesetzt werden, ist weit verbreitet. Es führt dazu, daß NIS häufig als Option von vornherein ausgeschlossen wird, ohne daß man es näher betrachtet und sich mit den konkreten Risiken und deren mögliche Behebung auseinandersetzt. Tatsache ist, daß NIS in vielen Fällen verwendet werden kann, wenn man seine Wirkungsweise verstanden und die entsprechenden Maßnahmen getroffen hat.

Richtig ist, daß NIS ein unverschlüsseltes und unauthentisiertes Protokoll ist -- genau wie NFS, DNS, SMTP und eine Menge anderer Protokolle, die weitläufig eingesetzt werden. Für viele davon existieren auch Erweiterungen, die eine Verschlüsselung und/oder Authentisierung erlauben; diese sind aber meistens nicht sehr verbreitet.

Eine solche Variante gibt es auch bei NIS; sie heißt NIS+ (»NIS-plus«) und basiert auf Secure-RPC. Auch dies ist nicht weit verbreitet und behebt die Sicherheitsmängel von NIS nicht auf zufriedenstellende Weise. Es wird daher hier nicht weiter betrachtet.

Schauen wir uns einmal konkret an, welche Probleme bei der Verwendung von NIS auftreten können. Folgende Einzelaspekte gilt es zu berücksichtigen:

Unbefugtes Abfragen von Informationen:

Jeder, der einen NIS-Server (Master oder Slave) kontaktieren kann, kann an den Inhalt der Maps gelangen. Wenn diese Maps sensitive Informationen beinhalten, gilt es, dies zu verhindern. Dies kann man einerseits mit einer Firewall erreichen, die die entsprechenden Anfragen blockiert, und zweitens mit der Datei /var/yp/securenets. Wenn diese Datei existiert, werden nur solche Anfragen beantwortet, die von einem Rechner oder Netz stammen, das darin aufgeführt ist. Auch der yppasswdd (sofern man ihn verwendet) hält sich an diese Datei.

Paßwörter:

Wenn man Paßwörter per passwd-Map verteilt, werden diese durch das Netz geschickt. Zwar sind diese nicht im Klartext, sondern gehasht (je nach UNIX-Variante mit DES oder [besser] mit MD5, Blowfish oder SHA1), aber ein Angriff per Brute-force oder Wörterbuch kann offline durchgeführt werden und kann je nach Qualität der Paßwörter in einigen Fällen zum Erfolg führen. Wenn man dem lokalen Netz nicht traut und damit rechnen muß, daß ein Unbefugter den Traffic mitsnifft, dann ist dies ein Problem. Man kann es umgehen, indem man keine Paßwort-Authentisierung zuläßt, sondern zum Beispiel SSH-Keys oder One-Time-Passwords (S/Key) verwendet.

NIS-Server-Spoofing:

Wenn das lokale Netz als unsicher anzusehen ist, ist es denkbar, daß eine unbefugte Person auf einem Rechner einen eigenen NIS-Master aufsetzt, der Pushs an die anderen Rechner verschickt und Anfragen von Clients beantwortet. Dazu muß er nur schneller antworten als die richtigen Server, damit die Clients auf ihn binden. Dies kann der Angreifer durch ausreichend schnelle Hardware erreichen, oder durch Denial-of-service-Angriffe auf die richtigen Server. Dieser Gefahr kann man dadurch begegnen, daß man die Adressen auf den Slaves und Clients fest konfiguriert, so daß sie keine Broadcasts machen und keine Antworten von anderen Servern akzeptieren. Dies hilft allerdings nicht gegen IP-Spoofing (d.h. ein Rechner nimmt die IP-Adresse des NIS-Masters an), was aber normalerweise nicht unentdeckt bleibt, da FreeBSD in solchen Fällen einen oder mehrere Log-Einträge erzeugt, die besagen, daß eine IP-Adresse von einer MAC-Adresse zu einer anderen gewechselt ist.

Wenn man obige Aspekte berücksichtigt und die entsprechenden Maßnahmen ergreift, werden die möglichen Kompromittierungs-Szenarien drastisch reduziert. Ob in einer bestimmten Situation die Verwendung von NIS tragbar ist oder nicht, muß natürlich jeder für sich selbst entscheiden.