28.10.2013 Aufrufe

Windows Server 2008 Sicherheit – Die technische Referenz - Gattner

Windows Server 2008 Sicherheit – Die technische Referenz - Gattner

Windows Server 2008 Sicherheit – Die technische Referenz - Gattner

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

Speichern der Authentifizierer 27<br />

Im Speicher<br />

Wenn sich ein Benutzer interaktiv oder über Terminaldienste anmeldet, speichert <strong>Windows</strong><br />

den Hashwert für das Kennwort des Benutzers (den NT-Hash und, sofern der Computer<br />

entsprechend konfiguriert ist, auch den LM-Hash) in einem Cache. Der Hashwert wird an<br />

einer Stelle im Speicher abgelegt, auf die nur das Betriebssystem und natürlich Prozesse, die<br />

als Betriebssystem agieren, Zugriff haben. Wenn ein Benutzer versucht, auf eine Netzwerkressource<br />

zuzugreifen, die eine Authentifizierung erfordert, verwendet das Betriebssystem<br />

diesen zwischengespeicherten Hashwert für die Authentifizierung. Das ermöglicht eine<br />

transparente Authentifizierung bei Netzwerkressourcen. Sobald sich der Benutzer abmeldet<br />

oder die Arbeitsstation sperrt, wird die entsprechende Speicherstelle automatisch gelöscht.<br />

Über diese Hashwerte wurde rege diskutiert, als ein bestimmter Fall demonstriert wurde:<br />

Falls ein Domänenadministrator angemeldet ist, kann jeder andere Benutzer, der ein Administrator<br />

ist, den Kennworthash des Domänenadministrators lesen und sich damit beim Domänencontroller<br />

als Domänenadministrator authentifizieren. Das sollte aber jedem, der sich<br />

mit der Materie beschäftigt, ohnehin klar sein, und ehrlich gesagt wäre ein solcher Angriff<br />

viel zu aufwendig. Falls ein Angreifer bereits eine Arbeitsstation kompromittiert hat, wäre es<br />

viel einfacher, einfach ein Subauthentifizierungspaket zu installieren, das Kennwörter während<br />

des Anmeldevorgangs im Klartext aufzeichnet. Solche Pakete werden unterstützt, um<br />

einmaliges Anmelden an Nicht-<strong>Windows</strong>-Netzwerkgeräten im Pass-through-Verfahren zu<br />

ermöglichen. Nach demselben Prinzip wird auch der NT-Hash zwischengespeichert, um das<br />

einmalige Anmelden an <strong>Windows</strong>-Geräten zu ermöglichen. Es wäre zwar möglich, die<br />

zwischengespeicherten Kennworthashwerte zu löschen, aber die meisten Benutzer würden<br />

rebellisch, müssten sie ihr Kennwort jedes Mal neu eingeben, wenn auf eine Netzwerkressource<br />

zugegriffen wird. Würden diese zwischengespeicherten Kennworthashwerte gelöscht,<br />

könnte sich der Computer nicht mehr transparent im Namen des Benutzers bei Nicht-Domänennetzwerkressourcen<br />

authentifizieren.<br />

Das Problem liegt somit nicht wirklich darin, wie <strong>Windows</strong> den NT-Hash zwischenspeichert,<br />

und auch nicht bei den Subauthentifizierungspaketen, sondern beim verwendeten Verfahren.<br />

Ein Domänenadministrator sollte sich niemals interaktiv an einer Arbeitsstation anmelden,<br />

an der ein Benutzer mit lokalen administrativen Privilegien angemeldet ist, sofern dieser<br />

Benutzer nicht von allen Domänen-Admins als vertrauenswürdig eingestuft wird. Wenn Sie<br />

sich an diese einfache Regel halten, können Sie verhindern, dass diese sinnvolle Funktionalität<br />

als Angriffsweg missbraucht wird. Weitere Informationen zu diesem Thema finden Sie<br />

in Kapitel 14, »Schützen des Netzwerks«.<br />

Umkehrbar verschlüsselt<br />

Schließlich bietet <strong>Windows</strong> noch die Möglichkeit, Kennwörter umkehrbar zu verschlüsseln.<br />

Wenn ein Kennwort umkehrbar verschlüsselt (engl. reversibly encrypted) gespeichert wird,<br />

kann es in Klartext zurückverwandelt werden. Offensichtlich heißt das, dass ein solches<br />

Kennwort nicht geknackt werden muss. In der Standardeinstellung ist die Speicherung von<br />

Kennwörtern im umkehrbar verschlüsselten Format deaktiviert. <strong>Die</strong>se Funktion wird gewöhnlich<br />

nur in zwei Situationen benötigt. Erstens, falls Sie bestimmte ältere Authentifizierungsprotokolle<br />

für Remotezugriff verwenden, zum Beispiel die CHAP- oder Digest-Protokolle.<br />

Zweitens, falls Sie eine erweiterte Analyse Ihrer Kennwörter durchführen wollen,<br />

nachdem sie festgelegt wurden. Zum Beispiel wollen manche Organisationen die Kennwör-

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!