13.4. Authentifizierung (AD, LDAP, Kerberos V...)

Authentifizierung, zentrale Ablage der (verschlüsselten) Passworte sind in Verbindung mit zentraler Administration eine wesentliche Komponente der Sicherheit. Sie ist klar verbunden mit den Diensten, die im Netzwerk genutzt werden. So haben in den letzten Jahren fast alle Dienste, welche Klartextpassworte zur Authentifizierung forderten, einen zusätzlichen Layer bekommen, z.B. SSLv2 und SSLv3 bekannt. Die Protokolle HTTPs, sFTP, sIMAP, sPOP, sSMTP sind Point - 2 - Point Protokolle, verwendet z.B. bei Homebanking, wobei SSLv2 wegen des M.I.T.M. - Problems unsicher ist, wie eigentlich auch die komplette Authentifizierung unter Windows, die ebenfalls unter diesem Problem leidet, welches unter passing the hash bekannt wurde, siehe auch Abschnitt 5.2. So ist z.B. der Diffie - Hellmann Key Exchange, siehe Abschnitt 2.1 in fast allen Verfahren enthalten, in denen zwischen zwei Computern ein Krypto-Tunnel aufgebaut wird, und zwar ohne daß zuvor ein shared secret bekannt sein muß. Auch dieses ist unsicher.

Weit verbreitet sind Authentifizierungsverfahren, wo nur die HASHES der Passworte über das Netzwerk gesendet werden, als quasi Prüfsummen der Passworte, aus denen das Passwort selber nicht ermittelt werden kann. Wer sich authentifizieren möchte, tippt ein Passwort ein, welches dann verschlüsselt wird, und mit dem verschlüsselten Passwort z.B. im LDAP - Server verglichen wird. Stimmt es überein, wird Zugang erteilt. Nun hat z.B. Windows hier ein Problem. Einige der Verfahren, z.B. zur Authentifizierung von Netzwerk-Komponenten (DCOM) verraten diese Hashes über das Netzwerk, die dann in ca. 10-15 Stunden mit einem handelsüblichen Athlon - Prozessor geknackt werden können. Wer also z.B. die verschlüsselten Passworte aus dem Netzwerk erschnüffelt phishing, sniffing, aus /etc/shadow, oder die eines LDAP - Servers ermitteln kann, kann mit L0phtCrack Passworte finden, die denselben Hash - Wert ergeben, wie das originale Passwort. Dies bedeutet, daß die schönen Diagramme zur Authentifizierung unter Microsoft Windows zwar nett aussehen, jedoch nicht die Realität abbilden. Auch Windows ist ein Sammelsurium von verschiedensten Authentifizierungsverfahren, darunter auch noch veraltete, aus Kompatibilitätsgründen.

Viele Entscheider haben aus Kostengründen und Gründen der Einfachheit der Administration auf Microsoft PDC/BDC oder Active Directory gesetzt. Auch SAMBA bietet hier einen NT 4.0 Clone mit AD - Client unter SAMBA 3.0 an. Damit können Linux Server entweder selber PDC/BDC sein, oder indirekt Teil einer Active Directory Domäne sein. SAMBA ist ein wichtiger Dienst, weil er File - und Druckservices im Heterogenen UNIX / Windows Netzwerk zur Verfügung stellt. Die Druck - und Fileservices unter Linux / Unix und Windows waren bis zu diesem Zeitpunkt inkompatibel.

Inzwischen hat sich sehr viel geändert. Alle Betriebssysteme, also Linux, UNIX, Mac OS X, Windows verwenden ein einheitliches Verfahren für Druckertreiber, Spooling, u.s.w. - CUPS - Common UNIX Printing System - und - Windows NT arbeitet seit Windows 2000 bereits damit. Zentrale Treiber, die die Hersteller als .ppd Datei zur Verfügung stellen, sind beliebig austauschbar. Diese Printing - Services, einmal auf einer Workstation oder einem Server installiert, arbeiten mit einem einheitlichen Protokoll, IPP (Internet Printing Protocol), welches auch alle Netzwerkdrucker beherrschen. Über Broadcast - Meldungen tauschen alle Workstations, Server und Netzwerkdrucker untereinander Informationen über Druckertyp, Rechte, u.s.w. aus. Aber auch die Treiber werden aus einem zentralen, frei zugänglichen Verzeichnis allen Rechnern im LAN zur Verfügung gestellt, bei Windows ist dies ebenso, wie bei SAMBA das versteckte Share print$ aus welchem Druckertreiber nachgeladen werden.

Inzwischen ist, dank CUPS, siehe auch Kapitel 23, Drucken in heterogenen Netzwerken kein Problem mehr. Diese Tatsache macht im Grunde SAMBA als Fileserver überflüssig. Microsoft hat angekündigt, daß das SMB Protokoll, welches diesem Dienst zugrunde liegt, sterben wird. Zu Recht. Es war ein Sammelsurium aus vielen Protokollen, verteilt über Ports 137-139, und zwar TCP und UDP. UDP ist ein sehr schlecht zu sicherndes Protokoll, sogar für stateful firewalls, mehr hierzu siehe Kapitel 17.

Microsoft hat inzwischen sich etwas neues überlegt, und zwar das WebDAV - Protokoll (Web-based Distributed Authoring and Versioning). Es ist eine Erweiterung des HTTP - Protokolls, unterstützt Locking, Versioning. Seit dem IE 5.5 kann man sich mit Hilfe von Web-Ordner mit einem WebDAV Fileserver verbinden, und diesen ganz normal mit allen Applikationen als Netzwerk - Laufwerk z.B. einbinden, wobei die Laufwerke nur Simulationen sind. Auch Linux Browser unterstützen alle das Protokoll webdav://server.de, völlig analog zu http://, ftp://. Dieses war notwendig, weil ja auch unter Windows Terminal - Server in Mode sind (was UNIX schon seit Jahrzehnten kennt), und jeder User ein eigenes Share mit eigenem Passwort einbinden können muß. Das altbekannte Netzlaufwerk verbinden entfällt, und man kann sogar webdav://intranet.server.de/share als Link in einer E-Mail versenden, Passwort z.B. telefonisch zu erfragen. Dies bedeutet eine völlig veränderte Administration und völlig andere Möglichkeiten der Steuerung des Workflows in Unternehmen und auch übergreifend. Es gibt keine notwendige Unterscheidung zwischen Internet und Intranet - Server mehr. Server, die in der DMZ einer Firewall stehen, können Shares enthalten, auf die auch Kunden Zugriff haben. Mehr zu WebDAV Server, siehe Abschnitt 18.2.

Dies hat erhebliche Auswirkungen auf Authentifizierungen. Die bisherigen Directory Server können die neuen, erhöhten Ansprüche aufgrund von Mängeln in den Protokollen nicht erfüllen. Microsoft hatte ein Einsehen, und hat ein Verfahren von UNIX übernommen, welches sehr bewährt ist - Kerberos V. Unter UNIX gibt es Kerberos V schon seit langer Zeit, für welches eine freie, kostenlose Implementierung namens Heimdal existiert, siehe http://www.pdc.kth.se/heimdal/. Interessant ist, daß bereits sehr viele FTP - Server - Implementierungen Kerberos - Authentifizierung unterstützen.

$ ftp ftp.cdrom.com
Connected to cdrom.wip.digitalriver.com.
220 drftp.digitalriver.com NcFTPd Server (licensed copy) ready.
KERBEROS_V4 rejected as an authentication type
Name (ftp.cdrom.com):

$ ftp.microsoft.com
Connected to ftp.microsoft.com.
220 Microsoft FTP Service
500 'AUTH GSSAPI': command not understood
500 'AUTH KERBEROS_V4': command not understood
KERBEROS_V4 rejected as an authentication type

$ ftp ftp.apple.com
Connected to ftp.apple.com.
220 ProFTPD 1.2.9 Server (Apple Anonymous FTP Server) [ftp02.apple.com]
500 AUTH not understood
500 AUTH not understood
KERBEROS_V4 rejected as an authentication type

$ ftp ftp.novell.com
Connected to thelev.provo.novell.com.
220-ftp.novell.com NcFTPd Server (licensed copy) ready.
220-
220-This is an ANONYMOUS FTP server please enter "anonymous" as the user ID
220
KERBEROS_V4 rejected as an authentication type
Name (ftp.novell.com): 

Alle großen Hersteller haben sich Kerberos verschrieben (Kerberos V4 zwar noch, aber immerhin).