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.
|