Windows Server 2008 Sicherheit – Die technische Referenz - Gattner
Windows Server 2008 Sicherheit – Die technische Referenz - Gattner
Windows Server 2008 Sicherheit – Die technische Referenz - Gattner
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Jesper M. Johansson<br />
mit dem Microsoft Security Team<br />
Microsoft<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
<strong>Sicherheit</strong> <strong>–</strong><br />
<strong>Die</strong> <strong>technische</strong> <strong>Referenz</strong>
<strong>Die</strong>ses Buch ist die deutsche Übersetzung von: Jesper M. Johansson with the Microsoft Security Team:<br />
Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Security Resource Kit<br />
Microsoft Press, Redmond, Washington 98052-6399<br />
Copyright <strong>2008</strong> Microsoft Corporation<br />
Das in diesem Buch enthaltene Programmmaterial ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden.<br />
Autor, Übersetzer und der Verlag übernehmen folglich keine Verantwortung und werden keine daraus folgende<br />
oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programmmaterials<br />
oder Teilen davon entsteht.<br />
Das Werk einschließlich aller Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen<br />
des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für<br />
Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen<br />
Systemen.<br />
<strong>Die</strong> in den Beispielen verwendeten Namen von Firmen, Organisationen, Produkten, Domänen, Personen, Orten,<br />
Ereignissen sowie E-Mail-Adressen und Logos sind frei erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit<br />
mit tatsächlichen Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen, E-Mail-<br />
Adressen und Logos ist rein zufällig.<br />
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1<br />
10 09 08<br />
ISBN 978-3-86645-921-2<br />
© Microsoft Press Deutschland<br />
(ein Unternehmensbereich der Microsoft Deutschland GmbH)<br />
Konrad-Zuse-Str. 1, D-85716 Unterschleißheim<br />
Alle Rechte vorbehalten<br />
Übersetzung: Detlef Johannis, Kempten<br />
Korrektorat: Claudia Mantel-Rehbach, München<br />
Fachlektorat und Satz: Günter Jürgensmeier, München<br />
Umschlaggestaltung: Hommer Design GmbH, Haar (www.HommerDesign.com)<br />
Gesamtherstellung: Kösel, Krugzell (www.KoeselBuch.de)
Inhaltsverzeichnis<br />
Danksagungen .................................................... XIII<br />
Einleitung . ....................................................... XV<br />
Überblick über das Buch . ............................................ XV<br />
Dokumentkonventionen ............................................. XVII<br />
Leserhinweise . ................................................. XVII<br />
Textblöcke .................................................... XVIII<br />
Befehlszeilenbeispiele . ........................................... XVIII<br />
Begleit-CD ....................................................... XVIII<br />
Elevation Tools ................................................. XVIII<br />
Passgen . ...................................................... XIX<br />
Verwaltungsskripts .............................................. XIX<br />
E-Book . ........................................................ XXI<br />
Materialien zu einzelnen Kapiteln ................................... XXI<br />
Links zu Tools, die im Buch erwähnt werden .......................... XXI<br />
Systemvoraussetzungen ............................................. XXII<br />
Support für dieses Buch ............................................. XXIII<br />
Teil I Grundlagen der <strong>Windows</strong>-<strong>Sicherheit</strong> ................................ 1<br />
1 Subjekte, Benutzer und andere Akteure . ................................. 3<br />
<strong>Die</strong> Beziehung von Subjekt, Objekt und Aktion ............................. 3<br />
Typen von <strong>Sicherheit</strong>sprinzipalen ........................................ 4<br />
Benutzer ........................................................ 4<br />
Computer ....................................................... 7<br />
Gruppen ........................................................ 7<br />
Abstrakte Konzepte (Anmeldegruppen) . ................................ 10<br />
<strong>Die</strong>nste ......................................................... 11<br />
<strong>Sicherheit</strong>s-IDs . ..................................................... 12<br />
Komponenten einer SID ............................................ 13<br />
SID-Autoritäten .................................................. 13<br />
<strong>Die</strong>nst-SIDs ..................................................... 15<br />
Bekannte SIDs ................................................... 15<br />
Zusammenfassung ................................................... 16<br />
Weitere Informationen ................................................ 16<br />
2 Authentifizierung und Authentifizierungsprotokolle ........................ 17<br />
Etwas, das Sie wissen, und etwas, das Sie haben ............................. 17<br />
Etwas, das Sie wissen .............................................. 18<br />
Etwas, das Sie haben . .............................................. 18<br />
Etwas, das Sie sind ................................................ 18<br />
III
IV Inhaltsverzeichnis<br />
Speichern der Authentifizierer . .......................................... 20<br />
LM-Hash ....................................................... 22<br />
NT-Hash ........................................................ 24<br />
Kennwortverifizierer . .............................................. 25<br />
Im Speicher ..................................................... 27<br />
Umkehrbar verschlüsselt . ........................................... 27<br />
Authentifizierungsprotokolle ........................................... 29<br />
Standardauthentifizierung ........................................... 29<br />
Frage-Antwort-Protokolle ........................................... 30<br />
Smartcardauthentifizierung . ............................................ 38<br />
Smartcards und Kennwörter ......................................... 38<br />
Angriffe auf Kennwörter . .............................................. 39<br />
Ausspähen von Kennwörtern ........................................ 39<br />
Nutzen der ausgespähten Informationen ................................ 43<br />
Schützen Ihrer Kennwörter .......................................... 46<br />
Verwalten von Kennwörtern ............................................ 47<br />
Verwenden anderer Authentifizierer ................................... 48<br />
Kennwörter sicher notieren .......................................... 48<br />
Nehmen Sie das »Wort« in »Kennwort« nicht zu wörtlich ................... 48<br />
Festlegen von Kennwortrichtlinien .................................... 49<br />
Abgestimmte Kennwortrichtlinien .................................... 50<br />
Zusammenfassung ................................................... 55<br />
Weitere Informationen ................................................ 55<br />
3 Objekte: Was Sie wollen .............................................. 57<br />
Terminologie der Zugriffssteuerung ...................................... 57<br />
Geschützte Objekte . ............................................... 58<br />
<strong>Sicherheit</strong>sbeschreibungen .......................................... 58<br />
Zugriffsteuerungslisten ............................................. 60<br />
Zugriffssteuerungseinträge .......................................... 61<br />
Zugriffsmasken . .................................................. 63<br />
Beziehung zwischen Zugriffssteuerungsstrukturen ........................ 69<br />
Vererbung . ...................................................... 69<br />
<strong>Sicherheit</strong>stoken .................................................. 71<br />
Ablauf der Zugriffsprüfung .......................................... 74<br />
Integritätsebenen . ................................................. 76<br />
Leere und Null-DACLs . ............................................ 77<br />
Security Descriptor Definition Language . ............................... 78<br />
Tools zum Verwalten von Berechtigungen . ................................. 81<br />
Cacls und Icacls .................................................. 82<br />
SC ............................................................ 83<br />
Subinacl ........................................................ 83<br />
Wichtige Änderungen bei der Zugriffssteuerung in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> . ......... 84<br />
TrustedInstaller-Berechtigungen ...................................... 84<br />
Netzwerkstandort-SIDs . ............................................ 84<br />
Änderungen beim Dateisystemnamespace ............................... 84<br />
Berechtigungen für Hauptbenutzer entfernt .............................. 85<br />
EIGENTÜMERRECHTE und Besitzerrechte ............................. 85
Inhaltsverzeichnis V<br />
Benutzerrechte und Privilegien .......................................... 85<br />
RBAC/AZMAN ..................................................... 89<br />
Zusammenfassung ................................................... 90<br />
Weitere Informationen ................................................ 90<br />
4 Grundlagen der Benutzerkontensteuerung ............................... 91<br />
Was ist Benutzerkontensteuerung? ....................................... 91<br />
So funktioniert die Tokenfilterung . ....................................... 93<br />
Komponenten der Benutzerkontensteuerung ................................ 94<br />
Benutzeroberfläche der Benutzerkontensteuerung ......................... 94<br />
Anwendungsinformationsdienst ...................................... 97<br />
Datei- und Registrierungsvirtualisierung ................................ 98<br />
Manifeste und angeforderte Ausführungsebenen .......................... 100<br />
Installererkennungstechnologie ....................................... 101<br />
UIPI ........................................................... 102<br />
Anhebungsaufforderungen auf dem sicheren Desktop ...................... 102<br />
Remoteunterstützung .............................................. 103<br />
UAC-Remoteeinschränkungen ....................................... 104<br />
Zuordnen von Netzlaufwerken im Administratorbestätigungsmodus ........... 104<br />
Blockierte Anwendungsanhebungen bei Anmeldung ....................... 106<br />
Konfigurieren der UAC-Kompatibilität für ältere Anwendungen .............. 107<br />
UAC-Gruppenrichtlinieneinstellungen .................................... 108<br />
UAC-Richtlinieneinstellungen unter <strong>Sicherheit</strong>soptionen ................... 108<br />
Zugehörige UAC-Richtlinien ........................................ 110<br />
Was hat sich bei der UAC in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista SP1 geändert? 111<br />
Neue Gruppenrichtlinieneinstellung: UIAccess-Anwendungen können erhöhte Rechte<br />
ohne sicheren Desktop anfordern ..................................... 111<br />
Nur eine Bestätigung bei Dateioperationen im <strong>Windows</strong>-Explorer . ............ 112<br />
Über 40 neue Anwendungskompatibilitäts-Shims ......................... 112<br />
Empfehlungen für die UAC ............................................ 112<br />
Gut ............................................................ 112<br />
Besser . ......................................................... 113<br />
Am besten ...................................................... 113<br />
Zusammenfassung ................................................... 113<br />
Weitere Informationen ................................................ 114<br />
5 Firewall und Netzwerkzugriffsschutz .................................... 115<br />
<strong>Windows</strong>-Filterplattform .............................................. 116<br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> ............................... 118<br />
Verbesserungen an der <strong>Windows</strong>-Firewall ............................... 118<br />
Verwalten der <strong>Windows</strong>-Firewall ..................................... 122<br />
Routing- und RAS-<strong>Die</strong>nste ............................................. 130<br />
Verbesserungen in RRAS ........................................... 131<br />
Internet Protocol Security .............................................. 133<br />
Grundlagen von IPsec . ............................................. 133<br />
Neue Fähigkeiten in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> .............................. 135
VI Inhaltsverzeichnis<br />
Netzwerkzugriffsschutz ............................................... 139<br />
Architektur ...................................................... 139<br />
Implementieren von NAP ........................................... 143<br />
NAP-Szenarien . .................................................. 146<br />
Zusammenfassung ................................................... 148<br />
Weitere Informationen ................................................ 149<br />
6 <strong>Die</strong>nste ........................................................... 151<br />
Einführung in <strong>Die</strong>nste . ................................................ 151<br />
Was ist ein <strong>Die</strong>nst? ................................................ 152<br />
Anmeldekonten für <strong>Die</strong>nste . ......................................... 152<br />
<strong>Die</strong>nstports ...................................................... 154<br />
Konfigurieren von <strong>Die</strong>nsten ......................................... 155<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<strong>Die</strong>nste für unterschiedliche Rollen .................. 161<br />
Angriffe auf <strong>Die</strong>nste .................................................. 161<br />
Blaster-Wurm .................................................... 162<br />
Verbreitete Angriffsmethoden ........................................ 163<br />
<strong>Die</strong>nsthärtung ....................................................... 165<br />
Geringstmögliche Privilegien ........................................ 166<br />
<strong>Die</strong>nst-SIDs ..................................................... 170<br />
Schreibeingeschränkte SIDs ......................................... 173<br />
Eingeschränkter Netzwerkzugriff ..................................... 175<br />
Sitzung-0-Isolierung ............................................... 177<br />
Verbindliche Integritätsebenen ....................................... 177<br />
Datenausführungsverhinderung . ...................................... 178<br />
Andere neue SCM-Features ......................................... 178<br />
Schützen von <strong>Die</strong>nsten ................................................ 179<br />
Inventarisieren von <strong>Die</strong>nsten . ........................................ 179<br />
Abschalten möglichst vieler <strong>Die</strong>nste ................................... 180<br />
Zuweisen geringstmöglicher Privilegien an die übrigen <strong>Die</strong>nste .............. 180<br />
Halten Sie Ihre Updates auf dem neuesten Stand .......................... 181<br />
Erstellen und Verwenden benutzerdefinierter <strong>Die</strong>nstkonten .................. 181<br />
Implementieren der Netzwerkisolierung mit <strong>Windows</strong>-Firewall und IPsec . ...... 183<br />
Überwachen von <strong>Die</strong>nstfehlern ....................................... 183<br />
Entwickeln und verwenden Sie sichere <strong>Die</strong>nste ........................... 183<br />
Zusammenfassung ................................................... 183<br />
Weitere Informationen ................................................ 184<br />
7 Gruppenrichtlinien .................................................. 185<br />
Was ist neu in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>? . .................................... 185<br />
Grundlagen von Gruppenrichtlinien ...................................... 186<br />
Das lokale Gruppenrichtlinienobjekt ................................... 186<br />
Active Directory-Gruppenrichtlinienobjekte ............................. 187<br />
Gruppenrichtlinienverarbeitung . ...................................... 193<br />
Was ist neu bei Gruppenrichtlinien? ...................................... 197<br />
Gruppenrichtliniendienst . ........................................... 197<br />
ADMX-Vorlagen und der zentrale Speicher ............................. 197<br />
Starter-Gruppenrichtlinienobjekte ..................................... 199
Inhaltsverzeichnis VII<br />
GPO-Kommentare ................................................ 200<br />
Verbesserungen an der Filterung ...................................... 203<br />
Erweiterte Verwaltungsmöglichkeiten für <strong>Sicherheit</strong>srichtlinien .............. 204<br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> . ............................ 206<br />
Richtlinien für verkabelte und Drahtlosnetzwerke ......................... 208<br />
Verwalten von <strong>Sicherheit</strong>seinstellungen ................................... 211<br />
Zusammenfassung ................................................... 214<br />
Weitere Informationen ................................................ 215<br />
8 Überwachung ...................................................... 217<br />
Wozu überwachen? . .................................................. 218<br />
So funktioniert die <strong>Windows</strong>-Überwachung ................................ 218<br />
Festlegen einer Überwachungsrichtlinie ................................... 221<br />
Optionen für Überwachungsrichtlinien ................................. 225<br />
Entwerfen einer guten Überwachungsrichtlinie .............................. 229<br />
Neue Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> .................................. 230<br />
Analysieren von Ereignissen mit den eingebauten Tools ....................... 236<br />
Ereignisanzeige .................................................. 236<br />
WEvtUtil ....................................................... 242<br />
Zusammenfassung ................................................... 242<br />
Teil II Implementieren von Identitäts- und Zugriffssteuerung<br />
mit Active Directory ............................................... 245<br />
9 Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong> .............. 247<br />
<strong>Die</strong> neue Benutzeroberfläche ........................................... 248<br />
Der neue Assistent zum Installieren von Active Directory-Domänendiensten . ....... 250<br />
Schreibgeschützte Domänencontroller .................................... 252<br />
Schreibgeschützte AD DS-Datenbank .................................. 253<br />
RODC-gefilterte Attributsätze ........................................ 253<br />
Unidirektionale Replikation ......................................... 254<br />
Zwischenspeichern von Anmeldeinformationen . .......................... 254<br />
Schreibgeschütztes DNS ............................................ 256<br />
Mehrstufige Installation für schreibgeschützte Domänencontroller ............ 257<br />
Neustartfähige Active Directory-Domänendienste ............................ 258<br />
Active Directory-Datenbankbereitstellung ................................. 259<br />
AD DS-Überwachung . ................................................ 261<br />
Überwachen von AD DS-Zugriffen .................................... 262<br />
Grundlagen von AD LDS .............................................. 266<br />
Neue Features für AD LDS in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ...................... 268<br />
Grundlagen der Active Directory-Verbunddienste ............................ 269<br />
Was ist AD FS? . .................................................. 269<br />
Was ist neu in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>? . ................................. 270<br />
Zusammenfassung ................................................... 271<br />
Weitere Informationen ................................................ 271
VIII Inhaltsverzeichnis<br />
10 Implementieren der Active Directory-Zertifikatdienste . ...................... 273<br />
Was ist neu in der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-PKI? .............................. 274<br />
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten .............. 275<br />
Kompromittierung des Schlüsselpaars einer Zertifizierungsstelle . ............. 275<br />
Verhinderung von Zertifikatsperrprüfungen . ............................. 276<br />
Versuche, die Konfiguration der Zertifizierungsstelle zu verändern ............ 279<br />
Versuche, eine Zertifikatsvorlage zu verändern ........................... 280<br />
Hinzufügen nichtvertrauenswürdiger Zertifizierungsstellen zum Speicher der<br />
vertrauenswürdigen Stammzertifizierungsstellen . ......................... 281<br />
Registrierungs-Agenten, die nichtautorisierte Zertifikate ausstellen ............ 283<br />
Kompromittierung einer Zertifizierungsstelle durch einen einzelnen Administrator 284<br />
Unautorisierte Wiederherstellung des privaten Schlüssels eines Benutzers aus der<br />
Zertifizierungsstellendatenbank . ...................................... 285<br />
Schützen von Zertifikatdiensten ......................................... 286<br />
Implementieren physischer <strong>Sicherheit</strong>smaßnahmen ........................ 286<br />
Empfehlungen ...................................................... 288<br />
Zusammenfassung ................................................... 289<br />
Weitere Informationen ................................................ 289<br />
11 Implementieren der Active Directory-Rechteverwaltungsdienste .............. 291<br />
Grundlagen von RMS ................................................. 293<br />
Erforderliche Clientkomponenten ..................................... 295<br />
Erforderliche <strong>Server</strong>rollen . .......................................... 295<br />
Denkbare Architekturen ............................................ 296<br />
Implementieren von AD RMS . .......................................... 297<br />
Vorbereiten der Infrastruktur ......................................... 299<br />
Bereitstellen des RMS-<strong>Server</strong>s ....................................... 300<br />
Erstellen von RMS-Richtlinienvorlagen ................................ 309<br />
Integration mit Microsoft Office ......................................... 311<br />
Einsetzen von RMS, um bestimmte Anforderungen zu erfüllen .................. 312<br />
Gesetze mit Auswirkungen darauf, wie Organisationen Aufzeichnungen<br />
archivieren ...................................................... 312<br />
Konsequenzen, wenn die Anforderungen nicht erfüllt werden ................ 313<br />
Wie AD RMS helfen kann . .......................................... 314<br />
Einschränkungen von AD RMS ......................................... 314<br />
Zusammenfassung ................................................... 314<br />
Weitere Informationen ................................................ 315<br />
Teil III <strong>Sicherheit</strong>sszenarien .............................................. 317<br />
12 Schützen von <strong>Server</strong>rollen ............................................ 319<br />
Rollen und Features .................................................. 320<br />
Standardrollen und -features ......................................... 321<br />
Ihr <strong>Server</strong> vor der Installation von Rollen .................................. 328<br />
Standardmäßig installierte <strong>Die</strong>nste .................................... 328<br />
<strong>Server</strong> Core ........................................................ 328<br />
In <strong>Server</strong> Core unterstützte Rollen . .................................... 330
Inhaltsverzeichnis IX<br />
In <strong>Server</strong> Core unterstützte Features ................................... 331<br />
Was in <strong>Server</strong> Core nicht enthalten ist .................................. 331<br />
Tools zum Verwalten von <strong>Server</strong>rollen .................................... 333<br />
Aufgaben der Erstkonfiguration ...................................... 333<br />
<strong>Die</strong> Assistenten Rollen hinzufügen und Features hinzufügen ................. 334<br />
<strong>Server</strong>-Manager .................................................. 335<br />
Der <strong>Sicherheit</strong>skonfigurations-Assistent ................................... 336<br />
<strong>Server</strong> mit mehreren Rollen ............................................ 346<br />
Zusammenfassung ................................................... 346<br />
13 Patchverwaltung .................................................... 349<br />
<strong>Die</strong> vier Phasen der Patchverwaltung ..................................... 349<br />
Phase 1: Bewerten ................................................ 350<br />
Phase 2: Identifizieren . ............................................. 351<br />
Phase 3: Auswerten und Planen . ...................................... 353<br />
Phase 4: Bereitstellen .............................................. 355<br />
Der Aufbau eines <strong>Sicherheit</strong>supdates . ..................................... 356<br />
Unterstützte Befehlszeilenparameter ................................... 356<br />
Integrieren von MSU-Dateien in eine <strong>Windows</strong>-Abbilddatei ................. 357<br />
Tools für Ihr Patchverwaltungsarsenal . .................................... 358<br />
Microsoft Download Center ......................................... 358<br />
Microsoft Update-Katalog . .......................................... 358<br />
<strong>Windows</strong> Update und Microsoft Update ................................ 359<br />
Automatische <strong>Windows</strong>-Updates . ..................................... 360<br />
Microsoft Baseline Security Analyzer .................................. 362<br />
<strong>Windows</strong> <strong>Server</strong> Update Services ..................................... 366<br />
System Center Essentials 2007 ....................................... 374<br />
Zusammenfassung ................................................... 376<br />
Weitere Informationen ................................................ 376<br />
14 Schützen des Netzwerks . ............................................. 377<br />
Einführung in <strong>Sicherheit</strong>sabhängigkeiten .................................. 380<br />
Akzeptable Abhängigkeiten ......................................... 381<br />
Inakzeptable Abhängigkeiten ........................................ 381<br />
Abhängigkeitsanalyse eines Angriffs . .................................. 383<br />
Abhängigkeitstypen .................................................. 385<br />
Nutzungsabhängigkeiten . ........................................... 385<br />
Zugriffsabhängigkeiten ............................................. 386<br />
Administrative Abhängigkeiten ....................................... 388<br />
<strong>Die</strong>nstkontoabhängigkeiten . ......................................... 388<br />
Betriebsabhängigkeiten . ............................................ 389<br />
Eindämmen von Abhängigkeiten ........................................ 389<br />
Schritt 1: Erstellen eines Klassifizierungsschemas . ........................ 390<br />
Schritte 2 und 3: Netzwerkgefahrenmodellierung ......................... 393<br />
Schritt 4: Analysieren, waschen und wiederholen, bis sauber . ................ 397<br />
Schritt 5: Entwerfen der Isolierungsstrategie ............................. 398<br />
Schritt 6: Ableiten einer Betriebsstrategie ............................... 399<br />
Schritt 7: Implementieren von Einschränkungen .......................... 400
X Inhaltsverzeichnis<br />
Zusammenfassung ................................................... 403<br />
Weitere Informationen ................................................ 404<br />
15 Schützen von Zweigstellen . ........................................... 405<br />
Einführung in die Probleme von Zweigstellen . .............................. 405<br />
Warum sind Zweigstellen wichtig? .................................... 406<br />
Was ist anders in einer Zweigstelle? ................................... 406<br />
Aufbauen von Zweigstellen . ......................................... 407<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle .................................. 409<br />
Features, die nicht mit <strong>Sicherheit</strong> zu tun haben ........................... 409<br />
<strong>Sicherheit</strong>sfeatures für die Zweigstelle ................................. 411<br />
Andere <strong>Sicherheit</strong>smaßnahmen . ......................................... 426<br />
Zusammenfassung ................................................... 427<br />
Weitere Informationen ................................................ 427<br />
16 Aspekte für kleine Unternehmen ....................................... 429<br />
Betreiben von <strong>Server</strong>n bei knappem Budget ................................ 430<br />
Auswählen der richtigen Plattformen und Rollen . ......................... 431<br />
<strong>Server</strong> für kleine Firmen ............................................... 433<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Web Edition . ................................... 433<br />
<strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> . ................................. 433<br />
<strong>Windows</strong> Essential Business <strong>Server</strong> ................................... 437<br />
Gehostete <strong>Server</strong> . ................................................. 438<br />
Virtualisierung ................................................... 438<br />
Verletzen aller Prinzipien mit <strong>Server</strong>n, die mehrere Rollen übernehmen ........... 439<br />
Akzeptable Rollen ................................................ 440<br />
<strong>Server</strong>komponenten ............................................... 440<br />
Risikofaktoren ................................................... 441<br />
Grenzserver ..................................................... 443<br />
Support und Updates . .............................................. 445<br />
Wiederherstellen des <strong>Server</strong>s . ........................................ 446<br />
Empfehlungen für kleine Unternehmen . ................................... 447<br />
Befolgen von Leitfäden zur <strong>Server</strong>härtung .............................. 448<br />
Richtlinien ...................................................... 452<br />
Verfahrensempfehlungen für Hersteller ................................. 454<br />
Remotezugriff . ................................................... 456<br />
Überwachungs- und Verwaltungs-Add-Ons . ............................. 457<br />
<strong>Die</strong> Rolle des <strong>Server</strong>s bei der Kontrolle und Verwaltung der Arbeitsstationen .... 459<br />
Empfehlungen für weitere <strong>Server</strong>einstellungen und -konfigurationen . .......... 463<br />
Zusammenfassung ................................................... 468<br />
Weitere Informationen ................................................ 468<br />
17 Schützen von <strong>Server</strong>anwendungen ..................................... 471<br />
Einführung ......................................................... 471<br />
IIS 7.0: Ein <strong>Sicherheit</strong>sstammbaum ...................................... 473<br />
Konfigurieren von IIS 7.0 .............................................. 473<br />
Featuredelegierung ................................................ 474
Inhaltsverzeichnis XI<br />
TCP/IP-<strong>Sicherheit</strong> ................................................... 476<br />
IP-Adressensicherheit .............................................. 476<br />
Portsicherheit .................................................... 479<br />
Hostheadersicherheit . .............................................. 479<br />
Einfache pfadbasierte <strong>Sicherheit</strong> ......................................... 480<br />
Definieren und Einschränken des physischen Pfads . ....................... 480<br />
Standarddokument oder Verzeichnissuche? .............................. 483<br />
Authentifizierung und Autorisierung . ..................................... 484<br />
Anonyme Authentifizierung ......................................... 485<br />
Standardauthentifizierung ........................................... 486<br />
Clientzertifikatzuordnung ........................................... 487<br />
Digestauthentifizierung . ............................................ 490<br />
ASP.NET-Identitätswechsel . ......................................... 490<br />
Formularauthentifizierung . .......................................... 491<br />
<strong>Windows</strong>-Authentifizierung ......................................... 492<br />
Dem <strong>Server</strong> vertrauen .............................................. 493<br />
Weitere <strong>Sicherheit</strong>saspekte für IIS . .................................... 495<br />
Zusammenfassung ................................................... 500<br />
Weitere Informationen ................................................ 501<br />
Stichwortverzeichnis . ................................................. 503<br />
<strong>Die</strong> Autoren ........................................................ 523
Danksagungen<br />
<strong>Die</strong> Autoren möchten einer Reihe von Leuten danken, die bei diesem Buch geholfen haben.<br />
Zahlreiche Personen haben während der Entstehung des Buchs wertvolle Beiträge geleistet<br />
und dafür gesorgt, dass hohe Qualitätsstandards eingehalten wurden.<br />
Chase Carpenter, Aaron Margosis, Paul Young, Pablo F. Matute, Dana Epp, Charlie Russel,<br />
Wolfgang Schedlbauer, Nick Gillot, Steve Riley, John Michener, Greg Cottingham, Austin<br />
Wilson, Chris Black, Ed Wilson, Erin Bourke-Dunphy, Kirk Soluk, Lara Sosnosky, Lee<br />
Walker, Tal Sarid, Dan Harman, Richard B. Ward.<br />
Und insbesondere Mitch Tulloch, unser Fachlektor, der jede einzelne Zeile in diesem Buch<br />
gelesen hat; Becka McKay, unsere Korrektorin, die fantastische Arbeit dabei geleistet hat,<br />
die Stile 12 unterschiedlicher Autoren zu vereinheitlichen; Devon Musgrave, der das Projekt<br />
ins Rollen brachte und sicherstellte, dass uns klar war, was von uns erwartet wurde; Maureen<br />
Zimmerman, die uns dazu brachte, fertig zu werden, und das sogar halbwegs im Zeitplan;<br />
und schließlich Martin DelRe, der viel mehr Arbeit hatte als sonst, weil er es mit<br />
12 unterschiedlichen Autoren zu tun hatte.<br />
XIII
Einleitung<br />
Falls es Ihnen ähnlich geht wie uns, sind Sie gerade ziemlich aufgeregt. Nein, nicht weil wir<br />
dieses Buch fertigbekommen haben, sondern weil das bedeutet, dass es ein neues Betriebssystem<br />
zu erforschen gibt! Selbst wenn Sie sich nicht von solchen Dingen aus der Ruhe<br />
bringen lassen, halten Sie das umfassende Werk zu <strong>technische</strong>r <strong>Sicherheit</strong> für <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> in Händen.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ist die neueste Version des zentralen <strong>Server</strong>betriebssystems von<br />
Microsoft. Es wurde eine Menge Arbeit aufgewendet, um sicherzustellen, dass es nicht nur<br />
hohe Qualität aufweist, sondern auch die <strong>Sicherheit</strong>sfeatures besitzt, die eine sichere Bereitstellung<br />
ermöglichen. <strong>Die</strong>ses Buch soll Ihnen als Begleiter und Führer dienen, während Sie<br />
diese Features erforschen und untersuchen, wie Sie damit bessere <strong>Die</strong>nste zur Verfügung<br />
stellen oder sich selbst das Leben erleichtern können. Das Buch beschreibt dabei Features,<br />
die niemals zuvor für das Zielpublikum IT-Experten dokumentiert wurden.<br />
<strong>Die</strong>ses Buch enthält alle <strong>technische</strong>n Details, die Sie in einer <strong>technische</strong>n <strong>Referenz</strong> erwarten.<br />
Es wurde von 12 Weltklasseexperten verfasst, von denen jeder als Autorität in seinem oder<br />
ihrem Fachgebiet gilt. Insgesamt haben die verschiedenen Autoren über 20 Bücher verfasst.<br />
In erster Linie sind und bleiben sie aber IT-Experten.<br />
Überblick über das Buch<br />
Das Buch hat 17 Kapitel, die in drei Abschnitte untergliedert sind:<br />
Teil I: Grundlagen der <strong>Windows</strong>-<strong>Sicherheit</strong><br />
Kapitel 1, »Subjekte, Benutzer und andere Akteure« <strong>Die</strong>ses Kapitel beschreibt, wie<br />
Benutzer und andere »Subjekte« in <strong>Windows</strong> verwaltet werden.<br />
Kapitel 2, »Authentifizierung und Authentifizierungsprotokolle« Sobald ein Subjekt<br />
identifiziert ist, muss es diese Identifizierung authentifizieren. <strong>Die</strong>ses Kapitel beschreibt,<br />
wie die Authentifizierung in <strong>Windows</strong> funktioniert.<br />
Kapitel 3, »Objekte: Was Sie wollen« Benutzer greifen auf Objekte wie zum Beispiel<br />
Dateien oder Registrierungsschlüssel zu. Das bedeutet, dass diese Objekte geschützt<br />
werden müssen. <strong>Die</strong>ses Kapitel beschreibt, wie der Schutz verwirklicht wird.<br />
Kapitel 4, »Grundlagen der Benutzerkontensteuerung« Microsoft hat die Benutzerkontensteuerung<br />
(User Account Control, UAC) in <strong>Windows</strong> Vista eingeführt. Falls<br />
Sie in erster Linie <strong>Server</strong>administrator sind, müssen Sie vor allem wissen, welche Rolle<br />
die UAC bei der Verwaltung Ihrer <strong>Server</strong> spielt. Falls Sie allerdings auch andere Aufgaben<br />
im IT-Bereich übernehmen, müssen Sie wissen, wie Sie mithilfe der UAC Ihr Netzwerk<br />
schützen können. <strong>Die</strong>ses Kapitel beschreibt, wie das geht.<br />
Kapitel 5, »<strong>Windows</strong>-Firewalls« <strong>Die</strong> primäre Firewall in <strong>Windows</strong> ist die <strong>Windows</strong>-<br />
Firewall mit erweiterter <strong>Sicherheit</strong>. <strong>Die</strong>ses Kapitel beschreibt, wie sie in <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong> arbeitet.<br />
Kapitel 6, »<strong>Die</strong>nste« Wenn ein Prozess unabhängig davon ausgeführt werden muss,<br />
ob ein Benutzer angemeldet ist oder nicht, wird dieser Prozess als <strong>Die</strong>nst installiert.<br />
<strong>Die</strong>nste bilden daher eine empfindliche Angriffsfläche auf Ihren Computern. Somit ist<br />
wichtig, dass Sie ihre <strong>Sicherheit</strong>saspekte kennen.<br />
XV
XVI Einleitung<br />
Kapitel 7, »Gruppenrichtlinien« Wenn Sie <strong>Windows</strong>-Netzwerke betreiben, wäre es<br />
Unsinn, auf den Einsatz von Gruppenrichtlinien zu verzichten. <strong>Die</strong> meisten <strong>Sicherheit</strong>sänderungen,<br />
die wir an Systemen vornehmen, werden mithilfe von Gruppenrichtlinien<br />
durchgeführt.<br />
Kapitel 8, »Überwachung« Der Nutzen von <strong>Sicherheit</strong> ist begrenzt, wenn Sie nicht<br />
beweisen können, wer was getan hat. Überwachung ist eine unverzichtbare Komponente<br />
aller <strong>Sicherheit</strong>smaßnahmen. <strong>Die</strong>ses Kapitel beschreibt im Detail, wie Überwachung in<br />
<strong>Windows</strong> funktioniert.<br />
Teil II: Implementieren von Identitäts- und Zugriffssteuerung mit<br />
Active Directory<br />
Kapitel 9, »Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong>«<br />
Jeder kann eine Active Directory-Bereitstellung implementieren, aber wenn diese Bereitstellung<br />
tatsächlich die <strong>Sicherheit</strong> Ihres Netzwerks verbessern soll, sind echte Fähigkeiten<br />
gefordert. <strong>Die</strong>ses Kapitel zeigt, wie Sie wirkungsvolle <strong>Sicherheit</strong>smaßnahmen<br />
implementieren.<br />
Kapitel 10, »Implementieren der Active Directory-Zertifikatdienste« Public-Key-<br />
Infrastrukturen (PKI, Infrastruktur mit öffentlichen Schlüsseln) werden von vielen Administratoren<br />
als unnötige Komplikation betrachtet. Das stimmt einfach nicht. Für viele<br />
(wenn nicht sogar die meisten) Umgebungen sind sie eine nötige Komplikation. <strong>Die</strong>ses<br />
Kapitel beschreibt, was an der PKI in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> neu ist.<br />
Kapitel 11, »Implementieren der Active Directory-Rechteverwaltungsdienste«<br />
Active-Directory-Rechteverwaltungsdienste-<strong>Server</strong> arbeiten mit Active Directory-Domänencontrollern<br />
zusammen, um Benutzeridentitäten zu überprüfen, Verschlüsselungsschlüssel<br />
als Reaktion auf Benutzeranforderungen auszustellen, Entschlüsselungsschlüssel<br />
für jedes Dokument zu speichern und die Entschlüsselungsschlüssel weiterzuleiten,<br />
wenn Benutzer, die autorisiert sind, ein bestimmtes Dokument zu öffnen, dies anfordern.<br />
Teil III: <strong>Sicherheit</strong>sszenarien<br />
Kapitel 12, »Schützen von <strong>Server</strong>rollen« An <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wird Ihnen als<br />
eines der ersten Dinge auffallen, dass die alten Methoden zum Installieren von Anwendungen<br />
entfernt wurden. Stattdessen erhalten Sie den <strong>Server</strong>-Manager, der auf Basis von<br />
sogenannten Rollen arbeitet. In diesem Kapitel erfahren Sie, welche Auswirkungen das<br />
auf die <strong>Sicherheit</strong> hat und wie Sie <strong>Server</strong> mithilfe von Rollen schützen.<br />
Kapitel 13. »Patchverwaltung« Leider muss jeder <strong>Server</strong> hin und wieder aktualisiert<br />
werden. Keine Software ist vollkommen, schließlich handelt es sich dabei um das komplexeste<br />
Gebilde, das die Menschheit je geschaffen hat. <strong>Die</strong> Patchverwaltung ist nicht<br />
einfach, aber wenn Sie über die richtigen Werkzeuge und ein gutes Verfahren verfügen,<br />
können Sie die Belastung deutlich verringern.<br />
Kapitel 14, »Schützen des Netzwerks« Bei jedem Computer hängt die <strong>Sicherheit</strong> von<br />
etwas oder jemandem ab. <strong>Die</strong>se Abhängigkeiten zu verwalten, ist wahrscheinlich das<br />
wichtigste, was Sie für den Schutz Ihres Netzwerks tun können. In diesem Kapitel beschreiben<br />
wir Abhängigkeiten, zeigen, wie Sie Gefahrenmodelle für Ihr Netzwerk entwickeln,<br />
und führen Sie in eines der wertvollsten <strong>Sicherheit</strong>skonzepte ein, das heutzutage<br />
zur Verfügung steht: <strong>Server</strong>isolierung.
Dokumentkonventionen XVII<br />
Kapitel 15, »Schützen von Zweigstellen« Einer der Bereiche, in denen <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> wichtige neue <strong>Sicherheit</strong>sfeatures einführt, ist der Betrieb von Zweigstellen.<br />
<strong>Die</strong>ses Kapitel zeigt, wie Sie alle diese Neuerungen nutzen.<br />
Kapitel 16, »Aspekte für kleine Unternehmen« <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> steht in mehr<br />
Versionen zur Verfügung als jedes andere <strong>Server</strong>betriebssystem, das Microsoft je entwickelt<br />
hat. Zwei davon sind speziell auf die besonderen <strong>Sicherheit</strong>sanforderungen kleiner<br />
und mittelgroßer Unternehmen zugeschnitten. Falls Sie ein Netzwerk in einem kleinen<br />
Unternehmen betreiben, liefert Ihnen dieses Kapitel wertvolle Informationen.<br />
Kapitel 17, »Schützen von <strong>Server</strong>anwendungen« <strong>Die</strong> meisten <strong>Server</strong> haben die<br />
Aufgabe, irgendeine Anwendung zur Verfügung zu stellen. <strong>Die</strong>ses Buch kann nicht annähernd<br />
jede einzelne Anwendung abdecken, die auf einem <strong>Server</strong> laufen kann. Aber<br />
Microsoft liefert die Anwendungsplattform IIS 7.0 in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> mit. <strong>Die</strong>ses<br />
Kapitel zeigt, wie Sie die <strong>Sicherheit</strong> in dieser Komponente verwalten.<br />
Online-Informationsquellen Sobald neues oder aktualisiertes Material zur Verfügung steht, das dieses<br />
Buch ergänzt, wird es online auf der Microsoft Press-Online-<strong>Windows</strong> <strong>Server</strong>- und -Client-Website veröffentlicht.<br />
Zu den Dingen, die Sie dort möglicherweise finden, gehören unter anderem Aktualisierungen zum<br />
Buchinhalt, die auf Basis der endgültigen Version von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> erstellt wurden, Artikel, Links<br />
zu begleitendem Inhalt, Errata oder Beispielkapitel. <strong>Die</strong>se Website steht demnächst in englischer Sprache<br />
unter http://www.microsoft.com/learning/books/online/serverclient zur Verfügung und wird regelmäßig aktualisiert.<br />
Dokumentkonventionen<br />
In diesem Buch werden als besondere Hinweise auf bestimmte Themen folgende Konventionen<br />
verwendet.<br />
Leserhinweise<br />
<strong>Die</strong> folgende Tabelle beschreibt, wie in diesem Buch auf nützliche Details hingewiesen<br />
wird:<br />
Leserhinweis Bedeutung<br />
Hinweis Weist auf die Bedeutung eines bestimmten Konzepts oder auf Ausnahmen hin.<br />
Wichtig Weist Sie auf wichtige Informationen hin.<br />
Vorsicht Weist Sie auf schwerwiegende Folgen hin, die sich aus der Durchführung oder dem Unterlassen einer<br />
bestimmten Arbeit für Benutzer, System, Datenintegrität und so weiter ergeben können.<br />
Auf der CD Weist Sie auf ein Skript, Tool, eine Vorlage oder sonstige Hilfsmittel auf der Begleit-CD hin, die Sie bei<br />
der Durchführung der beschriebenen Aufgabe unterstützen.
XVIII Einleitung<br />
Textblöcke<br />
<strong>Die</strong> folgenden Textblöcke vertiefen bestimmte Aspekte von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und<br />
geben Ihnen zusätzliche Hinweise und Tipps:<br />
Textkasten Bedeutung<br />
Direkt von der Quelle/<br />
Direkt aus der Praxis<br />
Beiträge, in denen Microsoft-Experten oder MVPs (Most Valuable Professionals) bestimmte<br />
Aspekte von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> vertiefen oder Hinweise zur Verwaltung der <strong>Sicherheit</strong><br />
oder zur Fehlerbehebung geben.<br />
So funktioniert’s Ausführlichere Beschreibungen zur Funktionsweise von ausgewählten <strong>Windows</strong> <strong>Server</strong>-<br />
Features.<br />
Befehlszeilenbeispiele<br />
<strong>Die</strong> folgenden Konventionen werden dazu verwendet, Befehlszeilenbeispiele in diesem<br />
Buch darzustellen:<br />
Element Bedeutung<br />
Fettschrift Zeichen, die vom Benutzer eingegeben werden (beachten Sie bei Eingaben, in denen zwischen<br />
Groß- und Kleinbuchstaben unterschieden wird, die genaue Schreibweise).<br />
Kursivschrift Variablen, für die ein bestimmter Wert eingegeben werden muss. Mit Dateiname ist zum<br />
Beispiel ein beliebiger gültiger Dateiname gemeint.<br />
nichtproportionale Wird für Codebeispiele und Ausgaben verwendet, die auf der Befehlszeile erfolgen.<br />
Schrift<br />
%SystemRoot% Prozentzeichen werden für Umgebungsvariablen verwendet.<br />
Begleit-CD<br />
<strong>Die</strong> Begleit-CD ist eine wichtige Ergänzung dieses Buchs, sie enthält nützliche Werkzeuge.<br />
<strong>Die</strong> CD hat folgenden Inhalt:<br />
Elevation Tools<br />
<strong>Die</strong> UAC hat das Verwalten von Systemen zweifellos komplexer gemacht. Ebenso zweifellos<br />
war diese Veränderung längst fällig, weil wir unsere Computer heutzutage anders nutzen.<br />
Als Administratoren müssen wir aber manchmal Dateien ändern, auf die nur Administratoren<br />
Zugriff haben. Oder wir müssen in einer Eingabeaufforderung schnell in einen bestimmten<br />
Ordner wechseln. <strong>Die</strong>ser Satz von Tools erweitert den <strong>Windows</strong>-Explorer um etliche<br />
Funktionen, die über einen Klick mit der rechten Maustaste zur Verfügung stehen (Abbildung<br />
E.1). Vor allem können Sie mit der rechten Maustaste auf irgendeinen Ordner klicken,<br />
den Befehl Elevate Explorer Here wählen und die Anhebungseingabeaufforderungen bestätigen.<br />
Daraufhin wird ein <strong>Windows</strong>-Explorer-Fenster geöffnet, das unter einem vollständigen<br />
administrativen Token läuft und den ausgewählten Speicherort anzeigt. Außerdem ist<br />
das Tool Elevate.exe enthalten, das die Rechte jeder beliebigen Anwendung aus einer Eingabeaufforderung<br />
heraus anheben kann.
Abbildung E.1 Wenn Sie die Elevation Tools installieren, erhalten Sie beim Klick mit der rechten<br />
Maustaste eine Reihe neuer Befehle im Kontextmenü von <strong>Windows</strong>-Explorer<br />
Begleit-CD XIX<br />
Passgen<br />
Passgen ist ein Tool, mit dem Sie Kennwörter für das eingebaute Administratorkonto und<br />
<strong>Die</strong>nstkonten im gesamten Netzwerk verwalten können. Es soll Ihnen dabei helfen sicherzustellen,<br />
dass Sie für das Administratorkonto einmalige Kennwörter konfiguriert haben.<br />
Außerdem kann es Kennwörter für beliebige Konten einstellen und <strong>Die</strong>nste so konfigurieren,<br />
dass sie unter diesen Konten gestartet werden.<br />
Verwaltungsskripts<br />
<strong>Die</strong> CD enthält außerdem einen Satz von Skripts zur Verwaltung von <strong>Windows</strong>. Darunter<br />
finden Sie ein Skript, das Konfigurationsinformationen von einem Computer abruft, inklusive<br />
der installierten Software. Alle diese Skripts setzen <strong>Windows</strong> PowerShell voraus. Folgende<br />
Skripts sind auf der CD enthalten:<br />
CreateLocalUser.ps1<br />
Erstellt einen lokalen Benutzer auf einem lokalen oder Remotecomputer.<br />
EvaluateServices.ps1<br />
Zählt <strong>Die</strong>nste auf einem lokalen oder Remotecomputer. Anschließend erstellt es einen Bericht<br />
darüber, wie viele <strong>Die</strong>nste jeweils automatisch starten, manuell gestartet werden müssen<br />
oder deaktiviert sind. Es zählt auch, wie viele Konten benutzt werden: SYSTEM, LOKA-<br />
LER DIENST, NETZWERKDIENST und benutzerdefinierte Konten. Schließlich gibt es noch<br />
detaillierte Informationen aus. Mit einer Option können Sie den Bericht anzeigen lassen,<br />
sobald er fertig ist.
XX Einleitung<br />
FindAdmin.ps<br />
Listet die Mitglieder der lokalen Gruppe Administratoren auf einem bestimmten Computer<br />
auf.<br />
FindServiceAccounts.ps1<br />
Identifiziert <strong>Die</strong>nste und ihre Startkonten auf einem lokalen oder Remotecomputer. <strong>Die</strong>ses<br />
Skript kann eine vollständige Liste aller <strong>Die</strong>nste und ihrer Konten für einen oder mehrere<br />
Computer zusammenstellen.<br />
ListUserLastLogon.ps1<br />
<strong>Die</strong>ses Skript listet auf, wann sich ein bestimmter Benutzer das letzte Mal an einer lokalen<br />
oder Remotedomäne angemeldet hat. Über den Parameter -user können Sie mehrere Benutzer<br />
angeben.<br />
LocateDisabledUsers.ps1<br />
Sucht deaktivierte Benutzer in einer lokalen oder Remotedomäne.<br />
LocateLockedOutUsers.ps1<br />
Sucht gesperrte Benutzer in einer lokalen oder Remotedomäne.<br />
LocateOldComputersNotLogon.ps1<br />
Sucht in einer lokalen oder Remotedomäne alle Computerkonten, die sich für die angegebene<br />
Zahl von Tagen nicht angemeldet haben.<br />
LocateOldUsersNotLogOn.ps1<br />
Sucht in einer lokalen oder Remotedomäne nach Benutzerkonten, die sich längere Zeit nicht<br />
mehr bei dieser Domäne angemeldet haben.<br />
LookUpUACEvents.ps1<br />
Listet Benutzerkontensteuerungsereignisse auf einem lokalen oder Remotecomputer auf.<br />
ScanForSpecificSoftware.ps1<br />
Sucht nach bestimmter Software.<br />
ScanForSpecificUpdate.ps1<br />
Sucht auf einem lokalen oder Remotecomputer nach bestimmten Updates. Das Skript listet<br />
auch alle Updates auf, die auf dem Computer installiert sind.<br />
ScanConfig.ps1<br />
Erstellt eine Liste mit folgenden Informationen: installierte Softwareupdates, ActiveX-Objekte,<br />
Browserhilfsobjekte, Netzwerkschnittstellen, Proxyeinstellungen, Autostart, <strong>Die</strong>nste,<br />
nicht signierte Treiber und Firewallrichtlinie.<br />
UnlockLockedOutUsers.ps1<br />
Hebt die Sperre für gesperrte Benutzerkonten wieder auf.<br />
WhoIs.ps1<br />
Ruft Whois-Informationen von einem Internet-Whois-<strong>Server</strong> ab.
Begleit-CD XXI<br />
E-Book<br />
Falls Sie das Buch lieber als elektronische Version lesen, die auch eine Volltextsuche ermöglicht,<br />
finden Sie eine entsprechende englischsprachige Datei auf der CD.<br />
Materialien zu einzelnen Kapiteln<br />
Zu manchen Kapiteln stehen zusätzliche Dokumente oder Tools zur Verfügung. Im jeweiligen<br />
Buchtext wird darauf hingewiesen, dass Sie diese Materialien auf der CD finden.<br />
Links zu Tools, die im Buch erwähnt werden<br />
Statt Ihnen Versionen von Tools zu liefern, die bereits veraltet sind, wenn Sie dieses Buch<br />
kaufen, haben wir Links zu Tools bereitgestellt, die als Downloads zur Verfügung stehen.<br />
<strong>Die</strong>s betrifft folgende Tools, die im Buch mehrfach erwähnt werden oder anderweitig nützlich<br />
sind:<br />
<strong>Windows</strong> PowerShell<br />
<strong>Windows</strong> PowerShell ist eine neue Befehlszeilenshell und Skriptsprache, die für die Systemadministration<br />
und -automatisierung entwickelt wurde. PowerShell baut auf dem .NET<br />
Framework auf. IT-Experten und Entwickler können damit die Administration von <strong>Windows</strong><br />
und Anwendungen steuern und automatisieren. <strong>Windows</strong> PowerShell steht unter http://www.<br />
microsoft.com/downloads/details.aspx?FamilyID=c6ef4735-c7de-46a2-997a-ea58fdfcba63<br />
(für 32-Bit-Editionen) beziehungsweise http://www.microsoft.com/downloads/details.aspx<br />
?FamilyID=af37d87d-5de6-4af1-80f4-740f625cd084 (für 64-Bit-Editionen) zur Verfügung.<br />
Process Explorer<br />
Viele Beispiele in diesem Buch zeigen den Process Explorer, ein erstaunliches Tool, das<br />
Ihnen mehr über die Vorgänge im Inneren Ihres Computers verrät, als Sie für möglich halten.<br />
Process Explorer steht unter http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx<br />
zur Verfügung.<br />
Microsoft Network Monitor<br />
<strong>Die</strong> neueste Version von Microsoft Microsoft Network Monitor ist ein enorm leistungsfähiges<br />
und nützliches Netzwerkverwaltungs- und -problembehandlungstool. Sie können damit<br />
den gesamten Netzwerkverkehr verfolgen, der in und aus Ihrem Computer fließt. Er ist ein<br />
unverzichtbares Werkzeug für jeden Administrator. Der Network Monitor steht unter der<br />
Adresse http://www.microsoft.com/downloads/info.aspx?na=22&p=2&SrcDisplayLang=<br />
en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d<br />
18b1d59d-f4d8-4213-8d17-2f6dde7d7aac%26DisplayLang%3den zum Download bereit.<br />
Privbar<br />
Privbar ist eine Symbolleiste für <strong>Windows</strong>-Explorer und Internet Explorer, die Ihnen anzeigt,<br />
ob Sie Administrator oder Standardbenutzer sind. Wie in Abbildung E.1 weiter oben<br />
zu sehen, ist Privbar in Kombination mit den Elevation Tools besonders nützlich, weil es<br />
Ihnen auf einen Blick verrät, ob die Benutzeroberfläche, mit der Sie arbeiten, unter einem
XXII Einleitung<br />
Administratorkonto läuft. Leider funktioniert die Version, die momentan zur Verfügung<br />
steht, zwar unter <strong>Windows</strong> Vista, aber nicht in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. Privbar steht unter<br />
http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/195350.aspx zur Verfügung.<br />
Digitale Inhalte für E-Book-Leser Falls Sie eine rein elektronische Edition dieses Buchs gekauft haben,<br />
können Sie ausgewählte Inhalte aus der Begleit-CD der gedruckten Ausgabe abrufen. Besuchen Sie<br />
http://go.microsoft.com/fwlink/?LinkId=108240, um den herunterladbaren Inhalt zu erhalten. <strong>Die</strong>ser Inhalt ist<br />
immer auf dem neuesten Stand und steht allen Lesern zur Verfügung.<br />
Systemvoraussetzungen<br />
Um die Begleit-CD zu diesem Buch nutzen zu können, brauchen Sie einen Computer, der<br />
folgende Mindestanforderungen erfüllt:<br />
Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, <strong>Windows</strong> Vista, <strong>Windows</strong> <strong>Server</strong> 2003 oder <strong>Windows</strong><br />
XP<br />
1-GHz-Prozessor mit 32-Bit- (x86) oder 64-Bit-Architektur (x64) (abhängig von den<br />
Mindestanforderungen des Betriebssystems)<br />
1 GByte Hauptspeicher (abhängig von den Mindestanforderungen des Betriebssystems)<br />
Eine Festplattenpartition mit mindestens 1 GByte freiem Speicherplatz<br />
Ein geeignetes Anzeigegerät<br />
Tastatur<br />
Maus oder anderes Zeigegerät<br />
Optisches Laufwerk zum Lesen von CD-ROMs<br />
Viele der Tools stellen zusätzliche Anforderungen. Einige haben folgende wichtige Systemvoraussetzungen:<br />
Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> oder <strong>Windows</strong> Vista<br />
<strong>Windows</strong> PowerShell 1.x<br />
Eine Netzwerkverbindung<br />
Informationen zu den Systemvoraussetzungen der einzelnen Tools finden Sie in der jeweiligen<br />
Dokumentation.
Support für dieses Buch XXIII<br />
Support für dieses Buch<br />
<strong>Die</strong>ses Buch und die Begleit-CD wurden mit großer Sorgfalt erstellt. Korrekturen zum Buch<br />
bietet Microsoft Press unter folgender Webadresse:<br />
http://www.microsoft.com/germany/mspress/support/<br />
Wenn Sie Kommentare, Fragen oder Anregungen zum Buch oder zur Begleit-CD haben, die<br />
sich nicht durch eine Abfrage der Knowledge Base beantworten lassen, wenden Sie sich an<br />
Microsoft Press:<br />
Per E-Mail (in englischer Sprache):<br />
rkinput@microsoft.com<br />
Per Post:<br />
Microsoft Press<br />
Betrifft: <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> <strong>Sicherheit</strong> <strong>–</strong> <strong>Die</strong> <strong>technische</strong> <strong>Referenz</strong><br />
Konrad-Zuse-Straße 1<br />
85716 Unterschleißheim<br />
Wenn Sie Ersatz für eine fehlerhafte Begleit-CD erhalten möchten, können Sie eine E-Mail<br />
an presscd@microsoft.com senden.<br />
Beachten Sie bitte, dass unter den genannten Adressen kein Produktsupport geleistet wird.<br />
Informationen über den Produktsupport finden Sie auf der Microsoft-Produktsupportwebsite<br />
unter folgender Adresse:<br />
http://support.microsoft.com
T E I L I<br />
Grundlagen der <strong>Windows</strong>-<strong>Sicherheit</strong><br />
In diesem Teil:<br />
Kapitel 1: Subjekte, Benutzer und andere Akteure ............................. 3<br />
Kapitel 2: Authentifizierung und Authentifizierungsprotokolle ...................... 17<br />
Kapitel 3: Objekte: Was Sie wollen . ....................................... 57<br />
Kapitel 4: Grundlagen der Benutzerkontensteuerung ........................... 91<br />
Kapitel 5: Firewall und Netzwerkzugriffsschutz . ............................... 115<br />
Kapitel 6: <strong>Die</strong>nste ................................................... 151<br />
Kapitel 7: Gruppenrichtlinien ............................................ 185<br />
Kapitel 8: Überwachung ............................................... 217
K A P I T E L 1<br />
Subjekte, Benutzer und andere Akteure<br />
Von Jesper M. Johansson<br />
In diesem Kapitel:<br />
<strong>Die</strong> Beziehung von Subjekt, Objekt und Aktion . ............................... 3<br />
Typen von <strong>Sicherheit</strong>sprinzipalen . ........................................ 4<br />
<strong>Sicherheit</strong>s-IDs ..................................................... 12<br />
Zusammenfassung .................................................. 16<br />
Weitere Informationen ................................................ 16<br />
Im Wesentlichen lässt sich alles, was mit <strong>Sicherheit</strong> zusammenhängt, auf Subjekte (engl.<br />
subject) und Objekte (engl. object) reduzieren. Objekte sind die Dinge, die Sie schützen, und<br />
Subjekte sind die Dinge, vor denen Sie die Objekte schützen. Subjekte und Objekte werden<br />
bei Authentifizierung (beweisen, wer Sie sind), Autorisierung (Zugriff auf etwas gewähren)<br />
und Überwachung (verfolgen, wer auf was zugegriffen hat) verwendet. <strong>Die</strong>se Konzepte sind<br />
im Grunde sehr simpel. Subjekte sind Benutzer. Objekte sind Dateien. Authentifizierung,<br />
Autorisierung und Überwachung haben damit zu tun, wie Subjekte und Objekte zusammenspielen.<br />
So war es in der Vergangenheit, und auf manchen einfachen Systemen ist es immer<br />
noch so.<br />
<strong>Windows</strong> unterstützt aber eine sehr leistungsfähige <strong>Sicherheit</strong>ssemantik und hat die Definition<br />
der Begriffe Subjekt und Objekt deutlich erweitert. Ein Subjekt kann viel mehr sein als<br />
ein schlichter Benutzer, und die Abbildung eines Subjekts ist viel komplexer als eine schlichte<br />
Benutzerkennung. <strong>Windows</strong> verweist auf Subjekte auch auf unterschiedliche Arten. Der<br />
Begriff <strong>Sicherheit</strong>sprinzipal (engl. security principal) wird Ihnen oft begegnen. Im <strong>Windows</strong>-Jargon<br />
umfasst ein <strong>Sicherheit</strong>sprinzipal nicht nur das typische Subjekt (was wir uns<br />
als Benutzer vorstellen), sondern auch Gruppen und Computer. Ein <strong>Sicherheit</strong>sprinzipal ist<br />
alles, was eine <strong>Sicherheit</strong>s-ID (Security Identifier, SID) zugewiesen bekommen und die<br />
Berechtigung erhalten kann, auf etwas zuzugreifen. In diesem Kapitel lernen Sie, was für<br />
Dinge <strong>Sicherheit</strong>sprinzipale sein können, wie sie in <strong>Windows</strong>-Betriebssystemen im Allgemeinen<br />
identifiziert werden und was daran in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> neu ist. In Kapitel 3,<br />
»Objekte: Was Sie wollen«, lernen Sie die andere Seite der <strong>Sicherheit</strong> kennen: Objekte.<br />
<strong>Die</strong> Beziehung von Subjekt, Objekt und Aktion<br />
Bei der Verwaltung der <strong>Sicherheit</strong> haben Sie es sehr oft mit der Dreifaltigkeit aus Subjekt/<br />
Objekt/Aktion zu tun. Das Subjekt ist der Akteur, der versucht, irgendeine Aktion an einem<br />
Objekt durchzuführen. Zum Beispiel könnte ein Benutzer versuchen, auf eine Datei zuzugreifen,<br />
wie in Abbildung 1.1 gezeigt.<br />
3
4 Kapitel 1: Subjekte, Benutzer und andere Akteure<br />
Abbildung 1.1 Ein Benutzer versucht, eine Datei zu lesen<br />
Wenn ein Benutzer versucht, die Datei zu lesen, prüft das Betriebssystem, ob Berechtigungen<br />
für das Objekt (die Datei) festgelegt sind, die dem Subjekt (dem Benutzer) erlauben, die<br />
Aktion durchzuführen. Falls Berechtigungen vorhanden sind, die dem Benutzer die Aktion<br />
erlauben, verläuft die Zugriffsanforderung erfolgreich. Falls keine Berechtigungen vorhanden<br />
sind, die dem Subjekt die angeforderte Aktion erlauben, wird die Zugriffsanforderung<br />
abgelehnt. So weit ist alles ganz einfach.<br />
In Kapitel 3 erfahren Sie mehr darüber, wie Berechtigungen und die tatsächlichen Zugriffsprüfungen<br />
funktionieren. In diesem Kapitel konzentrieren wir uns darauf, wie das Subjekt<br />
definiert ist. Wie bereits erwähnt, können unterschiedliche Dinge als Subjekte eingestuft<br />
werden. In den meisten Fällen sind Subjekte Benutzer, aber das ist nicht immer so. Im<br />
nächsten Abschnitt lernen wir die unterschiedlichen Typen von Subjekten kennen, anschließend<br />
sehen wir uns an, wie <strong>Windows</strong> diese Subjekte intern abbildet.<br />
Typen von <strong>Sicherheit</strong>sprinzipalen<br />
Subjekte <strong>–</strong> im Folgenden bezeichnen wir sie nur noch als <strong>Sicherheit</strong>sprinzipale <strong>–</strong> können in<br />
einem <strong>Windows</strong>-System und allgemein in einem <strong>Windows</strong>-Netzwerk viel mehr sein als<br />
schlichte Benutzer. Der Benutzer ist aber nach wie vor das grundlegende Konzept.<br />
Benutzer<br />
Ein Benutzer ist genau das, was das Wort bezeichnet: irgendeine individuelle Entität, die an<br />
einem Computer anmeldet ist. Im Grunde sind alle <strong>Sicherheit</strong>sprinzipale in gewisser Weise<br />
mit Benutzern verknüpft.<br />
In <strong>Windows</strong> gibt es zwei Arten von Benutzern: lokale und Domänenbenutzer. Ein lokaler<br />
Benutzer ist in der Datenbank der lokalen <strong>Sicherheit</strong>skontenverwaltung (Security Accounts<br />
Manager, SAM) auf einem Computer definiert. Jeder <strong>Windows</strong>-Computer hat eine lokale<br />
SAM, die alle Benutzer dieses Computers enthält.<br />
Hinweis Abgesehen von einer wichtigen Ausnahme unterstützen alle <strong>Windows</strong> NT-Betriebssysteme<br />
dieselben grundlegenden <strong>Sicherheit</strong>skonstrukte. Allerdings hat sich die Leistungsfähigkeit der Semantik<br />
vergrößert, insbesondere ab <strong>Windows</strong> 2000. <strong>Die</strong> wichtige Ausnahme ist, dass Active Directory, das in <strong>Server</strong>-Versionen<br />
seit <strong>Windows</strong> 2000 zur Verfügung steht, einen ganz anderen Satz von Features unterstützt<br />
als die Clientversionen und ältere <strong>Windows</strong> NT-Versionen.
Typen von <strong>Sicherheit</strong>sprinzipalen 5<br />
Hinweis Wenn in diesem Buch künftig von »<strong>Windows</strong>-Computern« oder allgemein »<strong>Windows</strong>« die Rede<br />
ist, beziehen wir uns dabei auf alle Computer, die unter einem Betriebssystem der <strong>Windows</strong> NT-Linie laufen.<br />
Dazu gehören:<br />
<strong>Windows</strong> NT 3.1<br />
<strong>Windows</strong> NT 3.5<br />
<strong>Windows</strong> NT 3.51<br />
<strong>Windows</strong> NT 4.0<br />
<strong>Windows</strong> 2000<br />
<strong>Windows</strong> XP<br />
<strong>Windows</strong> <strong>Server</strong> 2003<br />
<strong>Windows</strong> Vista<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Oft wird angenommen, dass Domänencontroller (Domain Controller, DC) keine lokale SAM<br />
und somit keine lokalen Benutzer haben. Das ist falsch. Sogar ein DC hat eine lokale SAM,<br />
aber die Konten in seiner SAM können nur für die Verzeichnisdienstwiederherstellung verwendet<br />
werden. In der Standardeinstellung befinden sich immer zwei Benutzerkonten in der<br />
lokalen SAM: Administrator und Gast. Das Konto Gast ist in der Standardeinstellung immer<br />
deaktiviert.<br />
Hinweis Wenn wir »Administrator« oder »Administratoren« kursiv schreiben, meinen wir damit den Benutzer<br />
beziehungsweise die Gruppe. Wenn wir »Administrator« normal schreiben, meinen wir irgendein<br />
Benutzerkonto oder eine Person, die administrative Privilegien besitzen. Dasselbe gilt für andere Entitäten,<br />
zum Beispiel »Gast« oder »Gast«.<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ist das Konto Administrator standardmäßig aktiviert. (Mit Ausnahme<br />
von <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong>.) Mit diesem Konto müssen Sie sich beim<br />
ersten Mal am Computer anmelden. In <strong>Windows</strong> Vista ist das Konto Administrator standardmäßig<br />
deaktiviert. Es kann nur unter ganz bestimmten Bedingungen benutzt werden. In<br />
beiden Fällen wird dringend empfohlen, dass Sie weitere Konten für jede Person anlegen,<br />
die einen Computer verwaltet. <strong>Die</strong>s ist eine obligatorische Forderung bei praktisch allen<br />
Regularien (Libenson, 2006). Ein Konto für eine Person sollte deren persönliches administratives<br />
Konto sein. Falls die Administratoren den Computer auch für nichtadministrative<br />
Aufgaben einsetzen, sollten sie zusätzlich persönliche nichtadministrative Konten haben.<br />
<strong>Die</strong> andere Art von Konto ist ein Domänenkonto. <strong>Die</strong>se Konten werden auf den Domänencontrollern<br />
der Domäne definiert, und sie können auf allen Computern in der Domäne verwendet<br />
werden. Domänenkonten haben eine viel größere Zahl von Eigenschaften als lokale<br />
Konten, wie in den Abbildungen 1.2 und 1.3 deutlich zu sehen.<br />
Domänenkonten haben eine umfangreichere Semantik, die eine Vielzahl von Attributen für<br />
eine Unternehmensumgebung abdeckt, zum Beispiel Telefonnummern, Organisationsstrukturen,<br />
E-Mail-Konten und so weiter. Domänenkonten sind auch in einem Netzwerk viel<br />
nützlicher, weil sie auf anderen Computern über das Netzwerk benutzt werden können. Und<br />
ihnen können Berechtigungen für beliebige Computer überall im Netzwerk zugewiesen werden.<br />
Indem Konten in der Domäne definiert werden, wird auch die Verwaltung einfacher.<br />
In Kapitel 9, »Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong>«, finden Sie<br />
weitere Informationen über Active Directory.
6 Kapitel 1: Subjekte, Benutzer und andere Akteure<br />
Abbildung 1.2 Das Eigenschaftenfenster für ein lokales Konto<br />
Abbildung 1.3 Das Eigenschaftenfenster für ein Domänenkonto
Typen von <strong>Sicherheit</strong>sprinzipalen 7<br />
Computer<br />
Ein Computer ist im Grunde nur eine andere Art von Benutzer. Das gilt besonders in Active<br />
Directory, wo es sich aus dem verwendeten Vererbungsmodell ergibt. <strong>Die</strong> Vererbungsstruktur<br />
für einen Computer sehen Sie in Abbildung 1.4.<br />
Abbildung 1.4 <strong>Die</strong> Vererbungshierarchie in Active Directory zeigt<br />
die Verwandtschaft zwischen Benutzern und Computern<br />
In Abbildung 1.4 dürften Ihnen mehrere interessante Punkte auffallen. Erstens sind alle<br />
Klassen in Active Directory von einer Basisklasse namens Top abgeleitet. Sogar Top selbst ist<br />
als von Top abgeleitete Klasse aufgeführt. Zweitens ist die Klasse User (Benutzer) von der<br />
Klasse organizationalPerson (Person im Unternehmen) abgeleitet. <strong>Die</strong> Klasse organizationalPerson<br />
wiederum ist indirekt von Top abgeleitet. Drittens <strong>–</strong> und das ist der interessanteste<br />
Teil <strong>–</strong> ist die Klasse Computer von der Klasse User abgeleitet. Anders ausgedrückt: Objektorientiert<br />
gesprochen ist ein Computer eine Art Benutzer. <strong>Die</strong>se Vermenschlichung von<br />
Computern ist sogar recht sinnvoll, weil Computer ebenfalls als Subjekte behandelt werden<br />
müssen und daher fast dieselben Attribute haben wie Benutzer.<br />
Gruppen<br />
Wie Sie wissen, ist ein Subjekt etwas, das versucht, auf ein Objekt zuzugreifen. Das Betriebssystem<br />
behandelt diesen Zugriffsversuch, indem es die Berechtigungen des Objekts<br />
überprüft. Schon in den Anfängen der Betriebssystemsentwicklung war den Entwicklern<br />
klar, dass es furchtbar umständlich wäre, jedem einzelnen Benutzer, der ein Objekt benötigt,<br />
Berechtigungen für dieses Objekt zuweisen zu müssen. Um dieses Problem zu lösen, erlaubten<br />
sie es, dass Benutzer Mitglieder von Gruppen werden. Auf diese Weise können wir Berechtigungen<br />
nicht nur einzelnen Benutzern, sondern auch Gruppen zuweisen. Eine Gruppe<br />
(engl. group) ist zwar kein Benutzer, aber eine Art von <strong>Sicherheit</strong>sprinzipal, weil sie eine<br />
Kennung haben kann, genau wie Benutzer und Computer. In <strong>Windows</strong> kann ein Benutzer<br />
Mitglied vieler Gruppen sein, und einem Objekt können Berechtigungen für viele Gruppen<br />
zugewiesen werden. Auch verschachtelte Gruppen sind erlaubt, allerdings gelten hier bestimmte<br />
Einschränkungen.
8 Kapitel 1: Subjekte, Benutzer und andere Akteure<br />
Ein Computer, der kein Domänencontroller ist, hat nur zwei Arten von Gruppen: integrierte<br />
(engl. built-in) und lokale (engl. local), die der Administrator definiert hat. In Active Directory<br />
finden Sie dagegen gleich sechs unterschiedliche Arten von <strong>Sicherheit</strong>sgruppen: integrierte<br />
domänenlokale (engl. built-in domain local), globale (engl. global) und universelle<br />
(engl. universal) Gruppen sowie benutzerdefinierte domänenlokale (engl. user-defined domain<br />
local), globale und universelle Gruppen. Domänenlokale Gruppen können nur Berechtigungen<br />
für Ressourcen in der Domäne zugewiesen bekommen, in der sie definiert sind.<br />
Aber sie können Benutzer, universelle und globale Gruppen aus beliebigen vertrauenswürdigen<br />
Domänen oder Gesamtstrukturen sowie domänenlokale Gruppen aus ihrer eigenen<br />
Domäne enthalten.<br />
Eine globale Gruppe kann nur Benutzer und globale Gruppen aus der Domäne enthalten,<br />
in der sie definiert wurde. Aber ihr können Berechtigungen für Ressourcen in beliebigen<br />
Domänen innerhalb der Gesamtstruktur, deren Mitglied die Domäne ist, oder innerhalb einer<br />
beliebigen vertrauenden Gesamtstruktur zugewiesen werden.<br />
Eine universelle Gruppe kann Benutzer und universelle oder globale Gruppen aus einer<br />
beliebigen Domäne enthalten. Einer universellen Gruppe können Berechtigungen für Ressourcen<br />
in einer beliebigen vertrauenden Domäne oder Gesamtstruktur zugewiesen werden.<br />
Während in einem eigenständigen <strong>Server</strong> in der Standardeinstellung nur zwei Gruppen vorhanden<br />
sind (Administratoren und Gäste), enthält eine Domäne eine relativ große Zahl von<br />
Gruppen aller drei Typen. Abbildung 1.5 zeigt die Standardgruppen in einer Domäne. Alle<br />
werden als <strong>Sicherheit</strong>sgruppen (engl. security group) bezeichnet, das bedeutet, dass ihnen<br />
Berechtigungen zugewiesen werden können. <strong>Sicherheit</strong>sgruppen dürfen Sie nicht mit Verteilergruppen<br />
(engl. distribution group) verwechseln, die von Microsoft Exchange <strong>Server</strong> eingesetzt<br />
werden, um Benutzer zu Gruppen zusammenzufassen, damit Sie E-Mail an mehrere<br />
Empfänger gleichzeitig senden können. Beide sind in Active Directory definiert.<br />
Abbildung 1.5 Im Active Directory-Container Users sind standardmäßig zahlreiche Gruppen definiert
Typen von <strong>Sicherheit</strong>sprinzipalen 9<br />
Neben den Gruppen, die in der Domäne definiert sind und die nur in Domänen vorhanden<br />
sind, gibt es auch integrierte lokale Gruppen. <strong>Die</strong>s sind Gruppen, die in einer anderen Hierarchie<br />
und von einer anderen Autorität definiert werden als Domänengruppen. Integrierte<br />
Gruppen gelten nicht per se als Domänengruppen. Vielmehr sind sie in allen oder zumindest<br />
einigen <strong>Windows</strong>-Computern vordefiniert, unabhängig davon, ob dieser Computer ein Domänencontroller<br />
ist oder nicht. Sie sind auf allen <strong>Windows</strong>-Computern vorhanden, sind aber<br />
in Active Directory auf Domänencontrollern definiert. Zum Beispiel ist die Gruppe Administratoren<br />
eine integrierte Gruppe, die auf allen <strong>Windows</strong>-Computern vorhanden ist; aber Domänen-Admins<br />
ist eine Domänengruppe, die nur in Domänen vorhanden ist. Abbildung 1.6<br />
zeigt 21 integrierte Gruppen auf einem Testcomputer.<br />
Abbildung 1.6 Zusätzliche integrierte Gruppen liegen im Container Builtin<br />
Wenn Sie versuchen, Berechtigungen für ein Objekt zuzuweisen, finden Sie noch mehr<br />
Gruppen. Auf einem normalen Domänencontroller gibt es nicht weniger als 63(!) Gruppen<br />
und integrierte <strong>Sicherheit</strong>sprinzipale, wie in Abbildung 1.7 zu sehen.<br />
<strong>Die</strong> restlichen 26 Gruppen sind abstrakte Konzepte, die für eine dynamische Gruppe<br />
von <strong>Sicherheit</strong>sprinzipalen stehen. Sie werden normalerweise als Spezialidentitäten (engl.<br />
special identity) bezeichnet.
10 Kapitel 1: Subjekte, Benutzer und andere Akteure<br />
Abbildung 1.7 Auf einem Domänencontroller finden Sie nicht weniger<br />
als 63 Gruppen und integrierte <strong>Sicherheit</strong>sprinzipale<br />
Abstrakte Konzepte (Anmeldegruppen)<br />
Neben den halbwegs konkret fassbaren Gruppen, die Sie auf einem Computer definieren,<br />
gibt es noch etliche weitere, wie Sie in Abbildung 1.7 sehen können. <strong>Die</strong>s sind Gruppen, die<br />
für irgendeinen dynamischen Aspekt eines <strong>Sicherheit</strong>sprinzipals stehen, zum Beispiel wie<br />
ein Benutzer oder ein anderer <strong>Sicherheit</strong>sprinzipal sich angemeldet hat. Beispielsweise umfasst<br />
die Gruppe INTERAKTIV aus Abbildung 1.7 alle Benutzer, die sich an der Konsole des<br />
Computers oder über Terminaldienste angemeldet haben. Dagegen enthält die Gruppe NETZ-<br />
WERK alle Benutzer, die sich über das Netzwerk angemeldet haben. Definitionsgemäß kann<br />
ein Benutzer nur jeweils in einer dieser Gruppen Mitglied sein, und die Mitgliedschaft wird<br />
bei der Anmeldung festgelegt. Sie können diese Gruppen nutzen, um allen Benutzern, die<br />
sich auf bestimmte Weise anmelden, Berechtigungen zuzuweisen.<br />
Sie werden noch andere Gruppen dieser Art kennenlernen. Besonders wichtig sind die<br />
Gruppen Jeder und Authentifizierte Benutzer. Wie der Name der Gruppe Jeder andeutet,<br />
umfasst sie alle Benutzer, die auf diesen Computer zugreifen; allerdings sind völlig anonyme<br />
Benutzer seit <strong>Windows</strong> XP keine Mitglieder dieser Gruppe. Gäste sind aber Mitglieder<br />
der Gruppe Jeder. <strong>Die</strong> Gruppe Authentifizierte Benutzer wird zwar ebenfalls dynamisch<br />
zusammengestellt, sie enthält aber nur Benutzer, die tatsächlich authentifiziert wurden. Das<br />
bedeutet, dass Gäste keine Mitglieder von Authentifizierte Benutzer sind. Das ist der einzige<br />
Unterschied. Weil das einzige Gastkonto, das im Betriebssystem vorhanden ist, aber deaktiviert<br />
ist, gibt es keinen funktionellen Unterschied zwischen Authentifizierte Benutzer und<br />
Jeder, sofern Sie das Gastkonto nicht von Hand aktivieren. Trotzdem haben sich viele
Typen von <strong>Sicherheit</strong>sprinzipalen 11<br />
Administratoren mit der Sorge um den Schlaf gebracht, dass »jeder auf der Welt Berechtigungen<br />
auf meinem <strong>Server</strong> hat«, und sehr drastische Schritte unternommen, um die Berechtigungen<br />
so zu ändern, dass dieses vermeintliche Problem behoben wird. Meist führen diese<br />
Veränderungen direkt in eine Katastrophe. Es gibt absolut keinen Grund, solche Änderungen<br />
vorzunehmen. Wenn Sie wollen, dass Gäste Berechtigungen auf Ihrem Computer erhalten,<br />
dann müssen Sie das Gastkonto aktivieren. Wenn Gäste keine Berechtigungen auf Ihrem<br />
Computer erhalten sollen, lassen Sie das Gastkonto deaktiviert. Falls Gäste Berechtigungen<br />
haben sollen, müssen Sie Berechtigungen für Jeder verwalten. Andernfalls unterscheidet<br />
sich Jeder überhaupt nicht von Authentifizierte Benutzer. Manche Administratoren erklären,<br />
dass sie diese Änderungen vornehmen, um eine »gestaffelte Verteidigung« zu implementieren.<br />
Das wäre ein triftiges Argument, wenn wir »gestaffelte Verteidigung« als »Änderungen,<br />
die wir anders nicht begründen können« definieren. Es ist schlicht so, dass diese Änderungen<br />
praktisch keinen <strong>Sicherheit</strong>sgewinn bringen, aber ein sehr großes Risiko bedeuten. Lassen<br />
Sie die Standardeinstellungen in Ruhe. Falls Sie das nicht überzeugt, sollten Sie sich den<br />
Microsoft Knowledge Base-Artikel 885409 durchlesen. Er erklärt im Wesentlichen, dass der<br />
umfassende Austausch des Berechtigungssystems Ihren Supportvertrag ungültig macht.<br />
Wenn Sie das tun, bauen Sie quasi Ihr eigenes Betriebssystem, und Microsoft kann nicht<br />
mehr garantieren, dass dieses Gebilde funktioniert.<br />
Ebenfalls wichtig ist der Unterschied zwischen Benutzer, einer integrierten Gruppe, und<br />
Authentifizierte Benutzer. Der Unterschied ist die offensichtliche Tatsache, dass Authentifizierte<br />
Benutzer eben alle Benutzer umfasst, die sich am Computer authentifiziert haben,<br />
darunter auch Benutzer in anderen Domänen; Benutzer, die Mitglieder von anderen lokalen<br />
Gruppen als Benutzer sind; und Benutzer, die bei überhaupt keinen Gruppen Mitglied sind<br />
(ja, so etwas gibt es). Anders ausgedrückt: <strong>Die</strong> Gruppe Benutzer ist viel, viel restriktiver als<br />
Authentifizierte Benutzer. Trotzdem hat dieser Autor Organisationen erlebt, die versuchten,<br />
Berechtigungen für Benutzer durch Berechtigungen für Authentifizierte Benutzer zu ersetzen,<br />
um ihre Systeme besser zu schützen. Es muss hoffentlich nicht explizit gesagt werden,<br />
dass diese Versuche meist kläglich scheiterten, sowohl was die <strong>Sicherheit</strong> betrifft als auch<br />
insbesondere die Stabilität.<br />
<strong>Die</strong>nste<br />
Seit Jahren tobt eine Dauerdebatte über hostbasierte Firewalls. Viele Leute, eifrig unterstützt<br />
von den Herstellern der entsprechenden Produkte, argumentieren, dass hostbasierte Firewalls<br />
Filter für ausgehenden Verkehr haben müssen, wenn sie etwas taugen sollen. Nur so<br />
ließe sich der Rest des Netzwerks vor einem befallenen Computer schützen. Objektivere<br />
Experten weisen darauf hin, dass ein Computer, sobald er befallen ist, definitionsgemäß<br />
schon Malware enthält. Und diese Malware kann die hostbasierte Firewall umgehen oder<br />
gleich ganz abschalten.<br />
Falls die Malware natürlich auf den Computer gelangt ist, indem sie über eine Anwendung<br />
eingedrungen ist, die mit geringen Privilegien läuft, gilt dieses Argument nicht mehr. In den<br />
letzten Jahren hat Microsoft viel Zeit aufgewendet, um <strong>Die</strong>nste so zu gestalten, dass sie mit<br />
geringeren Privilegien laufen. Aber ein <strong>Die</strong>nst, der als ein bestimmter Benutzer läuft, kann<br />
trotzdem beliebige andere <strong>Die</strong>nste steuern, die als derselbe Benutzer laufen, und kann alles<br />
tun, was diese anderen <strong>Die</strong>nste können. Falls also <strong>Die</strong>nst A Verkehr durch die Firewall senden<br />
kann, <strong>Die</strong>nst B aber nicht, kann <strong>Die</strong>nst B <strong>Die</strong>nst A übernehmen und Verkehr senden,<br />
sofern beide als derselbe Benutzer laufen.
12 Kapitel 1: Subjekte, Benutzer und andere Akteure<br />
Um dieses Problem zu beseitigen, brauchte Microsoft einen Weg, einem Prozess (genauer<br />
gesagt: einem <strong>Die</strong>nst) Berechtigungen zuzuweisen. Aus diesem Grund wurden <strong>Die</strong>nste ab<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> selbst <strong>Sicherheit</strong>sprinzipale. Jeder <strong>Die</strong>nst hat jetzt<br />
eine Kennung, die verwendet werden kann, um Berechtigungen zuzuweisen. Indem wir die<br />
Berechtigungen für diese Kennung als eingeschränkt kennzeichnen (Kapitel 3 enthält weitere<br />
Informationen zu eingeschränkten Zugriffssteuerungslisteneinträgen), können wir sogar<br />
sicherstellen, dass ein bestimmter <strong>Sicherheit</strong>sprinzipal vorhanden sein muss, wenn wir eine<br />
Anforderung senden, und zwar unabhängig davon, welche anderen Berechtigungen für das<br />
Objekt aufgeführt sind. Plötzlich wurde es in bestimmten Situationen sinnvoll, ausgehende<br />
Filter für hostbasierte Firewalls zu verwenden. Das ist der Grund, warum die Firewall in<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> jetzt Unterstützung dafür bietet. In der Standardeinstellung<br />
blockiert sie ausgehenden Verkehr von <strong>Die</strong>nsten, außer auf Ports, die von diesen<br />
<strong>Die</strong>nsten gebraucht werden. Das ist offen gesagt das Maximum an <strong>Sicherheit</strong>, die eine hostbasierte<br />
Firewall jemals bieten kann.<br />
<strong>Sicherheit</strong>s-IDs<br />
Bisher haben wir die Frage der IDs elegant ignoriert. Ich habe weiter oben erwähnt, dass ein<br />
<strong>Sicherheit</strong>sprinzipal eine Entität ist, die eine <strong>Sicherheit</strong>s-ID (Security Identifier, SID) haben<br />
kann, aber ich habe niemals definiert, was eine <strong>Sicherheit</strong>s-ID ist. Einfach ausgedrückt ist<br />
eine SID eine (hauptsächlich) numerische Darstellung eines <strong>Sicherheit</strong>sprinzipals. <strong>Die</strong> SID<br />
ist in erster Linie das, was intern vom Betriebssystem benutzt wird. Wenn Sie einem Benutzer,<br />
einer Gruppe, einem <strong>Die</strong>nst oder irgendeinem anderen <strong>Sicherheit</strong>sprinzipal Berechtigungen<br />
für ein Objekt gewähren, schreibt das Betriebssystem die SID und die Berechtigungen<br />
in die Zugriffssteuerungsliste (Access Control List, ACL).<br />
Abbildung 1.8 Eine SID ist aus mehreren erforderlichen Elementen aufgebaut
<strong>Sicherheit</strong>s-IDs 13<br />
Komponenten einer SID<br />
Eine SID setzt sich aus mehreren erforderlichen Elementen zusammen. Abbildung 1.8 zeigt<br />
die unterschiedlichen Komponenten einer SID.<br />
SIDs beginnen immer mit dem Text »S«, das kennzeichnet sie als SID. Sie enden immer mit<br />
einer relativen ID (Relative Identifier, RID). Dazwischen haben sie 0 oder mehr Teilautoritäten<br />
(engl. sub-authority). Der zweite Wert in einer SID ist immer die Version, momentan ist<br />
das immer 1.<br />
SID-Autoritäten<br />
Nach dem Präfix »S-1-« kann sich der Rest von SIDs stark unterscheiden, er beginnt aber<br />
immer mit einer ID-Autorität (engl. identifier authority), die angibt, welche Entität die SID<br />
ausgestellt hat. Tabelle 1.1 zeigt die momentan verwendeten ID-Autoritäten.<br />
Tabelle 1.1 ID-Autoritäten für SIDs<br />
ID-Autorität Beschreibung<br />
0 SECURITY_NULL_SID_AUTHORITY. Wird für Vergleiche verwendet, wenn die ID-Autorität unbekannt ist.<br />
1 SECURITY_WORLD_SID_AUTHORITY. Wird benutzt, um SIDs zusammenzustellen, die für alle Benutzer<br />
stehen. Zum Beispiel lautet die SID für die Gruppe Jeder S-1-1-0; sie wird erstellt, indem die WORLD-RID<br />
(0) an diese ID-Autorität angehängt wird, sodass alle Benutzer aus dieser Autorität gewählt werden.<br />
2 SECURITY_LOCAL_SID_AUTHORITY. Wird benutzt, um SIDs für Benutzer zusammenzustellen, die sich<br />
an einem lokalen Terminal anmelden.<br />
3 SECURITY_CREATOR_SID_AUTHORITY. Wird benutzt, um SIDs zusammenzustellen, die für den Ersteller<br />
oder Besitzer eines Objekts stehen. Zum Beispiel ist die SID für Ersteller-Besitzer S-1-3-0; sie wird<br />
generiert, indem die Ersteller-Besitzer-RID (ebenfalls 0) an diese ID-Autorität angehängt wird. Falls S<br />
-1-3-0 in einer vererbbaren ACL verwendet wird, wird sie in untergeordneten Objekten, die diese ACL<br />
erben, durch die SID des Besitzers ersetzt. S-1-3-1 ist die SID von ERSTELLERGRUPPE, sie hat<br />
dieselbe Funktion, wird aber durch die SID der primären Gruppe des Erstellers ersetzt.<br />
5 SECURITY_NT_AUTHORITY. Das Betriebssystem selbst. SIDs, die mit S-1-5 beginnen, wurden von<br />
einem Computer oder einer Domäne ausgestellt. <strong>Die</strong> meisten SIDs, die Sie sehen, beginnen mit S-1-5.<br />
Direkt von der Quelle: <strong>Die</strong> Geschichte der SIDs<br />
Das ursprüngliche Konzept der SID nutzte sämtliche Schichten der Hierarchie aus. Jede<br />
Schicht enthielt eine neue Teilautorität, und ein Unternehmen konnte beliebig komplizierte<br />
Hierarchien für die ausstellenden Autoritäten entwerfen. Jede Schicht konnte wiederum<br />
zusätzliche Autoritäten unter sich selbst anlegen. In der Praxis bedeutete das eine Menge<br />
Aufwand bei Setup und Bereitstellung, und es ließ das Verwaltungsmodell sogar noch<br />
altertümlicher wirken. Das Konzept, Identitäten in beliebig tiefer Verschachtelung zu<br />
erstellen, wurde schon in frühen Entwicklungsstadien zu Grabe getragen. Allerdings war<br />
die Struktur damals bereits zu tief integriert, als dass sie hätte entfernt werden können.
14 Kapitel 1: Subjekte, Benutzer und andere Akteure<br />
In der Praxis entwickelten sich zwei Muster für SIDs. Bei integrierten, vordefinierten<br />
Identitäten wurde die Hierarchie auf eine Tiefe von zwei oder drei Teilautoritäten verkürzt.<br />
Bei echten Identitäten von anderen Prinzipalen wurde die ID-Autorität auf den<br />
Wert 5 gesetzt, und der Satz der Teilautoritäten wurde auf 4 festgelegt.<br />
Richard B. Ward, Architect<br />
<strong>Windows</strong> Core<br />
Hinter der ID-Autorität folgt in der SID die Zahl der Teilautoritäten. <strong>Die</strong> letzte davon wird<br />
als relative ID bezeichnet. <strong>Die</strong>s ist die ID des eindeutigen <strong>Sicherheit</strong>sprinzipals innerhalb<br />
des Bereichs, in dem die SID definiert wurde. Am Beispiel der folgenden SID sollte das<br />
etwas klarer werden:<br />
S-1-5-21-1534169462-1651380828-111620651-500<br />
Wie Sie sehen, beginnt die SID mit S-1-5, sie wurde also von <strong>Windows</strong> NT ausgestellt. <strong>Die</strong><br />
erste Teilautorität ist 21 (hexadezimal 0x15). <strong>Die</strong> 21 definiert dies als eine <strong>Windows</strong> NT-<br />
SID, bei der nicht garantiert wird, dass sie weltweit einmalig ist. Sie ist einmalig innerhalb<br />
der Domäne, in der sie ausgestellt wurde, aber irgendwo anders kann es SIDs geben, die<br />
genau denselben Wert haben. <strong>Die</strong> erste der Teilautoritäten ist sehr oft eine bekannte (engl.<br />
well-known) Teilautorität. Tabelle 1.2 listet die wichtigsten bekannten Teilautoritäten auf.<br />
Tabelle 1.2 Bekannte Teilautoritäten<br />
Teilautorität Beschreibung<br />
5 SIDs werden für Anmeldesitzungen ausgestellt, damit jeder Anwendung, die in einer bestimmten Anmeldesitzung<br />
läuft, Berechtigungen zugewiesen werden können. Bei diesen SIDs hat die erste Teilautorität<br />
den Wert 5, sie haben daher die Form S-1-5-5-x-y.<br />
6 Wenn sich ein Prozess als <strong>Die</strong>nst anmeldet, bekommt er eine spezielle SID in seinem Token, die darauf<br />
hinweist. <strong>Die</strong>se SID hat die Teilautorität 6, und sie lautet immer S-1-5-6.<br />
21 SECURITY_NT_NON_UNIQUE. Bezeichnet Benutzer- und Computer-SIDs, bei denen nicht garantiert ist,<br />
dass sie weltweit einmalig sind.<br />
32 SECURITY_BUILTIN_DOMAIN_RID. Bezeichnet integrierte SIDs. Zum Beispiel lautet die bekannte SID für<br />
die integrierte Gruppe Administratoren S-1-5-32-544.<br />
80 SECURITY_SERVICE_ID_BASE_RID. Bezeichnet SIDs für <strong>Die</strong>nste.<br />
Unsere SID enthält anschließend drei weitere Teilautoritäten: 1534169462, 1651380828 und<br />
111620651. <strong>Die</strong>se Werte haben isoliert betrachtet keine implizite Bedeutung, aber in ihrer<br />
Kombination geben Sie die Domäne oder den Computer an, die diese SID ausgestellt haben.<br />
<strong>Die</strong> SID für die Domäne lautet demnach S-1-5-21-1534169462-1651380828-111620651, und<br />
alle SIDs, die in dieser Domäne ausgestellt werden, beginnen mit diesem Wert und enden<br />
mit einer eindeutigen RID für den Benutzer oder Computer, für die sie stehen. In diesem Fall<br />
endet die SID mit 500. <strong>Die</strong>s ist eine bekannte RID für das integrierte Konto Administrator.<br />
501 ist die bekannte RID für das integrierte Konto Gast, und 502 die bekannte RID für das<br />
Kerberos Ticket Granting Ticket (krbtgt).
<strong>Sicherheit</strong>s-IDs 15<br />
<strong>Die</strong>nst-SIDs<br />
Wie bereits erwähnt, haben in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> auch <strong>Die</strong>nste immer<br />
eine SID. <strong>Die</strong>nst-SIDs beginnen immer mit S-1-5-80 und enden mit einer Reihe von<br />
Teilautoritäten, die deterministisch aus dem Namen des <strong>Die</strong>nstes abgeleitet werden. Das<br />
bedeutet, dass ein bestimmter <strong>Die</strong>nst auf allen Computern dieselbe SID hat. Es bedeutet<br />
auch, dass Sie die SID für einen beliebigen <strong>Die</strong>nst selbst dann ermitteln können, wenn es<br />
diesen <strong>Die</strong>nst gar nicht gibt. Zum Beispiel können Sie sich ansehen, welche SID ein <strong>Die</strong>nst<br />
namens »foo« hätte, indem Sie den Befehl sc showsid ausführen:<br />
C:\>sc showsid foo<br />
NAME: foo<br />
DIENST-SID: S-1-5-80-2639291829-767035215-3510963033-3734144485-3832470211<br />
Wenn Sie das auf einem Ihrer <strong>Server</strong> probieren, bekommen Sie genau dieselbe SID. Falls<br />
Sie lieber den Anzeigenamen des <strong>Die</strong>nstes verwenden wollen, können Sie NT SERVICE\foo<br />
eingeben.<br />
Bekannte SIDs<br />
Wenn ein Entwickler ein Programm für <strong>Windows</strong> schreibt, muss er oft die SID eines <strong>Sicherheit</strong>sprinzipals<br />
kennen. Normalerweise lassen sich SIDs leicht zusammenstellen, wenn zumindest<br />
die RID bekannt ist, weil sie lediglich an die Computer- oder Domänen-SID angehängt<br />
wird (wie im Fall des Kontos Administrator). Oft ist es aber bequemer, wenn für bestimmte<br />
SIDs eine kürzere und immer gleiche Form zur Verfügung steht. Daher enthält das<br />
<strong>Sicherheit</strong>smodell von <strong>Windows</strong> eine größere Zahl bekannter SIDs (engl. well-known SID).<br />
Das sind SIDs, die auf allen Computern stets gleich sind. Dank dieses <strong>Sicherheit</strong>smodells<br />
sind einige bekannte SIDs auf allen Betriebssystemen identisch. <strong>Die</strong>s sind die SIDs, die mit<br />
S-1-1, S-1-2 oder S-1-3 beginnen. Einige davon wurden bereits weiter oben in diesem Kapitel<br />
erwähnt, zum Beispiel die SID für Ersteller-Besitzer: S-1-3-0.<br />
Daneben enthält <strong>Windows</strong> NT noch viele weitere Definitionen für bekannte SIDs. S-1-5-32<br />
zum Beispiel ist die bekannte SID für die integrierte Domäne. Sie kann wiederum mit einer<br />
bekannten RID kombiniert werden, um eine bekannte SID für ein bestimmtes Konto zu bilden.<br />
Zum Beispiel lautet die SID für die integrierte Gruppe Administratoren, egal ob in einer<br />
Domäne oder auf einem eigenständigen Computer, immer S-1-5-32-544. Tabelle 1.3 führt<br />
einige der wichtigsten domänenrelativen RIDs auf. Im Fall integrierter Gruppen können die<br />
domänenrelativen RIDs mit S-1-5-32 kombiniert werden, um eine SID zu bilden, die auf<br />
allen Computern gültig ist, auf denen dieser Benutzer oder die Gruppe relevant ist. Andere<br />
Konten werden an die Domäne angehängt, um die vollständige SID zu bilden. Das ist zum<br />
Beispiel der Fall bei Domänen-Admins, wo aus der bekannten RID 512 die SID S-1-5-21-<br />
1534169462-1651380828-111620651-512 gebildet wird.<br />
SIDs mögen auf den ersten Blick sehr kompliziert wirken, aber wenn Sie ihren Aufbau erst<br />
einmal kennen, sind sie ganz einfach zu entziffern. Mit etwas Übung können Sie problemlos<br />
erkennen, ob eine SID sich auf einen <strong>Die</strong>nst, einen bekannten Prinzipal oder einen Benutzer<br />
in einer Domäne bezieht. In Kapitel 3 sehen wir uns an, wie mit diesen SIDs Berechtigungen<br />
verwaltet werden.
16 Kapitel 1: Subjekte, Benutzer und andere Akteure<br />
Tabelle 1.3 Bekannte domänenrelative RIDs<br />
RID Beschreibung<br />
500 Administrator<br />
501 Gast<br />
502 Krbtgt<br />
512 Domänen-Admins<br />
513 Domänen-Benutzer<br />
514 Domänen-Gäste<br />
515 Domänencomputer<br />
516 Domänencontroller<br />
544 Integrierte Administratoren<br />
545 Integrierte Benutzer<br />
546 Integrierte Gäste<br />
Zusammenfassung<br />
<strong>Sicherheit</strong>sprinzipale und SIDs bilden die Basis für einen großen Teil der <strong>Windows</strong>-<br />
<strong>Sicherheit</strong>. Daher müssen Sie als Administrator zumindest die Grundlagen ihrer Funktionsweise<br />
verstehen. SIDs sind die grundlegenden Bausteine eines Tokens, das wiederum die<br />
grundlegende Entität bildet für die Prüfung, ob ein Zugriff erlaubt wird. Wenn Sie wissen,<br />
wie diese Komponenten zusammenwirken, und in der Lage sind, Berechtigungen mithilfe<br />
von Benutzern, Gruppen, Domänengruppen und den Anmeldetypen zuzuweisen, können Sie<br />
deutlich effektiver arbeiten und viele Überraschungen vermeiden, wenn Sie sich tiefer in<br />
die <strong>Windows</strong>-<strong>Sicherheit</strong> vorarbeiten.<br />
Weitere Informationen<br />
Libenson, E.: »Controlling Privileged Accounts to Comply with SOX Section 404«.<br />
http://www.s-ox.com/Feature/detail.cfm?articleID=2178.<br />
Microsoft Knowledge Base-Artikel »Empfehlungen zur <strong>Sicherheit</strong>skonfiguration«.<br />
http://support.microsoft.com/kb/885409.
K A P I T E L 2<br />
Authentifizierung und<br />
Authentifizierungsprotokolle<br />
Von Jesper M. Johansson<br />
In diesem Kapitel:<br />
Etwas, das Sie wissen, und etwas, das Sie haben ............................. 17<br />
Speichern der Authentifizierer ........................................... 20<br />
Authentifizierungsprotokolle ............................................ 29<br />
Smartcardauthentifizierung ............................................. 38<br />
Angriffe auf Kennwörter ............................................... 39<br />
Verwalten von Kennwörtern ............................................ 47<br />
Zusammenfassung .................................................. 55<br />
Weitere Informationen ................................................ 55<br />
Aus Kapitel 1, »Subjekte, Benutzer und andere Akteure«, wissen Sie, dass die Akteure in<br />
einem Computer als Subjekte oder Prinzipale bezeichnet werden. Wenn Sie einen Prinzipal<br />
haben, braucht dieser Prinzipal irgendeine Möglichkeit zu beweisen, dass er wirklich ist, wer<br />
er zu sein behauptet. Sehen wir uns einen Fall aus der wirklichen Welt an: Sie wollen in<br />
einem Laden mit einer Kreditkarte etwas kaufen. Und die Verkäufer in diesem Laden wissen<br />
ausnahmsweise tatsächlich, was <strong>Sicherheit</strong> bedeutet. Sie haben Ihre Identität: Sie selbst. Das<br />
Personal im Laden weiß aber nicht, wer Sie sind. Daher fordern sie einen Beweis, also eine<br />
Authentifizierung, dass Sie wirklich sind, wer Sie zu sein behaupten. Als Beweis für Ihre<br />
Identität legen Sie irgendeinen Authentifizierer (engl. authenticator) vor, zum Beispiel Ihren<br />
Personalausweis oder den Reisepass. Das Vorzeigen des Ausweises läuft routinemäßig ab,<br />
als Authentifizierungsprotokoll.<br />
In der virtuellen Welt läuft es ganz ähnlich, allerdings weiß die Entität, bei der Sie sich<br />
authentifizieren müssen, dass eine Unterschrift auf der Rückseite einer Kreditkarte kein<br />
Authentifizierer ist, sie liefert nämlich keinerlei Beweis der Identität. Daher brauchen Sie<br />
eine stärkere Form der Authentifizierung. In diesem Kapitel sehen wir uns an, wie <strong>Windows</strong><br />
Authentifizierer behandelt und welche Authentifizierer es unterstützt.<br />
Etwas, das Sie wissen, und etwas, das Sie haben<br />
Allgemein ausgedrückt gibt es drei Arten von Authentifizierern:<br />
Etwas, das Sie wissen<br />
Etwas, das Sie haben<br />
Etwas, das Sie sind<br />
17
18 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Etwas, das Sie wissen<br />
Ein Geheimnis, das Sie kennen und in vielen Fällen mit dem System teilen, auf das Sie<br />
zugreifen wollen, ist die einfachste und am weitesten verbreitete Form eines Authentifizierers.<br />
Ein Kennwort ist ein gutes Beispiel für etwas, das Sie wissen.<br />
Etwas, das Sie haben<br />
Ein Ding irgendeiner Art, das sich in Ihrem Besitz befindet, ist eine andere Art von Authentifizierer.<br />
Sie authentifizieren sich als Sie selbst, indem Sie beweisen, dass Sie dieses Ding<br />
besitzen. Ein Beispiel ist eine Smartcard (mehr dazu weiter unten in diesem Kapitel) oder<br />
ein RSA-SecurID-Einmalkennwortgerät (http://www.rsa.com/node.aspx?id=1156). <strong>Die</strong>se<br />
Dinge, die Sie besitzen, werden fast immer mit etwas kombiniert, das Sie wissen. Sie können<br />
die Qualität der Authentifizierungsbehauptungen stark verbessern.<br />
Etwas, das Sie sind<br />
Manche Systeme verwenden als Authentifizierer etwas, das Sie sind. <strong>Die</strong> bei Weitem wichtigsten<br />
Vertreter dieser Kategorie sind biometrische Authentifizierer: Dinge, die versuchen,<br />
etwas über Sie zu messen. Beispiele sind Retinascans, Fingerabdrücke, Blutproben und<br />
Stimmerkennung. Manche Leute betrachten es auch als biometrischen Authentifizierer,<br />
wenn der Tipprhythmus bei der Eingabe eines Kennworts ausgewertet wird. Darüber lässt<br />
sich aber streiten: Eigentlich werden nur mehr Parameter zu einem »Etwas, das Sie wissen«-<br />
Faktor ausgewertet. Somit kann die Eingabe leicht aufgezeichnet und von dem System, das<br />
die Eingabe abhört, erneut abgespielt werden, ohne das Subjekt zu verletzen oder Zwang<br />
auszuüben. Daher bietet diese Methode keine echte Zwei-Komponenten-Authentifizierung.<br />
Biometrische Systeme sind von Natur aus ungenau. DNA bietet zwar eine einwandfreie<br />
Identifizierung, aber die meisten Leute reagieren nicht mit Begeisterung, wenn sie sich Blut<br />
abzapfen lassen sollen, nur um einen Computer benutzen zu können. (Bei manchen Computern,<br />
mit denen ich arbeiten musste, hatte ich allerdings schon das Gefühl, dass sie mich bis<br />
auf den letzten Blutstropfen aussaugen.) <strong>Die</strong> meisten biometrischen Faktoren sind nicht<br />
besonders genau. Zum Beispiel gelten Fingerabdrücke als einmalig. Es ist aber fraglich, ob<br />
man genau dasselbe Ergebnis erhält, wenn man mehrere Abdrücke nimmt. Und ob ein Computer<br />
zweimal dasselbe Analyseergebnis zum selben Abdruck liefert, darf auch bezweifelt<br />
werden. Daher arbeiten biometrische Authentifizierungssysteme üblicherweise in einem<br />
Bereich akzeptabler Werte. Wenn Sie Ihre Authentifizierer speichern, sollten Sie sie daher<br />
mehrere Male messen. Auf Basis dieser Daten generiert das System den akzeptablen Bereich<br />
für Ihren Authentifizierer. Um sich erfolgreich zu authentifizieren, müssen die nachfolgenden<br />
Versuche innerhalb dieses Bereichs liegen.<br />
Biometrische Systeme weisen zahlreiche Probleme auf. Erstens: Abgesehen von der Messung<br />
des Tipprhythmus benötigen sie spezielle Hardwaregeräte auf jedem Client, die teilweise<br />
recht lästig sein können. Dasselbe gilt für »Etwas, das Sie haben«-Systeme, zum Beispiel<br />
Smartcards.<br />
Zweitens: Wie weiter oben erwähnt, sind biometrische Methoden ungenau, es wird lediglich<br />
eine annähernde Übereinstimmung benötigt. Bei manchen Methoden kann das verhängnisvoll<br />
sein. Falls sich Ihr biometrische Authentifizierer aus irgendwelchen Gründen geändert<br />
hat, schlägt die Authentifizierung fehl. Falls Sie zum Beispiel Stimmerkennung verwenden,<br />
müssen Sie unter Umständen draußen bleiben, falls Ihre Stimme aufgrund einer Erkältung
Etwas, das Sie wissen, und etwas, das Sie haben 19<br />
oder Erschöpfung anders klingt. Und eine Unachtsamkeit, während Sie am Wochenende<br />
Brennholz an der Kreissäge zuschneiden, könnte die Anmeldung mit dem Abdruck eines<br />
bestimmten Fingers am nächsten Montag schwierig machen.<br />
Drittens betrachten viele Leute die biometrische Authentifizierung als sehr lästig, manche<br />
sogar als gefährlich. Viele Menschen sehen es nicht sonderlich gern, wenn sehr persönliche<br />
Daten wie zum Beispiel Fingerabdrücke auf einem Computersystem gespeichert werden.<br />
Viertens stufen viele <strong>Sicherheit</strong>sexperten biometrische Verfahren als überbewertet ein. <strong>Die</strong><br />
Firmen, die biometrische Systeme verkaufen, stellen vielfach Behauptungen auf, die sich<br />
einfach nicht halten lassen. Nehmen wir als Beispiel ein Unternehmen, das eine Softwarelösung<br />
zum Messen des Tipprhythmus anbietet. Es behauptet, die Kunden vor Geräten zu<br />
schützen, die Tastatureingaben aufzeichnen (sogenannte Keystroke-Logger), sodass es<br />
einem Angreifer nichts mehr nützt, wenn er Kennwörter ausspäht. Das ist unmöglich. Zum<br />
Beispiel muss der Benutzer nach wie vor das Kennwort auf dem Client eintippen, und ein<br />
Keystroke-Logger auf dem Client kann leicht so aufgerüstet werden, dass er genau dieselben<br />
Informationen aufzeichnet, die auch die Biometriesoftware auswertet. <strong>Die</strong>se Daten lassen<br />
sich später einfach abspielen, wodurch eine erfolgreiche Authentifizierung möglich ist. <strong>Die</strong>se<br />
Lösung scheitert nicht nur daran, irgendein Problem bei der Verwendung von Kennwörtern<br />
zu beseitigen, es kommt noch schlimmer: Sie verschärft das Problem, dass Benutzer ihre<br />
Kennwörter stets auswendig wissen müssen, denn dieses Verfahren hebelt Lösungen aus, die<br />
zufällig generierte Kennwörter clientseitig speichern, wie zum Beispiel das Tool Password<br />
Safe (http://passwordsafe.sourceforge.net/).<br />
Fünftens gibt es die verbreitete Fehleinschätzung, dass biometrische Systeme sicher sind,<br />
weil sie untrennbar mit dem Benutzer verknüpft sind und nicht wie ein Notizzettel mit Kennwörtern<br />
in der Gegend herumliegen können. Dabei wird aber vergessen, dass biometrische<br />
Authentifizierungsdaten nicht nur kopiert werden können (zum Beispiel Fingerabdrücke auf<br />
einem Glas), sondern auch die körperlichen Merkmale, die untersucht werden, sich definitiv<br />
entwenden lassen. Es sind bereits Fälle dokumentiert, in denen sich <strong>Die</strong>be mit biometrischen<br />
Authentifizierern davongemacht haben (Kent, 2005). Auch weniger brutale Methoden, an<br />
Authentifizierer zu gelangen, werden genutzt. Zum Beispiel hat der deutsche Chaos Computer<br />
Club vor einigen Jahren ein Trainingsvideo veröffentlicht, das zeigt, wie man einen synthetischen<br />
Fingerabdruck erzeugt, indem man einen Abdruck von einer Flasche abnimmt.<br />
Und schließlich gibt es relativ wenige Auswahlmöglichkeiten für biometrische Authentifizierer.<br />
Zum Beispiel haben Sie bei einem System, das mit Fingerabdrücken arbeitet, nur<br />
zehn Finger zur Auswahl. Falls Sie einen davon nicht verwenden können, weil der Abdruck<br />
nicht deutlich ist oder Sie ein ungeschickter Heimwerker sind, bleiben nur neun. Das macht<br />
es schwierig, regelmäßig Ihre Authentifizierer zu wechseln, weil Sie bald keine mehr übrig<br />
haben. Weil die Gefahr, dass Anmeldeinformationen ausgespäht und erneut abgespielt werden,<br />
sehr real ist, stellt die begrenzte Auswahl von Authentifizierern eine Bedrohung dar, die<br />
Sie nicht ignorieren dürfen.<br />
Aus diesen Gründen verzichtet <strong>Windows</strong> auf eine eingebaute Unterstützung biometrischer<br />
Authentifizierung. Fremdhersteller bieten Add-On-Soft- und -Hardware für biometrische<br />
Authentifizierung an. Microsoft selbst verkauft ebenfalls ein Fingerabdruckgerät, weist aber<br />
deutlich darauf hin, dass dieses Gerät nicht ausreichend <strong>Sicherheit</strong> für den Unternehmenseinsatz<br />
bietet. Aus den weiter oben erläuterten Gründen gilt aber generell, dass biometrische<br />
Authentifizierer sich nicht für den Unternehmenseinsatz eignen und nicht benutzt werden<br />
sollten, um wichtige persönliche oder Firmendaten zu schützen. Für den Unternehmens-
20 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
einsatz können Smartcards und Kennwörter viel sicherer, flexibler und einfacher in die üblichen<br />
Abläufe zu integrieren sein. <strong>Die</strong> restlichen Abschnitte dieses Kapitels beschäftigen<br />
sich daher mit diesen zwei Technologien.<br />
Speichern der Authentifizierer<br />
Immer wenn Sie einen Authentifizierer einsetzen, müssen Sie ihn in irgendeiner Form speichern,<br />
damit er mit den Daten verglichen werden kann, die der Prinzipal während der Authentifizierung<br />
eingibt. <strong>Die</strong> Speichermethode hängt einerseits von der Art des Authentifizierers<br />
und andererseits davon ab, wie der Entwickler das System entworfen hat. In diesem<br />
Abschnitt sehen wir uns unterschiedliche Wege an, Authentifizierer in <strong>Windows</strong> zu speichern.<br />
Dabei konzentrieren wir uns auf Kennwörter, weil sie häufiger und in mehr Variationen<br />
eingesetzt werden als Smartcards.<br />
Smartcards arbeiten mit Zertifikaten. (Weitere Informationen über Zertifikate finden Sie in<br />
Kapitel 10, »Implementieren der Active Directory-Zertifikatdienste«.) <strong>Die</strong> Smartcard selbst<br />
enthält den geheimen Teil des Zertifikats. Das Authentifizierungssystem, in diesem Fall eine<br />
Active Directory-Domäne, enthält den öffentlichen Teil. Wenn Sie Smartcards verwenden,<br />
müssen daher keine geheimen Daten zur Smartcard in Domänencontrollern (Domain Controller,<br />
DC) gespeichert werden. Daher sind Smartcards in einigen Aspekten einfacher zu<br />
verwalten als Kennwörter.<br />
Hinweis <strong>Die</strong> meisten Systeme, die Smartcards nutzen, hinterlegen die geheimen Schlüssel an einer<br />
zentralen Stelle. <strong>Windows</strong> bietet ebenfalls diese Möglichkeit. Wenn Sie dieses Verfahren nutzen, verschaffen<br />
Sie sich die Möglichkeit, auf alle Geheimnisse zuzugreifen, die durch Smartcardanmeldeinformationen<br />
geschützt werden, zum Beispiel für forensische Maßnahmen. Das bedeutet aber auch, dass Sie wichtige<br />
Geheimnisse in Ihrem Netzwerk schützen müssen.<br />
In praktisch allen heute verfügbaren Implementierungen sind Kennwörter Geheimnisse, die<br />
mehreren Parteien bekannt sind. Das Geheimnis, mit dem sich der Benutzer anmeldet, ist<br />
dasselbe, mit dem der authentifizierende <strong>Server</strong> den Zugriff dieses Benutzers authentifiziert.<br />
Das bedeutet, dass Kennwörter wichtige Geheimnisse sind und geschützt werden müssen.<br />
Bei den ersten Computersystemen, an denen mehrere Benutzer arbeiten konnten, wurden<br />
Kennwörter einfach im Klartext in einer Textdatei gespeichert. <strong>Die</strong> Kennwörter in solchen<br />
Systemen waren niemals dazu gedacht, Personen den Zugang zu verwehren, weil ohnehin<br />
nur eine kleine Gruppe von Leuten Zugriff auf das System hatte. Sie sollten in erster Linie<br />
steuern, welche Umgebung Sie angezeigt bekamen. Schließlich wurden die Kennwörter in<br />
der Kennwortdatei aber verschlüsselt oder als Hashwerte gespeichert.<br />
Verschlüsselung und Hashwerte<br />
Das englische Wort für Verschlüsselung lautet »encryption«, und es ist vom Wort »cryptography«<br />
(dt. Kryptografie) abgeleitet. Kryptografie bedeutet wörtlich »verborgene<br />
Schrift«. Verschlüsselung ist der Vorgang, bei dem mithilfe von Kryptografie Text versteckt<br />
oder etwas aus einer lesbaren Form (normalerweise als Klartext oder engl. plaintext<br />
bezeichnet) in eine unverständliche Form (den sogenannten Ciphertext) konvertiert<br />
wird. Entschlüsselung ist der umgekehrte Vorgang, etwas wird von Ciphertext in Klartext<br />
konvertiert.
Speichern der Authentifizierer 21<br />
Verschlüsselung nutzt also Kryptografie, um etwas in eine unlesbare, aber wieder herstellbare<br />
Form zu konvertieren. Das Berechnen eines Hashwerts (engl. hashing) hängt<br />
damit eng zusammen. Dabei wird Klartext in eine unlesbare, hier aber nicht wieder herstellbare<br />
Form konvertiert. Ein Hash kann zum Beispiel als Prüfsumme verwendet werden,<br />
um zwei Klartextabschnitte zu vergleichen. Falls beide denselben Hashwert generieren,<br />
können Sie relativ sicher sein, dass die beiden Texte identisch sind. Ein Hashwert ist<br />
auch normalerweise kleiner (im Vergleich zum Klartext) als ein Ciphertext. Daher eignen<br />
sich Hashwerte sehr gut, um Dinge wie Kennwörter zu speichern.<br />
<strong>Die</strong> meisten Unix-Systeme verwenden diese Form der Kennwortspeicherung, allerdings mit<br />
zwei leichten Veränderungen. Erstens enthält die Kennwortdatei, normalerweise heißt sie<br />
/etc/passwd, jetzt keine Kennworthashwerte mehr, sondern nur Benutzernamen und -IDs.<br />
<strong>Die</strong> eigentlichen Hashwerte sind in der Shadow-Kennwortdatei gespeichert, zum Beispiel in<br />
/etc/passwd.shadow. Während die Kennwortdatei selbst von allen gelesen werden kann, ist<br />
der Zugriff auf die Shadow-Datei den Superusern vorbehalten.<br />
Und weil Kennworthashwerte ursprünglich für alle lesbar in der Datei /etc/passwd standen,<br />
mussten sie vor Vergleichsangriffen geschützt werden. Nehmen wir zum Beispiel an, Sie<br />
und ich haben Benutzerkonten auf demselben Computer. Mein Kennwort ist »pas$wort!«,<br />
und wie es der Zufall so will, haben Sie genau dasselbe Kennwort. Mit einem einfachen<br />
Hashwert würde für uns beide derselbe Kennworthashwert in der Datei /etc/passwd gespeichert.<br />
Ich könnte aus der Datei meinen Hashwert auslesen und dann nach anderen Konten<br />
suchen, die denselben Hashwert haben. Falls ich solche Konten finde, weiß ich, dass sie<br />
dasselbe Kennwort haben wie ich. Das darf nicht zugelassen werden. <strong>Die</strong> Lösung besteht<br />
darin, einen zufällig generierten Saltwert zum Kennwort hinzuzufügen, bevor der Hashwert<br />
berechnet wird. Ein Saltwert (engl. salt) ist einfach ein zufälliger Wert, der zum Kennwort<br />
hinzugefügt wird, bevor der Hash berechnet wird. Der Saltwert wird im Klartext in der<br />
Kennwortdatenbank gespeichert. Selbst wenn nun zwei Kennwörter identisch sind, haben<br />
sie unterschiedlich Saltwerte und liefern daher unterschiedliche Hashwerte. Abbildung 2.1<br />
zeigt diesen Ablauf.<br />
Abbildung 2.1 Weil das Kennwort vor dem Speichern in der Kennwortdatei<br />
mit einem Saltwert versehen wird, ist es vor Vergleichsangriffen geschützt
22 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
<strong>Windows</strong> nutzt Abwandlungen aller dieser Techniken, um Kennwörter zu speichern. In den<br />
folgenden Abschnitten beschreibe ich die fünf wichtigsten Methoden, wie <strong>Windows</strong> Kennwörter<br />
speichert, mit denen Benutzer in <strong>Windows</strong> selbst authentifiziert werden.<br />
LM-Hash<br />
Der LM-Hash ist genau genommen gar kein Hashwert, auch wenn er einige Eigenschaften<br />
damit gemeinsam hat. Es handelt sich um eine unidirektionale Funktion, die intern normalerweise<br />
als LMOWF (LanManager One-Way Function) bezeichnet wird. In <strong>Windows</strong> Vista<br />
und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wird der LM-Hash in der Standardeinstellung nicht gespeichert,<br />
und er wird auch nicht bei einer Netzwerkauthentifizierung benutzt. In älteren <strong>Windows</strong>-<br />
Versionen wurde der LM-Hash dagegen normalerweise gespeichert und übertragen. Daher<br />
sollten Sie wissen, wie der LM-Hash funktioniert. Beachten Sie, dass sowohl <strong>Windows</strong> Vista<br />
als auch <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> so konfiguriert werden können, dass sie den LM-Hash speichern<br />
und die Authentifizierung damit durchführen. Davon wird aber abgeraten, weil die<br />
Algorithmen Schwächen aufweisen.<br />
Direkt aus der Praxis: Geschichte von LM-Hash<br />
Der LM-Hash wurde von Microsoft erstmals im LAN-Manager-Netzwerkbetriebssystem<br />
verwendet, dessen letzte Version Anfang der 1990er erschien. LAN Manager lief über<br />
dem Betriebssystem OS/2 von IBM. Als 1993 die erste Version von <strong>Windows</strong> NT erschien,<br />
war es unverzichtbar, dass dieses neue Betriebssystem Interoperabilität mit LAN<br />
Manager bot, damit für die Organisationen, die in LAN Manager investiert hatten, diese<br />
Investitionen nicht plötzlich wertlos wurden. Das bedeutete aber auch, dass <strong>Windows</strong> NT<br />
trotz seiner weit besseren <strong>Sicherheit</strong>sstrukturen im Vergleich zu LAN Manager unter<br />
Schwächen von Entwurfsentscheidungen litt, die für LAN Manager Mitte der 1980er getroffen<br />
wurden. Im Jahr 2006 lieferte Microsoft das erste Betriebssystem aus, das den<br />
LAN-Manager-Kennworthashingmechanismus standardmäßig deaktivierte. <strong>Die</strong>ser<br />
Mechanismus kann aber nach wie vor aktiviert werden. Es dauerte 13 Jahre, bis dieses<br />
Feature in der Standardeinstellung als veraltet abgeschaltet wurde.<br />
Jesper M. Johansson<br />
<strong>Windows</strong> Security MVP<br />
Der LM-Hash wird mithilfe zahlreicher relativ komplizierter Schritte generiert, die Abbildung<br />
2.2 zeigt. Der Prozess beginnt, wenn ein Benutzer ein neues Kennwort anlegt. Das<br />
gesamte Kennwort wird sofort in Großbuchstaben konvertiert. Anders ausgedrückt: Bei<br />
Kennwörtern, die als LM-Hash gespeichert sind, wird nicht zwischen Groß- und Kleinschreibung<br />
unterschieden.<br />
Nachdem das Kennwort in Großbuchstaben konvertiert wurde, wird es auf eine Länge von<br />
14 Zeichen aufgefüllt. Falls das Kennwort bereits länger als 14 Zeichen ist, müsste es in<br />
diesem Schritt theoretisch verkürzt werden, aber in der Praxis schlägt der Prozess einfach<br />
fehl: Es wird kein LM-Hash generiert, falls das Kennwort länger ist als 14 Zeichen. Aus<br />
diesem Grund erhalten Sie eine Warnung, dass die Kompatibilität zu älteren Betriebssystemen<br />
nicht gewährleistet ist, wenn Sie ein Kennwort festlegen, das länger ist als 14 Zeichen.
Abbildung 2.2 Der LM-Hash wird mit einer Reihe komplizierter Schritte generiert<br />
Speichern der Authentifizierer 23<br />
Anschließend wird das Kennwort in zwei Teile zerlegt, die jeweils 7 Zeichen lang sind. Das<br />
ist nötig, weil diese Teile als Schlüssel in einer DES-Verschlüsselung (Data Encryption<br />
Standard) verwendet werden, und DEA (Data Encryption Algorithm), der in DES benutzte<br />
Algorithmus, arbeitet mit 56-Bit-Stücken. <strong>Die</strong>se Stücke werden als Schlüssel verwendet, um<br />
einen festen Wert zu verschlüsseln.<br />
Zuletzt werden die Ergebnisse der beiden DES-Operationen verbunden, und das Ergebnis<br />
wird als LM-Hash gespeichert. Der Hashwert wird entweder in der Datenbank der <strong>Sicherheit</strong>skontenverwaltung<br />
gespeichert (falls es das Kennwort für ein lokales Konto auf einem
24 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
eigenständigen oder Domänenmitgliedscomputer ist) oder im DBCS-Pwd-Attribut des Benutzerobjekts<br />
in Active Directory.<br />
Das erklärt, warum ein Angreifer in der Lage ist, das Kennwort eines Benutzers zu erschließen,<br />
wenn er den Hashwert kennt. Falls die zweite Hälfte des LM-Hash AAD3B435B51404EE<br />
lautet, ist die zweite Hälfte des Kennworts leer, und das Kennwort ist maximal 7 Zeichen<br />
lang. Falls beide Hälften AAD3B435B51404EE lauten, ist das Kennwort leer.<br />
NT-Hash<br />
Als 1993 die erste Version von <strong>Windows</strong> NT erschien, wurde eine neue Methode zum Speichern<br />
von Kennwörtern eingeführt. <strong>Die</strong>ser Mechanismus ist weit simpler als LM-Hash, wie<br />
Abbildung 2.3 zeigt.<br />
Abbildung 2.3 Der NT-Hash ist ein schlichter MD4-Hash<br />
Der NT-Hash (oder NTOWF, wie er intern bezeichnet wird) wird entweder in der SAM oder<br />
im Unicode-PWD-Attribut eines AD-Benutzers gespeichert.<br />
Beachten Sie, dass weder NTOWF noch LMOWF mit einem Saltwert versehen werden.<br />
<strong>Windows</strong> hat für Kennwörter niemals Saltwerte verwendet, aus dem einfachen Grund, weil<br />
die Kennwortdatenbanken niemals von anderen Personen gelesen werden konnten. Daher<br />
war ein Vergleichsangriff nie eine besonders interessante Angriffsart. Um die Datenbanken<br />
lesen zu können, muss der Angreifer ohnehin ein Administrator sein, sodass Computer oder<br />
Domäne bereits vollständig kompromittiert sind. Außerdem haben Authentifizierungssysteme,<br />
die mit einem gemeinsamen Geheimnis arbeiten, eine sehr interessante Eigenschaft,<br />
die wir uns in Kürze ansehen und die für diese Frage relevant ist.
Speichern der Authentifizierer 25<br />
Kennwortverifizierer<br />
Wenn Sie schon in einer <strong>Windows</strong> Active Directory-Umgebung gearbeitet haben, ist Ihnen<br />
wahrscheinlich aufgefallen, dass Sie ein Notebook, das Domänenmitglied ist, mitnehmen<br />
und sich auch dann mit einem Domänenkonto authentifizieren können, wenn Sie gar keine<br />
Verbindung zur Domäne haben. <strong>Die</strong>se erstaunliche Fähigkeit haben Sie dem sogenannten<br />
Kennwortverifizierer (engl. password verifier) zu verdanken. Der Kennwortverifizierer<br />
(auch oft als zwischengespeicherte Anmeldeinformationen oder engl. cached credentials<br />
bezeichnet) ist eine lokale Kopie des Hashwerts Ihres Domänenkennworts, mit dem Sie sich<br />
lokal anmelden können. In Betriebssystemversionen vor <strong>Windows</strong> Vista wurde der Hashwert<br />
mit dem Prozess generiert, der in Abbildung 2.4 dargestellt ist.<br />
Abbildung 2.4 In älteren <strong>Windows</strong>-Versionen war der Kennwortverifizierer einfach der<br />
Hashwert eines Hashwerts, bei dem der Benutzername als Saltwert verwendet wurde<br />
In den letzten Jahren haben sich Angreifer auf den Kennwortverifizierer konzentriert und<br />
mit der Entwicklung von Tools begonnen, die ihn knacken sollen. Auch wenn es sich um<br />
einen mit Saltwert berechneten Hashwert eines Hashwerts handelt, der somit schwierig zu<br />
knacken ist, kann der Kennwortverifizierer geknackt werden, falls das Kennwort relativ<br />
unsicher ist. Um dieser Gefahr vorzubeugen, wurde die Berechnung des Kennwortverifizie-
26 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
rers in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> geändert. Abbildung 2.5 zeigt das neue<br />
Verfahren.<br />
Abbildung 2.5 Der Kennwortverifizierer ist in <strong>Windows</strong> Vista und<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> viel sicherer als in älteren Versionen<br />
Es gibt zwar keine Möglichkeit, schwache Kennwörter zu schützen, aber die verbesserte<br />
Berechnung des Kennwortverifizierers liefert einen viel sichereren Verifizierer. Indem der<br />
alte Verifizierer durch eine große Zahl von PKCS #5-Operationen geschleust wird, könnte<br />
ein Angreifer, der eine Brute-force-Methode versucht, nur etwa 10 Versuche pro Sekunde<br />
berechnen. Das bietet ausreichenden Schutz, sofern es sich nicht um ein sehr unsicheres<br />
Kennwort handelt.
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-
28 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
ter durchgehen und feststellen, ob sie bestimmte Wörter enthalten. Solche Organisationen<br />
müssen die Kennwörter mit umkehrbarer Verschlüsselung speichern.<br />
Um die umkehrbare Verschlüsselung zu aktivieren oder zu prüfen, ob sie tatsächlich deaktiviert<br />
ist, können Sie den Gruppenrichtlinien-Editor verwenden (Abbildung 2.6).<br />
Abbildung 2.6 Mit dieser Gruppenrichtlinieneinstellung können Sie einen Computer oder eine<br />
Domäne so konfigurieren, dass Kennwörter umkehrbar verschlüsselt gespeichert werden<br />
<strong>Die</strong> große Mehrheit von Organisationen benötigt keine umkehrbare Verschlüsselung. Und<br />
wenn Clients aktualisiert werden, sodass sie sicherere Authentifizierungsprotokolle unterstützen,<br />
dürfte es immer weniger Gründe geben, sie zu aktivieren. <strong>Die</strong> umkehrbare Verschlüsselung<br />
ist aber eine weitere Möglichkeit, wie <strong>Windows</strong> Kennwörter speichern kann,<br />
und es ist wichtig, dass Sie diese Methode kennen.<br />
Wichtig Viele Leute überfährt ein kalter Schauer, wenn sie hören, dass <strong>Windows</strong> Kennwörter umkehrbar<br />
verschlüsselt speichern kann. Schließlich weiß jeder, dass es ganz schrecklich ist, wenn Kennwörter im<br />
Klartext gespeichert werden. Aber das geht am eigentlichen Punkt vorbei. Bei jedem kennwortbasierten<br />
System, das heutzutage im Einsatz ist, sind Kennwörter klartextäquivalent ! Kennwortbasierte Systeme<br />
verwenden gemeinsame Geheimnisse. Beim Authentifizierungsprozess wird nur das Geheimnis benutzt,<br />
das auf dem authentifizierenden <strong>Server</strong> gespeichert ist. Falls ein Angreifer sich Zugriff auf die Kennwortdatenbank<br />
des authentifizierenden <strong>Server</strong>s verschafft oder auf andere Weise das gemeinsame Geheimnis<br />
in Erfahrung bringt, hat er alles, was er für eine erfolgreiche Authentifizierung benötigt. Er muss sich nur<br />
noch in den richtigen Schritt des Authentifizierungsprozesses einklinken, dann kann er statt des Kennworts,<br />
von dem das gemeinsame Geheimnis abgeleitet ist, gleich das gemeinsame Geheimnis senden. Im Internet<br />
stehen momentan mehrere Tools frei zur Verfügung, die auf diese Weise eine <strong>Windows</strong>-<br />
Authentifizierung über das Netzwerk durchführen.<br />
<strong>Die</strong> Tatsache, dass Kennwörter klartextäquivalent sind, ist an sich kein <strong>Sicherheit</strong>sproblem. Das wird es<br />
erst, wenn ein Angreifer einen Kennworthashwert ausspäht. Wie Ihnen inzwischen klar sein dürfte, sind die<br />
in <strong>Windows</strong> recht gut geschützt. Falls es ein Angreifer schafft, einen Kennworthashwert in Erfahrung zu<br />
bringen, hat er bereits den Computer so weit oder stärker kompromittiert, wie er es mithilfe dieses Kennworthashwerts<br />
schaffen könnte! Anders ausgedrückt: Der Kennworthashwert gibt ihm keine zusätzlichen<br />
Privilegien auf einem bereits kompromittierten Computer.
Authentifizierungsprotokolle 29<br />
Falls Kennwörter allerdings auf anderen Computern gültig sind, ist es möglich, dass ein Angreifer mithilfe<br />
von Kennworthashwerten weiter vordringen kann. Und weil Kennworthashwerte im Arbeitsspeicher zwischengespeichert<br />
werden, könnte ein Angreifer in der Lage sein, administrative Anmeldeinformationen für<br />
eine Domäne auf einem Mitgliedcomputer auszuspähen, falls sich ein Domänenadministrator dort angemeldet<br />
hat. Das ist in erster Linie aber ein Verfahrensproblem. Sie müssen für Ihr Netzwerk entsprechende<br />
Regeln festlegen; wenn Sie den Empfehlungen in Kapitel 12 folgen, können Sie sich gegen diese Gefahr<br />
ausreichend schützen.<br />
Authentifizierungsprotokolle<br />
Bisher haben wir uns angesehen, wie Kennwörter in <strong>Windows</strong> gespeichert werden. Möglicherweise<br />
noch wichtiger ist, wie sie benutzt werden. Kennwörter sind Authentifizierer,<br />
das heißt, sie werden verwendet, um einen Benutzer bei einem Computer zu authentifizieren.<br />
Falls der Benutzer sich interaktiv an einem lokalen Konto anmeldet, ist der Ablauf recht<br />
simpel:<br />
1. Der Benutzer betätigt die SAS (Secure Attention Sequence, auch als »Drei-Finger-<br />
Salut«, »Geierkralle« oder schlicht STRG+ALT+ENTF bekannt), um das Anmeldedialogfeld<br />
zu öffnen. Daraufhin startet das LSASS (Local Security Authority Sub-System)<br />
eine neue Sitzung und lädt WinLogon in dieser Sitzung. WinLogon wiederum lädt die<br />
LogonUI, die Benutzeroberfläche für die Anmeldung.<br />
2. Der Benutzer gibt den Benutzernamen und das Kennwort ein.<br />
3. Der WinLogon-Prozess nimmt das Kennwort, generiert daraus einen NT-Hash, sucht<br />
den Benutzernamen in der lokalen SAM und vergleicht den NT-Hash mit dem Wert,<br />
der für den Benutzer gespeichert ist. Falls die beiden Hashwerte übereinstimmen, ist<br />
die Anmeldung erfolgreich.<br />
4. Falls Subauthentifizierungspakete auf dem Computer installiert sind, werden die Anmeldeinformationen<br />
zur weiteren Verarbeitung an diese Pakete übergeben. Andernfalls wird<br />
user32.exe aufgerufen und die Umgebung des Benutzers geladen.<br />
<strong>Die</strong>ser Vorgang ist relativ überschaubar, weil es einen sicheren Kanal gibt, der von der LogonUI,<br />
in der ein Benutzer seine Anmeldeinformationen im Klartext eingibt, bis zum Vergleich<br />
der Anmeldeinformationen reicht. Wenn allerdings eine Authentifizierung über das<br />
Netzwerk durchgeführt werden muss, wird es ein wenig komplizierter, weil in diesem Fall<br />
wichtig ist, wie die Authentifizierungsansprüche zwischen dem Client, an dem der Benutzer<br />
arbeitet, und dem authentifizierenden <strong>Server</strong> übertragen werden, der die Kontendatenbank<br />
hostet. In <strong>Windows</strong> kann dieser Vorgang viele Formen annehmen, die ich in den folgenden<br />
Abschnitten beschreibe.<br />
Standardauthentifizierung<br />
Standardauthentifizierung (engl. basic authentication) ist die einfachste Form der Authentifizierung.<br />
Sie überträgt die unveränderten Anmeldeinformationen über das Netzwerk. Anders<br />
ausgedrückt: Benutzername und Kennwort werden entweder als Klartext durch das Netzwerk<br />
gesendet oder in einer Form, die diese Daten intakt lässt, zum Beispiel Base-64-kodiert.<br />
In manchen Implementierungen wird dies als PAP (Password Authentication Protocol)<br />
bezeichnet. Standardauthentifizierung ist in älteren Netzwerkprotokollen wie zum Beispiel<br />
Telnet, FTP, POP, IMAP und sogar HTTP recht verbreitet. Auch heutzutage wird es noch<br />
manchmal verwendet, zum Beispiel im RPC/HTTPS-Connector-Mechanismus, mit dem ein
30 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Microsoft Office Outlook-Client über das Internet eine Verbindung zu einem Exchange <strong>Server</strong><br />
herstellt. In diesem Fall werden die Anmeldeinformationen in einem verschlüsselten<br />
Kanal an den Exchange <strong>Server</strong> oder ISA <strong>Server</strong> übertragen, je nachdem, wo die Verbindung<br />
endet. Außerhalb eines verschlüsselten Kanals, wie er bei dem Outlook-Exchange-Beispiel<br />
verwendet wird, sollte die Standardauthentifizierung aber vermieden werden.<br />
Frage-Antwort-Protokolle<br />
Frage-Antwort-Protokolle (engl. challenge-response protocol) sollen es unnötig machen, ein<br />
Kennwort im Klartext über das Netzwerk zu senden. Im Prinzip arbeiten sie alle nach demselben<br />
Schema, das in Abbildung 2.7 dargestellt ist.<br />
Abbildung 2.7 Alle Frage-Antwort-Protokolle bauen auf demselben Modell auf<br />
Das grundlegende Modell für ein Frage-Antwort-Protokoll sieht folgendermaßen aus: Ein<br />
Benutzer leitet die Anmeldung ein, woraufhin der Client eine Anforderung an den <strong>Server</strong><br />
sendet. Der <strong>Server</strong> generiert eine Frage (die challenge), die oft lediglich ein Zufallswert ist,<br />
und sendet sie an den Client. In der Zwischenzeit hat der Client die Anmeldeinformationen<br />
des Benutzers abgefragt. <strong>Die</strong> Anmeldeinformationen werden dann in einer kryptografischen<br />
Operation mit der Frage kombiniert. Das Ergebnis wird die Antwort (response). <strong>Die</strong> tatsächlichen<br />
Implementierungen können sich unterscheiden, aber die grundlegende Struktur ist<br />
immer dieselbe. <strong>Windows</strong> unterstützt als Frage-Antwort-Protokolle Digest-Authentifizierung,<br />
die LM/NTLM-Familie und Kerberos.
Authentifizierungsprotokolle 31<br />
Digestauthentifizierung<br />
Digestauthentifizierung (engl. digest authentication) ist kein in <strong>Windows</strong> eingebautes Protokoll.<br />
Sie wird in erster Linie in den Internetinformationsdiensten (Internet Information Services,<br />
IIS) eingesetzt, um eine Web-Authentifizierung nach RFC 2617 durchzuführen, und<br />
für einige LDAP-<strong>Server</strong> (Lightweight Directory Access Protocol) von Fremdherstellern.<br />
Digestauthentifizierung wurde als Ersatz für Standardauthentifizierung entworfen. Sie gilt<br />
als relativ unsicher und geht auf dem authentifizierenden <strong>Server</strong> einige Kompromisse bezüglich<br />
der <strong>Sicherheit</strong> ein.<br />
Der Frage-Antwort-Ablauf bei der Digestauthentifizierung sieht folgendermaßen aus:<br />
1. Der <strong>Server</strong> generiert eine zufällige Nonce und sendet sie an den Client. Eine Nonce ist<br />
schlicht eine Zufallszahl. Sie wird in Authentifizierungsprotokollen oft als Wert verwendet,<br />
der von einem Authentifizierer verändert wird. Beispiele sehen Sie in diesem Abschnitt.<br />
2. Der Client berechnet einen MD5-Hash für Benutzername, Authentifizierungsbereich<br />
(Domäne in <strong>Windows</strong>) und Kennwort.<br />
3. Der Client berechnet einen MD5-Hash der Methode und des Digest-URI.<br />
4. Der Client berechnet einen MD5-Hash über das Ergebnis von Operation 2, die <strong>Server</strong>-<br />
Nonce, einen Anforderungszähler, eine Client-Nonce, einen Schutzcode und das Ergebnis<br />
von Operation 3. <strong>Die</strong>s ist der Antwortwert (response), der vom Client zurückgesendet<br />
wird.<br />
5. Der <strong>Server</strong> berechnet dieselben Werte.<br />
Das größte Problem bei der Digestauthentifizierung liegt in Schritt 2. Wie Sie sehen, wird<br />
die Antwort des Clients mit dem tatsächlichen Kennwort berechnet, nicht mit einem Hashwert<br />
des Kennworts. Das bedeutet, dass der <strong>Server</strong> in Schritt 5 Zugriff auf das Klartextkennwort<br />
braucht, um die Antwort des Clients auswerten zu können. Falls Sie Digestauthentifizierung<br />
unterstützen wollen, müssen Sie Ihre Domäne daher so konfigurieren, dass Kennwörter<br />
mit umkehrbarer Verschlüsselung gespeichert werden.<br />
LM und NTLM<br />
Im Gegensatz zur Digestauthentifizierung sind sowohl LM als auch NTLM native Protokolle<br />
in <strong>Windows</strong>. Sie sind sich sehr ähnlich, der Unterschied liegt im Wesentlichen nur im<br />
Hashwert, mit dem die Antwort berechnet wird. LM wurde erstmals im weiter oben erwähnten<br />
LanManager eingesetzt. NTLM wurde als Ersatz für LM entworfen und erstmals 1993 in<br />
<strong>Windows</strong> NT 3.1 verwendet.<br />
LM und NTLM werden für die Authentifizierung in Arbeitsgruppen von <strong>Windows</strong> NT-<br />
Betriebssystemen verwendet. Außerdem werden sie in einer Domänenumgebung verwendet,<br />
falls entweder der Client oder der <strong>Server</strong> kein Domänenmitglied ist oder falls die Ressource,<br />
auf die zugegriffen wird, anhand einer IP-Adresse statt eines Hostnamens angegeben ist.<br />
Andernfalls wird in Active Directory-Domänen Kerberos benutzt. LM/NTLM muss benutzt<br />
werden, wenn auf eine Ressource über eine IP-Adresse zugegriffen wird, weil Kerberos mit<br />
vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) arbeitet und es<br />
keinen Weg gibt, einen FQDN aus einer IP-Adresse zu erhalten, weil jeder Host mehrere<br />
Aliasnamen haben kann.<br />
Der Authentifizierungsablauf in LM und NTLM wird normalerweise kombiniert. <strong>Die</strong>selbe<br />
Nachricht enthält beide Protokolle, und es findet keine Aushandlung statt, welches Protokoll
32 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
benutzt wird. Das ist einer der wenigen Fälle, in denen <strong>Windows</strong> vor einer Transaktion kein<br />
Protokoll aushandelt. Der kombinierte Ablauf ist in Abbildung 2.8 dargestellt.<br />
Abbildung 2.8 <strong>Die</strong> LM- und NTLM-Protokolle werden normalerweise zusammen übertragen<br />
Alle <strong>Windows</strong> NT-Betriebssysteme vor <strong>Windows</strong> <strong>Server</strong> 2003 arbeiten so, wie in Abbildung<br />
2.8 gezeigt, das heißt sie senden die LM- und NTLM-Antworten in der Standardeinstellung<br />
zusammen. In <strong>Windows</strong> <strong>Server</strong> 2003 wird standardmäßig nur die NTLM-Antwort<br />
gesendet, das Feld für die LM-Antwort bleibt meist leer. Beide Protokolle werden akzeptiert,<br />
wenn sie angefordert werden. Ab <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> hat sich<br />
das geändert, wie ich gleich erkläre.<br />
NTLMv2<br />
Ab <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> werden sowohl LM als auch NTLM in der<br />
Standardeinstellung nicht mehr verwendet. NTLM wird für eingehende Authentifizierung<br />
noch unterstützt, aber für ausgehende Authentifizierung wird in der Standardeinstellung<br />
stattdessen eine neuere Version von NTLM gesendet: NTLMv2. Ältere <strong>Windows</strong>-Versionen<br />
(schon seit <strong>Windows</strong> NT 4.0 Service Pack 4) konnten so konfiguriert werden, dass sie sich<br />
so verhalten, dies war aber nicht die Standardeinstellung. Konkret heißt das: Der Computer<br />
akzeptiert LM für die eingehende Authentifizierung, aber in der Standardeinstellung speichern<br />
weder <strong>Windows</strong> Vista noch <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> den LM-Hash. Daher haben sie<br />
keine Möglichkeit, eine eingehende LM-Antwort zu authentifizieren.<br />
Sie können das Authentifizierungsverhalten ab <strong>Windows</strong> NT 4.0 Service Pack 4 mit dem<br />
Registrierungswert LMCompatibilityLevel steuern. In den Gruppenrichtlinien wird die entsprechende<br />
Einstellung als Netzwerksicherheit: LAN Manager-Authentifizierungsebene<br />
angezeigt (Abbildung 2.9.)<br />
Der Standardwert für LMCompatibilityLevel in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
ist 3 beziehungsweise Nur NTLMv2-Antworten senden. <strong>Die</strong> Tabellen 2.1 und 2.2 zeigen,<br />
welche Auswirkungen die möglichen Werte auf einen Computer haben, der als Client beziehungsweise<br />
authentifizierender <strong>Server</strong> arbeitet. Dabei ist wichtig, dass die Einstellungen in<br />
Tabelle 2.2 sich nur auf den <strong>Server</strong> beziehen, der die Authentifizierung durchführt, also den<br />
<strong>Server</strong>, der die Benutzerkontendatenbank enthält. Alle dazwischen liegenden <strong>Server</strong> leiten<br />
die Anforderung einfach an diesen <strong>Server</strong> weiter. Das bedeutet, dass Tabelle 2.2 für Domä-
Authentifizierungsprotokolle 33<br />
nenmitglieder nur auf Domänencontrollern und Domänenmitgliedern relevant ist, die sich<br />
anhand ihrer lokalen Konten authentifizieren.<br />
Abbildung 2.9 <strong>Die</strong> Einstellung der LAN Manager-Authentifizierungsebene legt das<br />
Authentifizierungsverhalten bei der Nicht-Domänenauthentifizierung fest<br />
Tabelle 2.1 Auswirkungen von LMCompatibilityLevel auf das Clientverhalten<br />
Stufe Gruppenrichtlinienname Sendet Akzeptiert Verbietet das Senden von<br />
0 LM- und NTLM-Antworten senden LM, NTLM, NTLMv2.<br />
Sitzungssicherheit<br />
wird ausgehandelt.<br />
1 LM- und NTLM-Antworten senden<br />
(NTLMv2-Sitzungssicherheit verwenden,<br />
wenn ausgehandelt)<br />
LM, NTLM, NTLMv2.<br />
Sitzungssicherheit<br />
wird ausgehandelt.<br />
2 Nur NTLM-Antworten senden NTLM, NTLMv2.<br />
Sitzungssicherheit<br />
wird ausgehandelt.<br />
3 Nur NTLMv2-Antworten senden NTLMv2. Sitzungssicherheit<br />
wird immer<br />
verwendet<br />
LM,<br />
NTLM,<br />
NTLMv2<br />
LM,<br />
NTLM,<br />
NTLMv2<br />
LM,<br />
NTLM,<br />
NTLMv2<br />
LM,<br />
NTLM,<br />
NTLMv2<br />
NTLMv2-Sitzungssicherheit<br />
(auf <strong>Windows</strong> 2000 vor SRP1,<br />
<strong>Windows</strong> NT 4.0 und <strong>Windows</strong><br />
9x)<br />
NTLMv2<br />
LM und NTLMv2<br />
LM und NTLM<br />
Tabelle 2.2 Auswirkungen von LMCompatibilityLevel auf das Verhalten des authentifizierenden <strong>Server</strong>s<br />
Stufe Gruppenrichtlinienname Sendet Akzeptiert Verbietet das<br />
eingehend Senden von<br />
4 Nur NTLMv2-Antworten senden. LM verweigern NTLMv2,<br />
Sitzungssicherheit<br />
5 Nur NTLMv2-Antworten senden. LM und NTLM<br />
verweigern<br />
NTLMv2,<br />
Sitzungssicherheit<br />
NTLM,<br />
NTLMv2<br />
LM<br />
NTLMv2 LM und NTLM<br />
In allen <strong>Windows</strong>-Versionen vor <strong>Windows</strong> <strong>Server</strong> 2003 war der Standardwert 0. In <strong>Windows</strong><br />
<strong>Server</strong> 2003 ist der Standardwert 2. In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ist der<br />
Standardwert 3.
34 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
NTLMv2 ist eine stark verbesserte Version von NTLM. Sie arbeitet ebenfalls mit dem<br />
NT-Hash. Allerdings nimmt sie zusätzlich eine Clientfrage in die Berechnung auf. Abbildung<br />
2.10 zeigt den Authentifizierungsablauf unter NTLMv2.<br />
Abbildung 2.10 Das Protokoll NTLMv2 verwendet HMAC-MD5 und eine Clientfrage<br />
Wie Abbildung 2.10 zeigt, verwendet das NTLMv2-Protokoll nicht nur eine Clientfrage,<br />
sondern berechnet auch zwei HMAC-MD5-Nachrichtenauthentifizierungscodes, um die<br />
Antwort zu erstellen. Außerdem enthält es einen Zeitstempel, um Replay-Angriffe abzuwehren.<br />
Abbildung 2.10 zeigt auch eine LMv2-Antwort, die in der Antwort enthalten ist. <strong>Die</strong><br />
LMv2-Antwort hat im Gegensatz zur NTLMv2-Antwort eine feste Länge. Sie wird mit<br />
übertragen, um eine Pass-through-Authentifizierung für ältere <strong>Windows</strong>-Versionen wie zum<br />
Beispiel <strong>Windows</strong> 95 zu ermöglichen. Als NTLMv2 entworfen wurde, wurden diese Systeme<br />
weithin eingesetzt.<br />
<strong>Windows</strong> 9x bot keine native Unterstützung für NTLMv2, leitete aber die LM-Antwort weiter.<br />
Es schnitt aber Teile der unterschiedlich langen NTLMv2-Antwort ab, was die Authentifizierung<br />
verhinderte. Um dieses Problem zu vermeiden, wurde die LMv2-Antwort in das<br />
LM-Antwortfeld aufgenommen. Weil es dieselbe Länge hat wie die LM-Antwort, wird es<br />
unbeschädigt an den authentifizierenden <strong>Server</strong> weitergeleitet, sodass es verwendet werden<br />
kann, um die Authentifizierung abzuschließen. Auch heute noch wird es übergeben, wenn<br />
NTLMv2 benutzt wird. Der authentifizierende <strong>Server</strong> prüft beim Authentifizierungsprozess<br />
aber immer erst einmal, ob es eine NTLMv2-Antwort gibt, die sich erfolgreich validieren<br />
lässt. Falls es eine solche Antwort gibt, ist die Authentifizierung erfolgreich. Auch wenn es<br />
die LMv2-Antwort noch gibt, wird sie daher nur selten für die Authentifizierung eingesetzt.
Authentifizierungsprotokolle 35<br />
NTLM++<br />
Etwa zu der Zeit, als <strong>Windows</strong> 2000 entwickelt wurde, fügte Microsoft ein weiteres Protokoll<br />
der NTLM-Familie zu <strong>Windows</strong> hinzu. <strong>Die</strong>ses Protokoll hat keinen offiziellen Namen.<br />
In manchen Teilen der Implementierung wird es als NTLM2 bezeichnet. Das soll es von<br />
NTLM3 unterscheiden, das offiziell NTLMv2 heißt. An anderen Stellen wird es als NTLM++<br />
bezeichnet. Es wurde niemals dokumentiert, aber extern von mehreren Leuten entdeckt,<br />
darunter Eric Glass, Christopher R. Hertel und Hidenobu Seki. Es wird sogar vom Ethereal-<br />
Netzwerkverkehranalyzer erkannt, der es als NTLM2 Session Security (NTLM2-Sitzungssicherheit)<br />
bezeichnet. <strong>Die</strong>ser Name entstand, weil es immer dann beobachtet wurde, wenn<br />
LMCompatibilityLevel den Wert 1 hatte, was die NTLMv2-Sitzungssicherheit aktiviert<br />
(über die ebenfalls nicht viel bekannt war). Microsoft fügte NTLM++ hinzu, um bestimmte<br />
Man-in-the-Middle-Angriffe zu erschweren, aber trotzdem die Fähigkeit zu bieten, eine Passthrough-Authentifizierung<br />
zu implementieren, wenn eine Verbindung zu <strong>Server</strong>n mit älteren<br />
<strong>Windows</strong>-Versionen hergestellt wird. NTLM++ ist gewissermaßen eine Zwischenstation in<br />
der Entwicklung von NTLM zu LMv2/NTLMv2.<br />
Bei NTLM++ wird das LM-Antwortfeld statt mit der LM-Antwort mit einer Clientfrage<br />
gefüllt, wie in Abbildung 2.11 gezeigt.<br />
Abbildung 2.11 Das Protokoll NTLM++ ändert die NTLM-Antwort und fügt eine Clientfrage hinzu<br />
Das NTLM-Antwortfeld enthält eine geänderte NTLM-Antwort, die genauso wie die ursprüngliche<br />
NTLM-Antwort berechnet wird, aber einen HMAC-MD5-Wert über die Clientfrage<br />
und die <strong>Server</strong>-Frage berechnet, nicht nur über die <strong>Server</strong>frage.<br />
Der Computer verwendet NTLM++ immer dann, wenn NTLMv2-Sitzungssicherheit aktiviert<br />
ist. Ab <strong>Windows</strong> 2000 Security Rollup Pack 1 (SRP 1) senden alle Computer im ersten<br />
Versuch automatisch die NTLM++-Antwort. Das bedeutet, dass ab dieser Version alle Computer<br />
arbeiten, als hätte LMCompatibilityLevel den Wert 1.
36 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Übrigens bedeutet NTLMv2-Sitzungssicherheit, dass Sitzungsschlüssel auf sicherere Weise<br />
berechnet werden. Mit diesen Sitzungsschlüsseln arbeiten Anwendungen, wenn sie Sitzungssicherheit<br />
anfordern, sobald die Verbindung hergestellt ist. Mit Authentifizierungsprotokollen<br />
hat dies nur insoweit zu tun, als sie mit derselben Einstellung verwaltet werden.<br />
Kerberos<br />
Kerberos wird in Domänenumgebungen benutzt, wenn Hostnamen (inklusive vollqualifizierter<br />
Domänennamen) verwendet werden, um eine Verbindung herzustellen. Das ist gewöhnlich<br />
der Fall, sofern der Benutzer nicht explizit eine Verbindung zu einer IP-Adresse<br />
anfordert. Wie die NTLM-Familie implementiert <strong>Windows</strong> Kerberos als SSP (Security Support<br />
Provider), und Kerberos verwendet ebenfalls den NT-Hash für die Authentifizierung,<br />
aber hier enden die Ähnlichkeiten mit den anderen Protokollen.<br />
Kerberos bietet Authentifizierung sowohl für den Benutzer, der eine Verbindung herstellen<br />
will, als auch zwischen dem Client und dem <strong>Server</strong>. Das ist ein großer Unterschied zu<br />
NTLM, das dem Benutzer keinerlei Garantie bietet, dass der <strong>Server</strong> tatsächlich der Computer<br />
ist, mit dem er kommunizieren will. Kerberos ist auch mit den expliziten Annahmen<br />
entworfen worden, dass das Netzwerk eine feindselige Umgebung ist, dass irgendein Angreifer<br />
versucht, Verkehr abzuhören, und dass der Angreifer die Fähigkeit hat, den Verkehr,<br />
der über das Netzwerk gesendet wird, zu lesen, zu ändern oder zu löschen.<br />
Abbildung 2.12 <strong>Die</strong>ser Austausch findet statt, wenn ein Computer startet und eine Datei von einem<br />
Dateiserver anfordert
Authentifizierungsprotokolle 37<br />
Um alle diese Ziele zu erreichen, nutzt Kerberos neben Verschlüsselung auch eine Zeitsynchronisierung.<br />
In der Standardeinstellung müssen in <strong>Windows</strong> die Uhren von Client und<br />
<strong>Server</strong> innerhalb eines Toleranzbereichs von 5 Minuten synchron laufen. Sie können diese<br />
Einstellung verändern, falls Sie in einer Umgebung mit wahrscheinlich starker Zeitabweichung<br />
arbeiten. In diesem Fall können Sie den Wert Max. Toleranz für die Synchronisation<br />
des Computertakts unter Computerkonfiguration\<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\Kontorichtlinien\Kerberos-Richtlinien<br />
in einem Gruppenrichtlinienobjekt anpassen,<br />
das auf die Computer angewendet wird, für die Sie die Toleranz für die Zeitabweichung<br />
einstellen wollen. Denken Sie aber daran, dass die effektive maximale Toleranz für die Zeitabweichung<br />
der niedrigste Wert in der Transaktion ist. Jeder der Computer kann die Transaktion<br />
zurückweisen, falls der Zeitstempel außerhalb des erlaubten Toleranzbereichs liegt.<br />
Um zu verstehen, wie Kerberos arbeitet, sehen wir uns in Abbildung 2.12 einen Austausch<br />
an. Dabei meldet sich ein Benutzer an einer Arbeitsstation an und fordert dann eine Datei<br />
von einem Dateiserver an.<br />
Der Austausch in Abbildung 2.12 besteht aus folgenden Elementen:<br />
1. Wenn der Computer gestartet ist, erstellt er einige Vorauthentifizierungsdaten, die unter<br />
anderem einen Zeitstempel umfassen. <strong>Die</strong>se Vorauthentifizierungsdaten werden mit<br />
einem Schlüssel verschlüsselt, der aus dem Kennwort des Computers abgeleitet ist. <strong>Die</strong><br />
Daten werden zu einem KRB_AS_REQ-Paket (Kerberos Authentication Service Request)<br />
zusammengefasst und an den Authentifizierungsdienst (Authentication Service, AS)<br />
gesendet, der auf dem Schlüsselverteilungscenter (Key Distribution Center, KDC) läuft.<br />
<strong>Die</strong>ses Schlüsselverteilungscenter ist hier der Domänencontroller.<br />
2. Der AS erstellt ein TGT (Ticket Granting Ticket) und einen Sitzungsschlüssel, die der<br />
Client verwenden kann, um mit dem TGS (Ticket Granting Service) zu kommunizieren.<br />
Der TGS läuft in <strong>Windows</strong> ebenfalls auf dem Domänencontroller. <strong>Die</strong>ser Schlüssel ist in<br />
Abbildung 2.12 mit mit Keyclient,TGS bezeichnet. Er wird an den Client übertragen, nachdem<br />
er mit dem öffentlichen Schlüssel des Clients verschlüsselt wurde. <strong>Die</strong>se Nachricht<br />
wird als KRB_AS_REP zurückgesendet.<br />
3. Der Client sendet nun eine KRB_TGS_REQ-Nachricht an den TGS auf dem KDC, um ein<br />
Ticket für den Dateiserver anzufordern. <strong>Die</strong>se Anforderung enthält das TGT, außerdem<br />
gibt sie an, auf welchen <strong>Die</strong>nst der Client zugreifen will, und umfasst Informationen zum<br />
Client, die mit dem öffentlichen Schlüssel des TGS verschlüsselt sind. <strong>Die</strong> KRB_TGS_REQ-<br />
Nachricht enthält einen Authentifizierer, der im Wesentlichen ein Zeitstempel ist, der mit<br />
dem Sitzungsschlüssel verschlüsselt ist, den sich der Client mit dem TGS teilt.<br />
4. Der TGS antwortet mit einer KRB_TGS_REP-Nachricht, die ein Ticket für den <strong>Die</strong>nst umfasst,<br />
den der Client angefordert hat. <strong>Die</strong> Nachricht enthält dieselben Informationen, die<br />
der Client in seiner KRB_TGS_REQ-Nachricht gesendet hat, diesmal sind sie aber mit dem<br />
öffentlichen Schlüssel des <strong>Server</strong>s verschlüsselt. Anders ausgedrückt: Der Client kann<br />
diese Daten nicht lesen. Der TGS generiert außerdem einen Sitzungsschlüssel, den der<br />
Client mit dem <strong>Server</strong> teilen kann, und verschlüsselt ihn mit dem Sitzungsschlüssel, den<br />
der Client mit dem TGS teilt.<br />
5. Zuletzt sendet der Client sein Ticket für den <strong>Die</strong>nst an den <strong>Server</strong>. Dafür wird eine<br />
KRB_AP_REQ-Nachricht verwendet. <strong>Die</strong> Clientinformationen und der Client/<strong>Server</strong>-<br />
Sitzungsschlüssel werden mit dem öffentlichen Schlüssel des <strong>Server</strong>s verschlüsselt.<br />
Außerdem enthält die Nachricht den Authentifizierer des Clients, der mit dem gemeinsamen<br />
Sitzungsschlüssel verschlüsselt ist.
38 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Wenn sich ein Benutzer am Client anmeldet, wird dieser Vorgang wiederholt, diesmal enthalten<br />
die Nachrichten aber Benutzerinformationen. Der Kerberos-Client sendet eine weitere<br />
KRB_AS_REQ-Nachricht, verschlüsselt die Vorauthentifizierungsdaten aber mit einem Schlüssel,<br />
der aus dem Kennwort des Clients abgeleitet ist <strong>–</strong> oder genauer gesagt: aus dem NT-<br />
Hash des Clients. Der KDC prüft die Authentifizierung anhand dieser Informationen. In der<br />
KRB_AS_REP-Nachricht empfängt der Client ein TGT, mit dem der Benutzer Kontakt zum<br />
TGS aufnehmen kann. Das TGT umfasst Sitzungsschlüssel für das KDC sowie <strong>Sicherheit</strong>s-<br />
IDs (Security Identifier, SID) für den Benutzer und alle Gruppen, bei denen der Benutzer<br />
Mitglied ist. Künftig verwendet der Client dann das TGT des Benutzers, wenn er Anforderungen<br />
im Namen des Benutzers schickt.<br />
Kerberos ist offensichtlich ein recht kompliziertes Protokoll, aber es hat sich in <strong>Windows</strong> als<br />
bemerkenswert robust erwiesen. Es hat sich auch gezeigt, dass es erweiterbar ist, weil die<br />
Vorauthentifizierungsdaten des Benutzers genauso gut mit einem Geheimnis verschlüsselt<br />
werden können, das nicht von einem Kennwort abgeleitet ist. Das passiert bei der Smartcardauthentifizierung,<br />
die wir uns als Nächstes ansehen.<br />
Smartcardauthentifizierung<br />
Eine Smartcard ist in den meisten Fällen ein Gerät in der Größe einer Kreditkarte, das einen<br />
Speicherchip enthält. <strong>Die</strong>se Geräte sind vielseitig einsetzbar. Zum Beispiel werden sie verwendet,<br />
um die Identität eines Telefons bei der GSM-Kommunikation (Global System<br />
for Mobile) von Mobiltelefonen und den davon abgeleiteten Technologien bereitzustellen.<br />
Smartcards können auch für die Authentifizierung in <strong>Windows</strong> verwendet werden. In diesem<br />
Fall enthalten sie ein X.509-Zertifikat. (Kapitel 10 enthält weitere Informationen über Zertifikate.)<br />
Das Zertifikat enthält einen privaten Schlüssel, und der zugehörige öffentliche<br />
Schlüssel ist im Benutzerobjekt in Active Directory gespeichert.<br />
Wenn sich der Benutzer mit einer Smartcard authentifiziert, fragt WinLogon nicht nach<br />
einem Kennwort, sondern nach einer Geheimnummer, dem sogenannten PIN-Code. Dann<br />
nimmt es Kontakt zum Smartcardanbieter (engl. smartcard provider) auf und übergibt ihm<br />
den PIN-Code sowie die Vorauthentifizierungsdaten. Der Smartcardanbieter greift mithilfe<br />
des PIN-Codes auf die Smartcard zu, um die Vorauthentifizierungsdaten zu verschlüsseln,<br />
die der Kerberos-SSP in der KRB_AS_REQ-Nachricht verwendet. Ab diesem Punkt läuft bei<br />
einer Smartcardanmeldung fast alles genauso ab wie bei einer normalen Kennwortanmeldung,<br />
allerdings mit einem wichtigen Unterschied: Falls sich der Benutzer mit einer Smartcard<br />
anmeldet, gibt er niemals ein Kennwort ein. Falls der Benutzer daher versucht, auf<br />
irgendwelche Ressourcen zuzugreifen, die nicht mit dem Kerberos-System arbeiten können,<br />
muss der Computer das Kennwort vom Benutzer anfordern. Um das zu vermeiden, behandelt<br />
<strong>Windows</strong> Kennwörter bei einer Smartcardanmeldung etwas anders.<br />
Smartcards und Kennwörter<br />
Zu allen Konten wird auf dem Domänencontroller ein Kennworthashwert gespeichert. Sogar<br />
wenn sich der Benutzer mit einer Smartcard anmelden muss, gibt es einen Kennworthashwert.<br />
Wenn Sie ein Konto so konfigurieren, dass es eine Smartcardanmeldung erfordert,<br />
erstellt der Domänencontroller ein zufälliges Kennwort, berechnet dessen Hashwert und<br />
speichert ihn im Benutzerobjekt.
Angriffe auf Kennwörter 39<br />
Wenn sich ein Benutzer mit einer Smartcard anmeldet, stellt das KDC dem Client während<br />
des Anmeldevorgangs den Kennworthashwert des Benutzers zur Verfügung. <strong>Die</strong>se Anmeldeinformationen<br />
werden mit dem öffentlichen Schlüssel des Clients verschlüsselt, bevor sie<br />
übertragen werden. Der Kerberos-SSP auf dem Client entschlüsselt sie und speichert sie auf<br />
dieselbe Weise in einem Cache, wie er es täte, hätte der Benutzer das Kennwort selbst bei<br />
der Anmeldung eingegeben. Der Computer verwendet diese Anmeldeinformationen, um sich<br />
bei Computern anzumelden, die aus irgendwelchen Gründen nicht über Kerberos erreichbar<br />
sind. Auch wenn also eine Smartcardanmeldung erforderlich ist, sind die Hashwerte auf dem<br />
Client durch böswillige Software gefährdet, die als Administrator läuft. Auch wenn Smartcards<br />
eingesetzt werden, sind kennwortbasierte Anmeldeinformationen nicht besser geschützt<br />
als bei einer Kennwortanmeldung. Daher sollten Sie dieselben Vorsichtsmaßnahmen<br />
gegen die Angriffe treffen, die wir uns als Nächstes ansehen.<br />
Angriffe auf Kennwörter<br />
An diesem Punkt sollten wir einen kleinen Abstecher machen und uns mit Angriffen beschäftigen,<br />
schon aus dem Grund, weil sich so viele Leute deswegen Sorgen machen. Der<br />
wichtigste Punkt im Bezug auf Kennwörter besteht offensichtlich darin zu verhindern, dass<br />
die bösen Buben sie in die Finger bekommen. Wenn Angreifer die Kennwörter oder irgendeine<br />
abgeleitete Form einmal haben, ist die Frage, was sie damit tun. Sehen wir uns erst<br />
einmal an, wie ein potenzieller Angreifer ein Kennwort oder eine abgeleitete Form ausspähen<br />
kann.<br />
Ausspähen von Kennwörtern<br />
Angreifer haben verschiedene Möglichkeiten, an Ihre Kennwörter zu kommen. <strong>Die</strong> folgenden<br />
Abschnitte führen die wichtigsten Methoden auf, von den einfachsten und häufigsten<br />
Angriffen zu den schwierigeren und selteneren (natürlich etwas vereinfacht).<br />
Einfach fragen<br />
Eine erstaunliche Zahl von Leuten (bis zu 75% in manchen Untersuchungen) sind bereit,<br />
ihre Kennwörter im Tausch gegen etwas herauszugeben, dem sie mehr Wert beimessen. In<br />
einer Untersuchung war das zum Beispiel Schokolade (Wagner, 2004).<br />
Kennwörter direkt abfangen<br />
Sofern die Benutzer ihre Kennwörter nicht willig herausgeben, ist es heutzutage am erfolgreichsten,<br />
einfachsten und wahrscheinlich verbreitetsten, einen sogenannten Keystroke-<br />
Logger zu verwenden, der ein Kennwort als Klartext aufzeichnet, während der Benutzer es<br />
eingibt. Es gibt viele unterschiedliche Arten von Keystroke-Loggern. Eine unscheinbare<br />
Möglichkeit ist ein Hardwaregerät, das zwischen Tastatur und Computer eingeschleift wird<br />
und Speicher enthält, in dem alle Tastenbetätigungen aufgezeichnet werden. Es kann binnen<br />
Sekunden heimlich installiert und wieder entfernt werden. Ein solches Gerät verschafft<br />
Zugriff auf alles, was der Computer an Eingaben bekommt, inklusive aller Tastendrücke,<br />
Metadaten wie zum Beispiel der Tipprhythmus und so weiter. Ein Softwareprogramm, wie<br />
es heute oft in Malware und Spyware zu finden ist, kann ebenfalls alle Tastatureingaben<br />
aufzeichnen, üblicherweise auch inklusive der Metadaten. Das ist nicht auf Kennwörter<br />
beschränkt. Manche dieser Programme können die ausgespähten Daten automatisch auf eine
40 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Website oder in einen IRC-Kanal (Internet Relay Chat) hochladen. Andere Software bringt<br />
gleich einen kleinen Webserver mit, über den der Angreifer die Daten abrufen kann.<br />
Der einfachste und direkteste Weg für einen Angreifer, der nur Kennwörter ausspähen will,<br />
besteht darin, ein Subauthentifizierungspaket zu schreiben. Wie alle professionellen Betriebssysteme<br />
bietet <strong>Windows</strong> Fremdherstellern die Möglichkeit, sein Authentifizierungssubsystem<br />
so zu erweitern, dass es eine Authentifizierung an anderen Netzwerkgeräten<br />
durchführt. Ein Angreifer kann mit wenigen Aufrufen der Programmierschnittstelle (Application<br />
Programming Interface, API) ein Subauthentifizierungspaket schreiben, das alle<br />
Kennwörter im Klartext aufzeichnet, während sich ein Benutzer anmeldet. Mit etwas mehr<br />
Aufwand kann der Angreifer das Paket mit denselben Features wie ein leistungsfähigerer<br />
Keystroke-Logger aufrüsten. Ein solches System liefert aber bei Weitem nicht so viele überflüssige<br />
Daten, weil es sich darauf spezialisiert, ausschließlich Kennwörter aufzuzeichnen.<br />
Bei beiden Softwaremethoden sind administrative Privilegien nötig, um das Programm zu<br />
installieren. Der Angreifer muss den Computer also vollständig kompromittiert haben. Physischer<br />
Zugriff auf den Computer reicht aus, um solche Tools zu installieren. Es gibt zu denken,<br />
dass Keystroke-Logger inzwischen regelmäßig auf öffentlich zugänglichen Computern<br />
zu finden sind, insbesondere auf Konferenzen.<br />
Abfangen der Frage-Antwort-Sequenz<br />
Es kommt heute nur noch selten vor, dass Kennwörter überhaupt durch das Netzwerk übertragen<br />
werden. Und noch seltener ist es, dass in neuen Implementierungen Klartextprotokolle<br />
wie FTP, POP und Telnet verwendet werden. Aber selbst wenn Frage-Antwort-Protokolle<br />
eingesetzt werden, kann der Angreifer oft sowohl die Frage als auch die Antwort abfangen<br />
und diese Kombination für seinen Angriff einsetzen. Dafür sind mehr Berechnungen notwendig<br />
als beim Angriff auf normale Hashwerte, aber falls das Kennwort schwach ist, kann<br />
der Angreifer durchaus Erfolg haben.<br />
Ausspähen der Hashwerte<br />
<strong>Die</strong>s ist der Angriff, den jeder fürchtet. Falls ein Angreifer Zugriff auf die Kennworthashwerte<br />
hat, kann er das Kennwort ermitteln oder die Hashwerte auf andere Weise nutzen. Es<br />
gibt mehrere Wege, Hashwerte zu knacken, wie wir in Kürze sehen werden. Am häufigsten<br />
spähen Angreifer die Hashwerte aus, indem sie den authentifizierenden <strong>Server</strong> kompromittieren,<br />
der die Kennwörter speichert. In Kapitel 14, »Schützen des Netzwerks«, werden Sie<br />
sehen, dass dieser Angriff umso leichter gelingt, je mehr Abhängigkeiten Sie in Ihrem Netzwerk<br />
haben.<br />
Eine andere Möglichkeit (weniger verbreitet, aber genauso machbar) besteht darin, einen<br />
Computer zu kompromittieren, während bereits jemand angemeldet ist. Wie weiter oben<br />
beschrieben, speichert <strong>Windows</strong> den NT-Hash eines Benutzers im Arbeitsspeicher, solange<br />
der Benutzer angemeldet ist. Ein Angreifer mit vollständiger Kontrolle über den Computer<br />
kann diesen Hashwert auslesen und auf dieselbe Weise wie jeden anderen Hashwert nutzen.<br />
Noch einmal: <strong>Die</strong>ses Problem muss in erster Linie über Verfahrensregeln gelöst werden.<br />
Wie Sie in Kapitel 14 sehen werden, können Sie dieses Problem ganz vermeiden, indem<br />
Sie besonders vertrauliche Hashwerte von Computern fernhalten, die weniger wichtig (und<br />
somit weniger sicher) sind. Und falls ein Verbrecher es schafft, einen Computer in diesem<br />
Ausmaß zu kompromittieren, kann er auch problemlos das Klartextkennwort ausspähen, wie<br />
wir im nächsten Abschnitt sehen.
Angriffe auf Kennwörter 41<br />
Erraten von Kennwörtern<br />
Schließlich kann der Angreifer auch einfach versuchen, Kennwörter zu erraten. <strong>Die</strong>se Methode<br />
lässt sich am einfachsten abwehren. Sie bringt dem Angreifer am wenigsten Erfolg,<br />
oder zumindest sollte das so sein. Jeder, dessen <strong>Windows</strong>-Computer mit dem Internet verbunden<br />
ist und der sich tatsächlich die Protokolldateien ansieht, findet Hinweise auf entsprechende<br />
Versuche. Abbildung 2.13 zeigt einen fehlgeschlagenen Versuch auf einem meiner<br />
Computer, der durchgeführt wurde, während dieses Buch entstand.<br />
Abbildung 2.13 Jeder, dessen <strong>Windows</strong>-Computer mit dem Internet verbunden ist,<br />
findet fehlgeschlagene Anmeldungsversuche in seinen Ereignisprotokollen<br />
<strong>Die</strong> meisten Angreifer verwenden sogenannte »Grinder«, die automatisiert versuchen, sich<br />
über Terminaldienste oder das <strong>Windows</strong>-Netzwerk (<strong>Server</strong> Message Block, SMB) anzumelden.<br />
Der Anmeldungsversuch in Abbildung 2.13 wurde in Wirklichkeit bei den Internetinformationsdiensten<br />
durchgeführt. Das weiß ich nur deshalb, weil der Host nicht auf Terminaldienste-<br />
oder SMB-Kommunikation aus dem Internet reagiert.<br />
<strong>Die</strong> meisten automatisierten Kennwort-Grinder probieren verbreitete Benutzernamen, zum<br />
Beispiel Administrator, mit einem Wörterbuch von Kennwörtern durch. Es scheint unglaublich,<br />
aber offenbar sind sie mit diesem Ansatz so erfolgreich, dass die Methode sich lohnt.<br />
Viele Leute empfehlen, das Konto Administrator umzubenennen, um Angreifer zu täuschen.<br />
Manche schwören sogar darauf, als Ablenkungsmanöver ein spezielles Konto mit dem Namen<br />
Administrator anzulegen. Das hat nicht den geringsten Sinn. <strong>Die</strong> Fehlermeldung ist<br />
dieselbe, unabhängig davon, ob es gar kein Konto mit dem Namen Administrator gibt oder<br />
der Angreifer das falsche Kennwort probiert. Daher kann der Angreifer auf diese Weise gar<br />
nicht herausfinden, ob Sie ein Konto namens Administrator haben. Er stellt nur fest, dass er<br />
sich nicht anmelden konnte. Wenn Sie ein sicheres Kennwort wählen, können Sie sich sicher<br />
sein, dass ein Angreifer nicht in das Konto eindringen kann. Falls das Kennwort zum Beispiel<br />
15 Zeichen lang und quasi zufällig ist (das heißt, es sieht aus Sicht des Angreifers wie<br />
ein Zufallswert aus), muss der etwa 542.086.379.860.909.058.354.552.242.176 Versuche
42 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
durchführen, bevor er Erfolg hat. Es ist anzunehmen, dass er es woanders probiert, bevor er<br />
dieses Kennwort erraten hat.<br />
Es kann sinnvoll sein, leere Kennwörter zu verwenden<br />
Wie bei allen <strong>Windows</strong>-Versionen seit <strong>Windows</strong> XP können sich Benutzerkonten mit leerem<br />
Kennwort nicht aus dem Netzwerk an <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> anmelden. Das ist ein<br />
geradezu genialer Entwurf, der sich für das lokale Administratorkonto sinnvoll nutzen<br />
lässt.<br />
In einem typischen Datencenter befinden sich die <strong>Server</strong> in verschlossenen Schränken,<br />
den sogenannten Racks. In vielen Fällen haben nicht alle Personen Zugriff auf sämtliche<br />
Schränke. Nur Mitarbeiter, die an bestimmten <strong>Server</strong>n arbeiten müssen, können diese<br />
Schränke öffnen. <strong>Die</strong> Schränke selbst befinden sich in verschlossenen Räumen, in die nur<br />
gelangt, wer einen Ausweis hat und die zugehörige Geheimnummer kennt. Datencenter<br />
haben Wachpersonal (oft bewaffnet) an der Zufahrt und im Empfangsbereich. Um in den<br />
Gang zu kommen, der zum <strong>Server</strong>raum führt, müssen Sie an der grimmig blickenden und<br />
sehr gelangweilten Wache vorbei, wobei Sie normalerweise durch eine Schleuse gehen, in<br />
der Sie auf beim Hinein- und Hinausgehen gewogen werden. (Was passiert übrigens,<br />
wenn Sie beim Verlassen weniger wiegen als beim Betreten?) Und um überhaupt an den<br />
Empfang zu gelangen, passieren Sie eine weitere, wahrscheinlich bewaffnete Wache in<br />
einem Häuschen an der Zufahrt zum Parkplatz. Sind Ihre <strong>Server</strong> in diesem Fall physisch<br />
sicher? Wahrscheinlich antworten Sie mit »Ja«. Warum sollten Sie dann nicht das Kennwort<br />
für das integrierte Konto Administrator leer lassen? <strong>Die</strong> einzigen Personen, die es<br />
nutzen können, sind bereits an zwei Wachen, der Personenschleuse und dem Ausweislesegerät<br />
vorbeigekommen, sie wissen den PIN-Code für den richtigen Raum und haben<br />
den Schlüssel für den richtigen <strong>Server</strong>schrank. Wenn jemand all das schafft, gehört er<br />
wahrscheinlich zur Firma und muss dieses Konto im Rahmen seiner Arbeit benutzen.<br />
Und er hätte dann sicherlich eine Möglichkeit, das Kennwort zu ermitteln, sollte er es<br />
brauchen. Offensichtlich sollte er es nicht für die normale Arbeit nutzen, aber falls alles<br />
schiefgeht und er sich als integrierter Administrator anmelden muss, weiß er, wie das<br />
Kennwort lautet, und kann sich problemlos anmelden.<br />
Wenn Sie das Kennwort leer lassen, lösen Sie eines der großen Probleme für die Netzwerksicherheit:<br />
Wie verhindern Sie, dass das Administratorkonto auf allen <strong>Server</strong>n im<br />
Netzwerk dasselbe Kennwort hat? Es lässt sich kaum begründen, dass ein leeres Kennwort<br />
die <strong>Sicherheit</strong> auf irgendeine Weise gefährdet, solange die physische <strong>Sicherheit</strong> gewährleistet<br />
ist. Leider ist es wahrscheinlich viel schwieriger, einen inkompetenten <strong>Sicherheit</strong>sauditor<br />
zu überzeugen, dass ein leeres Kennwort sicherer ist als auf jedem einzelnen<br />
<strong>Server</strong> dasselbe 8 Zeichen lange Kennwort einzurichten. Falls Sie versprechen, es<br />
zu probieren, werde ich meinen Teil dazu beitragen. Ein Kennwort, das nur von jemand<br />
innerhalb des Datencenters benutzt werden kann, ist viel, viel sicherer als eine monumentale<br />
<strong>Sicherheit</strong>sabhängigkeit zwischen Tausenden von <strong>Server</strong>n, die alle mit der vom Auditor<br />
bevorzugten, aber unsinnigen Lösung arbeiten.
Angriffe auf Kennwörter 43<br />
Nutzen der ausgespähten Informationen<br />
Nehmen wir an, der Angreifer hat irgendwelche Informationen bekommen. Wie nutzt er<br />
diese Daten? Falls er ein Klartextkennwort weiß, ist die Antwort offensichtlich. Er braucht<br />
nur einen Zugang, an dem er das Kennwort eingeben kann. Falls er dagegen eine Frage-Antwort-Sequenz<br />
oder einen Kennworthashwert in Erfahrung gebracht hat, ist das Problem<br />
etwas komplizierter.<br />
Knacken von Kennwörtern<br />
Der häufigste Angriff besteht darin, das Kennwort zu knacken. Mit »Knacken« ist in diesem<br />
Fall gemeint, dass der Angreifer aus einem simplen Kennwort einen Kennworthashwert oder<br />
eine Frage-Antwort-Sequenz berechnet und das Ergebnis mit dem ausgespähten Hashwert<br />
oder der aufgezeichneten Antwort vergleicht. Falls die Daten übereinstimmen, ist das probierte<br />
Kennwort richtig.<br />
Wie Sie weiter oben in diesem Kapitel gesehen haben, sind beim Berechnen einer Frage-<br />
Antwort-Sequenz mehr Berechungen nötig als beim Generieren eines normalen Hashwerts.<br />
Logischerweise dauert das Knacken einer aufgezeichneten Frage-Antwort-Sequenz daher<br />
deutlich länger als das Knacken eines Kennworthashwerts. Auf heutzutage üblicher Hardware<br />
können Sie etwa 3 bis 10 Millionen Hashwerte pro Sekunde berechnen, aber nur etwa<br />
ein Drittel so viele Frage-Antwort-Paare. Falls der Angreifer nur den Kennwortverifizierer<br />
besitzt, kann er lediglich ca. 10 pro Sekunde berechnen, sodass ein Knacken praktisch unmöglich<br />
ist, sofern das Kennwort nicht außergewöhnlich schwach ist.<br />
Es gibt verschiedene Ansätze, um das Knacken von Kennwörtern zu beschleunigen. Ein<br />
Angreifer kann ein Wörterbuch häufig verwendeter Wörter oder Kennwörter verwenden<br />
(Burnett, 2005). Der Angreifer kann auch einen Brute-force-Angriff mit allen möglichen<br />
Kennwörtern aus einem bestimmten Satz von Zeichen starten. Aus Leistungsgründen kann<br />
der Angreifer den Satz von Zeichen deutlich einschränken. Meine eigenen Untersuchungen<br />
haben gezeigt, dass Benutzer 80 Prozent der Zeichen, die in Kennwörtern verwendet werden,<br />
aus einem Satz von lediglich 32 Zeichen auswählen. Und schließlich kann der Angreifer<br />
einen kombinierten Ansatz verwenden, wobei er die durchprobierten Kennwörter aus<br />
irgendeinem Wörterbuch bezieht, aber bestimmte Zeichen ändert. Zum Beispiel kann der<br />
Angreifer häufig verwendete Ersetzungen probieren, zum Beispiel »!« oder »1« statt »i«,<br />
»@« statt »a« oder »at«, »3« statt »e« und so weiter. Um die Geschwindigkeit des Angriffs<br />
in der entscheidenden Phase wirklich zu beschleunigen, kann der Angreifer im Vorfeld eine<br />
Liste von Hashwerten generieren und diese Daten dann für einen Angriff mit vorberechneten<br />
Hashwerten verwenden.<br />
Angriffe mit vorberechneten Hashwerten<br />
Angriffe mit vorberechneten Hashwerten (engl. precomputed hash attack) folgen einem ganz<br />
simplen Prinzip. Auf breiter Basis wurden sie erstmals Ende der 1990er in einem Tool namens<br />
Gerald Quakenbush’s Password Appraiser eingesetzt. Das Tool wurde mit mehreren CDs<br />
voller Kennworthashwerte geliefert. Einige Jahre später entwickelten Cedric Tissieres und<br />
Philippe Oechslin das Programm Ophcrack, das LM-Hashwerte mithilfe vorberechneter<br />
Hashwerte knackte, aber einen Kompromiss zwischen Zeitaufwand und Speicherbedarf<br />
implementierte, um den benötigten Speicherplatz für die Hashwerte zu verringern. Statt alle<br />
Hashwerte zu speichern, wurde nur ein Teil davon zusammen mit allen Kennwörtern eingelesen,<br />
die diesen Hashwert generieren. Zur Laufzeit braucht der Cracker nur noch zu suchen,
44 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
welcher Satz von Kennwörtern möglicherweise den Hashwert generiert, den er knacken<br />
will, die Hashwerte für alle Optionen berechnen und die Ergebnisse mit dem Hashwert vergleichen.<br />
Das war deutlich langsamer als der Password Appraiser, aber um ein vielfaches<br />
schneller als eine Brute-force-Methode. Zhu Shuanglei implementierte dieselbe Technik im<br />
enorm beliebten Rainbow Crack Tool, das praktisch alle Hashformate knacken kann, die es<br />
gibt. Angriffe mit vorberechneten Hashwerten werden nach diesem Tool oft als Rainbow<br />
Cracks oder Rainbow-Table-Angriffe bezeichnet.<br />
Angriffe mit vorberechneten Hashwerten wurden in der Presse gewaltig breitgetreten, und<br />
viele Leute sowie selbsternannte »<strong>Sicherheit</strong>sexperten« haben sich darüber ausgelassen, wie<br />
schlimm sie sind und dass sie nur funktionieren, weil <strong>Windows</strong> so fehlerhaft ist, und dass<br />
Microsoft <strong>Windows</strong> verbessern muss, um den Erfolg solcher Tools zu verhindern. Üblicherweise<br />
werden solche Sprüche mit der Aussage garniert, dass Entwickler anderer Betriebssysteme<br />
(natürlich) so vorausschauend waren, einen Schutz vor diesen Angriffen zu implementieren.<br />
<strong>Die</strong>se Einschätzungen sind grobe Vereinfachungen, die durch keinerlei Erfahrungen<br />
oder Ereignisse gestützt werden.<br />
Erstens ist <strong>Windows</strong> nicht fehlerhaft, weil es keine Angriffe mit vorberechneten Hashwerten<br />
in seinem Entwurf berücksichtigt. Es stimmt, dass die Verwendung eines Saltwerts in der<br />
Berechung des Kennworthashwerts gegen Angriffe mit vorberechneten Hashwerten helfen<br />
kann. Aber dies war keine (und ist nach wie vor keine) signifikante Bedrohung, gegen die<br />
man sich schützen müsste. Ich habe es bereits vorher erwähnt: Falls ein Angreifer Zugriff<br />
auf Ihre Hashwerte hat, ist Ihr Computer oder das Netzwerk bereits verhängnisvoll kompromittiert.<br />
Sie wurden in diesem Fall bereits gehackt, und der Schaden ist bereits so groß, dass<br />
ein Angreifer kaum noch mehr Schaden anrichten kann, auch wenn er diese Kennworthashwerte<br />
knackt.<br />
Lassen Sie sich außerdem nicht einreden, dass die Entwickler von Konkurrenzbetriebssystemen<br />
die Voraussicht besaßen, einen Schutz vor solchen Angriffen zu verwirklichen. Saltwerte<br />
wurden als Schutz hinzugefügt, weil die Kennwortdatei von allen gelesen werden<br />
konnte. Angriffe mit vorberechneten Hashwerten waren irrelevant, als diese Plattformen<br />
entworfen wurden. Hunderte von Gigabyte oder sogar Terabyte an Kennworthashwerten<br />
bereitzuhalten, war einfach nicht praktikabel, als Computer 16 KByte Arbeitsspeicher und<br />
ein Bandlaufwerk hatten.<br />
Zweitens ist es absolut sinnlos, <strong>Windows</strong>-Kennworthashwerte mit Saltwerten zu versehen,<br />
um Angriffe mit vorberechneten Hashwerten abzuwehren. Sehen Sie sich doch an, wie die<br />
Authentifizierungsprotokolle arbeiten. Falls Sie die Hashmechanismen ändern, müssen Sie<br />
auch ein neues Authentifizierungsprotokoll einführen, weil die alten Protokolle die alten<br />
Hashwerte voraussetzen. Das letzte Mal wurde ein Authentifizierungsprotokoll tatsächlich<br />
aufgegeben, als in <strong>Windows</strong> Vista LM entfernt wurde. Das dauerte 13 Jahre ab der Einführung<br />
des Nachfolgers. Wenn der Hashmechanismus so geändert wird, dass ein Saltwert hinzugefügt<br />
wird, kann das Angriffe mit vorberechneten Hashwerten zweifellos verhindern. Es<br />
würde aber wieder einen Zeitraum wie etwa 13 Jahre erfordern, bis die alten NT-Hashwerte<br />
verschwunden sind. Und weil Kennworthashwerte unabhängig davon, ob sie mit oder ohne<br />
Saltwert berechnet werden, klartextäquivalent sind, würde diese Maßnahmen das eigentliche<br />
Problem ohnehin nicht beseitigen. Jeder, der behauptet, dass in <strong>Windows</strong> lediglich Kennwörter<br />
mit einem Saltwert versehen werden müssten, hat das Problem entweder nicht bis<br />
zum Ende durchdacht oder versteht es überhaupt nicht.
Angriffe auf Kennwörter 45<br />
Warum das Knacken von Kennwörtern nicht Ihre größte Sorge<br />
zu sein braucht<br />
Es ist wichtig, nicht die Tatsache zu vergessen, dass der Angreifer in allen Fällen, wo<br />
Hashwerte kompromittiert wurden, sämtliche <strong>Sicherheit</strong>ssysteme ausgeschaltet und vollständige<br />
Kontrolle über mindestens ein System hat, das ihm erweiterten Zugriff ermöglicht.<br />
Wahrscheinlich hat er sogar Zugriff auf ein System, das alle Geheimnisse speichert:<br />
den Domänencontroller. Anders ausgedrückt: Falls ein Angreifer sich an das Knacken<br />
von Hashwerten machen kann, wurden Sie bereits ernstlich gehackt und Angreifer mit<br />
Kennworthashwerten sollten Ihre kleinste Sorge sein. Unabhängig davon, ob der Angreifer<br />
es schafft, die Hashwerte direkt zu nutzen oder sie zu knacken, ist Ihr Netzwerk bereits<br />
so stark kompromittiert, dass radikale Maßnahmen erforderlich sind. Ihre einzige<br />
Lösung besteht darin, alle kompromittierten Computer neu aufzusetzen. Das umfasst das<br />
gesamte Netzwerk, falls die Gefahr besteht, dass ein Domänen- oder Organisationsadministratorkonto<br />
kompromittiert wurde. Sie müssen die System entweder von Grund auf<br />
neu installieren oder eine Datensicherung wiederherstellen, die nachweislich nicht kompromittiert<br />
ist.<br />
Pass-the-Hash-Angriffe<br />
Kennworthashwerte sind klartextäquivalent. Sie konnten das bereits mehrmals lesen, daher<br />
sollte es inzwischen mehr als deutlich sein. Das Geheimnis, mit dem der <strong>Server</strong> die Identität<br />
des Clients überprüft, ist dasselbe Geheimnis, mit dem der Client seine Identität beweist.<br />
Das gilt für alle Authentifizierungsprotokolle, die mit gemeinsamen Geheimnissen arbeiten,<br />
es ist nicht auf <strong>Windows</strong> beschränkt. Falls ein Verbrecher es schafft, dieses Geheimnis auszuspähen,<br />
kann er es missbrauchen, um eine Identität zu beweisen, ohne überhaupt das<br />
Kennwort zu wissen, mit dem dieses Geheimnis generiert wurde.<br />
Das ist ein wichtiger Punkt. Wenn wir uns darin einig sind, dass Kennworthashwerte klartextäquivalent<br />
sind, ändert sich die Art und Weise, wie wir über Kennwortsicherheit denken.<br />
Erstens können wir sofort sehen, warum es sinnlos ist, die aktuellen NT-Hashwerte durch<br />
Hashwerte zu ersetzen, die mit einem Saltwert berechnet wurden: <strong>Die</strong> mit Saltwert berechneten<br />
Hashwerte sind ebenfalls klartextäquivalent. Sich mit einem Saltwert gegen den <strong>Die</strong>bstahl<br />
von Hashwerten schützen zu wollen, hat fatale Ähnlichkeit mit dem Versuch, einen<br />
abgetrennten Arm mit einem Pflaster zu verarzten. Das eigentliche Problem lässt sich auf<br />
diese Weise kaum beheben. Zweitens können wir sehen, dass das Kernproblem nicht die<br />
Kennworthashwerte sind, sondern die Tatsache, dass Angreifer Zugriff darauf haben. <strong>Die</strong><br />
einzige echte <strong>technische</strong> Lösung besteht darin, Frage-Antwort-Protokolle völlig durch<br />
Protokolle zu ersetzen, die mit öffentlichen Schlüsseln arbeiten. Das setzt aber eine durchgreifende<br />
Änderung an allen Plattformen voraus, daher ist kurzfristig wohl nicht damit zu<br />
rechnen.<br />
<strong>Die</strong> einzige Lösung besteht also darin, Angreifer daran zu hindern, auf Kennworthashwerte<br />
zuzugreifen. Zu diesem Zweck müssen wir die Zugriffsmöglichkeiten auf Kennworthashwerte<br />
einschränken und sicherstellen, dass wird unsere authentifizierenden <strong>Server</strong> ausreichend<br />
schützen. Kapitel 14 beschreibt diese Themen ausführlich.
46 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Schützen Ihrer Kennwörter<br />
Alle bisher betrachteten Angriffe können Sie weitgehend abwehren, indem Sie entweder<br />
bessere Kennwörter verwenden oder Ihr Netzwerk sicherer verwalten und betreiben. Kapitel<br />
14 beschreibt im Detail, wie Sie bei Verwaltung und Betrieb eines Netzwerks mehr<br />
<strong>Sicherheit</strong> erreichen. Weil Kennworthashwerte klartextäquivalent sind, hilft die Verwendung<br />
sicherer Kennwörter offensichtlich nicht gegen alle bisher beschriebenen Angriffe. Viele<br />
davon lassen sich deutlich abschwächen.<br />
Wodurch zeichnet sich ein sicheres Kennwort aus? Simple Antwort: je länger, desto besser!<br />
<strong>Die</strong> Länge ist bei Weitem der wichtigste Faktor, wenn es um die <strong>Sicherheit</strong> eines Kennworts<br />
geht. Tabelle 2.3 zeigt, wie lang ein aus n Zeichen bestehendes Kennwort, dessen Zeichen<br />
zufällig aus einem Satz von 32 Zeichen ausgewählt wurden, Angriffen widersteht, bei denen<br />
das Kennwort erraten oder geknackt werden soll.<br />
Tabelle 2.3 Dauer eines erfolgreichen Angriffs auf Kennwörter, die aus einem Satz von 32 Zeichen<br />
ausgewählt werden<br />
Länge Tage, bis das Kennwort erraten ist Tage, bis das Kennwort geknackt ist<br />
6 10 0<br />
7 331 0<br />
8 10.605 1<br />
9 339.355 27<br />
10 10.859.374 869<br />
11 347.499.971 27.800<br />
12 11.119.999.080 889.600<br />
13 355.839.970.558 28.467.198<br />
14 11.386.879.057.845 910.950.325<br />
Wie Sie in Tabelle 2.3 sehen, steigt die <strong>Sicherheit</strong> eines Kennworts gewaltig an, je länger es<br />
wird. Ein 14-Zeichen-Kennwort, das zufällig ausgewählte Zeichen aus einem bekannten<br />
Satz von 32-Zeichen umfasst, widersteht Rateversuchen über 31 Milliarden (!) Jahre. Sogar<br />
ein 8 Zeichen langes Kennwort ist nicht in einem praktikablen Zeitraum zu erraten, solange<br />
der Angreifer keine heuristischen Methoden nutzen kann. Das 14 Zeichen lange Kennwort<br />
widersteht dem Versuch, es zu knacken, 2,5 Millionen Jahre lang. Aber natürlich gilt weiterhin,<br />
dass es klartextäquivalent ist. Daher ist die Widerstandsfähigkeit gegen das Knacken<br />
nur relevant, falls es im Rahmen einer Frage-Antwort-Sequenz aufgezeichnet wurde.<br />
Viele Leute stellen sich aber vor allem die Frage, wie wichtig der Satz der verwendeten<br />
Zeichen für die <strong>Sicherheit</strong> des Kennworts ist. Je größer der Satz der Zeichen ist, mit denen<br />
sich der Angreifer herumschlagen muss, desto sicherer ist das Kennwort offensichtlich. <strong>Die</strong><br />
Wirkung ist aber bei Weitem nicht so nachhaltig wie bei der Länge. Tabelle 2.4 zeigt dieselben<br />
Daten wie Tabelle 2.3, aber für Kennwörter, die aus einem Satz von 95 Zeichen generiert<br />
werden.
Verwalten von Kennwörtern 47<br />
Tabelle 2.4 Dauer eines erfolgreichen Angriffs auf Kennwörter, die aus einem Satz von 95 Zeichen<br />
ausgewählt werden<br />
Länge Tage, bis das Kennwort erraten ist Tage, bis das Kennwort geknackt ist<br />
6 7.090 1<br />
7 673.551 54<br />
8 63.987.310 5.119<br />
9 6.078.794.461 486.304<br />
10 577.485.473.802 46.198.838<br />
11 54.861.120.011.233 4.388.889.601<br />
12 5.211.806.401.067.100 416.944.512.085<br />
13 495.121.608.101.375.000 39.609.728.648.110<br />
14 47.036.552.769.630.600.000 3.762.924.221.570.450<br />
Tabelle 2.4 zeigt, dass Kennwörter, die aus einem Satz von 95 Zeichen ausgewählt werden,<br />
zweifellos sicherer sind als Kennwörter, die aus einem Satz von nur 32 Zeichen generiert<br />
wurden. Aber ein 6 Zeichen langes Kennwort, das aus einem Satz von 95 Zeichen ausgewählt<br />
wurde, ist schwächer als ein 8-Zeichen-Kennwort aus einem Satz von 32-Zeichen. Da<br />
das Beherrschen von Komplexität eine verbreitete menschliche Schwäche ist, fällt es vielen<br />
Leuten wahrscheinlich leichter, sich ein 8 Zeichen langes Kennwort zu merken, das aus<br />
einem kleinem Satz häufig benutzter Zeichen besteht, als ein 6 Zeichen langes Kennwort,<br />
das aus kaum jemals verwendeten Zeichen besteht. Sie können diese Zahlen hernehmen, um<br />
eine geeignete Strategie für unterschiedliche Leute zu entwickeln, je nachdem, was sie bevorzugen.<br />
<strong>Die</strong> Daten zeigen aber deutlich, dass wir eine Menge Probleme im Zusammenhang<br />
mit Kennwörtern beseitigen können, wenn wir die Benutzer einfach dazu bringen,<br />
längere Kennwörter zu verwenden. Generell gilt: Kennwörter sind ein einwandfreier, sehr<br />
bequemer, verständlicher und einfach zu implementierender Authentifizierungsmechanismus.<br />
Ihr einziger Nachteil besteht darin, dass es Menschen schwerfällt, sich Kennwörter zu<br />
merken. Könnten wir die Menschen, die sie nutzen, aus dem System entfernen, wären Kennwörter<br />
wahrscheinlich die beste Möglichkeit, sich bei einem System zu authentifizieren.<br />
Glücklicherweise haben wir diese Möglichkeit.<br />
Hinweis <strong>Die</strong> Daten zur Widerstandsfähigkeit von Kennwörtern, die in den Tabellen 2.3 und 2.4 angegeben<br />
sind, basieren auf der Annahme, dass ein theoretischer Angreifer 600 Kennwörter pro Sekunde raten<br />
oder 7,5 Millionen Kennwörter pro Sekunde knacken kann. <strong>Die</strong>se Zahlen sind deutlich höher, als es ein<br />
einzelner Computer gegenwärtig erlaubt; das gilt sowohl für das Erraten von Kennwörtern als auch für das<br />
Knacken aufgezeichneter Frage-Antwort-Paare.<br />
Verwalten von Kennwörtern<br />
Benutzer wählen keine besonders guten Kennwörter, wenn sie völlig frei entscheiden dürfen.<br />
Aber wir müssen dafür sorgen, dass sie lange Kennwörter verwenden, um sich selbst<br />
wirksam zu schützen. Um dieses Dilemma zu lösen, müssen wir einige althergebrachte<br />
Konzepte neu bewerten, selbst wenn sie von vielen Leuten für absolute Wahrheiten gehalten<br />
werden.
48 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Verwenden anderer Authentifizierer<br />
Erstens ist ein Kennwort, das der Benutzer nicht weiß, besser als eines, das der Benutzer<br />
weiß. Falls Sie Smartcards einsetzen und das System so konfigurieren, dass für die Anmeldung<br />
eine Smartcard erforderlich ist, besitzt jedes Konto weiterhin ein Kennwort, aber dies<br />
ist ein langes und zufälliges Kennwort. Sein Hashwert kann weiterhin von jedem Computer<br />
gestohlen werden, an dem sich der Benutzer anmeldet, sofern Malware als Betriebssystem<br />
auf diesem Computer ausgeführt wird, aber Sie können fast sicher sein, dass sich das Kennwort<br />
niemals erraten lässt.<br />
Kennwörter sicher notieren<br />
<strong>Die</strong>jenigen unter uns, die den Einsatz von Smartcards in unseren Netzwerken nicht vorschreiben<br />
können, müssen sich damit abfinden, dass die Benutzer ihr Kennwort wissen müssen.<br />
Damit sie sich ihre Kennwörter besser merken können, erfanden die Chinesen im zweiten<br />
Jahrhundert eine verblüffende Technologie, das sogenannte »Papier«. Sie haben richtig<br />
gelesen: Ich behaupte, dass sich die Benutzer ihre Kennwörter notieren sollen. Momentan<br />
haben die meisten Organisationen eine Kennwortrichtlinie, die Kennwörter mit mindestens<br />
8 Zeichen Länge erfordert und vorschreibt, dass sie wenigstens drei unterschiedliche Zeichengruppen<br />
enthalten. Das Ergebnis? Benutzer wählen Kennwörter wie »Seattle1«. Wie Sie bei<br />
genauem Hinsehen erkennen, entspricht dieses Kennwort der Richtlinie. »Test1234« ist<br />
ebenfalls gültig, genauso wie »Password1«, »Passw0rd« und »Pa$$word«. Wenn Sie die<br />
Wahl haben, wäre es Ihnen dann nicht lieber, ein Benutzer trägt einen kleinen Zettel in seinem<br />
Geldbeutel mit sich, auf dem »Trink einen großen Milchkaffee vor der Arbeit!« steht?<br />
Falls ein Unbefugter diesen Zettel in die Hände bekommt, merkt der Benutzer es recht<br />
schnell und kann entsprechende Maßnahmen treffen, um das Kennwort zurückzusetzen<br />
(wenn Sie ihm gezeigt haben, wie das geht). Und was könnte der böse <strong>Die</strong>b überhaupt mit<br />
dem Zettel anfangen? Für welches System gilt dieses Kennwort? Ist es überhaupt ein Kennwort,<br />
oder vielleicht doch eine andere Notiz? Ein Kennwort, das der Benutzer notieren kann,<br />
ist viel leichter zu beherrschen als eines, das er sich merken muss, nachdem er es zweimal<br />
eingetippt hat. Und für all die anderen Kennwörter, die wir täglich benutzen, können Sie<br />
sogar ein elektronisches Kennwortverwaltungstool verwenden, zum Beispiel Password Safe<br />
(http://passwordsafe.sourceforge.net). Was ist wirklich schlechter: ein schwaches Kennwort,<br />
das sich der Benutzer merken kann, nachdem er es zweimal eingetippt hat, oder ein sehr<br />
starkes Kennwort, das an sicherer Stelle notiert wurde? Über welche Art von Gefahr machen<br />
wir uns denn hier Sorgen?<br />
Stellen Sie sich jetzt vor, Sie können Ihren Benutzern mitteilen, dass sie das Kennwort auf<br />
einem Zettel mit sich herumtragen können, bis sie es auswendig wissen. Danach sollten sie<br />
den Zettel in den Schredder stecken oder aufessen, ganz nach Belieben. Sie dürfen davon<br />
ausgehen, dass Sie in diesem Fall sogar eine Kennwortrichtlinie für 10 Zeichen lange<br />
Kennwörter durchsetzen können, ohne auf dem nächsten Scheiterhaufen zu landen.<br />
Nehmen Sie das »Wort« in »Kennwort« nicht zu wörtlich<br />
Im letzten Abschnitt lautete ein Beispielkennwort »Trink einen großen Milchkaffee vor der<br />
Arbeit!« Das ist kein Kennwort (oder Passwort). Es ist eine Passphrase. Es gibt keine Vorschrift,<br />
dass Kennwörter überhaupt Wörter sein müssen. Schon der Begriff Kennwort ist<br />
irreführend. <strong>Windows</strong> nimmt als Kennwort bereitwillig bis zu 127 Zeichen entgegen, die Sie
Verwalten von Kennwörtern 49<br />
beliebig aus allen Feldern Ihrer Tastatur auswählen dürfen (inklusive Leertaste). Und Sie<br />
wissen aus dem letzten Abschnitt auch, dass ein Kennwort umso stärker ist, je länger es ist.<br />
Eine Passphrase zu verwenden, ist die perfekte Methode, Ihr Kennwort länger zu machen.<br />
Passphrasen sind lang und daher sicher. Sie sind einfacher einzutippen und auswendig zu<br />
lernen als seltsame, weil sichere Kennwörter, zum Beispiel »hG%'3m.^«. Einfach ausgedrückt:<br />
Passphrasen passen zur Denkweise von Menschen. Menschen fassen ihre Gedanken<br />
in Wörter. Ich habe siebenjährige Kinder erlebt, die kein Problem mit Passphrasen hatten.<br />
Außerdem ist ein Satz wie der mit dem Milchkaffee viel, viel länger und um Größenordnungen<br />
sicherer als das seltsame, starke Kennwort. Wenn wir pessimistisch davon ausgehen,<br />
dass der Angreifer weiß, dass wir Passphrasen verwenden, dass diese Passphrase sieben<br />
Wörter lang ist und dass er sogar ein Wörterbuch hat, aus dem alle Wörter ausgewählt wurden,<br />
dauert es wahrscheinlich trotzdem Millionen von Jahren, die Passphrase zu erraten.<br />
Und das gilt sogar für den Fall, dass der Angreifer ein Angriffstool verwendet, das komplette<br />
Wörter durchwechselt statt einzelner Zeichen. Der Satz von Möglichkeiten ist viele Male<br />
größer als der Satz der Zeichen auf einer Tastatur. Falls Sie die Stärke noch ein wenig<br />
verbessern wollen, können Sie irgendwo eine der üblichen Ersetzungen verwenden. Tauschen<br />
Sie zum Beispiel ein »a« gegen ein »@« aus, ein »l« (Kleinbuchstabe L) durch eine<br />
»1« (Zahl 1), ein »e« durch eine »3« oder ein »o« durch eine »0«. In unserem 8 Zeichen<br />
langen Kennwort können wir von Glück reden, wenn wir eine dieser Ersetzungsmöglichkeiten<br />
haben und die Zahl der Möglichkeiten gerade einmal verdoppeln können. Im Fall der<br />
Passphrase erhalten wir schon 11 mögliche Ersetzungen, selbst wenn wir uns auf die 4 genannten<br />
Beispiele beschränken. Der Suchraum vergrößert sich dadurch um den Faktor<br />
2.048! Passphrasen sind als Authentifizierer enorm wirksam.<br />
Festlegen von Kennwortrichtlinien<br />
Schließlich sollten Sie natürlich Kennwortrichtlinien haben. Sie brauchen sowohl schriftlich<br />
festgehaltene Unternehmensrichtlinien als auch technisch erzwungene Richtlinien. Eine<br />
ausführliche Behandlung der schriftlichen Richtlinien würde den Umfang dieses Buchs<br />
sprengen. <strong>Die</strong> Richtlinien sollten aber realistisch sein, anders ausgedrückt: Verbieten Sie es<br />
nicht, Kennwörter aufzuschreiben. Sie sollten auch einen Leitfaden zur Verfügung stellen,<br />
in dem die Benutzer erklärt bekommen, wie sie Kennwörter auswählen sollten.<br />
Technische Richtlinien sollten domänenweit erzwungen werden, aber auch auf Mitgliedscomputern,<br />
falls Sie lokale Konten auf Mitgliedscomputern verwenden. Sie sollten komplexe<br />
und lange Kennwörter (mindestens 10 Zeichen sind sehr empfehlenswert, wenn Sie<br />
bedenken, dass es eine Weile dauern dürfte, bis alle Benutzer gute Kennwörter wählen) erzwingen,<br />
die regelmäßig geändert werden müssen. Entwickeln Sie aber eine sinnvolle Kombination<br />
dieser Richtlinien. Falls Sie 10 Zeichen lange Kennwörter fordern, gibt es nichts<br />
dagegen einzuwenden, sie 6 Monate oder 1 Jahr lang zu behalten. 8 Zeichen lange Kennwörter<br />
sollten Sie alle 3 bis 6 Monate wechseln. Wenn die Kennwörter kürzer als 8 Zeichen<br />
sind, ist es wahrscheinlich sinnvoll, sie monatlich zu ändern.<br />
Richtlinien können mit Gruppenrichtlinien verwaltet werden. Abbildung 2.14 zeigt die entsprechenden<br />
Einstellungen im Gruppenrichtlinienverwaltungs-Editor.<br />
Kennwortrichtlinien, die auf eine Domäne angewendet werden, gelten für Domänenkonten.<br />
Kennwortrichtlinien, die auf eine Organisationseinheit angewendet werden, gelten für lokale<br />
Konten auf allen Mitgliedscomputern in dieser Organisationseinheit.
50 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Abbildung 2.14 Kennwortrichtlinien können Sie über Gruppenrichtlinien verwalten<br />
Abgestimmte Kennwortrichtlinien<br />
Kunden haben immer wieder die Möglichkeit gefordert, Kennwortrichtlinien so zu verwalten,<br />
dass für unterschiedliche Benutzer in der Domäne jeweils andere Kennwortrichtlinien<br />
gelten. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> sind endlich solche abgestimmte Kennwortrichtlinien (engl.<br />
fine-grained password policies) verfügbar. Abgestimmte Kennwortrichtlinien stehen in allen<br />
Editionen von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zur Verfügung, aber nur wenn die Domänenfunktionsebene<br />
auf <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> gesetzt ist. Anders ausgedrückt: Sie müssen erst bei all<br />
Ihren Domänencontrollern ein Upgrade auf <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> durchführen, bevor Sie<br />
dieses Feature nutzen können.<br />
Abbildung 2.15 <strong>Die</strong>se Domäne verwendet unterschiedliche Kennwortrichtlinien für Administratoren<br />
und normale Benutzer
Verwalten von Kennwörtern 51<br />
Abgestimmte Kennwortrichtlinien haben vor allem die Aufgabe, für privilegierte Konten<br />
strengere Einstellungen festzulegen, aber weniger strenge Einstellungen für Konten von<br />
normalen Benutzern. In anderen Fällen kann es sinnvoll sein, eine spezielle Kennwortrichtlinie<br />
für Konten festzulegen, deren Kennwörter mit anderen Datenquellen synchronisiert<br />
werden.<br />
Abgestimmte Kennwortrichtlinien gelten nur für Benutzerobjekte oder inetOrgPerson-<br />
Objekte, falls Sie solche Objekte statt Benutzerobjekten und globalen <strong>Sicherheit</strong>sgruppen<br />
einsetzen. Abgestimmte Kennwortrichtlinien sind mithilfe eines Kennworteinstellungscontainers<br />
(Password Settings Container, PSC) unter dem Container System der Domäne implementiert.<br />
(In Kapitel 9, »Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong>«,<br />
finden Sie weitere Informationen über Active Directory.) Der PSC speichert ein oder mehrere<br />
Kennworteinstellungsobjekte (Password Settings Object, PSO), die die eigentlichen<br />
Richtlinien enthalten. Abbildung 2.15 zeigt einen PSC mit zwei PSOs.<br />
Leider hat Microsoft in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> keine besonders gute Benutzeroberfläche zum<br />
Verwalten der abgestimmten Kennwortrichtlinien zur Verfügung gestellt. Gehen Sie folgendermaßen<br />
vor, um eine unterschiedliche Kennwortrichtlinie für Administratoren zu konfigurieren:<br />
1. Starten Sie den ADSI-Editor, indem Sie adsiedit.msc eingeben.<br />
2. Stellen Sie die Verbindung zu Ihrer Domäne her, indem Sie im linken Fensterabschnitt<br />
mit der rechten Maustaste auf den Knoten ADSI-Editor klicken und den Befehl Verbindung<br />
herstellen wählen. Geben Sie den Namen der Domäne ein.<br />
3. Erweitern Sie die Domäne, dann den DC-Knoten und den Knoten CN=System. Wählen<br />
Sie CN=Password Settings Container aus.<br />
4. Klicken Sie mit der rechten Maustaste auf CN=Password Settings Container, wählen Sie<br />
den Befehl Neu und dann Objekt.<br />
5. Wählen Sie den Eintrag msDS-PasswordSettings aus (Abbildung 2.16) und klicken Sie<br />
auf Weiter.<br />
Abbildung 2.16 Um eine abgestimmte Kennwortrichtlinie zu erstellen,<br />
müssen Sie ein neues msDS-PasswordSettings-Objekt erstellen
52 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
6. Geben Sie dem neuen Objekt einen aussagekräftigen Namen, zum Beispiel »Administrative<br />
Kennwortrichtlinie«.<br />
7. Klicken Sie auf Weiter und geben Sie den Vorrangwert für das Objekt an. <strong>Die</strong>ser Wert<br />
legt fest, welche Richtlinie Vorrang hat, falls zwei Richtlinien auf denselben Benutzer<br />
angewendet werden. <strong>Die</strong> Einstellung mit dem kleineren Vorrangwert gewinnt.<br />
8. Gehen Sie die übrigen Assistentenseiten durch und tragen Sie Werte für alle Elemente<br />
ein. <strong>Die</strong> möglichen Werte sind in Tabelle 2.5 aufgeführt.<br />
9. Wenn Sie die Sperrdauer (msDS-LockoutDuration) konfiguriert haben, wird die Seite<br />
aus Abbildung 2.17 angezeigt. Hier müssen Sie konfigurieren, auf welche Benutzer dieses<br />
PSO angewendet wird. Beginnen Sie diesen Konfigurationsvorgang, indem Sie auf<br />
Weitere Attribute klicken.<br />
Abbildung 2.17 Auf dieser Seite können Sie konfigurieren,<br />
auf wen das Objekt angewendet wird<br />
10. Wählen Sie in der Dropdownliste Anzuzeigende Eigenschaft den Eintrag<br />
msDS-PSOAppliesTo aus.<br />
11. Geben Sie den definierten Namen (Distinguished Name, DN) des Benutzers oder der<br />
globalen <strong>Sicherheit</strong>sgruppe ein, auf die Sie diese Richtlinie anwenden wollen. Zum Beispiel<br />
können Sie die Richtlinie auf die Gruppe Domänen-Admins anwenden, indem Sie<br />
die folgende Syntax verwenden, aber dabei die DC-Attribute für Ihre eigene Domäne<br />
eintragen: CN=Domänen-Admins,CN=Benutzer,DC=contoso,DC=com. Das Ergebnis<br />
sehen Sie in Abbildung 2.18. Klicken Sie auf OK.<br />
12. Klicken Sie auf Fertig stellen.
Abbildung 2.18 Mit dem Attribut msDS-PSOAppliesTo wenden<br />
Sie die Richtlinie auf eine Gruppe oder einen Benutzer an<br />
Tabelle 2.5 Werte für abgestimmte Kennwortrichtlinien<br />
Verwalten von Kennwörtern 53<br />
Attributname Beschreibung Möglicher<br />
Wertebereich<br />
msDS-PasswordSettings-<br />
Precedence<br />
msDS-PasswordReversible-<br />
Encryption-<br />
Enabled<br />
msDS-PasswordHistory-<br />
Length<br />
msDS-PasswordComplexityEnabled<br />
msDS-<br />
Minimum-<br />
Password-<br />
Length<br />
Definiert, welche Richtlinie Vorrang hat, falls mehrere Richtlinien auf denselben<br />
Benutzer angewendet werden. <strong>Die</strong> Richtlinie mit dem kleinsten Vorrangwert<br />
gewinnt.<br />
Legt fest, ob Kennwörter mit umkehrbarer Verschlüsselung gespeichert<br />
werden. False bedeutet, dass sie nicht mit umkehrbarer Verschlüsselung<br />
gespeichert werden.<br />
Legt fest, wie viele Kennwörter das System für einen Benutzer aufzeichnet.<br />
<strong>Die</strong>s bedeutet in der Praxis, dass der Benutzer ein früher verwendetes<br />
Kennwort erst wieder hernehmen kann, wenn er mindestens so viele andere<br />
Kennwörter eingestellt hat, wie in diesem Attribut festgelegt sind.<br />
False, falls die Kennwortkomplexität für diese Benutzerkonten nicht erforderlich<br />
ist. True, falls Kennwortkomplexität erforderlich ist.<br />
<strong>Die</strong> minimale Länge für ein Kennwort. Kennwörter können bis zu 255 Zeichen<br />
lang sein, aber ältere Systeme unterstützen nur Kennwörter mit maximal<br />
127 Zeichen.<br />
Größer 0<br />
FALSE / TRUE<br />
0 bis 1024<br />
FALSE / TRUE<br />
0 bis 255
54 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Attributname Beschreibung Möglicher<br />
Wertebereich<br />
msDS-MinimumPassword-<br />
Age<br />
msDS-MaximumPassword-<br />
Age<br />
msDS-Lockout-<br />
Threshold<br />
msDS-Lockout-<br />
Observation-<br />
Window<br />
msDS-Lockout-<br />
Duration<br />
Wie alt ein Kennwort mindestens sein muss, bevor es wieder geändert<br />
werden kann. Wenn Sie hier einen vernünftigen Wert einstellen, zum Beispiel<br />
1 oder 2 Tage, ist sichergestellt, dass ein Benutzer nicht automatisch<br />
durch die Kennwortchronik wechseln und das gerade erst verwendete<br />
Kennwort erneut verwenden kann. <strong>Die</strong>ser Wert (wie alle Zeitwerte) wird im<br />
Format Tage:Stunden:Minuten:Sekunden eingegeben. 02:00:00:00 steht<br />
also für zwei Tage.<br />
Legt fest, wie alt ein Kennwort sein darf, bevor es geändert werden muss.<br />
Wenn Kennwörter niemals ablaufen, können Sie den Wert (Nie) eintragen.<br />
Geben Sie andernfalls den Zeitraum im üblichen Zeitformat ein, zum Beispiel<br />
180:00:00:00.<br />
Legt fest, wie oft ein Benutzer das Kennwort falsch eingeben kann, bevor<br />
das Konto gesperrt wird. Mit dem Wert 0 können Sie die Kontosperrung<br />
deaktivieren.<br />
Das Zeitintervall, für das die Zahl falscher Kennworteingaben summiert wird.<br />
Falls dieser Wert zum Beispiel auf 00:00:30:00 gesetzt ist, hat der Benutzer<br />
msDS-LockoutThreshold Versuche innerhalb von 30 Minuten, danach wird<br />
der Zähler zurückgesetzt.<br />
Legt fest, wie lange das Konto gesperrt bleibt, bevor die Sperre automatisch<br />
aufgehoben wird. Wenn Sie den Wert (Nie) eintragen, muss das Konto von<br />
einem Administrator entsperrt werden.<br />
(Kein)<br />
00:00:00:00 bis<br />
msDS-Maximum-<br />
PasswordAge-<br />
Wert<br />
(Nie)<br />
msDS-Minimum-<br />
PasswordAge-<br />
Wert bis (Nie)<br />
msDS-Maximum-<br />
PasswordAge darf<br />
nicht 0 sein<br />
0 bis 65535<br />
(Kein)<br />
00:00:00:01 bis<br />
msDS-Lockout-<br />
Duration-Wert<br />
(Kein)<br />
(Nie)<br />
msDS-Lockout-<br />
Observation-<br />
Window-Wert bis<br />
(Nie)<br />
Tools zum Verwalten abgestimmter Kennwortrichtlinien<br />
Sie haben wahrscheinlich schon erraten, dass Microsoft nicht mehr genug Zeit hatte, um<br />
gute Tools zum Verwalten abgestimmter Kennwortrichtlinien zu entwickeln. Glücklicherweise<br />
stehen einige andere Möglichkeiten zur Verfügung. Joeware.net bietet unter<br />
http://www.joeware.net/freetools/tools/psomgr/index.htm ein Befehlszeilentool an.<br />
Es steht ein GUI-Tool für PowerGUI zur Verfügung, das auf der <strong>Windows</strong> PowerShell<br />
von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> aufsetzt:<br />
http://powergui.org/entry.jspa?externalID=882&categoryID=46<br />
Ein weiteres kostenloses GUI-Tool stellt Special Operations Software zur Verfügung:<br />
http://www.specopssoft.com/wiki/index.php/SpecopsPasswordPolicybasic/SpecopsPass<br />
wordPolicybasic/
Weitere Informationen 55<br />
Vorrang bei abgestimmten Kennwortrichtlinien<br />
Ich habe weiter oben erwähnt, dass für abgestimmte Kennwortrichtlinien ein Vorrangwert<br />
festgelegt wird. <strong>Die</strong>ser Wert dient dazu, den Konflikt für den Fall zu lösen, dass zwei PSOs<br />
auf denselben Benutzer angewendet werden. Der Domänencontroller führt die Richtlinien<br />
nicht zusammen, daher muss ein Weg gefunden werden, den Konflikt zu beseitigen. <strong>Die</strong><br />
Auflösung funktioniert nach folgendem Schema:<br />
1. Falls nur ein PSO mit dem Benutzerobjekt verknüpft ist, wird dieses PSO verwendet.<br />
Falls mehrere PSOs mit einem Benutzerobjekt verknüpft sind, wird eine Warnmeldung<br />
in das Ereignisprotokoll eingetragen und das PSO mit dem kleinsten Vorrangwert wird<br />
verwendet.<br />
2. Falls kein PSO mit dem Benutzerobjekt verknüpft ist, vergleicht das System die Vorrangwerte<br />
aller PSOs, die mit Gruppen verknüpft sind, bei denen der Benutzer Mitglied<br />
ist. Das PSO mit dem kleinsten Vorrangwert wird verwendet.<br />
3. Falls keine dieser Methoden ergibt, dass ein PSO ausgewählt wurde, gilt die Standarddomänenrichtlinie.<br />
Zusammenfassung<br />
Kennwörter und Authentifizierung sind ein kompliziertes, aber sehr interessantes Gebiet. Sie<br />
bilden die Basis für vieles, was wir in allen anderen Bereichen der <strong>Sicherheit</strong> tun. Sie brauchen<br />
zwar kein Experte für Authentifizierung zu sein, um <strong>Windows</strong>-<strong>Server</strong> zu verwalten,<br />
aber Sie müssen die grundlegenden Konzepte so weit verstehen, dass sie sinnvolle Entscheidungen<br />
bezüglich der Authentifizierung treffen können. Falls Sie sich schon einmal mit<br />
Consultants oder Auditoren herumschlagen mussten, haben Sie wahrscheinlich schon mit<br />
einem der wenigen, aber immer noch viel zu zahlreichen Leute zu tun gehabt, die nichts von<br />
Kennwörtern und Authentifizierung verstehen, aber trotzdem Forderungen aufstellen, wie<br />
sie verwaltet werden sollen. Schon etliche Netzwerke wurden entweder durch diese Änderungen<br />
direkt zerstört oder anschließend gehackt, weil die Änderungen keinen Schutz gegen<br />
schwerwiegende Angriffe boten. Nur wenn Sie genug davon verstehen, wie Authentifizierung<br />
funktioniert, können Sie sinnvolle Entscheidungen darüber treffen, wie Sie die »Schlüssel<br />
zur Stadt« verwalten wollen, oder in diesem Fall: die Authentifizierer, die Zugriff auf Ihr<br />
Netzwerk gewähren.<br />
Weitere Informationen<br />
Burnett, M.: Perfect Passwords: Selection, Protection, Authentication (Syngress, 2005).<br />
Johansson, J. M.: Protect Your <strong>Windows</strong> Network (Addison-Wesley, 2005).<br />
Johansson, J. M.: »The Most Misunderstood Security Setting of All Time«. TechNet<br />
Magazine.<br />
Kent, J.: »Malaysia Car Thieves Steal Finger« unter http://news.bbc.co.uk/2/hi/asiapacific/4396831.stm.
56 Kapitel 2: Authentifizierung und Authentifizierungsprotokolle<br />
Microsoft Corporation: »<strong>Server</strong> Core Installation Option of <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Stepby-Step<br />
Guide« unter http://technet2.microsoft.com/windowsserver<strong>2008</strong>/en/library/<br />
47a23a74-e13c-46de-8d30-ad0afb1eaffc1033.mspx?mfr=true.<br />
Microsoft Corporation: »Step-by-Step Guide for Fine-Grained Password and Account<br />
Lockout Policy Configuration« unter http://go.microsoft.com/fwlink/?LinkID=91477.<br />
Wagner, M.: »The Password Is: Chocolate« unter http://informationweek.com/story/<br />
showArticle.jhtml?articleID=18902123.
K A P I T E L 3<br />
Objekte: Was Sie wollen<br />
Von Jesper M. Johansson<br />
In diesem Kapitel:<br />
Terminologie der Zugriffssteuerung ....................................... 57<br />
Tools zum Verwalten von Berechtigungen ................................... 81<br />
Wichtige Änderungen bei der Zugriffssteuerung in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ............. 84<br />
Benutzerrechte und Privilegien .......................................... 85<br />
RBAC/AZMAN ..................................................... 89<br />
Zusammenfassung .................................................. 90<br />
Weitere Informationen ................................................ 90<br />
Ich weiß, was Sie denken: Jetzt haben Sie schon zwei komplette Kapitel gelesen, und bisher<br />
ging es um nichts anderes als Benutzer! Menschen! Wen interessieren die schon? Ich habe<br />
jetzt eine gute und eine schlechte Nachricht für Sie. <strong>Die</strong> gute Nachricht ist, dass wir gleich<br />
damit beginnen werden, in abstrakte und mysteriöse <strong>technische</strong> Konzepte wie zum Beispiel<br />
<strong>Sicherheit</strong>sbeschreibungen einzutauchen. <strong>Die</strong> schlechte Nachricht ist, dass dies alles dazu<br />
dient, unseren Benutzern zu helfen und ihnen sicheren Datenzugriff bieten zu können.<br />
Wenn wir die Menschen eine Weile ignorieren (was alle <strong>Sicherheit</strong>sexperten gerne tun würden),<br />
sind Objekte die Dinge, die wir vor den Benutzern schützen wollen. (Falls Sie noch<br />
nicht so lange im Bereich <strong>Sicherheit</strong> arbeiten wie ich, können Sie auch diese naive Definition<br />
verwenden: auf die wir Benutzern den Zugriff ermöglichen wollen.) In diesem Kapitel<br />
sehen wir uns an, welche Technologien den Zugriff auf Objekte steuern. Das ist eines der<br />
<strong>technische</strong>r orientierten Kapitel in diesem Buch. Ich denke, es ist wichtig, dass ein Administrator<br />
die grundlegende Funktionsweise dieser Technologien kennt. Nur so ist er in der<br />
Lage, <strong>Windows</strong> sinnvoll zu verwalten. Wir beschäftigen uns hier mit Tools zum Verwalten<br />
und Objekten und sehen uns an, wie sich die Zugriffssteuerung in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
geändert hat. Ein kurzer Abschnitt zur rollenbasierten Zugriffssteuerung folgt am Ende.<br />
Bevor wir damit anfangen, muss ich aber sicherstellen, dass wir uns über die Terminologie<br />
einig sind.<br />
Terminologie der Zugriffssteuerung<br />
Falls Sie bisher noch nicht mit grundlegenden Konzepten der <strong>Windows</strong>-<strong>Sicherheit</strong> gearbeitet<br />
haben, müssen Sie eine Menge seltsamer Begriffe lernen. Und selbst wenn Sie die <strong>Sicherheit</strong>sinfrastruktur<br />
in anderen Betriebssystemen verwaltet haben, müssen Sie sich in <strong>Windows</strong><br />
an einige neue Begriffe gewöhnen. <strong>Die</strong>ser Abschnitt definiert die wichtigsten Konzepte, die<br />
bei der Zugriffssteuerung in <strong>Windows</strong> verwendet werden.<br />
57
58 Kapitel 3: Objekte: Was Sie wollen<br />
Geschützte Objekte<br />
Der Grundbaustein für die <strong>Sicherheit</strong>sverwaltung in <strong>Windows</strong> ist ein geschütztes Objekt<br />
(engl. securable object). Ein geschütztes Objekt ist schlicht irgendeine Art von Objekt, auf<br />
das Berechtigungen angewendet werden können. Das geschützte Objekt, mit dem Sie vermutlich<br />
am häufigsten zu tun hatten, ist eine Datei. Im Dateisystem NTFS können sowohl<br />
auf Dateien als auch auf Verzeichnisse Berechtigungen angewendet werden. <strong>Die</strong> Berechtigungen<br />
werden übrigens in den Dateisystemmetadaten gespeichert, nicht in der Datei selbst,<br />
aber dieses <strong>technische</strong> Detail ist für einen Systemadministrator letztlich unerheblich. Unterschiedliche<br />
Typen geschützter Objekte sind:<br />
Dateien<br />
Verzeichnisse<br />
Registrierungsschlüssel<br />
Active Directory-Objekte<br />
Kernobjekte (Ereignisse, Semaphore, Mutexe)<br />
<strong>Die</strong>nste<br />
Threads<br />
Prozesse<br />
Firewallports (neu in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>)<br />
Arbeitsstationen und Desktops<br />
<strong>Sicherheit</strong>sbeschreibungen<br />
Alle geschützten Objekte haben eines gemeinsam: Sie sind mit einer <strong>Sicherheit</strong>sbeschreibung<br />
(Security Descriptor, SD) verknüpft. <strong>Die</strong> SD ist das Konstrukt, das alle <strong>Sicherheit</strong>sinformationen<br />
enthält, die mit dem Objekt verknüpft sind. Eine <strong>Sicherheit</strong>sbeschreibung ist<br />
gar nicht sonderlich kompliziert. Abbildung 3.1 zeigt ihren Aufbau.<br />
Abbildung 3.1 <strong>Die</strong> <strong>Sicherheit</strong>sbeschreibung enthält im Wesentlichen Zeiger<br />
auf andere <strong>Sicherheit</strong>sobjekte<br />
<strong>Die</strong> <strong>Sicherheit</strong>sbeschreibung können Sie als Tabelle mit 5 Zeilen zu jeweils 32 Bits betrachten.<br />
<strong>Die</strong> erste Zeile in Abbildung 3.1 (wie auch in den weiteren Abbildungen) zeigt die Bitposition<br />
jedes Elements. Beachten Sie, dass die Nummern von links nach rechts kleiner<br />
werden. <strong>Die</strong> Ursache ist die Datenstruktur der Intel-Prozessoren, auf denen <strong>Windows</strong> läuft.<br />
Weitere Informationen finden Sie im Textkasten »Warum zählt <strong>Windows</strong> rückwärts?«
Terminologie der Zugriffssteuerung 59<br />
Warum zählt <strong>Windows</strong> rückwärts?<br />
Abbildung 3.1 und die nachfolgenden Abbildung zeigen Tabellen mit Bitstrukturen. <strong>Die</strong><br />
Nummerierung ganz oben scheint dabei verkehrt herum zu laufen. <strong>Die</strong>s sind die Bitpositionen<br />
für die Objekte in der Struktur. Zum Beispiel umfasst die Versionsangabe einer SD<br />
8 Bits, die in den Bits 0 bis 7 der SD liegen. Der Zeiger auf den Besitzer beginnt bei Bitposition<br />
32 und so weiter.<br />
<strong>Die</strong> Spalten sind so nummeriert, weil <strong>Windows</strong> ein sogenanntes Little-endian-Betriebssystem<br />
ist. Alle Speicherstrukturen sind so gespeichert, dass die Bits von rechts nach links<br />
gezählt werden. Das ist eigentlich ein Artefakt der Prozessorarchitektur, im Fall von <strong>Windows</strong><br />
basiert dies auf der x86-Architektur, die bis vor Kurzem die weitaus wichtigste Architektur<br />
für <strong>Windows</strong> war. Auch die x64-Architektur arbeitet im Little-endian-Format.<br />
<strong>Die</strong> Vor- und Nachteile des Little-endian-Formats und seinem Gegenstück, dem Bigendian-Format,<br />
haben geradezu religiöse Debatten unter den Leuten ausgelöst, die sich<br />
mit solchen Dingen beschäftigen. Beide Methoden haben Vorteile, und in der Praxis brauchen<br />
Sie sich ohnehin kaum darum zu kümmern, sofern Sie kein Entwickler sind.<br />
<strong>Die</strong> letzten vier Zeilen in der SD sind Zeiger auf etwas anderes. <strong>Die</strong> zweite Zeile in Abbildung<br />
3.1 ist ein Zeiger auf eine <strong>Sicherheit</strong>s-ID (Security Identifier, SID), die für den Besitzer<br />
des Objekts steht. <strong>Die</strong> dritte Zeile ist ein Zeiger auf eine SID, die für die primäre Gruppe<br />
des Besitzers steht. Das Konzept der primären Gruppe wird ausschließlich für POSIX-Kompatibilität<br />
benötigt, nicht für native <strong>Windows</strong>-Operationen. In POSIX werden Berechtigungen<br />
nur drei Entitäten gewährt: dem Besitzer, der Gruppe des Besitzers und allen Benutzern.<br />
Damit es eine Gruppe gibt, der eine Berechtigung gewährt werden kann, verwendet <strong>Windows</strong><br />
ein Konzept für eine primäre Gruppe. <strong>Die</strong>s ist der entsprechende Eintrag in einer SD.<br />
<strong>Die</strong> letzten zwei Zeilen sind Zeiger auf die SACL (System Access Control List, Systemzugriffssteuerungsliste)<br />
beziehungsweise DACL (Discretionary Access Control List, freigegebene<br />
Zugriffssteuerungsliste).<br />
<strong>Die</strong> erste Zeile enthält eine Versionsnummer, die momentan immer 1 ist, 8 reservierte Bits<br />
und ein Steuerfeld. Das Steuerfeld enthält eine Reihe von Flags, die die Aufgabe der <strong>Sicherheit</strong>sbeschreibung<br />
festlegen. Das Feld kann eine Kombination unterschiedlicher Flagwerte<br />
sein. <strong>Die</strong> meisten Werte sind in Tabelle 3.1 aufgeführt. Dort ist auch das SDDL-Flag (Security<br />
Descriptor Definition Language) für den Wert angegeben (sofern vorhanden). <strong>Die</strong> Aufgabe<br />
dieses Flags wird weiter unten in diesem Kapitel noch ausführlich erklärt. Vorerst können<br />
Sie es ignorieren.<br />
Tabelle 3.1 Steuerflags in einer <strong>Sicherheit</strong>sbeschreibung<br />
Flagname SDDL-<br />
Flag<br />
Flagwert Beschreibung<br />
SE_OWNER_DEFAULTED 0x0001 <strong>Die</strong> <strong>Sicherheit</strong>s-ID (Security Identifier, SID), auf die das Besitzerfeld<br />
verweist, wurde durch einen Standardmechanismus<br />
bereitgestellt.<br />
SE_GROUP_DEFAULTED 0x0002 <strong>Die</strong> <strong>Sicherheit</strong>s-ID, auf die das Gruppenfeld verweist, wurde<br />
durch einen Standardmechanismus bereitgestellt.<br />
SE_DACL_PRESENT 0x0004 <strong>Die</strong>se SD verweist auf eine DACL. Falls dieses Flag nicht<br />
gesetzt ist, hat die SD eine NULL-DACL.
60 Kapitel 3: Objekte: Was Sie wollen<br />
Flagname SDDL-<br />
Flag<br />
Flagwert Beschreibung<br />
SE_DACL_DEFAULTED 0x0008 <strong>Die</strong> DACL wurde durch einen Standardmechanismus festgelegt,<br />
nicht explizit. Das ist üblich bei Systemobjekten, aber<br />
nicht bei Dingen wie Dateisystemobjekten, Registrierungsschlüsseln<br />
und so weiter.<br />
SE_SACL_PRESENT 0x0010 <strong>Die</strong>se SD enthält einen Zeiger auf eine SACL.<br />
SE_SACL_DEFAULTED 0x0020 <strong>Die</strong> SACL wurde durch einen Standardmechanismus eingetragen.<br />
SE_DACL_AUTO_INHERIT_<br />
REQ<br />
SE_SACL_AUTO_INHERIT_<br />
REQ<br />
AR 0x0100 <strong>Die</strong> DACL muss an untergeordnete Objekte vererbt werden.<br />
Falls dieses Flag zum Beispiel bei einem Verzeichnis gesetzt<br />
ist, erben Unterverzeichnisse und Dateien die DACL. <strong>Die</strong>ses<br />
Flag definiert einen alten Vererbungsmechanismus, der in<br />
erster Linie in <strong>Windows</strong> NT 4.0 und seinen Vorgängern verwendet<br />
wurde. Das Flag wird von den meisten modernen<br />
Tools ignoriert. Neuere <strong>Windows</strong>-Versionen unterstützen die<br />
Vererbung einzelner Einträge in der ACL.<br />
0x0200 <strong>Die</strong> SACL muss an untergeordnete Objekte vererbt werden.<br />
Wie beim entsprechenden DACL-Flag wird dieser Mechanismus<br />
nicht mehr verwendet.<br />
SE_DACL_AUTO_INHERITED AI 0x0400 <strong>Die</strong> DACL wurde von einem übergeordneten Objekt geerbt,<br />
zum Beispiel einem Verzeichnis.<br />
SE_SACL_AUTO_INHERITED 0x0800 <strong>Die</strong> SACL wurde von einem übergeordneten Objekt geerbt.<br />
SE_DACL_PROTECTED P 0x1000 <strong>Die</strong> DACL ist gegen Vererbung geschützt. Das bedeutet, dass<br />
die DACL eines übergeordneten Objekts die DACL des untergeordneten<br />
Objekts nicht überschreibt.<br />
SE_SACL_PROTECTED 0x2000 <strong>Die</strong> SACL ist geschützt.<br />
Zugriffsteuerungslisten<br />
Der vierte Zeiger in der <strong>Sicherheit</strong>sbeschreibung verweist auf eine DACL (Discretionary<br />
Access Control List). Eine DACL ist einer von drei unterschiedlichen Typen von Zugriffssteuerungslisten<br />
(Access Control List, ACL). <strong>Windows</strong> unterstützt zwei dieser drei Typen.<br />
<strong>Die</strong> drei ACL-Typen werden für unterschiedliche Zwecke verwendet. Eine ACL dient normalerweise<br />
dazu, Berechtigungen für ein Objekt zu definieren. DACLs und MACLs (Mandatory<br />
Access Control List) haben diesen Zweck.<br />
Normalerweise ist eine DACL gemeint, wenn wir über eine ACL in <strong>Windows</strong> reden. Eine<br />
DACL kann vom Administrator oder Objektbesitzer verwaltet werden. Der Administrator<br />
kann zum Beispiel einem anderen Benutzer die Berechtigung gewähren, in ein Objekt zu<br />
schreiben. Das System, das die Berechtigungen durchsetzt, sorgt dafür, dass die definierten<br />
Regeln eingehalten werden. Wenn der Administrator denkt, dass der andere Benutzer keinen<br />
Zugriff mehr auf das Objekt braucht, kann er die Berechtigungen ändern. Das System hat<br />
nur die Aufgabe, die Berechtigungen durchzusetzen, die der Administrator, der Besitzer oder<br />
ein anderer Benutzer, der die Berechtigung zum Ändern von Berechtigungen besitzt, festgelegt<br />
hat. <strong>Die</strong> Berechtigungen werden also immer von irgendwelchen Benutzern gesteuert.
Terminologie der Zugriffssteuerung 61<br />
Eine MACL wird dagegen nicht von einem Benutzer verwaltet. Alle Daten werden mit einer<br />
Kennzeichnung versehen, die angibt, wie wichtig oder vertraulich das jeweilige Objekt ist.<br />
Auf Basis dieser Kennzeichnung erzwingt das System die Zugriffssteuerung für dieses Objekt.<br />
Der große Unterschied besteht in diesem Fall darin, dass nicht von einem anderen Benutzer<br />
im System festgelegt wird, welche Operationen ein anderer Benutzer mit dem Objekt<br />
durchführen darf. <strong>Die</strong> Berechtigungen werden allein vom System erzwungen. <strong>Die</strong>se ACL ist<br />
also verpflichtend (engl. mandatory). Falls Sie die CISSP-Prüfung bestanden oder sich mit<br />
theoretischen <strong>Sicherheit</strong>smodellen beschäftigt haben, sind Sie wahrscheinlich mit dem Bell-<br />
LaPadula-Modell der <strong>Sicherheit</strong> vertraut. <strong>Die</strong>ses Modell beschreibt ein System der verpflichtenden<br />
Zugriffssteuerung (Mandatory Access Control, MAC). <strong>Windows</strong> unterstützt<br />
MACLs nicht.<br />
Schließlich gibt es noch SACLs (System Access Control List). SACLs haben genau denselben<br />
Aufbau wie DACLs. Aber während DACLs steuern, wer was mit dem Objekt tun darf,<br />
steuern SACLs, welche Zugriffsversuche überwacht werden. Nehmen wir zum Beispiel an,<br />
wir haben eine ACL, die Administratoren Schreibzugriff zuweist. Falls diese ACL eine DACL<br />
ist, gewährt sie Administratoren die Berechtigung, in das Objekt zu schreiben. Falls die ACL<br />
eine SACL ist, bewirkt sie, dass jedes Mal, wenn ein Mitglied der Administratorengruppe in<br />
das Objekt schreibt, ein Überwachungsereignis aufgezeichnet wird. Weitere Informationen<br />
zu SACLs und Überwachung finden Sie in Kapitel 8, »Überwachung«.<br />
Aufbau einer ACL<br />
Wie bei einer <strong>Sicherheit</strong>sbeschreibung lässt sich der Aufbau einer ACL in Tabellenform<br />
darstellen. Den Header einer ACL sehen Sie in Abbildung 3.2. Aber während bei einer <strong>Sicherheit</strong>sbeschreibung<br />
der Inhalt variabler Länge (zum Beispiel DACL und SACL) als Zeiger<br />
definiert ist, sodass die Länge der <strong>Sicherheit</strong>sbeschreibung selbst immer gleich bleibt, eignet<br />
sich diese Struktur nicht für eine ACL, weil sie praktisch beliebig lang sein kann.<br />
Abbildung 3.2 Der ACL-Header enthält die Metadaten der ACL<br />
Der erste Teil einer ACL (von rechts nach links) ist ein 16-Bit-Wert, der die Größe der ACL<br />
in der Einheit Byte angibt. Das bedeutet, dass eine ACL maximal 64 KByte lang sein kann.<br />
Neben der Versionsnummer ist der einzige andere Teil die Zahl der ACEs (Access Control<br />
List Entry, Zugriffssteuerungseintrag). <strong>Die</strong> ACEs werden an die ACL angehängt, aber normalerweise<br />
werden sie als eigenständige Struktur betrachtet.<br />
Zugriffssteuerungseinträge<br />
Der ACE ist das Arbeitspferd der Zugriffssteuerung. Er definiert das Subjekt und welche<br />
Berechtigungen dieses Subjekt bezüglich des Objekts hat. Abbildung 3.3 zeigt den Aufbau<br />
des ACE.
62 Kapitel 3: Objekte: Was Sie wollen<br />
Abbildung 3.3 <strong>Die</strong> Größe des ACE ist variabel, weil er eine SID enthält, deren Größe schwanken kann<br />
Der erste Teil eines ACE ist das Größenattribut. <strong>Die</strong>s ist wiederum ein 16-Bit-Wert, aber<br />
offensichtlich kann ein ACE nicht so groß sein, weil er dann nicht mehr in eine ACL passen<br />
würde. Der ACE hat aber eine variable Länge, weil er eine SID enthält, deren Größe nicht<br />
fest ist. <strong>Die</strong> SID definiert, für welches Subjekt der ACE gilt. Der ACE hat außerdem einen<br />
Satz von 8 Flags und 8 Bits, die den ACE-Typ definieren. <strong>Die</strong> Flags definieren, wie der ACE<br />
erstellt oder verarbeitet wurde. Tabelle 3.2 beschreibt die wichtigsten Flags, wiederum mit<br />
den SDDL-Verknüpfungen (Security Descriptor Definition Language). <strong>Die</strong>se SDDL-Verknüpfungen<br />
werden im Abschnitt »Security Descriptor Definition Language« weiter unten<br />
in diesem Kapitel genauer beschrieben.<br />
Tabelle 3.2 Wichtige ACE-Flags<br />
Flag SDDL-Verknüpfung<br />
Bedeutung<br />
OBJECT_INHERIT_ACE OI <strong>Die</strong>ser ACE sollte von untergeordneten Objekten geerbt werden.<br />
CONTAINER_INHERIT_ACE CI <strong>Die</strong>ser ACE sollte von untergeordneten Containern geerbt werden.<br />
NO_PROPAGATE_INHERIT_ACE NP <strong>Die</strong>ser ACE wird an untergeordnete Objekte vererbt, aber nur auf<br />
der nächsten Hierarchieebene. Sobald der ACE einmal vererbt<br />
wurde, löscht das System die OI- und/oder CI-Flags.<br />
INHERIT_ONLY_ACE IO <strong>Die</strong>ser ACE wird nur vererbt. Er steuert nicht den Zugriff auf das<br />
Objekt, für das der ACE ursprünglich definiert wurde.<br />
INHERITED_ACE ID <strong>Die</strong>ser ACE wurde von einem übergeordneten Objekt geerbt.<br />
SUCCESSFUL_ACCESS_ACE_<br />
FLAG<br />
SA <strong>Die</strong>ser ACE gehört zu einer SACL und löst Überwachungsereignisse<br />
für erfolgreiche Zugriffsversuche aus.<br />
FAILED_ACCESS_ACE_FLAG FA <strong>Die</strong>ser ACE gehört zu einer SACL und löst Überwachungsereignisse<br />
für fehlgeschlagene Zugriffsversuche aus.<br />
Wie Sie in Tabelle 3.2 sehen, dienen die ACE-Flags in erster Linie dazu, das Vererbungsverhalten<br />
des ACE zu steuern. Sie werden aber auch dazu benutzt, das Verhalten eines ACE in<br />
einer SACL zu definieren.<br />
Wie bereits erwähnt, werden 8 Bits für den ACE-Typ verwendet. Tabelle 3.3 zeigt die wichtigsten<br />
ACE-Typen.<br />
<strong>Die</strong>se Flags und Typen mögen auf den ersten Blick seltsam wirken. Wenn wir aber weiter<br />
unten in diesem Kapitel zu SDDL kommen, wird klar werden, dass Sie wissen müssen, was<br />
alle diese Typen und Flags bedeuten. Nur dann können Sie Berechtigungen interpretieren<br />
und definieren.
Terminologie der Zugriffssteuerung 63<br />
Der letzte Teil des ACE, mit dem wir uns noch nicht beschäftigt haben, ist die Zugriffsmask.<br />
<strong>Die</strong> Zugriffsmaske definiert die eigentlichen Berechtigungen oder Überwachungseinstellungen<br />
für das Objekt.<br />
Tabelle 3.3 ACE-Typen<br />
Typ SDDL-Verknüpfung<br />
Beschreibung<br />
ACCESS_ALLOWED_ACE_TYPE A <strong>Die</strong> in diesem ACE definierten Berechtigungen legen fest, welchen<br />
Zugriff das in der SID angegebene Subjekt auf das Objekt hat.<br />
<strong>Die</strong>se ACE-Typen werden oft als Zugriff-erlaubt-ACEs (engl.<br />
access allowed ACE) bezeichnet.<br />
ACCESS_DENIED_ACE_TYPE D <strong>Die</strong>ser ACE verweigert den Zugriff auf das Objekt. <strong>Die</strong> im ACE<br />
definierten Berechtigungen werden mit dem Zugriffsversuch verglichen.<br />
Falls der Zugriffsversuch irgendeine der hier festgelegten<br />
Berechtigungen enthält, wird er verweigert. <strong>Die</strong>se ACE-Typen<br />
werden oft als Zugriff-verweigert-ACEs (engl. access denied ACE)<br />
bezeichnet.<br />
SYSTEM_AUDIT_ACE_TYPE AU <strong>Die</strong>ser ACE gehört zu einer SACL.<br />
ACCESS_ALLOWED_OBJECT_<br />
ACE_TYPE<br />
ACCESS_DENIED_OBJECT_<br />
ACE_TYPE<br />
SYSTEM_AUDIT_OBJECT_<br />
ACE_TYPE<br />
SYSTEM_MANDATORY_LABEL_<br />
ACE_TYPE<br />
OA <strong>Die</strong>ser ACE-Typ ähnelt dem Typ A, gilt aber für ein Active Directory-Objekt,<br />
nicht für ein Dateisystemobjekt.<br />
OD <strong>Die</strong>ser ACE-Typ ähnelt dem Typ D, gilt aber für ein Active Directory-Objekt,<br />
nicht für ein Dateisystemobjekt.<br />
OU <strong>Die</strong>s ist ein Überwachungs-ACE in einer SACL für ein Active Directory-Objekt.<br />
<strong>Die</strong>ser ACE wird nicht für Zugriffssteuerung oder Überwachung<br />
genutzt, sondern definiert die Integritätsebene des Objekts, für das<br />
der ACE gilt. Weitere Informationen zu Integritätsebenen finden Sie<br />
im Abschnitt »Integritätsebenen« weiter unten in diesem Kapitel.<br />
Zugriffsmasken<br />
Eine Zugriffsmaske (engl. access mask) ist eine 32-Bit-Struktur. Sie ist in drei Hauptabschnitte<br />
untergliedert (Abbildung 3.4).<br />
Abbildung 3.4 Eine Zugriffsmaske definiert die eigentlichen Berechtigungen in einer 32-Bit-Struktur<br />
Jedes Bit in der Zugriffsmaske kann entweder ein oder aus sein (1 oder 0). Wenn ein Bit auf<br />
1 gesetzt ist, wird die entsprechende Berechtigung gewährt. Wenn das Bit auf 0 gesetzt ist,<br />
wird die Berechtigung nicht gewährt. Falls die Zugriffsmaske zu einem Zugriff-erlaubt-ACE<br />
gehört und die Berechtigung nicht explizit gewährt wird, wird sie implizit verweigert.<br />
<strong>Die</strong> vier obersten Bits in der Zugriffsmaske definieren die sogenannten generischen Berechtigungen<br />
(engl. generic permission). <strong>Die</strong>s sind im Grunde Auflistungen der Berechtigungen,<br />
die Sie in Betriebssystemen mit einfacheren Zugriffssteuerungsmodellen finden. GR (Generic<br />
Read) steht für eine generische Leseberechtigung. In einem Zugriff-erlaubt-ACE gewährt
64 Kapitel 3: Objekte: Was Sie wollen<br />
sie dem Subjekt den Lesezugriff auf das Objekt, und zwar unabhängig vom Objektstyp.<br />
<strong>Die</strong>se Berechtigung kann auch als FR (für FILE_GENERIC_READ, generischer Lesezugriff auf<br />
eine Datei) oder KR (für KEY_GENERIC_READ, generischer Lesezugriff auf einen Schlüssel)<br />
lauten, um generische Berechtigungen zum Lesen von Dateien beziehungsweise Registrierungsschlüsseln<br />
zu gewähren. Entsprechend definiert GW (Generic Write) eine generische<br />
Berechtigung für den Schreibzugriff und GX (Generic eXecute) für das Ausführen. GA ist<br />
eine Kurzform für die Kombination aller drei. Welche Bedeutung diese Einstellungen im<br />
konkreten Fall haben, hängt vom Objekt ab. Falls Sie zum Beispiel die GX-Berechtigung für<br />
ein Verzeichnis setzen, geben Sie dem Subjekt das Recht, das Verzeichnis bis zu einem Unterverzeichnis<br />
oder einer Datei hin zu durchlaufen, auf das dieses Subjekt Zugriff hat.<br />
Das macht einen sehr wichtigen Punkt bezüglich Zugriffsmasken deutlich. Der Kurzname<br />
der Berechtigung, zum Beispiel GR und FR, ist nur insofern wichtig, als er definiert, welches<br />
Bit in der Zugriffsmaske gesetzt ist. Falls eine Zugriffsmaske erstellt und darin FR<br />
gesetzt wird, diese Zugriffsmaske dann aber auf einen Registrierungsschlüssel angewendet<br />
wird, wird die Berechtigung KEY_GENERIC_READ gewährt, weil Bit 31 gesetzt wurde. Das<br />
klingt etwas unlogisch, aber wenn Sie sich die Berechtigungen in der Form von SDDL-<br />
Zeichenfolgen ansehen, stellen Sie sehr oft fest, dass generische Dateiberechtigungen auf<br />
Registrierungsschlüssel angewendet werden, Objektberechtigungen auf Dateien und so weiter.<br />
Sie dürfen nie vergessen, dass alle diese Berechtigungen Bitmasken definieren. <strong>Die</strong> tatsächliche<br />
Bedeutung dieser Bitmaske wird auf Basis des Objekttyps ausgewertet, wenn die<br />
Zugriffsprüfung durchgeführt wird.<br />
<strong>Die</strong> 8 Bits mit den Standardrechten in Abbildung 3.4 werden ähnlich benutzt, allerdings<br />
werden nur die unteren 5 Bits tatsächlich verwendet. <strong>Die</strong> Standardrechte sind:<br />
DELETE: <strong>Die</strong> Fähigkeit, das Objekt zu löschen. <strong>Die</strong>se Berechtigung ist als 0x10000<br />
definiert, in Abbildung 3.4 ist also Bit 16 auf 1 gesetzt.<br />
READ_CONTROL: <strong>Die</strong> Fähigkeit, die <strong>Sicherheit</strong>sbeschreibung des Objekts zu lesen<br />
(ausgenommen die SACL). <strong>Die</strong>se Berechtigung ist als 0x20000 definiert, in Abbildung<br />
3.4 ist also Bit 17 auf 1 gesetzt.<br />
WRITE_DAC: <strong>Die</strong> Fähigkeit, Berechtigungen für dieses Objekt zu ändern (die DACL<br />
zu schreiben). <strong>Die</strong>se Berechtigung ist als 0x40000 definiert, in Abbildung 3.4 ist also Bit<br />
18 auf 1 gesetzt.<br />
WRITE_OWNER: <strong>Die</strong> Fähigkeit, den Besitzer eines Objekts zu ändern. <strong>Die</strong>se Berechtigung<br />
ist als 0x80000 definiert, in Abbildung 3.4 ist also Bit 19 auf 1 gesetzt.<br />
SYNCHRONIZE: Das Recht, das Objekt für die Synchronisierung zu verwenden. Falls<br />
zum Beispiel ein Prozess informiert werden muss, wenn ein Objekt seinen Zustand ändert,<br />
erstellt er ein Synchronisierungshandle für das Objekt. Er wird dann benachrichtigt,<br />
sobald sich der Zustand des Objekts ändert. <strong>Die</strong>se Berechtigung ist als 0x100000 definiert,<br />
in Abbildung 3.4 ist also Bit 20 auf 1 gesetzt.<br />
Es gibt auch Kombinationen der Standardrechte, aber sie sind in erster Linie für Programmierer<br />
interessant. Sie kommen nur damit in Berührung, falls Sie Entwicklerdokumentationen<br />
lesen. Daher ignorieren wir diese Kombinationen vorerst.<br />
Schließlich haben wir 16 Bits für objektspezifische Rechte in der Zugriffsmaske. Mit den<br />
objektspezifischen Rechten können Sie Berechtigungen konfigurieren, die nur für bestimmte<br />
Objekte gültig sind. Tabelle 3.4 erklärt die objektspezifischen Rechte für Dateisystemobjekte.<br />
Nur 8 der Bits werden tatsächlich für Dateisystemobjekte verwendet. Falls Sie sich die ob-
Terminologie der Zugriffssteuerung 65<br />
jektspezifischen Rechte für andere Objekttypen ansehen wollen, können Sie die Entwicklerdokumentation<br />
unter http://msdn.microsoft.com lesen. Suchen Sie dort nach den objektspezifischen<br />
Rechten und dem gewünschten Objekttyp.<br />
Tabelle 3.4 Objektspezifische Rechte für Dateisystemobjekte<br />
Definition Wert Bit Beschreibung<br />
FILE_READ_DATA 0x1 0 Leseberechtigung. Bei einer Datei gewährt das Flag das Recht, die<br />
Datei zu lesen.<br />
FILE_LIST_DIRECTORY 0x1 0 Bei einem Verzeichnis gewährt dieses Flag das Recht, den Inhalt des<br />
Verzeichnisses aufzulisten.<br />
FILE_WRITE_DATA 0x2 1 Dateischreibberechtigung. Bei einer Datei gewährt das Flag das Recht,<br />
in die Datei zu schreiben.<br />
FILE_ADD_FILE 0x2 1 <strong>Die</strong>ses Recht wird für ein Verzeichnis benutzt. Das Flag erlaubt dem<br />
Subjekt, eine Datei im Verzeichnis zu erstellen.<br />
FILE_APPEND_DATA 0x4 2 Bei einer Datei erlaubt das Flag einem Benutzer, Daten an eine Datei<br />
anzuhängen.<br />
FILE_ADD_SUB-<br />
DIRECTORY<br />
0x4 2 Bei einem Verzeichnis erlaubt das Flag dem Subjekt, ein neues Unterverzeichnis<br />
anzulegen.<br />
FILE_READ_EA 0x8 3 Bei einer Datei gewährt das Flag die Berechtigung, die erweiterten<br />
Dateiattribute zu lesen. Erweiterte Dateiattribute werden in <strong>Windows</strong><br />
normalerweise nicht mehr benutzt. Sie wurden ursprünglich eingeführt,<br />
um Kompatibilität zu Anwendungen zu gewährleisten, die für OS/2<br />
geschrieben wurden.<br />
FILE_WRITE_EA 0x10 4 Bei einer Datei gewährt das Flag die Berechtigung, erweiterte Attribute<br />
zu schreiben.<br />
FILE_EXECUTE 0x20 5 Ausführungsberechtigung. Bei einer ausführbaren Binärdatei gewährt<br />
das Flag das Recht, die Datei auszuführen.<br />
FILE_TRAVERSE 0x20 5 Berechtigung zum Durchlaufen von Verzeichnissen. <strong>Die</strong>se Berechtigung<br />
erlaubt es dem Subjekt, ein Verzeichnis zu durchlaufen, auf das<br />
dieses Subjekt keinen Zugriff hat. So kann das Subjekt zu einem Unterverzeichnis<br />
gelangen, auf das es Zugriff besitzt. Allerdings haben alle<br />
Subjekte in <strong>Windows</strong> das Privileg Auslassen der durchsuchenden Überprüfung<br />
(SeChangeNotify), das ihnen dieses Recht ganz unabhängig<br />
von dieser Berechtigung gewährt.<br />
FILE_DELETE_CHILD 0x40 6 Bei einem Verzeichnis erlaubt das Flag dem Subjekt, das Verzeichnis<br />
mit seinem gesamten Inhalt zu löschen.<br />
FILE_READ_ATTRIBUTES 0x80 7 Bei einer Datei gewährt das Flag das Recht, die normalen Dateiattribute<br />
zu lesen.<br />
FILE_WRITE_ATTRIBUTES 0x100 8 Bei einer Datei gewährt das Flag das Recht, Dateiattribute zu schreiben.<br />
Jetzt fragen Sie sich wahrscheinlich, ob Sie alle diese Details wirklich müssen wissen, um<br />
<strong>Windows</strong> zu administrieren. Klare Antwort: Nein, das müssen Sie nicht. Viele Administratoren<br />
kennen diese Details nicht und schaffen es dennoch, ihren Benutzern die benötigten<br />
<strong>Die</strong>nste problemlos zur Verfügung zu stellen. Falls Sie allerdings Berechtigungen verwalten<br />
wollen, sollten Sie wirklich wissen, wie alle diese Strukturen miteinander verbunden sind.
66 Kapitel 3: Objekte: Was Sie wollen<br />
Abbildung 3.5 Um beliebige Berechtigungen zu analysieren, müssen Sie den hexadezimalen Wert auf<br />
die Zugriffsmaske abbilden
Terminologie der Zugriffssteuerung 67<br />
Und falls Sie Berechtigungen in <strong>Server</strong> Core-Installationen verwalten oder die für Verzeichnisse<br />
eingestellten Berechtigungen verstehen wollen, müssen Sie sich fast zwangsläufig mit<br />
diesen Details beschäftigen. Dasselbe gilt, falls Sie die Berechtigungsverwaltung für irgendein<br />
Objekt an einen Benutzer delegieren wollen, der kein vollgültiger Administrator sein<br />
soll.<br />
<strong>Die</strong> Definitionen in den Tabellen sind in einem bestimmten Format aufgelistet. <strong>Die</strong>ses Format<br />
wird von Entwicklern verwendet, es ist im Software Development Kit (SDK) definiert.<br />
Statt neue Definitionen zu erfinden, ist es sinnvoll, diese vorhandenen Bezeichnungen zu<br />
verwenden, wenn im Rest dieses Kapitels und des Buchs auf Berechtigungen verwiesen<br />
wird.<br />
Sie können die Berechtigungen natürlich auch in der grafischen Benutzeroberfläche des<br />
ACL-Editors (kurz ACL-UI für Access Control List User Interface) betrachten. Dort finden<br />
Sie intuitiv aufbereitete Darstellungen dieser Daten. Das ist aber eine sehr ineffiziente Methode,<br />
und sie hilft Ihnen nicht, wenn Sie zum Beispiel <strong>Sicherheit</strong>svorlagen oder bei einer<br />
Problembehandlung die im SDDL-Format aufgelisteten Berechtigungen interpretieren müssen.<br />
In diesen Fällen müssen Sie wissen, wie diese Berechtigungen aufgebaut sind. Zum<br />
Beispiel könnten Sie auf die Berechtigung 0x1200a9 stoßen. Wie Sie sich inzwischen wohl<br />
denken können, steht dieser Wert für eine Kombination aus den Bits in den vorherigen<br />
Tabellen. 0x1200a9 ist binär 100100000000010101001. Wenn wir dieses Muster in Abbildung<br />
3.4 eintragen, erhalten wir so etwas wie Abbildung 3.5.<br />
Abbildung 3.5 demonstriert, wie wir gewährte Berechtigungen wie zum Beispiel 0x1200a9<br />
analysieren müssen. Der Wert verrät, welche Bits in der Zugriffsmaske gesetzt sind. Um<br />
herauszufinden, was das bedeutet, müssen wir den hexadezimalen Wert (Basis 16) in einen<br />
Binärwert konvertieren. Dafür können Sie den <strong>Windows</strong>-Rechner verwenden, wenn sie ihn<br />
in den wissenschaftlichen Modus schalten. Den Binärwert bilden wir auf die Zugriffsmaske<br />
ab, wie in Abbildung 3.5 gezeigt. <strong>Die</strong> gesetzten Bits geben an, welche Berechtigungen gewährt<br />
wurden.<br />
Abbildung 3.6 0x1200a9 ist einer der ACEs für das Stammverzeichnis eines Laufwerks
68 Kapitel 3: Objekte: Was Sie wollen<br />
Damit Sie jetzt nicht denken, dass dies ein künstlich konstruiertes Beispiel einer DACL ist,<br />
die es in der Praxis gar nicht gibt, präsentiere ich in Abbildung 3.6 die ACL-UI-Darstellung<br />
mit genau diesem ACE.<br />
Wie Sie in Abbildung 3.6 sehen, kommt die Berechtigung 0x1200a9 in der Praxis gar nicht<br />
so selten vor. Sie erlaubt Standardbenutzern, auf einem gesamten Volume Dateien zu lesen<br />
und Verzeichnisse aufzulisten. Vielleicht ist Ihnen aufgefallen, dass die ACL-UI in Abbildung<br />
3.6 nicht ganz richtig ist, es fehlt die Synchronisierungsberechtigung. <strong>Die</strong>se Berechtigung<br />
können Sie in der GUI überhaupt nicht festlegen.<br />
Abbildung 3.7 <strong>Die</strong> verschiedenen Zugriffssteuerungsstrukturen haben genau festgelegte Beziehungen
Terminologie der Zugriffssteuerung 69<br />
Beziehung zwischen Zugriffssteuerungsstrukturen<br />
Bevor wir das Thema Zugriffssteuerungsstrukturen verlassen und zur weiteren Terminologie<br />
im Bereich der Objektsicherheit übergehen, ist es sinnvoll, uns noch einmal im Überblick<br />
anzusehen, welche Beziehungen zwischen den Strukturen bestehen. Abbildung 3.7 zeigt<br />
diese Beziehungen.<br />
Eine <strong>Sicherheit</strong>sbeschreibung enthält zwei Zeiger auf SIDs, die Besitzer- und Gruppen-<br />
SIDs. Außerdem enthält sie Zeiger auf zwei ACLs. In der Praxis ist es nicht ungewöhnlich,<br />
wenn einer oder mehrere dieser Zeiger Nullzeiger sind (nur aus Nullen besteht). In diesem<br />
Fall fehlen dem Objekt die entsprechenden Strukturen. Das sehen wir uns weiter unten genauer<br />
an. Am häufigsten hat die SACL einen Nullzeiger, weil viele Objekte keine SACL<br />
haben. Falls einer der anderen Zeiger ein Nullzeiger ist, können interessante Bugs auftreten.<br />
Zum Beispiel können sogar integrierte Tools spektakulär fehlschlagen, falls der DACL-<br />
Zeiger ein Nullzeiger ist.<br />
Beachten Sie in Abbildung 3.7 außerdem, dass zwar nur ein ACE in jeder ACL aufgeführt<br />
ist, aber zusätzliche ACEs hinzugefügt werden können. In diesem Fall wird die ACL länger.<br />
Vererbung<br />
ACLs können von übergeordneten Objekten an untergeordnete Objekte vererbt werden.<br />
Zum Beispiel kann ein Verzeichnis eine ACL enthalten, die auf das Verzeichnis angewendet<br />
wird, aber zusätzlich auf Dateien und Unterverzeichnisse. Heutzutage sollten wir allerdings<br />
genauer sagen: <strong>Die</strong> ACEs werden vererbt, nicht die ACL.<br />
Vor <strong>Windows</strong> 2000 wurde tatsächlich die ACL vererbt. <strong>Die</strong> Steuerungsflags der <strong>Sicherheit</strong>sbeschreibung,<br />
zum Beispiel SE_DACL_AUTO_INHERIT_REQ (in einer SDDL-Zeichenfolge oft als<br />
AR aufgeführt), sind ein Überbleibsel aus dieser Zeit. Seit <strong>Windows</strong> 2000 werden die *AUTO_<br />
INHERIT_REQ-Flags aber de facto ignoriert. Genauso wird das AI-Flag (SE_DACL_AUTO_INHERI-<br />
TED) praktisch ignoriert. Stattdessen werden jetzt die Vererbungsflags in den einzelnen ACEs<br />
verwendet, was die Flexibilität bei der Vererbung gewaltig steigert, die Sache für den Systemadministrator<br />
aber auch deutlich komplizierter macht.<br />
<strong>Die</strong> Vererbungsflags wurden weiter oben in Tabelle 3.2 aufgelistet. <strong>Die</strong>s sind die Flags, die<br />
Sie kennen müssen, um eine SDDL-Zeichenfolge auszuwerten oder um Software zu schreiben,<br />
die das für Sie erledigt. Falls Sie ausschließlich in der GUI arbeiten, sehen Sie die Vererbungsflags<br />
wie in Abbildung 3.8.<br />
In Abbildung 3.8 sehen Sie ein Verzeichnis, das sowohl geerbte als auch nichtgeerbte ACEs<br />
hat. <strong>Die</strong> Spalte Geerbt von zeigt an, woher sie stammen. <strong>Die</strong> Spalte Übernehmen für gibt an,<br />
wie sie weitervererbt werden. Der erste ACE (für System) gilt offensichtlich nur für Ordner.<br />
Es gibt einen Vollzugriff-ACE für System, der auch weitervererbt wird. <strong>Die</strong>se Redundanz<br />
kommt in ACLs recht häufig vor.<br />
Außerdem sehen Sie zwei Kontrollkästchen unten in Abbildung 3.8. Sie sind praktisch dynamische<br />
Darstellungen der ACL-Flags aus Tabelle 3.1. Vererbbare Berechtigungen des übergeordneten<br />
Objektes einschließen bewirkt, dass alle vererbbaren Berechtigungen an dieses<br />
Objekt weitergegeben werden. Falls dieses Kontrollkästchen deaktiviert ist, entspricht das<br />
einem gesetzten P-Flag in der <strong>Sicherheit</strong>sbeschreibung. Das zweite Kontrollkästchen, Bestehende<br />
vererbbare Berechtigungen aller untergeordneten Objekte durch vererbbare Berechtigungen<br />
dieses Objektes ersetzen, steht nicht für irgendein Flag. Es bewirkt, dass Berechtigungen<br />
erneut vererbt werden. Manche Tools interpretieren das AI-Flag aus Tabelle 3.1 in
70 Kapitel 3: Objekte: Was Sie wollen<br />
derselben Weise, insbesondere der <strong>Sicherheit</strong>skonfigurations-Editor (Security Configuration<br />
Editor, SCE). Falls Sie daher in Gruppenrichtlinien die Vererbung für ein Objekt oder einen<br />
Container auslösen wollen, können Sie in einer <strong>Sicherheit</strong>svorlage das AI-Flag verwenden,<br />
wobei Sie keine anderen ACEs angeben.<br />
Abbildung 3.8 <strong>Die</strong> ACL-UI macht die Vererbungsflags mithilfe mehrerer Mechanismen sichtbar<br />
Abbildung 3.9 zeigt eine andere Möglichkeit, wie die ACL-UI das Vererbungsverhalten<br />
darstellt.<br />
Abbildung 3.9 Wenn Sie einen ACE erstellen oder ändern,<br />
können Sie sein Vererbungsverhalten auswählen
Terminologie der Zugriffssteuerung 71<br />
Das Vererbungsverhalten des ACE wird beim Erstellen festgelegt. <strong>Die</strong> Dropdownliste Übernehmen<br />
für in Abbildung 3.9 stellt Kombinationen der bekannten Vererbungsflags bereit.<br />
Tabelle 3.5 führt die angebotenen Kombinationen auf.<br />
Tabelle 3.5 Vererbungsmöglichkeiten in der ACL-UI und die zugehörigen Flagkombinationen<br />
ACL-UI-Begriff Flags<br />
Nur diesen Ordner <br />
<strong>Die</strong>sen Ordner, Unterordner und Dateien OI CI (Objekt erben, Container erben)<br />
<strong>Die</strong>sen Ordner, Unterordner CI<br />
<strong>Die</strong>sen Ordner, Dateien OI<br />
Nur Unterordner und Dateien OI CI IO (nur erben)<br />
Nur Unterordner CI IO<br />
Nur Dateien OI IO<br />
Berechtigungen nur für Objekte und/oder Container<br />
in diesem Container übernehmen<br />
NP (keine Vererbungsweitergabe für ACE)<br />
Es dauert etwas, um sich in die Vererbung einzuarbeiten, aber wenn Sie erst einmal die<br />
Grundkonzepte verstanden haben, wird das Thema beherrschbar. <strong>Die</strong> größte Schwierigkeit<br />
besteht darin zu wissen, wie die Folgen für große Hierarchien aussehen. Sie müssen die<br />
folgenden Kernkonzepte kennen:<br />
Containervererbung bewirkt, dass ACEs von Containern geerbt werden. <strong>Die</strong> Objektvererbung<br />
bewirkt dagegen, dass ACEs von Objekten geerbt werden. Außerdem müssen Sie<br />
wissen, wie für einen bestimmten Objekttyp die Definition von Container und Objekt<br />
aussieht.<br />
Eine geschützte ACL überschreibt die gesamte Vererbung von ihren übergeordneten<br />
Objekten.<br />
Ein ACE, der nur vererbt wird, steuert nicht den Zugriff auf den Container, in dem er<br />
definiert wurde.<br />
Ein ACE, der nicht vererbt wird, gilt nur für den Container, in dem der definiert ist.<br />
Damit Sie das Thema Vererbung wirklich beherrschen, müssen Sie allerdings auch wissen,<br />
wie die eigentlichen ACEs bei einer Zugriffsprüfung ausgewertet werden. Daher beschäftigen<br />
wir uns als Nächstes mit diesem Thema. Zuerst müssen wir dafür das Konzept eines<br />
<strong>Sicherheit</strong>stokens verstehen.<br />
<strong>Sicherheit</strong>stoken<br />
Wenn sich ein Benutzer an einem <strong>Windows</strong>-Computer anmeldet, erstellt das Betriebssystem<br />
ein Token für diesen Benutzer. Das Token gibt an, wer der Benutzer (das Subjekt) ist, bei<br />
welchen Gruppen er Mitglied ist und welche Privilegien er hat. In manchen Fällen erstellt<br />
das Betriebssystem sogar zwei Token für das Subjekt, wenn die Benutzerkontensteuerung<br />
(User Account Control, UAC) aktiv ist. Mehr dazu finden Sie in Kapitel 4, »Grundlagen der<br />
Benutzerkontensteuerung«.<br />
Sie können sich die Token im Microsoft-Tool Process Explorer ansehen, das Sie unter<br />
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx<br />
herunterladen können (dieses Tool steht nur in englischer Sprache zur Verfügung). Abbil-
72 Kapitel 3: Objekte: Was Sie wollen<br />
dung 3.10 zeigt das gefilterte Standardbenutzertoken für einen Administrator, der unter der<br />
UAC arbeitet. Abbildung 3.11 zeigt das vollständige administrative Token für denselben<br />
Benutzer.<br />
Abbildung 3.10 Bei einem gefilterten Token wurden fast alle Privilegien<br />
entfernt, und für die Gruppe Administratoren ist Deny eingetragen<br />
Abbildungen 3.10 und 3.11 demonstrieren mehrere wichtige Punkte. Erstens: Im gefilterten<br />
Token ist für die Administratoren-SID Deny (Verweigern) eingetragen. Das bedeutet, dass<br />
sie nur verwendet werden kann, um den Zugriff auf etwas zu verweigern. Anders ausgedrückt:<br />
Falls eine ACL einen Zulassen-ACE für Administratoren enthält, gibt es keine Übereinstimmung<br />
mit dem gefilterten Token. Nur wenn der ACE ein Verweigern-ACE ist, ergibt<br />
sich eine Übereinstimmung.<br />
Zweitens: Viele Privilegien in beiden Token sind deaktiviert. Das bedeutet nicht, dass der<br />
Benutzer diese Privilegien nicht einsetzen kann. Es bedeutet lediglich, dass ein Prozess, der<br />
diese Privilegien braucht, sie erst aktivieren muss. Dazu reicht oft ein einfacher Funktionsaufruf<br />
aus. Wenn die Privilegien deaktiviert werden, schützt das den Benutzer nur vor einer<br />
unbeabsichtigten Nutzung der Privilegien. Es bedeutet keinen <strong>Sicherheit</strong>svorteil.<br />
Drittens: Sehen Sie sich die beeindruckende Zahl von SIDs im Token an. Auch wenn Sie nur<br />
zwei Gruppen sehen, während Sie die Gruppenmitgliedschaft des Benutzers untersuchen (in<br />
diesem Fall Benutzer und Administratoren), geben eine Menge weiterer SIDs unter anderem<br />
an, wie der Benutzer sich angemeldet hat. Alle Subjekte außer anonymen Benutzern haben<br />
standardmäßig die Jeder-SID in ihrem Token. Alle Subjekte, die sich authentifiziert haben<br />
(also keine anonymen Benutzer oder Gäste), haben auch das Authentifizierte Benutzer-SID<br />
in ihrem Token. Weil das Konto Gast in der Standardeinstellung deaktiviert ist, sind Jeder
Terminologie der Zugriffssteuerung 73<br />
und Authentifizierte Benutzer daher funktional identisch. Das ist seit <strong>Windows</strong> <strong>Server</strong> 2003<br />
und <strong>Windows</strong> XP so.<br />
Abbildung 3.11 Im vollständigen administrativen Token wird<br />
der gesamte Privilegiensatz des Benutzers aufgeführt<br />
<strong>Die</strong> Token in den Abbildungen 3.10 und 3.11 zeigen auch mehrere SIDs, die den Anmeldungstyp<br />
angeben. Erstens ist dies die LOKAL-SID, das bedeutet, dass sich der Benutzer an<br />
einem Terminal angemeldet hat, das direkt an den Computer angeschlossen ist. Außerdem<br />
sehen Sie den Eintrag Logon SID, eine ID für die Anmeldungssitzung, die diesem Benutzer<br />
zugewiesen ist. <strong>Die</strong> meisten Fenster in einer Benutzersitzung werden anhand der Logon-SID<br />
geschützt. Weiterhin gibt es die INTERAKTIV-SID, die verrät, dass dieser Benutzer sich<br />
interaktiv am Computer angemeldet hat, also nicht über das Netzwerk. Der Unterschied<br />
zwischen dieser SID und der LOKAL-SID besteht darin, dass Terminalserverbenutzer die<br />
INTERAKTIV-SID haben, aber nicht die LOKAL-SID. Eine weitere SID, NTLM-Authentifizierung,<br />
definiert, dass der Benutzer sich über NTLM angemeldet hat, nicht über Kerberos.<br />
<strong>Die</strong> SID <strong>Die</strong>se Organisation bedeutet, dass der Benutzer in derselben Organisation wie das<br />
Computerkonto definiert ist. Offensichtlich ist diese SID auf einem eigenständigen Computer<br />
immer vorhanden. Schließlich sehen Sie noch die SID None. Das ist eigentlich keine<br />
SID, die tatsächlich verwendet wird. Ihre RID ist 513, was für Domänen-Benutzer steht. Sie<br />
dient auf Computern, die (wie in diesem Beispiel) keine Domänenmitglieder sind, als eine<br />
Art Platzhalter für die Domänen-Benutzer-SID.
74 Kapitel 3: Objekte: Was Sie wollen<br />
Ablauf der Zugriffsprüfung<br />
Wenn ein Prozess versucht, auf ein geschütztes Objekt zuzugreifen, vergleicht das Betriebssystem<br />
das Zugriffstoken erst mit der DACL und dann (sofern vorhanden) mit der SACL des<br />
Objekts. Der Vergleich mit der DACL konzentriert sich auf drei Faktoren:<br />
Der geforderte Zugriff (zum Beispiel Lesen, Schreiben, Ausführen, Löschen)<br />
<strong>Die</strong> SIDs im Token<br />
<strong>Die</strong> ACEs in der DACL des Objekts<br />
Der Vergleichsprozess beginnt damit, dass alle SIDs im Token ausgewertet werden, die auf<br />
Verweigern gesetzt sind. Falls irgendeine dieser SIDs einer SID in einem Verweigern-ACE<br />
entspricht, vergleicht das Betriebssystem den angeforderten Zugriff mit der Zugriffsmaske<br />
im ACE. Falls irgendwelche Bits in beiden auf 1 gesetzt sind, wird der Zugriffsversuch an<br />
diesem Punkt verweigert. Weitere Vergleiche werden nicht mehr durchgeführt.<br />
Falls keine Übereinstimmungen mit Verweigern-SIDs gefunden werden, wertet der Prozess<br />
als Nächstes jeden einzelnen ACE aus. Es gibt drei mögliche Bedingungen, die bewirken,<br />
dass die Auswertung abgebrochen wird. Erstens wird die Auswertung sofort beendet, falls<br />
irgendein ACE oder eine Kombination von ACEs irgendeiner Kombination der SIDs im<br />
Token den geforderten Zugriff vollständig gewährt. Falls das passiert, wird der Zugriff erlaubt.<br />
Zweitens: Falls irgendein Verweigern-ACE gefunden wird, der irgendeiner SID im Token<br />
irgendeines der geforderten Zugriffsrechte verweigert, wird die Auswertung abgebrochen<br />
und der Zugriffsversuch wird verweigert.<br />
Drittens und letztens: Falls das Ende der ACL erreicht ist, wird die Auswertung abgebrochen.<br />
Falls an diesem Punkt nicht alle geforderten Zugriffsrechte von irgendeinem ACE<br />
gewährt wurden, wird der Zugriffsversuch verweigert.<br />
Unabhängig davon, wie die Zugriffsprüfung ausgeht, wertet das Betriebssystem als Nächstes<br />
die SACL aus (sofern vorhanden) und prüft, ob ein Überwachungsereignis generiert werden<br />
soll.<br />
Wie Sie sich nach der bisherigen Beschreibung der Zugriffsprüfung bestimmt schon denken<br />
können, ist wichtig, in welcher Reihenfolge die ACEs ausgewertet werden. Nehmen wir an,<br />
Sie haben ein Verweigern-ACE, das dem Benutzer Zugriff auf das Objekt verbietet, sowie<br />
einen ACE, das einer der SIDs im Token des Benutzers entspricht und alle geforderten Zugriffsrechte<br />
gewährt. Wenn dieser Zulassen-ACE zuerst abgearbeitet wird, wird die Auswertung<br />
abgebrochen und der Zugriffsversuch wird gewährt. Aus diesem Grund müssen ACEs<br />
in einer ACL in einer bestimmten Reihenfolge gespeichert sein:<br />
1. Nichtgeerbte Verweigern-ACEs<br />
2. Nichtgeerbte Zulassen-ACEs<br />
3. Geerbte Verweigern-ACEs<br />
4. Geerbte Zulassen-ACEs<br />
Verschiedene Tools, zum Beispiel die ACL-UI, speichern die ACEs in dieser Reihenfolge.<br />
Sie korrigieren auch eine ACL, deren Reihenfolge nicht stimmt, sobald sie geöffnet wird.<br />
Außerdem stellt das Befehlszeilentool icacls.exe das Argument /verify zur Verfügung, mit<br />
dem Sie prüfen können, ob ACLs die richtige Reihenfolge haben. Das Betriebssystem erzwingt<br />
diese Reihenfolge aber nicht automatisch, und es kommt erschreckend oft vor, dass
Terminologie der Zugriffssteuerung 75<br />
Entwickler ACLs erstellen, deren ACEs in der falschen Reihenfolge vorliegen. Das kann<br />
dazu führen, dass Zugriffsversuche, die eigentlich verweigert werden müssten, gewährt<br />
werden.<br />
Und falls explizit definierte Zulassen-ACEs einem Benutzer Zugriff gewähren, haben diese<br />
ACEs Vorrang gegenüber geerbten Verweigern-ACEs. Das hat in der Vergangenheit ebenfalls<br />
immer wieder für Verwirrung bei Administratoren gesorgt.<br />
Eingeschränkte Token<br />
<strong>Die</strong> Standardzugriffsprüfung kann auf mehrere Arten verändert werden. Ein solcher Fall<br />
liegt zum Beispiel vor, wenn der Benutzer ein Privileg besitzt, das ein Überschreiben der<br />
Zugriffsprüfung erlaubt. Zum Beispiel kann ein Benutzer, der das Recht zum Sichern von<br />
Dateien besitzt, jegliche ACL umgehen, um die Daten zu lesen. Und ein Benutzer mit dem<br />
Recht, Dateien wiederherzustellen, kann alle ACLs umgehen, um die Daten zu schreiben.<br />
Eine andere Methode, die in <strong>Windows</strong> Vista und <strong>Server</strong> <strong>2008</strong> deutlich häufiger genutzt wird<br />
als in der Vergangenheit, ist der Einsatz von eingeschränkten Token.<br />
Ein eingeschränktes Token (engl. restricted token) wird mit der API-Funktion (Application<br />
Programming Interface) CreateRestrictedToken erstellt. Falls ein Prozess ein Zugriffstoken<br />
vorweist, das eingeschränkt ist, führt das Betriebssystem zwei getrennte Zugriffsprüfungen<br />
durch. <strong>Die</strong> erste Zugriffsprüfung ist die normale. Sie stellt sicher, dass die ACL des Objekts<br />
einer Kombination der SIDs im Token alle angeforderten Zugriffsmethoden gewährt. <strong>Die</strong><br />
zweite Zugriffsprüfung funktioniert genauso, überprüft die ACL aber ausschließlich auf die<br />
einschränkenden SIDs. An einem Beispiel lässt sich das besser verstehen: Nehmen wir an,<br />
ein Zugriffstoken hat Administratoren als normale SID und Benutzer als eingeschränkte<br />
SID. Nehmen wir außerdem an, dass es ein Objekt gibt, das Administratoren Vollzugriff und<br />
Benutzer Lesezugriff gewährt. Falls ein Prozess mit einem solchen Token versucht, das Objekt<br />
zum Lesen und Ausführen zu öffnen, schlägt der Zugriffsversuch fehl, weil die Zugriffsprüfung<br />
anhand der einschränkenden SID durchgeführt wird, und das ist die Benutzer-SID.<br />
In diesem Fall hat Benutzer nur die Berechtigung Lesen, und der Zugriffsversuch hat Lesen,<br />
Ausführen angefordert.<br />
Eingeschränkte Token umfassen eine spezielle SID: S-1-5-12, falls es ein normales eingeschränktes<br />
Token ist, und S-1-5-33, falls es ein schreibeingeschränktes Token ist (zu sehen<br />
in Abbildung 3.12). Normal eingeschränkte Token gibt es schon lange. In <strong>Windows</strong> Vista<br />
und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wurde eine neue Variante eingeführt, das schreibeingeschränkte<br />
Token (engl. write-restricted token). Bei einem schreibeingeschränkten Zugriffstoken wird<br />
die zweite Zugriffsprüfung nur für Schreibzugriff durchgeführt. Nehmen wir an, das Token<br />
in unserem letzten Beispiel war schreibeingeschränkt, nicht nur eingeschränkt. In diesem<br />
Fall wird der Zugriff trotzdem gewährt, weil die zweite Zugriffsprüfung nicht durchgeführt<br />
wird (der Zugriffsversuch betraf keine Schreiboperation). Nehmen wir nun an, der Zugriffsversuch<br />
wurde stattdessen für Lesen und Schreiben durchgeführt. In diesem Fall führt ein<br />
schreibeingeschränktes Zugriffstoken dazu, dass der Zugriffsversuch fehlschlägt, weil diesmal<br />
die zweite Zugriffsprüfung fehlschlägt, denn Benutzer ist schreibeingeschränkt und hat<br />
nur die Berechtigung Lesen für das Objekt.
76 Kapitel 3: Objekte: Was Sie wollen<br />
Abbildung 3.12 Ein Prozess mit einem eingeschränkten Token<br />
unterliegt einer geänderten Zugriffsprüfung<br />
Schreibeingeschränkte Token werden in erster Linie für <strong>Die</strong>nste verwendet, aber auch wenn<br />
Sie in älteren <strong>Windows</strong>-Versionen das Kontrollkästchen Computer und Daten vor nicht autorisierter<br />
Programmaktivität schützen beim Verwenden des Befehls Ausführen als aktivieren.<br />
In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> haben aber einige <strong>Die</strong>nste, zum Beispiel<br />
der Prozess Svchost.exe, der die verschiedenen Firewalldienste und das Basisfilterungsmodul<br />
hostet, schreibeingeschränkte Token. Ein solches Token umfasst die schreibeingeschränkte<br />
SID, S-1-5-33 (NT-AUTORITÄT\SCHREIBEN EINGESCHRÄNKT). <strong>Die</strong> eigentlichen<br />
einschränkenden SIDs sind die <strong>Die</strong>nst-SIDs (bei einem Svchost.exe-Prozess mehrere,<br />
deren <strong>Die</strong>nst-SIDs alle schreibeingeschränkt sind), die Logon-SID und die Jeder-SID. Anders<br />
ausgedrückt: Ein schreibeingeschränkter <strong>Die</strong>nst kann nur in Objekte schreiben, in die<br />
Jeder schreiben kann oder für die diesem <strong>Die</strong>nst explizit eine Schreibberechtigung gewährt<br />
wurde.<br />
Integritätsebenen<br />
In den Abbildungen 3.10, 3.11 und 3.12 ist Ihnen wahrscheinlich die Integritätsebene (engl.<br />
integrity label) aufgefallen. Jeder Prozess hat jetzt eine Beschriftung, die seine Integritätsebene<br />
definiert. Integritätsebenen sind normalerweise eine Komponente der verbindlichen<br />
Zugriffssteuerung (engl. mandatory access control). Sie definieren aber die Integrität,<br />
die mit dem Prozess verknüpft ist. Ein Prozess auf einer bestimmten Integritätsebene kann in<br />
Objekte schreiben, die auf seiner oder einer niedrigeren Integritätsebene liegen, und er kann<br />
Objekte lesen, die auf seiner eigenen oder einer höheren Integritätsebene liegen.
Terminologie der Zugriffssteuerung 77<br />
Tabelle 3.6 zeigt die Integritätsebenen, die in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> (und <strong>Windows</strong> Vista)<br />
zur Verfügung stehen. <strong>Die</strong> meisten Objekte im Betriebssystem haben in der Standardeinstellung<br />
eine mittlere Integrität. Ein Standardbenutzertoken hat ebenfalls eine mittlere Integrität.<br />
Daher unterscheidet sich die Funktionalität in weiten Bereichen nicht von den vorherigen<br />
<strong>Windows</strong>-Versionen. Der Internet Explorer im geschützten Modus läuft aber mit einer niedrigeren<br />
Integritätsebene. Das bedeutet, dass der Internet Explorer standardmäßig nicht in der<br />
Lage ist, in die meisten Teile des Betriebssystems zu schreiben. Beachten Sie, dass dieser<br />
<strong>Sicherheit</strong>svorteil verloren geht, wenn die UAC deaktiviert ist!<br />
Tabelle 3.6 Integritätsebenen in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Integritätsebenen-SID<br />
Name<br />
S-1-16-0 Nicht vertrauenswürdiger Prozess. Wird in manchen Konfigurationen für anonyme Prozesse verwendet.<br />
S-1-16-4096 Verbindliche Beschriftung\Niedrige Verbindlichkeitsstufe. <strong>Die</strong>se Ebene wird standardmäßig für den<br />
Internet Explorer im geschützten Modus verwendet.<br />
S-1-16-8192 Verbindliche Beschriftung\Mittlere Verbindlichkeitsstufe. <strong>Die</strong>s ist die Standardeinstellung für Standardbenutzer<br />
und das eingeschränkte Token für Administratoren im Administratorbestätigungsmodus.<br />
S-1-16-12288 Verbindliche Beschriftung\Hohe Verbindlichkeitsstufe. Wird für das vollständige Token von Administratoren<br />
im Administratorbestätigungsmodus verwendet.<br />
S-1-16-16384 Verbindliche Beschriftung\Systemverbindlichkeitsstufe. Wird für Systemprozesse und -dienste verwendet.<br />
S-1-16-20480 Geschützter Prozess. Wird für bestimmte geschützte Prozesse verwendete, zum Beispiel Digital<br />
Rights Management-Prozesse.<br />
<strong>Die</strong> Integritätsebenen sind als ACE für die in Tabelle 3.6 aufgeführte SID in der SACL des<br />
Objekts gespeichert. Wenn ein Benutzer die Beschriftungen ändern will, muss er daher die<br />
Berechtigung haben, die SACL zu ändern. Dazu sind Besitzer und Administratoren in der<br />
Lage.<br />
Leere und Null-DACLs<br />
Wie bereits erwähnt, kann es sein, dass ein Prozess keine DACL hat. <strong>Die</strong>s wird als Null-<br />
DACL (engl. NULL DACL) bezeichnet. Eine Null-DACL ist ein sehr wichtiges Konstrukt,<br />
weil es bedeutet, dass für das Objekt keine Zugriffssteuerung definiert ist. <strong>Die</strong>s ist daher so,<br />
als würde jedem Subjekt Vollzugriff auf das Objekt gewährt.<br />
Normalerweise sind Null-DACLs das Ergebnis eines Programmierfehlers. Zum Beispiel war<br />
das Updateprogramm für einige Microsoft-Spiele defekt und erstellte Dateien mit einem<br />
Null-DACL. Null-DACLs waren auch zu der Zeit, als <strong>Windows</strong> NT 4.0 im Einsatz war, bei<br />
Systemobjekten recht verbreitet. Das war, bevor das Verhalten für diese Objekte so geändert<br />
wurde, dass direkt beim Erstellen eine Standard-DACL hinzugefügt wurde.<br />
Eine leere DACL (engl. empty DACL) ist etwas anderes als eine Null-DACL. Bei einer<br />
Null-DACL ist keine Zugriffssteuerung für das Objekt definiert. Bei der leeren DACL ist<br />
schon eine Zugriffssteuerung definiert, aber niemandem wurde Zugriff auf das Objekt gewährt.<br />
Das ist also so, als ob niemand auf irgendeine Weise auf das Objekt zugreifen dürfte.
78 Kapitel 3: Objekte: Was Sie wollen<br />
Glücklicherweise kann der Besitzer des Objekts die Berechtigungen normalerweise überschreiben<br />
und ändern.<br />
Security Descriptor Definition Language<br />
Weiter oben in diesem Kapitel habe ich zum ersten Mal die SDDL (Security Descriptor Definition<br />
Language) erwähnt, die <strong>Sicherheit</strong>sbeschreibungsdefinitionssprache. SDDL wurde ursprünglich<br />
entwickelt, damit Entwickler Berechtigungen im Textformat definieren können.<br />
Im Lauf der Zeit wurde sie in vielen Tools eingesetzt, vor allem in Befehlszeilentools und<br />
dem <strong>Sicherheit</strong>skonfigurations-Editor, mit dem in Gruppenrichtlinien Berechtigungen festgelegt<br />
werden. Daher sollte man voraussetzen dürfen, dass ein <strong>Windows</strong>-Systemadministrator<br />
mit der Sprache vertraut ist.<br />
SDDL hält sich eng an das Format einer <strong>Sicherheit</strong>sbeschreibung. Sie hat folgendes Format:<br />
Besitzer-SID<br />
Gruppen-SID<br />
DACL-Flags und alle DACL-ACEs im Zeichenfolgenformat<br />
SACL-Flags und alle SACL-ACEs im Zeichenfolgenformat<br />
Oft sehen Sie auch eine Kurzfassung, bei der Besitzer- und Gruppen-SIDs fehlen. Das ist<br />
der Fall bei den SDDL-Zeichenfolgen, die von den Befehlszeilentools Cacls und Icacls erstellt<br />
werden. Wenn Sie sich die gesamte SDDL-Zeichenfolge ansehen wollen, brauchen Sie<br />
ein Tool wie zum Beispiel Subinacl, das Sie von http://download.microsoft.com herunterladen<br />
können. Abbildung 3.13 zeigt die SDDL-Zeichenfolge, die die Berechtigungen für das<br />
Stammverzeichnis des Laufwerks C: definiert.<br />
Abbildung 3.13 Das Tool Subinacl zeigt die vollständige SDDL-Zeichenfolge eines Objekts an<br />
Abbildung 3.13 zeigt, dass der Besitzer eine SID ist: S-1-5-80-956008885-3418522649-<br />
1831038044-1853292631-2271478464. <strong>Die</strong>s ist die SID für den <strong>Die</strong>nst TrustedInstaller, den<br />
<strong>Windows</strong>-Modulinstaller. Er besitzt alle Betriebssystemobjekte im Dateisystem. Trusted-<br />
Installer ist auch als primäre Gruppe für diese Objekte konfiguriert.<br />
Möglicherweise erkennen Sie auch die SDDL-Zeichenfolge in Abbildung 3.13, in der Form<br />
O:TIG:TI. Dabei ist TI ein Kurzname für TrustedInstaller, die Entität, deren SID in Abbildung<br />
3.13 aufgeführt ist. Weil diese Version etwas einfacher zu lesen ist, verwenden wir sie<br />
bei unserer Analyse. Beachten Sie, dass sie zwei Token enthält: O:TI und G:TI. <strong>Die</strong> Parame-
Terminologie der Zugriffssteuerung 79<br />
ter werden ohne Leerzeichen aneinandergehängt, deshalb ist die SDDL-Zeichenfolge etwas<br />
schwierig zu lesen. Das führt oft zu Verwirrung, daher müssen Sie beim Auswerten dieser<br />
Zeichenfolgen daran denken, dass das Präfix O: für den Besitzer (engl. owner) und G: für<br />
die Gruppe steht.<br />
Beachten Sie auch den Beginn der DACL in Abbildung 3.13, die mit »D:PARAI« beginnt.<br />
Das »D:« ist das Präfix für DACL, auch wenn es mit der TI-SID verknüpft zu sein scheint.<br />
»P« bedeutet, dass die DACL davor geschützt ist, ACEs von übergeordneten Objekte zu<br />
erben (auch wenn es in diesem Beispiel gar keine übergeordneten Objekte gibt). »AR« ist<br />
das alte Flag, das angibt, dass Vererbung erforderlich ist. Es wird nicht mehr benutzt, in<br />
<strong>Sicherheit</strong>sbeschreibungen ist es aber noch oft enthalten. Und »AI« bedeutet, dass die DACL<br />
geerbt wurde. Weil das offensichtlich nicht der Fall ist, muss sie von Programmcode aus so<br />
geschrieben worden sein, dass alle diese Flags gesetzt sind. Falls die ACL nicht von Hand geändert<br />
wurde, dürften Sie diese Flags nie zusammen sehen, insbesondere nicht P in Kombination<br />
mit AI.<br />
Der Rest der <strong>Sicherheit</strong>sbeschreibung ist viel einfacher zu lesen, wenn wir sie umformatieren.<br />
Es ist sinnvoll, wenn wir uns ihre Bedeutung genauer ansehen.<br />
Interpretieren einer SDDL-Zeichenfolge<br />
In ihre Komponenten untergliedert sieht die DACL für das Stammverzeichnis des Laufwerks<br />
C: so aus:<br />
1. (A;OICI;FA;;;SY)<br />
2. (A;OICI;FA;;;BA)<br />
3. (A;OICI;0x1200a9;;;BU)<br />
4. (A;CI;LC;;;BU)<br />
5. (A;CIIO;DC;;;BU)<br />
6. (A;OICIIO;GA;;;CO)<br />
Der erste ACE gilt für SYSTEM (SY). <strong>Die</strong>s ist ein ACE, der an Objekte und Container vererbt<br />
wird und Vollzugriff (FA, für Full Access) gewährt.<br />
Der zweite ACE gleicht weitgehend dem ersten, gilt aber für die integrierte Gruppe Administratoren<br />
(BA, für Built-in Administrators).<br />
Der dritte ACE ist der erste von drei Benutzer-ACEs. <strong>Die</strong>sen hier haben wir bereits weiter<br />
oben in diesem Kapitel analysiert und festgestellt, dass er Lese- und Ausführungsberechtigungen<br />
sowie READ_CONTROL und SYNCHRONIZE gewährt.<br />
Der vierte ACE ist ein weiterer Benutzer-ACE. Er wird über Ordner vererbt (CI), verwendet<br />
aber eine unbekannte Berechtigung: LC. LC ist in Wirklichkeit eine Abkürzung, die in Active<br />
Directory verwendet wird. Sie steht für »List Children«, also »Auflisten der untergeordneten<br />
Objekte«. Das verrät uns zumindest die Erklärung der ACE-Zeichenfolgen unter http://msdn2.<br />
microsoft.com/en-us/library/aa374928.aspx. Um allerdings zu verstehen, welche Berechtigungen<br />
dadurch für eine Datei gewährt werden, müssen wir sie in eine Bitmaske konvertieren.<br />
Dazu müssen wir wissen, was die Konstante ADS_RIGHT_ACTRL_DS_LIST bedeutet, deren<br />
Abkürzung LC ist. Dazu sehen wir uns unter http://msdn2.microsoft.com/en-us/library/<br />
aa772285.aspx die Enumeration ADS_RIGHTS_ENUM an. Sie verrät uns, dass ADS_RIGHT_ACTRL_<br />
DS_LIST für den Wert 0x4 steht. 0x4 entspricht Bit 3 in Abbildung 3.5. Wenn dieses Bit bei<br />
einem Verzeichnis (um das es sich hier handelt) gesetzt ist, hat das Subjekt das Recht, ein<br />
Unterverzeichnis anzulegen.
80 Kapitel 3: Objekte: Was Sie wollen<br />
SDDL zeigt verzeichnisspezifische Abkürzungen, wenn Sie sich die Berechtigungen für eine<br />
Datei ansehen, weil das Modul, das die SDDL generiert, nichts über Objekttypen weiß. Es<br />
liest einfach die Zugriffsmaske und gibt dafür die am besten passenden Berechtigungsangaben<br />
aus einer Enumeration aus. <strong>Die</strong> verzeichnisspezifischen Berechtigungen stehen in der<br />
Enumeration schlicht am Anfang, und daher bekommen wir sie hier angezeigt.<br />
Dasselbe passiert im fünften ACE. Hier ist DC angegeben, die Abkürzung für ADS_RIGHT_<br />
DS _DELETE_CHILD. <strong>Die</strong>se Konstante steht für 0x2, es wird als Bit 2 gesetzt. Bei einem Active<br />
Directory-Objekt gibt Ihnen das das Recht, ein untergeordnetes Objekt zu löschen. In einem<br />
Verzeichnis gibt Ihnen Bit 2 dagegen das Recht, eine Datei im Verzeichnis anzulegen. Zusammen<br />
geben diese beiden ACEs Benutzern das Recht, neue Unterverzeichnisse zu erstellen<br />
und Dateien in Unterverzeichnissen anzulegen.<br />
Schließlich haben wir noch einen ACE für den Ersteller/Besitzer (CO für Creator/Owner).<br />
<strong>Die</strong>s ist ein weiterer ACE, der nur vererbt wird und auf alle untergeordneten Objekte angewendet<br />
wird. Er gewährt dem Subjekt, das ein untergeordnetes Objekt erstellt, Vollzugriff<br />
(GA) für das untergeordnete Objekt.<br />
Abbildung 3.14 zeigt, wie die Kombination dieser ACEs in der Benutzeroberfläche angezeigt<br />
wird.<br />
Abbildung 3.14 In der ACL-UI können Sie prüfen, ob Sie die SDDL-Zeichenfolge<br />
richtig interpretiert haben<br />
Sie sollten jetzt besser als die meisten verstehen, wie die Zugriffssteuerung in <strong>Windows</strong><br />
funktioniert. Sie haben sogar eine Reihe von Tools kennengelernt, mit denen Sie Berechtigungen<br />
verwalten können. Im nächsten Abschnitt arbeiten wir uns etwas tiefer in das Thema<br />
ein, wobei wir uns auf die Tools konzentrieren.
Tools zum Verwalten von Berechtigungen 81<br />
Direkt von der Quelle: Ändern von ACLs kann die Gesundheit Ihres<br />
Netzwerks und Ihre Karriere gefährden<br />
Wenn Sie versuchen, einen Computer zu schützen, können ACLs Verbündete oder Gegner<br />
sein. Ich bin Mitglied des Solution Accelerator Teams bei Microsoft. Unter anderem<br />
erstellt mein Team die <strong>Sicherheit</strong>sratgeber für viele Microsoft-Produkte. ACLs sind ein<br />
Aspekt der <strong>Sicherheit</strong>, mit dem wir uns immer beschäftigen, den wir aber selten in größerem<br />
Maßstab verwenden. Viele Fremdhersteller empfehlen, die Standard-ACLs eines<br />
Systems zu ändern. Manche beschreiben kleinere Anpassungen, andere eine große Zahl<br />
von Änderungen. Vor einigen Jahren veröffentlichten wir KB885409, um die Probleme zu<br />
beschreiben, die sich aufgrund solcher Änderungen ergeben können.<br />
Eines der größten Probleme beim Ändern von ACLs für Systemdateien und <strong>Die</strong>nstprogramme<br />
ist die unbekannte (aber oft deutliche) Auswirkung auf Anwendungskompatibilität.<br />
Vor einigen Jahren hatten wir einen Kunden, der die ACLs im Stammverzeichnis des<br />
Laufwerks C:\ änderte und diese Änderungen an alle Unterordner weitergab. <strong>Die</strong>se Konfiguration<br />
wurde dann in allen Umgebungen der Firma bereitgestellt, was dazu führte,<br />
dass Tausende von Computern nicht mehr benutzbar waren. Unabsichtlich hatten sie die<br />
<strong>Sicherheit</strong> verringert und Dutzende von <strong>Die</strong>nstprogrammen und Anwendungen lahmgelegt.<br />
Änderungen an den ACLs einzelner Dateien können diese Gefahr verringern, aber trotzdem<br />
die gewünschten Ergebnisse bringen. <strong>Die</strong> <strong>Die</strong>nstprogramme, die in jedem Betriebssystem<br />
oder Produkt enthalten sind, bringen den Administratoren große Vorteile. Oft kann<br />
auch ein Angreifer diese <strong>Die</strong>nstprogramme nutzen, um Details über die Umgebung auszuforschen,<br />
diverse Untaten zu begehen oder seine Spuren zu verwischen. Sie sollten<br />
sorgfältig überlegen, ob Sie die Nutzung dieser Ressourcen einschränken. Einerseits verringern<br />
Sie dadurch möglicherweise bestimmte Bedrohungen für das System, es kann<br />
aber auch reichlich lästig werden, wenn Sie das System warten oder mitten in der Nacht<br />
eine Problembehandlung durchführen müssen.<br />
Im Lauf der Jahre hat sich Microsoft mit großer Sorgfalt um dieses Detail gekümmert,<br />
und unser Team hat festgestellt, dass deutlich weniger Bedarf besteht, die Standard-ACLs<br />
zu verändern. Trotzdem sind solche Änderungen immer ein Faktor, den Sie im Rahmen<br />
einer Risikoanalyse für ein System beachten müssen. Das gilt insbesondere für Bereiche<br />
und Anwendungen, die sensible Daten enthalten.<br />
Chase Carpenter, Product Unit Manager<br />
Solution Accelerators <strong>–</strong> Security and Compliance<br />
Tools zum Verwalten von Berechtigungen<br />
Es gibt drei große Klassen von Tools zum Verwalten von Berechtigungen: integrierte GUI<br />
Tools, zum Beispiel die ACL-UI, integrierte Befehlszeilentools (Command-Line Interface,<br />
CLI), zum Beispiel Icacls, und andere Tools, zum Beispiel Subinacl. In diesem Abschnitt<br />
sehen wir uns kurz die wichtigsten dieser Tools an. <strong>Die</strong> ACL-UI ist relativ selbsterklärend<br />
und wir haben uns bereits weiter oben damit beschäftigt. Daher konzentriert sich dieser Abschnitt<br />
auf die beiden anderen Kategorien.
82 Kapitel 3: Objekte: Was Sie wollen<br />
Cacls und Icacls<br />
Cacls (change ACLs) ist seit vielen Jahren in <strong>Windows</strong> integriert. Es ist ein Befehlszeilentool,<br />
das in <strong>Windows</strong> 2000 nicht vollständig aktualisiert wurde, als sich das Vererbungsmodell<br />
änderte. Daher führte Microsoft in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Icacls<br />
(improved cacls) ein. Es ist zwar ein viel leistungsfähigeres Tool als Cacls, aber Icacls leidet<br />
noch unter einigen Kinderkrankheiten und weist einen deutlichen Nachteil auf: Es bietet<br />
keine Möglichkeit, einfach eine ACL als SDDL-Zeichenfolge auszugeben. <strong>Die</strong>ses Problem<br />
wird hoffentlich bald beseitigt, weil Cacls gerade ausgemustert wird, früher oder später wird<br />
es wohl ganz aus dem Betriebssystem verschwinden.<br />
Neben der grundlegenden Funktionalität bringt Icacls einige erweiterte Features mit, die<br />
vorher nicht in integrierten Tools zur Verfügung standen:<br />
Speichern und Wiederherstellen von ACLs. Mit den Befehlszeilenargumenten /save und<br />
/restore kann Icacls eine ACL speichern. Sie können die ACL in einer Datei speichern<br />
und diese Datei sogar ansehen. <strong>Die</strong>se Datei ist aber keine Textdatei, auch wenn sie so<br />
aussieht. Sie hat in Wirklichkeit ein binäres Format, das einer Unicode-Textdatei ähnelt,<br />
bei dem aber die entsprechende Zwei-Byte-Markierung am Anfang fehlt. Wenn Sie die<br />
Datei daher im <strong>Windows</strong>-Editor öffnen, fügt der Editor diese Markierung ein. Das führt<br />
dazu, dass Ihre ACLs nicht mehr aus der Datei wiederhergestellt werden können. Es<br />
kann daher sinnvoll sein, beim Speichern Ihrer Dateien die Erweiterung .bin anzuhängen,<br />
damit sie als Binärdateien interpretiert werden.<br />
Ersetzen von SIDs. <strong>Die</strong> Fähigkeit, Berechtigungen, die einer SID gewährt wurden, auf<br />
eine andere SID zu übertragen, ist ein sehr nützliches Feature in Icacls. Geben Sie dazu<br />
zusammen mit /restore das Befehlszeilenargument /substitute an, wenn Sie eine ACL<br />
wiederherstellen.<br />
Ändern des Besitzers. Mit dem Befehlszeilenargument /setowner kann Icacls den Besitzer<br />
eines Objekts ändern.<br />
Alle Berechtigungen für einen bestimmten Benutzer finden. Es kommt recht häufig vor,<br />
dass Sie eine Liste aller Berechtigungen brauchen, die einem bestimmten Benutzer gewährt<br />
werden. Mit dem Befehlszeilenargument /findsid ist das ganz einfach. <strong>Die</strong>se<br />
Funktion kann zum Beispiel bei der Überwachung nützlich sein.<br />
Zurücksetzen von ACLs. Falls eine ACL aus irgendwelchen Gründen zerstört wurde,<br />
können Sie sie mit dem Argument /reset auf die geerbte ACL zurücksetzen. Denken Sie<br />
aber daran, dass Ihnen dies nicht hilft, wenn Sie die Berechtigungen auf ihre Standardeinstellungen<br />
zurücksetzen wollen, falls Sie Berechtigungen für wichtige Betriebssystemdateien<br />
zerstört haben. <strong>Die</strong>se Dateien verwenden normalerweise keine geerbten Berechtigungen.<br />
Es gibt keine Möglichkeit, die Standardberechtigungen wiederherzustellen.<br />
Aus diesem Grund wird der Support verweigert, falls Sie Berechtigungen für wichtige<br />
Betriebssystemdateien ändern. Weitere Informationen finden Sie in KB 885409.<br />
Zulassen/Verweigern/Entfernen. Sie können natürlich Berechtigungen für beliebige SIDs<br />
gewähren, verweigern und entfernen.<br />
Einstellen der Integritätsebene. Icacls bietet auch die Fähigkeit, Integritätsebenen zu<br />
verwalten. Ich habe es bereits einige Male erlebt, dass Benutzer Objekte nicht löschen<br />
konnten, weil sie mit mittlerer Integrität (Standardwert) angemeldet waren und das Objekt<br />
eine hohe Integritätsebene hatte. Das Befehlszeilenargument /setintegritylevel<br />
kann ein solches Problem beseitigen.
SC<br />
Tools zum Verwalten von Berechtigungen 83<br />
Anzeigen von SDDL. Wie bereits erwähnt, ist Icacls nicht in der Lage, die SDDL-<br />
Zeichenfolge auszugeben, aber Cacls beherrscht diese Fähigkeit. Verwenden Sie cacls<br />
Objekt /s.<br />
Entfernen geerbter Berechtigungen. Icacls bietet auch keine Möglichkeit, geerbte Berechtigungen<br />
zu entfernen. Dazu müssen Sie Cacls ohne das Argument /E aufrufen.<br />
Warnung Es gibt einen Bug in der Komponente, auf der Cacls, Icacls und externe Tools wie zum Beispiel<br />
Subinacl aufbauen. <strong>Die</strong>ser Bug kann eine Menge Verwirrung stiften. Sie können ihn beobachten, indem Sie<br />
eine Eingabeaufforderung im Verzeichnis %SystemRoot%\system32\ öffnen und icacls c: ausführen.<br />
Führen Sie dann icacls c:\ aus und vergleichen Sie die Ergebnisse. Sie sind unterschiedlich. C: ist kein<br />
gültiges Verzeichnis. Daher meldet die Komponente, die die ACL abruft, einen Fehler und ruft stattdessen<br />
die ACL für das aktuelle Verzeichnis ab. Denken Sie daran, dass Sie alle Pfade in diesen drei Befehlszeilentools<br />
immer mit einem Backslash (\) abschließen müssen.<br />
SC, das Befehlszeilenprogramm für die <strong>Die</strong>nstkonfiguration, kann ACLs von <strong>Die</strong>nsten anzeigen<br />
und verwalten. Es zeigt sie allerdings nur in SDDL an. Rufen Sie dazu sc sdshow<br />
<strong>Die</strong>nstname auf. Mit sc sdset <strong>Die</strong>nstname SD-im-SDDL-Format können Sie die ACL für einen<br />
<strong>Die</strong>nst festlegen.<br />
Subinacl<br />
Weiter oben haben Sie gesehen, wie mit Subinacl eine <strong>Sicherheit</strong>sbeschreibung angezeigt<br />
wird. Subinacl ist leistungsfähiger als alle integrierten CLI-Tools zusammen, aber auch entsprechend<br />
kompliziert. Es ist aber das einzige Tool, das Berechtigungen für alle folgenden<br />
Objekte verwalten kann:<br />
<strong>Die</strong>nste<br />
Dateien<br />
Clusterfreigaben<br />
Drucker<br />
Freigaben<br />
Registrierungsschlüssel<br />
SAM-Objekte<br />
<strong>Die</strong> IIS-Metabasis (wird in IIS 7.0 nicht mehr benutzt)<br />
Prozesse<br />
Kernobjekte<br />
Offensichtlich eignet sich Subinacl in erster Linie für sehr erfahrene Administratoren. Es<br />
kann aber unverzichtbar sein, wenn Sie bestimmte erweiterte Operationen mit ACLs durchführen<br />
müssen.
84 Kapitel 3: Objekte: Was Sie wollen<br />
Wichtige Änderungen bei der Zugriffssteuerung<br />
in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista führen gegenüber älteren <strong>Windows</strong>-Versionen<br />
einige Änderungen bei der Zugriffssteuerung ein. Einige dieser Änderungen sind recht subtil,<br />
aber zwei sind für viele Administratoren sehr wichtig. Sehen wir uns erst einmal die<br />
subtilen an.<br />
TrustedInstaller-Berechtigungen<br />
Wie Sie bereits gesehen haben, ist der <strong>Die</strong>nst TrustedInstaller nun Besitzer vieler Objekte in<br />
<strong>Windows</strong>. Das bedeutet, dass sogar Administratoren auf eine Menge Objekte stoßen, die sie<br />
nicht ändern können, ohne vorher ihre Berechtigungen zu ändern. Als Administrator werden<br />
Sie natürlich niemals völlig ausgesperrt, aber irgendwann kommt es sicherlich vor, dass Sie<br />
versuchen, ein Objekt zu ändern, und Ihnen der Zugriff verweigert wird. Dann sollten Sie<br />
sich fragen, ob Sie dieses Objekt tatsächlich ändern sollten. <strong>Die</strong>se Einschränkungen sollen<br />
dafür sorgen, die Stabilität zu verbessern.<br />
Netzwerkstandort-SIDs<br />
Wie Sie in den Abbildungen 3.10 und 3.11 gesehen haben, enthalten die <strong>Sicherheit</strong>stoken<br />
Netzwerkstandort-SIDs. Weil in einer ACL SIDs für INTERAKTIV, NETZWERK und so<br />
weiter enthalten sind, kann ein Administrator den Zugriff auf ein bestimmtes Objekt abhängig<br />
von der Zugriffsmethode steuern. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista wurden<br />
zwei neue Netzwerkstandort-SIDs hinzugefügt: DIALUP und INTERNET. <strong>Die</strong> SID DIALUP<br />
gilt für Benutzer, die eine DFÜ-Verbindung herstellen, INTERNET für jeden, der sich über<br />
eine Netzwerkverbindung anmeldet, die nicht als der lokale Standort eingestuft wird.<br />
Änderungen beim Dateisystemnamespace<br />
Es fällt gleich auf, dass das Verzeichnis Dokumente und Einstellungen (beziehungsweise<br />
Documents and Settings in der englischen Version), das wir seit <strong>Windows</strong> 2000 kennen, jetzt<br />
%SystemDrive%\Users heißt, und dass beträchtliche Teile davon in %SystemDrive%\ProgramData<br />
verschoben wurden. <strong>Die</strong>se Änderung hat Microsoft durchgeführt, um den Dateisystemnamespace<br />
zu vereinfachen. Allerdings verwenden viele alte Anwendungen die vollständigen<br />
Pfade mit den alten Verzeichnisnamen, statt Umgebungsvariablen auszuwerten.<br />
Um zu vermeiden, dass solche Anwendungen lahmgelegt werden, hat Microsoft Abzweigungspunkte<br />
und Symlinks vom alten Namespace in den neuen angelegt. Für die Migration<br />
wurden alle diese Abzweigungspunkte und Symlinks mit einem Verweigern-ACE versehen,<br />
der das Auflisten des Verzeichnisses verbietet. Anders ausgedrückt: Sie können eine Datei<br />
im alten Dokumente und Einstellungen-Verzeichnis angeben, aber Sie können dieses Verzeichnis<br />
nicht in <strong>Windows</strong>-Explorer öffnen. Falls Sie versuchen, es zu öffnen, bekommen<br />
Sie eine Fehlermeldung, dass der Zugriff verweigert wurde. Viele Leute haben sich darüber<br />
beklagt, seit <strong>Windows</strong> Vista herauskam. Es sollte darauf hingewiesen werden, warum das<br />
der Fall ist.
Benutzerrechte und Privilegien 85<br />
Berechtigungen für Hauptbenutzer entfernt<br />
Eine der auffälligeren Änderungen ist, dass fast alle Berechtigungen für Hauptbenutzer entfernt<br />
wurden. Es gibt hier und da noch einige Überbleibsel, aber alles in allem sind Hauptbenutzer<br />
nicht mehr leistungsfähiger als Standardbenutzer. <strong>Die</strong>s soll den Weg bereiten, um<br />
die Gruppe Hauptbenutzer irgendwann ganz zu entfernen. Ursprünglich sollte Hauptbenutzer<br />
eine Gruppe für Leute sein, die einige kritische Operationen durchführen können, aber<br />
keine richtigen Administratoren sind. Als aber alle Berechtigungen hinzugefügt waren, die<br />
erforderlich waren, um die Gruppe nutzbar zu machen, waren ihre Mitglieder beinahe vollständige<br />
Administratoren. In der Praxis lief es auf dasselbe hinaus, ob Sie einen Benutzer<br />
zum Hauptbenutzer oder Administrator machten. Weil die Gruppe keinen Nutzen brachte,<br />
aber Verwirrung stiften konnte, hat sich Microsoft daran gemacht, die Gruppe zu deaktivieren.<br />
<strong>Die</strong> UAC erfüllt jetzt die Aufgabe, an der Hauptbenutzer letztlich immer scheiterte.<br />
EIGENTÜMERRECHTE und Besitzerrechte<br />
<strong>Die</strong> letzte Änderung ist wahrscheinlich die interessanteste. Bisherige <strong>Windows</strong>-Versionen<br />
hatten immer die ERSTELLER-BESITZER-SID. ERSTELLER-BESITZER wird normalerweise<br />
in vererbbaren ACEs benutzt, um dem Subjekt, das ein untergeordnetes Objekt anlegt,<br />
bestimmte Berechtigungen zu geben. <strong>Die</strong> SID wird beim Erstellen des Objekts durch die<br />
SID des tatsächlichen Erstellers ersetzt.<br />
In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> gibt es in diesem Bereich eine neue SID:<br />
EIGENTÜMERRECHTE. Während ERSTELLER-BESITZER beim Erstellen des Objekts<br />
ersetzt wird, gilt das für EIGENTÜMERRECHTE nicht. EIGENTÜMERRECHTE wurde<br />
eingeführt, weil sich etwas an den Berechtigungen für Besitzer geändert hat. In älteren<br />
Versionen hatte der Besitzer eines Objekts immer die implizite Berechtigung, die DACL<br />
des Objekts zu ändern. Viele Administratoren forderten die Fähigkeit, dieses Verhalten zu<br />
ändern, damit Benutzer die Berechtigungen ihrer eigenen Dateien nicht mehr verändern<br />
können. <strong>Die</strong>se Funktionalität wird nun in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> mithilfe<br />
der SID EIGENTÜMERRECHTE verwirklicht. Falls die SID EIGENTÜMERRECHTE auf<br />
das Objekt angewendet wird, hat sie Vorrang vor den impliziten Rechten des Besitzers.<br />
Wenn Sie also einen EIGENTÜMERRECHTE-ACE mit Ändern-Berechtigungen zu einem<br />
Objekt hinzufügen, kann der Besitzer die Berechtigungen des Objekts nicht mehr verändern.<br />
Falls der Besitzer des Objekts ausgetauscht wird, wird der EIGENTÜMERRECHTE-ACE so<br />
markiert, dass er nur noch vererbt wird. Das gilt sogar dann, wenn es sich um eine Datei<br />
handelt. Der ACE wird dadurch de facto deaktiviert, bis der Administrator sicherstellen<br />
kann, dass die Berechtigungen nicht alle aussperren.<br />
Benutzerrechte und Privilegien<br />
Wir haben einen letzten Aspekt der Zugriffssteuerung bereits mehrmals erwähnt, aber noch<br />
nicht richtig erklärt: Benutzerrechte und Privilegien. <strong>Die</strong> Begriffe Benutzerrechte (engl. user<br />
right) und Privilegien (engl. privilege) werden oft durcheinandergewürfelt, viele glauben,<br />
beide wären dasselbe. Sie sind aber in Wirklichkeit ganz unterschiedliche Konstrukte. Benutzerrechte<br />
steuern nur, auf welche Art sich ein Benutzer anmelden kann. Privilegien legen<br />
dagegen fest, was Benutzer tun können, sobald sie einmal angemeldet sind. In den Abbildungen<br />
3.10 und 3.11 haben Sie Privilegien in einem Token gesehen. Privilegien werden
86 Kapitel 3: Objekte: Was Sie wollen<br />
in Gruppenrichtlinien unter dem Knoten Zuweisen von Benutzerrechten verwaltet (Abbildung<br />
3.15).<br />
Abbildung 3.15 Sie können Privilegien in Gruppenrichtlinien verwalten<br />
In vielen Tools (zum Beispiel bei den Tokens, die im Process Explorer aufgelistet werden)<br />
werden Privilegien in einem anderen Format als in den Gruppenrichtlinien angezeigt. Tabelle<br />
3.7 führt beide Zeichenfolgen für alle Privilegien auf und beschreibt, was das Privileg<br />
bedeutet. Fettgedruckte Privilegien in Tabelle 3.7 sind sehr kritische Privilegien, die dem,<br />
der sie gewährt bekommt, sehr mächtige Rechte auf dem Computer geben.<br />
Tabelle 3.7 Privilegien in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Konstante/Wert Anzeigename Beschreibung<br />
SeAssign-<br />
PrimaryToken-<br />
Privilege<br />
Ersetzen eines Tokens<br />
auf Prozessebene<br />
SeAuditPrivilege Generieren von <strong>Sicherheit</strong>süberwachungen<br />
SeBackup-<br />
Privilege<br />
SeChangeNotify-<br />
Privilege<br />
Sichern von Dateien<br />
und Verzeichnissen<br />
Auslassen der durchsuchenden<br />
Überprüfung<br />
Erlaubt es, jedem beliebigen Prozess ein neues Token zuzuweisen.<br />
<strong>Die</strong>ses Privileg kann sehr kritisch sein, falls es in Kombination mit<br />
einem Privileg vergeben wird, das es erlaubt, ein Prozesstoken<br />
abzurufen.<br />
Erlaubt es, beliebige <strong>Sicherheit</strong>sereignisprotokollereignisse zu erstellen.<br />
Ein Angreifer kann damit beliebige Daten in das Ereignisprotokoll<br />
schreiben.<br />
Erlaubt es, auf alle Teile von beliebigen Dateien oder Objekten<br />
zuzugreifen, unabhängig von der ACL des Objekts. Anders<br />
ausgedrückt: Es gewährt Lesezugriff auf alle Objekte.<br />
<strong>Die</strong>ses Privileg ist für alle Benutzer aktiviert. Es bewirkt, dass das<br />
System ein Durchlaufen von Verzeichnishierarchien erlaubt, auf die<br />
der Benutzer keinen Zugriff hat. Wie der Name der Konstante andeutet,<br />
erlaubt es dem Benutzer auch, Benachrichtigungen über Änderungen<br />
an einem geschützten Objekt zu empfangen.
Konstante/Wert Anzeigename Beschreibung<br />
SeCreateGlobal-<br />
Privilege<br />
SeCreatePagefilePrivilege <br />
SeCreatePermanentPrivilege <br />
SeCreateSymbolicLinkPrivilege<br />
SeCreateToken-<br />
Privilege<br />
SeDebugPrivilege <br />
SeEnableDelegationPrivilege<br />
SeImpersonate-<br />
Privilege<br />
SeIncreaseBase-<br />
PriorityPrivilege<br />
Erstellen globaler Objekte<br />
Erstellen einer Auslagerungsdatei<br />
Erstellen von dauerhaft<br />
freigegebenen Objekten<br />
Erstellen symbolischer<br />
Verknüpfungen<br />
Erstellen eines Tokenobjekts<br />
Debuggen von Programmen<br />
Ermöglichen, dass<br />
Computer- und Benutzerkonten<br />
für Delegierungszwecke<br />
vertraut<br />
wird<br />
Annehmen der Clientidentität<br />
nach Authentifizierung<br />
Anheben der Zeitplanungspriorität<br />
Benutzerrechte und Privilegien 87<br />
Erlaubt es, Objekte (zum Beispiel symbolische Links) in einem Objekt-Manager-Namespace<br />
zu erstellen, der einer anderen Sitzung<br />
zugewiesen ist.<br />
Gewährt das Recht, eine Auslagerungsdatei zu erstellen.<br />
Ein dauerhaftes Objekt wird nicht gelöscht, wenn es von niemandem<br />
mehr benötigt wird. <strong>Die</strong>ses Privileg ist recht kritisch, weil es einem<br />
böswilligen Benutzer erlauben könnte, Ressourcen auf dem Computer<br />
zu verbrauchen und im Vorfeld Objekte anzulegen, die von wichtigen<br />
Prozessen benötigt werden.<br />
<strong>Die</strong> Fähigkeit, symbolische Verknüpfungen (symbolische Links) zu<br />
erstellen, ist in Unix-Betriebssystemen schon lange eine Ursache für<br />
<strong>Sicherheit</strong>slücken. Ein böswilliger Benutzer kann eine symbolische<br />
Verknüpfung unter demselben Namen wie eine Betriebssystemdatei<br />
erstellen, die aber auf ein böswilliges Programm verweist. Falls ein<br />
Administrator die symbolische Verknüpfung aufruft, wird der böswillige<br />
Code ausgeführt, nicht die gewünschte Betriebssystemdatei. Um<br />
diese Gefahr zu verringern, stellt <strong>Windows</strong> dieses Privileg bereit.<br />
<strong>Die</strong>s ist ein äußerst kritisches Privileg. Es erlaubt dem Benutzer,<br />
<strong>Sicherheit</strong>stoken für beliebige Benutzer mit beliebiger Gruppenmitgliedschaft<br />
zu erstellen. Ein Subjekt kann auf diese Weise<br />
ein beliebiger anderer Benutzer auf dem Computer werden.<br />
<strong>Die</strong>s ist eines der kritischsten Privilegien im Betriebssystem. Es<br />
erlaubt es, beliebige Prozesse zu debuggen, auch Prozesse, die<br />
anderen Benutzern gehören. Mit diesem Privileg kann ein Benutzer<br />
Code in andere Prozesse einschleusen und im Kontext<br />
des Subjekts ausführen lassen, das den Prozess gestartet hat.<br />
Auf diese Weise arbeiten zum Beispiel alle Programme, die<br />
Kennworthashwerte ausspähen.<br />
<strong>Die</strong>s ist ein weiteres sehr kritisches Privileg, aber nur in einer<br />
Domänenumgebung. Es ermöglicht es, Konten zu konfigurieren,<br />
denen für Delegierungszwecke vertraut wird. Konten, denen für<br />
Delegierungszwecke vertraut wird, können <strong>Sicherheit</strong>stoken<br />
erstellen.<br />
Erlaubt es, ein Identitätswechseltoken für einen Benutzer zu erstellen.<br />
Vor einigen Jahren gab es öfters Angriffe, bei denen eine Named<br />
Pipe mit einem ähnlichen Namen wie eine häufig verwendete Freigabe<br />
eingerichtet wurde. Wenn ein Benutzer mit der Pipe verbunden<br />
ist, kann das böswillige Programm, das die Pipe angelegt hat, sich<br />
für den Benutzer ausgeben und alle Aktionen ausführen, die dem<br />
Benutzer erlaubt sind. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> kann nur ein Subjekt,<br />
das SeImpersonatePrivilege besitzt, den Identitätswechsel durchführen.<br />
Erlaubt es, die Priorität eines Prozesses zu ändern. Ein Subjekt, das<br />
dieses Privileg besitzt, könnte dem System die benötigten Ressourcen<br />
vorenthalten, indem er einem einzigen Prozess so hohe Priorität<br />
gibt, dass er alle Prozessorzyklen mit Beschlag belegt.
88 Kapitel 3: Objekte: Was Sie wollen<br />
Konstante/Wert Anzeigename Beschreibung<br />
SeIncrease-<br />
QuotaPrivilege<br />
SeIncrease-<br />
WorkingSet-<br />
Privilege<br />
SeLoadDriver-<br />
Privilege<br />
SeLockMemory-<br />
Privilege<br />
SeMachine-<br />
AccountPrivilege<br />
SeManage-<br />
VolumePrivilege<br />
SeProfileSingle-<br />
ProcessPrivilege<br />
SeRelabelPrivilegeSeRemoteShutdownPrivilege <br />
SeRestorePrivilege <br />
SeSecurityPrivilege<br />
SeShutdown-<br />
Privilege<br />
SeSyncAgent-<br />
Privilege<br />
SeSystem-<br />
Environment-<br />
Privilege<br />
SeSystemProfile-<br />
Privilege<br />
SeSystemtime-<br />
Privilege<br />
Anpassen von Speicherkontingenten<br />
für einen<br />
Prozess<br />
Arbeitssatz eines Prozesses<br />
vergrößern<br />
Laden und Entfernen<br />
von Gerätetreibern<br />
Sperren von Seiten im<br />
Speicher<br />
Hinzufügen von Arbeitsstationen<br />
zur Domäne<br />
Durchführen von Volumewartungsaufgaben<br />
Erstellen eines Profils für<br />
einen Einzelprozess<br />
Verändern einer Objektbezeichnung<br />
Erzwingen des Herunterfahrens<br />
von einem Remotesystem<br />
aus<br />
Wiederherstellen von<br />
Dateien und Verzeichnissen<br />
Verwalten von Überwachungs-<br />
und <strong>Sicherheit</strong>sprotokollen<br />
Herunterfahren des<br />
Systems<br />
Synchronisieren von<br />
Verzeichnisdienstdaten<br />
Verändern der Firmwareumgebungsvariablen<br />
Erlaubt es zu ändern, wie viel Arbeitsspeicher einem Prozess zugewiesen<br />
ist.<br />
<strong>Die</strong>ses Privileg ist relativ neu. Früher wurde dieses Verhalten durch<br />
SeIncreaseQuotaPrivilege gesteuert. SeIncreaseWorkingSetPrivilege<br />
erlaubt es, die Arbeitsseiten für eigene Prozesse zu ändern. Es ist<br />
daher weniger kritisch.<br />
Erlaubt es, einen Gerätetreiber zu laden. <strong>Die</strong>s ist ein sehr kritisches<br />
Privileg, weil es erlaubt, Code zu laden, der im Kernel<br />
ausgeführt wird, also ohne irgendwelche <strong>Sicherheit</strong>seinschränkungen.<br />
Erlaubt es, Seiten im Speicher zu sperren, sodass sie nicht auf<br />
Festplatte ausgelagert werden.<br />
Erlaubt es, Computer in einer Domäne hinzuzufügen. <strong>Die</strong>ses Privileg<br />
hat auf einem eigenständigen Computer keine Auswirkungen.<br />
Erlaubt es, bestimmte Aufgaben direkt auf einem Datenträgervolume<br />
durchzuführen, zum Beispiel das Volume zu defragmentieren.<br />
Erlaubt es, bestimmte Leistungsdaten im Zusammenhang mit dem<br />
Datei-Prefetching in einem Prozess zu sammeln.<br />
Erlaubt einem Benutzer, die Beschriftung (label) eines Objekts zu<br />
ändern, selbst wenn der Benutzer dessen SACL nicht ändern darf.<br />
Wie der Name andeutet, erlaubt dieses Privileg, das System im<br />
Remotezugriff herunterzufahren.<br />
Ein sehr kritisches Privileg, das es erlaubt, in beliebige Dateien<br />
oder Registrierungsschlüssel zu schreiben.<br />
Erlaubt es, das <strong>Sicherheit</strong>sereignisprotokoll zu verwalten, zum Beispiel<br />
die Größe zu ändern, das Protokoll zu leeren und seine Ereignisse<br />
anzusehen.<br />
Erlaubt es, den Computer normal herunterzufahren.<br />
Erlaubt es, alle Objekte und Eigenschaften in Active Directory<br />
zu lesen.<br />
Manche Computer speichern Systemkonfigurationsparameter in<br />
nichtflüchtigem RAM. <strong>Die</strong>ses Privileg erlaubt es, diese Parameter zu<br />
ändern.<br />
Erstellen eines Profils der Erlaubt es, Leistungsdaten zum gesamten System abzurufen.<br />
Systemleistung<br />
Ändern der Systemzeit Erlaubt es, die Systemuhr zu ändern. Das gilt als kritische Operation,<br />
denn wenn ein Benutzer die Systemuhr verstellen kann, ist er in der<br />
Lage, die Reihenfolge von Überwachungsereignissen zu verfälschen.
Konstante/Wert Anzeigename Beschreibung<br />
SeTakeOwnershipPrivilege<br />
Übernehmen des Besitzes<br />
von Dateien und<br />
Objekten<br />
SeTcbPrivilege Einsetzen als Teil des<br />
Betriebssystems<br />
SeTimeZone-<br />
Privilege<br />
SeTrustedCred-<br />
ManAccess-<br />
Privilege<br />
SeUndock-<br />
Privilege<br />
RBAC/AZMAN 89<br />
Erlaubt es, den Besitz eines beliebigen Objekts zu übernehmen,<br />
unabhängig von der DACL des Objekts.<br />
Wer dieses Privileg besitzt, kann einige sehr kritische Operationen<br />
durchführen, zum Beispiel Prozesstoken mit beliebigen<br />
SIDs erstellen.<br />
Ändern der Zeitzone Ein neues Privileg in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>.<br />
<strong>Die</strong>ses Privileg wurde hinzugefügt, um Standardbenutzern zu erlauben,<br />
die Zeitzone des Betriebssystems zu ändern, auch wenn sie<br />
nicht berechtigt sind, die Systemuhr zu verstellen.<br />
Auf Anmeldeinformations-Manager<br />
als vertrauenswürdigemAufrufer<br />
zugreifen<br />
Entfernen des Computers<br />
von der Dockingstation<br />
Erlaubt erweiterten Zugriff auf das Anmeldeinformationsverwaltungs-Subsystem,<br />
in erster Linie für die Datensicherung. Das<br />
Privileg erlaubt, alle Einträge in der Anmeldeinformationsverwaltung<br />
zu sichern und wiederherzustellen. <strong>Die</strong>ses Privileg wird<br />
normalerweise überhaupt keinem Benutzer zugewiesen, aber<br />
einige Prozesse, zum Beispiel WinLogon und LSASS (Local<br />
Security Authority Subsystem), haben es in der Standardeinstellung.<br />
Erlaubt es, ein Notebook ordnungsgemäß aus einer Dockingstation<br />
zu entfernen. Allerdings kann jemand auch ohne dieses Privileg<br />
einfach die Auswurftaste der Dockingstation drücken oder die Dockingstation<br />
samt Computer stehlen.<br />
Sie müssen unbedingt wissen, wie die Privilegien aus Tabelle 3.7 funktionieren. Genauso<br />
wichtig ist, dass Sie wissen, welcher Gefahr Sie sich aussetzen, wenn Sie Privilegien von<br />
Gruppen ändern (insbesondere entfernen), die sie in der Standardeinstellung haben. Das<br />
kann sich negativ auf die Stabilität Ihres Computers auswirken <strong>–</strong> und so mancher Administrator<br />
musste schon feststellen, dass es auch der Karriere einen Dämpfer versetzen kann.<br />
Falls Sie diese Privilegien richtig verwalten, können Sie die <strong>Sicherheit</strong> Ihres Computers<br />
verbessern, indem Sie die Zuweisung von Privilegien anpassen. Falls Sie dabei Fehler<br />
machen, können Sie einen oder mehrere Computer unbenutzbar machen (wenn Sie Glück<br />
haben) oder ernste <strong>Sicherheit</strong>slücken schaffen (wenn Sie Pech haben).<br />
RBAC/AZMAN<br />
Bevor wir das Thema Zugriffssteuerung hinter uns lassen und zu anderen Themen weitergehen,<br />
sollte ich kurz den Autorisierungs-Manager (Authorization Manager, AZMAN) erwähnen.<br />
AZMAN ist nicht neu in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, aber er ist relativ unbekannt. Er soll es<br />
den Entwicklern von Fremdherstellern ermöglichen, eigene Zugriffssteuerungsmechanismen<br />
zu implementieren, unabhängig von denen, die das Betriebssystem zur Verfügung stellt. Insbesondere<br />
können Entwickler AZMAN nutzen, um ein rollenbasiertes Zugriffssteuerungssystem<br />
(Role-Based Access Control, RBAC) zu implementieren.<br />
Was wir bisher beschrieben haben, ist eine identitätsbasierte Zugriffssteuerung. Statt die<br />
Zugriffssteuerung von der Identität des Subjekts abhängig zu machen, arbeitet RBAC auf<br />
Basis einer Rollenmitgliedschaft. Im Prinzip ist sie nicht inkompatibel zur identitätsbasierten<br />
Zugriffssteuerung, aber die in der RBAC verwendeten Konstrukte leiten sich aus dem
90 Kapitel 3: Objekte: Was Sie wollen<br />
Konzept der Rolle in der realen Welt ab. Zum Beispiel kann ein Benutzer die Rolle »Spesenabrechungsprüfer«<br />
haben, die ihm erlaubt, Spesenabrechnungen zu genehmigen.<br />
<strong>Die</strong>ser Teil der rollenbasierten Zugriffssteuerung kann mithilfe der herkömmlichen Zugriffssteuerungsmechanismen<br />
implementiert werden. RBAC erlaubt es aber auch, Einschränkungen<br />
für die Rollen festzulegen, bei denen ein Benutzer Mitglied sein kann. Eine statische<br />
Einschränkung verhindert, dass ein Benutzer gleichzeitig zwei Rollen einnehmen kann. Ein<br />
Beispiel für eine statische Einschränkung ist, dass ein Schalteraufseher in der Bank niemals<br />
selbst als Schaltermitarbeiter tätig sein darf. RBAC unterstützt auch dynamische Einschränkungen,<br />
die dem Benutzer erlauben, zwei verschiedene Rollen wahrzunehmen, aber nicht<br />
gleichzeitig. In unserem vorigen Beispiel kann ein Schaltermitarbeiter also ein Schalteraufseher<br />
sein, aber er kann niemals beide Rollen gleichzeitig wahrnehmen.<br />
Das war eine ganz kurze Einführung in RBAC, und <strong>Windows</strong> unterstützt es nicht für die<br />
Verwaltung von <strong>Windows</strong> selbst. Falls Sie allerdings Branchensoftware für <strong>Windows</strong> verwalten<br />
oder entwickeln, müssen Sie sich unter Umständen eingehender mit RBAC beschäftigen.<br />
Weitere Informationen finden Sie im White Paper unter http://technet2.microsoft.com/<br />
windowsserver/en/library/72b55950-86cc-4c7f-8fbf-3063276cd0b61033.mspx?mfr=true.<br />
Zusammenfassung<br />
Zugriffssteuerung ist ein Thema, bei dem sich viele Administratoren weniger gut auskennen,<br />
als sie sollten. Zum Beispiel sind die Vererbungsmechanismen in <strong>Windows</strong> recht komplex<br />
und sehr leistungsfähig. Mangelnder Respekt gegenüber der Komplexität sowie fehlendes<br />
Verständnis dafür, wie die Zugriffssteuerung funktioniert, hat viele Administratoren veranlasst,<br />
DACLs großflächig auszutauschen. Oft wurden sie dazu von Auditoren gedrängt, die<br />
noch weit weniger davon verstehen, wie <strong>Windows</strong> arbeitet. Dabei werden immer wieder<br />
Computer völlig unbrauchbar gemacht. Ich war einmal bei einem Kunden im Einsatz, der<br />
ein Gruppenrichtlinienobjekt bereitgestellt hatte, das Jeder durch Authentifizierte Benutzer<br />
ersetzte. Wie ich weiter oben erwähnt habe, sind die beiden von der Funktion her praktisch<br />
identisch. Das Ergebnis war, dass das Profil des Administrators von allen gelesen werden<br />
konnte, der Papierkorb nicht funktionierte und sich kein Benutzer mehr anmelden konnte.<br />
Wenn der Kunde das nur auf einem einzigen Computer gemacht hätte, wäre es schon<br />
schlimm genug gewesen, aber die Richtlinie wurde auf über 10.000 Computern bereitgestellt,<br />
bevor sie deaktiviert wurde. Jeder einzelne dieser Computer musste von einem Abbild<br />
wiederhergestellt werden, damit der normale Betrieb wieder möglich war. Hätte der Kunde<br />
verstanden, wie DACLs wirklich funktionieren, wäre es unter Umständen möglich gewesen,<br />
die beabsichtigte Änderung durchzuführen. Noch besser wäre es allerdings gewesen, er hätte<br />
gleich erkannt, dass sie ohnehin unnötig war.<br />
Weitere Informationen<br />
Microsoft Knowledge Base-Artikel 885409, »Empfehlungen zur <strong>Sicherheit</strong>skonfiguration«<br />
unter http://support.microsoft.com/?kbid=885409.
K A P I T E L 4<br />
Grundlagen der Benutzerkontensteuerung<br />
Von Darren Canavor<br />
In diesem Kapitel:<br />
Was ist Benutzerkontensteuerung? ....................................... 91<br />
So funktioniert die Tokenfilterung ......................................... 93<br />
Komponenten der Benutzerkontensteuerung ................................. 94<br />
UAC-Gruppenrichtlinieneinstellungen ...................................... 108<br />
Was hat sich bei der UAC in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista SP1 geändert? .... 111<br />
Empfehlungen für die UAC ............................................. 112<br />
Zusammenfassung .................................................. 113<br />
Weitere Informationen ................................................ 114<br />
Computer werden heute anders verwendet als noch vor einigen Jahren. Zum Beispiel geben<br />
Benutzer Banküberweisungen auf, kaufen online Waren und speichern persönliche Daten.<br />
Infolgedessen haben sich neue <strong>Sicherheit</strong>sbedrohungen entwickelt. Ein großer Teil der <strong>Windows</strong>-Benutzer<br />
arbeitete ständig mit administrativen Privilegien. Falls der Benutzer versehentlich<br />
böswillige Software (Malware) auf einem solchen Computer installierte, konnte<br />
diese Malware (die Administratorzugriff hatte) praktisch alles tun. In <strong>Windows</strong> Vista und<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> soll die neue Benutzerkontensteuerung (User Account Control, UAC)<br />
das Prinzip der »geringmöglichsten Privilegien« durchsetzen: Es soll nur gerade so viel<br />
Zugriff gewährt werden, wie unbedingt erforderlich ist, um die Aufgabe durchzuführen;<br />
dabei sollen möglichst wenig Unterbrechungen auftreten, um die Benutzerfreundlichkeit<br />
nicht zu gefährden. Das betrifft alle interaktiven Benutzer, mit Ausnahme des integrierten<br />
Kontos Administrator. Das mag einfach klingen, aber dafür musste eine Lösung entwickelt<br />
werden, die umfassende Änderungen am Kernbetriebssystem erforderte, die Wahrnehmung<br />
des Standardbenutzerdesktops veränderte und durchsetzen musste, dass die Softwarefremdhersteller<br />
auf breiter Basis Verfahrensempfehlungen für Standardbenutzer befolgten.<br />
Hinweis <strong>Die</strong> UAC steht zwar in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zur Verfügung, in erster Linie wird sie aber als<br />
Clientfeature eingestuft. Für einen Systemadministrator konzentriert sich die Auswirkung der UAC auf<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> darauf, mithilfe von Gruppenrichtlinien UAC-Richtlinien für <strong>Windows</strong> Vista-Clients zu<br />
verwalten.<br />
Was ist Benutzerkontensteuerung?<br />
<strong>Die</strong> UAC kann helfen, unautorisierte Änderungen an einem Computer zu verhindern, indem<br />
sie dem Benutzer erlaubt, Aktionen zu bestätigen, bevor sie durchgeführt werden. Wenn ein<br />
Benutzer, der erhöhte Privilegien besitzt, sich an <strong>Windows</strong> Vista oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
anmeldet, werden zwei Zugriffstoken ausgestellt: ein vollständiges Zugriffstoken und ein<br />
91
92 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
gefiltertes Standardbenutzer-Zugriffstoken. Der Filterungsprozess entfernt die administrativen<br />
Privilegien und deaktiviert die <strong>Sicherheit</strong>s-IDs (Security Identifier, SID) der Administratorgruppe,<br />
wodurch ein gefiltertes Standardbenutzer-Zugriffstoken entsteht. Das Standardbenutzertoken<br />
wird dann verwendet, um den <strong>Windows</strong>-Desktop (explorer.exe) und danach<br />
alle untergeordneten Prozesse zu starten. Folglich laufen alle Anwendungen in der Standardeinstellung<br />
mit dem Standardbenutzertoken, und nur wenn ein Administrator die Genehmigung<br />
erteilt, läuft eine Anwendung mit einem vollständigen Zugriffstoken. Anwendungen<br />
erben die Privilegebene des übergeordneten Prozesses. Falls daher der übergeordnete Prozess<br />
mit einem vollständigen Zugriffstoken läuft, erbt der neue untergeordnete Prozess dieses<br />
Token und wird ausgeführt, ohne dass die Genehmigung des Administrators angefordert<br />
wird. Falls Sie zum Beispiel eine Eingabeaufforderung als Administrator starten, läuft auch<br />
jeder Prozess, den Sie innerhalb der Eingabeaufforderung ausführen, als Administrator.<br />
Auf der CD Elevating Explorer<br />
Standardmäßig wurde Explorer.exe nicht dafür entworfen, erhöhte Privilegien anzufordern. Wenn Sie daher<br />
mit der rechten Maustaste auf die ausführbare Datei klicken und Als Administrator ausführen wählen, wird<br />
zwar ein neues Fenster geöffnet, aber im selben Kontext wie das Original. Auf der Begleit-CD finden Sie<br />
einen Satz von Anhebungstools, darunter eines, das die Kontextmenüs aller Ordner durch den Befehl<br />
Elevate Explorer Here ergänzt (das Tool steht nur in englischer Sprache zur Verfügung). Mit diesem Tool<br />
können Sie an jeder beliebigen Stelle eine <strong>Windows</strong>-Explorer-Instanz mit erhöhten Privilegien öffnen.<br />
Tabelle 4.1 UAC-Liste der eingeschränkten RIDs<br />
Eingeschränkte RIDs Beschreibung<br />
DOMAIN_GROUP_RID_ADMINS Administratives Domänenbenutzerkonto<br />
DOMAIN_GROUP_RID_CONTROLLERS Gruppe Domänencontroller<br />
DOMAIN_GROUP_RID_CERT_ADMINS Gruppe Zertifikatherausgeber<br />
DOMAIN_GROUP_RID_SCHEMA_ADMINS Gruppe Schema-Admins<br />
DOMAIN_GROUP_RID_ENTERPRISE_ADMINS Gruppe Organisations-Admins<br />
DOMAIN_GROUP_RID_POLICY_ADMINS Gruppe Richtlinien-Ersteller-Besitzer<br />
DOMAIN_ALIAS_RID_ADMINS Administratives lokales Benutzerkonto<br />
DOMAIN_ALIAS_RID_POWER_USERS Gruppe Hauptbenutzer<br />
DOMAIN_ALIAS_RID_ACCOUNT_OPS Gruppe Konten-Operatoren, nur für <strong>Server</strong><br />
DOMAIN_ALIAS_RID_SYSTEM_OPS Gruppe <strong>Server</strong>-Operatoren, nur für <strong>Server</strong><br />
DOMAIN_ALIAS_RID_PRINT_OPS Gruppe Druck-Operatoren, nur für <strong>Server</strong><br />
DOMAIN_ALIAS_RID_BACKUP_OPS Gruppe Sicherungs-Operatoren<br />
DOMAIN_ALIAS_RID_RAS_SERVERS Gruppe RAS- und IAS-<strong>Server</strong><br />
DOMAIN_ALIAS_RID_PREW2KCOMPACCESS Gruppe Prä-<strong>Windows</strong> 2000 kompatibler Zugriff<br />
DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS Gruppe Netzwerkkonfigurations-Operatoren<br />
DOMAIN_ALIAS_RID_CRYPTO_OPERATORS Gruppe Kryptografie-Operatoren
So funktioniert die Tokenfilterung 93<br />
So funktioniert die Tokenfilterung<br />
Wenn sich ein Benutzer an einem <strong>Windows</strong> Vista- oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Computer<br />
anmeldet, untersucht das Betriebssystem die RIDs (Relative ID) und Privilegien des Benutzers.<br />
Der Benutzer erhält zwei Token (gefiltert und vollständig), sofern sein Konto irgendeine<br />
der RIDs besitzt, die in Tabelle 4.1 aufgeführt sind, oder irgendeines der Privilegien aus<br />
Tabelle 4.2.<br />
Tabelle 4.2 UAC-Liste der eingeschränkten <strong>Windows</strong>-Privilegien<br />
Eingeschränkte<br />
<strong>Windows</strong>-Privilegien<br />
Beschreibung<br />
SeCreateTokenPrivilege Wird benötigt, um ein primäres Token anzulegen.<br />
SeTcbPrivilege Legt fest, dass das Subjekt Mitglied der vertrauenswürdigen Computerbasis ist.<br />
SeTakeOwnershipPrivilege Kann den Besitz eines Objekts übernehmen, ohne DACL-Zugriff zu haben.<br />
SeBackupPrivilege Erforderlich, um systemweite Datensicherungsaufgaben durchzuführen.<br />
SeRestorePrivilege Erforderlich, um systemweite Wiederherstellungsaufgaben durchzuführen.<br />
SeDebugPrivilege Kann den Arbeitsspeicher eines Prozess debuggen, dessen Besitzer ein anderes<br />
Konto ist.<br />
SeImpersonatePrivilege Erforderlich, um die Identität eines Clients nach der Authentifizierung anzunehmen.<br />
SeRelabelPrivilege Erforderlich, um die verbindliche Integritätsebene eines Objekts zu ändern.<br />
Beim gefilterten Standardbenutzertoken werden alle <strong>Windows</strong>-Privilegien außer den <strong>Windows</strong>-Standardprivilegien<br />
entfernt, die in Tabelle 4.3 aufgeführt sind.<br />
Tabelle 4.3 UAC-Liste der <strong>Windows</strong>-Standardprivilegien<br />
<strong>Windows</strong>-Standardprivilegien Beschreibung<br />
SeChangeNotifyPrivilege Erforderlich, um Benachrichtigungen über Änderungen an Dateien oder Ordnern<br />
zu empfangen.<br />
SeShutdownPrivilege Erforderlich, um ein System im Remotezugriff herunterzufahren.<br />
SeUndockPrivilege Erforderlich, um ein Notebook aus der Dockingstation zu entfernen.<br />
SeReserveProcessorPrivilege Erforderlich, um das Benutzerprozessorprivileg zu ändern.<br />
SeTimeZonePrivilege Erforderlich, um die Zeitzone des Computers zu verstellen.<br />
Beim gefilterten Zugriffstoken sind alle RIDs aus Tabelle 4.1 (sofern vorhanden) als USE_<br />
FOR_DENY_ONLY markiert. <strong>Die</strong> Privilegien aus Tabelle 4.2 werden entfernt. Das unveränderte<br />
vollständige Administrator-Zugriffstoken ist mit dem gefilterten Zugriffstoken verknüpft.<br />
Es wird benutzt, wenn versucht wird, Anwendungen mit einem vollständigen Administrator-<br />
Zugriffstoken auszuführen.<br />
Weitere Informationen über RIDs finden Sie in Kapitel 1, »Subjekte, Benutzer und andere<br />
Akteure«, weitere Informationen über <strong>Windows</strong>-Privilegien in Kapitel 3, »Objekte: Was Sie<br />
wollen«.
94 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
Komponenten der Benutzerkontensteuerung<br />
Benutzer nehmen die UAC in erster Linie als Anhebungseingabeaufforderung wahr. Aber<br />
obwohl dieser Teil am deutlichsten sichtbar ist, ist es nicht der wichtigste Teil der UAC. <strong>Die</strong><br />
UAC umfasst in Wirklichkeit eine ganze Reihe von Komponenten, die erst in ihrer Kombination<br />
bewirken, dass mehr Benutzer als Nicht-Administratoren arbeiten, was letztendlich<br />
das Ziel der UAC ist. <strong>Die</strong>ser Abschnitt beschreibt die verschiedenen Komponenten der<br />
UAC. Wir beginnen mit den verschiedenen Typen von Anhebungsdialogen.<br />
Benutzeroberfläche der Benutzerkontensteuerung<br />
<strong>Die</strong> deutlichsten Auswirkungen auf die Benutzerzufriedenheit zeigen sich bei Benutzern, die<br />
Mitglieder der lokalen Gruppe Administratoren sind. Standardbenutzer erhalten durch die<br />
Benutzerkontensteuerung die Fähigkeit, administrative Aufgaben auszuführen, ohne sich<br />
abmelden zu müssen. <strong>Die</strong> Eingabeaufforderung für Standardbenutzer sieht ganz ähnlich aus<br />
wie die administrative Eingabeaufforderung, allerdings müssen Standardbenutzer ein Kennwort<br />
eingeben.<br />
<strong>Die</strong> Eingabeaufforderung für Anmeldeinformationen<br />
Mit Ausnahme des integrierten Kontos Administrator starten in <strong>Windows</strong> Vista und <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> alle Benutzer ihre Anwendungen ohne Administratorprivilegien. Wenn<br />
eine bestimmte Aufgabe Administratorprivilegien erfordert, bekommt der interaktive Standardbenutzer<br />
eine Anhebungseingabeaufforderung angezeigt, in der er seine Anmeldeinformationen<br />
eingeben muss (Abbildung 4.1). Dort muss er einen gültigen Benutzernamen<br />
und das zugehörige Kennwort eines Benutzers angeben, der Mitglied der lokalen Gruppe<br />
Administratoren ist.<br />
Abbildung 4.1 Wenn ein Standardbenutzer eine administrative Aktion ausführen will, bekommt<br />
er eine Eingabeaufforderung angezeigt, in der er Anmeldeinformationen eingeben muss
Komponenten der Benutzerkontensteuerung 95<br />
<strong>Die</strong> Zustimmungs-Eingabeaufforderung<br />
In der Standardeinstellung wird die Zustimmungs-Eingabeaufforderung (Abbildung 4.2)<br />
angezeigt, wenn ein Benutzer, der Mitglied der lokalen Gruppe Administratoren ist, versucht,<br />
eine Aufgabe durchzuführen, die Administratorprivilegien erfordert. <strong>Die</strong>se Zustimmungs-Eingabeaufforderung<br />
bekommen nur lokale Administratoren angezeigt, die im<br />
Administratorbestätigungsmodus arbeiten.<br />
Abbildung 4.2 Ein Administrator bekommt eine Zustimmungs-Eingabeaufforderung<br />
angezeigt, wenn er versucht, eine administrative Aktion auszuführen<br />
Damit die Benutzer sinnvolle Entscheidungen treffen können, verwenden die UAC-Anhebungsaufforderungen<br />
Farbcodes und weisen mit unterschiedlichen Texten auf das potenzielle<br />
<strong>Sicherheit</strong>srisiko einer Anwendung hin. Zum Beispiel weisen das vierfarbige Schildsymbol<br />
auf blau-grünem Hintergrund und der Text in Abbildung 4.2 darauf hin, dass eine <strong>Windows</strong><br />
Vista- oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Anwendung administrativen Zugriff braucht. Das ist zum<br />
Beispiel bei der Microsoft Management Console der Fall.<br />
Wenn eine Anwendung versucht, unter dem vollständigen Zugriffstoken eines Administrators<br />
zu laufen, analysieren <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> die ausführbare Datei<br />
und ermitteln ihren Herausgeber. Anhand dieser Informationen legen sie fest, welcher Dialog<br />
angezeigt wird.<br />
<strong>Die</strong> Abbildungen 4.3 bis 4.5 zeigen verschiedene Eingabeaufforderungen, die sich jeweils in<br />
Farbe und Text unterscheiden. Zum Beispiel weisen in Abbildung 4.3 das gelbe Schildsymbol<br />
auf grauem Hintergrund und der Text darauf hin, dass die Anwendung, die administrativen<br />
Zugriff benötigt, Authenticode-signiert ist und auf dem lokalen Computer als vertrauenswürdig<br />
gilt; ein Beispiel ist der Microsoft Firewall-Client für ISA <strong>Server</strong>. In Abbildung 4.4<br />
bedeuten das gelbe Schildsymbol vor gelbem Hintergrund und der Text, dass die Anwendung,<br />
die administrativen Zugriff braucht, nicht identifiziert werden konnte und keine gültige<br />
Authenticode-Signatur vom Herausgeber hat; überlegen Sie in einem solchen Fall genau,<br />
ob Sie es erlauben sollten, die Anwendung auszuführen. Und in Abbildung 4.5 weisen das<br />
rote Schildsymbol auf rotem Hintergrund und der Text darauf hin, dass die Anwendung, die<br />
administrativen Zugriff braucht, von einem explizit blockierten oder nichtvertrauenswürdigen<br />
Herausgeber stammt. Ein Administrator kann das Signaturzertifikat eines Herausgebers<br />
in den Speicher Nicht vertrauenswürdige Zertifikate des lokalen Computers legen, um diesen<br />
Herausgeber zu blockieren. <strong>Die</strong>se Einstellung kann auch über Gruppenrichtlinien konfiguriert<br />
werden.
96 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
Abbildung 4.3 <strong>Die</strong>se UAC-Eingabeaufforderung wird angezeigt, wenn<br />
die Anwendung, die administrativen Zugriff braucht, mit Authenticode signiert<br />
ist und auf dem lokalen Computer als vertrauenswürdig eingestuft wird<br />
Abbildung 4.4 <strong>Die</strong>se UAC-Eingabeaufforderung wird angezeigt, wenn<br />
die Anwendung, die administrativen Zugriff braucht, nicht identifiziert werden<br />
kann und keine gültige Authenticode-Signatur für den Herausgeber hat<br />
Abbildung 4.5 <strong>Die</strong>se UAC-Eingabeaufforderung wird angezeigt,<br />
wenn die Anwendung, die administrativen Zugriff braucht, von einem<br />
explizit blockierten oder nichtvertrauenswürdigem Herausgeber stammt<br />
<strong>Die</strong> UAC-Dialogfelder zeigen auch unterschiedliche Details zu Name und Pfad der ausführbaren<br />
Datei an, je nachdem, welche Vertrauensebene die Authenticode-Signatur des<br />
Herausgebers hat. Zum Beispiel versucht der Benutzer in Abbildungen 4.3 und 4.5, dieselbe
Komponenten der Benutzerkontensteuerung 97<br />
Anwendung zu starten. Der Unterschied besteht darin, dass der Herausgeber in Abbildung<br />
4.3 als vertrauenswürdig eingestuft ist, in Abbildung 4.5 dagegen explizit blockiert ist. Wenn<br />
ein Herausgeber als vertrauenswürdig gilt, ändert sich nicht nur die Farbe des Dialogfelds,<br />
sondern auch der angezeigte Text klingt viel positiver.<br />
In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bedeutet das Schildsymbol aus Abbildung 4.6,<br />
dass die UAC eine Eingabeaufforderung für die Autorisierung anzeigt, falls der Benutzer die<br />
Ausführung des entsprechenden Steuerelements oder Programms genehmigt.<br />
Abbildung 4.6 Das Schildsymbol kennzeichnet in <strong>Windows</strong> Vista<br />
und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> eine administrative Aktion<br />
Manche Systemsteuerungskomponenten, zum Beispiel Datum und Uhrzeit, enthalten sowohl<br />
Administrator- als auch Standardbenutzeroperationen. Zum Beispiel können Standardbenutzer<br />
die Uhrzeit ablesen und die Zeitzone ändern, aber um die lokale Systemzeit zu ändern,<br />
ist ein vollständiges Administrator-Zugriffstoken nötig (Abbildung 4.7). Das hat unter anderem<br />
den Grund, dass ein Benutzer, der die Systemzeit ändert, die Reihenfolge der Ereignisse<br />
im Ereignisprotokoll verändern oder es dem Computer unmöglich machen kann, sich bei<br />
einer <strong>Windows</strong>-Domäne zu authentifizieren.<br />
Abbildung 4.7 Das Systemsteuerungsmodul Datum und Uhrzeit dient dazu,<br />
die lokale Computeruhr und die Zeitzone zu konfigurieren<br />
Anwendungsinformationsdienst<br />
Der Anwendungsinformationsdienst (Application Information Service, AIS) ist ein neuer<br />
Systemdienst in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. Er steuert den Start von Programmen,<br />
die zum Ausführen erhöhte Privilegien, beschränkte Rechte oder privilegierte<br />
Integritätsebenen benötigen. AIS ist die Komponente, die diese Prozesse tatsächlich startet
98 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
und mit dem richtigen Token verknüpft. In gewisser Weise ist AIS das Herz der UAC. Beachten<br />
Sie, dass AIS im abgesicherten Modus deaktiviert ist; daher melden sich Benutzer,<br />
die Mitglieder der lokalen Gruppe Administratoren sind, mit ihren vollständigen administrativen<br />
Token an. <strong>Windows</strong> verwendet diesen Ansatz, weil der abgesicherte Modus ohnehin<br />
nur für Wiederherstellung und Wartung genutzt werden sollte.<br />
Datei- und Registrierungsvirtualisierung<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> führen eine Datei- und Registrierungsvirtualisierung<br />
durch. <strong>Die</strong>s ist eine neue Anwendungskompatibilitätstechnologie, die Probleme mit<br />
alten Anwendungen beseitigen soll, die ein Administratorzugriffstoken für die Ausführung<br />
benötigen. <strong>Die</strong> Virtualisierung hilft, diese Anwendungen lauffähig zu machen, auch wenn<br />
der Hersteller keine Änderung vornimmt. Eine große Zahl von alten Anwendungen, die<br />
bisher ohne Administratorzugriffstoken nicht lauffähig waren, funktioniert nun in <strong>Windows</strong><br />
Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. Dafür ist die Virtualisierung verantwortlich.<br />
Wenn eine alte Anwendung, die unter einem gefilterten Standardbenutzer-Zugriffstoken<br />
läuft, versucht, in ein geschütztes Verzeichnis wie zum Beispiel Program Files zu schreiben,<br />
bekommt die Anwendung eine virtualisierte Ansicht der Ressource präsentiert, die sie zu<br />
ändern versucht. <strong>Die</strong> virtualisierte Kopie wird unter dem Profil (Registrierung) des Benutzers<br />
verwaltet. Jeder Benutzer hat eine völlig unabhängige Kopie der virtualisierten Datei.<br />
Das bedeutet, dass zwei Benutzer, die auf demselben Computer dasselbe Spiel spielen, möglicherweise<br />
nicht dieselbe Bestenliste angezeigt bekommen, weil jeder Benutzer seine eigene<br />
virtualisierte Ansicht der Datei %ProgramFiles%\Spiel\highscores.txt zu sehen bekommt.<br />
Daher müssen IT-Administratoren die Datei- und Registrierungsvirtualisierung verstehen. In<br />
manchen Fällen ist es nötig, die Virtualisierungseinstellungen innerhalb des Unternehmens<br />
anzupassen, um Anwendungskompatibilitätsprobleme zu beseitigen. <strong>Die</strong> folgenden Abschnitte<br />
beschreiben die Datei- und Registrierungsvirtualisierung.<br />
Dateivirtualisierung<br />
Dateivirtualisierung soll Probleme lösen, die entstehen, wenn eine Anwendung Dateien<br />
anlegen oder ändern muss, für die nur Administratoren Schreibzugriff haben. Das kann zum<br />
Beispiel eine Konfigurationsdatei in einem geschützten Speicherort wie %ProgramFiles%,<br />
%ProgramData% oder %SystemRoot% sein. Wird ein solches Programm unter einem gefilterten<br />
Standardbenutzertoken ausgeführt, kann das zu unerwarteten Fehlern führen. In manchen<br />
Fällen kann das Programm überhaupt nicht ausgeführt werden, weil es nicht auf unbedingt<br />
benötigte Dateien oder Registrierungsschlüssel zugreifen kann.<br />
Wenn ein Programm in einen geschützten Systemspeicherort schreibt, wird die Operation<br />
vom Dateivirtualisierungsfiltertreiber (%SystemRoot%\System32\Drivers\Luafv.sys) »abgefangen«<br />
und auf einen benutzerspezifischen Speicherort innerhalb des Verzeichnisses VirtualStore<br />
umgeleitet, das in %LocalAppData%\VirtualStore liegt. Wenn das Programm die<br />
Datei später liest, fängt Luafv.sys die Operation wieder ab und leitet sie erneut auf den virtuellen<br />
Speicher des Benutzers um. Falls die Datei nicht im virtuellen Speicher gefunden wird,<br />
ruft Luafv.sys den nichtvirtualisierten Speicherort ab. Weil die Dateivirtualisierung automatisch<br />
durchgeführt wird, glaubt das Programm, es hätte erfolgreich in %ProgramFiles%\<br />
geschrieben. Aus <strong>Sicherheit</strong>sgründen erlaubt die Dateivirtualisierung<br />
standardmäßig keine Umleitung bekannter ausführbarer Dateitypen wie .exe, .dll, .sys, .bat<br />
und .cmd. Falls das Programm aufgrund von Anwendungskompatibilitätseinschränkungen
Komponenten der Benutzerkontensteuerung 99<br />
eine .bat-Datei virtualisieren muss, können Sie den Dateivirtualisierungsfilter so konfigurieren,<br />
dass dies unterstützt wird. <strong>Die</strong> folgenden Beispiele demonstrieren, wie Sie die Dateivirtualisierung<br />
konfigurieren.<br />
Hinweis Der Registrierungszweig FileList ist in der Standardeinstellung nicht vorhanden. Sie müssen ihn<br />
von Hand erstellen, um die Dateivirtualisierung zu konfigurieren.<br />
Hier ein Beispielszenario: Ein Unternehmen braucht eine alte Buchhaltungsanwendung, die<br />
eine Protokolldatei in den eingeschränkten Programmordner der Anwendung schreibt. Um<br />
die Virtualisierung für den Ordner C:\Programme\ des Buchhaltungsprogramms<br />
zu aktivieren, müssen Sie unter dem folgenden Registrierungsschlüssel einen<br />
neuen DWORD-Eintrag namens Exclude erstellen und auf den Wert 0 setzen:<br />
[HKLM\SYSTEM\CurrentControlSet\Services\luafv\Parameters\FileList\Device\\<br />
]<br />
Ein anderes Szenario: Ein Unternehmen zwingt alle Benutzer, ihre Daten in einem bestimmten<br />
Speicherort abzulegen, indem es den Benutzern die Schreibberechtigung für alle Speicherorte<br />
außer dem gewünschten Datensicherungsort entzieht. Wenn die Virtualisierung<br />
aktiviert ist, kann ein Benutzer Daten potenziell an jedem Speicherort ablegen, für den die<br />
Virtualisierung eingeschaltet ist. Um die Virtualisierung für den Ordner C:\Programme\<br />
zu deaktivieren, können Sie im folgenden Registrierungsschlüssel<br />
einen neuen DWORD-Wert namens Exclude erstellen und auf 1 setzen:<br />
[HKLM\SYSTEM\CurrentControlSet\Services\luafv\Parameters\FileList\Device\\<br />
Program Files\AnwendungsnameY]<br />
Ein letztes Szenario: Ein Unternehmen nutzt eine alte Buchhaltungsanwendung, die eine<br />
.bat-Datei in den eingeschränkten Programmordner der Anwendung schreibt. Um die Virtualisierung<br />
für Dateien mit der Erweiterung .bat zu aktivieren, müssen Sie unter dem folgenden<br />
Registrierungsschlüssel einen neuen REG_MULTI_SZ-Wert namens ExcludedExtensionsRemove<br />
erstellen und als Wert »bat« eintragen:<br />
[HKLM\SYSTEM\CurrentControlSet\Services\luafv\Parameters]<br />
Hinweis Sie können sich virtuelle Dateien und Ordner ansehen, indem Sie im <strong>Windows</strong>-Explorer den<br />
virtualisierten Dateispeicherort öffnen und in der Explorer-Symbolleiste auf Kompatibilitätsdateien klicken.<br />
Registrierungsvirtualisierung<br />
Registrierungsvirtualisierung ähnelt der Dateivirtualisierung, betrifft aber Registrierungsschlüssel<br />
unter HKLM\SOFTWARE. <strong>Die</strong>ses Feature erlaubt Anwendungen, die Konfigurationsinformationen<br />
in HKLM\SOFTWARE speichern müssen, weiterhin lauffähig zu bleiben,<br />
wenn sie ohne administrative Privilegien ausgeführt werden. <strong>Die</strong> Schlüssel und Daten werden<br />
in HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE umgeleitet. Der Zweig VirtualStore<br />
wird erst bei Bedarf erstellt, wenn zum ersten Mal eine Anwendung Virtualisierung nutzt.<br />
Wie bei der Dateivirtualisierung verfügt jeder Benutzer über ein virtualisiertes Exemplar der<br />
Werte, die eine Anwendung in HKLM gespeichert hat. Falls ein Programm aufgrund von<br />
Anwendungskompatibilitätseinschränkungen die Registrierungsvirtualisierung konfigurieren<br />
muss, wird dies unterstützt. <strong>Die</strong> folgenden Beispiele demonstrieren, wie Sie die Registrierungsvirtualisierung<br />
konfigurieren.
100 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
Konfigurieren der Registrierungsvirtualisierung zum Verbessern<br />
der Anwendungskompatibilität<br />
Ein Beispielszenario: Ein Unternehmen will die Virtualisierung von Registrierungswerten<br />
unter dem Schlüssel DontVirtMe verhindern. Führen Sie dazu an einer Eingabeaufforderung<br />
mit erhöhten Rechten den folgenden Befehl aus:<br />
Reg.exe flags HKLM\Software\DontVirtMe SET DONT_VIRTUALIZE<br />
Ein anderes Beispiel: Ein Unternehmen will die Virtualisierung aller Registrierungswerte<br />
und Unterschlüsselwerte unter dem übergeordneten Registrierungsschlüssel DontVirtMe<br />
verhindern. Führen Sie dazu an einer Eingabeaufforderung mit erhöhten Rechten den folgenden<br />
Befehl aus:<br />
Reg.exe flags HKLM\Software\DontVirtMe RECURSE_FLAG DONT_VIRTUALIZE<br />
<strong>Die</strong> Virtualisierung erlaubt es zwar, die große Mehrheit von Anwendungen auszuführen, die<br />
vor <strong>Windows</strong> Vista entwickelt wurden, aber dies ist eine Übergangs-, keine Dauerlösung.<br />
Außerdem gibt es einige Anwendungen, die nicht lauffähig sind. Das sind zum Beispiel<br />
Anwendungen, die gezielt prüfen, ob bestimmte Benutzerprivilegien vorhanden sind. Zum<br />
Beispiel prüfen viele Prozesssteuerungsanwendungen, ob der Benutzer ein Administrator ist;<br />
sie beenden sich sofort, wenn das nicht der Fall ist. Sie können solche Anwendungen unter<br />
<strong>Windows</strong> Vista ausführen, indem Sie ein Anwendungsmanifest hinzufügen, das aussagt,<br />
dass die Anwendung mit administrativen Privilegien ausgeführt werden muss, und die Anwendung<br />
dann erneut bereitstellen. Entwickler sollten alle Anwendungen so anpassen, dass<br />
sie die Anforderungen des <strong>Windows</strong> Vista- und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Logoprogramms<br />
erfüllen, statt sich auf Datei- und Registrierungsvirtualisierung zu verlassen.<br />
Manifeste und angeforderte Ausführungsebenen<br />
Anwendungen, die unter <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> laufen, können mithilfe<br />
von Anwendungsmanifesten Anforderungen an das Betriebssystem während der Laufzeit<br />
beschreiben oder deklarieren. Administrative Anwendungen können ihre Privilegienanforderungen<br />
im Anwendungsmanifest deklarieren, das System fordert dann beim Benutzer die<br />
entsprechende Genehmigung an. <strong>Die</strong> meisten administrativen Anwendungen, die vor <strong>Windows</strong><br />
Vista entwickelt wurden, laufen aber auch problemlos ohne Anpassungen, wenn sie<br />
keinen Eintrag im Anwendungsmanifest haben. Das ist den umfangreichen Anwendungskompatibilitätskorrekturen<br />
in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zu verdanken, die<br />
allerdings nur wirksam werden, wenn die UAC aktiviert ist. Anwendungskompatibilitätskorrekturen<br />
ermöglichen es, Anwendungen auszuführen, die ohne administrativen Zugriff normalerweise<br />
nicht lauffähig wären. Stellen Sie sich zum Beispiel ein Spiel vor, das beim Start<br />
prüft, ob der Benutzer Mitglied der lokalen Gruppe Administratoren ist. Wird dieses Programm<br />
unter einem gefilterten Standardbenutzer-Zugriffstoken ausgeführt, schlägt diese<br />
Prüfung fehl, sodass die Anwendung sich beendet. Anhand der Anwendungskompatibilitätsdatenbank<br />
kann das Betriebssystem feststellen, dass die Anwendung mit einem vollständigen<br />
Token ausgeführt werden muss, und beim Benutzer die entsprechende Erlaubnis anfordern.<br />
Oder die Anwendungskompatibilitätsdatenbank verrät, dass die Anwendung auch ohne<br />
vollständiges Token einwandfrei läuft. Dann spiegelt das System der Anwendung nur vor,<br />
dass sie mit einem vollständigen Token läuft. <strong>Die</strong>se Arten von Anwendungskompatibilitätskorrekturen<br />
werden als Shims (dt. Ausgleichsscheibe) bezeichnet.
Komponenten der Benutzerkontensteuerung 101<br />
Alle Anwendungen, die die Anforderungen des <strong>Windows</strong> Vista- und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<br />
Logos erfüllen, müssen ein gültiges Manifest haben, in dem die geforderte Ausführungsebene<br />
definiert ist. <strong>Die</strong> Anwendung deklariert ihre Zugriffsanforderungen mit dem Attribut<br />
requestedExecutionLevel. Falls die Anwendung administrativen Zugriff benötigt, gibt das<br />
Anwendungsmanifest die geforderte Ausführungsebene requireAdministrator an. So ist<br />
sichergestellt, dass das System dieses Programm als administrative Anwendung erkennt und<br />
die erforderliche Eingabeaufforderung für die Privilegienanhebung anzeigt. Eine Anwendung<br />
kann abhängig vom Benutzer auch unterschiedliche Funktionalität haben: eine Version<br />
für Administratoren und eine für Standardbenutzer. Zum Beispiel ist die Microsoft Management<br />
Console (MMC) mit highestAvailable markiert. Falls ein Standardbenutzer die MMC<br />
ausführt, startet sie mit Standardbenutzerprivilegien und zeigt keine Eingabeaufforderung<br />
an. Falls der Benutzer ein gefiltertes Zugriffstoken hat, zum Beispiel ein lokaler Administrator<br />
oder ein Netzwerkoperator, zeigt das Betriebssystem eine Eingabeaufforderung an, mit<br />
der er die MMC mit den höchstmöglichen verfügbaren Privilegien starten kann. So kann ein<br />
Administrator eine andere Zugriffsebene haben als der Netzwerkoperator oder der Standardbenutzer.<br />
Installererkennungstechnologie<br />
Installationsprogramme sind Anwendungen, die Software bereitstellen. <strong>Die</strong> meisten davon<br />
schreiben in Systemverzeichnisse und Computerregistrierungsschlüssel. <strong>Die</strong>se geschützten<br />
Systemspeicherorte erfordern normalerweise Administratorprivilegien, das bedeutet, dass<br />
Standardbenutzer keinen ausreichenden Zugriff haben, um die meisten Programme zu installieren.<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> erkennen mit heuristischen Methoden<br />
Installationsprogramme, Updater und Deinstallationsprogramme, die Administratorzugriff<br />
erfordern. <strong>Die</strong> Installererkennung ist eine Schlüsselkomponente im UAC-Entwurf. Sie sorgt<br />
dafür, dass die passende Eingabeaufforderung angezeigt wird, und verhindert, dass Installationen<br />
ohne Wissen des Benutzers ausgeführt werden.<br />
<strong>Die</strong> Installererkennung gilt nur für folgende Elemente:<br />
Ausführbare 32-Bit-Dateien<br />
Anwendungen ohne requestedExecutionLevel<br />
Interaktive Prozesse, die als Standardbenutzer ausgeführt werden, während die UAC<br />
aktiviert ist<br />
Das Betriebssystem stellt mithilfe heuristischer Methoden fest, ob eine Anwendung ein<br />
Installer ist. Dabei werden folgende Attribute ausgewertet:<br />
Schlüsselwörter im Dateiname, zum Beispiel Install, Setup, Update und äquivalente<br />
Wörter in anderen Sprachen<br />
Schlüsselwörter in den folgenden Versionsressourcenfeldern der ausführbaren Datei:<br />
Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name<br />
und Export Name<br />
Schlüsselwörter im Side-by-side-Manifest, das in die ausführbare Datei eingebettet ist<br />
Schlüsselwörter in bestimmten StringTable-Einträgen, die in die ausführbare Datei eingebunden<br />
sind<br />
Schlüsselattribute in den RC-Daten, die mit der ausführbaren Datei verknüpft sind
102 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
UIPI<br />
Falls Sie zum Beispiel eine Anwendung namens Setup.exe oder Install.exe haben, wird sie<br />
als Installer erkannt, sodass automatisch eine Eingabeaufforderung angezeigt wird. Allgemeine<br />
Informationen und einen Überblick zum Microsoft <strong>Windows</strong> Installer finden Sie im<br />
MSDN unter http://go.microsoft.com/fwlink/?LinkId=30197.<br />
User Interface Privilege Isolation (UIPI, Benutzeroberflächen-Rechteisolierung) ist eine<br />
neue Technologie in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. Sie hilft dabei, Prozesse, die<br />
auf Administratorebene laufen, von Prozessen zu isolieren, die auf demselben interaktiven<br />
Desktop mit geringeren Privilegien ausgeführt werden. UIPI verhindert, dass eine Anwendung<br />
mit geringeren Privilegien <strong>Windows</strong>-Nachrichten missbraucht, um Eingaben an einen<br />
Prozess mit höheren Privilegien zu senden. Wenn ein Prozess Eingaben an einen anderen<br />
sendet, kann er Eingaben in den anderen »einschleusen«, ohne dass der Benutzer dafür seine<br />
Zustimmung gegeben hat.<br />
UIPI definiert einen Satz erlaubter <strong>Windows</strong>-Nachrichtenoperationen, die von den höchsten<br />
der unterschiedlichen Prozessebenen erlaubt werden. Höhere Privilegebenen können <strong>Windows</strong>-Nachrichten<br />
an Anwendungen senden, die auf niedrigeren Ebenen laufen, aber umgekehrt<br />
können niedrigere Ebenen bestimmte <strong>Windows</strong>-Nachrichten nicht an Anwendungsfenster<br />
senden, die unter höheren Ebenen laufen. UIPI hat keinen Einfluss auf die Funktion<br />
oder das Verhalten des Fensternachrichtenaustauschs zwischen Anwendungen derselben<br />
Privilegebene. UIPI kommt ins Spiel, wenn ein Benutzer, der Mitglied der Gruppe Administratoren<br />
ist, auf demselben interaktiven Desktop Anwendungen als Administrator und Standardbenutzer<br />
ausführt.<br />
Anhebungsaufforderungen auf dem sicheren Desktop<br />
Eingabeaufforderungen für Anmeldeinformationen und Anhebungszustimmung werden in<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> standardmäßig auf dem sicheren Desktop angezeigt.<br />
Jede Anwendung muss auf einem Desktop laufen, und jeder interaktive Benutzer bekommt<br />
bei der Anmeldung einen Desktop zugewiesen, auf dem alle seine Anwendungen<br />
laufen. Der sichere Desktop wird vom Betriebssystem für <strong>Die</strong>nste und kritische Benutzeroberflächen<br />
verwendet, zum Beispiel die Anmeldungsoberfläche.<br />
Indem das Betriebssystem die Anhebungseingabeaufforderung auf dem sicheren Desktop<br />
anzeigt, garantiert das Betriebssystem, dass die dort angezeigten Informationen nicht manipuliert<br />
werden können. Wenn eine ausführbare Datei eine Anhebung anfordert, wird der<br />
Benutzer von seinem interaktiven Desktop auf den sicheren Desktop umgeschaltet. Der<br />
sichere Desktop zeichnet einen abgeblendeten Hintergrund des Benutzerdesktops und zeigt<br />
hervorgehoben die Anhebungseingabeaufforderung an. Wenn der Benutzer auf Fortsetzen<br />
oder Abbrechen klickt, schaltet der Desktop automatisch zurück zum interaktiven Desktop<br />
des Benutzers. Malware kann zwar den interaktiven Desktop übermalen und eine Imitation<br />
des sicheren Desktops anzeigen (das sogenannte Spoofing), aber selbst wenn der Benutzer<br />
eine solche gefälschte Eingabeaufforderung autorisiert, bekommt die Malware keine Anhebung.<br />
Falls die UAC so konfiguriert ist, dass sie Anmeldeinformationen vom Benutzer anfordert,<br />
könnte Malware, die eine entsprechende Eingabeaufforderung vortäuscht, die Anmeldeinformationen<br />
des Benutzers ausspähen. <strong>Die</strong> Malware kann diese Anmeldeinformationen<br />
aber im Remotezugriff nicht nutzen, um sich Administratorprivilegien zu verschaffen.<br />
Malware gewinnt letztlich also überhaupt nichts dadurch, dass sie das Dialogfeld für den
Komponenten der Benutzerkontensteuerung 103<br />
Administratorbestätigungsmodus fälscht. Malware kann Benutzername und Kennwort nicht<br />
in ein gültiges UAC-Dialogfeld eingeben, das auf dem sicheren Desktop angezeigt wird, und<br />
sie kann nicht Runas.exe verwenden, um einen Prozess mit erhöhten Privilegien auszuführen,<br />
oder ein echtes UAC-Dialogfeld automatisieren.<br />
Remoteunterstützung<br />
In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> kann ein Domänenbenutzer als Standardbenutzer<br />
arbeiten, wobei eine zentrale IT-Gruppe alle Verwaltungsaufgaben erledigt. Microsoft<br />
stellt für unterschiedliche Administrationszwecke einerseits den Remotedesktop (Remote<br />
Desktop, RD) und andererseits die Remoteunterstützung (Remote Assistance, RA) zur Verfügung,<br />
um auf Computer zuzugreifen. RD-Sitzungen sind nützlich, wenn ein Administrator<br />
keine Endbenutzerinteraktion benötigt, aber vollständige Kontrolle über den Remotecomputer<br />
braucht. RA ist nützlich für Diagnose und Problembehandlung, wenn der Endbenutzer<br />
einem IT-Experten sein Problem demonstrieren muss. Auf die RA hat die UAC einige Auswirkungen.<br />
Es ist wichtig, dass Sie diese Auswirkungen kennen.<br />
IT-Experten bekommen es im Zusammenhang mit der RA vor allem mit zwei Problemen zu<br />
tun. Erstens: In der Standardeinstellung verwenden die UAC-Eingabeaufforderungen den<br />
sicheren Desktop, daher kann der Remotebenutzer sie nicht bedienen. Zweitens: Falls die<br />
UAC-Richtlinie Verhalten der Benutzeraufforderung mit erhöhten Rechten für Standardbenutzer<br />
auf die Einstellung Anforderungen für erhöhte Rechte automatisch ablehnen gesetzt<br />
ist, werden Anhebungsanforderungen völlig verweigert.<br />
<strong>Windows</strong> Vista SP1 hat eine neue UAC-Richtlinie, die das Problem mit der Eingabeaufforderung<br />
auf dem sicheren Desktop beseitigen soll: Benutzerkontensteuerung: UIAccess-Anwendungen<br />
können erhöhte Rechte ohne sicheren Desktop anfordern. Wenn diese Richtlinie<br />
konfiguriert ist, deaktiviert AIS dynamisch den sicheren Desktop für Anwendungen mit UI-<br />
Access-Zugriffsebene (zum Beispiel Remoteunterstützung) und aktiviert ihn wieder, sobald<br />
das Programm beendet wurde. Weitere Informationen finden Sie im Abschnitt »Was hat sich<br />
bei der UAC in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista SP1 geändert« weiter unten in<br />
diesem Kapitel.<br />
Falls die Richtlinie Verhalten der Benutzeraufforderung mit erhöhten Rechten für Standardbenutzer<br />
auf Anforderungen für erhöhte Rechte automatisch ablehnen gesetzt ist, kann der<br />
IT-Experte, der die Verbindung über RA herstellt, keine Anwendung mit administrativen<br />
Privilegien starten. Um dieses Problem zu umgehen, kann der IT-Experte mit Runas.exe ein<br />
Eingabeaufforderungsfenster unter seinem eigenen Benutzernamen und dem zugehörigen<br />
Kennwort starten und dort einen Prozess starten, der die Anhebung erfordert. <strong>Die</strong> UAC verwendet<br />
dann die UAC-Eingabeaufforderungsrichtlinie des IT-Experten.<br />
Als IT-Experte können Sie zum Beispiel folgendermaßen vorgehen, um den Registrierungs-<br />
Editor mit Administratorprivilegien auszuführen:<br />
1. Öffnen Sie eine Eingabeaufforderung und geben Sie runas /user:Domäne\ITExperte<br />
cmd.exe ein.<br />
2. Geben Sie im daraufhin geöffneten Eingabeaufforderungsfenster den Befehl regedit.exe<br />
ein.<br />
3. Bestätigen Sie die UAC-Anhebungseingabeaufforderung.
104 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
UAC-Remoteeinschränkungen<br />
Wenn sich ein Administrator im Remotezugriff über die normalen <strong>Windows</strong>-Netzwerkfunktionen<br />
an einem <strong>Windows</strong> Vista- oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Computer anmeldet, arbeitet er<br />
im Administratorbestätigungsmodus, genau wie bei einer lokalen Anmeldung. Um dieses<br />
Verhalten zu ergänzen, beschränkt die UAC die Remoteverwaltung, was Administrator-<br />
Loopback-Angriffe verhindern soll. Außerdem dient dies als Schutz vor böswilliger Software,<br />
die lokal läuft, aber im Remotezugriff administrative Privilegien erlangt. Zum Beispiel<br />
tritt ein Administrator-Loopback auf, wenn ein Benutzer sich mit einem gefilterten Zugriffstoken<br />
anmeldet und Malware dann einfach den Befehl net use \\127.0.0.1\c$ ausführt, um<br />
administrativen Zugriff auf das Dateisystem zu erlangen. Wenn die UAC-Remoteeinschränkungen<br />
aktiviert sind, erhält auch das Loopback nur ein gefiltertes Zugriffstoken, keinen<br />
vollständigen administrativen Zugriff. <strong>Die</strong>ses Verhalten arbeitet jeweils anders für unterschiedliche<br />
Typen von Benutzerkonten, wie in den folgenden Abschnitten beschrieben.<br />
Lokale Benutzerkonten<br />
Nehmen wir an, ein Benutzer arbeitet lokal auf dem <strong>Server</strong> und ist Mitglied der lokalen<br />
Gruppe Administratoren auf diesem <strong>Server</strong>. Er baut mit net use * \\<strong>Server</strong>\Freigabe eine<br />
Remoteverbindung auf. Anders als bei älteren <strong>Windows</strong>-Versionen ist das Token, das auf<br />
dem <strong>Server</strong> für den Benutzer verwendet wird, in diesem Fall kein vollständiges administratives<br />
Token. Der Benutzer kann auf dem Remotecomputer keine Anhebung durchführen und<br />
keine administrativen Aufgaben erledigen. Falls der Benutzer die Arbeitsstation mit einem<br />
lokalen Konto administrieren will, muss er sich interaktiv am Remotecomputer anmelden,<br />
zum Beispiel über Remoteunterstützung oder Remotedesktop.<br />
Domänenbenutzerkonten<br />
Wenn ein Benutzer, der ein Domänenbenutzerkonto hat, sich im Remotezugriff an einem<br />
Computer anmeldet und Mitglied der lokalen Gruppe Administratoren ist, arbeitet dieser<br />
Domänenbenutzer auf dem Remotecomputer mit einem vollständigen Administrator-Zugriffstoken.<br />
<strong>Die</strong> UAC ist in diesem Fall nicht wirksam.<br />
Verwalten der UAC-Remoteeinschränkungen<br />
Sie können die UAC-Remoteeinschränkungen für lokale Konten deaktivieren und das Verhalten<br />
wie unter <strong>Windows</strong> XP und <strong>Windows</strong> <strong>Server</strong> 2003 einstellen, indem Sie unter dem<br />
folgenden Registrierungsschlüssel einen DWORD-Eintrag namens LocalAccountTokenFilterPolicy<br />
erstellen und auf den Wert 1 setzen:<br />
HKLM\SOFTWARE\Microsoft\<strong>Windows</strong>\CurrentVersion\Policies\system<br />
Zuordnen von Netzlaufwerken im Administratorbestätigungsmodus<br />
Wenn ein Administrator, der im Administratorbestätigungsmodus arbeitet, ein Netzlaufwerk<br />
zuordnet, wird diese Zuordnung nur mit der aktuellen Anmeldesitzung für das aktuelle Prozesszugriffstoken<br />
verknüpft. Falls also ein Benutzer eine Eingabeaufforderung (Cmd.exe)<br />
mit einem gefilterten Zugriffstoken ausführt und darin explizit eine Netzwerkfreigabe zuordnet,<br />
steht diese Netzwerkfreigabe nicht in irgendwelchen angehobenen Cmd.exe-Instanzen<br />
zur Verfügung, die unter einem vollständigen Administrator-Zugriffstoken laufen. Nur<br />
im Fall von UNC-Pfaden werden die Sitzungen automatisch vom System verknüpft.
Komponenten der Benutzerkontensteuerung 105<br />
Sie können einen Registrierungswert definieren, um festzulegen, dass Netzwerkverbindungen<br />
von Prozessen gemeinsam genutzt werden, die mit gefiltertem oder vollständigem Zugriffstoken<br />
laufen. Das gilt aber nur für Mitglieder der Gruppe Administratoren. Wenn Sie<br />
diese Registrierungseinstellung aktivieren und eine Netzwerkressource einem Zugriffstoken<br />
zugeordnet ist, prüft die LSA, ob ein anderes Zugriffstoken mit der aktuellen Benutzersitzung<br />
verknüpft ist. Falls die LSA feststellt, dass es ein verknüpftes Zugriffstoken gibt, fügt<br />
sie die Netzwerkfreigabe zur verknüpften Position hinzu.<br />
Sie können ein verknüpftes Netzlaufwerk aktivieren, indem Sie unter dem folgenden Registrierungsschlüssel<br />
einen DWORD-Eintrag namens EnableLinkedConnections erstellen und<br />
auf den Wert 1 setzen:<br />
HKLM\SOFTWARE\Microsoft\<strong>Windows</strong>\CurrentVersion\Policies\System<br />
Direkt aus der Praxis: Welche Konten können angehoben werden?<br />
Vor Kurzem bat mich eine Freundin, einige Probleme im Zusammenhang mit der Privilegienanhebung<br />
zu beseitigen. Es war ihr nicht möglich, eine Anhebung durchzuführen, um<br />
einige Netzwerkparameter auf ihrem Notebook zu ändern. Das Notebook war ein Domänenmitglied,<br />
aber der Domänencontroller war zu diesem Zeitpunkt nicht verfügbar. Nach<br />
einigen Minuten Problembehandlung notierte ich das folgende Szenario, das meiner Meinung<br />
nach demonstriert, wie verwirrend die UAC bisweilen sein kann und welche Wechselwirkungen<br />
sie mit anderen Features von <strong>Windows</strong> hat:<br />
Der Computer hat den Namen Denise-PC.<br />
Der Computer ist Mitglied der Domäne example.com.<br />
Der Domänencontroller von example.com ist offline. Anders ausgedrückt: Denise-PC<br />
arbeitet ohne Domänenverbindung.<br />
Bisher hat sie sich an Denise-PC nur unter EXAMPLE\Denise angemeldet.<br />
EXAMPLE\Denise ist Mitglied von VORDEFINIERT\Benutzer.<br />
VORDEFINIERT\Administratoren auf Denise-PC hat die Mitglieder VORDEFI-<br />
NIERT\Administrator und DENISE-PC\Denise.<br />
Wenn sie versucht, eine administrative Aktion auszuführen, erhält sie eine Anhebungseingabeaufforderung,<br />
in der sie Anmeldeinformationen eines Administratorkontos<br />
eingeben soll.<br />
Es stehen mehrere Möglichkeiten zur Auswahl, eine Anhebung durchzuführen:<br />
1. Anhebung auf VORDEFINIERT\Administrator<br />
2. Anhebung auf EXAMPLE\Denise<br />
3. Anhebung auf EXAMPLE\Administrator<br />
4. Anhebung auf EXAMPLE\Foo, wobei Foo Mitglied von EXAMPLE\Domänen-<br />
Admins ist<br />
5. Anhebung auf DENISE-PC\Denise<br />
Option 1 schlägt fehl, weil VORDEFINIERT\Administrator in <strong>Windows</strong> Vista standardmäßig<br />
deaktiviert ist, sofern es ein anderes lokales Administratorkonto gibt. Weil<br />
DENISE-PC\Denise ein lokales Administratorkonto ist und auch aktiviert ist, steht<br />
VORDEFINIERT\Administrator nicht zur Verfügung.
106 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
Option 2 schlägt ebenfalls fehl. EXAMPLE\Denise ist nur Mitglied von Benutzer. Es ist<br />
kein Administratorkonto, daher ist keine Anhebung möglich.<br />
Option 3 schlägt fehl, denn obwohl EXAMPLE\Administrator (indirekt) Mitglied von<br />
VORDEFINIERT\Administratoren ist, hat sich dieses Konto noch nie auf Denise-PC angemeldet.<br />
Weil der Computer offline ist, muss die Authentifizierung von Domänenkonten<br />
anhand des Kennwortverifizierers durchgeführt werden. (In Kapitel 2, »Authentifizierung<br />
und Authentifizierungsprotokolle«, finden Sie Informationen zu zwischengespeicherten<br />
Anmeldeinformationen.) Zwischengespeicherte Anmeldeinformationen gibt es nur für<br />
Benutzer, die sich vorher interaktiv angemeldet haben. Daher gibt es keine Daten, anhand<br />
derer EXAMPLE\Administrator authentifiziert werden könnte. Außerdem sollte erwähnt<br />
werden, dass es äußerst leichtsinnig wäre, auf einer Mitgliedarbeitsstation eine Anhebung<br />
auf einen Domänenadministrator durchzuführen. <strong>Die</strong> Gründe sind in Kapitel 14, »Schützen<br />
des Netzwerks«, beschrieben.<br />
Option 4 schlägt aus denselben Gründen fehl wie Option 3.<br />
Option 5 funktioniert. DENISE-PC\Denise ist ein lokales Konto. Daher werden keine<br />
zwischengespeicherten Anmeldeinformationen benötigt. Es ist Mitglied von VOR-<br />
DEFINIERT\Administratoren, daher kann eine Anhebung auf dieses Konto durchgeführt<br />
werden. Und es ist nicht deaktiviert, daher kann eine Anmeldung damit vorgenommen<br />
werden.<br />
Ich meine, dass dieser Bericht gut erklärt, welche Konten für eine UAC-Anhebung genutzt<br />
werden können und welche Beziehung zwischen Domänenkonten, Kennwortverifizierern<br />
und UAC besteht.<br />
Jesper M. Johansson<br />
<strong>Windows</strong> Security MVP<br />
Blockierte Anwendungsanhebungen bei Anmeldung<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> blockieren administrative Anwendungen, die<br />
versuchen, im Anmeldungsstartpfad des Benutzers zu starten. Viele Fremdhersteller legen<br />
Programme in den Anmeldungsstartpfad des Benutzers, um sicherzustellen, dass sie jedes<br />
Mal ausgeführt werden, wenn sich der Benutzer anmeldet. <strong>Die</strong>se Lösung mag bequem sein,<br />
sie verursacht aber oft Anwendungskompatibilitätsprobleme, wenn der Benutzer, der sich<br />
anmeldet, kein Administrator ist, die Anwendung dies aber voraussetzt. <strong>Die</strong>ses Verhalten ist<br />
auch praktisch für Malware, die sich einfach im Anmeldungsstartpfad des Benutzers einnisten<br />
kann. Künftig wird jedes Mal, wenn sich der Benutzer anmeldet, die Malware unbemerkt<br />
mit Administratorzugriff ausgeführt, ohne dass der Benutzer zugestimmt hat. Um dieses<br />
Verhalten zu blockieren, bieten <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> dem Benutzer die<br />
Möglichkeit, die Liste der blockierten Programme zu verwalten. Eine Anhebungsmeldung<br />
benachrichtigt den Benutzer (Abbildung 4.8), und das Symbol in der Taskleiste erlaubt dem<br />
Benutzer, das blockierte Programm auszuführen oder die Verwaltungsoberfläche zu öffnen<br />
(Abbildung 4.9).
Abbildung 4.8 Meldung, dass <strong>Windows</strong> irgendwelche<br />
automatisch startenden Programme blockiert hat<br />
Komponenten der Benutzerkontensteuerung 107<br />
Abbildung 4.9 Über das Taskleistensymbol können blockierte Autostartprogramme<br />
ausgeführt oder entfernt werden<br />
Mit der UAC werden Anwendungen, die Administratorprivilegien benötigen, blockiert, falls<br />
sie von folgenden Orten gestartet werden:<br />
Benutzerspezifischer Autostart-Ordner %UserProfile%\Start Menu\Programs\<br />
Startup<br />
Computerspezifischer Autostart-Ordner %AllUsersProfile%\Start Menu\Programs\<br />
Startup<br />
Benutzerspezifischer RUN-Schlüssel HKEY_USERS\*\Software\Microsoft\<strong>Windows</strong>\<br />
CurrentVersion\Run<br />
Computerspezifischer RUN-Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\<br />
Microsoft\<strong>Windows</strong>\CurrentVersion\Run<br />
Hinweis Der Stern (»*«) in den Registrierungspfaden steht hier für alle <strong>Sicherheit</strong>s-IDs des Benutzers,<br />
inklusive der .Default-SID.<br />
Dabei ist wichtig, dass Gruppenrichtlinien ein Benutzeranmeldeskript unterstützen, das unter<br />
dem höchstmöglichen Zugriffstoken des momentan angemeldeten Benutzers ausgeführt<br />
wird. Falls der Benutzer Mitglied der lokalen Gruppe Administratoren ist, führt das Skript<br />
eine Anhebung durch, ohne dass der Administrator im Administratorbestätigungsmodus eine<br />
Eingabeanforderung angezeigt bekommt.<br />
Konfigurieren der UAC-Kompatibilität für ältere Anwendungen<br />
Der letzte und wichtigste Schritt beim Konfigurieren der UAC besteht darin sicherzustellen,<br />
dass Ihre Software entweder UAC-kompatibel entworfen wurde (das heißt, sie erfüllt die<br />
Logoanforderungen) oder so konfiguriert ist, dass sie unter <strong>Windows</strong> Vista oder <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> läuft.<br />
Neue Anwendungen, die die Anforderungen des <strong>Windows</strong> Vista- und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<br />
Logos erfüllen, müssen entweder unter Standardbenutzerprivilegien laufen oder, wenn es<br />
sich um eine administrative Anwendung handelt, mit einem Anwendungsmanifesteintrag
108 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
markiert sein. Weitere Informationen finden Sie auf der Microsoft <strong>Windows</strong>-Logoseite unter<br />
http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx.<br />
Bei der Bereitstellung von <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> stellen IT-Abteilungen<br />
unter Umständen fest, dass einige vorhandene Unternehmensanwendungen nicht richtig<br />
funktionieren. In den meisten Fällen ist die Ursache eine Anwendungsinkompatibilität aufgrund<br />
der Verbesserungen in den neuen Betriebssystemen. Microsoft stellt ein Application<br />
Compatibility Toolkit zur Verfügung, das dabei hilft, die Ursache für Kompatibilitätsprobleme<br />
aufzuspüren und Anwendungskompatibilitätskorrekturen oder Shims zu erstellen.<br />
Manche Programme müssen unter Umständen administrative Operationen ausführen. Damit<br />
solche Anwendungen in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> unter der UAC richtig<br />
laufen, muss das Programm dem Betriebssystem diese Tatsache bekannt geben, sodass der<br />
Benutzer eine Anhebungsaufforderung angezeigt bekommt, bevor die Anwendung mit<br />
einem vollständigen Administrator-Zugriffstoken ausgeführt wird. Das Application Compatibility<br />
Toolkit 5.0 mit dem Standard User Analyzer bietet die Fähigkeit, Einträge für die<br />
Anwendungskompatibilitätsdatenbank zu testen, erstellen und installieren, wodurch der<br />
Mechanismus zum Markieren der geforderten Ausführungsebene implementiert wird.<br />
Informationen über Anwendungskompatibilität und das Application Compatibility Toolkit 5.0<br />
mit dem Standard User Analyzer finden Sie in TechNet unter http://go.microsoft.com/<br />
fwlink/?LinkId=23302.<br />
UAC-Gruppenrichtlinieneinstellungen<br />
Der folgende Abschnitt beschreibt die 11 UAC-Gruppenrichtlinien, die in <strong>Windows</strong> Vista<br />
und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> unterstützt werden. <strong>Die</strong>se Einstellungen können lokal mit dem<br />
Editor Lokale <strong>Sicherheit</strong>srichtlinie oder im gesamten Unternehmen mithilfe von Gruppenrichtlinien<br />
angewendet werden.<br />
UAC-Richtlinieneinstellungen unter <strong>Sicherheit</strong>soptionen<br />
<strong>Die</strong> folgenden 9 UAC-Einstellungen finden Sie im Gruppenrichtlinien-Editor oder in der<br />
Konsole Lokale <strong>Sicherheit</strong>srichtlinie unter dem Zweig Richtlinien für lokaler Computer\<br />
Computerkonfiguration\<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\Lokale Richtlinien\<strong>Sicherheit</strong>soptionen.<br />
Benutzerkontensteuerung: Administratorbestätigungsmodus für das<br />
integrierte Administratorkonto<br />
<strong>Die</strong>se <strong>Sicherheit</strong>seinstellung steuert das Verhalten des integrierten Kontos Administrator.<br />
Falls Sie das integrierte Konto Administrator für tägliche administrative Aufgaben nutzen,<br />
kann es sinnvoll sein, diese Einstellung zu deaktivieren. In diesem Fall geht Ihnen allerdings<br />
der geschützte Modus des Internet Explorers verloren. Alle Anwendungen laufen als vollständiger<br />
Administrator. In der Standardeinstellung ist diese Richtlinie aktiviert.<br />
Benutzerkontensteuerung: Verhalten der Benutzeraufforderung mit erhöhten<br />
Rechten für Administratoren im Administratorbestätigungsmodus<br />
Wenn eine Operation Administratorprivilegien erfordert, legt diese Richtlinie fest, welche<br />
UAC-Eingabeaufforderung Administratoren im Administratorbestätigungsmodus angezeigt<br />
bekommen. <strong>Die</strong> Standardkonfiguration, in der ein Klick auf Fortsetzen genügt, kann recht
UAC-Gruppenrichtlinieneinstellungen 109<br />
bequem sein, aber manchmal ist es sinnvoller, den Administrator zu zwingen, Anmeldeinformationen<br />
einzugeben. Falls zum Beispiel Mutter und Tochter dasselbe Benutzerkonto<br />
verwenden, kann die Tochter keine administrativen Aufgaben durchführen, wenn sie das<br />
Kennwort nicht weiß. Und in manchen Fällen wollen Administratoren Anhebungsaufforderungen<br />
abschalten, ohne gleich die ganze UAC zu deaktivieren; dann können die erhöhten<br />
Privilegien ohne Anhebungseingabeaufforderung gewährt werden. Auf diese Weise bleibt<br />
der geschützte Modus im Internet Explorer erhalten, aber es müssen keine Anhebungsaufforderungen<br />
mehr bestätigt werden. In der Standardeinstellung hat diese Richtlinie die Einstellung<br />
Aufforderung zur Eingabe der Zustimmung.<br />
Benutzerkontensteuerung: Verhalten der Anhebungsaufforderung<br />
für Standardbenutzer<br />
<strong>Die</strong> UAC öffnet bei Bedarf eine Anhebungseingabeaufforderung, und falls der Benutzer<br />
Benutzername und Kennwort eines gültigen Administratorkontos eingeben kann, kann die<br />
Operation durchgeführt werden. In Unternehmen, die nicht wollen, dass ihre Benutzer eine<br />
Anhebung durchführen, können Sie diese Richtlinie so einstellen, dass alle Anhebungsanforderungen<br />
automatisch abgelehnt werden. Standardeinstellung für diese Richtlinie ist Aufforderung<br />
zur Eingabe der Anmeldeinformationen.<br />
Benutzerkontensteuerung: Anwendungsinstallationen erkennen<br />
und erhöhte Rechte anfordern<br />
<strong>Die</strong>se Einstellung aktiviert oder deaktiviert die Erkennung von Anwendungsinstallern. Am<br />
besten lassen Sie diese Einstellung aktiviert, was auch die Standardeinstellung ist.<br />
Benutzerkontensteuerung: Nur ausführbare Dateien heraufstufen,<br />
die signiert und validiert sind<br />
<strong>Die</strong>se Einstellung erzwingt die Authenticode-Signaturüberprüfung bei allen interaktiven<br />
Anwendungen, die eine Anhebung anfordern. Falls ein Unternehmen nur Authenticodesignierte<br />
Programme verwendet, kann diese Einstellung die <strong>Sicherheit</strong> erhöhen, weil kontrolliert<br />
wird, welche Anwendungsherausgeber ihre Programme mit erhöhten Privilegien<br />
ausführen dürfen. Bei den meisten Benutzern dürften aber erhebliche Anwendungskompatibilitätsprobleme<br />
auftreten, falls diese Einstellung verwendet wird. Daher ist sie in der Standardeinstellung<br />
deaktiviert.<br />
Benutzerkontensteuerung: Nur erhöhte Rechte für UIAccess-Anwendungen,<br />
die an sicheren Orten installiert sind<br />
UIAccess-Anwendungen sind meist Programme für erleichterte Bedienung, die direkt mit<br />
den <strong>Windows</strong>-UAC-Anhebungsdialogen kommunizieren müssen. UAC-Anhebungsdialoge<br />
sind in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> mit einer hohen Integritätsebene geschützt.<br />
Damit für UIAccess-Anwendungen eine Interaktion möglich wird, müssen Sie diese<br />
Anforderung im Anwendungsmanifest deklarieren. Wenn das Programm startet, bekommt es<br />
eine spezielle Integritätsebene, die Interaktion zulässt. Weil UIAccess-Anwendungen sehr<br />
mächtig sind, erzwingt diese Einstellung, dass solche Programme nur aus sicheren Dateipfaden<br />
gestartet werden können. UIAccess-Anwendungen müssen außerdem eine gültige und<br />
vertrauenswürdige Authenticode-Signatur haben. In der Standardeinstellung ist diese Einstellung<br />
aktiviert.
110 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
Benutzerkontensteuerung: Alle Benutzer (inkl. Administratoren)<br />
als Standardbenutzer ausführen<br />
<strong>Die</strong>s ist der Ein-/Ausschalter für die UAC. Deaktivieren Sie die UAC nicht! Falls die UAC<br />
deaktiviert ist, werden auch alle dazugehörigen Features deaktiviert. Datei- und Registrierungsvirtualisierung<br />
arbeiten nicht mehr, und für den Benutzer sieht es aus, als wären alle<br />
virtualisierten Daten verloren gegangen. Benutzer, die im Administratorbestätigungsmodus<br />
gearbeitet haben, werden nun mit vollständigen Administratorrechten angemeldet, und alle<br />
Anwendungen laufen völlig stillschweigend mit Administratorprivilegien! Auch Anwendungskompatibilitäts-Shims,<br />
die die Kompatibilität zu alten Anwendungen sicherstellen<br />
sollen, sind deaktiviert. Der geschützte Modus im Internet Explorer ist deaktiviert, sodass<br />
der Internet Explorer mit administrativen Privilegien ausgeführt wird. Haben wir Sie ausreichend<br />
abgeschreckt, sodass Sie die UAC eingeschaltet lassen? In der Standardeinstellung ist<br />
diese Einstellung aktiviert.<br />
Benutzerkontensteuerung: Bei Benutzeraufforderung nach erhöhten Rechten<br />
zum sicheren Desktop wechseln<br />
<strong>Die</strong>se Einstellung legt fest, ob Anhebungsanforderungen auf dem interaktiven Desktop des<br />
Benutzers oder auf dem sicheren Desktop angezeigt werden. Der sichere Desktop verhindert<br />
eine Fälschung der angezeigten Daten (spoofing). Das bedeutet, dass nicht manipuliert werden<br />
kann, was der Benutzer auf dem sicheren Desktop angezeigt bekommt. UAC-Dialogfelder<br />
auf dem interaktiven Desktop des Benutzers können gefälscht werden, daher sind sie<br />
weniger sicher als die im sicheren Desktop. In der Standardeinstellung ist diese Richtlinie<br />
aktiviert.<br />
Benutzerkontensteuerung: Datei- und Registrierungsschreibfehler<br />
an Einzelbenutzerstandorte virtualisieren<br />
<strong>Die</strong>se Einstellung aktiviert oder deaktiviert die Umleitung von fehlgeschlagenen Schreibversuchen<br />
in Dateisystem und Registrierung. Deaktivieren Sie dieses Feature, falls Sie ausschließlich<br />
Software verwenden, die die Anforderung an das <strong>Windows</strong> Vista- oder <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>-Logo erfüllen. Wie Sie Virtualisierungseinstellungen anpassen können, ist im<br />
Abschnitt »Konfigurieren der Registrierungsvirtualisierung zum Verbessern der Anwendungskompatibilität«<br />
weiter oben in diesem Kapitel beschrieben. In der Standardeinstellung<br />
ist diese Richtlinie aktiviert.<br />
Zugehörige UAC-Richtlinien<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> haben zwei ergänzende Richtlinieneinstellungen:<br />
Vertrauenswürdiger Pfad für Anmeldeinformationseintrag erforderlich und Bei Ausführung<br />
mit erhöhten Rechten Administratorkonten auflisten. Sie finden beide Einstellungen im<br />
Gruppenrichtlinien-Editor unter dem Knoten Richtlinien für lokaler Computer\Computerkonfiguration\Administrative<br />
Vorlagen\<strong>Windows</strong>-Komponenten\Benutzerschnittstelle für<br />
Anmeldeinformationen.<br />
Vertrauenswürdiger Pfad für Anmeldeinformationseintrag erforderlich<br />
<strong>Die</strong>se Einstellung steuert, ob der Benutzer <strong>Windows</strong>-Anmeldeinformationen über einen<br />
vertrauenswürdigen Pfad eingeben muss. Der vertrauenswürdige Pfad ist eine sichere Tastenkombination,<br />
die auch als Secure Attention Sequence (SAS) bezeichnet wird. Sie soll
Was hat sich bei der UAC in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista SP1 geändert? 111<br />
verhindern, dass Malware Ihre <strong>Windows</strong>-Anmeldeinformationen ausspäht. Wenn ein Standardbenutzer<br />
versucht, eine Aufgabe durchzuführen, die Administratorprivilegien erfordert,<br />
zwingt das System den Benutzer, die Tastenkombination STRG+ALT+ENTF zu drücken,<br />
bevor er auf den sicheren Desktop umgeleitet wird, wo er Benutzername und Kennwort<br />
eines gültigen Administratorkontos eingibt, um die Operation abzuschließen. <strong>Die</strong> Eingabe<br />
dieses vertrauenswürdigen Pfads verhindert das Fälschen von Ein- und Ausgaben, daher ist<br />
dies die sicherste Methode zur Eingabe von <strong>Windows</strong>-Anmeldeinformationen. In der Standardeinstellung<br />
ist diese Richtlinie deaktiviert.<br />
Bei Ausführung mit erhöhten Rechten Administratorkonten auflisten<br />
<strong>Die</strong>se Einstellung aktiviert die automatische Auflistung der lokalen Administratorkonten in<br />
der UAC-Eingabeaufforderung (Abbildung 4.10). Beachten Sie, dass diese Einstellung in<br />
Domänenumgebungen unerwartete Verzögerungen auslösen kann, falls die Netzwerkverbindung<br />
Probleme verursacht. In der Standardeinstellung ist diese Richtlinie deaktiviert.<br />
Abbildung 4.10 Lokale Administratorkonten werden im UAC-<br />
Anmeldeinformationendialog automatisch aufgelistet<br />
Was hat sich bei der UAC in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
und <strong>Windows</strong> Vista SP1 geändert?<br />
Gegenüber der ersten Version von <strong>Windows</strong> Vista wurden in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und<br />
<strong>Windows</strong> Vista SP1 einige kleinere Änderungen an der UAC vorgenommen. <strong>Die</strong> folgenden<br />
Abschnitte fassen diese Änderungen zusammen.<br />
Neue Gruppenrichtlinieneinstellung: UIAccess-Anwendungen können<br />
erhöhte Rechte ohne sicheren Desktop anfordern<br />
<strong>Die</strong>se Einstellung ermöglicht es UIAccess-Anwendungen, zum Beispiel Remoteunterstützung,<br />
die Verwendung des sicheren Desktops für Anhebungsaufforderungen zu deaktivieren.
112 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
Wenn die UIAccess-Anwendung beendet ist, wird die Verwendung des sicheren Desktops für<br />
Anhebungsaufforderungen automatisch wieder aktiviert. Der Endbenutzer braucht daher dem<br />
Helfer nicht mehr zu erlauben, Anhebungsaufforderungen zu bestätigen (Abbildung 4.11.)<br />
Wie weiter oben in diesem Kapitel beschrieben, ist das eine nützliche Einstellung für Unternehmen,<br />
in denen der Helpdesk mithilfe der Remoteunterstützung Support für Endbenutzer<br />
anbietet. In der Standardeinstellung ist diese Richtlinie deaktiviert.<br />
Abbildung 4.11 <strong>Windows</strong>-Remoteunterstützung: Bestätigen von Eingabeaufforderungen<br />
der Benutzerkontensteuerung zulassen<br />
Nur eine Bestätigung bei Dateioperationen im <strong>Windows</strong>-Explorer<br />
Wenn ein Benutzer einen neuen Ordner in einem geschützten Speicherort anlegt, muss er<br />
nur eine Eingabeaufforderung bestätigen, um den Ordner zu erstellen und mit einem Namen<br />
zu versehen. In <strong>Windows</strong> Vista RTM erschienen bei dieser Operation zwei Eingabeaufforderungen.<br />
Über 40 neue Anwendungskompatibilitäts-Shims<br />
Das UAC-Team hat in Zusammenarbeit mit dem Anwendungskompatibilitätsteam über 40<br />
neue Anwendungs-Shims erstellt, um die Kompatibilität zu <strong>Windows</strong> Vista und <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> zu verbessern.<br />
Empfehlungen für die UAC<br />
Das Verwalten der UAC ist nicht so schwierig, wie es auf den ersten Blick aussieht. Welche<br />
Einstellungen Sie in einer Organisation vornehmen, hängt in erster Linie von den <strong>Sicherheit</strong>sanforderungen<br />
Ihrer Organisation ab. Außerdem muss eine sinnvolle Balance im Bezug<br />
auf die Benutzerfreundlichkeit gefunden werden. <strong>Die</strong> Liste der folgenden Lösungen ist nach<br />
zunehmender <strong>Sicherheit</strong> sortiert.<br />
Gut<br />
Lassen Sie Benutzer im Administratorbestätigungsmodus arbeiten. Falls ein administrativer<br />
Benutzer erhöhte Privilegien benötigt, sollte die UAC-Richtlinie des Unternehmens erzwingen,<br />
dass der Benutzer Name und Kennwort eines gültigen Administratorkontos eingibt, und<br />
nicht einfach auf Fortsetzen klicken kann. <strong>Die</strong>se Konfiguration verhindert unautorisierte<br />
Anhebungen für den Fall, dass ein Benutzer seine Arbeitsstation unbeaufsichtigt lässt. Um<br />
die <strong>Sicherheit</strong> zu verbessern, können Sie außerdem fordern, dass bei allen Anhebungen die<br />
Tastenkombination STRG+ALT+ENTF verwendet werden muss. Das macht es wesentlich<br />
sicherer, administrative Anmeldeinformationen einzugeben.
Zusammenfassung 113<br />
Besser<br />
Schreiben Sie vor, dass alle Benutzer, die Administratorprivilegien brauchen, zwei Konten<br />
haben: ein Standardbenutzerkonto für alltägliche Tätigkeiten wie das Lesen von E-Mail, und<br />
eines für die seltener ausgeführten administrativen Operationen. Der Benutzer kann sich als<br />
Standardbenutzer anmelden, und bei Bedarf kann er über eine UAC-Eingabeaufforderung<br />
seine Anmeldeinformationen eingeben und so eine Anhebung durchführen. Das ist nicht die<br />
beste Lösung, weil der Benutzer in derselben interaktiven Sitzung Anwendungen mit Standardbenutzer-<br />
und Administratorprivilegien ausführt. Um die <strong>Sicherheit</strong> zu verbessern, kann<br />
ein Unternehmen erzwingen, dass der Benutzer immer die schnelle Benutzerumschaltung<br />
(Fast User Switching, FUS) verwendet, wenn er eine Operation mit erhöhten Privilegien<br />
durchführen will. <strong>Die</strong> schnelle Benutzerumschaltung ist zwar sicherer, sie ist aber weniger<br />
benutzerfreundlich. Um die <strong>Sicherheit</strong> zu verbessern, können Sie außerdem auch hier fordern,<br />
dass bei allen Anhebungen die Tastenkombination STRG+ALT+ENTF verwendet werden<br />
muss.<br />
Am besten<br />
Lassen Sie alle Benutzer als Standardbenutzer arbeiten. <strong>Die</strong> IT-Abteilung muss dann davon<br />
ausgehen, dass Standardbenutzer im Allgemeinen keine Anwendungen installieren können.<br />
Daher muss sie Software für die Benutzer bereitstellen. <strong>Windows</strong> stellt dafür einen Installationsdienst<br />
zur Verfügung, den MSI-<strong>Die</strong>nst (Microsoft Software Installer). Außerdem erlaubt<br />
die GPSI-Erweiterung (Group Policy Software Installation) es, Anwendungen auf den Computer<br />
eines Benutzers zu verteilen, ohne dass dafür eine Interaktion des Benutzers erforderlich<br />
ist. Weitere Informationen finden Sie in der Dokumentation der GPSI-Erweiterung unter<br />
http://go.microsoft.com/fwlink/?LinkId=71356.<br />
Zusammenfassung<br />
UAC ist wahrscheinlich das am meisten diskutierte Feature in <strong>Windows</strong> Vista. Sie wird<br />
sogar in Werbeanzeigen konkurrierender Softwarehersteller erwähnt. Es ist schwer zu sagen,<br />
ob man es als schmeichelhaft oder ärgerlich empfinden sollte, wenn Microsofts Konkurrenz<br />
ihre Produkte als besser anpreist, weil <strong>Windows</strong> zu sicher ist. <strong>Die</strong> UAC ist auf jeden Fall ein<br />
bedeutender Schritt für <strong>Windows</strong>. Der frühere Zustand, in dem Benutzer ganz normale Aufgaben<br />
als Administratoren ausführten, ist jedenfalls inakzeptabel und hat zu einer gewaltigen<br />
Verbreitung von Malware geführt. Nur wenn wir den Benutzern helfen, ihre Aufgaben als<br />
Nicht-Administratoren auszuführen, können wir hoffen, die Flut von Malware aufzuhalten<br />
und die Betriebskosten für Desktopsysteme zu senken.<br />
In der Zukunft setzen die Benutzer administrative Privilegien nur noch bei Bedarf ein. <strong>Die</strong><br />
UAC ist ein Schritt in diese Richtung. Das kann aber nur funktionieren, wenn Benutzer sie<br />
auch einsetzen und von den Softwareherstellern verlangen, dass ihre Programme als Standardbenutzer<br />
ausgeführt werden können. Sie können Ihren Teil dazu beitragen, das IT-Ökosystem<br />
zu schützen, indem Sie die UAC nutzen, Software kaufen, die damit funktioniert.<br />
und Software zurückweisen, die dazu nicht in der Lage ist.
114 Kapitel 4: Grundlagen der Benutzerkontensteuerung<br />
Weitere Informationen<br />
Microsoft Corporation (2006): »The <strong>Windows</strong> Vista and <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Developer<br />
Story: <strong>Windows</strong> Vista Development Requirements for User Account Control (UAC)«<br />
unter http://msdn2.microsoft.com/en-us/library/aa905330.aspx.<br />
Mark Russinovich (2007): »Inside <strong>Windows</strong> Vista User Account Control« unter<br />
http://www.microsoft.com/technet/technetmag/issues/2007/06/UAC/.<br />
Raymond Chen (2006): »An Administrator Is Not the Administrator« unter http://www.<br />
microsoft.com/technet/technetmag/issues/2006/03/<strong>Windows</strong>Confidential/?related=<br />
/technet/technetmag/issues/2006/03/<strong>Windows</strong>Confidential.<br />
Wole Moses (2007): »Services Hardening in <strong>Windows</strong> Vista« unter http://www.micro<br />
soft.com/technet/technetmag/issues/2007/01/SecurityWatch/?related=/technet/technet<br />
mag/issues/2007/01/SecurityWatch.
K A P I T E L 5<br />
Firewall und Netzwerkzugriffsschutz<br />
Von Kurt Dillard<br />
In diesem Kapitel:<br />
<strong>Windows</strong>-Filterplattform ............................................... 116<br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> . ................................. 118<br />
Routing- und RAS-<strong>Die</strong>nste ............................................. 130<br />
Internet Protocol Security .............................................. 133<br />
Netzwerkzugriffsschutz ............................................... 139<br />
Zusammenfassung .................................................. 148<br />
Weitere Informationen ................................................ 149<br />
Falls Sie wie ich in jener lang vergangenen Ära geboren wurden, als Musik analog auf Vinylplatten<br />
gepresst wurde, haben Sie vielleicht noch mit Computern gearbeitet, die keinen<br />
ständigen Internetzugriff hatten, möglicherweise sogar überhaupt keine Netzwerkverbindung.<br />
Als die heutigen Netzwerktechnologien ihren Weg aus den Labors in die Wohnzimmer<br />
genommen hatten, begannen die Leute zu sehen, welche Auswirkungen nichtauthentifizierter<br />
Zugriff und Klartext-Kommunikationsprotokolle hatten. Es sieht aus, als hätten wir seitdem<br />
ein unglaublich schwieriges Katz- und Mausspiel mit den bösen Buben gespielt. Leider<br />
enden die Guten allzu oft als die Mäuse.<br />
<strong>Die</strong> ersten Firewalls wurden Ende der 1980er als Reaktion auf <strong>Sicherheit</strong>sprobleme wie zum<br />
Beispiel den Morris-Wurm eingeführt. Frühe Firewalls waren simpel verglichen mit ihren<br />
heutigen Nachfahren: Sie erlaubten oder blockierten eingehenden Verkehr abhängig von<br />
Informationen im Paketheader, zum Beispiel Quell-IP-Adresse und Portnummer. Sie verfolgten<br />
nicht den Status einer Kommunikationssequenz zwischen dem vertrauenswürdigen<br />
Host im internen Netzwerk und dem anonymen Computer irgendwo da draußen. Firewalls<br />
entwickelten sich aber ständig weiter. Zunächst wurden Firewalls statusbehaftet (engl. stateful),<br />
das bedeutet, sie erkennen die normale Sequenz von Paketen, mit denen Kommunikation<br />
zwischen zwei Hosts hergestellt und aufrechterhalten wird. Dann erschienen Firewalls,<br />
die Anwendungsschichtprotokolle verstanden: Sie untersuchten die eigentlichen Nutzdaten<br />
innerhalb eines Pakets, um nach böswilligem Verkehr zu suchen. Zum Beispiel kann eine<br />
Firewall, die einen Webserver schützt, die von einem Remoteclient gesendete HTTP-Anforderung<br />
untersuchen und feststellen, ob sie eine gültige Anforderung nach Daten enthält oder<br />
einen Versuch darstellt, den <strong>Server</strong> zu kompromittieren. Anwendungsschichtfirewalls sind<br />
seitdem sehr leistungsfähig geworden. Wer weiß, wie Microsofts Internet Security and Acceleration<br />
<strong>Server</strong> (ISA <strong>Server</strong>) vorgeht, wenn er einen <strong>Server</strong> schützt, der Microsoft Office<br />
Outlook-Webzugriff zur Verfügung stellt, wird sich vorstellen können, wie leistungsfähig<br />
diese Technologien geworden sind.<br />
Bisher haben wir uns damit beschäftigt, wie Organisationen ihre Netzwerkgrenzen mithilfe<br />
von Unternehmensnetzwerkfirewalls schützen. Aber inzwischen sind sehr viele mobile<br />
115
116 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Geräte und komplexe Netzwerkarchitekturen im Einsatz, und kritische Unternehmensdaten<br />
werden über das öffentliche Internet für den gemeinsamen Zugriff durch Geschäftspartner<br />
bereitgestellt. Daher stellen die meisten Organisationen auch hostbasierte Firewalls bereit.<br />
Authentifizierungs- und Verschlüsselungstechnologien haben sich seit den Zeiten von<br />
Gopher und Veronica deutlich weiterentwickelt. Remotehosts können sichere Kommunikationskanäle<br />
über TLS (Transport Layer Security), IKE (Internet Key Exchange) und andere<br />
Protokolle herstellen. Sie können Benutzer auf viele unterschiedliche Arten authentifizieren<br />
und sie können den Netzwerkverkehr mit IPsec (Internet Protocol Security), HTTPS (Secure<br />
Hypertext Transport Protocol) und vielen anderen Protokollen verschlüsseln. <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong> bietet Unterstützung für viele dieser Protokolle. <strong>Die</strong>ses Kapitel konzentriert sich<br />
besonders auf die <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong>, IPsec, Netzwerkzugriffsschutz<br />
(Network Access Protection, NAP) und einige neue Fähigkeiten, die zum Routing-<br />
und RAS-<strong>Die</strong>nst (Routing And Remote Access Service, RRAS) hinzugefügt wurden.<br />
Uralte Protokolle: Das Internet vor dem Webzeitalter<br />
Manche Leser werden geschockt sein: Millionen von Leuten nutzten das Internet für<br />
Kommunikation und Informationsabruf, lange bevor Sir Tim Berners-Lee und Robert<br />
Cailliau HTTP (Hypertext Transport Protocol) und HTML (Hypertext Markup Language)<br />
entwickelten. Es stimmt wirklich: Leute konnten ganz ohne Browser andere Leute finden<br />
und online auf nützliche Informationen zugreifen! E-Mail wurde schon vor dem Internet<br />
verwendet, sie half sogar, seine Entwicklung zu beschleunigen. Leute stellten Informationen<br />
online zur Verfügung, indem sie Dokumente und andere Datentypen auf FTP-<strong>Server</strong>n<br />
(File Transfer Protocol) veröffentlichten, aber wenn man den Speicherort der gewünschten<br />
Datei nicht wusste, war es recht schwierig, sie zu finden. Gopher (ein verteiltes Dokumentensuch-<br />
und -abrufsystem) war der Vorläufer des World Wide Web. Veronica, eine<br />
der ersten Suchmaschinen im Internet, konnte Informationen anhand des Namens von<br />
Menüelementen in Gopher-Sites finden. WAIS (Wide Area Informationen <strong>Server</strong>s) war<br />
ein frühes Client/<strong>Server</strong>-Suchsystem, das Volltextsuche in Gopher-<strong>Server</strong>n beherrschte.<br />
Ja, ich habe unter anderem mit all diesen Technologien gearbeitet, als mir USENET und<br />
Forensysteme langweilig wurden. Das war über ein 2400-Baud-Modem. Ich bin ein<br />
Dinosaurier.<br />
<strong>Windows</strong>-Filterplattform<br />
Um die Entwicklung von Netzwerkverkehrfilterprodukten voranzutreiben, entwickelte<br />
Microsoft die <strong>Windows</strong>-Filterplattform (<strong>Windows</strong> Filtering Platform, WFP). Sie steht sowohl<br />
in <strong>Windows</strong> Vista als auch <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zur Verfügung. WFP ist keine Firewall,<br />
sondern ein Satz von Systemdiensten und Anwendungsprogrammierschnittstellen<br />
(Application Programming Interface, API), die von Entwicklern bei Microsoft und Fremdherstellern<br />
genutzt werden können. WFP ermöglicht eine völlig neue Qualität des Zugriffs<br />
auf den TCP/IP-Stack (Transmission Control Protocol/Internet Protocol), sodass ein- und<br />
ausgehende Netzwerkpakete untersucht oder geändert werden können, bevor ihnen der Weitertransport<br />
erlaubt wird. Entwickler können mit WFP eine Vielzahl von Diagnose- und<br />
<strong>Sicherheit</strong>stools erstellen, zum Beispiel Firewalls und Antivirensoftware. Abbildung 5.1<br />
bietet einen Überblick über die WFP-Architektur und zeigt, wo sich Tools von Fremdherstellern<br />
einklinken können.
Abbildung 5.1 <strong>Die</strong> Architektur der <strong>Windows</strong>-Filterplattform<br />
WFP umfasst folgende Architekturkomponenten:<br />
<strong>Windows</strong>-Filterplattform 117<br />
<strong>Die</strong> RPC-Schnittstelle bietet Zugriff auf die WFP. Firewalls und andere Anwendungen<br />
rufen die WFP-API auf, die diese Aufrufe an das Basisfilterungsmodul (Base Filtering<br />
Engine, BFE) weiterleitet.<br />
Das BFE ist die Benutzermoduskomponente, die zwischen Anwendungen, die Filterungsanforderungen<br />
stellen, und der GFE (Generic Filter Engine) vermittelt, die innerhalb<br />
des Treibers läuft, der den neuen TCP/IP-Stack implementiert. <strong>Die</strong> BFE fügt Filter<br />
zum System hinzu und entfernt sie, speichert die Filterkonfiguration und erzwingt die<br />
WFP-Konfigurationssicherheit.<br />
<strong>Die</strong> GFE ist die Kernmoduskomponente, die Filterinformationen von der Base Filtering<br />
Engine empfängt, mit Callout-Treibern kommuniziert und mit dem TCP/IP-Stack zusammenarbeitet.<br />
Wenn ein- oder ausgehende Pakete im neuen TCP/IP-Stack verarbeitet<br />
werden, werden sie von der Generic Filter Engine ausgewertet, die überprüft, ob einem<br />
Paket die Weiterbeförderung erlaubt werden soll. <strong>Die</strong> Generic Filter Engine führt diese<br />
Analyse durch, indem sie jedes Paket mit den zuständigen Filtern und Callout-Modulen<br />
vergleicht.<br />
Callout-Module werden benutzt, wenn eine Anwendung Pakete detailliert untersuchen<br />
oder ihre Daten verändern will. Zum Beispiel kann ein Antivirentool den Verkehr auf der<br />
Anwendungsschicht untersuchen, bevor er tatsächlich an die Zielanwendung weitergeleitet<br />
wird, um sicherzustellen, dass sich keine Malware in die Daten eingeschmuggelt<br />
hat.
118 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong><br />
Konnektivität ist allgegenwärtig. <strong>Die</strong> meisten Computer sind nicht nur mit einem internen<br />
Unternehmensnetzwerk verbunden, sondern auch mit dem Internet. Hochgeschwindigkeits-<br />
Drahtlosnetzwerke und mobile Benutzer sind überall, oft direkt an das Internet mit seinen<br />
gigantischen Botnets angeschlossen, in denen sich alle Arten von Viren tummeln und die<br />
Unmassen von Spam ausspucken. Sogar <strong>Server</strong>, die in verwalteten Unternehmensnetzwerken<br />
liegen, sind Gefahren ausgesetzt: Mitarbeiter kommen von einer <strong>Die</strong>nstreise und verbinden<br />
ihre Notebooks wieder mit dem internen Netzwerk, nachdem sie außerhalb infiziert<br />
wurden, Besucher wie Consultants und Kunden wollen Ihr Netzwerk benutzen und natürlich<br />
gibt es böswillige Insider, die aus irgendwelchen Gründen denken, sie müssten Ihre Geschäftssysteme<br />
kompromittieren.<br />
Aus diesen Gründen ist es sinnvoll, die in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthaltene Hostfirewall zu<br />
aktivieren. So ziehen Sie eine weitere Schutzschicht in Ihre gestaffelte Verteidigung ein. <strong>Die</strong><br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> bietet bidirektionale Filterung, um zu verhindern,<br />
dass unerwünschter Verkehr zu den <strong>Die</strong>nsten gelangt, die auf dem System laufen. Und<br />
sie verhindert, dass kompromittierte <strong>Server</strong> Ihr übriges Netzwerk angreifen. <strong>Die</strong> Verwaltung<br />
von <strong>Windows</strong>-Firewall und IPsec (Internet Protocol Security) ist in einer einzigen MMC-<br />
Konsole (Microsoft Management Console) integriert, sodass die Firewall ein Eckpfeiler für<br />
die Isolationsstrategie Ihres Netzwerks wird.<br />
Verbesserungen an der <strong>Windows</strong>-Firewall<br />
Bevor wir uns genau ansehen, wie Sie mithilfe der neuen <strong>Windows</strong>-Firewall Ihre <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>-Hosts schützen, wollen wir uns kurz einen Überblick über die wichtigsten Verbesserungen<br />
gegenüber den Vorgängerversionen verschaffen.<br />
Bessere Verwaltungsschnittstelle<br />
<strong>Die</strong> deutlichste Verbesserung ist eine neue grafische Benutzeroberfläche, in der Sie die <strong>Windows</strong>-Firewall<br />
lokal und über Gruppenrichtlinien für Active Directory-Domänen verwalten<br />
können. Das alte Systemsteuerungsmodul, <strong>Windows</strong>-Firewall, bietet nach wie vor Zugriff<br />
auf grundlegende Einstellmöglichkeiten. <strong>Die</strong> neue Benutzeroberfläche ist ein Microsoft<br />
Management Console-Snap-In. Wenn Sie lokale Einstellungen konfigurieren wollen, können<br />
Sie die Konsole <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> aus dem Ordner Verwaltung<br />
starten. <strong>Die</strong>ses Snap-In ist auch in der Konsole Gruppenrichtlinien-Editor enthalten, sodass<br />
Sie die Firewall über Active Directory-Domänengruppenrichtlinien verwalten können. Verbesserungen<br />
wurden auch an Netsh.exe vorgenommen, dem Befehlszeilentool zum Verwalten<br />
von Firewall und IPsec. Der Befehl Netsh hat jetzt einen neuen Kontext, advfirewall,<br />
mit dem Sie die Konfiguration der Firewall über ein Skript anpassen oder in einer <strong>Server</strong><br />
Core-Installation verwalten können.<br />
<strong>Windows</strong>-<strong>Die</strong>nsthärtung<br />
Es wurde zwar viel getan, um die <strong>Die</strong>nste selbst zu schützen, aber es ist denkbar, dass ein<br />
Angreifer immer noch einen Weg findet, einen <strong>Windows</strong>-Systemdienst zu kompromittieren.<br />
Falls ein <strong>Die</strong>nst kompromittiert wird, hilft die <strong>Windows</strong>-<strong>Die</strong>nsthärtung (engl. service hardening),<br />
die Auswirkungen gering zu halten: <strong>Die</strong> Firewall blockiert anormales Verhalten, zum<br />
Beispiel wenn ein <strong>Die</strong>nst, der nicht auf das Netzwerk zugreifen muss, plötzlich HTTP-<br />
Verkehr aussendet. Kapitel 6, »<strong>Die</strong>nste«, beschreibt die <strong>Windows</strong>-<strong>Die</strong>nsthärtung genauer.
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> 119<br />
Ausgehende Filterung<br />
Nachdem ich viele Jahre lang Händeringen, Hyperventilation und meterlange Bücherregale<br />
mit Ratschlägen von Herstellern, Administratoren und <strong>Sicherheit</strong>sexperten (sowohl echte als<br />
auch selbsternannte) beobachten durfte, bin ich zu dem Schlusss gekommen, dass ausgehende<br />
Filterung von Netzwerkverkehr auf Hostfirewalls in den meisten Fällen sinnlos ist. Ich<br />
schreibe bewusst »in den meisten Fällen«. Etwas weiter unten komme ich darauf zurück und<br />
beschreibe, wann ich ausgehende Filterung für angebracht halte. Um einen bekannten Ausspruch<br />
von Bruce Schneier zu zitieren, den ich für einen echten Experten halte (auch wenn<br />
ich öfters anderer Meinung bin als er): Ausgehende Filterung ist üblicherweise lediglich<br />
»<strong>Sicherheit</strong>stheater«. Es ist die eingehende Filterung, die böswilligen Netzwerkverkehr<br />
stoppt, zum Beispiel Nimda, Slammer, Sasser, Blaster oder was auch immer unerwünschten<br />
Netzwerkverkehr an Ihren <strong>Server</strong> sendet.<br />
Als Microsoft in Service Pack 2 für <strong>Windows</strong> XP die stark verbesserte Firewall einführte,<br />
wurde eine Menge Geschwafel produziert, weil sie keine ausgehende Filterung enthielt. Ich<br />
sage es Ihnen ganz unverblümt: <strong>Die</strong> meisten dieser Beschwerden kamen von Leuten, die<br />
(gelinde gesagt) nicht allzu viel davon verstehen, was beim Thema Computersicherheit<br />
sinnvoll ist, oder von Unternehmen, die ihre eigenen Clientfirewallprodukte anpriesen. Falls<br />
ein Angreifer (oder Malware) die Kontrolle über Ihren Computer übernommen hat, was soll<br />
ihn dann hindern, die Firewall so umzukonfigurieren, dass sie Verkehr von beliebigen Anwendungen<br />
durchlässt? Der Angreifer braucht wahrscheinlich nicht einmal die Firewall<br />
umzukonfigurieren, er kann einfach Ports nutzen, die bereits erlaubt sind, oder die Kontrolle<br />
über eine Anwendung übernehmen, die bereits Verkehr hinaussenden kann. Ein anderer<br />
bedenklicher Aspekt der meisten Clientfirewalllösungen ist, dass ausgehende Filterung jegliche<br />
Benutzerfreundlichkeit in Grund und Boden stampft: Nachdem Sie das verdammte<br />
Ding installiert haben, werden Sie mit Hunderten von Popupdialogen bombardiert, die Sie<br />
fragen, ob der Internet Explorer wirklich eine Verbindung zu www.microsoft.com öffnen darf<br />
oder ob Sie wirklich absolut sicher sind, dass der MSN Web Messenger Verkehr an msn.com<br />
senden darf. Nachdem sich ein Benutzer eine Woche lang durch Unmassen dieser Dialogfelder<br />
geklickt hat, neigen selbst paranoide Systemadministratoren und <strong>Sicherheit</strong>sexperten<br />
dazu, das Ding völlig zu deaktivieren. Oder sie gewöhnen sich an, sofort ohne Hinsehen auf<br />
Ja oder Zulassen zu klicken, damit sie eine Chance haben, ihre Arbeit auf dem Computer<br />
erledigt zu bekommen!<br />
Microsofts neuestes <strong>Server</strong>betriebssystem nutzt die ausgehende Filterung auf intelligente<br />
Weise, indem sie Systemdienste daran hindert, Netzwerkverbindungen aufzubauen, sofern<br />
sie diese Verbindungen nicht benötigen, um ihre Funktion zu erfüllen. Falls ein <strong>Die</strong>nst kompromittiert<br />
wird, ist er nicht in der Lage, die Firewall umzukonfigurieren, ohne den Benutzer<br />
darüber zu informieren. Sie können nämlich keine Firewalleinstellungen ändern. In der<br />
Standardeinstellung erlaubt die neue Firewall alle anderen ausgehenden Netzwerkpakete.<br />
Sie können das Standardverhalten so ändern, dass der gesamte ausgehende Verkehr blockiert<br />
wird, aber ich rate davon ab, weil Sie dann viele Stunden, Tage und möglicherweise Wochen<br />
dafür aufwenden müssen, jede Ausnahme auszutüfteln, die Sie konfigurieren müssen, damit<br />
Ihre <strong>Server</strong> alle ihre vorgesehenen Aufgaben erfüllen können.<br />
Detaillierte Regeln<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista ist die Firewall sowohl für eingehende als auch<br />
ausgehende Verbindungen aktiviert. <strong>Die</strong> Standardrichtlinien blockieren den meisten eingehenden<br />
Verkehr und erlauben den meisten ausgehenden Verkehr. <strong>Die</strong> Firewall unterstützt die
120 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Filterung aller IP-Protokollnummern (Abbildung 5.2). Bei der <strong>Windows</strong> XP-Firewall war<br />
das anders, sie konnte nur TCP- (Transmission Control Protocol), UDP- (User Datagram<br />
Protocol) und ICMP-Verkehr (Internet Control Message Protocol) blockieren. Sie können<br />
spezifische Regeln konfigurieren, um Verkehr anhand von IP-Adressen, IP-Protokollnummern,<br />
Active Directory-Verzeichnisdienstkonten und -gruppen, Systemdiensten, UDP- und<br />
TCP-Quell- und -Zielports, bestimmten Schnittstellentypen und ICMP anhand von Typ und<br />
Code zu blockieren oder zu erlauben.<br />
Abbildung 5.2 Einige der Filterungsoptionen in der <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong><br />
Standortabhängige Profile<br />
<strong>Die</strong> <strong>Windows</strong>-Firewall nutzt die Fähigkeit des neuen TCP/IP-Stacks, automatisch zu verfolgen,<br />
an welches Netzwerk er angeschlossen ist. Sie können Regeln und Einstellungen für<br />
jedes der drei Profile konfigurieren: Domäne, Privat und Öffentlich. Das Domänenprofil<br />
wird verwendet, wenn alle Netzwerke des Computers Active Directory-Domänencontroller<br />
für die Domäne enthalten, zu der dieser Computer gehört. Das private Profil wird verwendet,<br />
wenn alle aktiven Netzwerkverbindungen von einem Administrator als private Netzwerke<br />
eingestuft wurden, die durch eine Firewall geschützt sind. Das öffentliche Profil wird<br />
verwendet, wenn der Computer direkt mit dem Internet oder einem Netzwerk verbunden ist,<br />
das nicht als privates oder Domänennetzwerk eingestuft wurde.
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> 121<br />
Authentifizierte Umgehung<br />
Sie können Regeln konfigurieren, die es bestimmten Computern oder Computergruppen<br />
erlauben, andere Firewallregeln mithilfe von IPsec-Authentifizierung in diesen Regeln zu<br />
umgehen. Das bedeutet, dass Sie bestimmte Verkehrstypen auf allen anderen Hosts blockieren,<br />
aber einigen ausgewählten Systemen erlauben können, diese Einschränkungen zu umgehen<br />
und auf den blockierten <strong>Die</strong>nst zuzugreifen. <strong>Die</strong> Regeln können sogar noch spezifischer<br />
sein, indem sie festlegen, welche Ports oder Programme den Verkehr empfangen dürfen.<br />
Unterstützung für Active Directory-Benutzer, -Computer und -Gruppen<br />
Regeln können Benutzer, Computer und Gruppen verwenden, die in Active Directory definiert<br />
sind. Sie müssen Verbindungen, die von derartigen Regeln betroffen sind, aber mit<br />
IPsec schützen und dabei Anmeldeinformationen eines Active Directory-Kontos verwenden.<br />
IPv6-Unterstützung<br />
<strong>Die</strong> <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> bietet vollständige Unterstützung für IPv6.<br />
IPsec-Integration<br />
In <strong>Windows</strong> XP und <strong>Windows</strong> <strong>Server</strong> 2003 werden Regeln für die <strong>Windows</strong>-Firewall und<br />
IPsec getrennt voneinander konfiguriert. Weil beide eingehenden Verkehr blockieren oder<br />
erlauben können, konnte es passieren, dass Sie versehentlich redundante oder sogar widersprüchliche<br />
Regeln erstellen. Solche Konfigurationsfehler können schwierig aufzuspüren<br />
sein. <strong>Die</strong> neue <strong>Windows</strong>-Firewall fasst die Konfiguration von Firewall und IPsec in denselben<br />
grafischen und Befehlszeilentools zusammen. Das vereinfacht die Verwaltung und verringert<br />
die Gefahr einer Fehlkonfiguration.<br />
Direkt von der Quelle: Ausgehende Filterung ist <strong>Sicherheit</strong>stheater<br />
Welche Aufgabe hat eine Firewall? Sie soll eingehenden Verkehr blockieren, den Sie<br />
nicht angefordert haben. Ist es vielleicht auch sinnvoll, wenn eine Firewall ausgehenden<br />
Verkehr blockiert, den Sie nicht genehmigt haben? <strong>Die</strong> Hersteller vieler Firewallprodukte<br />
glauben das. Sie behaupten, dass der Entwurf der <strong>Windows</strong>-Firewall nicht genug Funktionsumfang<br />
für eine Clientfirewall bietet. Ihr Argument ist, dass eine brauchbare Clientfirewall<br />
den gesamten Verkehr <strong>–</strong> ein- und ausgehend <strong>–</strong> blockieren soll, sofern der Benutzer<br />
ihn nicht explizit genehmigt hat.<br />
Denken wir mal einen Moment darüber nach. Zwei Szenarien drängen sich auf. Falls Sie<br />
als lokaler Administrator arbeiten und Ihr Computer mit Malware infiziert wird, deaktiviert<br />
die Malware einfach die Firewall. Sie sind »0wn3d«. Falls Sie nicht als lokaler Administrator<br />
arbeiten und Ihr Computer mit Malware infiziert wird, bewirkt die Malware,<br />
dass die Firewall eines Fremdherstellers einen Dialog voller unverständlicher Details<br />
über Ports sowie IP-Adressen öffnet, die eine sehr ernste Frage stellt: »Wollen Sie das<br />
erlauben?« <strong>Die</strong> einzige Antwort ist natürlich: »Ja, du blöder Computer, nerv mich nicht!«<br />
Und sobald dieser Dialog geschlossen ist, ist auch Ihre <strong>Sicherheit</strong> futsch. Noch häufiger<br />
kommt es allerdings vor, dass die Malware einfach die vorhandene Sitzung eines Programms<br />
übernimmt, die Sie bereits autorisiert haben. Dann bekommen Sie nicht einmal<br />
den Dialog zu sehen. Und wieder: Sie sind »0wn3d«.
122 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Es gibt ein wichtiges Axiom in der <strong>Sicherheit</strong>, das Sie verstehen müssen: Schutz gehört<br />
auf das Objekt, das Sie schützen wollen, nicht auf das Ding, vor dem Sie sich schützen<br />
wollen. Der richtige Ansatz lautet, auf allen Computern in Ihrer Organisation die schlanke,<br />
aber effektive <strong>Windows</strong>-Firewall auszuführen. So schützen Sie jeden Computer vor<br />
allen anderen Computern in der Welt. Falls Sie versuchen, ausgehende Verbindungen von<br />
einem Computer zu blockieren, der bereits kompromittiert ist, wie können Sie dann<br />
sicher sein, dass der Computer wirklich tut, was Sie ihm befehlen? Simple Antwort:<br />
Das können Sie nicht. Ausgehender Schutz ist <strong>Sicherheit</strong>stheater <strong>–</strong> ein Gimmick, das nur<br />
vorspiegelt, Ihre <strong>Sicherheit</strong> zu verbessern. In Wirklichkeit wird Ihre <strong>Sicherheit</strong> überhaupt<br />
nicht verbessert, mit einer Ausnahme, wie weiter oben in diesem Kapitel erwähnt:<br />
<strong>Die</strong> <strong>Die</strong>nsthärtung in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> verbessert tatsächlich<br />
die <strong>Sicherheit</strong>.<br />
Steve Riley, Security Evangelist<br />
Microsoft Corporation<br />
Verwalten der <strong>Windows</strong>-Firewall<br />
Mit dem Systemsteuerungsapplet <strong>Windows</strong>-Firewall können Sie zwar einige grundlegende<br />
Einstellungen konfigurieren, aber für die erweiterten Features brauchen Sie die MMC-Konsole<br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong>, die MMC-Konsole Gruppenrichtlinien-<br />
Editor oder das Befehlszeilentool Netsh. Mit der Konsole <strong>Windows</strong>-Firewall mit erweiterter<br />
<strong>Sicherheit</strong> können Sie nicht nur Einstellungen auf dem lokalen Host konfigurieren, sondern<br />
auch auf Remotecomputern.<br />
Abbildung 5.3 Verwalten der <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> über Gruppenrichtlinien
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> 123<br />
Sie können die neue <strong>Windows</strong>-Firewall über Gruppenrichtlinien verwalten, indem Sie im<br />
Snap-In Gruppenrichtlinien-Editor den Knoten Computerkonfiguration/<strong>Windows</strong>-Einstellungen/<strong>Sicherheit</strong>seinstellungen/<strong>Windows</strong>-Firewall<br />
mit erweiterter <strong>Sicherheit</strong> öffnen (Abbildung<br />
5.3). Gruppenrichtlinieneinstellungen für die neue <strong>Windows</strong>-Firewall werden von<br />
Computern ignoriert, die unter <strong>Windows</strong> XP oder <strong>Windows</strong> <strong>Server</strong> 2003 laufen. Sie wenden<br />
weiterhin die Einstellungen an, die unter Computerkonfiguration\Administrative Vorlagen\<br />
Netzwerk\Netzwerkverbindungen\<strong>Windows</strong>-Firewall definiert sind. Das mag verwirrend<br />
sein, aber wegen der grundlegenden Entwurfsänderungen und der IPsec-Integration war es<br />
nötig, eine neue Position in den Gruppenrichtlinien festzulegen, um die neue Firewall zu<br />
verwalten.<br />
Grafische Verwaltung<br />
<strong>Die</strong> Konsole <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> und das entsprechende Snap-In,<br />
das in der Konsole Gruppenrichtlinien-Editor enthalten ist, sind praktisch identisch. Der<br />
Hauptunterschied besteht darin, dass die eigenständige Konsole einen Knoten namens<br />
Überwachung anzeigt, in dem Sie Echtzeitinformationen über den Status der Firewallfilterregeln,<br />
IPsec-Verbindungssicherheitsregeln sowie Hauptmodus- und Schnellmodussicherheitszuordnungen<br />
angezeigt bekommen (Abbildung 5.4).<br />
Abbildung 5.4 <strong>Die</strong> MMC-Konsole <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong><br />
In einer Regel können viele Elemente angegeben werden, zum Beispiel Quell- und Ziel-IP-<br />
Adressen, IP-Protokollnummern, Quell- und Ziel-TCP- und -UDP-Ports, Active Directory-<br />
Computer- und -Benutzerkonten, Active Directory-Gruppen, Programme, Systemdienste,<br />
ICMP-Typen und -Codes und Schnittstellentypen, zum Beispiel Drahtlos, Kabel oder<br />
Remotezugriff. Eingehende, ausgehende und Verbindungssicherheitsregeln werden mithilfe<br />
von Assistenten erstellt. Wie in Abbildung 5.5 zu sehen, stehen beim Erstellen einer neuen<br />
eingehenden Regel vier Typen zur Auswahl: Programm, Port, Vordefiniert oder Benutzerdefiniert.<br />
Der Assistent für ausgehende Regeln sieht fast genauso aus.
124 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Abbildung 5.5 Der Assistent für neue eingehende Regel<br />
Auf der ersten Seite des Assistenten geben Sie an, welche Art von Regel Sie erstellen wollen:<br />
Programm Wählen Sie Programm, falls Sie eine Regel anhand des Namens eines<br />
Programms definieren wollen. Sie müssen anschließend angeben, welche Aktion durchgeführt<br />
werden soll: Verbindung zulassen, Verbindung zulassen, wenn sie sicher ist oder<br />
Verbindung blocken. Und Sie müssen wählen, für welche Profile die Regel gelten soll<br />
(Domäne, Privat oder Öffentlich), und einen Namen für die Regel angeben.<br />
Port Wählen Sie Port aus, wenn Sie eine Regel anhand von TCP- oder UDP-Portnummern<br />
erstellen wollen. Sie müssen dann angeben, welche Aktion durchgeführt werden<br />
soll: Verbindung zulassen, Verbindung zulassen, wenn sie sicher ist oder Verbindung<br />
blocken. Und Sie müssen wählen, für welche Profile die Regel gelten soll (Domäne,<br />
Privat oder Öffentlich), und einen Namen für die Regel angeben.<br />
Vordefiniert Wählen Sie Vordefiniert, falls Sie eine Regel erstellen wollen, die auf<br />
einem der vordefinierten <strong>Die</strong>nste basiert. Sie müssen anschließend angeben, welche<br />
Aktion durchgeführt werden soll: Verbindung zulassen, Verbindung zulassen, wenn sie<br />
sicher ist oder Verbindung blocken.<br />
Benutzerdefiniert Wählen Sie Benutzerdefiniert, wenn Sie eine Regel erstellen wollen,<br />
die nicht einem der drei anderen Typen entspricht. Sie können die Merkmale beliebig<br />
kombinieren, zum Beispiel Programmname, Systemdienst, Protokolltyp und -nummer,<br />
lokale und Remoteports, lokale IP-Adressen und Remote-IP-Adressen. Sie müssen<br />
anschließend angeben, welche Aktion durchgeführt werden soll: Verbindung zulassen,<br />
Verbindung zulassen, wenn sie sicher ist oder Verbindung blocken. Und Sie müssen wählen,<br />
für welche Profile die Regel gelten soll (Domäne, Privat oder Öffentlich), und einen<br />
Namen für die Regel angeben.
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> 125<br />
Sie können sich die Eigenschaften von Regeln ansehen und sie ändern. Viele Einstellungen<br />
der vordefinierten Regeln lassen sich aber nicht ändern. Sie können die erweiterten Eigenschaften<br />
konfigurieren, indem Sie mit der rechten Maustaste auf den Namen der Regel klicken<br />
und den Befehl Eigenschaften wählen. Daraufhin öffnet sich ein Dialogfeld, das wie in<br />
Abbildung 5.6 aussieht.<br />
Abbildung 5.6 Erweiterte Eigenschaften einer Firewallregel<br />
Im Eigenschaftendialogfeld von ein- oder ausgehenden Regeln können Sie auf den folgenden<br />
Registerkarten verschiedene Einstellungen konfigurieren:<br />
Allgemein Hier können Sie den Namen der Regel sowie ihre Beschreibung definieren<br />
und einstellen, ob sie aktiviert ist und welche Aktion sie durchführt (Verbindungen zulassen,<br />
Nur sichere Verbindungen zulassen oder Verbindungen blockieren).<br />
Programme und <strong>Die</strong>nste Hier können Sie einstellen, ob die Regel für alle oder nur<br />
für bestimmte Programme, und für welchen <strong>Die</strong>nst sie gilt.<br />
Benutzer und Computer Falls die Aktion der Regel Nur sichere Verbindungen zulassen<br />
ist, können Sie hier angeben, welche Konten und Gruppen die geschützte Verbindung<br />
herstellen dürfen.<br />
Protokoll und Ports Hier können Sie Protokolltyp und -nummer der Regel, Quell-<br />
und Zielportnummern und ICMP-Einstellungen der Regel definieren.<br />
Bereich Hier können Sie die Quell- und Ziel-IP-Adressen der Regel festlegen.<br />
Erweitert Hier legen Sie die Profile und Schnittstellentypen für die Regel fest und<br />
stellen ein, ob Randüberquerung für die Regel erlaubt ist.<br />
Sie können eine neue Computerverbindungssicherheitsregel erstellen, indem Sie in der<br />
Strukturansicht mit der rechten Maustaste auf Verbindungssicherheitsregeln klicken und den<br />
Befehl Neue Regel wählen. Daraufhin wird der Assistent für neue Verbindungssicherheitsregel<br />
gestartet (Abbildung 5.7).
126 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Abbildung 5.7 Der Assistent für neue Verbindungssicherheitsregel<br />
Geben Sie auf der ersten Seite des Assistenten an, welche Art von Verbindungssicherheitsregel<br />
Sie erstellen wollen:<br />
Isolierung Wählen Sie Isolierung, um die Verbindungen anhand des Integritätsstatus<br />
oder der Domänenmitgliedschaft des anderen Computers einzuschränken. Sie müssen<br />
auch angeben, ob Sie Authentifizierung für ein- und ausgehenden Verkehr anfordern<br />
oder verpflichtend machen, welche Authentifizierungsmethode benutzt werden soll,<br />
für welche Profile die Regel gelten soll (Domäne, Privat oder Öffentlich) und welchen<br />
Namen die Regel bekommt. Isolierung auf Basis des Integritätsstatus eines Computers<br />
können Sie nur nutzen, wenn Sie Netzwerkszugriffsschutz (Network Access Protection,<br />
NAP) in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bereitstellen. NAP wird weiter unten<br />
in diesem Kapitel genauer behandelt.<br />
Authentifizierungsausnahme Wählen Sie Authentifizierungsausnahme, wenn Sie<br />
eine Liste mit den IP-Adressen der Hosts definieren wollen, die ihren Verkehr nicht<br />
authentifizieren oder schützen müssen. Sie müssen dann wählen, für welche Profile die<br />
Regel gelten soll (Domäne, Privat oder Öffentlich), und einen Namen für die Regel<br />
angeben.<br />
<strong>Server</strong>-zu-<strong>Server</strong> Wählen Sie <strong>Server</strong>-zu-<strong>Server</strong> aus, wenn Sie erzwingen wollen, dass<br />
Netzwerkverkehr zwischen bestimmten Hosts geschützt wird. Sie müssen die Endpunkte<br />
angeben, die den geschützten Verkehr austauschen, ob Authentifizierung für ein- und<br />
ausgehenden Verkehr angefordert oder verpflichtend gemacht wird, die Authentifizierungsmethode,<br />
für welche Profile die Regel gilt (Domäne, Privat oder Öffentlich) und<br />
einen Namen für die Regel. Solche Regeln werden üblicherweise bei der Bereitstellung
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> 127<br />
der <strong>Server</strong>isolierung verwendet. Weitere Informationen dazu finden Sie in Kapitel 14,<br />
»Schützen des Netzwerks«.<br />
Tunnel <strong>Die</strong>se Regel dient normalerweise dazu, Verkehr zu schützen, der zwischen<br />
zwei Gatewaycomputern über das Internet ausgetauscht wird. Sie müssen die Tunnelendpunkte<br />
anhand der IP-Adresse definieren, die Authentifizierungsmethode, für welche<br />
Profile die Regel gilt (Domäne, Privat oder Öffentlich) und einen Namen für die Regel.<br />
Benutzerdefiniert Wählen Sie Benutzerdefiniert, um eine Regel zu erstellen, die sich<br />
nicht mit einem der anderen Typen definieren lässt. Sie müssen die Endpunktcomputer<br />
anhand ihrer IP-Adresse angeben, ob Authentifizierung für ein- und ausgehenden Verkehr<br />
angefordert oder verpflichtend gemacht wird, die Authentifizierungsmethode, für<br />
welche Profile die Regel gilt (Domäne, Privat oder Öffentlich) und einen Namen für die<br />
Regel.<br />
Sie können die Eigenschaften von Verbindungssicherheitsregeln anzeigen und ändern, indem<br />
Sie mit der rechten Maustaste auf den Namen der Regel klicken und den Befehl Eigenschaften<br />
wählen. Daraufhin öffnet sich ein Dialogfeld, das ähnlich wie in Abbildung 5.8<br />
aussieht.<br />
Abbildung 5.8 Erweiterte Eigenschaften einer Verbindungssicherheitsregel<br />
Im Eigenschaftendialogfeld einer Regel können Sie auf den folgenden Registerkarten verschiedene<br />
Einstellungen konfigurieren:<br />
Allgemein Auf dieser Registerkarte können Sie den Namen der Regel sowie ihre Beschreibung<br />
ändern und festlegen, ob sie aktiviert ist.<br />
Computer Hier können Sie festlegen, bei welchen Computern (angegeben über ihre<br />
IP-Adressen) der Verkehr geschützt wird.<br />
Authentifizierung Auf dieser Registerkarte können Sie definieren, welche Authentifizierung<br />
für den geschützten Verkehr erforderlich ist.<br />
Erweitert Hier legen Sie die Profile und Schnittstellentypen für die Regel fest und<br />
stellen ein, ob die Regel IPsec-Tunneling erfordert.
128 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
<strong>Die</strong> Firewall verarbeitet Regeln in folgender Reihenfolge:<br />
1. <strong>Die</strong>nsteinschränkungen<br />
2. Verbindungssicherheitsregeln<br />
3. Authentifizierte Umgehung<br />
4. Blocken-Regeln<br />
5. Zulassen-Regeln<br />
6. Standardregeln<br />
Befehlzeilenverwaltung<br />
Netsh ist ein Befehlszeilentool, das eine Textshell zum Verwalten von Netzwerkkomponenten<br />
zur Verfügung stellt. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> können Sie die <strong>Windows</strong>-Firewall mit<br />
erweiterter <strong>Sicherheit</strong> mit den Befehlen konfigurieren, die im Kontext advfirewall zur Verfügung<br />
stehen. In Netsh wechseln Sie in einen bestimmten Kontext, wenn Sie die Komponenten<br />
innerhalb dieses Kontextes ändern wollen. Neben advfirewall stehen noch viele<br />
andere Kontexte zur Verfügung, zum Beispiel interface, nap, ras und rpc. Eine vollständige<br />
Beschreibung aller Fähigkeiten von Netsh würde den Umfang dieses Kapitels sprengen. Wir<br />
konzentrieren uns auf den Kontext zum Verwalten der Firewall.<br />
Sie müssen Netsh in einer Eingabeaufforderung aufrufen, die administrative Privilegien<br />
besitzt. <strong>Die</strong> UAC ist in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zwar in der Standardeinstellung nicht aktiviert,<br />
unter Umständen ist sie auf Ihren <strong>Server</strong>n aber aktiv; manche Leser führen vielleicht<br />
auch Verwaltungsaufgaben auf <strong>Windows</strong> Vista-Computern durch, wo die UAC standardmäßig<br />
aktiviert ist. Gehen Sie folgendermaßen vor, um eine Eingabeaufforderung mit<br />
erhöhten Rechten zu öffnen:<br />
1. Klicken Sie auf Start.<br />
2. Geben Sie im Suchfeld des Startmenüs Eingabeaufforderung ein.<br />
3. Klicken Sie mit der rechten Maustaste auf das Symbol Eingabeaufforderung und wählen<br />
Sie den Befehl Als Administrator ausführen.<br />
4. Klicken Sie auf Fortsetzen, falls sich eine UAC-Eingabeaufforderung öffnet. Je nachdem,<br />
wie die UAC in Ihrer Umgebung konfiguriert ist, müssen Sie möglicherweise auch<br />
Anmeldeinformationen für ein Konto mit administrativen Privilegien eingeben.<br />
5. Geben Sie in der Eingabeaufforderung den Befehl netsh ein, um das Tool zu starten.<br />
Geben Sie an der Netsh-Eingabeaufforderung advfirewall ein, um in den Kontext für die<br />
erweiterte Firewall zu wechseln. Hier stehen viele Befehle zur Verfügung. Sie können<br />
entweder ein Fragezeichen (?) oder help eingeben, um sich eine Liste der Befehle anzeigen<br />
zu lassen, die in Ihrem momentan ausgewählten Kontext zur Verfügung stehen.<br />
Folgende Befehle stehen im Kontext advfirewall zur Verfügung:<br />
Dump Zeigt ein Konfigurationsskript an.<br />
Export Exportiert die aktuelle Richtlinie in eine Datei.<br />
Import Importiert eine Richtliniendatei in den aktuellen Richtlinienspeicher.<br />
Reset Setzt die Richtlinie auf die Standardrichtlinie zurück.<br />
Set Legt profilspezifische oder globale Einstellungen fest.<br />
Show Zeigt Profil- oder globale Eigenschaften an.
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> 129<br />
Außerdem stehen einige Unterkontexte zur Verfügung. Sie können in einen solchen Unterkontext<br />
wechseln, indem Sie seinen Namen an der netsh advfirewall-Eingabeaufforderung<br />
eingeben.<br />
Consec Wechselt in den netsh advfirewall consec-Kontext, wo Sie Verbindungssicherheitsregeln<br />
konfigurieren können.<br />
Firewall Wechselt in den netsh advfirewall firewall-Kontext, wo Sie ein- und ausgehende<br />
Firewallregeln anzeigen und konfigurieren können.<br />
Monitor Wechselt in den netsh advfirewall monitor-Kontext, wo Sie <strong>Sicherheit</strong>szuordnungen<br />
anzeigen und überwachen können.<br />
Sie können mit Netsh ausgefeilte Skripts erstellen, um Konfigurationsvorgänge zu automatisieren,<br />
die Sie auf mehreren Computern durchführen müssen. Das kann für Computer sehr<br />
nützlich sein, die keine Domänenmitglieder sind, zum Beispiel Computer in einem Testlabor<br />
oder einem geschützten Subnetz, das für Besucher aus dem Internet erreichbar ist.<br />
Abbildung 5.9 Das Konfigurationsfenster der <strong>Windows</strong>-Firewall zeigt an, dass automatisch<br />
das Domänenetzwerkprofil angewendet wurde<br />
Netzwerkprofile<br />
<strong>Die</strong> Fähigkeit, sich Netzwerke zu merken und sie zu erkennen, ist zwar auf mobilen Computern<br />
wichtiger, aber es ist immer nützlich, wenn Sie genau wissen, wie <strong>Windows</strong> festlegt, mit<br />
welcher Art Netzwerk es verbunden ist. Wenn ein Domänencomputer sich erfolgreich an<br />
seiner Domäne angemeldet hat, wird automatisch das Domänenprofil angewendet (Abbildung<br />
5.9). <strong>Die</strong>ses Profil können Sie nicht explizit auswählen. Wenn der Computer mit einem<br />
Netzwerk verbunden ist, das durch eine äußere Firewall geschützt ist, können Sie das private<br />
Profil auswählen, sofern Sie administrative Privilegien besitzen. Wenn der Computer direkt<br />
ans Internet angeschlossen ist, sollten Sie das öffentliche Profil wählen. Wahrscheinlich ist
130 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Ihnen aufgefallen, dass das Dialogfeld drei Auswahlmöglichkeiten bietet. Wenn Sie Arbeitsplatz<br />
oder Zu Hause auswählen, wird jeweils das private Profil angewendet.<br />
Im Fall einer Netzwerkänderung, wenn zum Beispiel eine neue IP-Adresse oder eine neue<br />
Netzwerkschnittstelle eingestellt wird, bemerkt der NLA-<strong>Die</strong>nst (Network Position Awareness)<br />
diese Änderung. NLA verwaltet eine Datenbank mit vorher benutzten Netzwerken,<br />
sodass er sie erkennen kann, wenn der Computer erneut mit einem davon verbunden wird.<br />
<strong>Die</strong> Datenbank enthält Informationen darüber, welche Schnittstelle mit dem Netzwerk verbunden<br />
ist, ob der Computer bei einem Domänencontroller authentifiziert wurde und die<br />
MAC-Adresse des Standardgateways. Falls NLA das Netzwerk wiedererkennt, wird das<br />
passende Profil automatisch ausgewählt und die Firewall wendet die entsprechende Richtlinie<br />
an. NLA versucht, das am stärksten eingeschränkte Profil zu verwenden. Falls Sie also<br />
gleichzeitig mit dem Unternehmensnetzwerk und über ein Modem mit Ihrem Mobilfunkanbieter<br />
verbunden sind, wird das öffentliche Profil angewendet, nicht das Domänenprofil.<br />
Wenn Sie eine VPN-Verbindung in Ihr Unternehmensnetzwerk herstellen, wird das öffentliche<br />
oder private Profil angewendet, je nachdem, welches Profil Sie angegeben haben, als<br />
Sie das System an Ihr Heimnetzwerk (oder Ihren momentanen Standort) angeschlossen<br />
haben. Das bedeutet, dass Regeln, die für die Remoteverwaltung des Systems eingerichtet<br />
wurden, durch das restriktivere aktive Profil überschrieben werden. Es ist wichtig zu wissen,<br />
dass immer nur jeweils ein Profil aktiv sein kann. Es ist immer das am stärksten eingeschränkte<br />
Profil aktiv, falls der Computer mit mehreren Netzwerken verbunden ist, die<br />
unterschiedliche Profile nutzen.<br />
Vorsicht Falls Sie mithilfe von Gruppenrichtlinien ausgehende Verbindungen blockieren, sollten Sie alle<br />
Ihre Anwendungen sorgfältig testen, andernfalls könnten sie lahmgelegt werden. Computer können nicht<br />
einmal ihre Domänengruppenrichtlinien aktualisieren, falls Sie ausgehende Regeln falsch konfiguriert<br />
haben.<br />
Routing- und RAS-<strong>Die</strong>nste<br />
<strong>Die</strong>ses Kapitel setzt voraus, dass Sie bereits mit Vorgängerversionen der Routing- und RAS-<br />
<strong>Die</strong>nste (Routing and Remote Access Services, RRAS) vertraut sind. Daher konzentriert es<br />
sich darauf, was in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> neu ist und was sich verändert hat. <strong>Die</strong>ses Kapitel<br />
beschäftigt sich insbesondere mit dem neuen Feature, das ich für die wichtigste Ergänzung<br />
halte: SSTP (Secure Socket Tunneling Protocol), eine SSL-VPN-Technologie. Technologien<br />
wie diese waren bereits vorher als separate Produkte von Microsoft und Fremdherstellern<br />
verfügbar. Falls Sie sich erst in die Grundlagen von RRAS einarbeiten müssen, sollten Sie<br />
sich die Links im Abschnitt »Weitere Informationen« am Ende dieses Kapitels ansehen.<br />
Wichtig Sie könnten übersehen, wie Sie RRAS mit dem Assistenten "Rollen hinzufügen" installieren<br />
können, wenn Sie sich nicht die Beschreibungen aller <strong>Server</strong>rollen durchlesen. RRAS ist Teil der Rolle<br />
Netzwerkrichtlinien- und Zugriffsdienste. Wenn Sie diese Rolle installieren, wird RRAS unter der Bezeichnung<br />
Routing- und RAS-<strong>Die</strong>nste als einer der verfügbaren Rollendienste aufgeführt.
Routing- und RAS-<strong>Die</strong>nste 131<br />
Verbesserungen in RRAS<br />
<strong>Die</strong> folgenden Abschnitte fassen kurz die neuen und verbesserten Fähigkeiten in RRAS von<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zusammen.<br />
Unterstützung für IPv6<br />
Sowohl der Remotezugriffsclient als auch RRAS bieten vollständige Unterstützung für IPv6<br />
bei PPP- (Point-to-Point Protocol) und L2TP/IPsec-VPN-Verbindungen (Layer Two Tunneling<br />
Protocol mit IPsec). Zusätzliche Unterstützung für IPv6 ist im DHCPv6-Relay-Agent,<br />
RADIUS und statischen Paketfiltern verfügbar.<br />
NAP-Erzwingung für Remotezugriff-VPN-Verbindungen<br />
RRAS kann jetzt NAP-Anforderungen auf eingehenden VPN-Verbindungen erzwingen.<br />
Weitere Informationen finden Sie im Abschnitt »Netzwerkzugriffsschutz« weiter unten in<br />
diesem Kapitel.<br />
Überarbeiteter Assistent zum Herstellen von Verbindungen<br />
<strong>Die</strong> Konfiguration von DFÜ-, Breitbandinternet- und VPN-Verbindungen wurde im Assistenten<br />
zum Herstellen von Verbindungen vereinfacht.<br />
SSTP<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> unterstützt einen neuen Typ VPN-Tunnel, der meist als SSL-VPN<br />
bezeichnet wird. SSTP (Secure Socket Tunneling Protocol) erlaubt es, Verkehr durch Firewalls,<br />
Proxyserver und NAT-Geräte (Network Address Translation) zu leiten, die PPTP- und<br />
L2TP/IPsec-Verbindungen blockieren. PPP-Verkehr wird im SSL-Kanal des Protokolls<br />
HTTPS gekapselt. Das bedeutet, dass der Verkehr durch weniger Netzwerksicherheitsgeräte<br />
blockiert und durch starke Verschlüsselung und Integritätsprüfung geschützt wird. Wenn ein<br />
Benutzer, der unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> oder <strong>Windows</strong> Vista mit Service Pack 1 arbeitet,<br />
eine SSTP-VPN-Verbindung aufbaut, finden folgende Vorgänge statt:<br />
1. Der Client fordert eine SSL-Sitzung mit dem SSTP-<strong>Server</strong> an.<br />
2. Der SSTP-<strong>Server</strong> sendet sein Computerzertifikat an den Client.<br />
3. Der Client überprüft das Computerzertifikat, legt die Verschlüsselungsmethode fest,<br />
generiert einen Sitzungsschlüssel, verschlüsselt den Sitzungsschlüssel mit dem öffentlichen<br />
Schlüssel des SSTP-<strong>Server</strong>s aus dem Zertifikat und sendet den verschlüsselten<br />
Sitzungsschlüssel an den SSTP-<strong>Server</strong>.<br />
4. Der SSTP-<strong>Server</strong> entschlüsselt den Sitzungsschlüssel mit dem privaten Schlüssel, der<br />
dem Computerzertifikat zugeordnet ist. Der gesamte künftige Verkehr wird mit dem<br />
SSL-Sitzungsschlüssel verschlüsselt.<br />
5. Der Client handelt einen SSTP-Tunnel mit dem SSTP-<strong>Server</strong> aus.<br />
6. Der Client fordert eine PPP-Verbindung mit dem SSTP-<strong>Server</strong> über den SSTP-Tunnel<br />
an. Während der Aushandlung stellt der Benutzer seine Anmeldeinformationen bereit,<br />
und die IPv4- oder IPv6-Einstellungen werden festgelegt.<br />
7. Der Client beginnt, IPv6- oder IPv4-Verkehr über die PPP-Verbindung zu senden.
132 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Unterstützung für mehrere Standorte im Verbindungs-Manager-Verwaltungskit<br />
Das Verbindungs-Manager-Verwaltungskit (Connection Manager Administration Kit,<br />
CMAK) erlaubt es, Verbindungs-Manager-Profile auf einem <strong>Server</strong> mit beliebigen Lokalisierungseinstellungen<br />
zu entwickeln, die dann auf Clients mit beliebigen Lokalisierungseinstellungen<br />
bereitgestellt werden können. Das vereinfacht die Verwaltung mit dem Verbindungs-Manager-Verwaltungskit.<br />
Unterstützung für dynamische DNS-Updates im Verbindungs-Manager<br />
Verbindungs-Manager-Clients unterstützen jetzt die Registrierung von Clientnamen und<br />
-adressen mit Dynamic DNS.<br />
Unterstützung für das Netzwerkdiagnose-Framework<br />
RRAS unterstützt jetzt das Netzwerkdiagnose-Framework für Clientverbindungen, was die<br />
Verwaltung und Problembehandlung von RRAS einfacher macht.<br />
Verbesserte WinLogin-Unterstützung<br />
Zugriffsanbieter von Fremdherstellern können ihre Verbindungen so konfigurieren, dass sie<br />
automatisch Remotezugriffsverbindungen aufbauen, wenn sich ein Benutzer anmeldet.<br />
Zusätzliche kryptografische Algorithmen<br />
L2TP/IPsec-Verbindungen unterstützen jetzt AES (Advanced Encryption Standard) mit 128-<br />
und 256-Bit-Schlüsseln. Schwächere Algorithmen wie zum Beispiel 40- und 56-Bit-MPPE<br />
(Microsoft Point-to-Point) für PPTP und DES mit MD5 (Message Digest 5) für L2TP/IPsec<br />
sind standardmäßig deaktiviert. Sie können 40- und 56-Bit-MPPE für PPTP-Verbindungen<br />
aktivieren, indem Sie den DWORD-Wert HKEY_LOCAL_MACHINE\System\Current-<br />
ControlSet\Services\Rasman\Parameters\AllowPPTPWeakCrypto auf 1 setzen und den<br />
Computer neu starten. DES mit MD5 für L2TP/IPsec-Verbindungen können Sie aktivieren,<br />
indem Sie den DWORD-Wert HKEY_LOCAL_MACHINE\System\CurrentControlSet\<br />
Services\Rasman\Parameters\AllowL2TPWeakCrypto auf 1 setzen und den Computer neu<br />
starten. Natürlich sollten Sie erwägen, Ihre geistige Gesundheit untersuchen zu lassen, wenn<br />
Sie einen Schalter aktivieren, der »WeakCrypto« (schwache Kryptografie) heißt.<br />
Robuste Zertifikatsprüfung für VPN-Verbindungen<br />
RRAS unterstützt eine sorgfältigere Zertifikatsprüfung, mit der Man-in-the-Middle-Angriffe<br />
verhindert werden sollen. Der VPN-Client prüft zusätzlich, ob die Felder Antragsteller<br />
oder Alternativer Antragstellername im Zertifikat des VPN-<strong>Server</strong>s dem Namen oder der<br />
IP-Adresse des VPN-<strong>Server</strong>s entsprechen, die in der VPN-Verbindung benutzt werden. Sie<br />
können diese zusätzliche Zertifikatprüfung auf dem VPN-Client folgendermaßen deaktivieren:<br />
Öffnen Sie das Eigenschaftendialogfeld für die Verbindung, klicken Sie auf die Registerkarte<br />
Netzwerk und dort auf die Schaltfläche IPSec-Einstellungen und deaktivieren Sie<br />
das Kontrollkästchen <strong>Die</strong> Namen- und Verwendungsattribute des <strong>Server</strong>zertifikats überprüfen<br />
(Abbildung 5.10).
Abbildung 5.10 Deaktivieren der erweiterten Zertifikatprüfung bei einer VPN-Verbindung<br />
Internet Protocol Security 133<br />
Internet Protocol Security<br />
<strong>Die</strong>ser Abschnitt beginnt mit einer kurzen Wiederholung der Grundlagen von IPsec (Internet<br />
Protocol Security), beschäftigt sich dann ausführlich mit den neuen Fähigkeiten von IPsec<br />
in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und zeigt Ihnen schließlich, wie Sie mithilfe dieser Technologie<br />
<strong>Server</strong> und Domänen isolieren, was die Grundlage für Ihre NAP-Architektur bildet.<br />
Grundlagen von IPsec<br />
IPsec ist ein offener Standard, mit dem Informationen, die durch Netzwerke befördert werden,<br />
vor unautorisiertem Zugriff und Manipulation geschützt werden. Dazu kann eine Kombination<br />
von Authentifizierungsprotokollen, Datenverschlüsselung und digitalen Signaturen<br />
eingesetzt werden. Wenn zwei Hosts beginnen, mit IPsec zu kommunizieren, richten sie erst<br />
einmal zwei <strong>Sicherheit</strong>szuordnungen (engl. security association) ein. In Phase 1 oder dem<br />
Hauptmodus (engl. main mode) authentifizieren sich die Hosts gegenseitig. In Phase 2 oder<br />
dem Schnellmodus (engl. quick mode) handeln die Hosts aus, welche Protokolle sie einsetzen,<br />
um den Netzwerkverkehr digital zu signieren oder zu verschlüsseln. Jedes Paket kann<br />
signiert werden, damit der Empfänger sicher sein kann, dass es vom vertrauenswürdigen<br />
Host stammt und nicht manipuliert wurde. Jedes Paket kann verschlüsselt werden, um die<br />
Daten zu schützen, sodass niemand außer dem Empfänger darauf zugreifen kann. Sie können<br />
IPsec-Regeln konfigurieren, um einen oder beide Schutzmechanismen zu implementieren.
134 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
IPsec-Authentifizierung<br />
<strong>Sicherheit</strong>szuordnungen werden mit dem IKE-Protokoll (Internet Key Exchange) ausgehandelt,<br />
das wiederum drei andere Protokolle umfasst: ISAKMP, Oakley und SKEME. Über<br />
IKE einigen sich die beiden Hosts, wie Authentifizierungsnachrichten aufgebaut und ausgetauscht<br />
werden. (<strong>Die</strong> vollständigen Details sind recht komplex und würden den Umfang<br />
dieses Kapitels sprengen.) <strong>Die</strong> Hosts können sich über eine Reihe unterschiedlicher Methoden<br />
authentifizieren. Unter anderem stehen zur Wahl:<br />
Kerberos Version 5 Falls beide Hosts in derselben Active Directory-Gesamtstruktur<br />
liegen, können Sie Kerberos für die gegenseitige Authentifizierung einsetzen. Kerberos<br />
ist ideal, wenn Sie keine Infrastruktur für öffentliche Schlüssel (Public Key Infrastructure,<br />
PKI) haben und keine Vertrauensstellungen mit Hosts außerhalb Ihrer Gesamtstruktur<br />
eingerichtet wurden.<br />
Digitale Zertifikate Falls die Hosts Zugriff auf eine robuste PKI haben, können digitale<br />
Zertifikate die ideale Authentifizierungsmethode sein. <strong>Windows</strong> XP und neuere Versionen<br />
der Microsoft-Betriebssysteme unterstützen die automatisierte Verteilung von<br />
Computerzertifikaten, was eines der größten Probleme beim Verwalten einer großen PKI<br />
beseitigt: das Verteilen der Zertifikate. Solange jeder Host ein Zertifikat hat, das von<br />
einer Zertifizierungsstelle (Certificate Authority, CA) signiert wurde, der der andere<br />
Host vertraut, authentifizieren sie sich gegenseitig.<br />
Vorinstallierte Schlüssel Unterstützung für vorinstallierte Schlüssel (engl. preshared<br />
keys) ist nur enthalten, weil der IPsec-Standard es vorschreibt. <strong>Die</strong>se Methode ist eigentlich<br />
nur sinnvoll, während Sie Ihre IPsec-Richtlinien entwickeln und testen. Jeder Host,<br />
der Teil der Richtlinie ist, muss denselben Schlüssel haben. Genauso wie es unsinnig ist,<br />
wenn mehrere Benutzer dasselbe Kennwort verwenden, ist es auch unsinnig, wenn mehrere<br />
Computer denselben Schlüssel für die Authentifizierung einsetzen.<br />
Weiter unten in diesem Abschnitt wird beschrieben, welche neuen Authentifizierungsfähigkeiten<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zur Verfügung stellt.<br />
IPsec-Kommunikationsmodi<br />
IPsec-Kommunikation findet in einem von zwei Modi statt: Transportmodus oder Tunnelmodus.<br />
Der Transportmodus (engl. transport mode) wird verwendet, wenn Sie wollen, dass mehrere<br />
Computer untereinander mit IPsec kommunizieren. In diesem Modus authentifizieren sich<br />
die beiden Hosts in Phase 1 gegenseitig und einigen sich dann auf Signierungs- und Verschlüsselungsverfahren<br />
für den Verkehr. Auch wenn der Name genau das Gegenteil zu behaupten<br />
scheint, wird genau dieser Modus für L2TP-VPNs zwischen Remoteclient und<br />
VPN-<strong>Server</strong> verwendet.<br />
Der Tunnelmodus (engl. tunnel mode) eignet sich, um Standort-zu-Standort-Verbindungen<br />
zu schützen, die ein nichtvertrauenswürdiges Netzwerk wie das Internet durchlaufen. Anders<br />
ausgedrückt: <strong>Die</strong> beiden Hosts sind jeweils Gateways, die Verkehr zwischen den Standorten<br />
weiterleiten. Im Gateway wird ausgehender Verkehr verschlüsselt und an das Remotegateway<br />
gesendet, wo er entschlüsselt und über das interne Netzwerk an sein endgültiges Ziel<br />
weitergeleitet wird.
Internet Protocol Security 135<br />
IPsec-Methoden<br />
Falls eine IPsec-Regel fordert, dass die Hosts <strong>Sicherheit</strong> aushandeln, stehen dafür zwei<br />
Methoden zur Verfügung, die einzeln oder kombiniert verwendet werden können: ESP<br />
(Encapsulated Security Payload) oder AH (Authentication Header).<br />
ESP kann sowohl Vertraulichkeit (mithilfe von Verschlüsselung) als auch Integrität (mithilfe<br />
von Signaturen) gewährleisten. Verschlüsselung und Signatur betreffen die Nutzdaten und<br />
TPC/UDP-Header jedes Pakets, aber nicht die IP-Adresse. Das bedeutet, dass ESP-Verkehr<br />
mithilfe von Unterstützungstechnologien wie zum Beispiel NAT-Traversal (NAT-T) über<br />
NAT-Geräte geleitet werden kann. Es ist auch möglich, in ESP eine Nullverschlüsselung zu<br />
nutzen, das bedeutet, dass alle Pakete signiert, aber nicht verschlüsselt werden. Ähnlich wie<br />
bei AH heißt das, dass Sie sicher sein können, dass Verkehr nicht manipuliert wurde, während<br />
er zwischen den Hosts unterwegs war. <strong>Die</strong>s ist die Standardmethode, wenn Sie Sitzungen<br />
zwischen zwei Hosts authentifizieren lassen.<br />
AH stellt die Nachrichtenintegrität mit digitalen Signaturen sicher, die über das gesamte<br />
Paket inklusive IP-Header berechnet werden (also mit Quell- und Ziel-IP-Adressen). AH hat<br />
zwei wichtige Einschränkungen: Es bietet keine Vertraulichkeit, weil es keine Datenverschlüsselung<br />
unterstützt, und AH-Verkehr kann keine NAT-Geräte durchqueren, weil diese<br />
Geräte die IP-Adresse des internen Hosts in jedem Paket austauschen, bevor sie es weiterleiten.<br />
Wichtig AH wird in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> nicht mehr unterstützt. <strong>Die</strong>se Methode wird nur aus Gründen<br />
der Vollständigkeit beschrieben.<br />
IPsec-Regeln und -Richtlinien<br />
Eine IPsec-Richtlinie besteht aus einer oder mehreren IPsec-Regeln. Jeder Host kann nur<br />
eine einzige IPsec-Richtlinie haben. Jede Regel hat eine Filterliste und eine Filteraktion.<br />
Filterlisten legen die Merkmale des Verkehrs fest, für den die Regel gilt, zum Beispiel<br />
Adressen, Ports und Protokolle. Filteraktionen definieren, was die Regel mit dem Verkehr<br />
macht: zulassen, blockieren oder <strong>Sicherheit</strong> aushandeln. <strong>Die</strong> ersten beiden Aktionen ähneln<br />
dem, was eine Firewall bei der Portfilterung tut. Einige <strong>Sicherheit</strong>sleitfäden für <strong>Windows</strong><br />
2000, <strong>Windows</strong> XP und <strong>Windows</strong> <strong>Server</strong> 2003 beschrieben auch, wie sich mithilfe der<br />
IPsec-Filterung eine hostbasierte Firewall nachbilden lässt. Aber die IPsec-Filterung arbeitet<br />
nicht statusbehaftet, das bedeutet, dass ihre Leistungsfähigkeit als Firewallersatz recht beschränkt<br />
ist. Wenn <strong>Sicherheit</strong> ausgehandelt wird, teilt die Regel dem Host mit, ob ESP oder<br />
AH benötigt wird, ob ESP oder AH angefordert werden, aber ungeschützter Verkehr erlaubt<br />
wird, und die Details der zu benutzenden Authentifizierungs-, Verschlüsselungs- und Signierungsprotokolle.<br />
Neue Fähigkeiten in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
<strong>Die</strong> folgenden Abschnitte beschreiben, welche Verbesserungen in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> an<br />
IPsec vorgenommen wurden.<br />
Integrierte Firewall- und IPsec-Konfiguration<br />
In <strong>Windows</strong> XP und <strong>Windows</strong> <strong>Server</strong> 2003 werden Regeln für die <strong>Windows</strong>-Firewall und<br />
IPsec getrennt voneinander konfiguriert. Weil beide eingehenden Verkehr blockieren oder<br />
erlauben können, kann es passieren, dass versehentlich redundante oder sogar widersprüch-
136 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
liche Regeln erstellt werden. <strong>Die</strong>se Arten von Konfigurationsfehlern können schwierig aufzuspüren<br />
sein. <strong>Die</strong> neuen grafischen und Befehlszeilenverwaltungstools fassen die Konfiguration<br />
von Firewall und IPsec zusammen. Das vereinfacht die Verwaltung und verringert die<br />
Gefahr einer Fehlkonfiguration. In der Vergangenheit unterstützten Firewall und IPsec unterschiedliche<br />
Merkmale für die Elemente in Regeln. Zum Beispiel konnten Sie eine Firewallausnahme<br />
anhand des Anwendungsnamens erstellen, aber IPsec bot diese Möglichkeit<br />
nicht.<br />
Vereinfachte IPsec-Richtlinienkonfiguration<br />
Vor <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> mussten Sie einen Satz Regeln konfigurieren,<br />
um Verkehr zu schützen, und einen Satz Regeln, um Ausnahmen für geschützten Verkehr zu<br />
definieren, die für Infrastrukturserver wie DHCP, DNS und Domänencontroller benötigt<br />
wurden. Während der Startphase konnte der Clientcomputer nicht auf diese <strong>Die</strong>nste zugreifen,<br />
falls der <strong>Server</strong> IPsec erforderte. <strong>Die</strong> neue Version von IPsec kann dieses Problem beseitigen,<br />
indem sie gleichzeitig IPsec-geschützte und Klartextverbindungen aufbaut. Falls<br />
der andere Host nicht auf die IPsec-Anforderung antwortet, setzt der Host die Kommunikation<br />
im Klartext fort. Falls er eine Antwort auf die IPsec-Anforderung empfängt, setzt er die<br />
Kommunikation im Klartext nur so lange fort, bis die Aushandlung abgeschlossen ist, danach<br />
ist der gesamte weitere Verkehr geschützt. Das passiert offensichtlich nur, falls IPsec<br />
angefordert, aber nicht verpflichtend gemacht wird. <strong>Die</strong>ses Verhalten ist zwar optional, wird<br />
aber empfohlen, weil es die IPsec-Richtlinien in einem Unternehmen gewaltig vereinfacht.<br />
<strong>Die</strong>ses neue Verhalten ermöglicht auch schnellere Netzwerkverbindungen, weil <strong>Windows</strong><br />
XP- und <strong>Windows</strong> <strong>Server</strong> 2003-Hosts, die IPsec anfordern, aber auch Klartextkommunikation<br />
erlauben, bis zu 3 Sekunden warten, ob die IPsec-Kommunikation fehlschlägt, bevor sie<br />
auf ungeschützte Kommunikation umschalten.<br />
Verbesserte IPsec-Authentifizierung<br />
Neben der Authentifizierung mit Kerberos, digitalen Zertifikaten und vorinstallierten Schlüsseln<br />
können <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Systeme auch eine Authentifizierung mit Integritätszertifikaten<br />
durchführen. Integritätszertifikate werden an Clients von einer Integritätsregistrierungsstelle<br />
(Health Registration Authority, HRA) vergeben, wenn der Client bewiesen hat,<br />
dass sein Integritätsstatus die Anforderungen der aktuellen Richtlinie erfüllt. <strong>Die</strong>s ist eine<br />
Komponente von NAP, das im Abschnitt »Netzwerkzugriffsschutz« weiter unten in diesem<br />
Kapitel beschrieben wird. Für IPsec stehen unter anderem folgende Authentifizierungsmethoden<br />
zur Verfügung:<br />
Computerintegritätszertifikat<br />
Benutzerzertifikat<br />
NTLMv2-Anmeldeinformationen des Computers<br />
NTLMv2-Anmeldeinformationen des angemeldeten Benutzers<br />
Kerberos-Anmeldeinformationen des angemeldeten Benutzers<br />
Das bedeutet, dass Sie für die anfängliche Computerauthentifizierung Kerberos-Anmeldeinformationen<br />
und danach ein Integritätszertifikat fordern können. <strong>Die</strong> zweite Authentifizierung<br />
kann auch ohne die erste genutzt werden.
Internet Protocol Security 137<br />
Verbesserte Unterstützung für Lastausgleich und Clusterserver<br />
Ältere Versionen von IPsec brauchen üblicherweise 3 bis 6 Sekunden, um nach einer Administrationsänderung<br />
die Kommunikation wieder aufzunehmen. Wenn ein Clusterknoten ausfiel,<br />
konnte es sogar bis zu 2 Minuten dauern. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista<br />
ist die Zeitüberschreitungsschwelle viel kürzer. Normalerweise ist sie so schnell, dass die<br />
Anwendung weiterlaufen kann. Statt darauf zu warten, dass ein ausgefallener Clusterknoten<br />
aufgrund der Zeitüberschreibung entdeckt wird, überwacht IPsec TCP-Verbindungen aktiv<br />
nach eingerichteten <strong>Sicherheit</strong>szuordnungen (Security Association, SA). Falls die SA beginnt,<br />
Pakete erneut zu senden, handelt IPsec neue SAs aus, um zu versuchen, die Verbindung<br />
zu einem anderen Knoten im Cluster wiederherzustellen.<br />
IPsec-Schutz zwischen Client und Domänencontroller<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> unterstützt IPsec zwischen Domänencontrollern und Mitgliedscomputern<br />
in zwei Modi. Erstens können Sie eine Richtlinie konfigurieren, die IPsec anfordert,<br />
aber nicht verpflichtend macht; Domänencontroller schützen dann den meisten Verkehr mit<br />
Domänenmitgliedern, erlauben aber auch Klartextkommunikation für Domänenbeitritte und<br />
andere Verkehrstypen. Zweitens können Sie eine Richtlinie konfigurieren, die IPsec vorschreibt<br />
und NTLMv2-Authentifizierung erlaubt; in diesem Fall wird die gesamte Kommunikation<br />
mit Domänencontrollern geschützt. <strong>Die</strong>se restriktivere Konfiguration funktioniert,<br />
weil NTLMv2-Benutzeranmeldeinformationen für die Authentifizierung verwendet werden<br />
können. Wenn ein Computer, der unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> oder <strong>Windows</strong> Vista läuft, versucht,<br />
der Domäne beizutreten, wird der Benutzer aufgefordert, Benutzernamen und Kennwort<br />
eines Domänenkontos einzugeben, das Computerkonten hinzufügen darf. <strong>Die</strong>ses neue<br />
Verhalten steht nur auf Clientcomputern zur Verfügung, die unter <strong>Windows</strong> Vista oder <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> laufen, und auf Domänencontrollern, die unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
laufen.<br />
Integrierte IPv4- und IPv6-Unterstützung<br />
<strong>Die</strong> Unterstützung für IPsec mit IPv6 ist identisch mit der Unterstützung für IPsec mit IPv4,<br />
was vor <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> noch nicht der Fall war. IPsec-Richtlinienregeln<br />
für IPv6 und IPv4 werden auf dieselbe Weise mit denselben Tools konfiguriert,<br />
zum Beispiel in der Konsole <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong>.<br />
Integration mit Netzwerkzugriffsschutz<br />
Sie können NAP verwenden, um zu erzwingen, dass Hosts eine zweite Authentifizierung mit<br />
einem Integritätszertifikat durchführen. So wird sichergestellt, dass jeder Host die Integritätsanforderungen<br />
Ihrer Organisation erfüllt. Weitere Informationen finden Sie im Abschnitt<br />
»Netzwerkzugriffsschutz« weiter unten in diesem Kapitel.<br />
Weitere Konfigurationsoptionen für geschützte Kommunikation<br />
Verbindungssicherheitsregeln unterstützen folgende neue Einstellungen:<br />
Bereiche von IP-Adressen Sie können jetzt numerische Bereiche angeben, zum Beispiel<br />
192.168.10.15 bis 192.168.10.68.<br />
Für alle Drahtlosadapter Drahtlosadapter sind ein weiterer Schnittstellentyp, den Sie<br />
für eine Regel angeben können.
138 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Neue Kryptografieunterstützung<br />
Während sich die Techniken der Kryptografie weiterentwickeln, fügt Microsoft ständig<br />
Unterstützung für neuere, robustere Algorithmen zu seinen Betriebssystemen hinzu. <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista bieten erstmals Unterstützung für folgende Algorithmen,<br />
um Masterschlüsselmaterial während der Hauptmodusaushandlung abzuleiten:<br />
Diffie-Hellman (DH) Group 19 <strong>Die</strong>s ist ein auf elliptischen Kurven beruhender Algorithmus,<br />
der eine 256 Bit lange zufällige Kurvengruppe verwendet (NIST-ID P-256).<br />
DH Group 20 <strong>Die</strong>s ist ein auf elliptischen Kurven beruhender Algorithmus, der eine<br />
384 Bit lange zufällige Kurvengruppe verwendet (NIST-ID P-384).<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista unterstützen jetzt folgende neue Datenverschlüsselungsalgorithmen:<br />
AES (Advanced Encryption Standard) mit CBC (Cipher Block Chaining) und 128-Bit-<br />
Schlüssellänge (AES 128)<br />
AES mit CBC und 192-Bit-Schlüssellänge (AES 192)<br />
AES mit CBC und 256-Bit-Schlüssellänge (AES 256)<br />
Vorsicht Ältere <strong>Windows</strong>-Versionen, zum Beispiel <strong>Windows</strong> 2000, <strong>Windows</strong> XP und <strong>Windows</strong> <strong>Server</strong><br />
2003, implementieren einige dieser Algorithmen für andere Funktionen, sie unterstützen sie aber nicht für<br />
den Einsatz von IPsec.<br />
Unterstützung für das Netzwerkdiagnose-Framework<br />
IPsec unterstützt jetzt das Netzwerkdiagnose-Framework (Network Diagnostics Framework,<br />
NDF). NDF ist eine Infrastruktur sowie ein Satz integrierter Komponenten, die versuchen,<br />
Verbindungsprobleme automatisch zu diagnostizieren und zu reparieren. Wenn ein Problem<br />
auftaucht, bietet NDF dem Benutzer seine Hilfe an, um festzustellen, wo der Fehler liegt,<br />
und das Problem zu beseitigen. <strong>Die</strong>s geschieht direkt in dem Kontext, in dem das Problem<br />
aufgetreten ist. Das bedeutet, dass der Benutzer die Meldungen von NDF in der Anwendung<br />
angezeigt bekommt, in der das Problem aufgetreten ist.<br />
Erweiterte Ereignisse und Systemmonitor-Leistungsindikatoren<br />
Es wurden neue IPsec-spezifische Überwachungsereignisse hinzugefügt, und der Text vorhandener<br />
Ereignisse wurde aktualisiert, sodass er mehr nützliche Informationen enthält, die<br />
Ihnen bei der Behandlung von IPsec-Problemen helfen. Außerdem wurden IPsec-Leistungsindikatoren<br />
hinzugefügt.<br />
Erweiterte Authentifizierungsumgehung<br />
Sie können Umgehungsregeln konfigurieren, sodass Verbindungen von bestimmten Computern<br />
die anderen IPsec-Regeln umgehen können. Das bedeutet, dass Sie den Verkehr von<br />
allen Hosts blockieren können, aber den authentifizierten Computern erlauben, diese Blockierung<br />
zu umgehen. Das ist nützlich, wenn Sie <strong>Sicherheit</strong>slückenscannern oder anderen<br />
Verwaltungstools erlauben wollen, auf geschützte Hosts zuzugreifen.
Netzwerkzugriffsschutz 139<br />
Netzwerkzugriffsschutz<br />
Netzwerkzugriffsschutz (Network Access Protection, NAP) ist eine Plattform, mit der Sie<br />
erzwingen können, dass Hosts bestimmte Integritätsanforderungen erfüllen, bevor sie Zugriff<br />
auf Netzwerkressourcen erhalten. NAP kann sicherstellen, dass das System bestimmte<br />
Updates enthält und bestimmte Konfigurationsanforderungen erfüllt sind, zum Beispiel der<br />
Firewallstatus. NAP kann auch sicherstellen, dass bestimmte Software, zum Beispiel Antimalware,<br />
installiert und auf dem neuesten Stand ist.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthält die <strong>Server</strong>komponenten, die für NAP erforderlich sind. Es<br />
kann auch als NAP-Client agieren, ebenso wie <strong>Windows</strong> Vista, <strong>Windows</strong> XP und <strong>Windows</strong><br />
<strong>Server</strong> 2003 <strong>–</strong> die beiden Letzteren erfordern allerdings Updates von Microsoft, die <strong>2008</strong><br />
veröffentlicht werden. Integritätsrichtlinien definieren, welche Updates, Antimalwaresignaturen,<br />
Softwareversionen, <strong>Sicherheit</strong>seinstellungen und andere Einstellungen auf dem NAP-<br />
Client vorhanden sein müssen, damit er Zugriff auf Netzwerkressourcen erhält. Inkompatible<br />
Systeme (also Systeme, die diese Anforderungen nicht erfüllen) können Zugriff auf ein<br />
eingeschränktes Netzwerk bekommen, wo sie alle Änderungen vornehmen können, die gebraucht<br />
werden, um die Anforderungen zu erfüllen. Nachdem Sie im letzten Abschnitt einiges<br />
über IPsec gelesen haben, machen Sie sich vielleicht Gedanken darüber, wie Sie NAP in<br />
Ihre Isolierungsstrategie integrieren können.<br />
Hinweis NAP zwar ein leistungsfähiges Verwaltungs- und Richtlinienerzwingungstool, es kann aber keine<br />
Benutzer mit unlauteren Absichten (insbesondere böswillige Insider) davon abhalten, unerwünschte Aktionen<br />
in Ihrem Netzwerk auszuführen.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bringt zwar die Grundlagen mit, die Sie brauchen, um NAP bereitzustellen<br />
und zu verwalten, aber Microsoft rechnet auch damit, dass viele Fremdhersteller ihre<br />
<strong>Sicherheit</strong>slösungen in diese Architektur integrieren wollen. NAP enthält einen Satz APIs,<br />
über die sich andere Tools einklinken können, um Integritätsrichtlinien zu überprüfen, den<br />
Zugriff auf das Netzwerk zu steuern, Wartungsaktionen durchzuführen und die dauerhafte<br />
Erfüllung der Anforderungen sicherzustellen. Microsoft ist Mitglied in mehreren Herstellerkonsortien<br />
und arbeitet mit zahlreichen Partnern zusammen, um sicherzustellen, dass Interoperabilität<br />
mit möglichst vielen ergänzenden Technologien möglich ist.<br />
Architektur<br />
Es gibt bereits Unternehmenslösungen, die Netzwerke vor Computern schützen sollen, die<br />
die <strong>Sicherheit</strong>sanforderungen nicht erfüllen. <strong>Die</strong> aktuellen Lösungen wirken oft einschüchternd.<br />
Einige Analysten und Experten haben an diesen Lösungen ihre Komplexität, Verwaltungsprobleme<br />
und schlechte Interoperabilität kritisiert. <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong><br />
Vista gehen diese Probleme mit einfach bedienbaren Assistenten, leistungsfähigen Verwaltungstools<br />
und der Möglichkeit zur Interoperabilität mit Lösungen vieler Partner an. <strong>Die</strong><br />
NAP-Architektur besteht aus einer Reihe von <strong>Server</strong>- und Netzwerkkomponenten, die mit<br />
NAP-Clients zusammenarbeiten, um Integritätsrichtlinien zu verteilen und zu erzwingen<br />
sowie Lösungsmöglichkeiten für den Fall anzubieten, dass ein Client die Anforderungen<br />
nicht erfüllt. Abbildung 5.11 zeigt diese Komponenten.
140 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Abbildung 5.11 NAP-Komponenten für VPN-, DHCP- und 802.1-Erzwingung<br />
Netzwerkrichtlinienserver<br />
Der Netzwerkrichtlinienserver (Network Policy <strong>Server</strong>, NPS) ist die Microsoft-Implementierung<br />
eines RADIUS-<strong>Server</strong>s (Remote Authentication Dial-In User Service) in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>. Er ersetzt IAS (Internet Authentication <strong>Server</strong>) aus <strong>Windows</strong> <strong>Server</strong> 2003. NPS<br />
führt die Integritätsprüfung durch und entscheidet, welchen Zugriff NAP-Clients erhalten.<br />
Wenn eine Zugriffsanforderung eintrifft, extrahiert NPS das SoH (Statement of Health) des<br />
Clients und leitet es an den NAP-Administrationsserver weiter. Abhängig von den SoHRs<br />
(Statement of Health Response) von den Systemintegritätsprüfungen (System Health Validator,<br />
SHV) und den Integritätsrichtlinien generiert NPS ein SSoHR (System Statement of<br />
Health Response), das angibt, ob der Client die Anforderungen erfüllt.<br />
Hinweis Sicherlich sind Ihnen die vielen Akronyme im letzten Absatz aufgefallen. Eine stillschweigende<br />
Forderung an jede neue Technologie lautet, dass sie neue Akronyme einführen muss, und NAP erfüllt diese<br />
Aufgabe mit Begeisterung. Es empfiehlt sich, eine Liste zur Hand zu haben, wenn Sie sich mit NAP beschäftigen.<br />
Im Abschnitt »Akronyme für IPSec, Firewall, RRAS und NAP« weiter unten in diesem Kapitel<br />
sind die wichtigsten Akronyme aufgelistet.
Netzwerkzugriffsschutz 141<br />
NAP-Administrationsserver<br />
Der NAP-Administrationsserver erledigt die Kommunikation zwischen den SHVs und dem<br />
NPS-<strong>Server</strong>. Der Administrationsserver empfängt über den NPS-<strong>Die</strong>nst das SSoH vom NAP-<br />
Erzwingungsserver (Enforcement <strong>Server</strong>, ES), verteilt die SoHs im SSoH an die SHVs und<br />
sammelt die SoHRs von den SHVs ein, die dann vom NPS-<strong>Die</strong>nst ausgewertet werden.<br />
Integritätsregistrierungsstelle<br />
<strong>Die</strong> Integritätsregistrierungsstelle (Health Registration Authority, HRA) empfängt SSoHRs<br />
für NAP-Clients, wenn sie bewiesen haben, dass sie die Anforderungen erfüllen. Das SSoHR<br />
wird benutzt, um NAP-Clients zu authentifizieren, wenn sie über IPsec die Verbindung zu<br />
anderen NAP-Clients herstellen.<br />
Host Credential Authorization-Protokoll<br />
HCAP (Host Credential Authorization Protocol) wird bereitgestellt, um die Interoperabilität<br />
mit der Network Access Control-Technologie von Cisco zu gewährleisten. NPS stellt für die<br />
Cisco-Integration die Attribute Extended State und Policy Expiration in der Netzwerkrichtlinie<br />
bereit.<br />
Wartungsserver<br />
Wartungsserver (engl. remediation server) werden verwendet, um Clients so zu aktualisieren,<br />
dass sie die Anforderungen erfüllen können, falls sie nicht beweisen konnten, dass ihr<br />
Integritätsstatus die Richtlinien der Organisation erfüllt. Wartungsserver können die neuesten<br />
Antimalwaresignaturen, Updates und Service Packs für <strong>Windows</strong>, Konfigurationsskripts<br />
und andere Ressourcen hosten, die ein Client nutzen kann, um die Anforderungen zu erfüllen.<br />
Erzwingungskomponenten<br />
Ein NAP-ES steuert den Netzwerkzugriff des NAP-Clients, leitet das SoH des Clients zur<br />
Auswertung an den NPS weiter und stellt dann abhängig von der Antwort des NPS-<strong>Server</strong>s<br />
entweder eingeschränkten oder vollständigen Zugriff zur Verfügung. <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
hat vier integrierte Erzwingungsserver: IPsec, VPN, Terminalservergateway und DHCP.<br />
Erzwingungsmethoden<br />
Es stehen folgende Möglichkeiten zur Wahl, um Netzwerkeinschränkungen für inkompatible<br />
Hosts zu erzwingen:<br />
IPsec <strong>Die</strong>s ist die bevorzugte Methode, weil jeder verwaltete Host sich selbst vor Hosts<br />
schützt, die nicht die Integritätsanforderungen Ihrer Organisation erfüllen. Unabhängig<br />
davon, wie und wo der potenziell gefährliche Computer verbunden ist, ignorieren alle<br />
verwalteten Computer seine Kommunikation, bis er bewiesen hat, dass er die Richtlinien<br />
erfüllt.<br />
IEEE 802.1x <strong>Die</strong>se Technik steuert den Zugriff mithilfe von Einschränkungen, die<br />
von Netzwerk-Switches und Drahtloszugriffspunkten erzwungen werden. Bis der Host<br />
bewiesen hat, dass sein Integritätsstatus die Anforderungen erfüllt, kann er mit der ID<br />
eines virtuellen LANs oder einem Satz von IP-Paketfiltern eingeschränkt werden.<br />
VPN VPN ist eine gute Methode, um Richtlinien auf Remoteclients zu erzwingen. Wenn<br />
der Benutzer seine Identität bewiesen hat, wird sein Zugriff so lange eingeschränkt, bis
142 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
der Computer, mit dem er arbeitet, bewiesen hat, dass er die Anforderungen Ihrer Integritätsrichtlinien<br />
erfüllt. Falls Sie mit der Netzwerkzugriffquarantäne in <strong>Windows</strong> <strong>Server</strong><br />
2003 vertraut sind, dürften Ihnen Ähnlichkeiten zu NAP auffallen. NAP basiert aber auf<br />
einer völlig neu entwickelten Technologie.<br />
Terminalservergateway Terminalservergateway (TS Gateway) schränkt den Zugriff<br />
für Remoteterminaldiensteclients ein, wenn diese mit RDP (Remote Desktop Protocol)<br />
über HTTPS auf interne Ressourcen zugreifen.<br />
DHCP DHCP-Erzwingung mag einfach bereitzustellen sein, es ist aber auch die unsicherste<br />
Lösung. Bei diesem Ansatz wird der Zugriff über die IPv4-Adresskonfiguration<br />
und -Routingtabellen des Hosts gesteuert. Ein findiger Benutzer mit administrativen Privilegien<br />
kann das einfach umgehen, indem er seine TCP/IP-Einstellungen von Hand<br />
konfiguriert. Falls Sie im selben Netzwerk Hosts unterstützen, die nicht NAP-fähig sind<br />
oder das zumindest behaupten, kann jeder den Schutz umgehen, indem er einfach behauptet,<br />
keine NAP-Fähigkeit zu bieten.<br />
Systemintegritätsprüfungen<br />
Eine Systemintegritätsprüfung (System Health Validator, SHV) ist ein Element, das<br />
einem Systemintegritätsagenten (System Health Agent, SHA) auf dem NAP-Client zugeordnet<br />
ist. Ein SHA ist mit einem oder mehreren Integritätsanforderungsservern verknüpft.<br />
Antivirensoftware ist ein gutes Beispiel. Sie haben einen SHA für das Antivirenprogramm<br />
und eine SHV, die die Antivirensignaturen auf dem Client mit dem <strong>Server</strong><br />
vergleicht, der aktuelle Signaturdateien hostet. <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthält die <strong>Windows</strong>-<strong>Sicherheit</strong>sintegritätsprüfung.<br />
Microsoft und andere Hersteller können weitere<br />
SHVs entwickeln, die sich in die NAP-Plattform einklinken. <strong>Die</strong> <strong>Windows</strong>-SHV kann<br />
folgende Szenarien für NAP-Clients erzwingen:<br />
Auf dem Clientcomputer ist Firewallsoftware installiert und aktiviert.<br />
Auf dem Clientcomputer ist Antivirensoftware installiert und wird ausgeführt.<br />
Auf dem Clientcomputer sind aktuelle Antivirenupdates installiert.<br />
Auf dem Clientcomputer ist Antispywaresoftware installiert und wird ausgeführt.<br />
Auf dem Clientcomputer sind Antispywareupdates installiert.<br />
<strong>Die</strong> Microsoft Update-<strong>Die</strong>nste sind auf dem Clientcomputer aktiviert.<br />
Systemintegritätsagenten<br />
SHAs überwachen den Integritätsstatus des Clients, sodass der NPS weiß, ob der NAP-<br />
Client die Anforderungen erfüllt. Zum Beispiel kann der <strong>Windows</strong>-Systemintegritätsagent<br />
(<strong>Windows</strong> System Health Agent, WSHA), das Gegenstück zur vorher beschriebenen<br />
<strong>Windows</strong>-SHV, die <strong>Windows</strong>-Firewall überwachen. Der WSHA kann Folgendes<br />
feststellen:<br />
Ob Antivirensoftware installiert, aktiviert und auf dem neuesten Stand ist.<br />
Ob Antispywaresoftware installiert, aktiviert und auf dem neuesten Stand ist.<br />
Ob die Microsoft Update-<strong>Die</strong>nste aktiviert sind.<br />
Ob auf dem Host die neuesten <strong>Sicherheit</strong>supdates installiert sind.<br />
Andere Hersteller können weitere SHAs für andere <strong>Sicherheit</strong>slösungen entwickeln.
Netzwerkzugriffsschutz 143<br />
NAP-Agent<br />
Der NAP-Agent sammelt Integritätsdaten, verarbeitet SoHs von SHAs und meldet den Integritätsstatus<br />
an Erzwingungsclients. Er meldet die Zusammenfassung der Systemintegrität<br />
mithilfe eines SSoH (System Statement of Health).<br />
NAP-Erzwingungsclients<br />
Um NAP nutzen zu können, muss auf den Clientcomputern ein NAP-Erzwingungsclient<br />
(Enforcement Client, EC) laufen. Einzelne NAP-ECs sind den weiter oben vorgestellten<br />
Erzwingungsmethoden zugeordnet, zum Beispiel IPsec und Terminaldienstegateway. Der<br />
NAP-EC fordert Netzwerkzugriff an, kommuniziert mit dem NPS-<strong>Server</strong> und meldet den<br />
Status des NAP-Clients an andere Komponenten in der NAP-Clientarchitektur.<br />
Implementieren von NAP<br />
NAP ist flexibel. Sie können es so konfigurieren, dass es den Anforderungen und Fähigkeiten<br />
Ihrer Organisation entspricht. Daher unterscheiden sich die Implementierungen von<br />
Netzwerk zu Netzwerk. <strong>Die</strong>ser Abschnitt demonstriert, wie NAP in einem Beispielnetzwerk<br />
arbeitet: Hosts, die Zugriff auf Netzwerkressourcen anfordern, erhalten eingeschränkten<br />
Zugriff, falls sie inkompatible NAP-Clients sind oder Clients, die sich nicht bei der NAP-<br />
Infrastruktur authentifizieren können. Den Hosts wird vollständiger Zugriff gewährt, falls<br />
sie NAP-Clients sind, die entsprechend der Integritätsrichtlinie konfiguriert sind. <strong>Die</strong>s wird<br />
im Folgenden genauer beschrieben.<br />
Wenn der NAP-Client versucht, auf Netzwerkressourcen zuzugreifen, sammelt der NAP-<br />
Agent auf dem Client SoHs von allen SHAs und fasst sie zu einem SSoH zusammen. Dann<br />
erstellt er eine RADIUS-Access-Request-Nachricht, die er an den NAP-EC sendet. Der<br />
NAP-EC sendet die Access-Request-Nachricht an den NAP-ES, der sie wiederum an den<br />
NPS-<strong>Die</strong>nst auf dem NAP-Integritätsrichtlinienserver sendet. Der NPS-<strong>Die</strong>nst weist alle<br />
RADIUS-Nachrichten von Clients zurück, für deren Verwaltung er nicht konfiguriert ist.<br />
Der NPS-<strong>Die</strong>nst prüft, ob die Access-Request-Nachricht seinem Satz von Verbindungsanforderungsrichtlinien<br />
entspricht. <strong>Die</strong> Access-Request-Nachricht sollte einer Richtlinie entsprechen,<br />
die erfordert, dass der NPS-<strong>Die</strong>nst Authentifizierung und Autorisierung lokal<br />
durchführt.<br />
Der NPS-<strong>Die</strong>nst wertet die Integritätsinformationen in der Access-Request-Nachricht aus,<br />
die ein SSoH und ein oder mehrere SoHs umfasst. <strong>Die</strong> NAP-Administrationsserverkomponente<br />
auf dem NAP-Integritätsrichtlinienserver leitet jedes SoH an die entsprechende SHV<br />
weiter. Jede SHV stellt fest, ob das empfangene SoH die Anforderungen erfüllt. Der NAP-<br />
Administrationsserver generiert aus den SHVs einen Satz von SoHRs. Der NPS-<strong>Die</strong>nst vergleicht<br />
die Access-Request-Nachricht und die SoHRs mit den Netzwerkrichtlinien. <strong>Die</strong><br />
SoHRs werden mit den Integritätsrichtlinien in den Netzwerkrichtlinien verglichen. Der<br />
NPS-<strong>Die</strong>nst wendet dann die Netzwerkrichtlinie an, die am besten zur Access-Request-<br />
Nachricht passt. <strong>Die</strong>s ist entweder die erste Übereinstimmung mit einer bestimmten Quelle<br />
(für Anforderungen, die ein Quell-Tag enthalten, das den Typ des RADIUS-Clients angibt)<br />
oder das erste mit einer unspezifizierten Quelle.<br />
Der NPS-<strong>Die</strong>nst generiert anhand der am besten passenden Netzwerkrichtlinie und der<br />
NAP-Einstellungen innerhalb der Richtlinie ein SSoHR. Das SSoHR umfasst die SoHRs aus<br />
den SHVs, und es gibt an, ob der Client eingeschränkten oder uneingeschränkten Zugriff<br />
erhält. Falls der Zugriff eingeschränkt wird, gibt das SSoHR auch an, ob der Client versu-
144 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
chen sollte, eine automatische Wartung durchzuführen. Der NPS-<strong>Die</strong>nst sendet eine RADIUS-<br />
Access-Accept-Nachricht mit dem SSoHR an den NAP-ES. Der NAP-ES leitet das SSoHR<br />
an den Client weiter. In manchen Fällen sendet der NPS-<strong>Die</strong>nst das SSoHR direkt an den<br />
Client und Anweisungen zum Einschränken des Zugriffs an den NAP-ES. Falls der Client<br />
eingeschränkten Zugriff hat, kann diese Nachricht auch eine Liste mit Adressen von Wartungsservern<br />
enthalten. Der NAP-ES sendet das SSoHR an den NAP-Client. <strong>Die</strong>ser Vorgang<br />
ist in Abbildung 5.12 illustriert. <strong>Die</strong> durchgezogenen Linien stehen für die Zugriffsanforderung,<br />
die der Client sendet. Sie führen zum Erzwingungsserver und von dort durch die serverseitigen<br />
Komponenten. <strong>Die</strong> gestrichelten Linien stehen für die Antwort, die im Administrationsserver<br />
erstellt und über den Erzwingungsserver zum Client zurückgeleitet wird.<br />
Abbildung 5.12 Weg der Nachrichten zwischen NAP-Komponenten
Netzwerkzugriffsschutz 145<br />
Hinweis Hosts, die NAP nicht nutzen können, erhalten in der Standardeinstellung eingeschränkten<br />
Zugriff. Falls zum Beispiel IPsec-Erzwingung eingesetzt wird, können solche Hosts keine Verbindung zu<br />
irgendwelchen geschützten Hosts im Netzwerk herstellen, weil diese anderen Systeme Verkehr vom fremden<br />
Host ignorieren. Falls DHCP-Erzwingung eingesetzt wird, empfängt der Client IP-Adresskonfigurationsdaten<br />
und -Routen, die den Zugriff einschränken.<br />
Direkt von der Quelle: 802.1x- und IPsec-Erzwingung<br />
im Netzwerkzugriffsschutz<br />
NAP umfasst mehrere Methoden, um Netzwerkrichtlinien auf lokalen und Remotecomputern<br />
zu erzwingen. Für eine lokale Erzwingung in großen Unternehmensnetzwerken<br />
eignen sich zwei Methoden: 802.1x und IPsec. Denken Sie nicht, dass sich diese beiden<br />
Methoden gegenseitig ausschließen, sie ergänzen sich vielmehr. Werden sie kombiniert,<br />
bilden sie zwei leistungsfähige Abwehrlinien für die gestaffelte Verteidigung in Ihrem<br />
Netzwerk.<br />
802.1x ist ein Standard für die physische Netzwerkauthentifizierung, der ursprünglich vor<br />
allem für den Schutz von Drahtlosnetzwerken eingesetzt wurde. Inzwischen unterstützen<br />
aber auch die meisten modernen Kabelnetzwerk-Switches für den Unternehmenseinsatz<br />
diese Technologie, sodass gesteuert werden kann, wer und was den Hardwareports zugeordnet<br />
wird. NAP ermöglicht auch Integration mit allen standardkompatiblen 802.1x-<br />
Switches, um Systeme abhängig von ihrer Systemintegrität bestimmten VLANs zuzuordnen.<br />
Zum Beispiel können Sie NAP so konfigurieren, dass alle inkompatiblen Computer<br />
in ein Wartungs-VLAN gelegt werden, das nur Zugriff auf Updateserver bietet. So können<br />
diese Hosts keinen Verkehr in das übrige Netzwerk senden. Indem NAP den offenen<br />
802.1x-Standard nutzt, bietet es eine leistungsfähige Schicht-2-Konnektivitätskontrolle<br />
auf Basis der Systemintegrität.<br />
802.1x bietet zwar wertvolle <strong>Sicherheit</strong>svorteile für Unternehmen, allein kann es aber<br />
nicht immer umfassenden Schutz für das gesamte Unternehmen gewährleisten. 802.1x-<br />
Schutz ist nämlich nur an dem Port wirksam, an den ein Gerät angeschlossen ist. Sobald<br />
die Verbindung einmal erfolgreich hergestellt wurde, erlegt 802.1x den Verkehrsroutingfähigkeiten<br />
des Clients keine weiteren Einschränkungen auf. Falls daher ein inkompatibler<br />
Computer eine Verbindung an irgendeiner Stelle im Netzwerk herstellen kann, wo<br />
802.1x nicht bereitgestellt wurde (zum Beispiel ein Netzwerkdruckeranschluss, der von<br />
der 802.1x-Erzwingung ausgenommen ist, oder eine Zweigstelle ohne 802.1x-kompatible<br />
Hardware), erhält dieser Computer vollständige Konnektivität zum Rest des Unternehmens.<br />
Anders ausgedrückt: 802.1x bietet Schutz auf Portebene, nicht auf Hostebene.<br />
IPsec ist ein anderer offener Standard, für den NAP Integrationsmöglichkeiten bietet.<br />
IPsec kann 802.1x ergänzen oder eigenständig bereitgestellt werden. IPsec-Schutz arbeitet<br />
auf Hostebene. Er schützt Systeme im Netzwerk unabhängig davon, ob ein inkompatibles<br />
System direkt an einen bestimmten Port angeschlossen wird. Für die IPsec-Erzwingung<br />
muss eine unternehmensweite IPsec-Richtlinie auf allen Systemen bereitgestellt<br />
werden (normalerweise geschieht dies über Gruppenrichtlinien). <strong>Die</strong>se Richtlinie konfiguriert<br />
die Systeme so, dass sie Verkehr zurückweisen, wenn der Absender den Verkehr<br />
nicht mit einem Zertifikat signiert, das von einer NAP-HRA ausgestellt wurde. <strong>Die</strong> HRA<br />
ist in NAP integriert, sodass sichergestellt ist, dass die Zertifikate nur an Systeme ausgestellt<br />
werden, die die Anforderungen der Integritätsrichtlinie im Unternehmen erfüllen.
146 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
Daher bietet die IPsec-Erzwingung Schutz auf der Hostschicht und kann entweder als<br />
eigenständige Erzwingungsmethode oder als zusätzliche Schicht in einer gestaffelten Verteidigung<br />
dienen, wenn sie mit 802.1x kombiniert wird. IPsec-Erzwingung bietet außerdem<br />
den Vorteil, dass sie einfacher in virtualisierte Umgebungen zu integrieren ist, wo<br />
virtuelle Computer unter Umständen nicht an 802.1x-fähige Ports angeschlossen sind<br />
(entweder Hardwareports oder solche in virtuellen Switches).<br />
John Morello, Senior Program Manager<br />
<strong>Windows</strong> <strong>Server</strong> Division<br />
NAP-Szenarien<br />
Folgende häufig anzutreffende NAP-Szenarien zeigen, wie nützlich diese neue Plattform ist:<br />
Desktopcomputer Desktopcomputer können eine Bedrohung für das Netzwerk sein,<br />
falls ihnen Updates fehlen, sie schlecht konfiguriert sind oder von Malware infiziert<br />
wurden. Alle diese Situationen können es böswilligen Benutzern erlauben, auf Informationen<br />
zuzugreifen, die das Unternehmen eigentlich nicht verlassen sollten. Computern<br />
können Updates fehlen, weil sie längere Zeit ausgeschaltet waren oder aus irgendwelchen<br />
Gründen keine Verbindung zum Netzwerk hatten. Sie können falsch konfiguriert<br />
sein, wenn Benutzer mehr Privilegien auf ihren Systemen haben, als die Empfehlungen<br />
zulassen. Sie können mit böswilliger Software infiziert werden, weil der Benutzer gefährliche<br />
Websites besucht oder Dateien geöffnet hat, die mit einem Virus infiziert<br />
waren.<br />
Notebooks Gerade die Mobilität macht Notebooks so nützlich, aber sie vergrößert<br />
gegenüber einem üblichen Desktopcomputer auch die Gefahr einer Kompromittierung.<br />
Einem Notebook können Updates oder die neuesten Antivirensignaturen fehlen, weil der<br />
Benutzer sein Notebook mehrere Wochen nicht mit dem Unternehmensnetzwerk verbunden<br />
hat. Ein Notebook ist potenziell Angriffen ausgesetzt, wenn es in Drahtlosnetzwerken<br />
benutzt wird oder an einem Ort unbeaufsichtigt bleibt, an dem Fremde Zugriff<br />
darauf haben. Mit NAP können Administratoren den Integritätsstatus von Notebooks<br />
jedes Mal überprüfen, wenn sie wieder ans Netzwerk der Organisation angeschlossen<br />
werden, sei es über ein VPN oder wenn der Benutzer ins Büro zurückkehrt.<br />
Unverwaltete Heimcomputer Manche Organisationen erlauben ihren Benutzern, von<br />
ihren privaten Computern aus über ein VPN eine Verbindung zum Unternehmensnetzwerk<br />
herzustellen. <strong>Die</strong>se Computer unterliegen nicht der Kontrolle der Organisation. Mit<br />
NAP können Netzwerkadministratoren aber jedes Mal, wenn eine VPN-Verbindung aufgebaut<br />
wird, den Integritätsstatus dieser Systeme überprüfen. Falls ein System die Integritätsanforderungen<br />
nicht erfüllt, kann sein Zugriff eingeschränkt werden.<br />
Computer von Besuchern Unternehmen erlauben allen möglichen Leuten, das Gelände<br />
zu betreten: Consultants, Partner, Freunde von Mitarbeitern, Stellenbewerber und<br />
Zulieferer bitten darum, Zugriff auf Ihr Netzwerk zu erhalten. Ihre Computer erfüllen<br />
unter Umständen nicht die Integritätsrichtlinien der Organisation, aber mit NAP können<br />
Administratoren diese Computer überprüfen und in einem eingeschränkten Netzwerk<br />
isolieren. Das eingeschränkte Netzwerk kann zum Beispiel Internetzugriff bieten, damit<br />
die Besucher auf ihre eigenen E-Mail-Konten und andere externe Ressourcen zugreifen<br />
können.
Netzwerkzugriffsschutz 147<br />
Akronyme für IPSec, Firewall, RRAS und NAP<br />
AES: Advanced Encryption Standard<br />
AH: Authentication Headers<br />
API: Application Programming Interface (Anwendungsprogrammierschnittstelle)<br />
BFE: Base Filtering Engine<br />
CA: Certificate Authority (Zertifizierungsstelle)<br />
CBC: Cipher Block Chaining<br />
CMAK: Connection Manager Administration Kit (Verbindungs-Manager-<br />
Verwaltungskit)<br />
DES: Data Encryption Standard<br />
DH: Diffie-Hellman<br />
ESP: Encapsulated Security Payload<br />
FTP: File Transfer Protocol<br />
GFE: Generic Filtering Engine<br />
HCAP: Host Credential Authorization Protocol<br />
HRA: Health Registration Authority (Integritätsregistrierungsstelle)<br />
HTML: Hypertext Markup Language<br />
HTTP: Hypertext Transport Protocol<br />
HTTPS: Secure Hypertext Transport Protocol<br />
ICMP: Internet Control Message Protocol<br />
IKE: Internet Key Exchange (IKE)<br />
IPsec: Internet Protocol security<br />
ISA: Internet Security and Acceleration <strong>Server</strong><br />
ISAKMP: Internet Security Association and Key Management Protocol<br />
L2TP: Layer 2 Tunneling Protocol<br />
MD5: Message Digest 5<br />
MMC: Microsoft Management Console<br />
MPPE: Microsoft Point-to-Point<br />
NAP: Network Access Protection (Netzwerkzugriffsschutz)<br />
NAP EC: Network Access Protection Enforcement Client (Netzwerkzugriffsschutz-<br />
Erzwingungsclient)<br />
NAP ES: Network Access Protection Enforcement <strong>Server</strong> (Netzwerkzugriffsschutz-<br />
Erzwingungsserver)<br />
NAT: Network Address Translation<br />
NAT-T: Network Address Translation-Traversal<br />
NDF: Network Diagnostics Framework (Netzwerkdiagnose-Framework)<br />
NLA: Network Location Awareness<br />
NPS: Network Policy <strong>Server</strong> (Netzwerkrichtlinienserver)
148 Kapitel 5: Firewall und Netzwerkzugriffsschutz<br />
NTLMv2: New Technology LAN Manager version 2<br />
PKI: Public Key Infrastructure<br />
PPP: Point-to-Point Protocol<br />
PPTP: Point-to-Point Tunneling Protocol<br />
RADIUS: Remote Authentication Dial-In User Service<br />
RDP: Remote Desktop Protocol<br />
RRAS: Routing and Remote Access Service (Routing- und RAS-<strong>Die</strong>nst)<br />
SA: Security Association (<strong>Sicherheit</strong>szuordnung)<br />
SHA: System Health Agent (Systemintegritätsagent)<br />
SHV: System Health Validator (Systemintegritätsprüfung)<br />
SKEME: Secure Key Exchange Mechanism<br />
SoH: Statement of Health<br />
SoHR: Statement of Health Response<br />
SSL: Secure Sockets Layer<br />
SSoHR: System Statement of Health Response<br />
SSTP: Secure Socket Tunneling Protocol<br />
TCP: Transmission Control Protocol<br />
TCP/IP: Transmission Control Protocol/Internet Protocol<br />
TLS: Transport Layer Security<br />
TS: Terminal <strong>Server</strong> (Terminalserver) oder Terminal Service (Terminaldienste)<br />
UAC: User Account Control (Benutzerkontensteuerung)<br />
UDP: User Datagram Protocol<br />
VPN: Virtual Private Network<br />
WAIS: Wide Area Information <strong>Server</strong>s<br />
WFP: <strong>Windows</strong> Filtering Platform<br />
WSHA: <strong>Windows</strong> System Health Agent (<strong>Windows</strong>-Systemintegritätsagent)<br />
Zusammenfassung<br />
<strong>Die</strong>ses Kapitel enthält zahlreiche Informationen über mehrere eng miteinander verbundene<br />
Technologien in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. <strong>Die</strong> <strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> ist<br />
die neue hostbasierte Firewall, die eng mit IPsec und NAP integriert ist. Sie können Isolierungsregeln<br />
in Kombination mit NAP und IPsec einsetzen, um <strong>Server</strong> vor potenziell gefährlichen<br />
Hosts im Netzwerk zu schützen. Das Kapitel hat außerdem kurz die Verbesserungen<br />
im Routing- und RAS-<strong>Die</strong>nst zusammengefasst, insbesondere SSTP, das die Verwaltung von<br />
VPNs für Remotebenutzer vereinfachen kann. Sie können alle diese Technologien einsetzen,<br />
um die Kommunikation zwischen Netzwerkhosts zu ermöglichen, aber trotzdem die Gefahr<br />
zu verringern, dass böswillige Benutzer sie kompromittieren.
Weitere Informationen<br />
Weitere Informationen 149<br />
Microsoft Corporation (2006, 2007): »New Networking Features in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
and <strong>Windows</strong> Vista« unter http://technet.microsoft.com/en-us/library/bb726965.aspx.<br />
Johansson, J. M.: Protect Your <strong>Windows</strong> Network (Addison-Wesley, 2005).<br />
Microsoft Corporation (2004): »<strong>Windows</strong> Filtering Platform« unter<br />
http://www.microsoft.com/whdc/device/network/wfp.mspx.<br />
Microsoft Corporation (2007): »<strong>Windows</strong> Firewall with Advanced Security <strong>–</strong> Diagnostics<br />
and Troubleshooting« unter http://technet2.microsoft.com/<strong>Windows</strong>Vista/en/library/<br />
9428d113-ade8-4dbe-ac05-6ef10a6dd7a51033.mspx?mfr=true.<br />
Microsoft Corporation (2007): »Routing and Remote Access« unter<br />
http://technet.microsoft.com/en-us/network/bb545655.aspx.<br />
Microsoft Corporation (2007): »Routing and Remote Access Blog« unter<br />
http://blogs.technet.com/rrasblog/default.aspx.<br />
Microsoft Corporation (2007): »Deploying SSTP Remote Access Step-by-Step Guide«<br />
unter http://download.microsoft.com/download/b/1/0/b106fc39-936c-4857-a6ea-3fb9d1<br />
f37063/deploying%20sstp%20remote%20access%20step%20by%20step%20guide.doc.<br />
Microsoft Corporation (2007): »<strong>Server</strong> and Domain Isolation« unter<br />
http://technet.microsoft.com/en-us/network/bb545651.aspx.<br />
Microsoft Corporation (2007): »Network Access Protection« unter<br />
http://technet.microsoft.com/en-us/network/bb545879.aspx.<br />
Microsoft Corporation (2007): »NAP Blog« unter http://blogs.technet.com/nap/.<br />
Riley, Steve (2007): »Exploring the <strong>Windows</strong> Firewall« unter http://www.microsoft.com/<br />
technet/technetmag/issues/2007/06/VistaFirewall/default.aspx.
K A P I T E L 6<br />
<strong>Die</strong>nste<br />
Von Roger A. Grimes<br />
In diesem Kapitel:<br />
Einführung in <strong>Die</strong>nste . ................................................ 151<br />
Angriffe auf <strong>Die</strong>nste .................................................. 161<br />
<strong>Die</strong>nsthärtung ...................................................... 165<br />
Schützen von <strong>Die</strong>nsten ............................................... 179<br />
Zusammenfassung .................................................. 183<br />
Weitere Informationen ................................................ 184<br />
Eine neue Enterprise-Standardinstallation von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthält mehr als 100<br />
<strong>Die</strong>nste, von denen über 40 aktiv sind und während des <strong>Windows</strong>-Startprozesses gestartet<br />
werden. Wenn Sie sämtliche <strong>Server</strong>rollen installieren (auch wenn das in der Praxis kaum<br />
vorkommen dürfte), kommen etwa weitere 40 aktive <strong>Die</strong>nste hinzu, die automatisch gestartet<br />
werden. Falls Sie weitere <strong>Windows</strong>-Komponenten hinzufügen (zum Beispiel WINS-<br />
<strong>Server</strong>, Subsystem für UNIX-basierte Anwendungen, Telnet-<strong>Server</strong> und so weiter), können<br />
Sie sich einige Dutzend weitere <strong>Die</strong>nste einhandeln. Sogar <strong>Server</strong> Core, die Installationsoption<br />
ohne grafische Benutzeroberfläche, ist nicht so minimalistisch, wie Sie vielleicht<br />
denken. Sie ist mit 70 <strong>Die</strong>nsten ein wenig genügsamer, gut die Hälfte davon werden automatisch<br />
gestartet. Unter dem Aspekt der <strong>Sicherheit</strong> bietet jeder <strong>Die</strong>nst einen zusätzlichen<br />
Angriffsweg. <strong>Die</strong>s ist eine Tatsache, die böswillige Hacker nur zu gut verstehen.<br />
Um die Gefahr zu verringern, dass Ihre Systeme kompromittiert werden, müssen Sie unbedingt<br />
wissen, wie <strong>Die</strong>nste arbeiten und wie sie richtig geschützt werden. <strong>Die</strong>ses Kapitel<br />
beschreibt die <strong>Windows</strong>-<strong>Die</strong>nste im Allgemeinen, stellt Bedrohungen vor und erklärt, wie<br />
Sie die Gefahr für <strong>Die</strong>nste so gering wie möglich halten können. Nachdem Sie dieses Kapitel<br />
gelesen haben, kennen Sie den Unterschied zwischen einer Anwendung und einem<br />
<strong>Die</strong>nst sowie die häufigsten Bedrohungen für <strong>Die</strong>nste und sind in der Lage, die verschiedenen<br />
<strong>Windows</strong>-<strong>Sicherheit</strong>smechanismen zu nutzen und zu konfigurieren, die das Risiko der<br />
Kompromittierung von <strong>Die</strong>nsten verringern sollen.<br />
Einführung in <strong>Die</strong>nste<br />
<strong>Die</strong>nste stellen Mechanismen für die Client- und <strong>Server</strong>kommunikation für lokale und Remotebenutzer,<br />
Anwendungen und <strong>Windows</strong> selbst zur Verfügung. <strong>Die</strong>se Funktionalität ist in<br />
<strong>Die</strong>nsten gekapselt. <strong>Die</strong>s sind Prozesse, die sogar dann laufen, wenn sich niemand angemeldet<br />
hat. Manche <strong>Die</strong>nste sind erforderlich, damit <strong>Windows</strong> funktioniert. Andere werden nur<br />
gebraucht, wenn bestimmte Aufgaben oder Rollen erledigt werden sollen.<br />
151
152 Kapitel 6: <strong>Die</strong>nste<br />
Was ist ein <strong>Die</strong>nst?<br />
Um <strong>Die</strong>nste verstehen zu können, müssen Sie wissen, wodurch sich ein <strong>Die</strong>nst von einer<br />
normalen Anwendung unterscheidet. <strong>Die</strong> meisten von Microsoft installierten <strong>Windows</strong>-<br />
<strong>Die</strong>nste werden als DLL- oder EXE-Dateien aus dem Ordner \System32 geladen, sie können<br />
aber auch an jeder anderen gültigen Stelle auf einem lokalen Laufwerk liegen. <strong>Die</strong>nste werden<br />
in Sitzung 0 mit Systemintegritätsebene und bei aktivierter Datenausführungsverhinderung<br />
(Data Execution Prevention, DEP) gestartet; sie enthalten die <strong>Sicherheit</strong>s-ID (Security<br />
Identifier, SID) DIENST und die Datei- und Registrierungsvirtualisierung ist deaktiviert. Im<br />
Unterschied zu normalen Anwendungen können <strong>Die</strong>nste dienstspezifische SIDs zugeordnet<br />
haben, die eine flexible Zugriffssteuerung ermöglichen.<br />
Hinweis Kapitel 1, »Subjekte, Benutzer und andere Akteure«, enthält weitere Informationen zu SIDs.<br />
Kapitel 4, »Grundlagen der Benutzerkontensteuerung«, enthält weitere Informationen zur Virtualisierung.<br />
Anmeldekonten für <strong>Die</strong>nste<br />
Alle <strong>Die</strong>nste bekommen ein <strong>Die</strong>nstanmeldekonto zugewiesen, das festlegt, in welchem primären<br />
<strong>Sicherheit</strong>skontext der <strong>Die</strong>nst läuft. <strong>Die</strong> integrierten <strong>Die</strong>nstanmeldekonten sind SYS-<br />
TEM, LOKALER DIENST und NETZWERKDIENST. Administratoren und Entwickler können<br />
aber nach Belieben neue Konten anlegen und verwenden. Mithilfe der Rechte, Berechtigungen<br />
und Privilegien, die dem <strong>Die</strong>nstanmeldekonto zugewiesen sind, wird in erster Linie<br />
(wenn auch nicht ausschließlich) gesteuert, welchen Zugriff ein bestimmter <strong>Die</strong>nst auf lokale<br />
und Netzwerkressourcen erhält. Tabelle 6.1 listet die integrierten <strong>Die</strong>nstanmeldekonten auf<br />
und beschreibt, welchen Zugriff sie auf lokale und Remoteressourcen haben.<br />
Tabelle 6.1 Integrierte <strong>Die</strong>nstanmeldekonten<br />
Name des Anmeldekontos Lokale Ressourcen Netzwerkressourcen<br />
SYSTEM<br />
(Oft auch als Lokales System<br />
oder LokalesSystem bezeichnet.<br />
Es kann NT-AUTORITÄT\ vorangestellt<br />
sein.)<br />
LOKALER DIENST<br />
(Es kann NT-AUTORITÄT\ vorangestellt<br />
sein.)<br />
NETZWERKDIENST<br />
(Es kann NT-AUTORITÄT\ vorangestellt<br />
sein.)<br />
Das Konto mit den höchsten<br />
Privilegien auf einem Computer.<br />
Es hat vollständigen Zugriff auf<br />
alle Ressourcen.<br />
Hat den Zugriff, der normalerweise<br />
authentifizierten Benutzern zugewiesen<br />
ist, mit etwas höheren<br />
Privilegien.<br />
Ähnlich wie LOKALER DIENST.<br />
Hat den Zugriff, der normalerweise<br />
authentifizierten Benutzern<br />
zugewiesen ist, mit etwas höheren<br />
Privilegien.<br />
Stellt die Verbindung zu Netzwerkressourcen<br />
mit dem <strong>Sicherheit</strong>skontext des Computers<br />
her, auf dem das Konto liegt.<br />
Stellt die Verbindung zu Netzwerkressourcen<br />
mit einem Null-Sitzungskonto (anonyme<br />
Anmeldeinformationen) her.<br />
Ähnlich wie das Konto SYSTEM. Es stellt<br />
die Verbindung als der Computer her. Das<br />
Remotetoken enthält auch die SIDs für<br />
Jeder und Authentifizierte Benutzer.<br />
<strong>Die</strong>nste können die integrierten <strong>Die</strong>nstanmeldekonten verwenden, aber auch irgendein gültiges<br />
lokales oder Domänenbenutzerkonto. In älteren <strong>Windows</strong>-Versionen liefen alle von<br />
Microsoft bereitgestellten <strong>Die</strong>nste unter dem SYSTEM-Kontext. Leider widersprach dies<br />
dem Prinzip der geringstmöglichen Rechte. Mit <strong>Windows</strong> XP hat Microsoft die restriktiveren<br />
Konten LOKALER DIENST und NETZWERKDIENST eingeführt und damit begonnen,
Einführung in <strong>Die</strong>nste 153<br />
nach und nach bei der Entwicklung neuer <strong>Die</strong>nste das Prinzip der geringstmöglichen Rechte<br />
einzuhalten. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> laufen 58 Prozent der installierten <strong>Die</strong>nste unter dem<br />
SYSTEM-Kontext, gefolgt von LOKALER DIENST mit 26 Prozent und NETZWERKDIENST<br />
mit 16 Prozent.<br />
<strong>Die</strong>se <strong>Die</strong>nstanmeldekonten dienen dazu, die <strong>Die</strong>nste bei lokalen und Remoteressourcen zu<br />
authentifizieren. Wenn <strong>Die</strong>nste die Kerberos-Authentifizierung (statt NTLM oder LM) nutzen<br />
wollen, muss dem <strong>Die</strong>nstanmeldekonto außerdem mindestens ein <strong>Die</strong>nstprinzipalname<br />
(Service Principal Name, SPN) zugewiesen sein. Der SPN dient dazu, einen <strong>Die</strong>nst eindeutig<br />
zu identifizieren, sodass eine gegenseitige Authentifizierung zwischen einer Clientanwendung<br />
und dem <strong>Die</strong>nst möglich ist.<br />
Hinweis Kapitel 2, »Authentifizierung und Authentifizierungsprotokolle«, enthält weitere Informationen<br />
zu NTLM und LM.<br />
<strong>Die</strong>nststeuerungs-Manager<br />
Alle <strong>Die</strong>nstanmeldekonten müssen das Recht Anmelden als <strong>Die</strong>nst besitzen, das dem <strong>Die</strong>nst<br />
die Fähigkeit gibt, mit dem <strong>Die</strong>nststeuerungs-Manager (Service Control Manager, SCM) zu<br />
kommunizieren und von ihm gesteuert zu werden. Das wiederum erlaubt dem <strong>Die</strong>nst, sich<br />
anzumelden und auf Ressourcen zuzugreifen, ohne dass sich erst ein externer <strong>Sicherheit</strong>sprinzipal<br />
anmelden muss.<br />
Der SCM wird während des <strong>Windows</strong>-Systemstarts als RPC-<strong>Server</strong> (Remote Procedure<br />
Call, Remoteprozeduraufruf) gestartet, damit <strong>Die</strong>nstverwaltungs- und -steuerungsprogramme<br />
(Sc.exe, Services.msc, WMIC und so weiter) mit lokalen und Remotediensten kommunizieren<br />
können. Der SCM hat die Aufgabe, während des <strong>Windows</strong>-Startprozesses <strong>Die</strong>nste automatisch<br />
zu starten, die einen entsprechenden Startmodus haben. Der SCM liest die <strong>Die</strong>nstwerte<br />
aus der Registrierung, meldet das <strong>Die</strong>nstkonto mit den ausgelesenen Anmeldeinformationen<br />
auf dem lokalen Computer an, lädt das Benutzerprofil des <strong>Die</strong>nstkontos, startet den<br />
<strong>Die</strong>nst in angehaltenem Zustand, verknüpft den <strong>Die</strong>nst mit dem Anmeldungstoken des<br />
<strong>Die</strong>nstkontos und schließt den <strong>Die</strong>nststart ab. Der SCM erkennt alle registrierten <strong>Die</strong>nstabhängigkeiten<br />
und startet sie bei Bedarf zuerst.<br />
Der SCM hat viele Aufgaben im Zusammenhang mit <strong>Die</strong>nsten, darunter:<br />
Verwalten der Datenbank mit installierten <strong>Die</strong>nsten<br />
Starten von <strong>Die</strong>nsten und Treiberdiensten entweder beim Systemstart oder auf Anforderung<br />
Auflisten der installierten <strong>Die</strong>nste und Treiberdienste<br />
Verwalten von Statusinformationen zu laufenden <strong>Die</strong>nsten und Treiberdiensten<br />
Übertragen von Steuerungsanforderungen an laufende <strong>Die</strong>nste<br />
Sperren und Entsperren der <strong>Die</strong>nstdatenbank<br />
Wenn der SCM einen <strong>Die</strong>nst starten muss, erstellt er eine Anmeldesitzung für das Anmeldekonto<br />
des <strong>Die</strong>nstes, lädt das Benutzerprofil des zugehörigen Anmeldekontos und startet den<br />
<strong>Die</strong>nst. Falls der SCM dabei erfolgreich war, verknüpft er das entstandene Prozesstoken (das<br />
die SIDs und Privilegien des <strong>Die</strong>nstes definiert) mit dem Prozess des <strong>Die</strong>nstes.<br />
Konfigurationsinformationen über jeden <strong>Die</strong>nst sind in der <strong>Windows</strong>-Registrierung unter<br />
HKLM\System\CurrentControlSet\Services gespeichert. Abbildung 6.1 zeigt an einem Beispiel,<br />
wie ein Registrierungseintrag für einen <strong>Die</strong>nst aussieht.
154 Kapitel 6: <strong>Die</strong>nste<br />
Abbildung 6.1 Registrierungseintrag für einen <strong>Die</strong>nst<br />
Sowohl <strong>Die</strong>nste als auch Treiber liegen unter dem genannten Registrierungsschlüssel Services.<br />
<strong>Die</strong>nste erkennen Sie daran, dass der Eintrag Type den Wert 0x10 (ein <strong>Die</strong>nst, der in<br />
seinem eigenen Prozess als eigenständiges Programm läuft) oder 0x20 (ein <strong>Die</strong>nst, der in<br />
einem gemeinsam genutzten Prozess läuft) hat. Ein Treiber hat in Type den Wert 0x1 (Kerneltreiber)<br />
oder 0x2 (Dateisystemtreiber) eingetragen. Außerdem ist der Wert Start bei einem<br />
<strong>Die</strong>nst immer 2 (automatisch), 3 (manuell) oder 4 (deaktiviert), bei Treibern dagegen 0 (Systemstart)<br />
oder 1 (System).<br />
Alle <strong>Die</strong>nstanmeldekonten besitzen ein zugehöriges Kennwort. Integrierte <strong>Die</strong>nstkonten<br />
bekommen von <strong>Windows</strong> lange und komplexe Kennwörter zugewiesen. Administratoren<br />
können diese Kennwörter nicht ohne Weiteres auflisten. Sie brauchen sie auch niemals zu<br />
ändern. Benutzerdefinierte Kennwörter für <strong>Die</strong>nstanmeldekonten müssen von Administratoren<br />
festgelegt werden, und sie sind in einem geschützten Bereich der lokalen Registrierung<br />
gespeichert. Alle Kennwörter von <strong>Die</strong>nstkonten können von einem lokalen Administrator<br />
mithilfe einer speziellen Software aufgelistet werden.<br />
<strong>Die</strong>nstports<br />
<strong>Die</strong> meisten <strong>Die</strong>nste haben ein Handle für einen Endpunkt, über den Informationen gesendet<br />
oder empfangen werden. Normalerweise wird dieses Handle anhand der TCP- oder UDP-<br />
Portnummer (zum Beispiel Terminaldienste unter der TCP-Portnummer 3389) und der<br />
IP-Adresse angegeben, aber <strong>Die</strong>nste können auch RPC, Named Pipes oder andere gültige<br />
Listenerprotokolle (zum Beispiel Net.msmq) verwenden. Den TCP/IP-Port eines <strong>Die</strong>nstes<br />
können Sie mit dem Process Explorer von <strong>Windows</strong> Sysinternals auflisten (Abbildung 6.2).<br />
Stattdessen können Sie auch an der Befehlszeile netstat -anob eingeben.<br />
Wenn der <strong>Die</strong>nst eine TCP-Portnummer verwendet, überwachen die meisten <strong>Die</strong>nste (ab<br />
<strong>Windows</strong> Vista) in der Standardeinstellung automatisch sowohl TCP Version 4 als auch TCP<br />
Version 6. Falls die IP-Adresse des Ports als 0.0.0.0 aufgeführt ist, antwortet der <strong>Die</strong>nst auf<br />
Verbindungen mit beliebigen Schnittstellenports, auch auf dem lokalen Host. Falls die IP-<br />
Adresse des Ports als 127.0.0.1 aufgeführt ist, beantwortet der <strong>Die</strong>nst nur Verbindungsversuche<br />
vom lokalen Host. Falls der <strong>Die</strong>nst eine bestimmte IP-Adresse überwacht (zum Beispiel<br />
192.168.1.10), beantwortet der <strong>Die</strong>nst nur Verbindungsversuche zu genau dieser IP-Adresse.
Abbildung 6.2 <strong>Die</strong> Registerkarte TCP/IP im Process Explorer verrät,<br />
dass die Listenerportnummer 3389 ist<br />
Einführung in <strong>Die</strong>nste 155<br />
Hinweis Der nächste Abschnitt, »Konfigurieren von <strong>Die</strong>nsten«, beschreibt das Thema sehr grundlegend.<br />
Wenn Sie bereits prinzipiell mit der Konfiguration von <strong>Windows</strong>-<strong>Die</strong>nsten vertraut sind, können Sie es<br />
überspringen.<br />
Konfigurieren von <strong>Die</strong>nsten<br />
<strong>Die</strong>nste können, müssen aber keine grafische Benutzeroberfläche haben, die Benutzer während<br />
der Laufzeit bedienen können. Aber alle <strong>Die</strong>nste enthalten Informationen, die vom<br />
Programmcode aus oder mithilfe der Konsole <strong>Die</strong>nste (Services.msc) konfiguriert werden<br />
können. <strong>Die</strong>se Informationen werden in der Registrierung gespeichert, wo der SCM sie<br />
lesen kann. Abbildung 6.3 zeigt die Konsole <strong>Die</strong>nste.<br />
Sie können doppelt auf einen der aufgeführten <strong>Die</strong>nste klicken, um die zugehörigen Details<br />
anzuzeigen (Abbildung 6.4). Standardbenutzer können sich <strong>Die</strong>nstinformationen ansehen,<br />
aber nur Mitglieder der Gruppen Konten-Operatoren, Domänen-Admins oder Organisations-<br />
Admins können die Einstellungen ändern.<br />
Registerkarte Allgemein<br />
<strong>Die</strong> Registerkarte Allgemein enthält mehrere Felder mit Informationen. <strong>Die</strong>nstname ist<br />
der interne Name, mit dem <strong>Windows</strong> auf den <strong>Die</strong>nst verweist. Er wird auch als Kurzname<br />
bezeichnet. Der <strong>Die</strong>nstname wird oft für <strong>Die</strong>nstverwaltungstools benötigt, um auf einen<br />
bestimmten <strong>Die</strong>nst zuzugreifen. Das Feld Anzeigename enthält die Bezeichnung, die in der<br />
Konsole <strong>Die</strong>nste in der Liste der <strong>Die</strong>nste angezeigt wird. Das Feld Beschreibung enthält eine<br />
kurze, vom Entwickler erstellte Meldung, die beschreibt, was der <strong>Die</strong>nst tut.
156 Kapitel 6: <strong>Die</strong>nste<br />
Abbildung 6.3 <strong>Die</strong> Konsole <strong>Die</strong>nste zeigt <strong>Die</strong>nstinformationen an<br />
Abbildung 6.4 <strong>Die</strong> Registerkarte Allgemein im Eigenschaftendialogfeld eines <strong>Die</strong>nstes<br />
Das Feld Pfad zur EXE-Datei versucht, den vollständigen Pfad zur ausführbaren Datei des<br />
<strong>Die</strong>nstes anzuzeigen, allerdings kann es vorkommen, dass nicht genug Platz für den gesamten<br />
Pfad ist. (Anders ausgedrückt: Der Text wird nicht umbrochen). Das Feld Pfad zur
Einführung in <strong>Die</strong>nste 157<br />
EXE-Datei kann bei der Problembehandlung sehr nützlich sein, wenn potenzielle Malware<br />
ähnliche oder identische Namen wie Microsoft-<strong>Die</strong>nstnamen verwendet. Zum Beispiel habe<br />
ich einmal ein Trojanisches Pferd mit dem Namen Svchost.exe gefunden, diese Datei lag<br />
allerdings im Ordner \<strong>Windows</strong>\Fonts statt in \<strong>Windows</strong>\System32, wo das Original immer<br />
gespeichert ist.<br />
Starttyp ist ein wichtiges Feld. Es kann einen der folgenden vier Werte haben:<br />
Automatisch (Verzögerter Start)<br />
Automatisch<br />
Manuell<br />
Deaktiviert<br />
Automatisch (Verzögerter Start) weist den SCM an, einen <strong>Die</strong>nst nach allen anderen <strong>Die</strong>nsten<br />
(und deren Abhängigkeiten) zu starten, die den Starttyp Automatisch haben. <strong>Die</strong>se Option<br />
wurde erstmals in <strong>Windows</strong> Vista eingeführt. <strong>Die</strong>nste mit dem Startyp Automatisch werden<br />
während des <strong>Windows</strong>-Startprozesses gestartet, ihre Reihenfolge wird durch verschiedene<br />
Registrierungsschlüssel festgelegt. Falls irgendein <strong>Die</strong>nst, der den Starttyp Automatisch hat,<br />
von anderen <strong>Die</strong>nsten abhängt, werden diese <strong>Die</strong>nste zuerst gestartet (sofern sie nicht als<br />
Deaktiviert markiert sind). <strong>Die</strong>nste mit dem Starttyp Manuell werden nur während des <strong>Windows</strong>-Startprozesses<br />
automatisch gestartet, wenn sie von anderen <strong>Die</strong>nsten oder Anwendungen<br />
benötigt werden. Viele <strong>Die</strong>nste mit dem Starttyp Manuell werden erst gestartet, wenn sie<br />
benötigt werden. Sie werden wieder beendet, sobald ihre Funktionalität nicht mehr gebraucht<br />
wird. Ein <strong>Die</strong>nst, der als Deaktiviert markiert ist, wird vom SCM nicht gestartet. Er kann<br />
erst von Hand gestartet werden, wenn der <strong>Die</strong>nst mit einem anderen Starttyp versehen wird.<br />
Das Feld <strong>Die</strong>nststatus zeigt den aktuellen Betriebszustand des <strong>Die</strong>nstes an. Mögliche Werte<br />
sind Gestartet, Beendet oder Angehalten. <strong>Die</strong> Bezeichnung Angehalten bedeutet nicht, dass<br />
der <strong>Die</strong>nst gar nicht mehr läuft. Der <strong>Die</strong>nst bleibt im Speicher aktiv und bedient unter Umständen<br />
sogar noch aktive Anforderungen, nimmt aber keine neuen Anforderungen mehr<br />
entgegen. <strong>Die</strong>nste müssen speziell programmiert werden, damit sie mit dem SCM zusammenarbeiten<br />
und die jeweilige Aktion ausführen, wenn sie gefragt werden, ob das Anhalten<br />
möglich ist. Aus Gründen der <strong>Sicherheit</strong> und Zuverlässigkeit können viele <strong>Windows</strong>-Standarddienste<br />
(über 80 Prozent) nicht angehalten werden, und fast 50 Prozent haben Berechtigungen,<br />
die verhindern, dass sie angehalten werden. Im Feld Startparameter können zusätzliche<br />
Laufzeitargumente, Direktiven oder Befehle definiert werden, die während des Starts<br />
an den <strong>Die</strong>nst übergeben werden.<br />
Registerkarte Anmelden<br />
<strong>Die</strong> Registerkarte Anmelden (Abbildung 6.5) legt fest, welches <strong>Die</strong>nstkonto mit dem <strong>Die</strong>nst<br />
verknüpft wird und welche Desktopinteraktionen und Hardwareprofile verwendet werden.<br />
Im Feld Anmelden als können Sie den <strong>Die</strong>nst so konfigurieren, dass er im SYSTEM-Kontext<br />
(Option Lokales Systemkonto) läuft, oder einen anderen <strong>Die</strong>nstkontonamen eingeben, zum<br />
Beispiel LOKALER DIENST, NETZWERKDIENST oder einen anderen gültigen <strong>Die</strong>nstnamen.<br />
Das <strong>Die</strong>nstanmeldekonto muss in der lokalen SAM-Datenbank oder in Active Directory vorhanden<br />
sein. Falls das <strong>Die</strong>nstkonto noch nicht das Recht Anmelden als <strong>Die</strong>nst zugewiesen<br />
bekommen hat, bekommt es dieses Recht, sobald Sie die Auswahl bei der Konfiguration<br />
bestätigen. Das gültige Kennwort des <strong>Die</strong>nstkontos müssen Sie in den beiden entsprechenden<br />
Feldern eingeben. Allerdings sollte kein Kennwort eingetragen werden, wenn die Konten<br />
SYSTEM, LOKALER DIENST oder NETZWERKDIENST verwendet werden. <strong>Die</strong> hier
158 Kapitel 6: <strong>Die</strong>nste<br />
angegebenen Kennwörter werden in der Registrierung gespeichert, damit der SCM sie<br />
künftig auslesen kann.<br />
Abbildung 6.5 <strong>Die</strong> Registerkarte Anmelden für <strong>Die</strong>nste<br />
Hinweis Hier wird nicht geprüft, ob das auf der Registerkarte Anmelden eingegebene Kennwort auch<br />
richtig ist. Solange Sie zweimal dasselbe Kennwort eingeben, nimmt der SCM es an und speichert es. Der<br />
<strong>Die</strong>nststart schlägt aber fehl, falls das Kennwort falsch ist.<br />
Sie können auch das Kontrollkästchen Datenaustausch zwischen <strong>Die</strong>nst und Desktop zulassen<br />
aktivieren. Manche <strong>Die</strong>nste benötigen diese Einstellung, um dem Benutzer die Interaktion<br />
zu ermöglichen. Desktopinteraktion wird von den <strong>Die</strong>nsten Druckwarteschlange und<br />
Erkennung interaktiver <strong>Die</strong>nste benötigt. In den meisten Fällen sollten Sie das Kontrollkästchen<br />
nicht aktivieren. Wenn es aktiviert ist, könnte es eine <strong>Sicherheit</strong>slücke für interaktive<br />
Endbenutzer, den Desktop, den <strong>Die</strong>nst oder den Computer reißen. Falls einem <strong>Die</strong>nst die<br />
Interaktion mit dem Desktop des Benutzers erlaubt wird, ist es zum Beispiel eher möglich,<br />
dass der <strong>Die</strong>nst vom Endbenutzer oder von Malware, die im <strong>Sicherheit</strong>skontext des Endbenutzers<br />
läuft, manipuliert wird. Der kompromittierte <strong>Die</strong>nst kann dann leicht andere Benutzer<br />
und Desktops auf demselben Computer infizieren. Dass <strong>Die</strong>nsten die Interaktion mit<br />
Benutzerdesktops verboten wird, ist ein neues Feature. Viele ältere <strong>Die</strong>nste bieten dafür<br />
noch keine vollständige Kompatibilität.<br />
Sie können einen <strong>Die</strong>nst auch in beliebigen vorhandenen Hardwareprofilen aktivieren oder<br />
deaktivieren. <strong>Die</strong>se Möglichkeit wird vor allem für Notebooks verwendet, die entweder mit<br />
der Dockingstation verbunden sind oder nicht. <strong>Die</strong>nste, die in einem bestimmten Hardwareprofil<br />
nicht gebraucht werden, sollten deaktiviert werden, um die Angriffsfläche gegenüber<br />
böswilligen Hackern zu verkleinern. (Das kann außerdem die Leistung verbessern und<br />
Strom sparen, was bestimmt der Hauptgrund war, dass Microsoft diese Möglichkeit eingeführt<br />
hat.)
Einführung in <strong>Die</strong>nste 159<br />
Registerkarte Wiederherstellung<br />
<strong>Die</strong> Registerkarte Wiederherstellung (Abbildung 6.6) definiert, welche Aktionen ausgeführt<br />
werden, falls ein bestimmter <strong>Die</strong>nst ausfällt (oder hängt). Es stehen folgende Optionen zur<br />
Auswahl:<br />
Keine Aktion durchführen<br />
<strong>Die</strong>nst neu starten<br />
Ein Programm ausführen<br />
Computer neu starten<br />
Abbildung 6.6 Registerkarte Wiederherstellung für <strong>Die</strong>nste<br />
Sie können getrennte Aktionen für den ersten, den zweiten und weitere Fehler festlegen. Sie<br />
können festlegen, nach wie vielen Tagen der Fehlerzähler zurückgesetzt wird. Falls zum<br />
Beispiel für den Fehlerzähler 1 Tag (ein üblicher Wert) eingetragen ist, wird der Zähler nach<br />
24 Stunden auf 0 zurückgesetzt, und beim nächsten auftretenden Fehler bestimmt dann wieder<br />
der Eintrag unter Erster Fehler, welche Aktion ausgeführt wird. Falls im Fehlerzähler<br />
der Wert 0 eingetragen ist, wird der Zähler erst dann zurückgesetzt, wenn der Computer neu<br />
gestartet wird. Falls als Wiederherstellungsaktion die Option <strong>Die</strong>nst neu starten ausgewählt<br />
ist, können Sie den SCM anweisen, wie viele Minuten er warten soll, bevor der den <strong>Die</strong>nst<br />
wieder startet. Sie können das Kontrollkästchen Aktionen bei Unterbrechungen mit Fehlern<br />
aktivieren aktivieren, wenn Wiederherstellungsaktionen auch bei Fehlern ausgeführt werden,<br />
die lediglich Unterbrechungen, aber keinen vollständigen Ausfall bewirken.<br />
Falls die Wiederherstellungsoption Ein Programm ausführen ausgewählt ist, wird beim Auftreten<br />
eines Fehlers ein Programm oder ein Skript ausgeführt. Abbildung 6.6 zeigt ein Beispiel,<br />
in dem das Programm Msg.exe benutzt wird, um die Nachricht »WSST-<strong>Die</strong>nst ausgefallen«<br />
an eine bestimmte Liste von Benutzern zu senden. Mit diesem Feature kann ein<br />
Helpdeskticket geöffnet werden, um den ausgefallenen <strong>Die</strong>nst zu untersuchen, oder es kann<br />
ein anderes Debugprogramm gestartet werden.
160 Kapitel 6: <strong>Die</strong>nste<br />
<strong>Die</strong>ses Feld wird auch oft benutzt, um mit dem <strong>Die</strong>nstprogramm Network Monitor Netzwerkpakete<br />
aufzuzeichnen, die zu und vom <strong>Die</strong>nst fließen, nachdem der <strong>Die</strong>nst neu gestartet<br />
wurde. Das kann bei der Problembehandlung helfen. <strong>Die</strong> aufgezeichneten Informationen<br />
können nützlich sein, um böswillige Verbindungen zu erkennen. Geben Sie die ausführbare<br />
Datei mithilfe von Laufwerkbuchstabe und vollständigem Pfad an, UNC-Pfade (zum Beispiel<br />
\\<strong>Server</strong>\Freigabename) funktionieren hier nicht.<br />
Hinweis Vor <strong>Windows</strong> XP Professional Service Pack 2 konnten Administratoren mit net send Nachrichten<br />
über das Netzwerk schicken. <strong>Die</strong>se Möglichkeit nutzte allerdings den unsicheren Nachrichtendienst.<br />
<strong>Windows</strong> Vista- und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Administratoren können stattdessen das Programm Msg.exe<br />
verwenden.<br />
Microsoft hat damit gerechnet, dass es sinnvoll ist, eine Nachricht zu senden, um Benutzer<br />
zu warnen, dass der Computer neu gestartet werden muss, weil ein <strong>Die</strong>nst neu gestartet wurde<br />
oder ausgefallen ist. Im Dialogfeld Computerneustartoptionen können Sie in solchen Fällen<br />
das Kontrollkästchen <strong>Die</strong>se Nachricht vor dem Neustart an Computer im Netzwerk senden<br />
aktivieren und eine Nachricht eingeben (Abbildung 6.7).<br />
Abbildung 6.7 Definieren einer Nachricht, die beim Neustart des Computers versendet wird<br />
<strong>Die</strong> Wiederherstellungsoptionen, die einen ausgefallenen <strong>Die</strong>nst automatisch neu starten,<br />
können böswilligen Angreifern allerdings zusätzliche Möglichkeiten verschaffen, einen<br />
Computer zu kompromittieren. Zum Beispiel legt ASLR (Address Space Layout Randomization)<br />
jedes Mal, wenn der Computer neu startet, <strong>Windows</strong>-Kern-APIs an 256 unterschiedliche,<br />
zufällig gewählte Speicheradressen. Viele Pufferüberlaufangriffe setzen voraus, dass<br />
der Angreifer die benötigte API-Adresse genau kennt, andernfalls kann der Pufferüberlaufangriff<br />
nicht funktionieren. Falls ein <strong>Die</strong>nst nach einem Fehler automatisch neu gestartet<br />
wird, sind die Chancen des Angreifers größer, bei nachfolgenden Versuchen die richtige<br />
Speicheradresse zu finden.<br />
Registerkarte Abhängigkeiten<br />
Abbildung 6.8 zeigt die Registerkarte Abhängigkeiten. Sie zeigt alle <strong>Die</strong>nste (und deren<br />
Abhängigkeiten) an, die der <strong>Die</strong>nst zum Laufen benötigt, und umgekehrt alle <strong>Die</strong>nste, die<br />
von diesem <strong>Die</strong>nst abhängen.
Abbildung 6.8 <strong>Die</strong> Registerkarte Abhängigkeiten im Eigenschaftendialogfeld eines <strong>Die</strong>nstes<br />
Angriffe auf <strong>Die</strong>nste 161<br />
Es gibt viele andere Einstellungen für <strong>Die</strong>nste, die Sie in der Konsole <strong>Die</strong>nste nicht sehen<br />
oder konfigurieren können (mehr dazu weiter unten in diesem Kapitel). Dazu gehören Berechtigungen,<br />
Privilegien und die Angabe, ob der <strong>Die</strong>nst beendet oder angehalten werden<br />
kann. Für die Konfiguration von <strong>Die</strong>nsten stehen neben der Konsole <strong>Die</strong>nste noch einige<br />
andere Möglichkeiten zur Verfügung, zum Beispiel Gruppenrichtlinien, Sc.exe, WMI (<strong>Windows</strong><br />
Management Instrumentation) und Steuerung durch Programmcode.<br />
Jeder unerwartete <strong>Die</strong>nstfehler sollte untersucht werden, um herauszufinden, ob Betriebs-<br />
oder <strong>Sicherheit</strong>sprobleme bestehen. <strong>Die</strong>nstprobleme werden zwar oft durch Faktoren ausgelöst,<br />
die nichts mit einem Angriff zu tun haben, aber bei vielen Malwarevorfällen (MS-<br />
Blaster-Worm, DDoS und so weiter) hat sich gezeigt, dass sie vorher unerklärliche <strong>Die</strong>nstprobleme<br />
auslösten.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<strong>Die</strong>nste für unterschiedliche Rollen<br />
Wie in der Einführung dieses Kapitels erwähnt, stellt <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> über 100 <strong>Die</strong>nste<br />
bereit, die je nachdem, welche Rollen und Features aktiviert sind, auf dem Computer installiert<br />
werden. Das Dokument »<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Services by Role« auf der Begleit-CD<br />
enthält eine Tabelle, die den Status der verschiedenen <strong>Die</strong>nste unter jeder <strong>Server</strong>rolle auflistet<br />
(nur in englischer Sprache verfügbar). Administratoren können diese Tabelle zurate ziehen,<br />
wenn sie versuchen, die Angriffsfläche durch Ausschalten nicht benötigter <strong>Die</strong>nste zu<br />
verkleinern.<br />
Angriffe auf <strong>Die</strong>nste<br />
Weil <strong>Windows</strong> so viele Standarddienste mitbringt, die bei jedem <strong>Windows</strong>-Systemstart automatisch<br />
gestartet werden, wissen böswillige Hacker, dass diese <strong>Die</strong>nste in vielen Fällen als<br />
Ziele in Frage kommen. <strong>Die</strong>ser Abschnitt beschreibt die bisher erfolgreichsten Angriffe auf<br />
<strong>Windows</strong>-<strong>Die</strong>nste und erklärt, auf welche Weise ein <strong>Die</strong>nst üblicherweise angegriffen wird.
162 Kapitel 6: <strong>Die</strong>nste<br />
Blaster-Wurm<br />
Der wahrscheinlich bekannteste Angriff auf einen <strong>Windows</strong>-<strong>Die</strong>nst war der sogenannte<br />
Blaster-Wurm (http://support.microsoft.com/kb/826955) im Jahr 2003. Blaster griff eine<br />
bekannte Pufferüberlaufverwundbarkeit im <strong>Windows</strong>-DCOM-RPC-<strong>Die</strong>nst von <strong>Windows</strong><br />
2000- und <strong>Windows</strong> XP-Computern an. <strong>Die</strong> <strong>Sicherheit</strong>slücke war zwar bekannt und es stand<br />
ein Microsoft-<strong>Sicherheit</strong>supdate zur Verfügung, aber ein großer Teil der <strong>Windows</strong>-Computer<br />
wurde nicht entsprechend aktualisiert. <strong>Die</strong>se mangelhafte Wartung wurde durch die fälschliche<br />
Annahme ergänzt, dass »richtig konfigurierte« Grenzfirewalls verhindern könnten,<br />
dass der Blaster-Wurm in Unternehmensnetzwerke eindringt.<br />
Der Blaster-Wurm stellte eine Verbindung zum DCOM-RPC-<strong>Die</strong>nst auf TCP-Port 135 her<br />
und leitete einen Pufferüberlaufangriff ein. Wenn der <strong>Die</strong>nst den Überlauf verursachte, bekam<br />
der Blaster-Wurm SYSTEM-Zugriff auf das kompromittierte System. Er startete daraufhin<br />
eine neue Shell auf TCP-Port 4444 und lud über TFTP auf UDP-Port 67 den Rest des<br />
Wurms herunter. Das Trojanische Pferd baute sich selbst erneut in einer Datei namens<br />
Msblaster.exe zusammen, die es in einen der Autostartpfade der Registrierung eintrug. Der<br />
Wurm startete schließlich den Computer neu und begann, über den befallenen Host andere<br />
Computer zu infizieren.<br />
Als Blaster zum ersten Mal gemeldet wurde, reagierten viele Organisationen recht träge,<br />
weil allgemein angenommen wurde, dass eine richtig konfigurierte Grenzfirewall (die keine<br />
eingehenden Zugriffe auf TCP-Port 135 erlaubte) Blaster-Infektionen auf lokalen Computern<br />
verhindern würde. Aber dann wurden infizierte Computer über VPNs an das Unternehmensnetzwerk<br />
angeschlossen, und extern infizierte Notebooks wurden in das »geschützte«<br />
Unternehmensnetzwerk eingebunden, sodass Blaster sich auf allen Unternehmenscomputern<br />
ausbreiten konnte, die keine <strong>Sicherheit</strong>supdates eingespielt hatten. Ein einziger infizierter<br />
Computer verbreitete den Wurm schnell auf alle verwundbaren Computer im Netzwerk.<br />
Blaster schaffte es, Hunderttausende verwundbarer Computer innerhalb weniger Stunden zu<br />
befallen.<br />
<strong>Die</strong> Reparaturmaßnahmen wurden dadurch erschwert, dass einige Tage später ein verwandter<br />
Wurm namens Nachi (http://support.microsoft.com/kb/826234) entwickelt wurde. <strong>Die</strong>s<br />
war ein fehlgeleiteter Versuch, verwundbare PCs zu aktualisieren. <strong>Die</strong>ser Wurm infizierte<br />
verwundbare Computer auf dieselbe Weise wie Blaster, versuchte dann aber, das <strong>Sicherheit</strong>supdate<br />
zu installieren, das die Blaster-Infektion verhinderte. Dummerweise wurde Nachi<br />
ein Paradebeispiel, warum niemals automatisierte Malware eingesetzt werden sollte, um<br />
Computerprobleme ohne die ausdrückliche Zustimmung des Computerbesitzers zu beseitigen.<br />
Nachi wies praktisch jeden verwundbaren Computer in einem Netzwerk an, ein <strong>Sicherheit</strong>supdate<br />
herunterzuladen. Das machten dann alle Computer gleichzeitig, was die Netzwerkressourcen<br />
überlastete. Und beim Installieren des Updates machte er einen Fehler, sodass<br />
das System, das er zu schützen versuchte, in einem verwundbaren Zustand zurückblieb.<br />
Ironischerweise war Nachi letztlich für mehr Probleme und Ausfallzeit verantwortlich als<br />
der Blaster-Wurm, vor dem es schützen sollte.<br />
Microsoft nahm in der Zeit nach Blaster deutliche Änderungen an seinen Verfahren vor. Es<br />
wurde beschlossen, <strong>Sicherheit</strong>supdates entschlossener auf die Computer zu verbreiten und<br />
diesen Vorgang zu automatisieren. <strong>Windows</strong>-Benutzer nutzten zwar schon länger <strong>Windows</strong><br />
Update und andere Updateclients (seit <strong>Windows</strong> 98), aber Microsoft entwickelte und verbreitete<br />
noch leistungsfähigere automatische Updatedienste, darunter verbesserte Versionen<br />
von Automatische Updates. Außerdem stellte es das kostenlose SUS/WSUS (Software
Angriffe auf <strong>Die</strong>nste 163<br />
Update Services/<strong>Windows</strong> <strong>Server</strong> Update Services) für Unternehmen zur Verfügung, die<br />
keine anderen Patchverwaltungslösungen einsetzten. Microsoft machte es auch einfacher,<br />
neue Betriebssysteme zu installieren und zu aktualisieren. Dabei wurde die Gefahr durch<br />
eine Infektion über das Netzwerk deutlich verringert, indem der Netzwerkzugriff so stark<br />
wie möglich beschränkt wurde, bis alle Updates installiert waren.<br />
<strong>Die</strong> wichtigste Lehre, die Computersicherheitsanalysten aus dem Blaster-Vorfall zogen, war,<br />
dass Grenzfirewalls nicht ausreichen, um <strong>Sicherheit</strong> zu gewährleisten. <strong>Die</strong> »knusprige Hülle<br />
mit dem weichen, saftigen Kern«, die Bill Cheswick und Hal Burch (http://www.cheswick.<br />
com/ches/papers/index.html) in ihrem berühmten Werk über Grenzfirewalls beschrieben,<br />
war endlich ins Rampenlicht gerückt. <strong>Windows</strong> XP Service Pack 2 (SP2) und neuere <strong>Windows</strong>-Clientcomputer<br />
aktivieren die hostbasierte <strong>Windows</strong>-Firewall in der Standardeinstellung.<br />
<strong>Die</strong>se Maßnahme soll verhindern, dass Millionen von Computern durch verschiedene<br />
böswillige Remoteangriffe kompromittiert werden. Microsoft begann außerdem, die <strong>Die</strong>nste<br />
besser zu schützen (mehr dazu im Abschnitt »<strong>Die</strong>nsthärtung« weiter unten in diesem Kapitel).<br />
Verbreitete Angriffsmethoden<br />
Jeder installierte und aktive <strong>Die</strong>nst bietet einem böswilligen Hacker eine weitere Angriffsfläche.<br />
<strong>Die</strong>ser Abschnitt fasst die häufigsten Bedrohungen zusammen.<br />
Pufferüberläufe<br />
Wie bereits erwähnt, stellen praktisch alle <strong>Die</strong>nste einen eingehenden Kanal für Remotezugriff<br />
zur Verfügung. Pufferüberläufe (engl. buffer overflow) werden ausgelöst, wenn ein<br />
<strong>Die</strong>nst in einer Routine die Eingaben ungeprüft übernimmt und auf diese Weise längere<br />
Daten in den Speicher geschrieben werden, als Pufferplatz reserviert wurde. Verwundbare<br />
<strong>Die</strong>nste können kompromittiert werden, sodass der <strong>Die</strong>nst unterbrochen wird. Im schlimmsten<br />
Fall erhält der Angreifer Zugriff auf das befallene System, der unter dem <strong>Sicherheit</strong>skontext<br />
des Anmeldekontos läuft, das der <strong>Die</strong>nst verwendet. Falls dieses Konto SYSTEM oder<br />
ein Administrator ist, können Angreifer in ihrem Programm beliebige Aktionen auf dem<br />
befallenen System ausführen, zum Beispiel das System steuern, Daten herunterladen, mehr<br />
Malware installieren und Remotesteuerungsshells nachladen.<br />
Denial-of-Service<br />
Falls ein <strong>Die</strong>nst einen Programmierfehler enthält, kann er daran gehindert werden, seine<br />
normalen Aufgaben zu erfüllen. <strong>Die</strong>se Unterbrechung kann temporär oder »dauerhaft« sein<br />
(bis der <strong>Die</strong>nst oder der Computer neu gestartet wird). Manchmal ist dazu ein raffinierter<br />
Pufferüberlaufangriff nötig, manchmal genügt ein einziges Netzwerkpaket oder ein eingegebenes<br />
Zeichen. Zum Beispiel konnte eine alte Version des Microsoft SQL <strong>Server</strong>-Auflösungsdienstes<br />
durch ein einziges unerwartetes ASCII-Zeichen mit dem Wert 0x04 lahmgelegt<br />
werden (http://www.iss.net/security_center/reference/2106151.html). Ein einziges manipuliertes<br />
Netzwerkpaket bildete den Kern des XP-SP2-LAND-Angriffs (http://seclists.org/<br />
bugtraq/2005/Mar/0112.html). Denial-of-Service-Angriffe verhindern den normalen Betrieb<br />
und können Unterbrechungen der Systemverarbeitung, außer Kontrolle geratenen Ressourcenverbrauch<br />
und unerwartete Computerneustarts auslösen.
164 Kapitel 6: <strong>Die</strong>nste<br />
Remoteanmeldung<br />
Viele <strong>Die</strong>nste (FTP, IIS, Remotedesktop, Terminaldienste und so weiter) stellen zusätzliche<br />
Anmeldungsmöglichkeiten zur Verfügung, über die ein Angreifer versuchen kann, Anmeldenamen<br />
und Kennwörter zu erraten, um unautorisierten Zugriff zu erhalten. In der Standardeinstellung<br />
wird das Konto Administrator nicht durch die üblichen Kontosperrungseinstellungen<br />
gesperrt. Angreifer können einen Anmeldungsdienst nutzen, um unzählige Male zu<br />
versuchen, das Administratorkennwort zu erraten, entweder von Hand oder mit einem automatisierten<br />
Tool. Sofern das <strong>Sicherheit</strong>sprotokoll nicht überwacht wird und die fehlgeschlagenen<br />
Anmeldeversuche nicht auffallen, kann ein Angreifer längere Zeit unbemerkt versuchen,<br />
das Kennwort des Kontos Administrator zu erraten.<br />
Ausspähen von Netzwerkverkehr<br />
Weil jeder Netzwerkdienst Daten sendet und empfängt, können Angreifer Kommunikationsdaten<br />
ausspähen, um unautorisiert an Informationen zu gelangen. Viele <strong>Die</strong>nste (SNMP,<br />
Telnet, FTP, POP und so weiter) verwenden Klartext für Anmeldenamen und Kennwörter.<br />
Sogar andere <strong>Die</strong>nste, die nicht mit Klartextdaten arbeiten, lassen sich ausnutzen. Zum Beispiel<br />
war RDP einige Zeit nach seiner Einführung gegen Man-in-the-Middle-Angriffe verwundbar.<br />
(Das wurde korrigiert.) Obwohl RDP Verschlüsselung nutzte, konnte eine neue<br />
Sitzung von einem Remoteangreifer abgefangen und umgeleitet werden. Weil RDP Endpunktclients<br />
erst ab Version 6.0 authentifizierte, war es für Man-in-the-Middle-Angreifer<br />
möglich (wenn auch sehr schwierig), sich selbst in den Kommunikationsstrom einzuklinken<br />
und verschlüsselte Anmeldekennwörter Zeichen für Zeichen zu extrahieren. Mehrere<br />
Hackingtools machten es ganz einfach, einen RDP-Man-in-the-Middle-Angriff auszuführen.<br />
Es reichte, wenn der Angreifer einige Schaltflächen anklickte, sobald er es erst einmal geschafft<br />
hatte, sich in den Kommunikationspfad einzuklinken. Das Ausspähen von Verkehr<br />
kann auch genutzt werden, um andere vertrauliche und persönliche Informationen abzufangen,<br />
es müssen nicht immer Anmeldeinformationen sein.<br />
Kompromittierte Kennwörter<br />
Vollständig kompromittierte Systeme können eine Ausweitung des Angriffs ins Netzwerk<br />
ermöglichen, wenn die Kennwörter der <strong>Die</strong>nstanmeldekonten ausgelesen werden. Falls ein<br />
Angreifer privilegierten Zugriff auf ein System hat (zum Beispiel Administrator oder<br />
SYSTEM), kann er mithilfe verschiedener Methoden und Tools Anmeldeinformationen<br />
von <strong>Die</strong>nstanmeldekonten im Klartext auslesen. Falls die so ausgespähten Anmeldeinformationen<br />
auf anderen Computern oder in der gesamten <strong>Windows</strong>-Domäne genutzt werden,<br />
können weitere Ressourcen kompromittiert werden. <strong>Die</strong>s wird in Kapitel 14, »Schützen des<br />
Netzwerks«, ausführlich beschrieben.<br />
Fehlkonfiguration<br />
Auch wenn ein <strong>Die</strong>nst einwandfrei programmiert ist, sodass er keinerlei <strong>Sicherheit</strong>slücken<br />
enthält, kann er kompromittiert werden. Es passiert häufig, dass Benutzer und Administratoren<br />
beim Konfigurieren der <strong>Die</strong>nste Fehler machen, die ihre Computer für unautorisierten<br />
Zugriff öffnen. Zum Beispiel könnte ein Benutzer den IIS- oder FTP-<strong>Die</strong>nst installieren,<br />
aber schwache Kennwörter verwenden. Oder ein Benutzer installiert ein Peer-to-Peer-<br />
Filesharing-Programm, um einige wenige Ordner mit anderen Benutzern auszutauschen,<br />
gibt aber stattdessen sein gesamtes Festplattenlaufwerk frei. <strong>Die</strong>ses Problem war oft dafür<br />
verantwortlich, dass vertrauliche oder sogar streng geheime Dokumente versehentlich im<br />
Internet veröffentlicht wurden.
<strong>Die</strong>nsthärtung 165<br />
Unautorisierte Datenweitergabe<br />
Viele <strong>Die</strong>nste geben Systeminformationen bekannt, die von böswilligen Angreifern genutzt<br />
werden können. Manchmal beziehen sich diese Informationen auf den <strong>Die</strong>nst selbst und sind<br />
kritisch für den normalen Betrieb des <strong>Die</strong>nstes. In anderen Fällen werden unerwartete Daten<br />
veröffentlicht, wenn böswillige Verbindungsdaten an den <strong>Die</strong>nst gesendet werden. Zum Beispiel<br />
beschreibt das Microsoft-<strong>Sicherheit</strong>sbulletin MS05-007 (http://www.microsoft.com/<br />
technet/security/Bulletin/MS05-007.mspx), wie die Kombination aus Computerbrowserdienst<br />
und Named Pipes missbraucht werden kann, um die Namen der angemeldeten Benutzerkonten<br />
aufzulisten.<br />
Social Engineering<br />
<strong>Die</strong>nste, die direkten Kontakt mit dem Endbenutzer herstellen, zum Beispiel Peer-to-Peer-<br />
Filesharing, bieten Malwareverbreitern etliche Möglichkeiten, die Benutzer durch Tricks<br />
dazu zu bringen, böswillige Programme auszuführen. Malware, die Peer-to-Peer-Systeme<br />
angreift, kann einen Chat mit einem Endbenutzer vortäuschen und dann eine Aufforderung<br />
an den Benutzer senden, eine neue Dateiübertragung zu genehmigen. <strong>Die</strong> Dateiübertragung<br />
wird als gewünschter Inhalt beschrieben, enthält in Wirklichkeit aber ein Trojanisches Pferd.<br />
Viele Antimalwareprogramme prüfen die Inhalte nicht, die über solche <strong>Die</strong>nste in den Computer<br />
gelangen. So kann es passieren, dass die Infektion sogar auf einem geschützten Computer<br />
unbemerkt bleibt.<br />
<strong>Die</strong>nste sind vielen unterschiedlichen Arten von Angriffen ausgesetzt, und jeder zusätzliche<br />
laufende <strong>Die</strong>nst auf einem Computer vergrößert die Gefahr einer Kompromittierung.<br />
<strong>Die</strong>nsthärtung<br />
Nach dem Blaster-Wurm verstärkte Microsoft das Gefahrenmodell der <strong>Windows</strong>-Standarddienste,<br />
um ihre <strong>Sicherheit</strong>sbedrohungen zu untersuchen und zu minimieren. Im Rahmen<br />
dieser Anstrengungen wurden Standardberechtigungen und Privilegien geändert, und es<br />
wurden viele neue Schutzmaßnahmen für <strong>Die</strong>nste entwickelt. Daher weisen <strong>Die</strong>nste, die<br />
in <strong>Windows</strong> Vista und neueren <strong>Windows</strong>-Versionen laufen, gegenüber älteren <strong>Windows</strong>-<br />
Clientversionen zahlreiche <strong>Sicherheit</strong>sverbesserungen auf. Das sind unter anderem:<br />
Jeder <strong>Die</strong>nst hält sich an das <strong>Sicherheit</strong>smodell der geringstmöglichen Privilegien.<br />
<strong>Die</strong>nste wurden so gestaltet, dass mehr <strong>Die</strong>nste im Anmeldungskontext LOKALER<br />
DIENST oder NETZWERKDIENST laufen.<br />
Jeder <strong>Die</strong>nst hat eine <strong>Sicherheit</strong>s-ID, was eine dienstspezifische Zugriffssteuerung<br />
ermöglicht.<br />
Auf manche <strong>Die</strong>nste werden einschränkende SIDs angewendet.<br />
<strong>Die</strong>nste können anhand der Netzwerkdomäne eingeschränkt werden.<br />
Für alle <strong>Windows</strong>-<strong>Die</strong>nste ist Sitzung-0-Isolierung erforderlich.<br />
Alle <strong>Die</strong>nste haben die verbindliche Integritätsebene System.<br />
<strong>Die</strong> Datenausführungsverhinderung ist für alle <strong>Die</strong>nste aktiviert.<br />
<strong>Die</strong> SCM-Statusbenachrichtigung wurde verbessert.<br />
<strong>Die</strong>se Verbesserungen werden in den folgenden Abschnitten im Einzelnen beschrieben.
166 Kapitel 6: <strong>Die</strong>nste<br />
Geringstmögliche Privilegien<br />
<strong>Windows</strong>-Privilegien legen fest, was ein <strong>Sicherheit</strong>sprinzipal auf einem Computer tun kann.<br />
(Anders ausgedrückt: Privilegien sind nicht mit einem bestimmten geschützten Objekt verknüpft.)<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> hat 35 unterschiedliche Privilegien (SeImpersonatePrivilege,<br />
SeCreateGlobalPrivilege und so weiter), die einem <strong>Sicherheit</strong>sprinzipal zugewiesen werden<br />
können. Tabelle 6.2 listet die verfügbaren Privilegien auf. Sie können sich die Privilegien<br />
auch in den Gruppenrichtlinien unter Computerkonfiguration\<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\Lokale<br />
Richtlinien\Zuweisen von Benutzerrechten ansehen. In den Gruppenrichtlinien<br />
sind allerdings auch 9 Rechte aufgeführt, die eigentlich keine Privilegien sind.<br />
Tabelle 6.2 Privilegien für <strong>Die</strong>nstanmeldekonten, die standardmäßig aktiviert sind.<br />
A = standardmäßig aktiviert; D = standardmäßig deaktiviert, kann aber aktiviert werden;<br />
<strong>–</strong> = Privileg nicht zugewiesen und kann nicht aktiviert werden<br />
Privileg SYSTEM LOKALER<br />
DIENST<br />
NETZWERK-<br />
DIENST<br />
Adminis-<br />
tratoren<br />
Standard-<br />
benutzer<br />
AssignPrimaryToken D D D <strong>–</strong> <strong>–</strong><br />
SeAudit A D D <strong>–</strong> <strong>–</strong><br />
SeBackup D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeChangeNotify A A A A A<br />
SeCreateGlobal A A A A A<br />
SeCreatePagefile A <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeCreatePermanent A <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong><br />
SeCreateSymbolicLink A <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeCreateToken <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong><br />
SeDebug A <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeEnableDelegation <strong>–</strong> <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeImpersonate A A A A A<br />
SeIncreaseBasePriority A <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
IncreaseQuotaPrivilege D D D D <strong>–</strong><br />
SeIncreaseWorkingSet A D D D D<br />
SeLoadDriver D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeLockMemory A <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong><br />
SeMachineAccount <strong>–</strong> D D D D<br />
SeManageVolume D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeProfileSingleProcess A <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeRelabel <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong><br />
SeRemoteShutdown <strong>–</strong> <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeRestore D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeSecurity D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeShutdown D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeSyncAgent <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong>
Privileg SYSTEM LOKALER<br />
DIENST<br />
NETZWERK-<br />
DIENST<br />
Adminis-<br />
tratoren<br />
SeSystemEnvironment D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeSystemProfile A <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeSystemtime D D <strong>–</strong> D <strong>–</strong><br />
SeTakeOwnership D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeTcb A <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong><br />
SeTimeZone A D <strong>–</strong> D <strong>–</strong><br />
SeTrustedCredManAccess <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong><br />
SeUndock D <strong>–</strong> <strong>–</strong> D <strong>–</strong><br />
SeUnsolicitedInput <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong> <strong>–</strong><br />
Standard-<br />
benutzer<br />
<strong>Die</strong>nsthärtung 167<br />
Direkt aus der Praxis: Rechte und Privilegien<br />
Rechte (engl. rights) geben (oder verweigern) einem Benutzer das Recht, sich auf bestimmte<br />
Weise anzumelden. <strong>Die</strong> meisten Leute bringen Rechte und Privilegien durcheinander,<br />
aber es sind ganz unterschiedliche Dinge. Zum Beispiel kann ein Benutzer das<br />
Recht haben, sich lokal anzumelden, aber ihm wird das Recht verweigert, sich als Stapelverarbeitungsauftrag<br />
anzumelden, und so weiter. <strong>Die</strong>se Rechte werden nur ausgewertet,<br />
während sich ein <strong>Sicherheit</strong>sprinzipal anmeldet. Falls die Anmeldung erfolgreich ist, wird<br />
anhand der Authentifiziererüberprüfung und der Benutzerrechtverifizierung das Zugriffstoken<br />
des Prinzipals erstellt. <strong>Die</strong> Benutzerrechte werden nicht in das Zugriffstoken eingetragen.<br />
Privilegien werden aber sehr wohl mit dem Zugriffstoken verknüpft. Sie werden<br />
im Verlauf einer Anmeldesitzung ständig ausgewertet.<br />
Ein Privileg erlaubt dem Prinzipal dagegen, nach der Anmeldung irgendeine Aktion<br />
durchzuführen. Zum Beispiel heißt ein Privileg SeChangeNotifyPrivilege, in den Gruppenrichtlinien<br />
wird es als Auslassen der durchsuchenden Überprüfung aufgelistet. Se-<br />
ChangeNotifyPrivilege ist das grundlegendste Privileg in <strong>Windows</strong>, und es wird jedem<br />
Prozess zugewiesen. Es erlaubt dem Prinzipal (oder genauer: einem Prozess, der im Namen<br />
des Prinzipals arbeitet), bestimmte <strong>Sicherheit</strong>sprüfungen zu umgehen. Nehmen wir<br />
zum Beispiel an, es gibt einen Ordner namens C:\ForYourEyesOnly008. In diesem Ordner<br />
befindet sich eine Datei namens For009.txt. Der Ordner definiert nur Berechtigungen<br />
für den Benutzer 008. <strong>Die</strong> Datei gewährt aber dem Benutzer 009 Leseberechtigungen.<br />
Dank SeChangeNotifyPrivilege kann Benutzer 009 direkt auf die Datei zugreifen, ohne<br />
dass der Zugriffsversuch abgewiesen wird, weil er den Ordner, in dem sich die Datei befindet,<br />
nicht lesen kann. Hätte 009 dieses Privileg nicht in seinem Zugriffstoken, bekäme<br />
er eine Fehlermeldung, weil das Verzeichnis ihm den Zugriff verweigert.<br />
Jesper M. Johansson<br />
Microsoft Security MVP
168 Kapitel 6: <strong>Die</strong>nste<br />
Das Konto SYSTEM besitzt die meisten standardmäßig aktivierten Privilegien, gefolgt von<br />
Mitgliedern der Gruppen Administratoren, LOKALER DIENST, NETZWERKDIENST und<br />
zuletzt Standardbenutzer ohne erhöhte Privilegien. Tabelle 6.2 zeigt, welche Standardprivilegien<br />
den integrierten <strong>Die</strong>nstanmeldekonten, Administratoren und Standardbenutzern zugewiesen<br />
sind, sofern sie nicht anderweitig eingeschränkt sind.<br />
Falls ein Privileg im Token eines <strong>Die</strong>nstprozesses vorhanden, aber deaktiviert ist, kann es<br />
gewissermaßen als aktiviert betrachtet werden (weil der <strong>Die</strong>nst ein deaktiviertes Privileg<br />
jederzeit aktivieren kann). Prozesse, die als Standardbenutzer laufen, besitzen nur fünf Standardprivilegien,<br />
genauso wie nicht angehobene Prozesse, die unter der Benutzerkontensteuerung<br />
als Administrator laufen. Ein angehobener Prozess hat deutlich mehr Privilegien in<br />
seinem Token. <strong>Die</strong>nstanmeldekonten unterliegen nicht der Benutzerkontensteuerung, dies<br />
gilt natürlich auch für das integrierte Konto Administrator.<br />
Hinweis <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> unterscheiden sich etwas bezüglich der Privilegien,<br />
die Standardbenutzern zugewiesen werden. In <strong>Windows</strong> Vista bekommen Benutzer SeTimeZone, damit sie<br />
die Zeitzone des Systems ändern können, ohne ein Administrator zu sein. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wird<br />
dieses Privileg durch SeCreateGlobal ersetzt, das für Freigabeobjekte gebraucht wird, etwa in den Terminaldiensten<br />
und anderen Freigabediensten.<br />
Microsoft hat alle <strong>Windows</strong>-Standarddienste in einer ausführlichen Gefahrenmodellierung<br />
analysiert. Falls ein <strong>Die</strong>nst keinen SYSTEM-Zugriff benötigt, bekommt er stattdessen<br />
LOKALER DIENST- oder NETZWERKDIENST-Zugriff. Indem das <strong>Die</strong>nstanmeldekonto<br />
mit den geringstmöglichen Privilegien verwendet wird, verringert Microsoft die Bedrohung<br />
durch eine böswillige Manipulation des <strong>Die</strong>nstes. Leider laufen zwar nur etwas über die<br />
Hälfte der bereitgestellten <strong>Die</strong>nste im SYSTEM-Kontext, aber dies sind absolut gesehen<br />
mehr <strong>Die</strong>nste als in <strong>Windows</strong> <strong>Server</strong> 2003. Das zeigt, wie stark der Funktionsumfang im<br />
neuen Betriebssystem zugenommen hat.<br />
Um zusätzlichen Schutz zu bieten, können <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> während<br />
des <strong>Die</strong>nststarts alle nicht benötigten Standardprivilegien entfernen, die einem <strong>Die</strong>nstanmeldekonto<br />
zugewiesen wurden. <strong>Die</strong> Entwickler bei Microsoft haben alle <strong>Windows</strong>-<br />
Standarddienste untersucht und nicht erforderliche Privilegien entfernt. Entsprechend laufen<br />
viele <strong>Die</strong>nste (zum Beispiel DHCP-Client) mit weniger Privilegien, als dem <strong>Die</strong>nstanmeldekonto<br />
zugewiesen sind, unter dem sie ausgeführt werden. Microsoft stellt viele nützliche<br />
Tools zur Verfügung und ermuntert Entwickler, ihre eigenen <strong>Die</strong>nste zu analysieren und<br />
unbenötigte Privilegien zu entfernen. Jedes Privileg weniger kann möglicherweise vor<br />
einem Angriff schützen. Bei der Installation eines <strong>Die</strong>nstes kann der <strong>Die</strong>nst in einen Registrierungsschlüssel<br />
namens RequiredPrivileges (siehe das Beispiel in Abbildung 6.1) eintragen,<br />
welche Privilegien er unbedingt braucht, um seine Aufgabe zu erfüllen.<br />
Der SCM untersucht die Privilegien, die der <strong>Die</strong>nst anfordert, und entfernt aus dem Anmeldekonto<br />
des <strong>Die</strong>nstes alle Privilegien, die nicht als unbedingt erforderlich gekennzeichnet<br />
sind. Falls keine Privilegien als erforderlich aufgelistet sind, entfernt der SCM alle zusätzlichen<br />
Privilegien, die über den Standardsatz im <strong>Die</strong>nstanmeldekonto hinausgehen. Falls ein<br />
<strong>Die</strong>nst mehr Privilegien anfordert, als dem <strong>Die</strong>nstanmeldekonto bereits zugewiesen sind,<br />
wird der <strong>Die</strong>nst nicht gestartet.<br />
Falls ein <strong>Die</strong>nstprozess (zum Beispiel Svchost.exe) mehrere <strong>Die</strong>nste hostet, berechnet der<br />
SCM, welche Privilegien für alle <strong>Die</strong>nste mindestens benötigt werden, und entfernt dann die<br />
nicht erforderlichen Privilegien. Falls allerdings einer der <strong>Die</strong>nste, die sich denselben <strong>Die</strong>nst-
<strong>Die</strong>nsthärtung 169<br />
prozess teilen, alle Privilegien braucht, die dem <strong>Die</strong>nstanmeldekonto zugewiesen sind, werden<br />
keine Privilegien entfernt. Und die Privilegien stehen allen <strong>Die</strong>nsten zur Verfügung, die<br />
im gemeinsam genutzten Host arbeiten. Anders ausgedrückt: Gemeinsam genutzte Prozesse<br />
können den Nutzen der Privilegienanalyse deutlich verringern. Sie können sich ansehen,<br />
welche Privilegien ein <strong>Die</strong>nst braucht (im Gegensatz zu den Privilegien, die dem Prozess<br />
tatsächlich zugewiesen sind), indem Sie sc mit dem Argument qprivs aufrufen. <strong>Die</strong> Syntax<br />
lautet:<br />
sc <strong>Server</strong> qprivs [<strong>Die</strong>nstname]<br />
Abbildung 6.9 zeigt ein Beispiel für den Befehl sc qprivs.<br />
Abbildung 6.9 sc kann die von einem <strong>Die</strong>nst benötigten Privilegien anzeigen<br />
Sie können auch das Befehlszeilenargument privs verwenden, um mit sc Privilegien festzulegen.<br />
<strong>Die</strong> Syntax lautet:<br />
sc <strong>Server</strong> privs [Privilegien]<br />
Dabei steht [Privilegien] für eine Liste mit Privilegien, die durch Schrägstriche (/) getrennt<br />
sind. Zum Beispiel können Sie die Privilegien für Sicherung und Wiederherstellung hinzufügen,<br />
indem Sie SeBackupPrivilege/SeRestorePrivilege angeben. <strong>Die</strong>nstentwickler und<br />
Systemadministratoren können die Möglichkeit, mit SCM Privilegien zu entfernen, nutzen,<br />
um die Angriffsfläche von <strong>Die</strong>nsten zu verringern. Allerdings sollten Benutzer und Administratoren<br />
die von einem <strong>Die</strong>nst geforderten Privilegien nur ändern, nachdem sie die neue<br />
Konfiguration sorgfältig analysiert und getestet haben.<br />
Sie können auch den Process Explorer verwenden (Abbildung 6.10), um die Privilegien<br />
(sowie Berechtigungen und SIDs) eines <strong>Die</strong>nstprozesses anzuzeigen. Denken Sie daran, dass<br />
ein Privileg dem <strong>Die</strong>nst zur Verfügung steht, falls es hier aufgelistet wird (aktiviert oder deaktiviert).<br />
Deaktiviert bedeutet nicht, dass es für alle Zeiten deaktiviert ist. Falls ein Privileg<br />
nicht erlaubt ist, wird es gar nicht aufgelistet.
170 Kapitel 6: <strong>Die</strong>nste<br />
Abbildung 6.10 Anzeigen der Privilegien eines <strong>Die</strong>nstprozesses<br />
<strong>Die</strong>nst-SIDs<br />
Das Prozesstoken eines <strong>Die</strong>nstes enthält die SID NT-AUTORITÄT\DIENST (S-1-5-6). Indem<br />
Sie bei einem laufenden Prozess nach dieser SID suchen, können Sie schnell feststellen, ob<br />
der Prozess ein <strong>Die</strong>nst oder nur eine Anwendung ist.<br />
Ab <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> kann jedem <strong>Die</strong>nst auch eine dienstspezifische<br />
SID zugewiesen werden, die sich aus seinem Namen ableitet. (Anders ausgedrückt: <strong>Die</strong>nste<br />
mit demselben Namen haben auf unterschiedlichen Systemen identische SIDs.) Eine dienstspezifische<br />
SID ermöglicht es, <strong>Die</strong>nsten direkt Berechtigungen für beliebige geschützte<br />
Objekte zuzuweisen. Sie kann auch genutzt werden, um den <strong>Die</strong>nst auf andere Weise zu<br />
steuern, um zum Beispiel Ports in der <strong>Windows</strong>-Firewall und IPsec zu öffnen.<br />
Sie können sich die SID eines <strong>Die</strong>nstes ansehen (auch solcher, die Sie noch gar nicht installiert<br />
haben), indem Sie an der Eingabeaufforderung sc mit dem Argument showsid aufrufen.<br />
<strong>Die</strong> Syntax lautet:<br />
sc showsid [<strong>Die</strong>nstname]<br />
<strong>Die</strong> SID eines <strong>Die</strong>nstes wird berechnet, indem der Unicodename des <strong>Die</strong>nstes (als Großbuchstaben)<br />
an eine SHA-1-Hashfunktion übergeben und das Hashergebnis an »S-1-5-80-«<br />
angehängt wird. Zum Beispiel lautet die SID für den <strong>Die</strong>nst W32Time: S-1-5-80-4267341169-<br />
2882910712-659946508-2704364837-2204554466. <strong>Die</strong>se SID ist auf allen <strong>Windows</strong> Vistaund<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Systemen gleich.<br />
Wenn Sie eine dienstspezifische SID zu einem <strong>Die</strong>nst hinzufügen, müssen Sie das tun, bevor<br />
der <strong>Die</strong>nst gestartet wird. Sie können die SID nicht mehr ändern, wenn der <strong>Die</strong>nst erst einmal<br />
läuft. Wenn eine dienstspezifische SID verwendet wird, wird sie zusammen mit der<br />
Anmeldekonto-SID des <strong>Die</strong>nstes zum Prozesstoken des <strong>Die</strong>nstes hinzugefügt. Falls ein gemeinsam<br />
genutzter <strong>Die</strong>nstprozess (zum Beispiel Svchost.exe) mehrere <strong>Die</strong>nste mit dienst-
<strong>Die</strong>nsthärtung 171<br />
spezifischen SIDs hostet, werden alle SIDs zum Token des <strong>Die</strong>nstprozesses hinzugefügt. Sie<br />
können dann von allen <strong>Die</strong>nsten im gemeinsam genutzten <strong>Die</strong>nstprozess eingesetzt werden.<br />
Falls eine dienstspezifische SID nicht aktiviert ist, wird zumindest die SID des <strong>Die</strong>nstanmeldekontos<br />
zum Token des <strong>Die</strong>nstprozesses hinzugefügt.<br />
Definieren von Zugriffssteuerungseinträgen für einen <strong>Die</strong>nst<br />
Falls ein <strong>Die</strong>nsttoken eine dienstspezifische SID hat, können Sie vom Programmcode aus<br />
oder mit Tools wie Icacls Berechtigungen definieren. Abbildung 6.11 zeigt ein Beispiel, wie<br />
Sie den Namen eines <strong>Die</strong>nstes angeben, um Berechtigungen in der GUI des <strong>Windows</strong>-A<br />
CL-Editors festzulegen. Sie müssen dem Kurznamen des <strong>Die</strong>nstes die Bezeichnung NT<br />
SERVICE\ voranstellen (auch in der deutschen Version muss die englische Bezeichnung<br />
verwendet werden). Abbildung 6.12 zeigt das Ergebnis im ACL-Editor.<br />
Abbildung 6.11 Auswählen des <strong>Die</strong>nstes W32Time<br />
Abbildung 6.12 Zuweisen von Berechtigungen an den <strong>Die</strong>nst W32Time
172 Kapitel 6: <strong>Die</strong>nste<br />
Auch wenn Sie NT SERVICE\ voranstellen müssen, damit <strong>Windows</strong> den richtigen <strong>Sicherheit</strong>sprinzipal<br />
findet, konvertiert <strong>Windows</strong> die eingegebene Bezeichnung in den reinen<br />
Kurznamen (zum Beispiel W32Time), sobald Sie die Schaltfläche Namen überprüfen anklicken.<br />
Aber es reicht nicht, wenn Sie nur den Kurznamen eingeben, um Berechtigungen zu<br />
definieren.<br />
Sie können NT SERVICE\<strong>Die</strong>nstname oder die SID des <strong>Die</strong>nstes verwenden, wenn Sie<br />
Zugriffssteuerungsberechtigungen mit dem Tool Icalcs konfigurieren (Abbildung 6.13).<br />
Abbildung 6.13 Festlegen von Berechtigungen für einen <strong>Die</strong>nst mit Icacls<br />
Wie wichtig eine dienstspezifische SID ist, kann gar nicht oft genug betont werden. Vor<br />
<strong>Windows</strong> Vista bekamen <strong>Die</strong>nste die Berechtigungen gewährt, die das <strong>Die</strong>nstanmeldekonto<br />
besaß. Falls dem <strong>Die</strong>nstanmeldekonto (zum Beispiel LOKALER DIENST) zusätzliche Berechtigungen<br />
gewährt werden mussten, damit ein <strong>Die</strong>nst richtig funktionierte, standen sie<br />
allen <strong>Die</strong>nsten zur Verfügung, die dasselbe <strong>Die</strong>nstanmeldekonto verwendeten. Jetzt können<br />
Berechtigungen für einzelne <strong>Die</strong>nste gewährt oder verweigert werden. Und weil <strong>Die</strong>nste<br />
SIDs haben, kann die Überwachung für Objektzugriffsversuche einfacher aufdecken, welche<br />
<strong>Die</strong>nstzugriffe gelingen oder fehlschlagen. Außerdem kann so der Netzwerkverkehr vom<br />
<strong>Die</strong>nst gesteuert werden. Zum Beispiel aktiviert die <strong>Windows</strong>-Firewall standardmäßig die<br />
Filterung für ausgehenden Verkehr, sodass jeder <strong>Die</strong>nst nur Verkehr auf seinen explizit genehmigten<br />
Ports übertragen darf.<br />
Übrigens können Sie auch anzeigen, welche Berechtigungen mit einem <strong>Die</strong>nst verknüpft<br />
sind (das heißt, wer welchen Zugriff auf den <strong>Die</strong>nst hat), indem Sie den Befehl sc mit dem<br />
Befehlszeilenargument sdshow aufrufen. <strong>Die</strong> Syntax lautet:<br />
sc sdshow [<strong>Die</strong>nstname] <br />
Das Ergebnis wird im SDDL-Format ausgegeben. Sie können das optionale Argument showrights<br />
hinzufügen, um die SDDL-Ausgabe in einfacher lesbare Zugriffssteuerungseinträge<br />
zu konvertieren. Sie können sich die Berechtigungen natürlich auch in den normalen <strong>Windows</strong>-GUIs<br />
und mit dem Process Explorer ansehen.
<strong>Die</strong>nsthärtung 173<br />
Schreibeingeschränkte SIDs<br />
Ein <strong>Die</strong>nst hat drei gültige SID-Typen:<br />
Keine (None)<br />
Uneingeschränkt (Unrestricted)<br />
Eingeschränkt (Restricted)<br />
Der SID-Typ None bedeutet, dass der <strong>Die</strong>nst keine dienstspezifische SID hat. <strong>Die</strong>ser Typ<br />
kann für alte <strong>Die</strong>nste mit Anwendungskompatibilitätsproblemen verwendet werden. Der<br />
SID-Typ Unrestricted bedeutet, dass der <strong>Die</strong>nst eine dienstspezifische SID hat, die für die<br />
Zugriffssteuerung verwendet werden kann, und dass diese SID zum <strong>Die</strong>nstprozesstoken<br />
hinzugefügt wurde. Der SID-Typ Restricted wird verwendet, um explizit eine weitere<br />
Zugriffssteuerung für den <strong>Die</strong>nst zu erzwingen. Weitere Informationen zu eingeschränkten<br />
Token finden Sie in Kapitel 3, »Objekte: Was Sie wollen«.<br />
Wenn ein <strong>Die</strong>nst mit dem SID-Typ Restricted markiert ist, wird die eigene SID des <strong>Die</strong>nstes<br />
zur Liste der eingeschränkten SIDs im Prozesstoken hinzugefügt, zusammen mit drei weiteren<br />
SIDs:<br />
Jeder-SID (S-1-1-0)<br />
Logon SID (S-1-5-5-0-64163)<br />
SCHREIBEN EINGESCHRÄNKT-SID (S-1-5-33)<br />
Wenn ein <strong>Die</strong>nst versucht, in eine Ressource zu schreiben, er aber die SCHREIBEN EINGE-<br />
SCHRÄNKT-SID in seinem Zugriffstoken hat, wird der Zugriff verhindert, sofern nicht der<br />
Gruppe Jeder, der SCHREIBEN EINGESCHRÄNKT-SID oder einer der <strong>Die</strong>nst-SIDs explizit<br />
die Schreibberechtigung zugewiesen wurde. <strong>Die</strong> meisten geschützten Objekte erlauben<br />
diesen SIDs keine Schreibberechtigungen, daher werden die meisten Schreiboperationen<br />
standardmäßig verhindert. Das soll verhindern, dass ein Angreifer, der es geschafft hat,<br />
einen schreibeingeschränkten <strong>Die</strong>nst zu kompromittieren, trotzdem nur eingeschränkt und<br />
kompliziert in Systembereiche schreiben kann (zum Beispiel System32).<br />
Leider sind nur eine Handvoll von <strong>Die</strong>nsten als schreibeingeschränkt markiert. Sie können<br />
sich den SID-Typ eines <strong>Die</strong>nstes ansehen, indem Sie den Befehl sc mit dem Befehlszeilenargument<br />
qsidtype aufrufen (Abbildung 6.14) oder den Process Explorer verwenden. <strong>Die</strong><br />
Syntax für sc lautet:<br />
sc qsidtype [<strong>Die</strong>nstname]<br />
Abbildung 6.14 Der Befehl sc qsidtype verrät den SID-Typ eines <strong>Die</strong>nstes
174 Kapitel 6: <strong>Die</strong>nste<br />
<strong>Die</strong> <strong>Windows</strong>-Firewall liefert ein gutes Beispiel, wie die SCHREIBEN EINGESCHRÄNKT-<br />
SID verwendet wird. <strong>Die</strong> <strong>Windows</strong>-Firewall ist naturgemäß Angriffen ausgesetzt, die über<br />
den eingehenden Verkehr eintreffen. Es gibt vier <strong>Windows</strong>-Firewalldienste: <strong>Windows</strong>-Firewall<br />
(Mpssvc), Base Filtering Engine (Bfe), Diagnoserichtliniendienst (Dps) und Leistungsprotokolle<br />
und -warnungen (Pla). <strong>Windows</strong> legt diese vier <strong>Die</strong>nste unter derselben Svchost.exe-Instanz<br />
an. Alle <strong>Die</strong>nste sind als schreibeingeschränkt markiert und enthalten die<br />
SCHREIBEN EINGESCHRÄNKT-SID (Abbildung 6.15).<br />
Abbildung 6.15 Der Process Explorer zeigt eine SCHREIBEN<br />
EINGESCHRÄNKT-SID für einen <strong>Die</strong>nst an<br />
Mit dem Befehl icacls /t /findsid "NT-AUTORITÄT\SCHREIBEN EINGESCHRÄNKT" können Sie<br />
feststellen, welche geschützten Objekte explizite Berechtigungen für die SCHREIBEN<br />
EINGESCHRÄNKT-SID haben. In meinem Testsystem liefert die Icacls-Abfrage zwei<br />
Dateien im Zusammenhang mit der <strong>Windows</strong>-<strong>Sicherheit</strong>skonfiguration, in die die <strong>Die</strong>nste<br />
schreiben können.<br />
Sie können den SID-Typ eines <strong>Die</strong>nstes mit dem Befehl sc sidtype festlegen. <strong>Die</strong> Syntax<br />
lautet:<br />
sc sidtype [<strong>Die</strong>nstname] <br />
Änderungen am SID-Typ werden erst wirksam, wenn der <strong>Die</strong>nst gestartet oder neu gestartet<br />
wird. Endbenutzer und Administratoren sollten SID-Typen nur ändern, wenn sie die Folgen<br />
genau getestet und analysiert haben.<br />
Hinweis Es gibt eine EINGESCHRÄNKT-SID, die restriktiver als die SCHREIBEN EINGESCHRÄNKT-<br />
SID ist, weil sie verhindert, dass neben Schreib- auch Leseoperationen durchgeführt werden.
<strong>Die</strong>nsthärtung 175<br />
Eingeschränkter Netzwerkzugriff<br />
Sie können den Netzwerkzugriff anhand des <strong>Die</strong>nstnamens (oder der SID) und auf bestimmte<br />
Ports, Protokolle oder Netzwerke beschränken. <strong>Die</strong> neue <strong>Windows</strong>-Firewall mit erweiterter<br />
<strong>Sicherheit</strong> erlaubt einem Administrator, Regeln für jeden beliebigen <strong>Die</strong>nst über drei<br />
Profile zu definieren (Öffentlich, Privat und Domäne). <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bringt Dutzende<br />
vordefinierter Regeln mit. Viele dieser Regeln gelten für <strong>Die</strong>nste. Manchmal gilt eine<br />
Regel für alle Programme und <strong>Die</strong>nste, manchmal nur für einen bestimmten <strong>Die</strong>nst (Abbildung<br />
6.16 zeigt ein Beispiel) oder eine Gruppe von <strong>Die</strong>nsten.<br />
Abbildung 6.16 <strong>Die</strong>nstbasierte Firewallregel<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ist die <strong>Windows</strong>-Firewall standardmäßig aktiviert, und in ihr sind<br />
über 170 eingehende und über 80 ausgehende Regeln aktiviert (Abbildung 6.17).<br />
<strong>Die</strong> meisten Firewallregeln betreffen <strong>Windows</strong>-<strong>Die</strong>nste. Sie schränken ein, welche Verbindungen<br />
sie erreichen und wo sie im Netzwerk erreicht werden können. Jede Regel kann verändert<br />
oder deaktiviert werden. Und natürlich können Administratoren neue Regeln definieren,<br />
um neue oder vorhandene <strong>Die</strong>nste zu schützen. Wie bei allen <strong>Windows</strong>-Firewallregeln<br />
können Sie auch erzwingen, dass IPsec mit Verschlüsselung und/oder Authentifizierung<br />
verwendet wird, bevor eine Verbindung hergestellt wird. Sie können Regeln auch mithilfe<br />
von Skripts definieren.<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bringen auch mehr als 80 vordefinierte ausgehende<br />
Regeln mit, die in der Standardeinstellung aktiviert sind. Sie können sich die Liste der<br />
Regeln unter HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\static<br />
ansehen (Abbildung 6.18).
176 Kapitel 6: <strong>Die</strong>nste<br />
Abbildung 6.17 Liste der <strong>Windows</strong>-Firewallregeln zum Schutz von <strong>Die</strong>nsten<br />
Abbildung 6.18 Statische Firewallregeln für <strong>Die</strong>nste<br />
<strong>Die</strong> Regeln werden in der normalen GUI nicht angezeigt, weil sie nicht geändert werden<br />
sollten. Falls Sie Regeln für eigene <strong>Die</strong>nste hinzufügen wollen, sollten Sie dafür COM-<br />
Skripting-Tools verwenden. In http://blogs.technet.com/voy/archive/2007/04/02/networkrestrictions-for-service-hardening.aspx<br />
finden Sie weitere Informationen und Beispielskripts.<br />
<strong>Die</strong> Regeln werden als statisch bezeichnet, weil sie unabhängig davon angewendet
<strong>Die</strong>nsthärtung 177<br />
werden, ob die Firewall aktiviert ist, und weil sie für alle drei Firewallprofile gelten. Sie<br />
können außerdem nur verwendet werden, um den Zugriff einzuschränken, nicht um ihn zu<br />
erlauben. Weil sich Microsoft darauf konzentriert, die Domänenisolierung auf <strong>Die</strong>nste auszuweiten,<br />
steigt die Widerstandsfähigkeit von <strong>Windows</strong> gegenüber Netzwerkangriffen.<br />
Etliche Angriffe, zum Beispiel der Blaster-Wurm, wären verhindert oder zumindest eingedämmt<br />
worden, wären diese Firewallregeln damals schon aktiv gewesen.<br />
Und falls Ihnen jemand erzählt, dass die <strong>Windows</strong>-Firewall standardmäßig keine ausgehenden<br />
Filter aktiviert hat, können Sie auf die Dutzenden von Regeln verweisen, die in der<br />
Standardeinstellung aktiv sind.<br />
Sitzung-0-Isolierung<br />
Am Anfang dieses Kapitels habe ich erwähnt, dass in <strong>Windows</strong> alle <strong>Die</strong>nste in Sitzung 0<br />
laufen. Alle Benutzermodusanwendungen und -programme laufen in einer anderen Sitzung.<br />
Das soll verhindern, dass Benutzer und die von ihnen ausgeführten Programme (unter denen<br />
Malware sein kann) ohne Weiteres Kerndienste manipulieren können. Etwa 86 Prozent aller<br />
<strong>Windows</strong>-Verwundbarkeiten, die in den letzten Jahren dokumentiert wurden, ergaben sich<br />
nur, weil Endbenutzer mit Social Engineering dazu gebracht wurden, Code auf dem Desktop<br />
auszuführen (http://www.infoworld.com/article/07/10/19/42OPsecadvise-insider-threats_1.<br />
html). Daher ist die Isolierung für <strong>Die</strong>nstsitzungen eine sehr wichtige Entwicklung.<br />
Der einzige potenzielle Nachteil der Sitzung-0-Isolierung besteht darin, dass alte <strong>Die</strong>nste<br />
manchmal erwarten, dass eine direkte Interaktion mit dem Endbenutzer möglich ist. Solche<br />
<strong>Die</strong>nste können keine Meldungen und Eingabeaufforderungen mehr anzeigen. Ohne irgendeine<br />
Übergangslösung würde ein alter <strong>Die</strong>nst seine Meldungen in Sitzung 0 anzeigen, wo<br />
der Endbenutzer sie nicht lesen kann. Microsoft stellt den <strong>Die</strong>nst Erkennung interaktiver<br />
<strong>Die</strong>nste (ui0detect) bereit, damit alte <strong>Die</strong>nste mit interaktiven Endbenutzern kommunizieren<br />
können. Wenn dieser <strong>Die</strong>nst gestartet wurde (er wird nicht automatisch gestartet), erkennt<br />
der <strong>Die</strong>nst, falls alte <strong>Die</strong>nste versuchen, mit dem Benutzer zu kommunizieren, und macht<br />
den angemeldeten interaktiven Benutzer darauf aufmerksam. Microsoft hat öffentlich erklärt,<br />
dass der Ui0detect-<strong>Die</strong>nst nur eine Übergangslösung ist, die in Zukunft nicht mehr zur<br />
Verfügung steht. Hersteller müssen ihre <strong>Die</strong>nste so anpassen, dass sie mit Benutzern in anderen<br />
Sitzungen über RPC, COM, Named Pipes oder andere Methoden kommunizieren.<br />
Weitere Informationen zur Sitzung-0-Isolierung finden Sie unter http://www.microsoft.com/<br />
whdc/system/vista/services.mspx.<br />
Verbindliche Integritätsebenen<br />
Alle <strong>Die</strong>nste haben in der Standardeinstellung die verbindliche Integritätsebene System. (In<br />
Kapitel 2 finden Sie weitere Informationen über Integritätsebenen.) Abbildung 6.19 zeigt die<br />
Integritätsebenen für mehrere <strong>Die</strong>nste. Nur die verbindliche Integritätsebene TrustedInstaller<br />
ist höher. Sie erlaubt <strong>Windows</strong> über den TrustedInstaller-<strong>Die</strong>nst, <strong>Die</strong>nste zu aktualisieren,<br />
installieren, entfernen und ersetzen, verringert aber gleichzeitig die Gefahr, dass andere<br />
Prozesse und Benutzer <strong>Die</strong>nste manipulieren können.
178 Kapitel 6: <strong>Die</strong>nste<br />
Abbildung 6.19 <strong>Die</strong>nstattribute im Process Explorer<br />
Datenausführungsverhinderung<br />
Wie Abbildung 6.19 außerdem zeigt, sind die meisten <strong>Die</strong>nste durch Datenausführungsverhinderung<br />
(Data Execution Prevention, DEP) und ASLR geschützt. DEP macht viele Pufferüberlaufangriffe<br />
unwirksam, indem es verhindert, dass in nicht ausführbaren Speicherbereichen<br />
Code ausgeführt wird. DEP und ASLR machen es bei einem Pufferüberlauf<br />
schwieriger, die tatsächlichen Funktionsadressen zu finden. Beide <strong>Sicherheit</strong>smechanismen<br />
verhindern bestimmte Arten von Angriffen, und sie konnten andere Angriffe abwehren, die<br />
auf älteren <strong>Windows</strong>-Plattformen noch erfolgreich waren. Keines der beiden kann aber alle<br />
Angriffe aufhalten. Entwickler, die <strong>Die</strong>nste erstellen, sollten sicherstellen, dass ihre <strong>Die</strong>nste<br />
DEP und ASLR nutzen.<br />
Andere neue SCM-Features<br />
Wenn ein Client vor <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> feststellen wollte, ob ein<br />
<strong>Die</strong>nst seinen Status geändert oder ob er erstellt oder gelöscht wurde, musste er die API-<br />
Funktion QueryServiceStatusEx aufrufen und den Status des <strong>Die</strong>nstes verfolgen. Es war sehr<br />
ineffizient, den Status ständig abfragen zu müssen, nur um eine Änderung feststellen zu<br />
können. <strong>Windows</strong> Vista führt eine neue API-Funktion ein, NotifyServiceStatusChange. Sie<br />
erlaubt es dem SCM, registrierte Clients zu benachrichtigen, sobald ein bestimmter <strong>Die</strong>nst<br />
seinen Status ändert. Das bedeutet, dass Anwendungen, die <strong>Die</strong>nste überwachen, jetzt Benachrichtigungen<br />
erhalten können, wenn sich der Status des <strong>Die</strong>nstes ändert. Das macht es<br />
deutlich einfacher, Verwaltungstools zu entwickeln.<br />
<strong>Die</strong>nste können sich auch registrieren, damit sie vor dem Herunterfahren benachrichtigt<br />
werden. So haben sie länger Zeit, sich auf das Herunterfahren des Systems vorzubereiten.<br />
Und beim Herunterfahren werden die Abhängigkeiten der <strong>Die</strong>nste beachtet, sodass sie (bei<br />
entsprechender Konfiguration) in einer sinnvolleren Reihenfolge beendet werden.
Schützen von <strong>Die</strong>nsten 179<br />
Der SCM kann jetzt unkritische Fehler besser erkennen und korrigieren. In älteren <strong>Windows</strong>-Versionen<br />
musste der <strong>Die</strong>nst vollständig abstürzen, bevor eine Wiederherstellungsaktion<br />
ausgelöst wurde. Jetzt können auch Speicherlecks, langsame Verarbeitung und andere<br />
Probleme eine Wiederherstellungsaktion auslösen.<br />
Microsoft hat viel Mühe darauf verwendet, die <strong>Windows</strong>-<strong>Die</strong>nste sicherer zu machen. Software,<br />
die so komplex ist wie <strong>Windows</strong>, wird niemals völlig frei von <strong>Sicherheit</strong>sbugs sein,<br />
aber <strong>Windows</strong> Vista hat bereits bewiesen, dass es gegen neu erkannten <strong>Sicherheit</strong>sverwundbarkeiten<br />
widerstandsfähiger ist. Lesen Sie das <strong>Sicherheit</strong>sblog des Microsoft-Mitarbeiters<br />
Jeff Jones (http://blogs.technet.com/security/archive/tags/Studies/default.aspx), wenn Sie<br />
sich für dieses Thema interessieren. Wir dürfen erwarten, dass sich <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
als ähnlich widerstandsfähig erweist.<br />
Schützen von <strong>Die</strong>nsten<br />
Microsoft weiß, dass die <strong>Sicherheit</strong>srisiken mit jedem laufenden <strong>Die</strong>nst steigen. Aus diesem<br />
Grund hat das Entwicklungsteam die <strong>Sicherheit</strong> aller integrierten <strong>Windows</strong>-<strong>Die</strong>nste analysiert<br />
und gegenüber älteren Versionen des Betriebssystems <strong>Windows</strong> verbessert. Als Administrator<br />
sollten Sie trotzdem Schritte einleiten, um die Gefahren noch weiter zu verringern.<br />
<strong>Die</strong> folgenden Abschnitte beschreiben, mit welchen Maßnahmen Administratoren die Gefahr<br />
einer böswilligen Kompromittierung mindern können. <strong>Die</strong>se Schritte sollten in <strong>Sicherheit</strong>srichtlinien<br />
und Richtlinien implementiert werden.<br />
Inventarisieren von <strong>Die</strong>nsten<br />
Um <strong>Die</strong>nste zu schützen, muss ein Administrator erst einmal herausfinden und dokumentieren,<br />
welche <strong>Die</strong>nste auf seinen Computern laufen. Ohne eine <strong>Die</strong>nstliste und die Erklärungen,<br />
was die einzelnen <strong>Die</strong>nste tun, ist es schwierig, nicht benötigte <strong>Die</strong>nste zu entfernen.<br />
Viele integrierte und Fremdherstellertools können Ihnen eine Liste der <strong>Die</strong>nste für jeden<br />
Computer generieren. Am einfachsten können Sie einen einzelnen Computer abfragen, indem<br />
Sie das <strong>Die</strong>nststeuerungstool Sc.exe verwenden. Damit können Sie lokal und im Remotezugriff<br />
<strong>Die</strong>nste abfragen und eine Reihe von Daten über die einzelnen <strong>Die</strong>nste auflisten.<br />
Außerdem kann der Administrator mit diesem Tool <strong>Die</strong>nstinformationen ändern (Privilegien,<br />
Status, Starttyp und so weiter). WMI (<strong>Windows</strong> Management Instrumentation) und<br />
WMIC (<strong>Windows</strong> Management Instrumentation Command-line) erlauben es, <strong>Die</strong>nste abzufragen<br />
und mit Skripts zu steuern. Zum Beispiel können Sie <strong>Die</strong>nstinformationen für einen<br />
<strong>Server</strong> namens <strong>Server</strong>1 abrufen, indem Sie an einer Eingabeaufforderung den folgenden<br />
Befehl eingeben:<br />
wmic /output:c:\services.htm /node:server1 service list full / format:htable<br />
Sehen Sie sich die generierte Datei C:\Services.htm im Microsoft Internet Explorer an. Andere<br />
Tools, zum Beispiel Microsoft Systems Management <strong>Server</strong> (SMS) oder System Center<br />
Configuration Manager (http://www.microsoft.com/smserver/default.mspx), eignen sich hervorragend,<br />
um detaillierte und zusammenfassende Listen von <strong>Die</strong>nsten zu erstellen. <strong>Die</strong>nste<br />
sollten in regelmäßigen Abständen inventarisiert werden, je nachdem, was die <strong>Sicherheit</strong>srichtlinien<br />
der Organisation vorschreiben. Falls Sie nicht alle Computersysteme inventarisieren<br />
können, sollten Sie mit den am stärksten gefährdeten und wertvollsten Systemen beginnen<br />
und von dort zu den Systemen weitergehen, die damit verbunden sind.
180 Kapitel 6: <strong>Die</strong>nste<br />
Abschalten möglichst vieler <strong>Die</strong>nste<br />
Im nächsten Schritt entscheiden Sie, welche <strong>Die</strong>nste tatsächlich gebraucht werden, und entfernen<br />
oder deaktivieren die übrigen. Das ist die größte Einzelmaßnahme, die Sie durchführen<br />
können, um die Gefahr durch Kompromittierung von <strong>Die</strong>nsten zu verringern. Mit jedem<br />
deaktivierten und entfernten <strong>Die</strong>nst verkleinern Sie die Angriffsfläche. Kapitel 12, »Schützen<br />
von <strong>Server</strong>rollen«, behandelt im Detail, wie Sie <strong>Die</strong>nste mithilfe von <strong>Server</strong>rollen und<br />
dem <strong>Sicherheit</strong>skonfigurations-Assistenten (Security Configuration Wizard, SCW) konfigurieren.<br />
Im Allgemeinen sollten Sie sehr vorsichtig sein, wenn Sie <strong>Windows</strong>-Standarddienste außerhalb<br />
von <strong>Server</strong>s-Manager oder SCW deaktivieren oder ändern. In den meisten Fällen hat<br />
Microsoft ermittelt, welche <strong>Die</strong>nste in den meisten Umgebungen für bestimmte Rollen<br />
wahrscheinlich benötigt werden, und sie so konfiguriert, dass sie entsprechend gestartet<br />
werden oder eben nicht. Was aktiviert ist, wurde mit den hier vorgestellten Mechanismen<br />
relativ gut geschützt. Wonach Sie Ausschau halten sollten, sind <strong>Die</strong>nste, die offensichtlich<br />
nicht gebraucht werden oder die entgegen der Unternehmensrichtlinie verwendet werden.<br />
Ein häufiges Beispiel für den ersten Fall ist der DHCP-Client. Er ist auf vielen <strong>Server</strong>n<br />
standardmäßig aktiviert, obwohl der <strong>Server</strong> eine statische Adresse hat. Ein Beispiel für den<br />
zweiten Fall kann ein unautorisiertes Peer-to-Peer-Filesharingprogramm sein. Selten kann<br />
sich ein Administrator darüber freuen, dass er bei einer Analyse seiner Umgebung keine<br />
oder zumindest nur wenige unautorisierte und potenziell gefährliche <strong>Die</strong>nste findet.<br />
Falls Sie feststellen wollen, ob ein <strong>Windows</strong>-Standarddienst gebraucht wird, können Sie<br />
einen der vielen Leitfäden zu <strong>Windows</strong>-<strong>Die</strong>nsten zurate ziehen, die Microsoft zur Verfügung<br />
stellt. <strong>Die</strong> folgenden Links enthalten Beschreibungen verschiedener <strong>Windows</strong>-<strong>Die</strong>nste und<br />
liefern allgemeine Empfehlungen für <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>:<br />
http://www.microsoft.com/whdc/system/vista/Vista_Services.mspx<br />
http://www.microsoft.com/downloads/details.aspx?FamilyID=a3d1bbed-7f35-4e72bfb5-b84a526c1565&displaylang=en<br />
http://www.microsoft.com/downloads/details.aspx?FamilyID=fb8b981f-227c-4af6a44bb115696a80ac&DisplayLang=en<br />
<strong>Die</strong>nste, die nicht gebraucht werden, sollten deaktiviert oder deinstalliert werden. Eine<br />
Deinstallation ist sicherer, aber wenn Sie einen <strong>Die</strong>nst erst einmal deaktivieren, können Sie<br />
ihn schnell wieder aktivieren, falls er in Zukunft doch noch gebraucht wird oder aufgrund<br />
eines Fehlers deaktiviert wurde. Der SCW erlaubt Ihnen, die Angriffsfläche auf sichere Weise<br />
zu verringern, weil Sie Ihre Änderungen problemlos rückgängig machen können. Weitere<br />
Informationen finden Sie in Kapitel 12.<br />
Hinweis Bevor Sie einen aktiven <strong>Die</strong>nst deaktivieren oder entfernen, sollten Sie genau untersuchen,<br />
wofür er verwendet wird und welche Abhängigkeiten unter Umständen gestört werden, wenn Sie ihn entfernen.<br />
Führen Sie immer eine Datensicherung des Systems (oder zumindest des Systemzustands) durch,<br />
bevor Sie <strong>Die</strong>nste entfernen oder deaktivieren.<br />
Zuweisen geringstmöglicher Privilegien an die übrigen <strong>Die</strong>nste<br />
Microsoft wendet bereits das <strong>Sicherheit</strong>smodell der geringstmöglichen Privilegien auf alle<br />
seine <strong>Die</strong>nste an. Daher betrifft die Aufforderung, das <strong>Sicherheit</strong>smodell der geringstmöglichen<br />
Privilegien zu implementieren, in erster Linie <strong>Die</strong>nste von Fremdherstellern und
Schützen von <strong>Die</strong>nsten 181<br />
selbst entwickelte <strong>Die</strong>nste. Leider lassen sich viele Softwarehersteller viel Zeit damit, eine<br />
Gefahrenmodellierung zu entwickeln und das <strong>Sicherheit</strong>sprinzip der geringstmöglichen<br />
Privilegien anzuwenden, insbesondere bei <strong>Die</strong>nsten.<br />
Wenn Sie einen neuen <strong>Die</strong>nst installieren und sich im Unklaren sind, wie sicher er ist, sollten<br />
Sie sich an den Hersteller wenden. Listen Sie mit dem Befehl sc die SID des <strong>Die</strong>nstes,<br />
SID-Typ, Anmeldekonto und benötigte Privilegien auf. Falls die Privilegien und Berechtigungen<br />
übertrieben scheinen für den Funktionsumfang, den der <strong>Die</strong>nst anbietet, kann es<br />
sinnvoll sein, Kontakt mit dem Hersteller aufzunehmen und um Unterstützung beim Entfernen<br />
von Privilegien zu bitten. Falls der Hersteller und/oder <strong>Die</strong>nst sich diesen Wünschen<br />
verweigert, sollten Sie in Erwägung ziehen, den <strong>Die</strong>nst zu entfernen und nicht zu verwenden.<br />
Nichts treibt einen Hersteller so an wie ausbleibende Kunden.<br />
Halten Sie Ihre Updates auf dem neuesten Stand<br />
Microsoft aktualisiert seine Software regelmäßig, indem es Bugfixes, <strong>Sicherheit</strong>supdates,<br />
neue Features und Leistungsoptimierungen zur Verfügung stellt. Falls ein kritischer Fehler<br />
in einem <strong>Die</strong>nst gefunden wird, der viele Kunden Gefahren aussetzt, bemüht sich Microsoft,<br />
die Verwundbarkeit schnell mit einem <strong>Sicherheit</strong>supdate und/oder anderen Empfehlungen zu<br />
beheben. Indem Sie Ihr System auf dem neuesten Stand halten, können Sie <strong>Sicherheit</strong>sgefahren<br />
stark verringern. <strong>Die</strong> beiden größten <strong>Windows</strong>-Malwarevorfälle in letzter Zeit (SQL<br />
Slammer und Blaster) funktionierten nur auf Computern, bei denen die verfügbaren <strong>Sicherheit</strong>supdates<br />
nicht eingespielt waren.<br />
Erstellen und Verwenden benutzerdefinierter <strong>Die</strong>nstkonten<br />
Microsoft empfiehlt, nach Möglichkeit die integrierten <strong>Die</strong>nstkonten (SYSTEM, LOKALER<br />
DIENST und NETZWERKDIENST) zu verwenden. Gelegentlich ist es allerdings sinnvoller,<br />
ein benutzerdefiniertes <strong>Die</strong>nstanmeldekonto anzulegen und zu verwenden.<br />
Verwenden starker Kennwörter und Ändern der Kennwörter in vernünftigen<br />
Abständen<br />
Benutzerdefinierte <strong>Die</strong>nstanmeldekonten sollten durch eine strenge Kennwortrichtlinie geschützt<br />
werden (das heißt durch starke Kennwörter, die öfter geändert werden). Benutzerdefinierte<br />
<strong>Die</strong>nstkonten speichern ihre Kennwörter in zwei Bereichen: erstens in Active<br />
Directory oder der lokalen SAM-Datenbank und zweitens auf dem lokalen System an einer<br />
Stelle, wo der SCM die Kennwörter abrufen kann. Wenn Sie die Kennwörter Ihres <strong>Die</strong>nstanmeldekontos<br />
ändern, müssen Sie die Änderung an beiden Stellen vornehmen, sonst laufen<br />
Sie Gefahr, dass Ihr <strong>Die</strong>nst nicht startet. Lassen Sie sich von dem Aufwand, Kennwörter von<br />
<strong>Die</strong>nstkonten an zwei Stellen zu ändern, nicht davon abbringen, diese Änderungen in regelmäßigen<br />
Abständen durchzuführen. Im Internet stehen mehrere Skripts zur Verfügung,<br />
die diese Aufgabe leichter machen, zum Beispiel eines im Microsoft Developer Network:<br />
http://msdn2.microsoft.com/en-us/library/ms675577.aspx. Sie können auch das Tool Passgen<br />
von der Begleit-CD verwenden, das Ihnen hilft, starke Kennwörter für lokale und Remotedienstkonten<br />
festzulegen.<br />
Hinweis Verwenden Sie Kennwortprüftools, um <strong>Die</strong>nstanmeldekonten auf schwache Kennwörter<br />
zu überwachen.
182 Kapitel 6: <strong>Die</strong>nste<br />
Verwenden der eingeschränkten Gruppen in Gruppenrichtlinien<br />
Falls benutzerdefinierte <strong>Die</strong>nstanmeldekonten mit kritischen Privilegien verwendet werden,<br />
sollten Sie die eingeschränkten Gruppen in den Gruppenrichtlinien einsetzen, um die Zuweisung<br />
von Berechtigungen zu erleichtern und zu verhindern, dass andere Konten versehentlich<br />
diese Berechtigungen erhalten. Wenn eine Gruppe und ihre Mitglieder in den eingeschränkten<br />
Gruppen definiert sind (Computerkonfiguration\<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\Eingeschränkte<br />
Gruppen), werden Änderungen an der Mitgliedschaft der<br />
Gruppe, die außerhalb des Features Eingeschränkte Gruppen vorgenommen werden, von<br />
den Gruppenrichtlinien rückgängig gemacht. <strong>Die</strong> Berechtigungen und Privilegien, die benutzerdefinierte<br />
Anmeldekonten brauchen, können der Gruppe zugewiesen werden, und<br />
danach wird die Mitgliedschaft der Gruppe mithilfe von Eingeschränkte Gruppen erzwungen.<br />
Domänenadministratorkonten nach Möglichkeit nicht verwenden<br />
Verwenden Sie auf Computern, die keine Domänencontroller sind, niemals benutzerdefinierte<br />
<strong>Die</strong>nstanmeldekonten, die zur Gruppe Domänen-Admins (oder Gruppen mit ähnlich hohen<br />
Privilegien) gehören. Falls ein <strong>Die</strong>nst, der ein <strong>Die</strong>nstanmeldekonto mit Privilegien von<br />
Domänen-Admins verwendet, kompromittiert wird, ist praktisch die ganze Gesamtstruktur<br />
kompromittiert. Probieren Sie irgendeinen anderen Kontotyp, zum Beispiel SYSTEM, und<br />
testen Sie, ob der <strong>Die</strong>nst damit funktioniert. Alle Computer, die <strong>Die</strong>nstkonten mit hohen<br />
Privilegien verwenden, sollten als hohes Risiko eingestuft werden und denselben <strong>Sicherheit</strong>seinschränkungen<br />
und Richtlinien unterliegen wie Domänencontroller.<br />
Verwenden von SYSTEM<br />
Viele Leitfäden empfehlen, <strong>Die</strong>nstkonten, die SYSTEM-Zugriff benötigten, auf benutzerdefinierte<br />
<strong>Die</strong>nstkonten mit weniger Privilegien umzustellen, falls der <strong>Die</strong>nst unter einem solchen<br />
Konto ebenfalls funktioniert. Aber viele Administratoren schließen daraus, dass sie um<br />
jeden Preis vermeiden sollten, <strong>Die</strong>nste unter SYSTEM auszuführen. <strong>Die</strong>se Administratoren<br />
haben keinerlei Bedenken, ein benutzerdefiniertes <strong>Die</strong>nstkonto zu einem Domänen- oder<br />
lokalen Administrator zu machen, und ignorieren dabei die Schutzmechanismen, die das<br />
Konto SYSTEM bietet. Es gibt bei SYSTEM kein Kennwort, das ein Angreifer ausspähen<br />
könnte. Falls ein Angreifer einen <strong>Die</strong>nst, der im SYSTEM-Kontext läuft, kompromittiert, hat<br />
er möglicherweise den lokalen Computer übernommen, aber zumindest ist nicht automatisch<br />
Ihre Domäne oder Gesamtstruktur kompromittiert. Das wäre der Fall, wenn der Angreifer<br />
das Konto eines Domänenadministrators übernimmt.<br />
Empfehlungen für <strong>Die</strong>nste besagen, dass Sie ein <strong>Die</strong>nstanmeldekonto mit möglichst wenigen<br />
Privilegien verwenden sollten. Beginnen Sie mit LOKALER DIENST oder NETZ-<br />
WERKDIENST, falls sie Ihre Anforderungen erfüllen. Falls Sie keinen Administrator- oder<br />
SYSTEM-Zugriff brauchen, können Sie ein benutzerdefiniertes <strong>Die</strong>nstkonto anlegen, das<br />
lediglich den Zugriff bietet, den Sie unbedingt benötigen. Falls ein Softwarehersteller behauptet,<br />
Sie müssten seinen <strong>Die</strong>nst auf Nicht-Domänencontrollern im Kontext eines Domänenadministrators<br />
ausführen, sollten Sie versuchen, ein benutzerdefiniertes <strong>Die</strong>nstkonto mit<br />
Vollzugriff auf die Ressourcen zu verwenden, die der <strong>Die</strong>nst benötigt. Oder noch besser:<br />
Geben Sie das Produkt zurück und verlangen Sie Ihr Geld zurück. Wenn irgendein <strong>Die</strong>nstkonto<br />
Vollzugriffberechtigungen für kritische Datei- und Registrierungsressourcen bekommt,<br />
ist das immer noch besser, als das <strong>Die</strong>nstanmeldekonto zur Gruppe Domänen-<br />
Admins hinzuzufügen. Wenn der <strong>Die</strong>nst Vollzugriffberechtigungen auf die meisten Dateien
Zusammenfassung 183<br />
und Ordner besitzt, aber nicht zu einer Administratorengruppe gehört, ist er zumindest nicht<br />
in der Lage, Benutzer hinzuzufügen und zu entfernen, Benutzerkennwörter zu ändern und<br />
unzählige andere Aufgaben eines Administrators durchzuführen. Den Vollzugriff auf ein<br />
System zu gewähren, ist etwas anderes, als Administratorzugriff zu gewähren. Und falls ein<br />
<strong>Die</strong>nstkonto Administratorzugriff auf ein System benötigt, sollten Sie versuchen, ihm stattdessen<br />
SYSTEM-Zugriff zu geben. SYSTEM ist ein lokaler Administrator, und Sie brauchen<br />
nicht regelmäßig Kennwörter zu ändern (ohne die Gefahr für erfolgreiche Angriffe zu vergrößern).<br />
Implementieren der Netzwerkisolierung mit <strong>Windows</strong>-Firewall und IPsec<br />
Sie können Ihre <strong>Die</strong>nste mithilfe von <strong>Windows</strong>-Firewall und IPsec in den <strong>Sicherheit</strong>sdomänen<br />
isolieren, die sie brauchen. Viele <strong>Die</strong>nste benötigen keinen Zugriff aus dem lokalen<br />
Netzwerk, manche müssen auch keine eingehenden Verbindungen aus dem Internet annehmen.<br />
Daher sollten Sie diese Möglichkeiten einschränken.<br />
Überwachen von <strong>Die</strong>nstfehlern<br />
Weil <strong>Die</strong>nste jetzt individuelle SIDs haben, ist es einfacher, <strong>Die</strong>nstfehler zu überwachen und<br />
festzustellen, ob ein <strong>Die</strong>nst keinen Zugriff auf eine benötigte Ressource erhält. Sie können<br />
ein übliches Programm oder Skript verwenden, das auf <strong>Die</strong>nstfehler reagiert und den IT-<br />
Support benachrichtigt. <strong>Die</strong> häufigsten <strong>Die</strong>nstfehler werden durch Probleme im normalen<br />
Betrieb oder aufgrund langer Laufzeit verursacht, aber in der Vergangenheit hat sich gezeigt,<br />
dass eine Epidemie von <strong>Die</strong>nstfehlern ein Frühwarnsignal für neu aufgetauchte Bedrohungen<br />
sein kann.<br />
Entwickeln und verwenden Sie sichere <strong>Die</strong>nste<br />
Falls Ihre Organisation <strong>Windows</strong>-<strong>Die</strong>nste entwickelt, sollten Sie die von Microsoft bereitgestellten<br />
Tools und Mechanismen nutzen, um sichere <strong>Die</strong>nste zu schreiben. Falls Sie <strong>Die</strong>nste<br />
lediglich nutzen, sollten Sie sich weigern, unsichere <strong>Die</strong>nste einzusetzen. Fordern Sie die<br />
Hersteller auf, die grundlegenden <strong>Sicherheit</strong>sempfehlungen zu befolgen, die in diesem Kapitel<br />
beschrieben wurden. Sicherere <strong>Die</strong>nste helfen den Computer zu schützen, auf dem sie<br />
installiert sind, und schützen somit auch die anderen Computer im Netzwerk.<br />
Zusammenfassung<br />
<strong>Die</strong>nste, die unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> (und <strong>Windows</strong> Vista) laufen, wurden gegenüber<br />
älteren <strong>Windows</strong>-Versionen deutlich verbessert. <strong>Die</strong>nste laufen jetzt in Modi mit geringstmöglichen<br />
Privilegien, mit dienstspezifischen SIDs, isoliert in Sitzung 0, mit eingeschränktem<br />
Netzwerkzugriff und geschützt durch DEP und ASLR. Administratoren können die<br />
Gefahren durch kompromittierte <strong>Die</strong>nste minimieren, indem sie nicht benötigte <strong>Die</strong>nste aus<br />
ihrer Umgebung entfernen und für die selbst entwickelten oder gekauften <strong>Die</strong>nste dem Prinzip<br />
der geringstmöglichen Privilegien folgen. <strong>Windows</strong> wird zwar immer ein Ziel für böswillige<br />
Hacker sein, aber <strong>Die</strong>nste, die mit geringstmöglichen Privilegien laufen, machen es<br />
ihnen schwerer, einen Ansatzpunkt zu finden.
184 Kapitel 6: <strong>Die</strong>nste<br />
Weitere Informationen<br />
Microsoft Corporation (2004): »Services in <strong>Windows</strong> Vista« unter http://www.microsoft.<br />
com/whdc/system/vista/Vista_Services.mspx.<br />
Microsoft Corporation (2007): »<strong>Windows</strong> Vista Security Guide« unter http://www.<br />
microsoft.com/downloads/details.aspx?FamilyID=a3d1bbed-7f35-4e72-bfb5b84a526c1565&displaylang=en.<br />
Microsoft Corporation (2007): »<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Security Guide« unter<br />
http://www.microsoft.com/downloads/details.aspx?FamilyID=fb8b981f-227c-4af6-a44bb115696a80ac&DisplayLang=en.
K A P I T E L 7<br />
Gruppenrichtlinien<br />
Von Darren Mar-Elia<br />
In diesem Kapitel:<br />
Was ist neu in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>? ..................................... 185<br />
Grundlagen von Gruppenrichtlinien ....................................... 186<br />
Was ist neu bei Gruppenrichtlinien? ....................................... 197<br />
Verwalten von <strong>Sicherheit</strong>seinstellungen .................................... 211<br />
Zusammenfassung .................................................. 214<br />
Weitere Informationen ................................................ 215<br />
<strong>Die</strong> Technologie der Gruppenrichtlinien gibt es seit dem Erscheinen von <strong>Windows</strong> 2000. Es<br />
ist die Multifunktions-Konfigurationstechnologie innerhalb von <strong>Windows</strong>-<strong>Server</strong>- und -Desktopbetriebssystemen.<br />
<strong>Die</strong> Technologie wurde mit dem Ziel entworfen, dass Sie zentral Tausende<br />
von Optionen konfigurieren können, die auf einige oder alle Ihre <strong>Windows</strong>-Systeme<br />
in unterschiedlichen Netzwerken und Standorten angewendet werden. Für das Thema dieses<br />
Buchs ist in erster Linie wichtig, dass Gruppenrichtlinien der wichtigste Mechanismus zum<br />
Bereitstellen von <strong>Sicherheit</strong>skonfigurationseinstellungen auf allen Ihren Systemen sind. Auf<br />
jeden Fall müssen Sie Gruppenrichtlinien verwenden, um die Kennwortrichtlinie innerhalb<br />
Ihrer Active Directory-Domänen zu konfigurieren. Aber Gruppenrichtlinien können viel<br />
mehr, als nur die Kennwortrichtlinie festzulegen. In diesem Kapitel zeige ich Ihnen, wie<br />
Gruppenrichtlinien funktionieren und welche Konfigurationsfähigkeiten im Bereich <strong>Sicherheit</strong><br />
unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zur Verfügung stehen.<br />
Was ist neu in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>?<br />
Bevor ich beschreibe, wie Gruppenrichtlinien funktionieren und wie Sie damit Konfigurationen<br />
in Ihrer gesamten Umgebung verwalten können, will ich einige der wichtigsten<br />
Änderungen vorstellen, die seit <strong>Windows</strong> XP und <strong>Windows</strong> <strong>Server</strong> 2003 an den Gruppenrichtlinien<br />
vorgenommen wurden. Viele der Änderungen an Gruppenrichtlinien tauchten<br />
zuerst in <strong>Windows</strong> Vista auf, und diese Änderungen wurden in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> beibehalten.<br />
Aber <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bringt auch selbst einige Neuerungen mit (in erster<br />
Linie im Bereich der Konsole Gruppenrichtlinienverwaltung), die die Verwaltung der Gruppenrichtlinien<br />
erleichtern. Folgende wichtige Änderungen wurden in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
und <strong>Windows</strong> Vista vorgenommen:<br />
Unterstützung für neue Richtlinienbereiche, darunter neue <strong>Sicherheit</strong>srichtlinien für<br />
Kabel- und Drahtlosnetzwerke, verbesserte Schnittstellen für <strong>Windows</strong>-Firewall- und<br />
IPsec-Richtlinienkonfiguration, Unterstützung für die Energieverwaltungskonfiguration<br />
und Richtlinien für die Einschränkung von USB-Geräten.<br />
185
186 Kapitel 7: Gruppenrichtlinien<br />
Verbesserte Erkennung langsamer Verbindungen zwischen Client und Domänencontrollern.<br />
So wird zuverlässiger erkannt, wenn der Client über eine langsame Verbindung angebunden<br />
ist, was die Verarbeitung der Gruppenrichtlinien beeinflussen kann.<br />
Gruppenrichtlinien werden aktualisiert, wenn sie auf den Domänencontrollern verfügbar<br />
sind, nicht nach festgelegten Intervallen. Wenn ein Client eine Verbindung zum Unternehmensnetzwerk<br />
wiederherstellt oder über eine VPN-Verbindung Kontakt aufnimmt,<br />
werden die Gruppenrichtlinien schneller aktualisiert.<br />
Unterstützung für mehrere lokale Gruppenrichtlinienobjekte (Local Group Policy Object,<br />
LGPO), sodass lokale Gruppenrichtlinien benutzerspezifisch oder für Administratoren<br />
beziehungsweise Standardbenutzer angewendet werden können.<br />
Unterstützung für das neue XML-basierte ADMX-Format für administrative Vorlagendateien,<br />
das die Unterstützung mehrsprachiger administrativer Vorlagen verbessert.<br />
Unterstützung für gruppenrichtlinienobjekt- und gruppenrichtlinienspezifische Einstellungskommentare.<br />
Verbesserungen an den Konsolen Gruppenrichtlinienverwaltung und Gruppenrichtlinien-Editor<br />
in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, die neue Fähigkeiten bieten, zum Beispiel die<br />
Filterung von Richtlinien anhand von Schlüsselwörtern, und die Möglichkeit, »Starter-<br />
Gruppenrichtlinienobjekte« für die Richtlinien in Administrative Vorlagen zu erstellen.<br />
Das Feature der Gruppenrichtlinieneinstellungen (Group Policy Preferences). Es umfasst<br />
neue Richtlinieneinstellungen, die vorher Teil der DesktopStandard-PolicyMaker-Technologie<br />
waren, die von Microsoft aufgekauft wurde.<br />
Aber bevor ich diese neuen Gruppenrichtlinienfeatures und -fähigkeiten im Detail beschreibe,<br />
sollten wir uns erst einmal mit den Grundlagen beschäftigen: Wie funktionieren Gruppenrichtlinien,<br />
was tun sie und wie können sie Ihnen helfen, Ihre <strong>Windows</strong>-Infrastruktur zu<br />
schützen?<br />
Grundlagen von Gruppenrichtlinien<br />
Als Erstes müssen Sie über Gruppenrichtlinien wissen, dass Sie eine Active Directory-Infrastruktur<br />
bereitstellen müssen, um alle ihre Fähigkeiten nutzen zu können. Indem Sie Active<br />
Directory verwenden, können Sie mit Gruppenrichtlinien erweiterte Features nutzen, die in<br />
Arbeitsgruppen nicht zur Verfügung stehen. Allerdings bringt jeder Computer, der unter<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, <strong>Windows</strong> Vista oder einer <strong>Windows</strong>-Version bis zurück zu <strong>Windows</strong><br />
2000 läuft, ein lokales Gruppenrichtlinienobjekt (Group Policy Object, GPO) mit, über das<br />
Sie bestimmte Konfigurationseinstellungen innerhalb einer Arbeitsgruppenumgebung verwalten<br />
können.<br />
Das lokale Gruppenrichtlinienobjekt<br />
Das lokale GPO (Local Group Policy Object, LGPO) können Sie öffnen, indem Sie im<br />
Startmenü auf Ausführen klicken und dann gpedit.msc im Dialogfeld Ausführen eingeben.<br />
Daraufhin wird die Konsole Lokaler Gruppenrichtlinien-Editor geöffnet (Abbildung 7.1).
Grundlagen von Gruppenrichtlinien 187<br />
Abbildung 7.1 Anzeigen des lokalen Gruppenrichtlinienobjekts mit der Microsoft Management<br />
Console in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Hinweis Wenn im Startmenü Ihres <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Systems die Programmgruppe Verwaltung<br />
aktiviert ist, finden Sie dort den Eintrag Lokale <strong>Sicherheit</strong>srichtlinie. Wenn Sie dieses Tool starten, öffnet<br />
sich das MMC-Snap-In Gruppenrichtlinien-Editor, in das der Zweig <strong>Sicherheit</strong> des lokalen Gruppenrichtlinienobjekts<br />
geladen ist, also die <strong>Sicherheit</strong>seinstellungen unter Computerkonfiguration\<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen.<br />
<strong>Die</strong>ses Tool bietet eine bequeme Möglichkeit, wenn Sie nur die <strong>Sicherheit</strong>soptionen<br />
innerhalb des lokalen Gruppenrichtlinienobjekts anzeigen und bearbeiten wollen. Aber vergessen<br />
Sie nicht, dass diese Einstellungen nur das lokale Gruppenrichtlinienobjekt betreffen.<br />
Das lokale Gruppenrichtlinienobjekt auf einem <strong>Windows</strong>-System wird auf alle Benutzer<br />
angewendet, die sich an diesem System anmelden. Systeme vor <strong>Windows</strong> Vista boten keine<br />
Möglichkeit zu steuern, auf welche Benutzer, die sich beim lokalen System anmeldeten, die<br />
Richtlinien aus dem lokalen GPO angewendet wurden. Alle Benutzer bekamen dieselben<br />
Einstellungen. In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> gibt es nun aber die Möglichkeit,<br />
mehrere benutzerspezifische lokale GPOs zu erstellen. Das ist nützlich, wenn Sie nicht<br />
Active Directory verwenden, aber die Auswirkungen des lokalen GPOs davon abhängig<br />
machen wollen, wer sich am System anmeldet. Auf den Einsatz mehrerer lokaler GPOs<br />
komme ich gleich noch zurück.<br />
Active Directory-Gruppenrichtlinienobjekte<br />
Sie haben nur eingeschränkte Steuerungsmöglichkeiten, wenn Sie lokale GPOs verwenden.<br />
Aber sobald Sie Active Directory bereitgestellt haben, steht Ihnen die volle Leistungsfähigkeit<br />
der Gruppenrichtlinien zur Verfügung. Trotz des Worts »Gruppe« in Gruppenrichtlinien<br />
werden GPOs nur auf Benutzer- und Computerobjekte innerhalb Ihrer Active Directory-<br />
Umgebung angewendet. Gruppenrichtlinienobjekte sind mit Containern innerhalb von Active<br />
Directory verknüpft. Über diese Verknüpfung können Sie steuern, welche Benutzer und<br />
Computer ein bestimmtes GPO verarbeiten (Abbildung 7.2).<br />
Sie können GPOs mit Active Directory-Standorten (einer Sammlung von IP-Subnetzen),<br />
Domänen und Organisationseinheiten (Organizational Unit, OU) verknüpfen. Sie können<br />
sogar mehrere GPOs mit jeder dieser Containerebenen verknüpfen, sodass unter Umständen<br />
Hunderte von GPOs auf einen bestimmten Benutzer oder Computer angewendet werden.
188 Kapitel 7: Gruppenrichtlinien<br />
Abbildung 7.2 Sie können GPOs mit mehreren Containerebenen innerhalb von Active Directory<br />
verknüpfen<br />
<strong>Die</strong> Benutzer und Computer, die diese für sie gültigen GPOs verarbeiten, gehen dabei in<br />
folgender Reihenfolge vor:<br />
1. Lokale GPOs<br />
2. Mit dem Standort verknüpfte GPOs<br />
3. Mit der Domäne verknüpfte GPOs<br />
4. Mit der Organisationseinheit verknüpfte GPOs<br />
<strong>Die</strong>se Reihenfolge bedeutet: Falls es bei den Einstellungen innerhalb der GPOs, die (zum<br />
Beispiel) mit einem Standort und einer Organisationseinheit verknüpft sind, Konflikte gibt,<br />
werden normalerweise die Einstellungen für die Organisationseinheit auf den Benutzer oder<br />
Computer angewendet. <strong>Die</strong> Gruppenrichtlinien werden nämlich nach dem Prinzip verarbeitet,<br />
dass die zuletzt verarbeitete Einstellung Vorrang hat. So ist garantiert, dass GPOs, die in<br />
der Active Directory-Hierarchie näher beim Benutzer oder Computer definiert sind, angewendet<br />
werden.
Grundlagen von Gruppenrichtlinien 189<br />
<strong>Sicherheit</strong>sfilterung für GPOs<br />
Damit Sie die Auswirkungen von Gruppenrichtlinien flexibler steuern können, bietet Ihnen<br />
<strong>Windows</strong> die Möglichkeit, die Auswirkungen eines GPOs anhand von <strong>Sicherheit</strong>sgruppen<br />
zu filtern. So können Sie genauer einstellen, wo ein GPO gültig wird, als wenn es einfach<br />
auf alle Benutzer und Computer in der Domäne oder Organisationseinheit angewendet wird.<br />
<strong>Sicherheit</strong>sgruppenfilterung ist relativ einfach zu benutzen, wenn Sie die Konsole Gruppenrichtlinienverwaltung<br />
auf Ihrem <strong>Windows</strong> Vista- oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-System installiert<br />
haben.<br />
Tipp <strong>Die</strong> Konsole Gruppenrichtlinienverwaltung wird in <strong>Windows</strong> Vista standardmäßig installiert, aber<br />
nicht in <strong>Windows</strong> Vista mit Service Pack 1. Sie können die Konsole Gruppenrichtlinienverwaltung auf <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> installieren, indem Sie den <strong>Server</strong>-Manager starten und im Abschnitt Features das<br />
Feature Gruppenrichtlinienverwaltung hinzufügen. Wenn Sie in <strong>Windows</strong> Vista mit Service Pack 1 Zugriff<br />
auf die Konsole Gruppenrichtlinienverwaltung erhalten wollen, müssen Sie das Paket der Remoteserver-<br />
Verwaltungstools (Remote <strong>Server</strong> Administration Tools, RSAT) auf diesem Vista-System installieren.<br />
RSAT enthält die Konsole Gruppenrichtlinienverwaltung und weitere Active Directory-Verwaltungstools.<br />
<strong>Sicherheit</strong>sfilter werden im GPO selbst eingestellt. Sie können in der Konsole Gruppenrichtlinienverwaltung<br />
ändern, welche Gruppen ein bestimmtes GPO verarbeiten. In der Standardeinstellung<br />
enthält ein neu erstelltes GPO im <strong>Sicherheit</strong>sfilter die Berechtigungen Lesen und<br />
Gruppenrichtlinie übernehmen für die Gruppe Authentifizierte Benutzer. Trotz des Namens<br />
umfasst diese Gruppe alle Benutzer- und Computerkonten in der Domäne. Das bedeutet, dass<br />
normalerweise alle Benutzer oder Computer dieses GPO verarbeiten, wenn es mit einem<br />
Container verknüpft wird, bei dem sie Mitglied sind. Damit eine Gruppe ein GPO verarbeiten<br />
kann, muss es diese beiden Berechtigungen haben, Lesen und Gruppenrichtlinie übernehmen.<br />
Eine Berechtigung allein reicht nicht aus. Glücklicherweise brauchen Sie sich nicht<br />
weiter darum zu kümmern, wie Sie einzelne Berechtigungen vergeben, wenn Sie die <strong>Sicherheit</strong>sfilterung<br />
in der Konsole Gruppenrichtlinienverwaltung verwalten. Im nächsten Abschnitt<br />
gehen wir ein Beispiel schrittweise durch.<br />
Ändern der GPO-<strong>Sicherheit</strong>sfilterung in der Konsole Gruppenrichtlinienverwaltung<br />
1. Starten Sie die Konsole Gruppenrichtlinienverwaltung unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>,<br />
indem Sie im Startmenü auf Verwaltung und dann auf Gruppenrichtlinienverwaltung<br />
klicken.<br />
2. Falls Sie Ihre Active Directory-Gesamtstruktur noch nicht zur Konsole Gruppenrichtlinienverwaltung<br />
hinzugefügt haben, können Sie das jetzt tun, indem Sie mit der rechten<br />
Maustaste auf den obersten Knoten Gruppenrichtlinienverwaltung klicken und den<br />
DNS-Namen Ihrer Gesamtstruktur-Stammdomäne eingeben.<br />
3. Erweitern Sie den Gesamtstrukturknoten, um die gewünschte Domäne zu verwalten.<br />
Falls die Domäne, die Sie verwalten wollen, sich nicht in der Gesamtstruktur-Stammdomäne<br />
befindet, können Sie mit der rechten Maustaste auf den Knoten Domänen klicken<br />
und den Befehl Domänen anzeigen wählen, um weitere Domänen einzubinden.<br />
4. Unter jedem Domänenknoten befindet sich ein Knoten namens Gruppenrichtlinienobjekte.<br />
Erweitern Sie diesen Knoten und wählen Sie das GPO aus, dessen <strong>Sicherheit</strong>sfilter<br />
Sie ändern wollen.<br />
5. Stellen Sie sicher, dass im rechten Fensterabschnitt die Registerkarte Bereich ausgewählt<br />
ist. Der Abschnitt <strong>Sicherheit</strong>sfilterung liegt in der Mitte dieses Fensterabschnitts. Darin
190 Kapitel 7: Gruppenrichtlinien<br />
ist in der Standardeinstellung die Gruppe Authentifizierte Benutzer aufgeführt (Abbildung<br />
7.3). Wie bereits erwähnt, können alle Benutzer und Computer ein GPO verarbeiten,<br />
nachdem es erstellt wurde.<br />
Abbildung 7.3 Anzeigen der <strong>Sicherheit</strong>sfilterung für ein GPO<br />
6. Entfernen Sie Authentifizierte Benutzer aus der Liste <strong>Sicherheit</strong>sfilterung. Wenn diese<br />
Berechtigung aktiv ist, verarbeiten alle Benutzer und Computer dieses GPO. Markieren<br />
Sie den Eintrag Authentifizierte Benutzer und klicken Sie auf Entfernen.<br />
7. Klicken Sie auf die Schaltfläche Hinzufügen und geben Sie den Namen einer Benutzer-<br />
oder Computergruppe ein, die Sie für die <strong>Sicherheit</strong>sfilterung verwenden wollen. Beachten<br />
Sie, dass Computergruppen verwendet werden, um computerspezifische Richtlinien<br />
zu filtern (die Richtlinien im Abschnitt Computerkonfiguration eines GPOs), und Benutzergruppen,<br />
um benutzerspezifische Richtlinien zu filtern (die Richtlinien im Abschnitt<br />
Benutzerkonfiguration eines GPOs). Klicken Sie auf Namen überprüfen, um den Gruppennamen<br />
aufzulösen, und dann auf OK, um die Eingabe zu bestätigen. <strong>Die</strong> neue Gruppe<br />
wird nun zum Abschnitt <strong>Sicherheit</strong>sfilterung auf der Registerkarte Bereich des Gruppenrichtlinienobjekts<br />
hinzugefügt.<br />
Hinter den Kulissen hat die Konsole Gruppenrichtlinienverwaltung in Wirklichkeit die Berechtigungen<br />
Lesen und Gruppenrichtlinie übernehmen für die Gruppe hinzugefügt, die Sie<br />
zu diesem GPO hinzugefügt haben. Sie können auch ein einzelnes Computer- oder Benutzerkonto<br />
zu einem <strong>Sicherheit</strong>sfilter hinzufügen. <strong>Die</strong>s wird zwar nicht empfohlen, es kann<br />
aber für Testzwecke nützlich sein, wenn ein GPO nur auf einen einzelnen Computer oder<br />
Benutzer angewendet wird.<br />
Oft wird missverstanden, welcher Unterschied zwischen der Verknüpfung mit einem GPO<br />
und der <strong>Sicherheit</strong>sfilterung besteht. Ein GPO muss mit einem Container verknüpft sein, in
Grundlagen von Gruppenrichtlinien 191<br />
dem das Computer- oder Benutzerkonto des gewünschten Ziels liegt. Falls ich computerspezifische<br />
<strong>Sicherheit</strong>srichtlinien auf allen Computern in der Marketingabteilung meiner Organisation<br />
bereitstellen will, verknüpfe ich mein GPO mit der Organisationseinheit Marketing.<br />
Falls ein Teil der Computer innerhalb der Organisationseinheit Marketing eine andere <strong>Sicherheit</strong>srichtlinie<br />
haben muss, (etwa weil sie unter einem anderen Betriebssystem laufen), kann<br />
ich die <strong>Sicherheit</strong>sgruppenfilterung bei einem zweiten GPO verwenden, das ebenfalls mit<br />
der Organisationseinheit Marketing verknüpft ist, um diese Computer auszusondern. Es ist<br />
egal, ob die <strong>Sicherheit</strong>sgruppe, mit der ich filtere, in einer Organisationseinheit liegt, die<br />
außerhalb der Organisationseinheit Marketing angeordnet ist. Vergessen Sie nicht, dass<br />
Gruppenrichtlinien nur von Benutzer- und Computerkonten verarbeitet werden. Daher kann<br />
eine <strong>Sicherheit</strong>sgruppe an beliebiger Stelle in Active Directory liegen, aber trotzdem eingesetzt<br />
werden, um Gruppenrichtlinien für die Computer oder Benutzer einer bestimmten<br />
Organisationseinheit zu filtern. Spätestens jetzt dürfte Ihnen aber bewusst werden, dass die<br />
Verwendung von <strong>Sicherheit</strong>sgruppen für bestimmte Arten der Filterung (etwa Filterung<br />
anhand des Betriebssystems) etwas umständlich ist. Für solche Zwecke sollten wir die<br />
WMI-Filterung verwenden.<br />
WMI-Filterung für GPOs<br />
Bisher habe ich beschrieben, wie GPOs verknüpft werden, um zu steuern, welche Benutzer<br />
und Computer sie verarbeiten, und ich habe erklärt, wie Sie mithilfe der <strong>Sicherheit</strong>sgruppenfilterung<br />
flexibler steuern können, auf welche Ziele innerhalb der verknüpften Standorte,<br />
Domänen und Organisationseinheiten ein GPO angewendet wird. Jetzt sehen wir uns den<br />
letzten Mechanismus an, mit dem Sie steuern, wie Gruppenrichtlinien verarbeitet werden:<br />
WMI-Filter.<br />
WMI-Filterung wurde erstmals in <strong>Windows</strong> <strong>Server</strong> 2003 und <strong>Windows</strong> XP eingeführt. Im<br />
Unterschied zur <strong>Sicherheit</strong>sgruppenfilterung, die voraussetzt, dass Sie Benutzer und Computer<br />
in Gruppen zusammenfassen, greift die WMI-Filterung auf das integrierte WMI-Framework<br />
(<strong>Windows</strong> Management Instrumentation) zurück, das seit <strong>Windows</strong> XP in das Betriebssystem<br />
eingebaut ist. Sie können damit die Anwendung von Gruppenrichtlinien dynamisch<br />
filtern, abhängig von der Hardware- und Softwarekonfiguration des Computers und<br />
Benutzers.<br />
Um die WMI-Filterung nutzen zu können, müssen Sie WQL (WMI Query Language) beherrschen.<br />
In Active Directory erstellen Sie mit der Konsole Gruppenrichtlinienverwaltung<br />
WMI-Filter, die eine WQL-Anweisung enthalten. <strong>Die</strong>se Anweisung kann zum Beispiel folgende<br />
Fragen stellen: »Läuft das System, das diese Richtlinie verarbeitet, unter <strong>Windows</strong><br />
XP Service Pack 2? Läuft es unter <strong>Windows</strong> Vista? Läuft es unter <strong>Windows</strong> Vista Business<br />
Edition?« Wenn Sie einen solchen Filter erstellt haben, können Sie ihn mit einem GPO verknüpfen,<br />
auch das tun Sie wieder in der Konsole Gruppenrichtlinienverwaltung. Anschließend<br />
wertet der Computer oder Benutzer, der das GPO verarbeitet, die WQL-Anweisung<br />
aus. Falls die Anweisung das Ergebnis True ergibt, wird das GPO angewendet. Falls die<br />
Anweisung das Ergebnis False liefert, wird das GPO nicht angewendet. Indem Sie WMI-<br />
Filter auf diese Weise verwenden, können Sie die Verarbeitung von Gruppenrichtlinien anhand<br />
der Hardware oder Software filtern, die auf einem Computer installiert ist.<br />
WMI-Filteranweisungen müssen immer die Form einer Abfrage haben, die das Ergebnis<br />
True oder False liefert, wenn sie auf dem Computer ausgeführt werden, der diesen Filter<br />
verarbeitet. Abbildung 7.4 zeigt ein Beispiel für einen WMI-Filter, der untersucht, ob auf<br />
dem Zielsystem <strong>Windows</strong> XP mit Service Pack 2 läuft.
192 Kapitel 7: Gruppenrichtlinien<br />
Abbildung 7.4 Eine WMI-Filterabfrage prüft, ob das System<br />
unter <strong>Windows</strong> XP Service Pack 2 läuft<br />
Wie Sie in Abbildung 7.4 sehen, bestehen WQL-Anweisungen aus einer Select-Anweisung,<br />
die alle Instanzen einer bestimmten WMI-Klasse abfragt (in diesem Beispiel Win32_OperatingSystem)<br />
und dann nach bestimmten Eigenschaften sucht (zum Beispiel Caption="<strong>Windows</strong><br />
XP Professional"). Eine vollständige Einführung, wie WQL-Anweisungen geschrieben werden,<br />
würde den Rahmen dieses Kapitels sprengen. Weitere Informationen finden Sie auf der<br />
Microsoft-Website unter http://msdn2.microsoft.com/en-us/library/aa392902.aspx.<br />
Wie bereits erwähnt, werden WMI-Filter in der Konsole Gruppenrichtlinienverwaltung verwaltet.<br />
Sie finden innerhalb jeder Domäne, die in die Konsole Gruppenrichtlinienverwaltung<br />
geladen wurde, einen Knoten mit dem Namen WMI-Filter. WMI-Filter werden nämlich in<br />
der jeweiligen Domäne gespeichert, genau wie GPOs. Wenn Sie mit der rechten Maustaste<br />
auf den Knoten WMI-Filter klicken und den Befehl Neu wählen, können Sie einen neuen<br />
WMI-Filter erstellen. Wenn Sie die WQL-Anweisung im WMI-Filtereditor eingeben, überprüft<br />
die Konsole Gruppenrichtlinienverwaltung sofort, ob die WQL-Anweisung syntaktisch<br />
richtig ist. Falls es keine gültige Anweisung ist, bekommen Sie die Meldung aus Abbildung 7.5<br />
angezeigt, wenn Sie versuchen, den Filter zu speichern.<br />
Abbildung 7.5 <strong>Die</strong> Syntax einer WQL-Abfrage wird überprüft,<br />
wenn Sie versuchen, einen WMI-Filter zu speichern<br />
Sie sollten bei der Verwendung von WMI-Filtern daran denken, dass manche Abfragen Leistungsprobleme<br />
verursachen können, während die Gruppenrichtlinien verarbeitet werden.<br />
Falls Sie zum Beispiel eine Abfrage schreiben, die die Active Directory-Gruppenmitgliedschaft<br />
auswertet, kann die Auswertung in einer großen Active Directory-Umgebung einige<br />
Zeit dauern, sodass die Verarbeitung der Gruppenrichtlinien deutlich verzögert wird.
Grundlagen von Gruppenrichtlinien 193<br />
Nachdem wir uns nun die Gruppenrichtlinien aus der Perspektive von Active Directory angesehen<br />
haben, wollen wir uns damit beschäftigen, wie Gruppenrichtlinien aus Sicht des<br />
Systems funktionieren, das eine Richtlinie verarbeitet.<br />
Gruppenrichtlinienverarbeitung<br />
Beim Thema Gruppenrichtlinien ist zwar wichtig zu wissen, wie GPOs erstellt und verwaltet<br />
werden, aber Sie müssen auch wissen, wie Gruppenrichtlinien verarbeitet werden (oder<br />
warum sie nicht verarbeitet werden). Nur so können Sie sicherstellen, dass Ihre Benutzer<br />
und Computer die <strong>Sicherheit</strong>skonfiguration erhalten, die Sie vorgesehen haben. Daher sehen<br />
wir uns in diesem Abschnitt die Clientseite von Gruppenrichtlinien an. Wie bereits erwähnt,<br />
verarbeiten Benutzer- und Computerobjekte, die in Active Directory liegen, die Gruppenrichtlinienobjekte.<br />
Das Modul zur Gruppenrichtlinienverarbeitung funktioniert im Prinzip<br />
immer gleich, ganz egal, ob es sich um <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, <strong>Windows</strong> Vista oder eine<br />
ältere Version handelt. Es werden zwei Arten von Gruppenrichtlinienverarbeitung durchgeführt,<br />
Vordergrund- und Hintergrundverarbeitung:<br />
Vordergrundverarbeitung findet statt, wenn ein <strong>Windows</strong>-Computer startet oder wenn<br />
sich ein Benutzer anmeldet. Vordergrundverarbeitung ist wichtig, weil bestimmte Bereiche<br />
der Gruppenrichtlinien, zum Beispiel Ordnerumleitung und Softwareinstallation, nur<br />
während der Vordergrundverarbeitungsphase ausgewertet werden. Sie brauchen nämlich<br />
exklusiven Zugriff auf die Computer- oder Benutzerumgebung, um ihre Aufgaben zu erfüllen.<br />
Ohne diesen exklusiven Zugriff wäre es schwierig herauszufinden, in welchem<br />
Zustand der Benutzer den Computer übergeben bekommt. Es ist nicht sinnvoll, dass<br />
Software installiert wird, während Sie versuchen, diese Software auszuführen!<br />
Hintergrundverarbeitung wird in regelmäßigen Abständen im Hintergrund durchgeführt.<br />
Domänencontroller führen in der Standardeinstellung alle 5 Minuten eine Hintergrundverarbeitung<br />
aus. Arbeitsstationen und Mitgliedserver führen die Hintergrundverarbeitung<br />
alle 90 Minuten aus, mit einem zufälligen Offset von 0 bis 30 Minuten, um sicherzustellen,<br />
dass nicht alle Systeme gleichzeitig die Richtlinien aktualisieren.<br />
Tipp Sie können das Aktualisierungsintervall für Domänencontroller, Arbeitsstationen und Mitgliedserver<br />
ändern, indem Sie die Richtlinieneinstellungen unter Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie\Gruppenrichtlinien-Aktualisierungsintervall<br />
für Domänencontroller beziehungsweise<br />
Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie\Gruppenrichtlinien-Aktualisierungsintervall<br />
für Computer anpassen.<br />
Neben diesen beiden Verarbeitungsmodi gibt es noch zwei Möglichkeiten, wie die Vordergrundverarbeitung<br />
durchgeführt werden kann: synchron oder asynchron. <strong>Die</strong> Hintergrundverarbeitung<br />
ist definitionsgemäß asynchron. Bei der synchronen Richtlinienverarbeitung<br />
muss die Gruppenrichtlinienverarbeitung abgeschlossen sein, bevor der Benutzer einen Anmeldedialog<br />
angezeigt bekommt (bei Computerrichtlinien) beziehungsweise bevor sich der<br />
Desktop des Benutzers öffnet (bei Benutzerrichtlinien). So wird sichergestellt, dass die<br />
Richtlinien, die unter Umständen Auswirkungen auf die aktuelle Sitzung haben, vollständig<br />
verarbeitet wurden, bevor der Benutzer mit dem System arbeiten kann. Das verzögert allerdings<br />
auch den Start- und Anmeldevorgang, daher ist in <strong>Windows</strong> XP und <strong>Windows</strong> Vista<br />
standardmäßig die asynchrone Vordergrundrichtlinienverarbeitung aktiviert. Asynchrone<br />
Verarbeitung bedeutet, dass das Gruppenrichtlinienmodul die Computerrichtlinien weiter<br />
verarbeitet, während der Benutzer sich schon anmelden und am Desktop arbeiten kann,
194 Kapitel 7: Gruppenrichtlinien<br />
obwohl die Benutzerrichtlinie unter Umständen noch nicht vollständig verarbeitet wurde. In<br />
<strong>Windows</strong> <strong>Server</strong> 2003 und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wird die Vordergrundverarbeitung immer<br />
synchron durchgeführt. Falls Sie allerdings Terminalserver verwenden, können Sie in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> jetzt die Vordergrundverarbeitung für Terminalserverbenutzer auf asynchron<br />
stellen, indem Sie die Richtlinie unter Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie\Asynchrone<br />
Verarbeitung der Gruppenrichtlinie für Benutzer<br />
bei Anmeldung über Terminaldienste zulassen aktivieren.<br />
Bestimmte Richtlinienbereiche können nur ausgewertet werden, wenn die Vordergrundverarbeitung<br />
synchron durchgeführt wird. Ein Beispiel sind Softwareinstallationsrichtlinien.<br />
Falls das Gruppenrichtlinienmodul eine Vordergrundverarbeitung durchführt und eine Softwareinstallationsrichtlinie<br />
findet, setzt es ein Flag, das <strong>Windows</strong> anweist, die Richtlinie während<br />
der nächsten Vordergrundaktualisierung synchron zu verarbeiten. Aus diesem Grund<br />
sind manchmal zwei Neustarts oder Anmeldevorgänge erforderlich, bis die Bereitstellung<br />
eines Softwareinstallationspakets abgeschlossen ist.<br />
Glücklicherweise funktionieren die meisten anderen Richtlinienbereiche, zum Beispiel<br />
<strong>Sicherheit</strong> und administrative Vorlagen, sowohl mit Vordergrund- als auch Hintergrundverarbeitung,<br />
und ganz unabhängig davon, ob sie synchron oder asynchron durchgeführt wird.<br />
Erkennen langsamer Verbindungen<br />
Neben den beiden unterschiedlichen Verarbeitungsarten gibt es weitere Bedingungen, die<br />
Auswirkungen darauf haben können, welche Gruppenrichtlinienbereiche angewendet werden.<br />
Zum Beispiel ist in die Gruppenrichtlinien ein Mechanismus zum Erkennen langsamer<br />
Verbindungen eingebaut. Er kann entdecken, wenn die Netzwerkverbindung zwischen<br />
Computer oder Benutzer und dem Domänencontroller langsam ist. In der Standardeinstellung<br />
gilt eine Verbindung als langsam, wenn sie mit weniger als 500 KBit/Sekunde überträgt.<br />
Sie können diesen Grenzwert in den Gruppenrichtlinien verändern. Der Vorgang zum<br />
Erkennen langsamer Verbindungen wurde in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
verändert. In älteren <strong>Windows</strong>-Versionen beruhte dieser Prozess auf ICMP-Pings zwischen<br />
Client und Domänencontroller, mit denen die Geschwindigkeit der Verbindung ermittelt<br />
wurde. <strong>Die</strong>se Methode war unzuverlässig, und viele Organisationen schränken ICMP-Verkehr<br />
im internen Netzwerk aus <strong>Sicherheit</strong>sgründen ein oder unterbinden ihn ganz. Daher<br />
greift die Erkennung langsamer Verbindungen in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
jetzt auf den NLA-<strong>Die</strong>nst (Network Position Awareness) zurück, um die Verbindungsgeschwindigkeit<br />
zwischen Client und Domänencontroller während der Gruppenrichtlinienverarbeitung<br />
zu ermitteln. In dieser Eigenschaft misst NLA LDAP-Verkehr zwischen Client<br />
und Domänencontroller, um die Verbindungsgeschwindigkeit zu berechnen.<br />
Falls der Grenzwert für die Erkennung langsamer Verbindungen während dieser Überprüfung<br />
unterschritten wird, werden bestimmte Gruppenrichtlinienbereiche standardmäßig nicht<br />
verarbeitet. Das sind unter anderem die Bereiche Softwareinstallation, Ordnerumleitung,<br />
Internet Explorer-Verwaltungsrichtlinien und Skriptrichtlinien. Sie können das Verhalten<br />
dieser Richtlinienbereiche aber verändern und erzwingen, dass sie auch bei einer langsamen<br />
Verbindung verarbeitet werden. Ändern Sie dazu die Einstellungen der Richtlinienbereiche<br />
unter Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie. Der<br />
wesentliche Faktor bei der Erkennung langsamer Verbindungen für die Gruppenrichtlinienverarbeitung<br />
ist, dass die <strong>Sicherheit</strong>srichtlinie auf jeden Fall verarbeitet wird, selbst bei<br />
einer langsamen Verbindung.
Grundlagen von Gruppenrichtlinien 195<br />
Optimierungen für die Richtlinienverarbeitung<br />
Das Gruppenrichtlinienmodul hat die Aufgabe, GPOs zu verarbeiten, die auf den aktuellen<br />
Computer oder Benutzer angewendet werden. Und wie ich bereits beschrieben habe, findet<br />
die Verarbeitung in regelmäßigen Abständen im Vorder- und Hintergrund statt. Würde das<br />
Gruppenrichtlinienmodul allerdings sämtliche angewendeten GPOs bei jeder Verarbeitung<br />
erneut vollständig verarbeiten (unabhängig davon, ob überhaupt Änderungen an den angewendeten<br />
GPOs vorgenommen wurden), wäre das eine Verschwendung von Netzwerk- und<br />
Systemressourcen. Daher hat Microsoft einige Optimierungen in das Gruppenrichtlinienmodul<br />
eingebaut. <strong>Die</strong> wichtigste ist, dass innerhalb einer Richtlinie keine Verarbeitung stattfindet,<br />
falls sich innerhalb der Umgebung nichts verändert hat. Was eine Änderung ist, lässt<br />
sich allerdings gar nicht so einfach bestimmen, es ist zumindest nicht offensichtlich. Es<br />
beschränkt sich auf jeden Fall nicht auf eine Änderung an einem GPO, schließlich können<br />
sich mehrere Faktoren darauf auswirken, welche GPOs auf einen bestimmten Computer<br />
oder Benutzer angewendet werden. Und falls sich eines von 10 GPOs, die auf einen Computer<br />
angewendet werden, geändert hat, müssen unter Umständen alle 10 erneut ausgeführt<br />
werden, damit die weiter oben beschriebenen Vorrangregeln eingehalten werden.<br />
Folgende Änderungen lösen aus, dass die Gruppenrichtlinienverarbeitung GPOs während<br />
einer bestimmten Phase erneut verarbeitet:<br />
Es wird eine Änderung an den Einstellungen innerhalb eines GPOs vorgenommen, das<br />
auf den Benutzer oder Computer angewendet wird.<br />
<strong>Die</strong> Liste der GPOs, die auf den Computer oder Benutzer angewendet werden, verändert<br />
sich. (Anders ausgedrückt: Es wird ein neues GPO hinzugefügt oder eines, das vorher<br />
angewendet wurde, wird entfernt.)<br />
Es wird eine Änderung an der <strong>Sicherheit</strong>sgruppenzugehörigkeit des Benutzers oder<br />
Computers vorgenommen, die sich auf die <strong>Sicherheit</strong>sgruppenfilterung auswirken kann.<br />
Es wird eine Änderung an einem WMI-Filter vorgenommen (es wird ein Filter zu einem<br />
GPO hinzugefügt oder daraus entfernt), der vom Computer oder Benutzer verarbeitet<br />
wird.<br />
So funktioniert’s: Versionskontrolle für Gruppenrichtlinien<br />
Da das Gruppenrichtlinienmodul Richtlinien nur verarbeitet, wenn sich etwas verändert<br />
hat, muss es offensichtlich einen Mechanismus geben, um zu erkennen, wann sich ein<br />
GPO verändert. Das wird mithilfe einer Versionskontrolle erreicht. Jedes Mal, wenn Sie<br />
eine Änderung an einer Einstellung innerhalb eines GPOs vornehmen, wird die Versionsnummer<br />
dieses GPOs erhöht. <strong>Die</strong> Versionsnummer wird in den Active Directory- und<br />
SYSVOL-Teilen des GPOs gespeichert, dem sogenannten GPC (Group Policy Container)<br />
und der GPT (Group Policy Template). Wenn das Gruppenrichtlinienmodul auf einem<br />
Clientsystem die Richtlinie verarbeitet, vergleicht es bei jedem GPO, das angewendet<br />
werden soll, die Versionsnummern mit denen, die es in seine eigene Registrierung eingetragen<br />
hat, als es die Gruppenrichtlinien das letzte Mal verarbeitet hat. <strong>Die</strong>ser Speicherort<br />
ist der sogenannte Gruppenrichtlinienverlauf. Falls sich die Versionen in GPO und Verlauf<br />
unterscheiden, weiß das Modul, dass es die Richtlinie während der aktuellen Phase<br />
erneut verarbeiten muss.
196 Kapitel 7: Gruppenrichtlinien<br />
Weil nicht jeder Richtlinienbereich eigene Versionsinformationen verwaltet, sondern es<br />
nur eine einzige Versionsnummer für das gesamte GPO gibt, kann folgender Fall eintreten:<br />
Nehmen wir an, ein Clientcomputer muss zwei GPOs verarbeiten, GPO A und GPO B.<br />
GPO A enthält Richtlinieneinstellungen aus den Zweigen Administrative Vorlagen und<br />
<strong>Sicherheit</strong>seinstellungen. GPO B enthält nur <strong>Sicherheit</strong>srichtlinieneinstellungen. Ein<br />
Administrator nimmt eine Änderung an einer Einstellung in Administrative Vorlagen von<br />
GPO A vor. Daraufhin wird die Versionsnummer von GPO A erhöht. Der Clientcomputer<br />
muss GPO A verarbeiten, um die neue Einstellung aus Administrative Vorlagen zu übernehmen,<br />
aber er muss auch GPO B verarbeiten, weil sowohl GPO A als auch GPO B<br />
<strong>Sicherheit</strong>seinstellungen enthalten. Daher muss der Computer die <strong>Sicherheit</strong>seinstellungen<br />
aus beiden GPOs verarbeiten, damit die Vorrangregeln beachtet werden.<br />
Wie Sie Ihre GPOs organisieren und welche Richtlinienbereiche Sie in welchen Richtlinien<br />
implementieren, kann also Auswirkungen darauf haben, wie sie verarbeitet werden.<br />
Ich habe beschrieben, dass die Gruppenrichtlinien nicht während jeder Vorder- und Hintergrundverarbeitung<br />
erneut ausgewertet werden, jedenfalls sofern sich nichts geändert hat.<br />
Aber es gibt eine Ausnahme von dieser Regel: <strong>Die</strong> Einstellungen der <strong>Sicherheit</strong>srichtlinie<br />
werden in der Standardeinstellung alle 16 Stunden aktualisiert, selbst falls sich in der Gruppenrichtlinieninfrastruktur<br />
nichts geändert hat. Dafür gibt es einen guten Grund. Falls ein<br />
Benutzer es absichtlich oder versehentlich schafft, eine Änderung an der lokalen <strong>Sicherheit</strong>srichtlinie<br />
seines Systems vorzunehmen, kann es nützlich sein, wenn diese Richtlinie<br />
alle 16 Stunden automatisch aus den Active Directory-Gruppenrichtlinien erneut angewendet<br />
wird.<br />
Auf der CD <strong>Die</strong> Begleit-CD enthält eine benutzerdefinierte ADMX-Datei namens Securityrefresh.ADMX<br />
(und die zugehörige Securityrefresh.ADML),mit der Sie dieses Intervall über die Richtlinie Administrative<br />
Vorlagen einstellen können.<br />
Hinweis Sie können den Standardwert von 16 Stunden für das Aktualisierungsintervall über die CSE<br />
(Client Side Extension) anpassen, indem Sie auf Clientcomputern den folgenden Registrierungswert ändern:<br />
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\<strong>Windows</strong> NT\CurrentVersion\Winlogon\GP-<br />
Extensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\MaxNoGPOListChangesInterval. <strong>Die</strong>ser<br />
Eintrag legt fest, wie viele Minuten zwischen erzwungenen Aktualisierungsintervallen liegen. Der Standardwert<br />
beträgt 960 (dezimal).<br />
Sie können auch das Richtlinienverarbeitungsverhalten einer CSE steuern und sie zwingen, Richtlinien<br />
sogar dann während jeder Vorder- und Hintergrundphase zu verarbeiten, wenn keine Änderungen vorgenommen<br />
wurden. Das kann eine Menge zusätzlichen Netzwerkverkehr und Systembelastung verursachen,<br />
stellt aber sicher, dass die Richtlinien einer bestimmten CSE immer auf dem neuesten Stand sind. Sie<br />
können dazu für jeden Computer, den Sie konfigurieren wollen, das Richtlinienverarbeitungselement einer<br />
CSE unter Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie verändern.<br />
Nachdem wir nun die Grundlagen zur Verarbeitung von Gruppenrichtlinien kennen, können<br />
wir uns genauer ansehen, welche Änderungen an der Gruppenrichtlinienverwaltung in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> vorgenommen wurden.
Was ist neu bei Gruppenrichtlinien? 197<br />
Was ist neu bei Gruppenrichtlinien?<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista führen einige wichtige Verbesserungen an der<br />
Verwaltung der Gruppenrichtlinien und der Elemente ein, die über Gruppenrichtlinien konfiguriert<br />
werden können. Sehen wir uns zuerst einige dieser Verwaltungsverbesserungen an,<br />
anschließend befassen wir uns damit, welche Richtlinienverbesserungen es im Bereich der<br />
<strong>Sicherheit</strong>skonfigurationsverwaltung gibt.<br />
Gruppenrichtliniendienst<br />
<strong>Die</strong> erste Änderung an der Gruppenrichtlinieninfrastruktur ist für Administratoren kaum zu<br />
sehen. Vor <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> lief das Gruppenrichtlinienmodul<br />
innerhalb des vertrauenswürdigen Winlogon-Prozesses in <strong>Windows</strong>. Das war damals sinnvoll,<br />
verursachte aber auch einige Probleme. Vor allem liefen auch CSEs (Client Side Extension)<br />
von Microsoft oder Fremdherstellern in diesem Prozess. Und falls Bugs in diesen<br />
CSEs auftraten, konnten sie dazu führen, dass <strong>Windows</strong> nicht mehr reagierte. In <strong>Windows</strong><br />
Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> verlegte Microsoft das Gruppenrichtlinienmodul aus Winlogon<br />
in den Gruppenrichtlinienclientdienst, der unter dem Svchost.exe-Prozess ausgeführt<br />
wird. <strong>Die</strong>ser Prozess kann allerdings nicht von einem Administrator beendet oder gestartet<br />
werden, zumindest nicht ohne Weiteres. Der <strong>Die</strong>nst ist gehärtet, um die Chancen zu verbessern,<br />
dass er immer läuft, während <strong>Windows</strong> ausgeführt wird. Und weil der <strong>Die</strong>nst nicht<br />
mehr in Winlogon läuft, bringen fehlerhafte CSEs nur den <strong>Die</strong>nst zum Absturz, nicht das<br />
gesamte Betriebssystem.<br />
ADMX-Vorlagen und der zentrale Speicher<br />
In <strong>Windows</strong>-Versionen vor <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wurden Einstellungen<br />
im Zweig Administrative Vorlagen durch sprachspezifische ADM-Vorlagendateien gesteuert.<br />
<strong>Die</strong>se Dateien wurden von Microsoft zur Verfügung gestellt, Administratoren können aber<br />
auch eigene erstellen. <strong>Die</strong> Syntax dieser Dateien war proprietär, und die Texte, die im Gruppenrichtlinien-Editor<br />
angezeigt wurden, wurden in derselben ADM-Datei gespeichert, die<br />
auch die Registrierungsposition für eine bestimmte Bindung definierte. Außerdem umfasste<br />
jedes GPO einen Satz von ADM-Dateien innerhalb des SYSVOL-Abschnitt des GPOs, die<br />
sogenannte GPT (Group Policy Template, Gruppenrichtlinien-Vorlage). <strong>Die</strong>se ADM-Dateien<br />
waren im Allgemeinen bei allen GPOs in einer Domäne identisch, aber trotzdem wurden sie<br />
überflüssigerweise auf alle Domänencontroller in der Domäne repliziert.<br />
Mit <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> führte Microsoft die neuen ADMX- und<br />
ADML-Dateiformate ein. <strong>Die</strong> ADMX-Datei enthält eine neue XML-basierte Syntax, mit der<br />
Richtlinien für Administrative Vorlagen beschrieben werden. Jeder ADMX-Datei ist eine<br />
ADML-Datei zugeordnet, die sprachspezifische Zeichenfolgen für diesen Satz von Richtlinieneinstellungen<br />
enthält. Indem die Richtlinienelemente von den Anzeigetexten getrennt<br />
wurden, hat Microsoft es Administratoren, die internationale <strong>Windows</strong> Vista- oder <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>-Versionen verwenden, einfacher gemacht, die Richtlinien in Administrative<br />
Vorlagen in ihrer jeweiligen Sprache zu verwalten.<br />
<strong>Die</strong> neuen ADMX- und ADML-Dateien nutzen auch ein anderes Speicherungsmodell als<br />
ihre Vorgängerversionen. ADMX- und ADML-Dateien werden von Microsoft standardmäßig<br />
mitgeliefert, sie befinden sich bei einer <strong>Windows</strong> Vista- oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<br />
Standardinstallation im Ordner %WinDir%\policydefinitions (Abbildung 7.6).
198 Kapitel 7: Gruppenrichtlinien<br />
Abbildung 7.6 Anzeigen der ADMX-Dateien, die in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthalten sind<br />
Beachten Sie den Ordner de-DE innerhalb des Ordners PolicyDefinitions in Abbildung 7.6.<br />
<strong>Die</strong>s ist der sprachspezifische Ordner für deutschsprachige ADML-Dateien. Wenn Sie den<br />
Gruppenrichtlinien-Editor in <strong>Windows</strong> Vista oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> starten und den<br />
Knoten Administrative Vorlagen erweitern, sucht der Editor automatisch im Ordner %Win-<br />
Dir%\policydefinitions nach ADMX- und ADML-Dateien. Sie können die Dateien aber auch<br />
an einen zentralen Speicherort kopieren, den sogenannten zentralen Speicher (engl. central<br />
store).<br />
Der zentrale Speicher ist einfach ein Dateiordner innerhalb der SYSVOL-Freigabe, der auf all<br />
Ihre Domänencontroller repliziert wird. Sie können den zentralen Speicher von Hand anlegen<br />
und Ihre ADMX- und ADML-Dateien hineinkopieren. Der zentrale Speicher muss innerhalb<br />
eines Ordners namens PolicyDefinitions im Ordner \\\sysvol\\<br />
policies liegen. Wenn Sie den zentralen Speicher nutzen, hat das unter anderem den Vorteil,<br />
dass alle Administratoren, die Gruppenrichtlinien verwalten, Zugriff auf alle verwendeten<br />
ADMX-Dateien haben, die im zentralen Speicher zur Verfügung gestellt werden. Administratoren<br />
brauchen keine ADM-Dateien mehr auf ihre lokalen Computer zu kopieren, um<br />
neue administrative Vorlagen zu konfigurieren. Der Gruppenrichtlinien-Editor durchsucht erst<br />
den zentralen Speicher, bevor er %WinDir%\policydefinitions ausliest. Falls er den zentralen<br />
Speicher findet, verwendet er statt der lokalen ADMX- und ADML-Dateien die Exemplare<br />
aus dem zentralen Speicher.<br />
Beachten Sie, dass ADMX- und ADML-Dateien niemals automatisch in den SYSVOL-<br />
Abschnitt eines GPOs kopiert werden. Falls Sie also neue GPOs unter <strong>Windows</strong> Vista oder<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> erstellen, enthalten sie keine ADMX-Dateien innerhalb dieses Abschnitts.<br />
Alle ADMX- und ADML-Dateien werden lokal oder im zentralen Speicher abgerufen,<br />
wenn Sie ein <strong>Windows</strong> Vista- oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-GPO bearbeiten. Das spart<br />
Speicherplatz auf den SYSVOL-Freigaben Ihrer Domänencontroller, weil diese Vorlagendateien<br />
nicht mehr in jedem GPO auf jedem Domänencontroller gespeichert sind.
Was ist neu bei Gruppenrichtlinien? 199<br />
Direkt aus der Praxis: Der zentrale ADMX-Speicher<br />
Eines der großartigen neuen Features, die in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
zur Verfügung stehen, ist der zentrale Speicher für ADMX-Dateien. In älteren <strong>Windows</strong>-<br />
Versionen wurden ADM-Vorlagen, aus denen der Abschnitt Administrative Vorlagen der<br />
Gruppenrichtlinienobjekte generiert wird, in jede einzelne Gruppenrichtlinienvorlage kopiert.<br />
<strong>Die</strong>se Vervielfältigung der ADM-Vorlagen verursachte Probleme bei Replikationsverkehr,<br />
Administration der Gruppenrichtlinienobjekte und Versionskontrolle. <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista lösen dieses Problem, indem sie das proprietäre Format<br />
der ADM-Vorlagen durch ADMX-Dateien im XML-Format ersetzen. Das verbessert<br />
Sprachkompatibilität und Flexibilität und macht die Verwaltung leistungsfähiger.<br />
Um die Replikations- und Verwaltungsprobleme der ADM-Vorlagen zu beseitigen, können<br />
ADMX-Dateien jetzt in einem zentralen Speicher gesammelt werden. <strong>Die</strong> Lösung ist<br />
sehr simpel, weil Sie lediglich einen neuen Ordner namens PolicyDefinitions unter<br />
C:\<strong>Windows</strong>\Sysvol\sysvol\\Policies auf allen Domänencontrollern anlegen<br />
müssen. Wenn Sie den neuen Ordner angelegt haben, kopieren Sie alle ADMX-<br />
Dateien in den neuen Speicherort. Wenn Sie künftig ein GPO bearbeiten, werden die<br />
zentralisierten ADMX-Dateien verwendet, schlicht aufgrund der Tatsache, dass dieser<br />
Ordner vorhanden ist. Sie können auch beliebige benutzerdefinierte ADMX-Dateien in<br />
diesen Ordner legen, dann werden auch sie automatisch vom Gruppenrichtlinienverwaltungs-Editor<br />
verarbeitet.<br />
Derek Melber, MCSE, MVP, CISM, President<br />
BrainCore.Net AZ, Inc. (www.braincore.net)<br />
Starter-Gruppenrichtlinienobjekte<br />
Starter-Gruppenrichtlinienobjekte sind ein brandneues Feature in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>.<br />
Wie der Name andeutet, sind Starter-Gruppenrichtlinienobjekte praktisch Vorlagen, mit<br />
denen Sie echte GPOs erstellen können. Ein Starter-Gruppenrichtlinienobjekt unterstützt nur<br />
Einstellungen in Administrative Vorlagen, momentan können keine anderen Richtlinienbereiche<br />
verwendet werden. Aber weil Sie viele Tausend Richtlinieneinstellungen in diesem<br />
Bereich eines GPOs finden, ist diese vorläufige Einschränkung nicht besonders schlimm.<br />
Sie können Starter-Gruppenrichtlinienobjekts anlegen und ändern, indem Sie die Konsole<br />
Gruppenrichtlinienverwaltung öffnen und den Knoten Starter-Gruppenrichtlinienobjekte<br />
unterhalb des Knotens WMI-Filter innerhalb einer Active Directory-Domäne suchen (Abbildung<br />
7.7.)<br />
<strong>Die</strong> Funktionsweise von Starter-Gruppenrichtlinienobjekten ist recht simpel. Nehmen wir<br />
zum Beispiel an, ich habe einen Satz Einstellungen in Administrative Vorlagen, die ich auf<br />
mehrere GPOs in mehreren Domänen anwenden möchte. Ich erstelle ein Starter-Gruppenrichtlinienobjekt,<br />
das diese Einstellungen enthält, klicke dann mit der rechten Maustaste auf<br />
dieses Starter-Gruppenrichtlinienobjekt und wähle den Befehl Neues Gruppenrichtlinienobjekt<br />
aus Starter-Gruppenrichtlinienobjekt. Daraufhin wird ein neues, unverknüpftes GPO in<br />
meiner Domäne erstellt, und alle Administrative Vorlagen-Einstellungen werden aus dem<br />
Starter-Gruppenrichtlinienobjekt in das neue GPO kopiert.
200 Kapitel 7: Gruppenrichtlinien<br />
Abbildung 7.7 Starter-Gruppenrichtlinienobjekte in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Denken Sie daran, dass Starter-Gruppenrichtlinienobjekte keine echten Gruppenrichtlinienobjekte<br />
sind. Sie können ein Starter-Gruppenrichtlinienobjekt nicht mit einem Standort,<br />
einer Domäne oder einer Organisationseinheit verknüpfen. Sie dienen einzig als Vorlagen,<br />
die in ein echtes GPO kopiert werden. Außerdem können Sie Starter-Gruppenrichtlinienobjekte<br />
in .cab-Dateien speichern und zwischen Domänen kopieren. Auf diese Weise können<br />
Sie einen Satz Starter-Gruppenrichtlinienobjekte in der Domäne UK erstellen, als .cab-<br />
Dateien speichern und als E-Mail an Ihre Kollegen in Australien senden, wo sie dann als<br />
Starter-Gruppenrichtlinienobjekte in deren Domäne eingesetzt werden.<br />
GPO-Kommentare<br />
Ein weiteres praktisches Feature, das in den Konsolen Gruppenrichtlinienverwaltung und<br />
Gruppenrichtlinien-Editor von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> verfügbar ist, ist die Unterstützung für<br />
das Einfügen von GPO-spezifischen und einstellungsspezifischen Kommentaren. Mithilfe<br />
von Kommentaren können Sie als Administrator erklären, wofür ein bestimmtes GPO oder<br />
eine GPO-Einstellung verwendet werden sollen. Ein Administrator, der nicht weiß, wofür<br />
ein bestimmtes GPO gut sein soll oder warum eine bestimmte Einstellung vorgenommen<br />
wurde, kann die Kommentare lesen und so Sinn und Zweck einer Richtlinie erfahren. Sie<br />
können sowohl GPO-spezifische als auch einstellungsspezifische Kommentare im Gruppenrichtlinien-Editor<br />
eintragen. Öffnen Sie im Gruppenrichtlinien-Editor ein GPO, klicken Sie<br />
mit der rechten Maustaste auf den Stammknoten, der den Namen des GPOs angibt, und<br />
wählen Sie den Befehl Eigenschaften. Klicken Sie auf die Registerkarte Kommentar, um<br />
Kommentare zum gesamten GPO einzutragen.<br />
Einstellungsspezifische Kommentare werden nur für Richtlinienelemente in Administrative<br />
Vorlagen unterstützt. In einem solchen Richtlinienelement finden Sie jetzt die Registerkarte<br />
Kommentare, in der Sie Ihren Text eingeben können (Abbildung 7.8).<br />
Wenn Sie Kommentare zu Ihren Gruppenrichtlinien hinzugefügt haben, kann die Konsole<br />
Gruppenrichtlinienverwaltung Berichte zu Kommentaren erstellen, die zu einem GPO oder<br />
Gruppenrichtlinieneinstellungen hinzugefügt wurden.
Was ist neu bei Gruppenrichtlinien? 201<br />
Direkt von der Quelle: Kommentare<br />
Das Gruppenrichtlinienteam hat hart daran gearbeitet, einige nützliche neue Features bereitzustellen,<br />
die Gruppenrichtlinienadministratoren helfen, ihre Umgebungen besser zu<br />
verwalten. Eines dieser Features sind Kommentare, ein unglaublich wichtiges neues Feature,<br />
mit dem sich unverzichtbare Anmerkungen einfügen lassen. Auf diese Weise vergessen<br />
wir Administratoren nicht mehr, warum eine bestimmte Konfiguration vorgenommen<br />
wurde. Vor einiger Zeit arbeitete ich bei einem Kunden, wo wir uns gemeinsam die Gruppenrichtlinienumgebung<br />
ansahen. Wir gruben ein GPO aus, das im Jahr 2000 erstellt<br />
wurde. »Unmöglich!«, sagen Sie wahrscheinlich. Ich war ebenfalls wie vom Blitz getroffen.<br />
(Ich bin zugegebenermaßen ein empfindsames Gemüt.) Es stimmt aber: <strong>Die</strong>se GPOs<br />
sind für die Konfiguration vieler Clientsysteme im gesamten Unternehmen verantwortlich.<br />
Es wäre interessant zu wissen, warum bestimmte Konfigurationen vorgenommen<br />
wurden, wer dafür verantwortlich war und welche Ergebnisse erwartet wurden. Oder<br />
nicht?<br />
Daher brauchen wir Kommentare. Sie können Kommentare auf der obersten Ebene eines<br />
GPOs eintragen, um den Zweck des GPOs zu dokumentieren oder eine Einführung zu<br />
bieten. Sie können Kommentare bis hinunter zu den einzelnen Einstellungen eintragen,<br />
die im GPO enthalten sind. Auf diese Weise können Sie dokumentieren, warum eine Einstellung<br />
so konfiguriert ist. Oder Sie tragen Kontaktinformationen ein, für den Fall, dass<br />
andere Administratoren mehr Informationen benötigen. Sie haben völlig freie Hand. Sie<br />
können die Einstellungen filtern, sodass in der Konsole nur die kommentierten Einstellungen<br />
angezeigt werden. So können Sie schnell feststellen, was andere Administratoren<br />
tun oder was Sie selbst gemacht, aber schon wieder vergessen haben. Damit können Sie<br />
schnell sicherstellen, dass Sie einige Hinweise liefern, wenn Sie Aktionen durchführen,<br />
die Auswirkungen auf die Umgebung haben. Wir alle haben uns schon irgendwelche Sachen<br />
angesehen und uns dabei verzweifelt gefragt: »Warum habe ich das gemacht? Es<br />
ergibt einfach keinen Sinn.« Jetzt können Sie Ihr Selbstgespräch zumindest etwas länger<br />
fortsetzen mit: »Ohhhhhh, deshalb habe ich es gemacht!«<br />
Einige Warnungen: Kommentare gibt es nur zum GPO selbst oder zu Einstellungen in<br />
Administrative Vorlagen. Andere Einstellungen in den Gruppenrichtlinien, zum Beispiel<br />
unter <strong>Sicherheit</strong>seinstellungen, erlauben keine Kommentare. <strong>Die</strong> Kommentare zu Einstellungen<br />
werden im Einstellungsbericht angezeigt, die Kommentare zum GPO auf der Registerkarte<br />
Details in der Konsole Gruppenrichtlinienverwaltung. Sie können ein GPO<br />
mit einem Kommentar versehen, indem Sie den Editor für das GPO öffnen und das Eigenschaftendialogfeld<br />
des GPOs öffnen (oberster Knoten). Aktivieren Sie in diesem Dialogfeld<br />
die Registerkarte Kommentar. Wenn Sie eine Einstellung mit einem Kommentar<br />
versehen wollen, müssen Sie die Eigenschaften der Einstellung öffnen. Dort finden Sie<br />
wiederum die Registerkarte Kommentar.<br />
Endlich haben wir eine Möglichkeit, direkt Kommentare einzufügen und zu rechtfertigen,<br />
warum wir bestimmte Konfigurationseinstellungen definiert haben. Da wir und unsere<br />
GPOs nicht gerade jünger werden, dürfte das in den kommenden Jahren eine große Hilfe<br />
sein.<br />
Kevin Sullivan<br />
Lead Program Manager <strong>–</strong> Group Policy
202 Kapitel 7: Gruppenrichtlinien<br />
Abbildung 7.8 Eintragen einstellungsspezifischer<br />
Kommentare in Gruppenrichtlinien<br />
Abbildung 7.9 Mithilfe der Filterung können Sie nach Richtlinieneinstellungen<br />
suchen, die das Wort »Firewall« enthalten
Was ist neu bei Gruppenrichtlinien? 203<br />
Verbesserungen an der Filterung<br />
<strong>Die</strong> letzte Verbesserung an der Gruppenrichtlinieninfrastruktur, die ich hier beschreibe, betrifft<br />
die Filterung der Richtlinieneinstellungen aus Administrative Vorlagen im Gruppenrichtlinien-Editor<br />
anhand ganz verschiedener Kriterien. Vor <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> hatten Sie<br />
keine Möglichkeit, Richtlinien in Administrative Vorlagen anhand von Kriterien wie Name<br />
des Richtlinienelements oder Wörtern im Erklärungstext zu suchen oder zu filtern. Das neue<br />
Filterungsfeature gibt Ihnen einen praktischen Suchmechanismus innerhalb von Administrative<br />
Vorlagen, mit dem Sie nur die Richtlinienelemente anzeigen können, die Ihren Filterkriterien<br />
entsprechen. Sie können auf dieses Feature zugreifen, indem Sie im Gruppenrichtlinien-<br />
Editor mit der rechten Maustaste auf den Knoten Administrative Vorlagen klicken und den<br />
Befehl Filteroptionen wählen. Daraufhin öffnet sich das Dialogfeld aus Abbildung 7.9.<br />
Im Beispiel aus Abbildung 7.9 habe ich einen Filter für alle Richtlinien eingetragen, deren<br />
Titel das Wort »Firewall« enthält. Ich kann auch Erklärungstext oder Kommentare nach<br />
diesem Text durchsuchen oder die Anforderungsfilter aktivieren, um nur entsprechende<br />
Richtlinien zu suchen, die auf <strong>Windows</strong> Vista angewendet werden. Und ich kann auswählen,<br />
ob nur konfigurierte Richtlinien, nur verwaltete Richtlinien (keine Voreinstellungen) oder<br />
nur kommentierte Richtlinien angezeigt werden sollen. Wenn ich meinen Filter definiert<br />
habe, klicke ich erneut mit der rechten Maustaste auf den Knoten Administrative Vorlagen<br />
und wähle den Befehl Filter aktivieren. Daraufhin ändert sich die Anzeige der Richtlinieneinstellungen<br />
unter dem Knoten Administrative Vorlagen, sodass sie nur noch die Richtlinien<br />
auflistet, die meinen Filterkriterien entsprechen (Abbildung 7.10).<br />
Abbildung 7.10 Anwenden eines Filters innerhalb des Gruppenrichtlinien-Editors
204 Kapitel 7: Gruppenrichtlinien<br />
Als letztes Feature möchte ich noch den neuen Knoten Alle Einstellungen erwähnen, den Sie<br />
in Abbildung 7.10 unter dem Knoten Administrative Vorlagen sehen. Alle Einstellungen ist<br />
praktisch eine lange Liste aller Richtlinien in Administrative Vorlagen, die innerhalb des<br />
GPOs zur Verfügung stehen. Sie bietet eine andere (und in gewisser Weise simplere) Ansicht<br />
der Tausenden von Einstellungen aus den Ordnern und Unterordnern in diesem Abschnitt<br />
des Gruppenrichtlinien-Editors.<br />
Wir haben jetzt die Grundlagen von Gruppenrichtlinien kennengelernt und erfahren, was in<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> neu ist. Jetzt wollen wir uns einige der neuen Richtlinienbereiche<br />
ansehen, die in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> unterstützt werden. Dabei konzentrieren wir uns vor<br />
allem auf die neuen <strong>Sicherheit</strong>sfeatures.<br />
Erweiterte Verwaltungsmöglichkeiten für <strong>Sicherheit</strong>srichtlinien<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> fügen nicht nur etliche neue Einstellungen zu<br />
Administrative Vorlagen hinzu, sondern führen auch eine Reihe neuer CSEs (Client Side<br />
Extensions) ein, mit denen viele Richtlinienbereiche verwaltet werden können. Aufgrund<br />
des Themas dieses Buchs konzentrieren wir uns hier auf diejenigen, die mit <strong>Sicherheit</strong> zu<br />
tun haben. Sie sollten aber wissen, dass Gruppenrichtlinien ein noch leistungsfähigeres<br />
Werkzeug geworden sind, mit dem Sie die Konfiguration für die meisten Aspekte des Betriebssystems<br />
zentral verwalten können.<br />
Geräteeinschränkungen<br />
Geräteinschränkungen werden in den meisten Organisationen dringend gebraucht. Wie sollen<br />
Sie sonst verhindern, dass Ihre Benutzer USB-Flashlaufwerke und USB-Datensicherungsgeräte<br />
mit in die Arbeit bringen und einen Stapel vertraulicher Informationen kopieren?<br />
<strong>Die</strong> Gruppenrichtlinien in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bieten eine Lösung: ein<br />
Satz von Richtlinien im Knoten Administrative Vorlagen der Gruppenrichtlinien, mit denen<br />
Sie zwei Kontrollstufen über solche Wechselmedien erhalten. Auf der ersten Stufe bekommen<br />
Sie die Möglichkeit, die Installation von Gerätetreibern für alle Gerätklassen zu verhindern,<br />
insbesondere für Wechselmediengeräte. Auf der zweiten Stufe können Sie den Zugriff<br />
auf diese Medien steuern, sofern die Installation der Treiber erlaubt wurde. <strong>Die</strong>se zweite<br />
Richtlinienstufe gibt Ihnen die Möglichkeit, schreibgeschützten oder Schreibzugriff auf<br />
einen Wechseldatenträger zu erlauben, den der Benutzer installieren durfte.<br />
Sehen wir uns zuerst die Geräteinstallationseinschränkungen an. <strong>Die</strong>se Richtlinien finden<br />
Sie im Gruppenrichtlinien-Editor unter Computerkonfiguration\Administrative Vorlagen\<br />
System\Geräteinstallation\Einschränkungen bei der Geräteinstallation. Innerhalb dieser<br />
computerspezifischen Richtlinie können Sie Gerätesetupklassen definieren, deren Installation<br />
erlaubt oder verboten ist. Oder Sie können ganz verbieten, dass irgendwelche Wechseldatenträgergeräte<br />
installiert werden. Beachten Sie, dass dieser Richtlinienbereich verhindern<br />
soll, dass überhaupt Gerätetreiber installiert werden. Falls bereits ein Gerätetreiber für ein<br />
bestimmtes Gerät installiert ist, verhindert diese Richtlinie lediglich, dass dieser Treiber<br />
später aktualisiert wird.
Was ist neu bei Gruppenrichtlinien? 205<br />
Vorsicht Sie müssen sich im Klaren darüber sein, dass diese Geräteeinschränkungen nicht hundertprozentig<br />
verhindern können, dass Benutzer wichtige Daten weitergeben. Benutzer können Daten als E-Mail<br />
versenden. Falls sie Administratoren auf ihrem Computer sind oder physischen Zugriff auf ihre Arbeitsstationen<br />
haben, finden sie sicherlich immer Wege, an Daten zu gelangen, die sie eigentlich nicht bekommen<br />
sollten. <strong>Die</strong> beste Lösung besteht darin, sicherzustellen, dass die Daten, die Sie wirklich schützen wollen,<br />
mit einer robusten Zugriffssteuerung versehen sind!<br />
Was ist denn nun eine Gerätesetupklasse und wie können Sie damit verhindern, dass zum<br />
Beispiel ein USB-Speicherstick installiert wird? Jedes Gerät, das auf einem <strong>Windows</strong>-System<br />
installiert wird, hat eine eindeutige Geräteklasse-ID. <strong>Die</strong>se ID ist eine GUID, die den<br />
Typ des Geräts angibt. Sie finden die Geräte-ID heraus, indem Sie das <strong>Die</strong>nstprogramm<br />
Geräte-Manager starten (über die Systemsteuerung) und dort das Gerät suchen, das Sie<br />
einschränken wollen. Klicken Sie mit der rechten Maustaste auf das Gerät, wählen Sie<br />
den Befehl Eigenschaften und klicken Sie auf die Registerkarte Details. Wählen Sie in<br />
der Dropdownliste Eigenschaft den Eintrag Geräteklasse-GUID aus (Abbildung 7.11).<br />
Abbildung 7.11 Ermitteln der Geräteklasse für ein USB-Flashlaufwerk<br />
Sie können nun im Feld Wert mit der rechten Maustaste auf die GUID klicken und den<br />
Befehl Kopieren wählen, um sie in die Zwischenablage zu kopieren.<br />
Sobald Sie die GUID haben, können Sie die Richtlinie unter Computerkonfiguration\<br />
Administrative Vorlagen\System\Geräteinstallation\Einschränkungen bei der Geräteinstallation\Installation<br />
von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen<br />
entsprechen aktivieren und die GUID in das Dialogfeld für diese Richtlinie<br />
eingeben (Abbildung 7.12).
206 Kapitel 7: Gruppenrichtlinien<br />
Abbildung 7.12 Eingeben der Geräteklasse in eine Richtlinie für Geräteinschränkungen<br />
Sie haben jetzt also die Installation neuer USB-Flashlaufwerke auf Ihren <strong>Windows</strong> Vista-<br />
und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Computern eingeschränkt. Aber was ist, falls Benutzer bereits<br />
vorher Speichersticks installiert haben und Sie verhindern wollen, dass sie irgendwelche<br />
Daten auf diese Laufwerke schreiben? Sie können in diesem Fall die Richtlinien unter<br />
Computerkonfiguration\Administrative Vorlagen\System\Wechselmedienzugriff (oder dieselbe<br />
Richtlinie unter Benutzerkonfiguration) verwenden, um dieses Verhalten zu steuern. Indem<br />
Sie die Richtlinie Wechseldatenträger: Schreibzugriff verweigern aktivieren, können<br />
Sie verhindern, dass auf dem Computer auf irgendwelche installierten Wechsellaufwerke<br />
geschrieben wird. Allerdings können davon neben USB-Flashlaufwerken auch Datensicherungs-<br />
oder Speichergeräte betroffen sein, die von der IT-Abteilung der Organisation benutzt<br />
werden. Das kann ein Problem sein. In solchen Fällen können Sie die Richtlinie Benutzerdefinierte<br />
Klassen: Schreibzugriff verweigern verwenden, um nur bestimmte Geräteklassen<br />
einzuschränken. Auch bei dieser Richtlinie müssen Sie wieder die Geräteklasse-GUID<br />
eingeben, die Sie vorher im Geräte-Manager ermittelt haben.<br />
Warnung Wenn Sie eine Wechselmedienzugriff-Richtlinie auf einen Computer oder Benutzer anwenden,<br />
während der Benutzer bereits sein Wechselmediengerät eingesteckt hat und mit seinem <strong>Windows</strong> Vista-<br />
System arbeitet, wird die Richtlinie üblicherweise erst wirksam, wenn er dieses Gerät entfernt und erneut<br />
anschließt.<br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong><br />
Vor <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> konnten <strong>Sicherheit</strong>skonfigurationsaufgaben<br />
im Netzwerk, zum Beispiel das Verwalten von <strong>Windows</strong>-Firewall oder IPsec-Richtlinie,<br />
zwar mithilfe von Gruppenrichtlinien erledigt werden, dabei musste aber für jede Aufgabe<br />
eine eigene Benutzeroberfläche verwendet werden. Jetzt wurden die Gruppenrichtlinien so<br />
verbessert, dass sie eine einheitliche Benutzeroberfläche zum Verwalten dieser Einstellungen<br />
bereitstellen. So können Sie <strong>Server</strong>- und Domänenisolierungsregeln deutlich übersichtlicher<br />
erstellen. Sie finden diese Benutzeroberfläche unter Computerkonfiguration\<strong>Windows</strong>-
Was ist neu bei Gruppenrichtlinien? 207<br />
Einstellungen\<strong>Sicherheit</strong>seinstellungen\<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong>. Sie<br />
fasst die Verwaltung von <strong>Windows</strong>-Firewallregeln mit der Erstellung von IPsec-Richtlinien<br />
zusammen, sodass Sie umfassende Möglichkeiten zur Verwaltung von Endpunkt-zu-Endpunkt-Netzwerksicherheit<br />
erhalten.<br />
Hinweis Zur <strong>Windows</strong>-Firewall finden Sie ausführlichere Informationen in Kapitel 5, »Firewall und Netzwerkzugriffsschutz«.<br />
Als Erstes dürfte Ihnen an diesem neuen Richtlinienbereich auffallen, dass Sie damit sowohl<br />
ausgehende als auch eingehende Regeln definieren können (Abbildung 7.13). <strong>Die</strong>s ist ein<br />
Unterschied gegenüber der früheren <strong>Windows</strong>-Firewallkonfiguration.<br />
Abbildung 7.13 Anzeigen der Regeln für die <strong>Windows</strong>-Firewallkonfiguration<br />
Außerdem stellt die neue <strong>Windows</strong>-Firewall ein Profilsystem zur Verfügung. <strong>Die</strong> <strong>Windows</strong>-<br />
Firewall in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> umfasst jetzt die folgenden drei Profile:<br />
Domänenprofil <strong>Die</strong>ses Profil wird angewendet, wenn der Computer mit dem Netzwerk<br />
verbunden ist, in dem sein Active Directory-Computerkonto liegt.<br />
Privates Profil <strong>Die</strong>ses Profil wird angewendet, wenn der Computer an ein Netzwerk<br />
angeschlossen ist, das ein lokaler Administrator als privat einstuft.<br />
Öffentliches Profil <strong>Die</strong>ses Profil wird auf alle Netzwerke angewendet, für die nicht<br />
das Domänen- oder private Profil gilt. Darunter fallen auch alle Netzwerke, die noch<br />
keiner Kategorie zugeordnet wurden.<br />
Sie können mithilfe von Gruppenrichtlinien unterschiedliche Stufen von Firewalleinschränkungen<br />
konfigurieren, je nachdem, mit welchem Profil der Computer gerade arbeitet. Beachten<br />
Sie, dass sich diese Richtlinien im Abschnitt Computerkonfiguration der Gruppenrichtlinien<br />
befinden, sie werden also nur auf Computerkonten angewendet. Wenn die Richt-
208 Kapitel 7: Gruppenrichtlinien<br />
linie auf den Computer angewendet wird, werden alle definierten Profile auf dem Computer<br />
gespeichert. Falls sich die Netzwerkbedingungen ändern, wird das entsprechende Profil<br />
aktiv. So kann der Computer während der Gruppenrichtlinienverarbeitung Firewallanweisungen<br />
erhalten und braucht keinen Kontakt mit einem Domänencontroller herzustellen,<br />
während er von einem Netzwerk ins andere verlegt wird. Wenn sich der Netzwerkzustand<br />
ändert, wird ermittelt, ob es sich um ein Domänen-, privates oder öffentliches Netzwerk<br />
handelt, und das passende Profil wird aktiviert.<br />
Hinweis Der Gruppenrichtlinien-Editor in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthält weiterhin im<br />
Abschnitt Administrative Vorlagen der Gruppenrichtlinien den Knoten <strong>Windows</strong>-Firewall. <strong>Die</strong>se »alten«<br />
Richtlinien werden auf <strong>Windows</strong> XP und <strong>Windows</strong> <strong>Server</strong> 2003 angewendet. Falls Sie diese alten Richtlinien<br />
auf <strong>Windows</strong> Vista- oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Systeme anwenden, sind die Ergebnisse nicht vorhersagbar,<br />
weil es keine 1:1-Zuordnung zwischen alten und neuen <strong>Windows</strong>-Firewallfeatures gibt.<br />
IPsec-Konfiguration<br />
Im Abschnitt Verbindungssicherheitsregeln des Richtlinienknotens <strong>Windows</strong>-Firewall mit<br />
erweiterter <strong>Sicherheit</strong> können Sie IPsec-Richtlinien definieren. Im Unterschied zur alten<br />
Methode beim Definieren dieser Richtlinien stellt die neue Benutzeroberfläche einen intuitiven<br />
Assistenten zur Verfügung, der Sie durch die Entscheidungen leitet, die Sie treffen<br />
müssen, um eine IPsec-Beziehung zwischen Computern zu definieren. Wenn Sie eine IPsec-<br />
Beziehung zwischen Computer A und Computer B definieren, sollten beide Computerkonten<br />
in Active Directory vorhanden sein, damit das GPO verarbeitet werden kann, das die IPsec-<br />
Anweisungen ausliefert; schließlich verwenden wir ja Gruppenrichtlinien, um diese Richtlinien<br />
zu konfigurieren und auszuliefern. Wie <strong>Windows</strong>-Firewallregeln werden IPsec-Regeln<br />
auf Basis der drei Profile angewendet. Sie können festlegen, dass eine IPsec-Regel nur dann<br />
wirksam wird, wenn der Computer mit einem bestimmten Netzwerktyp verbunden ist.<br />
Richtlinien für verkabelte und Drahtlosnetzwerke<br />
<strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bringen Verbesserungen und neue Fähigkeiten<br />
mit, die Ihnen die Verwaltung des Schutzes von Drahtlos- und Kabelnetzwerken über Gruppenrichtlinien<br />
erleichtern. Im Gruppenrichtlinien-Editor finden Sie einen neuen Richtlinienknoten<br />
unter Computerkonfiguration\<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\Richtlinien<br />
für verkabelte Netzwerke (IEEE 802.3) und einen aktualisierten Satz von Richtlinien<br />
für Drahtlosnetzwerke unter Computerkonfiguration\<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\Drahtlosnetzwerkrichtlinien<br />
(IEEE 802.11).<br />
Richtlinien für verkabelte Netzwerke<br />
Mit Richtlinien für verkabelte Netzwerke können Sie 802.1x-Authentifizierung für Ihre<br />
Computer erzwingen, die über Ethernet-Netzwerke kommunizieren. Sie können die Verwendung<br />
von 802.1x erzwingen und festlegen, welche Netzwerkauthentifizierungsmethode<br />
eingesetzt werden muss (Abbildung 7.14).<br />
Falls Sie sicherstellen wollen, dass ganze Gruppen von Computern im Netzwerk über 802.1x<br />
kommunizieren, müssen Sie wie bei der IPsec-Richtlinie sicherstellen, dass die Gruppenrichtlinien,<br />
in denen diese Einstellungen enthalten sind, von allen Computern verarbeitet<br />
werden, die an dieser Authentifizierungsrichtlinie beteiligt sind.
Abbildung 7.14 Konfigurieren der Richtlinien für<br />
verkabelte Netzwerke bei <strong>Windows</strong> Vista<br />
Was ist neu bei Gruppenrichtlinien? 209<br />
Richtlinien für Drahtlosnetzwerke<br />
Drahtlosnetzwerkrichtlinien wurden erstmals in <strong>Windows</strong> <strong>Server</strong> 2003 eingeführt. Allerdings<br />
konnten damit nur wenige Einschränkungen definiert werden, um zu steuern, mit welchen<br />
Drahtlosnetzwerken ein Computer eine Verbindung herstellt. Bei den neuen Drahtlosrichtlinien<br />
in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> stehen Ihnen nun mehr Möglichkeiten<br />
zur Verfügung, um den Zugriff auf Drahtlosnetzwerke zu sperren und zu steuern, welche<br />
Verschlüsselungs- und Authentifizierungsmethoden für ein bestimmtes Drahtlosnetzwerk<br />
eingesetzt werden müssen.<br />
<strong>Die</strong> wichtigste Änderung an der Drahtlosnetzwerkrichtlinie ist die Unterstützung für das<br />
Erstellen von Profilen. Mit Profilen können Sie Gruppen von Netzwerk-SSIDs konfigurieren,<br />
zu denen Ihre Computer eine Verbindung aufbauen dürfen (Abbildung 7.15).<br />
Ein Profil hat die Aufgabe, Drahtlosnetzwerke zusammenzufassen, die ähnliche Authentifizierungs-<br />
und Verschlüsselungsanforderungen haben. <strong>Die</strong> Drahtlosrichtlinie in <strong>Windows</strong><br />
Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> unterstützt folgende Authentifizierungsmethoden:<br />
Offen: Authentifizierung ohne Verschlüsselung. Kann optional WEP-Verschlüsselung<br />
(Wired Equivalent Privacy) nutzen.<br />
Gemeinsam verwendet: Ähnlich wie Offen, verwendet aber einen gemeinsamen WEP-<br />
Schlüssel.<br />
WPA-Enterprise: Authentifizierung über WPA-Verschlüsselung (Wi-Fi Protected<br />
Access) mit 802.1x-Authentifizierung<br />
WPA-Personal: Authentifizierung über WPA mit einem gemeinsamen geheimen Schlüssel<br />
WPA2-Enterprise: Authentifizierung über WPA-2-Verschlüsselung (Wi-Fi Protected<br />
Access Version 2) mit 802.1x-Authentifizierung
210 Kapitel 7: Gruppenrichtlinien<br />
WPA2-Personal: Authentifizierung über WPA-2 mit einem gemeinsamen geheimen<br />
Schlüssel<br />
Offen bei 802.1X: Verwendet WEP mit 802.1x-Authentifizierung.<br />
Abbildung 7.15 Konfigurieren von Drahtlosprofilen, sodass<br />
Verbindungen zu bekannten SSIDs hergestellt werden können<br />
Abbildung 7.16 Mithilfe von Netzwerkberechtigungen können Sie<br />
den Zugriff auf bestimmte Drahtloszugriffspunkte verhindern
Verwalten von <strong>Sicherheit</strong>seinstellungen 211<br />
Sie können außerdem sogenannte Netzwerkberechtigungen für Drahtlosnetzwerke definieren,<br />
die nicht explizit innerhalb Ihrer Profile definiert sind. Nehmen wir zum Beispiel an,<br />
Sie wissen, dass es ein öffentliches Drahtlosnetzwerk mit der SSID »Kostenloses WLAN«<br />
gibt, zu dem Ihre Benutzer keine Verbindung herstellen sollen. Sie können nun auf der Registerkarte<br />
Netzwerkberechtigungen innerhalb der Drahtlosrichtlinie eine Netzwerkberechtigung<br />
definieren, um zu verhindern, dass diese SSID benutzt wird (Abbildung 7.16).<br />
Neben diesen Verbesserungen bei der Verwaltung von <strong>Sicherheit</strong>seinstellungen gibt es eine<br />
Reihe von neuen <strong>Sicherheit</strong>srichtlinieneinstellungen, mit denen Sie Ihre <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong>- und <strong>Windows</strong> Vista-Systeme besser schützen können. Viele dieser Einstellungen sind<br />
in etlichen Szenarien sehr nützlich, bei einigen wird aber davor gewarnt, dass sie Probleme<br />
bei der Systemadministration und der Interoperabilität mit älteren <strong>Windows</strong>-Versionen verursachen<br />
können. <strong>Die</strong>se Einstellungen sehen wir uns im nächsten Abschnitt an.<br />
Verwalten von <strong>Sicherheit</strong>seinstellungen<br />
Wenn Sie den Gruppenrichtlinien-Editor starten und den Knoten Computerkonfiguration\<br />
<strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\Lokale Richtlinien öffnen, sehen Sie einige<br />
Richtlinienknoten (Zuweisen von Benutzerrechten und <strong>Sicherheit</strong>soptionen), die eine Reihe<br />
von Einstellungen zum Schützen Ihrer <strong>Windows</strong>-Systeme bereitstellen. Wie bei jeder <strong>Sicherheit</strong>sentscheidung<br />
müssen Sie eine Balance zwischen der gewünschten <strong>Sicherheit</strong>sstufe und<br />
dem Verlust an Funktionalität oder Verwaltbarkeit finden. Bei vielen Einstellungen innerhalb<br />
dieser zwei Richtlinienbereiche müssen Sie diese zwei Seiten gegeneinander abwägen,<br />
bevor Sie die Richtlinie implementieren. Glücklicherweise stellt Microsoft seit <strong>Windows</strong><br />
<strong>Server</strong> 2003 SP1 innerhalb jedes Richtlinienelements Warnungen bereit, die auf mögliche<br />
Auswirkungen einer Einstellung aufmerksam machen. Tabelle 7.1 listet einige der wichtigsten<br />
Risiken und Vorteile dieser Einstellungen auf.<br />
Tabelle 7.1 Risiken und Vorteile von Einstellungen zur <strong>Sicherheit</strong>shärtung<br />
Richtlinie Vorteil Risiko<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ Zuweisen von<br />
Benutzerrechten\ Auf diesen<br />
Computer vom Netzwerk aus<br />
zugreifen und Zugriff vom<br />
Netzwerk auf diesen Computer<br />
verweigern<br />
Mit diesen Rechten können Sie steuern,<br />
wer im Remotezugriff auf einen Computer<br />
zugreifen darf. Das umfasst Operationen<br />
wie Domänencontroller-zu-<br />
Domänencontroller-Replikation, Benutzerauthentifizierung<br />
an Domänencontrollern,<br />
Remoteverwaltung und Benutzerzugriff<br />
auf freigegebene Ressourcen.<br />
Falls Sie die falschen Gruppen aus<br />
diesen Rechten entfernen, ist kein<br />
Zugriff auf die Systeme mehr möglich.<br />
Zum Beispiel dürfen Sie keinesfalls der<br />
Gruppe Domänencontroller der Organisation<br />
das Zugriffsrecht entziehen oder<br />
sie zum Verweigern-Recht hinzufügen.<br />
Falls Sie der Gruppe Authentifizierte<br />
Benutzer das Zugriffsrecht entziehen,<br />
müssen Sie sicherstellen, dass eine<br />
ähnliche Gruppe dieses Recht hat.<br />
Löschen Sie nie alle Benutzer und<br />
Gruppen aus diesen Rechten,<br />
und verweigern Sie nie allen Benutzern<br />
und Gruppen diese Rechte.
212 Kapitel 7: Gruppenrichtlinien<br />
Richtlinie Vorteil Risiko<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ Zuweisen von<br />
Benutzerrechten\ Lokal anmelden<br />
zulassen und Lokal anmelden<br />
verweigern<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ Zuweisen von<br />
Benutzerrechten\ Auslassen<br />
der durchsuchenden Überprüfung<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ Zuweisen von<br />
Benutzerrechten\ Ermöglichen,<br />
dass Computer- und Benutzerkonten<br />
für Delegierungszwecke<br />
vertraut wird<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Domänenmitglied: Daten<br />
des sicheren Kanals digital<br />
verschlüsseln oder signieren<br />
(immer)<br />
Mit diesem Recht können Sie steuern,<br />
wer sich an der Konsole des Computers<br />
anmelden darf, der diese Richtlinie<br />
verarbeitet.<br />
<strong>Die</strong>ses Recht erlaubt es einem Benutzer,<br />
NTFS-Ordner zu durchlaufen, ohne<br />
dass die Berechtigungen für Ordner<br />
höher in der Ordnerhierarchie geprüft<br />
werden, um festzustellen, ob sie Rechte<br />
zum Durchsuchen des Ordners gewähren.<br />
<strong>Die</strong>ses Recht wird normalerweise<br />
allen Benutzern gewährt. Es erlaubt<br />
ihnen, Ordner (aber nicht den Ordnerinhalt)<br />
zu durchsuchen, selbst wenn sie<br />
keine Zugriffsrechte auf übergeordnete<br />
Ordner haben. <strong>Die</strong>s ist ein grundlegendes<br />
Recht, das alle Benutzer brauchen,<br />
um selbst einfache Aufgaben durchführen<br />
zu können.<br />
Erlaubt es einem Benutzer, einem Computer,<br />
einem <strong>Die</strong>nst, der als Computer<br />
läuft, oder einem Benutzer das Recht zu<br />
gewähren, die Identität eines Benutzerkontos<br />
anzunehmen, um auf Ressourcen<br />
in einem anderen System zuzugreifen.<br />
Erzwingt, dass die gesamte Kommunikation,<br />
die zwischen Arbeitsstationen<br />
oder Mitgliedservern und ihren Domänencontroller<br />
durch einen sicheren<br />
Kanal befördert wird, verschlüsselt oder<br />
signiert sein muss.<br />
Passen Sie auf, wenn Sie einer bestimmten<br />
Gruppe das Zugriffsrecht<br />
entziehen oder einer bestimmten Gruppe<br />
den Zugriff verweigern. Zum Beispiel<br />
dürfen Sie die administrativen Konten<br />
oder Gruppen nur dann aus dem Recht<br />
entfernen, wenn Sie tatsächlich verhindern<br />
wollen, dass sie sich an der Konsole<br />
anmelden können. Verhindern Sie<br />
nicht, dass <strong>Die</strong>nstkonten dieses Recht<br />
haben, weil sie es brauchen, um sich an<br />
einem System anzumelden.<br />
Wenn Sie der Gruppe Jeder oder anderen<br />
nichtadministrativen Benutzer dieses<br />
Recht entziehen, können sie nicht mehr<br />
in NTFS-Ordnerstrukturen arbeiten.<br />
Wenn Sie dieses Recht für eine bestimmte<br />
Gruppe aktivieren, kann diese<br />
Gruppe Computerobjekte in Active<br />
Directory als vertrauenswürdig für Delegierungszwecke<br />
kennzeichnen. Das<br />
kann diese Systeme für Angriffe verwundbar<br />
machen, bei denen ein Trojanisches<br />
Pferd die Identität eines Benutzers<br />
vortäuscht.<br />
Falls es in einer Domäne Domänencontroller<br />
gibt, die Daten in einem sicheren<br />
Kanal nicht verschlüsseln oder signieren<br />
können (zum Beispiel Domänencontroller,<br />
die unter NT 4.0 vor SP 6a laufen),<br />
können sich Clients, die mit dieser Einstellung<br />
konfiguriert sind, nicht an der<br />
Domäne authentifizieren, wenn sie auf<br />
diese Domänencontroller zugreifen.
Richtlinie Vorteil Risiko<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Microsoft-Netzwerk<br />
(Client): Kommunikation digital<br />
signieren (immer)<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Microsoft-Netzwerk (<strong>Server</strong>):<br />
Kommunikation digital<br />
signieren (immer)<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Domänenmitglied: Starker<br />
Sitzungsschlüssel erforderlich<br />
(<strong>Windows</strong> 2000 oder höher)<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Domänencontroller: Signaturanforderungen<br />
für LDAP-<br />
<strong>Server</strong><br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Netzwerksicherheit: Signaturanforderungen<br />
für LDAP-<br />
Clients<br />
Erzwingt, dass ein Client, der mit<br />
einem SMB-v1-<strong>Server</strong> (<strong>Server</strong> Message<br />
Block) wegen einer Dateifreigabe kommuniziert,<br />
SMB-Signierung verpflichtend<br />
macht. Das hilft, Angriffe zu verhindern,<br />
die eine Sitzung entführen.<br />
<strong>Die</strong>s funktioniert genauso wie beim<br />
Client im vorherigen Eintrag, allerdings<br />
wird hier garantiert, dass die SMB-<br />
<strong>Server</strong> Kommunikation mit Clients immer<br />
signieren.<br />
Erzwingt 128-Bit-Verschlüsselung für<br />
Kommunikation über einen sicheren<br />
Kanal zwischen Clients, auf die diese<br />
Richtlinie angewendet wird, und Domänencontrollern.<br />
Wenn diese Einstellung auf einen Domänencontroller<br />
angewendet wird,<br />
erzwingt sie, dass der Domänencontroller<br />
für die Kommunikation mit LDAP-<br />
Clients LDAP-Datensignierung verwendet,<br />
um Man-in-the-Middle-Angriffe zu<br />
verhindern.<br />
Wenn diese Einstellung auf einen Computer<br />
angewendet wird, erzwingt sie,<br />
dass der Client für die Kommunikation<br />
mit allen LDAP-<strong>Server</strong>n LDAP-Datensignierung<br />
verwendet, um Man-in-the-<br />
Middle-Angriffe zu verhindern.<br />
Verwalten von <strong>Sicherheit</strong>seinstellungen 213<br />
Falls der Client so konfiguriert ist, dass<br />
er immer SMB-Signierung verwendet,<br />
der <strong>Server</strong> dies aber nicht unterstützt<br />
oder erlaubt, schlägt die SMB-Kommunikation<br />
zwischen Client und <strong>Server</strong> fehl.<br />
Falls ein SMB-<strong>Server</strong> immer die Signierung<br />
erfordert, der Client dies aber nicht<br />
unterstützt, kann der Client nicht mit<br />
dem <strong>Server</strong> kommunizieren. Zum Beispiel<br />
bieten ältere <strong>Windows</strong>-Versionen<br />
und Nicht-Microsoft-SMB-Clients keine<br />
Unterstützung für SMB-Signierung.<br />
Beachten Sie, dass das Netzwerk langsamer<br />
werden kann, falls Sie diese<br />
Einstellung aktivieren. Weitere Informationen<br />
finden Sie in http://support.microsoft.com/kb/823659.<br />
Setzt voraus, dass alle Domänencontroller<br />
mindestens unter <strong>Windows</strong> 2000<br />
laufen, andernfalls schlägt die Kommunikation<br />
über den sicheren Kanal fehl.<br />
Manche LDAP-Clients, zum Beispiel<br />
<strong>Windows</strong> 2000 vor Service Pack 3,<br />
unterstützen dies nicht. Auch Nicht-<br />
<strong>Windows</strong>-LDAP-Clients bieten oft keine<br />
Unterstützung dafür.<br />
Falls Domänencontroller nicht mit denselben<br />
Einstellungen konfiguriert sind,<br />
schlägt jegliche LDAP-Kommunikation<br />
zwischen Client und Domänencontroller<br />
fehl.
214 Kapitel 7: Gruppenrichtlinien<br />
Richtlinie Vorteil Risiko<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Netzwerkzugriff: Anonyme<br />
SID-/<br />
Namensübersetzung zulassen<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Netzwerkzugriff: Anonyme<br />
Aufzählung von SAM-Konten<br />
und Freigaben nicht erlauben<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Netzwerksicherheit: LAN<br />
Manager-<br />
Authentifizierungsebene<br />
Computerkonfiguration\ <strong>Windows</strong>-Einstellungen\<strong>Sicherheit</strong>seinstellungen\<br />
Lokale<br />
Richtlinien\ <strong>Sicherheit</strong>soptionen\<br />
Überwachung: System<br />
sofort herunterfahren, wenn<br />
<strong>Sicherheit</strong>süberprüfungen<br />
nicht protokolliert werden<br />
können<br />
<strong>Die</strong>se Richtlinie wird in den meisten<br />
sicheren Konfigurationen deaktiviert.<br />
Wird sie aktiviert, kann ein anonymer<br />
Benutzer eine SID in einen Benutzernamen<br />
konvertieren. (Falls zum Beispiel<br />
ein anonymer Benutzer die bekannte<br />
SID des Administratorkontos angibt,<br />
kann dieser Benutzer den wirklichen<br />
Kontoname herausfinden, sogar wenn<br />
das Konto umbenannt wurde.)<br />
Wenn diese Richtlinie aktiviert ist, können<br />
anonyme Benutzer keine Liste der<br />
Benutzernamen in einer Domäne erhalten,<br />
die sich für verschiedene Angriffe<br />
nutzen lässt.<br />
Legt fest, welche Version der NTLM-<br />
Authentifizierung auf Computern erforderlich<br />
ist, die diese Richtlinie verarbeiten.<br />
Wenn Sie diese Richtlinie aktivieren,<br />
stellen Sie sicher, dass das System<br />
herunterfährt, falls irgendetwas verhindert,<br />
dass eine <strong>Sicherheit</strong>süberwachung<br />
generiert wird (falls zum Beispiel das<br />
<strong>Sicherheit</strong>sprotokoll voll ist).<br />
Falls diese Richtlinie aktiviert ist, funktionieren<br />
ältere <strong>Windows</strong>-Systeme, die<br />
diese anonyme Übersetzungsfähigkeit<br />
benötigen, möglicherweise nicht mehr.<br />
Das sind zum Beispiel der RAS-<strong>Die</strong>nst<br />
aus NT 4.0 und SQL <strong>Server</strong> in NT 3.x-<br />
oder 4.0-Domänen. Falls Sie aber solche<br />
Systeme in Ihrer Umgebung haben,<br />
sollten Sie ohnehin als Erstes sicherstellen,<br />
dass sie mit keinen anderen Systemen<br />
kommunizieren dürfen!<br />
Falls Sie diese Richtlinie auf Ebene<br />
einer Domäne deaktivieren, können Sie<br />
kein Domänenvertrauen mit NT 4.0-<br />
Domänen herstellen. (Glauben Sie mir:<br />
Das wollen Sie ohnehin nicht.)<br />
Bestimmte Stufen der NTLM-Authentifizierung<br />
(zum Beispiel v2) werden auf<br />
älteren <strong>Windows</strong>-Clients nicht unterstützt,<br />
zum Beispiel in NT 4.0 vor Service<br />
Pack 4 oder <strong>Windows</strong> 95 und <strong>Windows</strong><br />
98 ohne installierten Verzeichnisdienstclient.<br />
Heutzutage sollten eigentlich<br />
alle Computer funktionieren, wenn<br />
Sie diese Einstellung auf den Wert 5<br />
setzen (die sicherste Einstellung).<br />
Falls Sie diese Richtlinie aktivieren, aber<br />
keine automatische Überschreibung der<br />
Überwachungsprotokolle erlauben,<br />
wenn sie voll sind, oder die Protokolle<br />
zu klein sind, fährt das System herunter,<br />
sobald das Protokoll voll ist! Angreifer<br />
können diese Möglichkeit nutzen, um Ihr<br />
Netzwerk stillzulegen (das wurde in der<br />
Vergangenheit bereits praktiziert).<br />
Zusammenfassung<br />
In diesem Kapitel haben wir uns angesehen, wie Gruppenrichtlinien in lokalen und Active<br />
Directory-Umgebungen verwendet werden, wie Sie GPOs auf unterschiedlichen Ebenen in<br />
der Active Directory-Hierarchie verknüpfen und wie Sie mithilfe von <strong>Sicherheit</strong>sgruppen-<br />
und WMI-Filterung genauer steuern, auf welche Computer und Benutzer eine Richtlinie<br />
angewendet wird.<br />
Wir haben auch einige der neuen Gruppenrichtlinien-Verwaltungsfunktionen kennengelernt,<br />
die in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> neu eingeführt wurden, darunter Starter-Gruppenrichtlinienobjekte,<br />
Kommentare und Filterung. Wir haben einige der neuen Richtlinienbereiche unter-
Weitere Informationen 215<br />
sucht, die in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> neu zur Verfügung stehen, insbesondere<br />
solche, die mit der <strong>Sicherheit</strong> zu tun haben, zum Beispiel Geräteeinschränkungen, die<br />
die Verwendung von Wechselmedien, die zusammengefassten <strong>Windows</strong>-Firewall- und<br />
IPsec-Konfigurationsrichtlinien sowie Richtlinien für verkabelte und Drahtlosnetzwerke<br />
steuern.<br />
Zuletzt haben wir eine Reihe von Einstellungen für die <strong>Sicherheit</strong>shärtung innerhalb der<br />
Gruppenrichtlinien untersucht und uns genau angesehen, welche Einstellungen Kompatibilitätsprobleme<br />
verursachen können, insbesondere wenn ältere <strong>Windows</strong>-Versionen oder<br />
Nicht-<strong>Windows</strong>-Systeme beteiligt sind.<br />
Weitere Informationen<br />
<strong>Windows</strong> Group Policy Resource Kit: <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> and <strong>Windows</strong> Vista von<br />
Microsoft Press.<br />
»What Is New in Group Policy in <strong>Windows</strong> Vista« unter http://technet2.microsoft.com/<br />
<strong>Windows</strong>Vista/en/library/a8366c42-6373-48cd-9d11-2510580e48171033.mspx?mfr=true.<br />
»Virtual Lab: Managing <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> and <strong>Windows</strong> Vista Using Group Policy«<br />
unter http://go.microsoft.com/fwlink/?linkid=92472.<br />
»Managing Group Policy ADMX Files Step-by-Step Guide« unter http://technet2.<br />
microsoft.com/windowsvista/en/library/02633470-396c-4e34-971a-0c5b090dc4fd<br />
1033.mspx.<br />
»Security Group Policy Settings in <strong>Windows</strong> Vista« unter http://technet.microsoft.com/<br />
en-us/bb679962.aspx.
K A P I T E L 8<br />
Überwachung<br />
Von Eric Fitzgerald<br />
In diesem Kapitel:<br />
Wozu überwachen? . ................................................. 218<br />
So funktioniert die <strong>Windows</strong>-Überwachung .................................. 218<br />
Festlegen einer Überwachungsrichtlinie .................................... 221<br />
Entwerfen einer guten Überwachungsrichtlinie . ............................... 229<br />
Neue Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> . .................................. 230<br />
Analysieren von Ereignissen mit den eingebauten Tools ......................... 236<br />
Zusammenfassung .................................................. 242<br />
Im Bereich der Computersicherheit bedeutet der Begriff Überwachung (engl. auditing)<br />
meist, dass etwas mit einem Standard oder Grundwert verglichen wird (»die Wirksamkeit<br />
der <strong>Sicherheit</strong>skontrollen in der Organisation überwachen«), oder dass sicherheitsrelevante<br />
Ereignisse aufgezeichnet werden (»Überwachungsliste«). In diesem Kapitel verwenden wir<br />
Überwachung im zweiten Sinn, es wird also etwas aufgezeichnet.<br />
Seit der Einführung von <strong>Windows</strong> NT ist das <strong>Sicherheit</strong>sereignisprotokoll oft eine Quelle<br />
der Frustration für <strong>Windows</strong> <strong>Server</strong>-Administratoren. Das <strong>Sicherheit</strong>sereignisprotokoll enthält<br />
zwar viele Informationen darüber, welche <strong>Sicherheit</strong>sentscheidungen <strong>Windows</strong> trifft<br />
und welche kritischen System- und Benutzeraktivitäten sich auf die Systemsicherheit auswirken<br />
können, aber da sich Überwachungsrichtlinien nicht fein genug steuern ließen, entstanden<br />
riesige Mengen an Protokolleinträgen. Auch lieferten die Auswahl der Ereignisse,<br />
die Microsoft überwachte, und die Informationen, die in diesen Ereignisprotokollen angezeigt<br />
wurden, nicht immer die Antworten, die Administratoren wirklich brauchten.<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wurde das Überwachungssubsystem in etlichen Punkten verbessert,<br />
sodass es für Administratoren viel nützlicher geworden ist. Überwachungsrichtlinien<br />
wurden erweitert, sodass es viel einfacher ist, genau die Ereignisse auszuwählen, für die Sie<br />
sich interessieren. Das Format von Überwachungsereigniseinträgen und ihr Inhalt wurden<br />
verbessert, sodass es Ihnen leichter fallen wird, die Ereignisse im <strong>Sicherheit</strong>sprotokoll zu<br />
verstehen. Viel mehr Ereignisse lösen die Protokollierung von Überwachungsereignissen<br />
aus. Und schließlich beseitigen Verbesserungen am Ereignissubsystem und den zugehörigen<br />
Tools viele Skalierbarkeits-, Leistungs- und Analyseprobleme, mit denen Sie früher zu<br />
kämpfen hatten.<br />
217
218 Kapitel 8: Überwachung<br />
Wozu überwachen?<br />
Beim Festlegen einer Richtlinie für die <strong>Sicherheit</strong>szugriffssteuerung müssen drei grundlegende<br />
Steuerungsgruppen betrachtet werden: Authentifizierung (engl. authentication), Autorisierung<br />
(engl. authorization) und Überwachung (engl. audit, manchmal auch als accounting,<br />
Kontoführung, bezeichnet). Zugriffssteuerung (siehe Kapitel 2, »Authentifizierung und<br />
Authentifizierungsprotokolle«) und Authentifizierung (siehe Kapitel 4, »Grundlagen der<br />
Benutzerkontensteuerung«) werden als präventive Kontrollen (engl. preventative control)<br />
eingeordnet. Sie sollen verhindern, dass etwas passiert, was Sie nicht erlaubt haben. Überwachung<br />
gilt als Erkennungskontrolle (engl. detective control); sie verhindert nichts, hinterlässt<br />
aber eine Spur, über die verfolgt werden kann, ob Ihre <strong>Sicherheit</strong>srichtlinie verletzt<br />
wurde und auf welche Weise.<br />
Erkennungskontrolle, zum Beispiel Überwachungslisten (engl. audit trail), liefert Beweise,<br />
dass Ihre präventiven Kontrollen funktionieren, selbst wenn Sie gerade nicht selbst alles<br />
überwachen. Sie können die Überwachungslisten jederzeit auswerten, um zu prüfen, ob die<br />
Tätigkeiten Ihrer Benutzer Ihren Absichten entsprechen.<br />
Überwachungslisten liefern auch nützliche forensische Beweise für den Fall, dass sie gebraucht<br />
werden. Es ist zu spät, wenn Sie Ihr System Protokolle generieren lassen, nachdem<br />
ein Vorfall aufgetreten ist. In einem solchen Fall wollen Sie Informationen über Dinge, die<br />
bereits passiert sind.<br />
Wenn Sie wissen, welche <strong>Sicherheit</strong>sentscheidungen das System trifft, kann Ihnen das auch<br />
bei der Problembehandlung helfen. Wenn die Fehlermeldung aus einem schlichten »Zugriff<br />
verweigert« besteht, ist es nützlich, wenn Sie für Diagnosezwecke noch eine andere Informationsquelle<br />
als die Fehlermeldung haben.<br />
Und schließlich sind sich fast alle einig, dass viele juristische und organisatorische Regelwerke<br />
die Aufzeichnung und Prüfung von Überwachungslisten vorschreiben. Zum Beispiel<br />
schreiben manche Regelwerke für den medizinischen Bereich vor, dass Organisationen, die<br />
Patientendaten sammeln und verarbeiten, sicherstellen müssen, dass nur autorisierte Personen<br />
auf die Daten zugreifen können. Es wäre schwierig für eine Organisation, die Wirksamkeit<br />
ihrer Zugriffssteuerung zu beurteilen, wenn keine Überwachungsliste verrät, wer tatsächlich<br />
auf die Patientendaten zugegriffen hat.<br />
So funktioniert die <strong>Windows</strong>-Überwachung<br />
Das <strong>Windows</strong>-Überwachungssubsystem arbeitet mit Komponenten zusammen, die <strong>Sicherheit</strong>sentscheidungen<br />
treffen, sowie mit dem Ereignisprotokolldienst, in dem zuverlässig<br />
<strong>Sicherheit</strong>sereignisse generiert werden. Komponenten, die <strong>Sicherheit</strong>sentscheidungen treffen<br />
(sogenannte <strong>Sicherheit</strong>sreferenzmonitore), benachrichtigen das Überwachungssubsystem,<br />
sobald eine <strong>Sicherheit</strong>sentscheidung getroffen wurde oder andere sicherheitsrelevante Aktivitäten<br />
stattfinden, und leiten die Details der Aktivität weiter. Das Überwachungssystem<br />
formatiert diese Daten als Ereigniseinträge so, dass die Daten einen einheitlichen Aufbau<br />
haben, und verwirft alle generierten Ereignisse, die laut den Überwachungsrichtlinien nicht<br />
aufgezeichnet werden sollen. <strong>Die</strong> übrigen Ereignisse werden an den Ereignisprotokolldienst<br />
gesendet, damit er sie im <strong>Sicherheit</strong>sprotokoll speichert. Abbildung 8.1 zeigt den Aufbau des<br />
Überwachungssubsystems in <strong>Windows</strong>.
Abbildung 8.1 Aufbau des <strong>Windows</strong>-Überwachungssubsystems<br />
So funktioniert die <strong>Windows</strong>-Überwachung 219<br />
Hinweis <strong>Die</strong> meisten <strong>Windows</strong>-Komponenten, die Überwachungsereignisse generieren, prüfen selbst die<br />
Überwachungsrichtlinien, bevor sie ein Ereignis an das Überwachungssubsystem melden. Das verhindert<br />
unnötigen Ressourcenverbrauch.<br />
Das <strong>Windows</strong>-Überwachungssubsystem ist im LSA-Prozess (Local Security Authority), der<br />
in der <strong>Windows</strong>-Prozessliste als Lsass.exe aufgeführt wird, und im <strong>Windows</strong>-Kernel implementiert.<br />
<strong>Die</strong> LSA enthält die Benutzermoduskomponenten von <strong>Windows</strong>, die die <strong>Sicherheit</strong>srichtlinie<br />
erzwingen und andere <strong>Sicherheit</strong>sfunktionen durchführen, zum Beispiel Authentifizierung.<br />
Komponenten wie zum Beispiel Authentifizierungspakete liegen innerhalb<br />
der LSA und liefern Ereignisse direkt an das Überwachungssubsystem. Komponenten, die<br />
im Benutzermodus außerhalb der LSA laufen, sind zum Beispiel die Active Directory-<br />
Domänendienste (Active Directory Domain Services, AD DS) und Anwendungen, die <strong>Windows</strong>-Überwachungs-APIs<br />
verwenden und Ereignisse über RPC an die LSA liefern. Der<br />
Kernel enthält eine generische Überwachungsschnittstelle, die von Kernelkomponenten wie<br />
zum Beispiel Treibern benutzt wird. Er enthält außerdem den Objekt-Manager, dem die<br />
Aufgabe zufällt, die meisten Objektzugriffsversuchsereignisse zu generieren. Ereignisse<br />
werden entweder über das Ereignisverfolgungsmodul des Kernels (ETW) oder über RPC an<br />
den Ereignisprotokolldienst übergeben. <strong>Die</strong> meisten Ereignisse, die im Kernel generiert<br />
werden, werden direkt an das ETW geliefert, aber Ereignisse, die aufwendiger formatiert<br />
werden müssen, werden für diese Aufgabe an die LSA weitergeleitet. <strong>Die</strong> LSA liefert die<br />
meisten Ereignisse über ETW an das Ereignisprotokoll, wobei sie den RPC-Kanal in erster<br />
Linie für Fälle verwendet, in denen Fehler in einem Teil des Überwachungssubsystems aufgetreten<br />
sind.
220 Kapitel 8: Überwachung<br />
Direkt von der Quelle: Verbesserungen am Ereignisprotokolldienst<br />
Das Ereignisprotokollmodul in <strong>Windows</strong> wurde für die Version 6.0 von <strong>Windows</strong> (<strong>Windows</strong><br />
Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>) von Grund auf neu geschrieben. <strong>Die</strong> Leistungs-<br />
und Skalierungsprobleme des alten Ereignisprotokollmoduls wurden weitgehend beseitigt.<br />
Wo beim alten Ereignisprotokolldienst die effektive Protokolldateigröße maximal<br />
4 GByte betrug (und deutlich weniger auf 32-Bit-Computern), können Protokolle im<br />
neuen <strong>Die</strong>nst jetzt bis zu 2 53 -1 Byte groß werden, das ist über 1 Petabyte. Und wo das alte<br />
Protokoll einen maximalen Durchsatz von wenigen Tausend Ereignissen pro Sekunde<br />
hatte, wenn es als zirkulär eingerichtet wurde, kann das neue Protokoll Zehntausende von<br />
Ereignissen pro Sekunde verarbeiten.<br />
Das neue Ereignisprotokollmodul macht Ereignisse im XML-Format verfügbar, sodass<br />
andere Anwendungen darauf zugreifen können. So können Ereignisse nicht nur selbstbeschreibend<br />
sein, sondern das Modul kann Ereignisse auch anhand von XPATH-Ausdrücken<br />
filtern. So ist eine Vielzahl von Filtermöglichkeiten in Anwendungen wie der Ereignisanzeige<br />
machbar. Außerdem können Abonnements sehr detailliert definiert werden,<br />
Überwachungsanwendungen können also ganz genau festlegen, welche Ereignisse sie<br />
interessieren.<br />
Eric Fitzgerald, Senior Program Manager Forefront Security<br />
Wie bereits erwähnt, stammen die meisten <strong>Sicherheit</strong>sereignisse (mit Ausnahme der Ereignisse<br />
über die Integrität des Überwachungssubsystems) aus Komponenten außerhalb des<br />
Überwachungssubsystems. Jedes Ereignis wird unter ganz bestimmten Bedingungen ausgelöst.<br />
Bei den meisten Ereignissen sind dies folgende Bedingungen:<br />
Eine überwachbare Aktivität ist aufgetreten.<br />
Überwachungsrichtlinien geben an, dass diese Aktivität protokolliert werden soll.<br />
In einem Fall gibt es noch eine dritte Voraussetzung. Ressourcenmanager sind eine spezielle<br />
Art von <strong>Sicherheit</strong>sreferenzmonitor, die den Zugriff auf einen Satz Objekte regeln. Wenn<br />
Ressourcenmanager die Anforderung für den Zugriff auf ein Objekt erhalten, prüfen sie<br />
nicht nur die Überwachungsrichtlinien, sondern vergleichen die Zugriffsanforderung auch<br />
mit den jeweiligen Überwachungseinstellungen des angeforderten Objekts. Wie in Kapitel 2<br />
beschrieben, haben Objekte in <strong>Windows</strong> eine <strong>Sicherheit</strong>sbeschreibung, die verschiedene<br />
Aspekte der objektspezifischen <strong>Sicherheit</strong>srichtlinie definiert. Teil der <strong>Sicherheit</strong>sbeschreibung<br />
ist die DACL (Discretionary Access Control List). <strong>Die</strong>s ist die Liste der Berechtigungen<br />
für das Objekt, bei dem die Zugriffsprüfung ausgeführt wird. Üblicherweise wird diese<br />
Liste als die ACL des Objekts bezeichnet. Es ist aber noch eine zweite ACL mit jedem Objekt<br />
verknüpft, die die Überwachungsrichtlinien für dieses Objekt festlegt und die Integritätsebene<br />
(siehe Kapitel 2) für das Objekt enthält. <strong>Die</strong>se ACL wird offiziell als SACL (System<br />
Access Control List, Systemzugriffssteuerungsliste) bezeichnet. Sie ist genauso aufgebaut<br />
wie eine DACL, aber die einzelnen Zugriffssteuerungseinträge (Access Control Entry,<br />
ACE) in der SACL gewähren keine Berechtigungen an Benutzern und Gruppen, sondern<br />
legen fest, welche Zugriffe bei bestimmten Benutzern und Gruppen überwacht werden sollen.<br />
Wenn eine Zugriffsprüfung ausgeführt wird, muss der Ressourcenmanager entscheiden, ob<br />
eine Überwachung für diese konkrete Anforderung generiert wird. Erst stellt die Zugriffsprüfungsroutine<br />
fest, ob die Überwachungsrichtlinien für den Objektzugriff bei diesem Res-
Festlegen einer Überwachungsrichtlinie 221<br />
sourcenmanager aktiviert sind. Ist das der Fall, vergleicht die Zugriffsprüfungsroutine die<br />
SACL des Objekts mit dem Ergebnis der Zugriffsprüfung, nachdem die DACL ausgewertet<br />
wurde. Im Allgemeinen verläuft die Auswertung der SACL ganz ähnlich wie die für die<br />
DACL. Falls eine SACL mit dem Objekt verknüpft ist und mindestens eine der SIDs im<br />
Token des Anforderers irgendeiner SID in den ACEs der SACL entspricht und irgendeiner<br />
der entsprechenden Zugriffe in den Zugriffsmasken der passenden ACEs der angeforderten<br />
Zugriffsmaske entspricht, wird ein Ereignis generiert. Das Ereignis zeichnet die angeforderte<br />
Zugriffsmaske auf, un zwar als Ereignis über das Öffnen eines Handles. <strong>Die</strong>ser Prozess<br />
findet sowohl bei erfolgreichen als auch fehlgeschlagenen Zugriffsanforderungen statt. Das<br />
jeweilige Ereignis zeichnet den Erfolg beziehungsweise Fehlschlag der Operation zum Öffnen<br />
des Handles auf. <strong>Die</strong> Zugriffsmaske wird vom Objektmanager aufbewahrt; wenn später<br />
weitere Operationen mit diesem Handle durchgeführt werden, führt das erste Auftreten<br />
irgendeines überwachten Zugriffs dazu, dass ein Ereignis generiert wird.<br />
Festlegen einer Überwachungsrichtlinie<br />
In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> sind Überwachungsrichtlinien hierarchisch<br />
organisiert. Das ist eine deutliche Verbesserung der Überwachungsrichtlinien. Bei älteren<br />
<strong>Windows</strong>-Versionen war keine Struktur für Überwachungsrichtlinien vorgesehen, daher<br />
konnte der Umfang der überwachten Bereiche nicht so detailliert eingestellt werden.<br />
Vor <strong>Windows</strong> Vista wurde jedes <strong>Sicherheit</strong>sereignis in eine von neun Überwachungsrichtlinienkategorien<br />
eingeordnet. Indem Sie die Erfolgs- oder Fehlerüberwachung für eine<br />
Überwachungskategorie einschalten, aktivieren Sie alle Überwachungsereignisse für diese<br />
Kategorie. Abbildung 8.2 zeigt, wie Überwachungsrichtlinien in <strong>Windows</strong>-Systemen vor<br />
Vista aufgebaut sind.<br />
Abbildung 8.2 Hierarchie der Überwachungsrichtlinien vor <strong>Windows</strong> Vista
222 Kapitel 8: Überwachung<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista wird jedes <strong>Sicherheit</strong>sereignis einer Überwachungsrichtlinien-Unterkategorie<br />
zugeordnet. Wenn Sie Überwachungsrichtlinien für diese<br />
Unterkategorie aktivieren, werden alle Ereignisse aktiviert, die zu dieser Unterkategorie gehören.<br />
Jede Unterkategorie hat eine Einstellung, mit der Sie aktivieren, dass Ereignisse für<br />
erfolgreiche Aktivitäten generiert werden, und eine Einstellung, mit der Sie aktivieren, dass<br />
Ereignisse für fehlgeschlagene Aktivitäten generiert werden.<br />
Unterkategorien von Überwachungsrichtlinien sind wiederum in dieselben Überwachungsrichtlinienkategorien<br />
untergliedert, die in <strong>Windows</strong> <strong>Server</strong> 2003 und älteren Versionen vorhanden<br />
waren. <strong>Die</strong>s stellt die Kompatibilität sicher. Wenn eine Überwachungsrichtlinienkategorie<br />
aktiviert ist, sind alle Unterkategorien für diese Kategorie und damit die zugehörigen<br />
Ereignisse aktiviert. Und wenn eine Überwachungsrichtlinienkategorie deaktiviert ist, sind<br />
auch alle zugehörigen Unterkategorien und ihre Ereignisse deaktiviert. Abbildung 8.3 zeigt,<br />
wie Überwachungsrichtlinien in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Systemen aufgebaut sind.<br />
Abbildung 8.3 Hierarchie der Überwachungsrichtlinien in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Überwachungsrichtlinien können mit zwei Tools konfiguriert werden: einer grafischen Benutzeroberfläche,<br />
die von den MMC-Snap-Ins <strong>Sicherheit</strong>srichtlinieneditor und Gruppenrichtlinien-Editor<br />
verwendet wird, oder dem Befehlszeilentool AuditPol.exe. Allerdings<br />
kann nur AuditPol.exe Überwachungsrichtlinien auf der Ebene von Unterkategorien festlegen:<br />
Microsoft hat die grafische Benutzeroberfläche für Überwachungsrichtlinien (Abbildung<br />
8.4) nicht so aktualisiert, dass damit Überwachungsrichtlinien-Unterkategorien verwaltet<br />
werden können. <strong>Die</strong>se Einschränkung betrifft auch den Gruppenrichtlinienmechanismus
Festlegen einer Überwachungsrichtlinie 223<br />
für die Bereitstellung von Überwachungsrichtlinien. <strong>Die</strong>s wird sich in einer künftigen Version<br />
ändern, aber vorerst müssen Sie das Problem über die Befehlszeile lösen oder sich auf<br />
die alten Überwachungsrichtlinien beschränken.<br />
Abbildung 8.4 Benutzeroberfläche für die Konfiguration von Überwachungsrichtlinien<br />
im MMC-Snap-In Lokale <strong>Sicherheit</strong>srichtlinie<br />
Wegen der hierarchischen Beziehung zwischen Überwachungsrichtlinienkategorien und<br />
Unterkategorien ist es normalerweise nicht sinnvoll, alte Überwachungsrichtlinien auf <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista zu verwenden.<br />
Überwachungsrichtlinien sollen steuern, welche Ereignisse generiert und in Ihren Überwachungsprotokollen<br />
gespeichert werden. Und das neue GAP-Feature (Granular Audit Policy)<br />
gibt Ihnen viel flexiblere Steuermöglichkeiten. Aber die meisten <strong>Windows</strong>-Systeme erhalten<br />
ihre Überwachungsrichtlinien per Gruppenrichtlinie aus der Domäne, und dort wird GAP<br />
nicht unterstützt. Das bedeutet, dass Sie zwar tolle Überwachungsrichtlinien für Ihre neuen<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Systeme entwickeln können, aber sobald Sie den <strong>Server</strong> zu Ihrer<br />
Domäne hinzufügen, werden die neuen Überwachungsrichtlinien durch alte Überwachungsrichtlinieneinstellungen<br />
aus den Gruppenrichtlinie überschrieben.<br />
Glücklicherweise stellt Microsoft einen Mechanismus zur Verfügung, der verhindert, dass<br />
alte Überwachungsrichtlinien, die über Gruppenrichtlinien verteilt werden, GAP überschreiben.<br />
Ein Registrierungswert namens SCENoConfigLegacyAuditPolicy steuert, ob das <strong>Sicherheit</strong>skonfigurationsmodul<br />
(die Komponente, die Gruppenrichtlinieneinstellungen im Bereich<br />
der <strong>Sicherheit</strong> erzwingt) alte Überwachungsrichtlinien anwendet. Falls dieser Registrierungswert<br />
vorhanden ist und einen Wert ungleich 0 hat, werden Überwachungsrichtlinien<br />
auf Kategorieebene nicht angewendet, falls sie über das <strong>Sicherheit</strong>srichtlinien-Snap-In oder<br />
Gruppenrichtlinien eingestellt wurden. <strong>Die</strong>ser Registrierungswert ist im Microsoft Knowledge<br />
Base-Artikel 921468 (http://support.microsoft.com/kb/921468) beschrieben, einen<br />
Link finden Sie auch direkt in der Benutzeroberfläche der Überwachungsrichtlinien (Abbildung<br />
8.5). Es kommt noch besser: <strong>Die</strong> Registrierungseinstellung selbst kann über Gruppenrichtlinien<br />
bereitgestellt werden (Abbildung 8.6), sodass alle Ihre <strong>Windows</strong> Vista- und <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>-Computer alte Überwachungsrichtlinien ignorieren und nach Möglichkeit<br />
die neue GAP-Variante verwenden. Sie sollten wissen, dass die UI für Überwachungsrichtlinien<br />
irreführend sein kann, wenn Sie diese Einstellung verwenden: <strong>Die</strong> UI zeigt unter Umständen<br />
einige Kategorien als aktiviert oder deaktiviert an, diese Einstellungen werden aber<br />
nicht angewendet.
224 Kapitel 8: Überwachung<br />
Abbildung 8.5 Überwachungsrichtlinieneinstellungen<br />
für die Kategorie Anmeldeereignisse überwachen<br />
Abbildung 8.6 Im Gruppenrichtlinien-Editor kann verhindert werden, dass alte Überwachungsrichtlinien<br />
aus Gruppenrichtlinien die Einstellungen auf <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Systemen überschreiben<br />
Es gibt noch eine andere Einschränkung bei der Benutzeroberfläche für Überwachungsrichtlinien,<br />
die sich als Nebenwirkung aus der Beziehung zwischen Kategorien und Unterkategorien<br />
ergibt. Wenn Sie in der UI Einstellungen für die Überwachungsrichtlinienkategorie untersuchen,<br />
zeigt die UI an, dass die Kategorie aktiviert ist, falls alle Unterkategorien dieser<br />
Kategorie aktiviert sind. Und entsprechend zeigt die UI an, dass die Kategorie deaktiviert<br />
ist, falls alle zugehörigen Unterkategorien deaktiviert sind. Aber die UI muss noch einen<br />
anderen Fall beachten: wenn einige der Unterkategorien aktiviert sind, andere aber nicht. In<br />
diesem Fall zeigt die UI an, dass die Kategorie deaktiviert ist, aber Sie können sich in diesem<br />
Fall die richtigen Überwachungsrichtlinieneinstellungen mit dem <strong>Die</strong>nstprogramm<br />
AuditPol.exe anzeigen lassen (Abbildung 8.7).
Festlegen einer Überwachungsrichtlinie 225<br />
Abbildung 8.7 Mit AuditPol.exe können Sie die effektiven GAP-Einstellungen anzeigen<br />
Zusammenfassend lässt sich also sagen: GAP trägt viel dazu bei, die Probleme bei der Auswahl<br />
der überwachten Bereiche zu beseitigen, unter denen ältere <strong>Windows</strong>-Versionen zu<br />
leiden hatten. Aber wenn Sie dieses Feature nutzen, müssen Sie die gesamte Administration<br />
Ihrer Überwachungsrichtlinien mit dem Tool AuditPol.exe erledigen. Auch wenn Gruppenrichtlinien<br />
GAP nicht direkt unterstützen, ist es zumindest möglich, GAP über Gruppenrichtlinien<br />
bereitzustellen. Dazu stellen Sie ein Skript bereit, das AuditPol.exe ausführt und die<br />
gewünschten Überwachungsrichtlinien einstellt. Das Skript muss ein Startskript sein, das<br />
mit Systemprivilegien auf dem Computer läuft. Überwachungsrichtlinien können von<br />
Benutzern ohne erhöhte Privilegien nicht eingestellt werden, daher können sie nicht über<br />
Anmeldeskripts bereitgestellt werden.<br />
Eine vollständige Anleitung inklusive Beispielskripts finden Sie im Microsoft Knowledge<br />
Base-Artikel 921469 (http://support.microsoft.com/kb/921469). Kurz zusammengefasst<br />
müssen Sie folgendermaßen vorgehen:<br />
1. Stellen Sie mithilfe von Gruppenrichtlinien SCENoConfigLegacyAuditPolicy auf Ihren<br />
<strong>Windows</strong> Vista- und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Computern bereit.<br />
2. Schreiben Sie ein Skript, das mit AuditPol.exe die gewünschten Richtlinieneinstellungen<br />
anwendet, und kopieren Sie dieses Skript in eine Freigabe.<br />
3. Schreiben Sie ein Skript, um eine Aufgabe zu planen, die das Skript für die Überwachungsrichtlinien<br />
regelmäßig ausführt, und richten Sie dieses Skript als Startskript ein.<br />
<strong>Die</strong>ser Mechanismus wurde getestet, und er funktioniert einwandfrei. Sie können diese<br />
Lösung so bereitstellen, dass es auch bei späteren Änderungen an irgendwelchen Überwachungsrichtlinieneinstellungen<br />
nicht nötig ist, irgendwelche Gruppenrichtlinienobjekte<br />
(Group Policy Object, GPO) oder Skripts anzupassen. Das ist möglich, weil das Richtlinienanwendungsskript<br />
die Überwachungseinstellungen aus einer Textdatei liest.<br />
Optionen für Überwachungsrichtlinien<br />
Es gibt einige optionale Features im Bereich der Überwachungsrichtlinien, die Sie mit Audit-<br />
Pol.exe oder im Abschnitt <strong>Sicherheit</strong>soptionen der <strong>Sicherheit</strong>srichtlinienbenutzeroberfläche<br />
im lokalen oder Gruppenrichtlinienmodus aktivieren können.<br />
CrashOnAuditFail ist eine Einstellung, die erforderlich ist, um das Common-Criteria-Schutzprofil<br />
für Single-Level-Betriebssysteme zu erfüllen. <strong>Die</strong> Common-Criteria-Anforderung
226 Kapitel 8: Überwachung<br />
besagt, dass ein entsprechendes System in der Lage sein muss, sofort alle überwachbaren<br />
Aktivitäten abzubrechen, falls das Überwachungssystem keine <strong>Sicherheit</strong>sereignisse generieren<br />
oder speichern kann. In <strong>Windows</strong> wird dies dadurch implementiert, dass das System<br />
angehalten wird (in Form eines Bluescreens), wenn das Überwachungssystem nicht in der<br />
Lage ist, <strong>Sicherheit</strong>sereignisse aufzuzeichnen. Wenn dieser Fall eintritt, können nur Administratoren<br />
sich anmelden, nachdem das System neu gestartet ist. <strong>Die</strong>s gilt so lange, bis das<br />
<strong>Sicherheit</strong>sereignisprotokoll geleert und die Bedingung beseitigt wurde, die den Fehler ausgelöst<br />
hat.<br />
Verwenden Sie diese Einstellung nur, wenn sie unbedingt gebraucht wird. Sie kann einen<br />
möglichen Repudiation-Angriff in einen wirksamen Denial-of-Service-Angriff verwandeln.<br />
CrashOnAuditFail hat drei Zustände:<br />
Das Feature ist nicht aktiviert.<br />
Das Feature ist aktiviert, aber das System wurde noch nicht angehalten.<br />
Das Feature ist aktiviert, das System wurde wegen eines Überwachungssystemfehlers<br />
angehalten und das System wurde neu gestartet. Nur Administratoren des Computers<br />
können sich anmelden. Bis CrashOnAuditFail auf aktiviert oder deaktiviert zurückgesetzt<br />
und das Protokoll geleert wurde, ist es normalen Benutzern nicht möglich, sich anzumelden.<br />
<strong>Die</strong> Einstellung FullPrivilegeAuditing bewirkt, dass für alle Privilegien außer SeAuditPrivilege<br />
Ereignisse zur Privilegiennutzung (sofern über Überwachungsrichtlinien aktiviert)<br />
generiert werden. Normalerweise werden für die folgenden Privilegien keine Privilegiennutzungsereignisse<br />
generiert:<br />
Auslassen der durchsuchenden Überprüfung (SeChangeNotifyPrivilege)<br />
Debuggen von Programmen (SeDebugPrivilege)<br />
Erstellen eines Tokenobjekts (SeCreateTokenPrivilege)<br />
Ersetzen eines Tokens auf Prozessebene (SeAssignPrimaryTokenPrivilege)<br />
Generieren von <strong>Sicherheit</strong>süberwachungen (SeAuditPrivilege)<br />
Sichern von Dateien und Verzeichnissen (SeBackupPrivilege)<br />
Wiederherstellen von Dateien und Verzeichnissen (SeRestorePrivilege)<br />
<strong>Die</strong>se Privilegien werden ignoriert, weil sie von normalen Betriebssystemfunktionen und<br />
Anwendungen sehr häufig verwendet werden. Im Fall der Privilegien zum Sichern und Wiederherstellen<br />
treten sie auch in großen Mengen kurz hintereinander auf, wenn eine entsprechende<br />
Operation ausgeführt wird. Und würde das Privileg zum Generieren von Überwachungsereignissen<br />
selbst überwacht, würde sich das Protokoll mit diesem Ereignis füllen;<br />
daher wird SeAuditPrivilege niemals überwacht. Sie können es sich folgendermaßen vorstellen:<br />
Jedes Ereignis im <strong>Sicherheit</strong>sereignisprotokoll ist auch ein Privilegiennutzungsereignis<br />
zu SeAuditPrivilege. Jedenfalls ist dies eine weitere Einstellung, die Sie wahrscheinlich<br />
nicht aktivieren sollten, sofern dafür keine zwingenden Gründe vorliegen.<br />
<strong>Die</strong> Einstellungen AuditBaseObjects und AuditBaseDirectories bewirken, dass benannte<br />
Kernelobjekte (zum Beispiel Mutexe und Semaphore) SACLs zugewiesen bekommen, wenn<br />
sie erstellt werden. AuditBaseDirectories wirkt sich auf Containerobjekte aus, AuditBase-<br />
Objects auf Objekte, die keine anderen Objekte enthalten können. Basisobjekte (engl. base<br />
object) werden normalerweise benutzt, um Aktivitäten zwischen zwei Prozessen zu synchronisieren.<br />
<strong>Die</strong> meisten Kernelobjekte sind nicht benannt, sie werden nur über eine Zahl
Festlegen einer Überwachungsrichtlinie 227<br />
angesprochen, das sogenannte Handle. Handles sind in einem bestimmten Prozess einmalig,<br />
daher können Prozesse keine unbenannten Kernelobjekte sehen, die sie nicht selbst erstellt<br />
haben, und auch nicht darauf zugreifen. Benannte Kernelobjekte sind für andere Prozesse<br />
sichtbar, sofern ein Prozess keinen privaten Namespace anfordert. Falls benannte Kernelobjekte<br />
nicht ausreichend geschützt werden, bergen sie die Gefahr, dass ein böswilliger<br />
Prozess sie manipuliert, wodurch Fehler in den Prozessen ausgelöst werden könnten, die<br />
diese Objekte normalerweise einsetzen. <strong>Die</strong>s wird als Squatting-Angriff bezeichnet. Audit-<br />
BaseObjects und AuditBaseDirectories stehen zur Verfügung, damit Sie den Zugriff auf<br />
diese Objekte überwachen und Squatting-Angriffe im Protokoll erkennen können.<br />
Das Hauptproblem bei AuditBaseObjects und AuditBaseDirectories ist, dass sie sehr viele<br />
Überwachungsdaten generieren können, weil im Rahmen des normalen Betriebs viele Zugriffe<br />
auf diese Objekte stattfinden. <strong>Die</strong> angewendeten SACLs sind fest einprogrammiert<br />
und können vom Benutzer nicht verändert werden. In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong> wurden sie so verändert, dass nur Schreibzugriffe auf diese Objekte überwacht werden,<br />
sodass sich die Menge der generierten Ereignisse gegenüber älteren Versionen deutlich verringert.<br />
Eine andere Einschränkung des SACL-Mechanismus ist, dass SACLs während der<br />
gesamten Lebensdauer des Objekts existieren. Sie werden angewendet, wenn das Objekt<br />
erstellt wird, was bei Systemobjekten während des Systemstarts und bei Prozessen, die ihre<br />
eigenen Objekte erstellen, während der Initialisierungsphase ist. <strong>Die</strong> SACLs ändern sich<br />
nicht, bis das Objekt zerstört wird, was normalerweise beim Herunterfahren des Systems<br />
(für Systemobjekte) oder Beenden des Prozesses passiert, der das Objekt erstellt hat. Das<br />
bedeutet also, dass Sie neu starten müssen, um AuditBaseObjects oder AuditBaseDirectories<br />
zu aktivieren oder deaktivieren.<br />
Abbildung 8.8 Untersuchen eines Objekts im Process Explorer
228 Kapitel 8: Überwachung<br />
Es gibt keinen zentralen Informationsspeicher über Kernelobjekte. <strong>Die</strong> meisten Softwarehersteller<br />
veröffentlichen diese Art von Informationen nicht, weil sie die interne Funktionsweise<br />
der Software betreffen und nicht vom Benutzer konfiguriert werden können. Selbst wenn Sie<br />
AuditBaseObjects oder AuditBaseDirectories aktivieren, werden Sie wahrscheinlich sehen,<br />
dass es schwierig oder sogar unmöglich ist festzustellen, was ein bestimmtes Objekt tut oder<br />
wofür es verwendet wird. Sie können nur darauf hoffen, dass der Name des Objekts besonders<br />
aussagekräftig ist. Aus diesem Grund sollten Sie diese Einstellungen in Produktivumgebungen<br />
nur dann aktivieren, wenn es unbedingt nötig ist. Sie können sich Basisobjekte<br />
im Process Explorer (Abbildung 8.8.) ansehen, den Sie von Microsofts SysInternals-Website<br />
unter http://www.microsoft.com/technet/sysinternals/SystemInformation/Process<br />
Explorer.mspx herunterladen können.<br />
Verbesserungen an Überwachungsrichtlinien<br />
Neben dem GAP-Feature wurde in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> eine Reihe kleinerer Verbesserungen<br />
an den Überwachungsrichtlinien vorgenommen.<br />
Benutzerspezifische Überwachungsrichtlinien<br />
<strong>Windows</strong> XP führte einen Mechanismus ein, um benutzerspezifische Ausnahmen für<br />
Überwachungsrichtlinien festzulegen, die sogenannte benutzerspezifische Überwachung<br />
(engl. per user selective audit oder per-user auditing). In <strong>Windows</strong> Vista und <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> gibt es diesen Mechanismus weiterhin, und er wurde enger in den Überwachungsrichtlinienmechanismus<br />
integriert: Wo früher separate Tools erforderlich waren,<br />
um benutzerspezifische Überwachungsrichtlinien festzulegen, können jetzt für benutzerspezifische<br />
und Systemüberwachungsrichtlinien dieselben Tools (und ihre zugrunde liegenden<br />
APIs) verwendet werden.<br />
Delegieren von Überwachungsrichtlinien<br />
Ein <strong>Windows</strong>-System erledigt sechs Aufgaben im Bereich der Überwachungsrichtlinien:<br />
Prüfen des <strong>Sicherheit</strong>sereignisprotokolls<br />
Löschen des <strong>Sicherheit</strong>sereignisprotokolls<br />
Prüfen der Überwachungsrichtlinieneinstellungen<br />
Festlegen der Überwachungsrichtlinien<br />
Prüfen von SACLs<br />
Festlegen von SACLs<br />
Seit der Einführung von <strong>Windows</strong> NT wurden alle sechs Aufgaben zusammen delegiert,<br />
dafür wurde das Privileg Verwalten von Überwachungs- und <strong>Sicherheit</strong>sprotokollen<br />
(SeSecurityPrivilege) definiert.<br />
In <strong>Windows</strong> <strong>Server</strong> 2003 wurde ein Mechanismus eingeführt, um die Berechtigungen in<br />
Ereignisprotokollen über den Registrierungswert CustomSD festzulegen. (Weitere Informationen<br />
finden Sie im Microsoft Knowledge Base-Artikel 323076.) Ereignisprotokollberechtigungen<br />
erlauben es, die ersten beiden Aufgaben getrennt von den anderen, getrennt<br />
voneinander und unabhängig von SeSecurityPrivilege zu delegieren.<br />
In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wurde ein neuer Mechanismus für die<br />
Delegierung von Überwachungsrichtlinien eingeführt. Er erlaubt es, das Recht zum Prüfen<br />
und/oder Einstellen von Überwachungsrichtlinien getrennt von den übrigen Aufgaben
Entwerfen einer guten Überwachungsrichtlinie 229<br />
zu delegieren. <strong>Die</strong>ser Mechanismus ist in Form einer ACL direkt in den Überwachungsrichtlinien<br />
implementiert.<br />
In der Standardeinstellung hat nur VORDEFINIERT\Administratoren das Recht, Überwachungsrichtlinien<br />
einzustellen und anzusehen. Das bedeutet, dass sich der Standardzugriff<br />
auf Überwachungsrichtlinien gegenüber älteren Versionen nicht verändert hat.<br />
Sie können die Überwachungsrichtlinien-ACL mithilfe des Befehlszeilentools Audit-<br />
Pol.exe anpassen. Falls die ACL versehentlich falsch konfiguriert wird, kann sie mit<br />
AuditPol.exe von jedem Benutzer zurückgesetzt werden, der das Privileg SeSecurity-<br />
Privilege besitzt.<br />
Entwerfen einer guten Überwachungsrichtlinie<br />
Sie können das Überwachungsfeature wirksam nutzen, wenn Sie eine Überwachungsrichtlinie<br />
entwickeln, die einerseits die Ereignisse generiert, für die Sie sich interessieren, und<br />
andererseits so wenig Ereignisse erzeugt, dass Sie die entstehenden Protokolle mit vertretbaren<br />
Aufwand verwalten können.<br />
Viele Administratoren, die das Feature vorher noch nicht genutzt haben, aktivieren erst einmal<br />
sämtliche Überwachungsrichtlinien. Nach kurzer Zeit stellen sie dann entsetzt fest, dass<br />
eine Unmenge von Ereignissen generiert wird.<br />
Wie bei jeder anderen Form von <strong>Sicherheit</strong>srichtlinie erreichen Sie die effektivsten Ergebnisse,<br />
wenn Sie analysieren, welche <strong>Sicherheit</strong>sbedrohungen Sie am meisten betreffen, und<br />
geeignete Richtlinieneinstellungen bereitstellen, um diese Bedrohungen abzuwehren.<br />
<strong>Die</strong> Versuchung ist groß, bei der Auswahl von Überwachungsrichtlinieneinstellungen genauso<br />
vorzugehen wie beim Blättern in einem Versandhauskatalog oder in der Speisekarte eines<br />
Restaurants. Viele der Einstellungen sehen gut aus, und nichts hindert Sie daran, alle auszuwählen.<br />
Aber wie bereits erwähnt, kann <strong>Windows</strong> vermutlich viel mehr Überwachungsdaten<br />
generieren, als Sie auswerten können. Indem Sie sorgfältig genau die Ereignisse auswählen,<br />
die Ihre <strong>Sicherheit</strong>sgefahren abdecken, erzielen Sie letztlich wahrscheinlich viel bessere<br />
Ergebnisse.<br />
Auf der Begleit-CD zu diesem Buch finden Sie Dateien, mit denen Sie Überwachungsereignisse<br />
den Kategorien und Unterkategorien von Überwachungsrichtlinien zuordnen können,<br />
die diese Ereignisse ausgelöst haben. Sie können diese Daten zur Unterstützung bei der<br />
Planung Ihrer eigenen Überwachungsrichtlinieneinstellungen nutzen.<br />
Sobald Sie Ihre Überwachungsrichtlinien ausgewählt haben, sollten Sie sie auf einer kleinen<br />
Zahl von Produktivcomputern hosten und prüfen, wie groß die entstehenden <strong>Sicherheit</strong>sprotokolle<br />
werden. Sollten Sie feststellen, dass die Datenmenge für Ihren Geschmack zu groß<br />
ist, sollten Sie versuchen, weniger aggressive Überwachungseinstellungen zu verwenden.<br />
<strong>Die</strong> Ereignisanzeige ist ein sehr nützliches Tool in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, wenn Sie genau<br />
feststellen wollen, welche Richtlinieneinstellungen die meisten aufgezeichneten Überwachungsereignisse<br />
verursachen. Im Hauptfenster der Ereignisanzeige können Sie Ereignisse<br />
anhand von Aufgabenkategorie (dasselbe wie Unterkategorie), Ereignisquelle, Ereignis-ID<br />
und anderen Attributen gruppieren, woraufhin Sie angezeigt bekommen, wie viele Einträge<br />
jede Gruppe enthält (Abbildung 8.9). Falls Sie ein Ereignis finden, das sehr viele Einträge<br />
verursacht, sollten Sie sich einige Einzelereignisse ansehen und prüfen, ob das Ereignis
230 Kapitel 8: Überwachung<br />
tatsächlich nützliche Informationen liefert. Ist das nicht der Fall, können Sie überlegen, ob<br />
Sie nicht die Richtlinie deaktivieren, die bewirkt, dass dieses Ereignis generiert wird.<br />
Abbildung 8.9 <strong>Die</strong> Ereignisanzeige kann <strong>Sicherheit</strong>sereignisse anhand von Aufgabenkategorien<br />
gruppieren<br />
Wenn Sie Ihre Überwachungsrichtlinien ausgewählt, getestet und optimiert haben, können<br />
Sie sich daran machen, die Richtlinien bereitzustellen.<br />
Falls Sie Hilfe beim Entwickeln von Überwachungsrichtlinien benötigen, lesen Sie im <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> Security Guide die Empfehlungen für Überwachungsrichtlinien. Sie finden<br />
dieses Buch auf der TechNet Security-Website unter http://www.microsoft.com/technet/<br />
security/guidance.<br />
Neue Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> hat gegenüber älteren <strong>Windows</strong>-Versionen deutliche Änderungen an<br />
den Ereignissen im <strong>Sicherheit</strong>sereignisprotokoll aufzuweisen.<br />
Wenn Sie sich die Ereignisanzeige ansehen, dürfte Ihnen als Erstes auffallen, dass die<br />
Nummern der Ereignis-IDs ganz anders aussehen. <strong>Die</strong> <strong>Sicherheit</strong>sereignisse wurden neu<br />
nummeriert und auch umstrukturiert. Falls Sie viele Nummern von <strong>Sicherheit</strong>sereignis-IDs<br />
in <strong>Windows</strong> auswendig wissen, ist dieses Wissen aber nicht nutzlos geworden. Im Allgemeinen<br />
ist die Ereignis-ID eines <strong>Sicherheit</strong>sereignisses in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> um den Wert<br />
4096 höher als das entsprechende Ereignis in <strong>Windows</strong> <strong>Server</strong> 2003. Zum Beispiel wurde<br />
das Ereignis zu einer erfolgreichen Anmeldung, ID 528 in <strong>Windows</strong> <strong>Server</strong> 2003, zum Ereignis<br />
4624 in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> (528 + 4096 = 4624). Und das Ereignis zum Ändern
Neue Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 231<br />
der Systemzeit, vorher mit der Ereignis-ID 520, hat jetzt in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> die Ereignis-ID<br />
4616.<br />
Als Nächstes dürfte Ihnen auffallen, dass die Informationen zu den Ereignissen in der Ereignisanzeige<br />
etwas anders aufgebaut sind. Falls Sie mit den Ereignissen in älteren <strong>Windows</strong>-<br />
Versionen sehr vertraut sind, werden Sie auch bemerken, dass viele Ereignisse zusätzliche<br />
Felder enthalten. Sehen wir uns zum Beispiel das Ereignis zu einer erfolgreichen Anmeldung<br />
in <strong>Windows</strong> <strong>Server</strong> 2003 und das entsprechende Ereignis in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
genauer an.<br />
<strong>Windows</strong> <strong>Server</strong> 2003:<br />
Erfolgreiche Anmeldung:<br />
Benutzername: Administrator<br />
Domäne: CONTOSO<br />
Anmeldekennung: (0x0,0x13CC2)<br />
Anmeldetyp: 7<br />
Anmeldevorgang: User32<br />
Authentifizierungspaket: Negotiate<br />
Name der Arbeitsstation: DC<br />
Anmelde-GUID: {00000000-0000-0000-000000000000}<br />
Aufruferbenutzername: DC$<br />
Aufruferdomäne: CONTOSO<br />
Aufruferanmeldekennung: (0x0,0x3E7)<br />
Aufruferprozesskennung: -<br />
Übertragene <strong>Die</strong>nste: -<br />
Quellnetzwerkadresse: 127.0.0.1<br />
Quellport: 0<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>:<br />
Ein Konto wurde erfolgreich angemeldet.<br />
Antragsteller:<br />
<strong>Sicherheit</strong>s-ID: SYSTEM<br />
Kontoname: DC$<br />
Kontodomäne: CONTOSO<br />
Anmelde-ID: 0x3e7<br />
Anmeldetyp: 7<br />
Neue Anmeldung:<br />
<strong>Sicherheit</strong>s-ID: CONTOSO\Administrator<br />
Kontoname: Administrator<br />
Kontodomäne: CONTOSO<br />
Anmelde-ID: 0x16d30b<br />
Anmelde-GUID: {00000000-0000-0000-0000-000000000000}<br />
Prozessinformationen:<br />
Prozess-ID: 0x20c<br />
Prozessname: C:\<strong>Windows</strong>\System32\winlogon.exe
232 Kapitel 8: Überwachung<br />
Netzwerkinformationen:<br />
Arbeitsstationsname: DC<br />
Quellnetzwerkadresse: 127.0.0.1<br />
Quellport: 0<br />
Detaillierte Authentifizierungsinformationen:<br />
Anmeldeprozess: User32<br />
Authentifizierungspaket: Negotiate<br />
Übertragene <strong>Die</strong>nste: -<br />
Paketname (nur NTLM): -<br />
Schlüssellänge: 0<br />
Sie sehen mehrere deutliche Änderungen in diesem Ereignis. Erstens wurde das Ereignisformat<br />
so geändert, dass Sie die gesuchten Informationen einfacher und schneller finden<br />
können. Ähnliche Informationen wurden für die Anzeige in Abschnitten zusammengefasst.<br />
Ein Standardabschnitt, Antragsteller, wurde in den meisten Ereignissen hinzugefügt, um die<br />
Rolle des Benutzers deutlicher zu machen. Der Antragsteller ist das Konto, das dafür verantwortlich<br />
ist, dass dieses Ereignis generiert wurde. Es ist das Konto, das die überwachte<br />
Aktivität ausgeführt hat. In diesem Fall ist es SYSTEM. Warum? Weil die Aktivität nicht<br />
»ein Benutzer hat sich angemeldet« ist. <strong>Die</strong> Aktivität ist »ein Benutzerkonto wurde angemeldet«,<br />
also im Passiv. Ein Prozess, der als SYSTEM läuft (in diesem Fall WinLogon), hat<br />
die Anmeldung angefordert. Ein weiterer Satz von Feldern beschreibt den Benutzer, der<br />
angemeldet wurde.<br />
Anschließend führen Ereignisse automatisierungsfreundliche Zuordnungsfelder und für<br />
Menschen leicht lesbare Textfelder auf. Zum Beispiel wird die Prozess-ID (PID) durch den<br />
Prozesspfad ergänzt.<br />
<strong>Die</strong> Ereignisanzeige scheint den Namen des Benutzerkontos zweimal anzuzeigen, aber in<br />
Wirklichkeit ist das erste Exemplar jedes Kontos als <strong>Sicherheit</strong>s-ID (SID, siehe Kapitel 1,<br />
»Subjekte, Benutzer und andere Akteure«) gespeichert, das zweite als Name. <strong>Die</strong> Ereignisanzeige<br />
übersetzt die SID automatisch in einen Kontonamen, wo immer das möglich ist.<br />
Weil die Namen aber zusätzlich auch in Textform gespeichert sind, wird der Name (und die<br />
unübersetzte SID) auch dann angezeigt, wenn Sie sich an einem anderen Computer anmelden,<br />
wo die Übersetzung nicht möglich ist, oder wenn das Konto gelöscht wurde. Wenn<br />
Namen nicht aufgelöst werden konnten, war das in Vorgängerversionen bei der Auswertung<br />
des <strong>Sicherheit</strong>sprotokolls ein häufiges Ärgernis.<br />
Es wurden weitere Informationen hinzugefügt. Beträfe dieses Beispiel eine NTLM-Anmeldung,<br />
würde das jeweilige NTLM-Protokoll aufgelistet (LM, NTLM V1 oder NTLM V2),<br />
und falls ein NTLMv2-Sitzungsschlüssel ausgehandelt worden wäre, würde die Schlüssellänge<br />
ausgegeben werden. Das hilft Ihnen, wenn Sie die Migration in eine Umgebung ohne<br />
NTLM planen und im Vorfeld herausfinden möchten, welche Folgen das hat.<br />
Eine Reihe kleinerer, aber wichtiger Änderungen am Format wurden durchgeführt. Zum<br />
Beispiel wird das Feld Anmelde-ID nicht mehr wie in älteren Versionen als oberes und unteres<br />
DWORD angegeben, zum Beispiel »(0x0,0x16d30b)«. Das Komma bewirkte, dass dieses<br />
Feld schlecht auszuwerten war. Stattdessen wird das Feld jetzt als Einzelwert in hexadezimaler<br />
Notation angezeigt. Prozess-IDs werden ebenfalls hexadezimal angezeigt.
Neue Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 233<br />
Eine andere wichtige Änderung ist, dass in den Ereignissen über Registrierungs- und Active<br />
Directory-Objektzugriffe die bisherigen und neuen Werte aufgeführt werden:<br />
Ein Registrierungswert wurde geändert.<br />
Antragsteller:<br />
<strong>Sicherheit</strong>s-ID: CONTOSO\Administrator<br />
Kontoname: Administrator<br />
Kontodomäne: CONTOSO<br />
Anmelde-ID: 0x31e01<br />
Objekt:<br />
Objektname: \REGISTRY\MACHINE\SOFTWARE\Microsoft\<strong>Windows</strong>\CurrentVersion\Run<br />
Name des Objektwerts: StartupProgram<br />
Handle-ID: 0x118<br />
Vorgangstyp: Ein vorhandener Registrierungswert wurde geändert<br />
Prozessinformationen:<br />
Prozess-ID: 0xa58<br />
Prozessname: C:\<strong>Windows</strong>\regedit.exe<br />
Informationen zur Änderung:<br />
Typ des alten Werts: REG_SZ<br />
Alter Wert: C:\<strong>Windows</strong>\System32\windows_component.exe<br />
Typ des neuen Werts: REG_SZ<br />
Neuer Wert: C:\<strong>Windows</strong>\System32\malware.exe<br />
In diesem Fall verrät uns das Ereignis, dass Administrator einen Wert namens StartupProgram<br />
im Registrierungsschlüssel Run geändert hat (dieser Schlüssel listet Programme auf,<br />
die automatisch ausgeführt werden, wenn sich ein Benutzer interaktiv anmeldet). Der normale<br />
Wert, der auf <strong>Windows</strong>_component.exe verweist, wurde ersetzt und verweist jetzt auf<br />
Malware.exe.<br />
Es gibt viele neue Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. <strong>Die</strong> Tabellen 8.1 bis 8.8 führen die<br />
wichtigsten auf.<br />
Tabelle 8.1 Änderungen am Verzeichnisdienst<br />
Ereignis-ID Beschreibung<br />
5136 Ein Verzeichnisdienstobjekt wurde geändert.<br />
5137 Ein Verzeichnisdienstobjekt wurde erstellt.<br />
5138 <strong>Die</strong> Löschung eines Verzeichnisdienstobjekts wurde rückgängig gemacht.<br />
5139 Ein Verzeichnisdienstobjekt wurde verschoben.<br />
5141 Ein Verzeichnisdienstobjekt wurde gelöscht.
234 Kapitel 8: Überwachung<br />
Tabelle 8.2 Netzwerkrichtlinienserver (diese Ereignisse unterstützen den Internetauthentifizierungsdienst,<br />
den RADIUS-<strong>Server</strong> in <strong>Windows</strong> <strong>Server</strong> und das Netzwerkzugriffsschutzfeature)<br />
Ereignis-ID Beschreibung<br />
6272 Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff gewährt.<br />
6273 Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff verboten.<br />
6274 Der Netzwerkrichtlinienserver hat die Anforderung eines Benutzers verworfen.<br />
6275 Der Netzwerkrichtlinienserver hat die Kontoführungsanforderung eines Benutzers verworfen.<br />
6276 Der Netzwerkrichtlinienserver hat einen Benutzer in Quarantäne gestellt.<br />
6277 Der Netzwerkrichtlinienserver hat einem Benutzer Zugriff gewährt, aber nur vorläufig, weil der Host die<br />
definierte Integritätsrichtlinie nicht erfüllt.<br />
6278 Der Netzwerkrichtlinienserver hat einem Benutzer vollständigen Zugriff gewährt, weil der Host die<br />
definierte Integritätsrichtlinie erfüllt.<br />
6279 Der Netzwerkrichtlinienserver hat das Benutzerkonto gesperrt, weil Authentifizierungsversuche<br />
mehrfach fehlgeschlagen sind.<br />
6280 Der Netzwerkrichtlinienserver hat das Benutzerkonto entsperrt.<br />
Tabelle 8.3 Aufgabenplanungsereignisse (andere Objektzugriffsversuchsereignisse)<br />
Ereignis-ID Beschreibung<br />
4698 Eine geplante Aufgabe wurde erstellt.<br />
4706 Eine geplante Aufgabe wurde deaktiviert.<br />
4707 Eine geplante Aufgabe wurde aktualisiert.<br />
Tabelle 8.4 Low-Level-Ereignisse der <strong>Windows</strong>-Firewall (Filterungsplattform)<br />
Ereignis-ID Beschreibung<br />
5031 Der <strong>Windows</strong>-Firewalldienst hat verhindert, dass eine Anwendung eingehende Verbindungen im<br />
Netzwerk annimmt.<br />
5152 <strong>Die</strong> <strong>Windows</strong>-Filterplattform hat ein Paket blockiert.<br />
5153 Ein restriktiverer <strong>Windows</strong>-Filterplattformfilter hat ein Paket blockiert.<br />
5154 <strong>Die</strong> <strong>Windows</strong>-Filterplattform hat einer Anwendung oder einem <strong>Die</strong>nst erlaubt, einen Port nach<br />
eingehenden Verbindungen zu überwachen.<br />
5155 <strong>Die</strong> <strong>Windows</strong>-Filterplattform hat verhindert, dass eine Anwendung oder ein <strong>Die</strong>nst einen Port nach<br />
eingehenden Verbindungen überwacht.<br />
5156 <strong>Die</strong> <strong>Windows</strong>-Filterplattform hat eine Verbindung erlaubt.<br />
5157 <strong>Die</strong> <strong>Windows</strong>-Filterplattform hat eine Verbindung blockiert.<br />
5158 <strong>Die</strong> <strong>Windows</strong>-Filterplattform hat die Bindung an einen lokalen Port erlaubt.<br />
5159 <strong>Die</strong> <strong>Windows</strong>-Filterplattform hat die Bindung an einen lokalen Port blockiert.
Tabelle 8.5 ACL-Änderungsereignisse (Überwachungsrichtlinienänderung,<br />
ressourcenmanagerspezifische Unterkategorie)<br />
Ereignis-ID Beschreibung<br />
4715 <strong>Die</strong> Überwachungsrichtlinien (SACL) für ein Objekt wurden geändert.<br />
4670 Berechtigungen für ein Objekt wurden geändert.<br />
Tabelle 8.6 Dateifreigabezugriffsereignisse<br />
Ereignis-ID Beschreibung<br />
5140 Es wurde auf ein Netzwerkfreigabeobjekt zugegriffen.<br />
Tabelle 8.7 RPC-Ereignisse<br />
Ereignis-ID Beschreibung<br />
5712 Ein Remoteprozeduraufruf (Remote Procedure Call, RPC) wurde versucht.<br />
Neue Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 235<br />
Tabelle 8.8 Anmeldeereignisse im Bereich der Computernutzung (andere Anmelde/Abmeldeereignisse)<br />
Ereignis-ID Beschreibung<br />
4778 Eine Sitzung wurde erneut mit einer Arbeitsstation verbunden.<br />
4779 Eine Sitzung wurde von einer Arbeitsstation getrennt.<br />
4800 <strong>Die</strong> Arbeitsstation wurde gesperrt.<br />
4801 <strong>Die</strong> Arbeitsstation wurde entsperrt.<br />
4802 Der Bildschirmschoner wurde aktiviert.<br />
4803 Der Bildschirmschoner wurde abgeschaltet.<br />
Außerdem gibt es neue Ereignisse für die folgenden Ereignistypen:<br />
Kryptografieereignisse (Systemintegrität)<br />
IPsec-Ereignisse (völlig neu implementiert)<br />
Ereignisse zu Firewallrichtlinienänderungen (Richtlinienänderungen in MPSSVC-<br />
Regelebenen)<br />
Ereignisse zu Richtlinienänderungen an der Filterungsplattform<br />
<strong>Die</strong> Gesamtzahl der Ereignisse im Bereich <strong>Sicherheit</strong> ist von etwa 200 in <strong>Windows</strong> <strong>Server</strong><br />
2003 auf über 350 in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> gestiegen. Viele Aktivitäten können jetzt zum<br />
ersten Mal überwacht werden. Auf der Begleit-CD finden Sie Dateien mit der vollständigen<br />
Liste aller Ereignisse in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. Sie können eine solche Liste auch selbst<br />
erstellen, indem Sie an der Eingabeaufforderung das Tool WEvtUtil.exe aufrufen:<br />
C:>wevtutil gp Microsoft-<strong>Windows</strong>-Security-Auditing /ge /gm:true<br />
/f:xml > %temp%\WS08_<strong>Sicherheit</strong>sereignisse.xml<br />
C:>notepad %temp%\WS08_<strong>Sicherheit</strong>sereignisse.xml
236 Kapitel 8: Überwachung<br />
Analysieren von Ereignissen mit den eingebauten Tools<br />
<strong>Die</strong> Tools, mit denen Sie Ereignisse in <strong>Windows</strong> analysieren, wurden stark verbessert. <strong>Die</strong><br />
Befehlszeilentools sind nun genauso leistungsfähig wie die grafischen Tools, und die grafischen<br />
Tools wurden deutlich ausgefeilter. Früher konnten Sie anhand von Headerfeldern<br />
filtern und einfache Suchfunktionen nutzen. Jetzt können Sie in beliebigen Feldern aller<br />
Ereignisse suchen. Und Ereignisse können als Text oder XML exportiert und analysiert werden,<br />
sodass Automatisierungsmöglichkeiten genutzt werden können, die früher viel arbeitsintensiver<br />
waren.<br />
Ereignisanzeige<br />
Wie bereits erwähnt, hat sich die Ereignisanzeige, das Hauptwerkzeug in <strong>Windows</strong> zum<br />
Analysieren von Ereignissen, in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> gegenüber den früheren Versionen<br />
gewaltig verbessert.<br />
Wie in älteren Versionen zeigt die Ereignisanzeige eine Liste der Ereignisse an, wenn ein<br />
Protokoll ausgewählt wird. Sie können nach verschiedenen Feldern sortieren, indem Sie auf<br />
den gewünschten Spaltenkopf klicken. In der Ereignisanzeige von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
können Sie Ereignisse auf diese Weise auch gruppieren.<br />
Sehen wir uns diese Gruppierungsmöglichkeiten an einem kleinen Beispiel an. Klicken Sie<br />
in der Ereignisliste mit der rechten Maustaste auf den Kopf der Spalte Aufgabenkategorie<br />
und wählen Sie den Befehl Ereignisse nach dieser Spalte gruppieren. Nach einem Moment<br />
fasst die Ereignisanzeige alle Ereignisse anhand ihrer Unterkategorie zu Gruppen zusammen.<br />
Klicken Sie nun wieder mit der rechten Maustaste auf den Spaltenkopf Aufgabenkategorie<br />
und wählen Sie den Befehl Alle Gruppen reduzieren; Sie erhalten nun eine Ansicht<br />
wie in Abbildung 8.10.<br />
Sie können ein Protokoll filtern, indem Sie im linken Fensterabschnitt der Ereignisanzeige<br />
mit der rechten Maustaste auf den Protokollnamen klicken und den Befehl Aktuelles Protokoll<br />
filtern wählen. Daraufhin öffnet sich das Dialogfeld Aktuelles Protokoll filtern. Wählen<br />
Sie erst einmal nur die <strong>Windows</strong>-Überwachungsereignisse aus. Der Quellenname für diese<br />
Ereignisse lautet Microsoft <strong>Windows</strong> security auditing. Zeigen Sie die Liste der Ereignisquellen<br />
an, indem Sie die Dropdownliste Quellen aufklappen. Wählen Sie die Ereignisquelle<br />
aus, indem Sie das zugehörige Kontrollkästchen aktivieren, und klicken Sie dann irgendwo<br />
außerhalb der Liste. Abbildung 8.11 zeigt ein Beispiel, wie Ereignisse anhand der Ereignisquelle<br />
gefiltert werden.<br />
Jetzt können Sie den Filter so eng fassen, dass nur Ereignisse aus der Unterkategorie Anmelden<br />
angezeigt werden. Wie Sie sich erinnern werden, entspricht die »Unterkategorie« in den<br />
Überwachungsrichtlinien der »Aufgabenkategorie« in der Ereignisanzeige. Klicken Sie auf<br />
die Schaltfläche neben dem Feld Aufgabenkategorie, um die Dropdownliste aufzuklappen,<br />
und aktivieren Sie das Kontrollkästchen neben der Aufgabenkategorie Anmelden. Klicken<br />
Sie irgendwo außerhalb der Liste, um sie wieder einzuklappen. Abbildung 8.12 zeigt ein<br />
Beispiel, wie die Ereignisse anhand der Aufgabenkategorie gefiltert werden.<br />
Wenn Sie alles richtig gemacht haben, bekommen Sie nun nach einem Klick auf OK eine<br />
gefilterte Ereignisliste wie in Abbildung 8.13 angezeigt.
Analysieren von Ereignissen mit den eingebauten Tools 237<br />
Abbildung 8.10 Gruppieren von <strong>Sicherheit</strong>sereignissen in der Ereignisanzeige anhand der<br />
Aufgabenkategorie<br />
Abbildung 8.11 Filtern von Ereignissen in der Ereignisanzeige anhand der Ereignisquelle
238 Kapitel 8: Überwachung<br />
Abbildung 8.12 Filtern von Ereignissen in der Ereignisanzeige anhand der Aufgabenkategorie<br />
Abbildung 8.13 <strong>Die</strong> Ereignisanzeige zeigt nur eine gefilterte Liste mit Anmeldeereignissen an
Analysieren von Ereignissen mit den eingebauten Tools 239<br />
Das Dialogfeld zum Definieren der Filter ist zwar recht leistungsfähig, stellt aber nur einen<br />
Teil der Filterungsfähigkeiten des Ereignissystems zur Verfügung. Indem Sie XPATH nutzen,<br />
können Sie Ereignisse noch viel genauer filtern.<br />
Öffnen Sie das Dialogfeld Aktuelles Protokoll filtern erneut. Klicken Sie dann auf die Registerkarte<br />
XML oben im Dialogfeld. Der angezeigte XPATH-Ausdruck gibt die Optionen wieder,<br />
die Sie auf der Registerkarte Filter ausgewählt haben. Aktivieren Sie das Kontrollkästchen<br />
Manuell bearbeiten und klicken Sie im Bestätigungsdialogfeld auf Ja. Sie können nun<br />
den XPATH-Text editieren. Eine vollständige Beschreibung von XPATH würde den Umfang<br />
dieses Kapitels sprengen, aber es gibt eine simple Änderung, die Sie vornehmen können, um<br />
sich mit den Möglichkeiten vertraut zu machen. Sie können den Filterausdruck so ändern,<br />
dass nur interaktive Anmeldeereignisse angezeigt werden, also Ereignisse mit dem Anmeldetyp<br />
2.<br />
Der im Dialogfeld angezeigte XPATH-Ausdruck sieht so aus:<br />
<br />
<br />
*[System[Provider[@Name='Microsoft-<strong>Windows</strong>-Security-Auditing']<br />
and Task = 12544]]<br />
<br />
<br />
Ändern Sie diesen Code so, dass er wie im folgenden Codeausschnitt aussieht. <strong>Die</strong>ses Listing<br />
wurde umbrochen, um es besser lesbar zu machen. XML ignoriert Leerräume (außerhalb<br />
von Stringliteralen, also Zeichenfolgen, die in Anführungszeichen eingeschlossen<br />
sind). Das Dialogfeld unterstützt übrigens das Kopieren und Einfügen über die Tastenkombinationen<br />
STRG+C und STRG+V, sodass Sie den <strong>Windows</strong>-Editor zum Bearbeiten des<br />
Codes verwenden können.<br />
<br />
<br />
<br />
*[System[Provider[@Name='Microsoft-<strong>Windows</strong>-Security-Auditing'] and Task = 12544]<br />
and EventData[Data[@Name='LogonType'] = '2']]<br />
<br />
<br />
<br />
Klicken Sie auf OK, wenn Sie die Änderungen vorgenommen haben. <strong>Die</strong> Ereignisanzeige<br />
wendet den Filter an, woraufhin Sie nur noch interaktive Anmeldeereignisse angezeigt bekommen.<br />
Sehen Sie sich einige dieser Ereignisse an und überzeugen Sie sich, dass bei allen<br />
das Feld Anmeldetyp den Wert 2 hat. Falls Sie einen Fehler gemacht haben, informiert die<br />
Ereignisanzeige Sie darüber. Sie können dann im Menü Aktion den Befehl Filter löschen<br />
wählen, um den Filter zu entfernen, und neu beginnen. Abbildung 8.14 zeigt den XML-<br />
Filterausdruck.
240 Kapitel 8: Überwachung<br />
Abbildung 8.14 Bearbeiten des XPATH-Filterausdrucks in der Ereignisanzeige<br />
XPATH für Anfänger<br />
Sie brauchen kein XPATH-Experte zu sein, um die Registerkarte XML im Filterdialogfeld<br />
der Ereignisanzeige zu nutzen. Normalerweise finden Sie am einfachsten einen Einstieg,<br />
wenn Sie folgendermaßen vorgehen:<br />
1. Geben Sie ein Ereignis, das Sie interessiert, im XML-Format aus, sodass sie seine<br />
Datenfeldfelder sehen können.<br />
2. Stellen Sie auf der Registerkarte Filter in der grafischen Benutzeroberfläche ein Ereignis<br />
zusammen, das dem gewünschten Ergebnis am nächsten kommt.<br />
3. Bearbeiten Sie das Select-Element in der Registerkarte XML so, dass es die Datenelemente<br />
mit den konkreten Werten auswählt, für die Sie sich interessieren.<br />
Der XPATH-Ausdruck im Select-Element wird als Abfolge von Pfaden für XML-<br />
Elemente zusammengesetzt. Sehen wir uns einen XPATH-Ausdruck als Beispiel an:<br />
*[System[Provider[@Name='Microsoft-<strong>Windows</strong>-Security-Auditing'] and Task = 12544] and<br />
EventData[Data[@Name='LogonType'] = '2']]<br />
<strong>Die</strong>ser Ausdruck sucht nach XML, das folgendermaßen aussieht:<br />
<br />
<br />
12544<br />
<br />
<br />
2<br />
Analysieren von Ereignissen mit den eingebauten Tools 241<br />
Woher wissen wir das? Erstens verrät der Stern am Anfang: »Alle Ereignisse, die folgende<br />
Kriterien erfüllen«. Anschließend verwendet der XPATH-Ausdruck eckige statt runde<br />
Klammern, um Elemente zu gruppieren, daher müssen wir sie sorgfältig zählen. XPATH<br />
meldet einen Fehler, wenn zu viele eckige Klammern vorhanden sind.<br />
Anschließend folgt dieser Ausdruck:<br />
System[<br />
Das bedeutet, dass alle Elemente innerhalb des Ereignisses die Kriterien erfüllen, die den<br />
Namen »System« tragen. Im <strong>Windows</strong>-Ereignisschema gibt es immer ein -Element.<br />
Der nächste Ausdruck bedeutet, dass das -Element in dem gerade gefundenen<br />
Element () gesucht wird:<br />
Provider[@Name='Microsoft-<strong>Windows</strong>-Security-Auditing']<br />
Das bedeutet, dass wir nur an -Elementen interessiert sind, bei denen das Attribut<br />
Name den Wert Microsoft-<strong>Windows</strong>-Security-Auditing hat. <strong>Die</strong>s ist der Standardname<br />
des Überwachungsereignisanbieters in <strong>Windows</strong>. Achten Sie genau auf die schließende<br />
eckige Klammer (]) hinter der @Name-Klausel. Der nächste Teil der Abfrage ist ein and-<br />
Ausdruck. Das bedeutet, dass wir mit dem -Element fertig sind.<br />
Der nächste Teil der Abfrage verrät, dass wir das untergeordnete -Element im<br />
-Element suchen (mit sind wir ja bereits fertig):<br />
and Task=12544]<br />
Nur Task-Elemente mit dem Wert 12544 erfüllen also die Kriterien. Beachten Sie auch,<br />
dass wir den Elementwert vergleichen, nicht ein Attribut. <strong>Die</strong> schließende Klammer verrät,<br />
dass wir mit dem -Element fertig sind. Passen Sie immer auf, welche Klammer<br />
sich auf welches Element bezieht.<br />
<strong>Die</strong> nächste Klausel ist etwas komplexer, aber sie ist wichtig. Hier bekommen Sie nämlich<br />
die Informationen aus dem Data-Abschnitt von Ereignissen:<br />
and EventData[<br />
Das verrät uns, dass wir das untergeordnete -Element im Ereignis suchen.<br />
Das nächste Stück erledigt praktisch die ganze Arbeit:<br />
Data[@Name='LogonType'] = '2']<br />
Das besagt im Wesentlichen: Suche -Elemente mit dem Wert 2, aber nur, falls sie<br />
ein Attribut namens Name mit dem Wert LogonType haben. Das ist ein wirklich komplexer<br />
Weg, in XML zu beschreiben, dass wir Ereignisse suchen, bei denen LogonType=2 ist.<br />
<strong>Die</strong> letzte schließende Klammer am Ende des Ausdrucks schließt den Abschnitt für das<br />
-Element im XPATH-Ausdruck ab.<br />
Schließlich wird der gesamte Ausdruck mit einer schließenden Klammer beendet. Wenn<br />
Sie die Klammern zählen, stellen Sie fest, dass es gleich viel öffnende und schließende<br />
Klammern gibt. Jetzt brauchen Sie den Ausdruck nur noch auszuprobieren!
242 Kapitel 8: Überwachung<br />
WEvtUtil<br />
Das Befehlszeilenprogramm EventQuery aus <strong>Windows</strong> <strong>Server</strong> 2003 wurde mit einem neuen<br />
Tool namens WEvtUtil ersetzt. WEvtUtil kann das gesamte Ereignissystem über die Eingabeaufforderung<br />
verwalten.<br />
Bearbeiten Sie die XPATH-Abfrage aus dem vorherigen Beispiel im <strong>Windows</strong>-Editor. (Sie<br />
können den Filter anzeigen und ihn mit der Tastenkombination STRG+C in die Zwischenablage<br />
kopieren.) Sie können WEvtUtil eine XML-Datei als Eingabe übergeben, aber in diesem<br />
Fall verwenden Sie nur den Filterausdruck.<br />
<br />
<br />
<br />
*[System[Provider[@Name='Microsoft-<strong>Windows</strong>-Security-Auditing'] and Task = 12544]<br />
and EventData[Data[@Name='LogonType'] = '2']]<br />
<br />
<br />
<br />
Bearbeiten Sie diesen Text und entfernen Sie die XML-Tags. Es darf nur der reine Filterausdruck<br />
übrig bleiben (der Text zwischen den -Tags). Entfernen Sie alle Zeilenumbrüche<br />
aus dem Text.<br />
*[System[Provider[@Name='Microsoft-<strong>Windows</strong>-Security-Auditing'] and Task = 12544] and<br />
EventData[Data[@Name='LogonType'] = '2']]<br />
Kopieren Sie den fertigen Text in die Zwischenablage und öffnen Sie eine Eingabeaufforderung.<br />
Geben Sie an der Eingabeaufforderung den folgenden Befehl ein. Sie können den<br />
XPATH-Ausdruck über das Anwendungsmenü (linke obere Ecke) der Eingabeaufforderung<br />
einfügen. Der vollständige Befehl sieht so aus:<br />
C:\>wevtutil qe Security /q:“*[System[Provider[@Name='Microsoft-<strong>Windows</strong>- Security-Auditing']<br />
and Task = 12544] and EventData[Data[@Name= 'LogonType'] = '2']]”<br />
Wenn Sie die EINGABETASTE drücken, gibt WEvtUtil die Ereignisse im XML-Format an<br />
der Eingabeaufforderung aus. Sie können diese Ausgabe in eine Textdatei umleiten und mit<br />
einem anderen Programm ansehen. WEvtUtil stellt auch Befehlszeilenoptionen zur Verfügung,<br />
mit denen Sie die Ausgabe im Text- oder RenderedXML-Format generieren können.<br />
RenderedXML enthält neben dem XML des Ereignisses auch den Text.<br />
Beachten Sie, dass das XML, das WEvtUtil generiert, nicht ganz standardgerecht ist. Es hat<br />
keine XML-Deklaration und besteht normalerweise nicht aus einem Element. Falls Sie mit<br />
Automatisierung arbeiten, ist es unter Umständen sinnvoll, ein XMLDecl und ein Tag am Anfang<br />
der WEvtUtil-Ausgabe einzufügen und ein schließendes Tag am Ende anzufügen. So<br />
stellen Sie sicher, dass Ihre Automatisierungslösung standardgerechtes XML erhält.<br />
Zusammenfassung<br />
Auch wenn es einige Arbeit bedeutet, die Richtlinien zu entwerfen und die Einstellungen<br />
auszuwählen, ist es wahrscheinlich sehr sinnvoll, detaillierte Überwachungsrichtlinien bereitzustellen,<br />
falls Sie <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> oder <strong>Windows</strong> Vista in Ihrer Organisation einsetzen.
Zusammenfassung 243<br />
Aktivieren Sie gerade so viel Überwachung, dass Ihre Anforderungen erfüllt werden. Etwas<br />
Überwachung ist sinnvoll, aber wenn Sie alles aktivieren, bekommen Sie wahrscheinlich<br />
Schwierigkeiten, Ihre <strong>Sicherheit</strong>sereignisprotokolle bei einem solchen Umfang noch in den<br />
Griff zu bekommen.<br />
Aktivieren Sie die Überwachung, bevor ein Problem auftritt. Überwachungsereignisse treten<br />
auf, wenn eine überwachte Aktivität passiert. Falls eine solche Aktivität stattfindet, aber die<br />
Überwachung nicht aktiviert ist, ist das Ereignis für immer verloren.<br />
Und schließlich sollten Sie nicht erwarten, dass Überwachung ein Allheilmittel ist. Überwachung<br />
zeichnet auf, was im System passiert. Im <strong>Sicherheit</strong>sprotokoll befindet sich eine<br />
Menge nützlicher Informationen. Sie können alle Arten von Aktivitäten überwachen, wenn<br />
Sie vorausplanen. Aber Überwachung ist kein Privatdetektiv: Sie kann Ereignisse nicht beurteilen,<br />
und sie teilt Ihnen nicht mit: »<strong>Die</strong>ses Ereignis bedeutet, dass einer Ihrer Angestellten<br />
Ihre Daten stiehlt.« Das müssen Sie schon selbst herausfinden.
T E I L I I<br />
Implementieren von Identitäts- und<br />
Zugriffssteuerung mit Active Directory<br />
In diesem Teil:<br />
Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong> ............ 247<br />
Kapitel 10: Implementieren der Active Directory-Zertifikatdienste ................... 273<br />
Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste ............ 291
K A P I T E L 9<br />
Optimieren der Active Directory-<br />
Domänendienste für <strong>Sicherheit</strong><br />
Von Jimmy Andersson<br />
In diesem Kapitel:<br />
<strong>Die</strong> neue Benutzeroberfläche ........................................... 248<br />
Der neue Assistent zum Installieren von Active Directory-Domänendiensten . ........... 250<br />
Schreibgeschützte Domänencontroller ..................................... 252<br />
Neustartfähige Active Directory-Domänendienste .............................. 258<br />
Active Directory-Datenbankbereitstellung ................................... 259<br />
AD DS-Überwachung . ................................................ 261<br />
Grundlagen von AD LDS .............................................. 266<br />
Grundlagen der Active Directory-Verbunddienste .............................. 269<br />
Zusammenfassung .................................................. 271<br />
Weitere Informationen ................................................ 271<br />
Als ich begann, mir die Active Directory-Domänendienste (Active Directory Domain Services,<br />
AD DS) in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> anzusehen, wurde schnell klar, dass Microsoft sich<br />
darauf konzentriert hatte, die <strong>Sicherheit</strong> zu verbessern und die Bereitstellung und Verwaltung<br />
von AD DS einfacher zu machen. Ich beschreibe in diesem Kapitel mehrere neue Features,<br />
aber zuerst möchte ich Ihnen kurz dasjenige vorstellen, das ich für das wichtigste<br />
halte: den schreibgeschützten Domänencontroller (Read-Only Domain Controller, RODC).<br />
Sie fragen sich möglicherweise, warum ich diese Technologie für so wichtig halte. Ganz<br />
einfach: <strong>Die</strong> meisten meiner Kunden sind international tätige Organisationen mit mehreren<br />
Zweigstellen, die sich über die gesamte Welt verteilen. <strong>Die</strong> meisten davon sind lediglich<br />
Vertriebsbüros oder Produktionsstandorte mit geringer Bandbreite zum Zentralstandort, und<br />
oft ist in diesen Zweigstellen die physische <strong>Sicherheit</strong> der Domänencontroller sehr lax oder<br />
gar nicht vorhanden.<br />
In diesen Fällen ist es unverzichtbar, dass wir in der Lage sind, den Benutzern einerseits eine<br />
schnelle Anmeldung zu ermöglichen, aber andererseits auch zu steuern, was wir tatsächlich<br />
auf dem Domänencontroller (Domain Controller, DC) zur Verfügung stellen. Der RODC<br />
hilft Ihnen, Ihre DCs in Fällen wie diesen zu schützen. In den nächsten Abschnitten stelle<br />
ich die neuen Features genauer vor.<br />
247
248 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
<strong>Die</strong> neue Benutzeroberfläche<br />
Microsoft-Kunden haben schon seit einiger Zeit eine einfacher bedienbare grafische Benutzeroberfläche<br />
für die Installation von AD DS gefordert. Jetzt gibt es einen aktualisierten<br />
Installationsassistenten und neue AD DS-Installationsoptionen. Microsoft stellt auch einige<br />
neue Verwaltungsoptionen für Features wie zum Beispiel einen RODC zur Verfügung, und<br />
nützliche Features wie die Möglichkeit, alle DCs in einem gesamten Großunternehmen zu<br />
finden. Wir Administratoren haben viel Zeit damit verbracht, Verbindungen zu einer Domäne<br />
nach der anderen herzustellen, um diesen ganz bestimmten DC zu finden, dessen Position<br />
wir vergessen hatten. Viele von uns haben die Microsoft Management Console (MMC) links<br />
liegen gelassen und stattdessen ein Skript geschrieben, das die gesamte Domänenhierarchie<br />
durchsucht.<br />
Ein anderes nettes Feature der neuen Benutzeroberfläche ist die Fähigkeit, ein Objekt direkt<br />
auf den Eigenschaftenseiten des Objekts vor einer versehentlichen Löschung zu schützen.<br />
Wenn Sie das Kontrollkästchen Objekt vor zufälligem Löschen schützen aktivieren (Abbildung<br />
9.1), wird die <strong>Sicherheit</strong>sbeschreibung so aktualisiert, dass ein Löschen des Objekts<br />
verhindert wird. Damit dieses Kontrollkästchen und die Registerkarte Objekt sichtbar sind,<br />
müssen Sie in der Konsole Active Directory-Benutzer und -Computer im Menü Ansicht den<br />
Befehl Erweiterte Features auswählen.<br />
Abbildung 9.1 <strong>Die</strong> neue Konsole Active Directory-Benutzer<br />
und -Computer enthält die Registerkarte Objekt, auf der Sie<br />
verhindern können, dass ein Objekt versehentlich gelöscht wird<br />
<strong>Die</strong>ses neue Feature hilft Ihnen, wichtige Objekte vor einer versehentlichen Löschung zu<br />
schützen. Falls Sie Administrator sind, können Sie das Kontrollkästchen jederzeit deaktivieren<br />
und das Objekt dann löschen. Aber dazu ist zumindest ein zusätzlicher Schritt erforderlich,<br />
um sich noch einmal zu überlegen, ob Sie das Objekt wirklich löschen wollen. Wenn
<strong>Die</strong> neue Benutzeroberfläche 249<br />
Sie eine neue Organisationseinheit (Organizational Unit, OU) anlegen, ist diese Einstellung<br />
standardmäßig aktiviert.<br />
Einer der größten Nachteile bei der Konsole Active Directory-Benutzer und -Computer in<br />
Vorgängerversionen war, dass Sie nicht alle verfügbaren Attribute zu einem Objekt angezeigt<br />
bekamen. Viele meiner Kunden verwenden mehr Attribute, als innerhalb der Konsole<br />
Active Directory-Benutzer und -Computer sichtbar sind. Das ließ ihnen zwei Möglichkeiten:<br />
Entweder sie schreiben ihre eigene grafische Benutzeroberfläche, um die Konsole Active<br />
Directory-Benutzer und -Computer zu erweitern, oder sie verwenden ADSIEdit.msc. Falls<br />
Sie keine Zeit oder Lust haben, eine neue oder erweiterte grafische Benutzeroberfläche zu<br />
entwickeln, bleibt Ihnen also nur ADSIEdit.msc. Damit Sie mich nicht falsch verstehen: Ich<br />
mag ADSIEdit.msc. Aber es ist nicht gerade das benutzerfreundlichste Tool, das ich je gesehen<br />
habe, besonders wenn Helpdesk-Personal Benutzer anlegen und dann Attribute zuweisen<br />
soll, die in der Konsole Active Directory-Benutzer und -Computer standardmäßig nicht<br />
angezeigt werden. Und wenn Sie in Eile sind, ist dabei schnell ein Fehler passiert. Schließlich<br />
dauert es auch noch sehr lange, ein bestimmtes Objekt zu finden, falls ein Container<br />
viele Objekte enthält. In der neuen Konsole Active Directory-Benutzer und -Computer gibt<br />
es eine zusätzliche Registerkarte namens Attribut-Editor, auf der die verfügbaren Attribute<br />
für das Objekt angezeigt werden. Sie können die Attribute also direkt in der Konsole Active<br />
Directory-Benutzer und -Computer bearbeiten. Sie müssen lediglich die Option Erweiterte<br />
Features im Menü Ansicht der Konsole Active Directory-Benutzer und -Computer aktivieren.<br />
Sie brauchen die Benutzeroberfläche nicht zu erweitern und keine speziellen Tools zu<br />
entwickeln <strong>–</strong> zumindest nicht für diesen Zweck. Abbildung 9.2 zeigt diese neue Registerkarte.<br />
Abbildung 9.2 <strong>Die</strong> neue Konsole Active Directory-Benutzer und<br />
-Computer enthält die Registerkarte Attribut-Editor, auf der Sie Attribute<br />
bearbeiten können, für die es keine einfache Schnittstelle gibt
250 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
Was mir sofort positiv auffiel, war die Tatsache, dass ich überhaupt nichts Besonderes tun<br />
musste, um die neuen Verbesserungen nutzen zu können. Sie alle stehen in der Standardeinstellung<br />
zur Verfügung. Auch wenn Sie für manche Features die Option Erweiterte Features<br />
in der Konsole Active Directory-Benutzer und -Computer oder ein Kontrollkästchen aktivieren<br />
müssen, stehen sie in der GUI zur Verfügung. Sehen wir uns ein Beispiel an: Nehmen<br />
wir an, Sie wollen die erweiterten Seiten im AD DS-Installationsassistent sehen; in diesem<br />
Fall brauchen Sie nur das Kontrollkästchen Installation im erweiterten Modus verwenden<br />
auf der Willkommen-Seite des Assistenten zu aktivieren (Abbildung 9.3.)<br />
Abbildung 9.3 <strong>Die</strong> neue Willkommen-Seite des AD DS-Installationsassistenten<br />
bietet die Möglichkeit, die Installation im erweiterten Modus durchzuführen<br />
Der neue Assistent zum Installieren von Active Directory-<br />
Domänendiensten<br />
Um AD DS zu installieren, verwenden Sie den Assistenten "Rollen hinzufügen". Weitere<br />
Informationen über <strong>Server</strong>rollen finden Sie in Kapitel 12, »Schützen von <strong>Server</strong>rollen«. Sie<br />
öffnen den Assistenten "Rollen hinzufügen", indem Sie im Fenster Aufgaben der Erstkonfiguration,<br />
das nach der Installation des Betriebssystems erscheint, auf Rollen hinzufügen<br />
klicken. Sie können den Assistenten "Rollen hinzufügen" auch im <strong>Server</strong>-Manager starten,<br />
den Sie im Untermenü Verwaltung des Startmenüs finden.<br />
Weitere Domänencontrolleroptionen Auf dieser Seite können Sie zusätzliche Optionen<br />
für den DC konfigurieren, zum Beispiel DNS, GC oder RODC (Abbildung 9.4.)
Der neue Assistent zum Installieren von Active Directory-Domänendiensten 251<br />
Abbildung 9.4 <strong>Die</strong> neue Seite im Assistenten zum Installieren von Active Directory<br />
stellt zusätzliche Optionen für die Domänencontrollerinstallation zur Verfügung<br />
Domäne auswählen Mit dieser Option können Sie die Domäne angeben, falls Sie<br />
einen weiteren DC installieren wollen.<br />
Standort auswählen Auf dieser Seite können Sie angeben, zu welchem Standort der<br />
DC nach der Installation gehören soll.<br />
Funktionsebene der Gesamtstruktur festlegen Wenn Sie den ersten DC in einer<br />
neuen Gesamtstruktur oder Domäne installieren, können Sie auf dieser Seite die Funktionsebene<br />
festlegen.<br />
Delegierung der Installation und Verwaltung des RODC Auf dieser Seite können<br />
Sie den Namen der Gruppe oder des Benutzers festlegen, an die Sie Administration und<br />
weitere Installation delegieren wollen.<br />
Richtlinie für die Kennwortreplikation angeben Auf dieser Seite können Sie festlegen,<br />
welche Kontokennwörter auf einem RODC zwischengespeichert werden dürfen und<br />
welche nicht. <strong>Die</strong>se Seite erscheint nur, falls Sie das Kontrollkästchen Installation im<br />
erweiterten Modus verwenden aktivieren. Siehe »Zwischenspeichern von Anmeldeinformationen«<br />
weiter unten in diesem Kapitel.<br />
DNS-Delegierung Abhängig davon, welchen Typ von DC-Installation Sie angegeben<br />
haben und wie Ihre DNS-Umgebung aufgebaut ist, erhalten Sie auf dieser Seite eine<br />
Standardoption angeboten, um eine DNS-Delegierung zu erstellen.<br />
Andere Änderungen an diesem Assistenten zeigen, dass Microsoft den Prozess zum Installieren<br />
eines Domänencontrollers so einfach und fehlerfrei wie möglich machen will. Zum<br />
Beispiel brauchen Sie den Domänennamen nicht einzugeben, wenn Sie einen weiteren<br />
Domänencontroller installieren. Stattdessen können Sie die Domäne in einer Strukturansicht<br />
auswählen. So besteht keine Gefahr, dass Sie sich beim Eingeben des Domänennamens<br />
vertippen. Außerdem verwendet der Assistent jetzt die Anmeldeinformationen des Benut-
252 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
zers, der momentan angemeldet ist, um die Installation abzuschließen (sofern der Benutzer<br />
mit einem Domänenkonto angemeldet ist). Natürlich haben Sie die Möglichkeit, bei Bedarf<br />
andere Anmeldeinformationen zu verwenden. Ein weiteres nettes Feature ist, dass am Ende<br />
des Assistenten eine Zusammenfassungsseite angezeigt wird, die Sie direkt in eine Antwortdatei<br />
exportieren können. Sie können diese Datei dann als Vorlage für andere Installationen<br />
und Deinstallationen hernehmen. Aus <strong>Sicherheit</strong>sgründen stehen nicht alle Informationen in<br />
der Antwortdatei zur Verfügung. Zum Beispiel wird das Kennwort für die Verzeichnisdienstwiederherstellung<br />
(Directory Services Restore Mode, DSRM) nicht mit in die Datei exportiert.<br />
Sie können die Antwortdatei so ändern, dass sie spezifische Werte enthält. Passen Sie<br />
dabei aber genau auf, weil die Datei in falsche Hände gelangen könnte. Bezüglich der Kennwörter<br />
empfehle ich, password=* in die Antwortdatei einzutragen, dann werden Sie beim<br />
Ausführen aufgefordert, das Kennwort einzugeben.<br />
Schreibgeschützte Domänencontroller<br />
Am Anfang des Kapitels habe ich bereits erwähnt, dass Microsoft seit <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
einen neuen Typ Domänencontroller zur Verfügung stellt: den schreibgeschützten Domänencontroller<br />
(Read-Only Domain Controller, RODC). Mit dem RODC können Organisationen<br />
einen DC an Orten bereitstellen, wo die physische <strong>Sicherheit</strong> nicht garantiert werden kann.<br />
Ein RODC hostet schreibgeschützte Partitionen der AD DS-Datenbank. Das hat den großen<br />
Vorteil, dass Sie Ihre Umgebung besser schützen können. Bevor die Rolle des RODC zur<br />
Verfügung stand, hielt ich den DC in der Zweigstelle immer für den schwächsten Punkt. (In<br />
Kapitel 15, »Schützen von Zweigstellen«, wird genauer erklärt, was eine Zweigstelle ist und<br />
welche Auswirkungen die Verwendung eines RODC auf die <strong>Sicherheit</strong> hat.) Mit dieser neuen<br />
Rolle können wir nun die beschreibbaren DCs in den zentralen Standort mit einem richtigen<br />
Datencenter verlegen und die beschreibbaren DCs in der Zweigstelle durch RODCs ersetzen.<br />
Das verringert die <strong>Sicherheit</strong>sgefahren.<br />
Vor der Einführung des RODC mussten sich Benutzer in einer Zweigstelle bei einem DC im<br />
zentralen Standort über ein WAN (Wide Area Network) authentifizieren. Oder Sie stellten<br />
einen lokalen DC in der Zweigstelle bereit. Das war keine effiziente Lösung, weil kleine<br />
Standorte oft nicht die physische <strong>Sicherheit</strong> bieten, die ein beschreibbarer DC erfordert. <strong>Die</strong><br />
Netzwerkbandbreite zwischen einer Zweigstelle und einem zentralen Standort ist jedoch oft<br />
schlecht. Das kann bei Zweigstellenbenutzern die Anmeldezeiten verlängern und den Zugriff<br />
auf Netzwerkressourcen behindern. Jetzt können Sie diese Probleme aber umgehen, indem<br />
Sie einen RODC in Ihren Zweigstellen bereitstellen. Damit bieten Sie Ihren Zweigstellenbenutzern<br />
folgende Vorteile:<br />
Verbesserte <strong>Sicherheit</strong><br />
Schnellere Anmeldung<br />
Effizienterer Zugriff auf Ressourcen im Netzwerk<br />
Einer der wichtigsten Gründe für den Einsatz eines RODC ist meiner Meinung nach die<br />
ungenügende physische <strong>Sicherheit</strong>. Schließlich wissen wir alle, dass Computersicherheit bei<br />
der physischen <strong>Sicherheit</strong> beginnt. Wie kann ein RODC Ihnen hier helfen? Er bietet eine<br />
Möglichkeit, einen DC sicherer an Orten bereitzustellen, wo Sie schnelle und zuverlässige<br />
Authentifizierungsdienste brauchen, aber die physische <strong>Sicherheit</strong> nicht gewährleisten können.<br />
Das ist meiner Ansicht nach eine Grundvoraussetzung für den Einsatz eines beschreibbaren<br />
DCs. Ein anderes gutes Beispiel für den Einsatz eines RODCs ist ein Szenario, in dem
Schreibgeschützte Domänencontroller 253<br />
Sie spezielle Anforderungen haben, weil zum Beispiel eine Anwendung auf einem DC installiert<br />
sein muss. Oder wenn der einzige lokale <strong>Server</strong> im Standort der DC ist und Sie darauf<br />
auch Anwendungen hosten müssen. Der Besitzer einer Anwendung muss sich oft interaktiv<br />
an einem DC anmelden oder die Terminaldienste verwenden, um die Anwendung<br />
zu konfigurieren und zu verwalten. Das verursacht ein inakzeptables <strong>Sicherheit</strong>srisiko auf<br />
einem beschreibbaren DC. Ein weiteres Beispiel ist ein Szenario, in dem die lokale Speicherung<br />
aller Domänenbenutzerkennwörter eine Bedrohung verursacht, zum Beispiel in einem<br />
Extranet oder wenn eine Anwendung zur Verfügung gestellt wird. Meiner Ansicht nach ist<br />
das wichtigste Einsatzgebiet für den RODC die Bereitstellung in Remote- oder Zweigstellenumgebungen.<br />
Schreibgeschützte AD DS-Datenbank<br />
Der RODC speichert alle Active Directory-Objekte und -Attribute, die auch ein beschreibbarer<br />
DC verwaltet, aber Sie können keine Änderungen an seiner Datenbank vornehmen. Sie<br />
müssen Änderungen auf einem beschreibbaren DC durchführen und sie dann zurück auf den<br />
RODC replizieren. Eine lokale Anwendung, die Lesezugriff auf das Verzeichnis anfordert,<br />
erhält diesen Zugriff. Eine Anwendung, die Schreibzugriff anfordert, bekommt als Antwort<br />
eine LDAP-Umleitung. Das bedeutet, dass die Anwendung von der Antwort auf einen beschreibbaren<br />
DC verwiesen wird, wo sie den gewünschten Zugriff erhalten kann.<br />
RODC-gefilterte Attributsätze<br />
Keine Attribute, die im RODC-gefilterten Attributsatz definiert sind, dürfen auf irgendwelche<br />
RODCs in der Gesamtstruktur repliziert werden. Falls Sie also Anwendungen haben, die<br />
mit AD DS Authentifizierungsdaten wie zum Beispiel Kennwörter, Anmeldeinformationen<br />
oder Verschlüsselungsschlüssel speichern, und Sie nicht wollen, dass diese Daten auf einem<br />
RODC gespeichert werden (weil er kompromittiert werden könnte), können Sie diesen Satz<br />
von Attributen dynamisch als Teil des gefilterten Attributsatzes im Schema für Domänenobjekte<br />
definieren. Der Attributsatz wird dann niemals auf irgendwelche RODC repliziert.<br />
Falls ein böswillige Benutzer einen RODC kompromittiert und versucht, ihn so zu konfigurieren,<br />
dass er Attribute repliziert, die im RODC-gefilterten Attributsatz liegen, wird die<br />
Replikationsanforderung verweigert, sobald der RODC das nächste Mal versucht, diese<br />
Attribute von einem <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-DC zu replizieren. Aber falls der RODC versucht,<br />
diese Attribute von einem <strong>Windows</strong> <strong>Server</strong> 2003-DC zu replizieren, wird die Replikationsanforderung<br />
zugelassen. Falls Sie den RODC-gefilterten Attributsatz verwenden wollen,<br />
sollten Sie sicherstellen, dass Ihre Gesamtstrukturfunktionsebene <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
lautet. Falls die Gesamtstrukturfunktionsebene <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ist, sind keine <strong>Windows</strong><br />
<strong>Server</strong> 2003-DCs in der Gesamtstruktur erlaubt. Ein kompromittierter RODC lässt<br />
sich also nicht auf diese Weise missbrauchen.<br />
Um sicherzustellen, dass die AD DS-Funktionalität nicht von Hand fehlkonfiguriert wird,<br />
dürfen Sie keine systemkritischen Attribute zum RODC-gefilterten Attributsatz hinzufügen.<br />
Ein Attribut ist systemkritisch, falls es gebraucht wird, damit AD DS richtig funktioniert.<br />
Beispiele sind LSA (Local Security Authority), <strong>Sicherheit</strong>skontenverwaltung (Security Accounts<br />
Manager, SAM) und Microsoft-spezifische SSPIs (Security Service Provider Interface)<br />
wie etwa Kerberos. Bei einem systemkritischen Attribut ist der Attributwert schema-<br />
FlagsEx gleich 1 (schemaFlagsEx-Attributwert & 0x1 = TRUE).
254 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
Wenn Sie den RODC-gefilterten Attributsatz konfigurieren wollen, müssen Sie das auf dem<br />
<strong>Server</strong> tun, der die Rolle des Schemabetriebsmasters einnimmt. Falls Sie versuchen, ein<br />
systemkritisches Attribut zum RODC-gefilterten Satz hinzuzufügen, und der Schemamaster<br />
unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> läuft, gibt der <strong>Server</strong> den LDAP-Fehler unwillingToPerform<br />
zurück. Falls Sie versuchen, auf einem <strong>Windows</strong> <strong>Server</strong> 2003-Schemamaster ein systemkritisches<br />
Attribut zum RODC-gefilterten Attributsatz hinzuzufügen, scheint die Operation<br />
erfolgreich zu verlaufen, aber das Attribut wird nicht wirklich hinzugefügt. Aus diesem<br />
Grund <strong>–</strong> und um sicherzustellen, dass keine systemkritischen Attribute im RODC-gefilterten<br />
Attributsatz auftauchen <strong>–</strong> empfehle ich, die Schemamasterrolle auf einem <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong>-DC zu betreiben, wenn Sie Attribute zu einem RODC-gefilterten Satz hinzufügen<br />
wollen. Auf der Begleit-CD finden Sie eine Microsoft Office Excel-Datei, die dieses Standardschema<br />
für <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> dokumentiert.<br />
Unidirektionale Replikation<br />
Weil wir nicht direkt in den RODC schreiben, stammen keine Änderungen aus dem RODC.<br />
Und das bedeutet auch, dass die beschreibbaren DCs, die Replikationspartner für den RODC<br />
sind, keine Änderungen vom RODC abzurufen brauchen. Das verringert die Belastung der<br />
Bridgeheadserver in der Zentralstelle und den Aufwand zum Überwachen der Replikation.<br />
Keinerlei Änderungen oder Zerstörungen, die ein böswilliger Benutzer an einem RODC<br />
vornimmt, können vom RODC in die übrige Gesamtstruktur repliziert werden.<br />
<strong>Die</strong> unidirektionale Replikation des RODCs gilt sowohl für AD DS- als auch DFS-Replikation<br />
(Distributed File System, Verteiltes Dateisystem). Der RODC führt die normale eingehende<br />
Replikation für AD DS- und DFS-Replikationsänderungen durch.<br />
Zwischenspeichern von Anmeldeinformationen<br />
<strong>Die</strong> Standardeinstellung für einen RODC lautet, ausschließlich Benutzer- oder Computeranmeldeinformationen<br />
für das Computerskonto des RODCs selbst und ein spezielles krbtgt-<br />
Konto für den RODC zu speichern. Jede weitergehende Zwischenspeicherung von Anmeldeinformationen<br />
auf dem RODC müssen Sie explizit konfigurieren. In Kapitel 15 finden Sie<br />
weitere Informationen zu diesem Thema.<br />
In Zweigstellen, die einen RODC haben, kündigt sich der RODC selbst als das Schlüsselverteilungscenter<br />
(Key Distribution Center, KDC) an, aber wenn er TGT-Anforderungen<br />
(Ticket-Granting Ticket) signiert oder verschlüsselt, verwendet der RODC ein anderes<br />
krbtgt-Konto und -Kennwort als das KDC auf einem beschreibbaren DC.<br />
Nach der erfolgreichen Authentifizierung eines Kontos versucht der RODC, Kontakt mit<br />
einem beschreibbaren DC im zentralen Standort aufzunehmen und eine Kopie der entsprechenden<br />
Anmeldeinformationen anzufordern. Der beschreibbare DC erkennt, dass diese<br />
Anforderung von einem RODC stammt, und prüft die gültige Kennwortreplikationsrichtlinie<br />
für diesen RODC (Abbildung 9.5).<br />
<strong>Die</strong> Kennwortreplikationsrichtlinie legt dann fest, ob die Anmeldeinformationen eines Benutzers<br />
oder Computers vom beschreibbaren DC auf den RODC repliziert werden können.<br />
Falls die Kennwortreplikationsrichtlinie dies erlaubt, repliziert der beschreibbare DC die<br />
Anmeldeinformationen in den RODC und der RODC legt sie für künftige Verwendung in<br />
einem Zwischenspeicher ab. Wenn die Anmeldeinformationen auf dem RODC zwischengespeichert<br />
wurden, kann der RODC direkt die Anmeldeanforderungen dieses Benutzers
Schreibgeschützte Domänencontroller 255<br />
bedienen, bis sich die Anmeldeinformationen ändern. Das bedeutet, dass die Daten nicht<br />
bei jeder Anmeldeanforderung über das WAN befördert werden müssen. Wenn ein TGT mit<br />
dem krbtgt-Konto des RODCs signiert ist, erkennt der RODC, dass er eine zwischengespeicherte<br />
Kopie der Anmeldeinformationen hat. Falls dagegen ein anderer DC das TGT signiert<br />
hat, leitet der RODC Anforderungen an einen beschreibbaren DC weiter.<br />
Abbildung 9.5 <strong>Die</strong> Standardrichtlinie für die Kennwortreplikation während einer RODC-Installation<br />
Sie sollten die Zwischenspeicherung von Anmeldeinformationen auf Benutzer beschränken,<br />
die tatsächlich auf dem RODC authentifiziert werden müssen. So dämmen Sie die Gefahr<br />
ein, dass bei einer Kompromittierung des RODCs viele Anmeldeinformationen bekannt<br />
werden. Ich empfehle Ihnen, nur für einen kleinen Teil der Domänenbenutzer die Zwischenspeicherung<br />
ihrer Anmeldeinformationen auf einem bestimmten RODC zu erlauben. Sollte<br />
der RODC gestohlen werden, können nur die Anmeldeinformationen geknackt werden, die<br />
dort zwischengespeichert wurden. Und in den meisten Fällen sind dies nur Domänenbenutzer,<br />
die keine privilegierten Rechte haben. Ein Administrator kann die Standardkennwortreplikationsrichtlinie<br />
so ändern, dass die Anmeldeinformationen von Benutzern auf dem RODC<br />
zwischengespeichert werden. Sie verwalten diese Einstellungen über die neue Registerkarte<br />
Kennwortreplikation auf den Eigenschaftenseiten eines Domänencontrollers (Abbildung 9.6).<br />
Wenn Sie auf dieser Registerkarte auf die Schaltfläche Erweitert klicken, bekommen Sie<br />
angezeigt, welche Kennwörter an den RODC gesendet wurden, welche Kennwörter momentan<br />
auf dem RODC gespeichert wurden und welche Konten vom RODC authentifiziert wurden.<br />
Darunter fallen auch Konten, die momentan nicht in den <strong>Sicherheit</strong>sgruppen definiert<br />
sind, denen Replikation erlaubt oder verboten ist. Das bedeutet, dass Sie schnell und einfach<br />
feststellen können, wer den RODC benutzt, und jederzeit steuern können, ob die Kennwortreplikation<br />
erlaubt oder verboten ist. Sie können diese Liste auch in eine CSV-Datei exportieren,<br />
indem Sie auf die Schaltfläche Exportieren klicken. So können Sie aufzeichnen, welche<br />
Benutzer den RODC tatsächlich nutzen, und im RODC die Kennwörter für die von<br />
Ihnen ausgewählten Konten eintragen.
256 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
Abbildung 9.6 <strong>Die</strong> neue Registerkarte Kennwortreplikation<br />
Um die RODC-Kennwortreplikationsrichtlinie unterstützen zu können, mussten in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>-AD DS die folgenden neuen Attribute definiert werden (eine vollständige Liste<br />
aller Attribute und Klassen finden Sie in der Schemadokumentation auf der Begleit-CD):<br />
msDS-NeverRevealGroup Gibt die <strong>Sicherheit</strong>sgruppe mit Benutzern an, deren Geheimnisse<br />
niemals gegenüber einer bestimmten Instanz offengelegt werden.<br />
msDS-Reveal-OnDemandGroup Gibt die <strong>Sicherheit</strong>sgruppe mit Benutzern an, deren<br />
Geheimnisse gegenüber einer bestimmten Instanz offengelegt werden können.<br />
msDS-AuthenticatedToAccountList Eine Rückwärtsverknüpfung zu ms-DS-AuthenticatedAtDC,<br />
die angibt, welche Benutzer sich an diesem Computer authentifiziert haben.<br />
msDS-RevealedList Eine Liste der Benutzer, deren Geheimnisse offengelegt wurden.<br />
Schreibgeschütztes DNS<br />
Wenn ich einen RODC brauche, ist zusätzlich auch ein DNS-<strong>Server</strong> in der Zweigstelle erforderlich;<br />
schließlich will ich die Namensauflösung nicht über das WAN durchführen, das<br />
würde das Konzept zunichte machen, RODCs in Zweigstellen bereitzustellen, damit die<br />
Benutzer lokal authentifiziert werden. Um eine Namensauflösung in Zweigstellen zur Verfügung<br />
zu stellen, können Sie den DNS-<strong>Server</strong>dienst auf einem RODC ausführen, sodass<br />
alle Anwendungsverzeichnispartitionen repliziert werden, die DNS nutzt, darunter Forest-<br />
DNSZones und DomainDNSZones. Falls Sie den DNS-<strong>Server</strong> auf einem RODC installieren,<br />
können Ihre Clients ihn im Rahmen einer Namensauflösung genauso wie jeden anderen<br />
DNS-<strong>Server</strong> abfragen. Er bietet aber keine direkte Unterstützung für Clientaktualisierungen.<br />
Das bedeutet, dass der RODC keine NS-Ressourceneinträge (Name <strong>Server</strong>) für irgendeine<br />
Active Directory-integrierte Zone registriert, die er hostet. Wenn ein Client versucht, seine<br />
DNS-Einträge bei einem RODC zu aktualisieren, gibt der <strong>Server</strong> einen Verweis auf einen
Schreibgeschützte Domänencontroller 257<br />
anderen beschreibbaren DNS-<strong>Server</strong> zurück. Der Client kann dann versuchen, seine Daten<br />
bei diesem beschreibbaren DNS-<strong>Server</strong> zu aktualisieren. Im Hintergrund versucht der DNS-<br />
<strong>Server</strong> auf dem RODC, den aktualisierten Eintrag vom DNS-<strong>Server</strong> zu replizieren, der die<br />
Aktualisierung vorgenommen hat. <strong>Die</strong>se Replikationsanforderung betrifft nur ein einziges<br />
Objekt (den DNS-Eintrag), während dieser speziellen Replikationsanforderung nach einem<br />
einzigen Objekt wird nicht die gesamte Liste der geänderten Zonen- oder Domänendaten<br />
repliziert.<br />
Mehrstufige Installation für schreibgeschützte Domänencontroller<br />
Manchmal ist es sehr nützlich, wenn die Installation in zwei Schritten durchgeführt werden<br />
kann. Wenn Sie den RODC erstellen, können Sie die Installation und Administration des<br />
RODCs entweder an eine <strong>Sicherheit</strong>sgruppe oder einen Benutzer delegieren. Der erste<br />
Schritt muss von einem Mitglied der Gruppe Domänen-Admins erledigt werden, aber der<br />
zweite Schritt kann von irgendjemanden durchgeführt werden, an den Sie diese Aufgabe im<br />
Assistenten delegiert haben. Bezüglich der <strong>Sicherheit</strong> bedeutet das, dass Sie jegliche Konfiguration,<br />
die Administratorprivilegien erfordert, erledigen können, bevor Sie den Hardwareserver<br />
verschicken. So brauchen Sie den <strong>Server</strong> nicht inklusive vertraulicher Daten durch<br />
die Welt zu schicken und auch keine vertraulichen Daten mit einem Kurierdienst getrennt zu<br />
versenden. Klicken Sie dazu mit der rechten Maustaste auf die Organisationseinheit des<br />
Domänencontrollers oder öffnen Sie das Menü Aktion und wählen Sie dann Konto für<br />
schreibgeschützten Domänencontroller vorbereiten. Ich empfehle, dass Sie den zweiten<br />
Schritt der Installation an eine Gruppe delegieren. Das erleichtert auf lange Sicht den Verwaltungsaufwand.<br />
Wenn Sie den AD DS-Installationsassistenten ausführen, finden Sie ein neues Kontrollkästchen<br />
auf der Willkommen-Seite, mit dem Sie den erweiterten Modus direkt im Assistenten<br />
aktivieren können. <strong>Die</strong> frühere Methode, den Befehl dcpromo /adv auszuführen, steht aber<br />
auch weiterhin zur Verfügung. Im erweiterten Modus stehen zusätzliche Konfigurationsoptionen<br />
zur Verfügung, zum Beispiel die mehrstufige Installation eines RODCs. Sie können<br />
jeden Schritt im Assistenten zum Installieren von Active Directory-Domänendiensten abschließen.<br />
Im ersten Schritt der Installation erstellen Sie ein Konto für den RODC in AD DS. <strong>Die</strong> zweite<br />
Phase der Installation verbindet den <strong>Server</strong>, der später ein RODC wird, mit dem Konto, das<br />
vorher dafür erstellt wurde. Während der ersten Phase sammelt der Assistent alle Daten über<br />
den RODC, die in der Active Directory-Datenbank gespeichert werden, zum Beispiel den<br />
Kontonamen des Domänencontrollers und den Standort, in dem er bereitgestellt wird. Wenn<br />
Sie das RODC-Konto anlegen, können Sie auch angeben, welche Benutzer oder Gruppen<br />
die nächste Phase der Installation durchführen dürfen. <strong>Die</strong>se nächste Phase kann in einem<br />
anderen Standort durchgeführt werden, zum Beispiel in der Zweigstelle, und zwar von jedem<br />
Benutzer oder jeder Gruppe, an die Sie das Recht delegieren, die Installation abzuschließen.<br />
<strong>Die</strong>ser Benutzer oder diese Gruppe schließen die Installation ab, indem er oder<br />
sie den Befehl dcpromo.exe /UseExistingAccount:Attach ausführt. Damit wird der <strong>Server</strong> mit<br />
dem vorher erstellten RODC-Konto verbunden. Falls Sie kein Konto angegeben haben, das<br />
die Installation abschließen und den RODC administrieren darf, kann der zweite Schritt nur<br />
von einem Benutzer erledigt werden, der Mitglied der Gruppen Domänen-Admins oder<br />
Organisations-Admins ist. <strong>Die</strong> zweite Phase der Installation installiert AD DS auf dem neuen<br />
RODC-<strong>Server</strong>. Alle AD DS-Daten, die lokal abgelegt sind, zum Beispiel Protokolldateien
258 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
und die Datenbank, werden auf dem RODC selbst erstellt. Bei den Installationsquelldateien<br />
haben Sie zwei Optionen zur Auswahl: Entweder werden sie von einem anderen DC auf den<br />
RODC repliziert oder es wird das IFM-Feature (Install From Media) genutzt.<br />
Hinweis Sie müssen Ntdsutil.exe verwenden, um die Installationsmedium zu erstellen, wenn Sie IFM<br />
nutzen möchten.<br />
Während der Installation erkennt der Assistent automatisch, ob der Name des <strong>Server</strong>s dem<br />
Namen eines RODC-Kontos entspricht, das vorher angelegt wurde. Wenn der Assistent einen<br />
passenden Kontonamen findet, fragt er der Benutzer, ob er dieses Konto für die RODC-<br />
Installation verwenden soll. Daher ist wichtig, dass der <strong>Server</strong> nicht zur Domäne hinzugefügt<br />
wird, bevor Sie versuchen, ihn mit dem RODC-Konto zu verbinden.<br />
Welche Voraussetzungen müssen erfüllt sein?<br />
Bevor Sie einen RODC bereitstellen können, müssen folgende Voraussetzungen erfüllt sein:<br />
Ein beschreibbarer DC, der unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> läuft, muss in der Domäne vorhanden<br />
sein. Der RODC muss Authentifizierungsanforderungen an diesen DC weiterleiten,<br />
weil die Kennwortreplikationsrichtlinie darauf definiert ist.<br />
<strong>Die</strong> Domänenfunktionsebene muss <strong>Windows</strong> <strong>Server</strong> 2003 oder höher sein, damit die<br />
eingeschränkte Kerberos-Delegierung verfügbar ist. Eingeschränkte Delegierung wird<br />
für <strong>Sicherheit</strong>saufrufe eingesetzt, in denen die Identität des Aufrufers angenommen werden<br />
muss.<br />
<strong>Die</strong> Gesamtstrukturfunktionsebene muss <strong>Windows</strong> <strong>Server</strong> 2003 oder höher sein, damit<br />
die verknüpfte Wertreplikation verfügbar ist. <strong>Die</strong>s stellt sicher, dass die Replikationskonsistenz<br />
höher ist.<br />
Sie müssen Adprep/Rodcprep einmal in der Gesamtstruktur ausführen, um die Berechtigungen<br />
für alle DNS-Anwendungsverzeichnispartitionen in der Gesamtstruktur zu aktualisieren.<br />
Das macht es allen RODCs, die auch DNS-<strong>Server</strong> sind, möglich, die Berechtigungen<br />
erfolgreich zu replizieren.<br />
<strong>Die</strong> Rolle des PDC-Emulators muss auf einem <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Computer laufen.<br />
Andernfalls kündigt sich der RODC gegenüber seinen Clients nicht als Zeitquelle an.<br />
Einzelheiten finden Sie in http://technet2.microsoft.com/windowsserver<strong>2008</strong>/en/library/<br />
49eaca29-3399-4dd6-adcc-87a574e5d7921033.mspx?mfr=true.<br />
Hinweis Falls Sie einen RODC-gefilterten Attributsatz verwenden wollen, empfehle ich Ihnen, die<br />
Gesamtstrukturfunktionsebene auf <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zu setzen. Einzelheiten finden Sie im Abschnitt<br />
»RODC-gefilterte Attributsätze« weiter oben in diesem Kapitel.<br />
Neustartfähige Active Directory-Domänendienste<br />
Was haben Sie von einem Feature wie neustartfähigen AD DS? Als ich zum ersten Mal davon<br />
hörte, war ich nicht überzeugt, aber je mehr ich darüber nachdachte, desto besser gefiel<br />
mir die Idee. Der Vorteil ist, dass Sie ohne Ihren <strong>Server</strong> neu zu starten manche Operationen<br />
ausführen können, die normalerweise einen Neustart des DCs erfordern, zum Beispiel das<br />
Einspielen von <strong>Sicherheit</strong>supdates. Sie können damit auch AD DS anhalten, um Aufgaben<br />
wie eine Offlinedefragmentierung der Active Directory-Datenbank durchzuführen. Der<br />
größte Vorteil ist aber, dass andere <strong>Die</strong>nste, die auf dem <strong>Server</strong> laufen und nicht von AD DS
Active Directory-Datenbankbereitstellung 259<br />
abhängen, zum Beispiel DHCP (Dynamic Host Configuration Protocol), weiterhin Clientanforderungen<br />
entgegennehmen können, während Sie Ihr <strong>Sicherheit</strong>supdate oder die Offlinedefragmentierung<br />
durchführen.<br />
Hinweis Falls Sie AD DS beenden, werden auch die <strong>Die</strong>nste DNS, KDC und standortübergreifender<br />
Messagingdienst beendet.<br />
Neustartfähige AD DS stehen standardmäßig auf allen DCs zur Verfügung, die unter <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> laufen. Es bestehen keine Anforderungen bezüglich der Funktionsebene<br />
oder andere Voraussetzungen, um dieses Feature zu nutzen. Sie können AD DS im Microsoft<br />
Management Console-Snap-In <strong>Die</strong>nste oder über die Befehlszeile beenden und starten,<br />
genau wie jeden anderen <strong>Die</strong>nst.<br />
Wenn Sie AD DS beenden, ist das ein ähnlicher Vorgang wie die Anmeldung an der Verzeichnisdienstwiederherstellung.<br />
Aber aufgrund der neustartfähigen AD DS gibt es einen<br />
neuen Status für DCs, die unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> laufen: »AD DS beendet«. Ein DC,<br />
der sich in diesem Zustand befindet, vereinigt Merkmale eines DCs in der Verzeichnisdienstwiederherstellung<br />
mit denen eines Domänenmitgliedservers. <strong>Die</strong> Active Directory-<br />
Datenbank (Ntds.dit) auf dem DC ist offline, genau wie bei der DSRM. Während dieser<br />
Modus aktiv ist, kann für die Anmeldung Kontakt mit einem anderen DC aufgenommen<br />
werden, sofern einer verfügbar ist. Falls kein anderer DC erreichbar ist, können Sie sich mit<br />
dem DSRM-Kennwort anmelden. Und als normaler Mitgliedserver ist ein DC, bei dem die<br />
AD DS beendet wurden, immer noch Teil der Domäne. Das bedeutet, dass Gruppenrichtlinien<br />
und andere Einstellungen weiterhin auf den Computer angewendet werden. Aber er<br />
kann keine Anmeldungsanforderungen beantworten oder eine Replikation mit anderen DCs<br />
ausführen, während er in diesem Zustand ist.<br />
Active Directory-Datenbankbereitstellung<br />
Microsoft hat den Active Directory-Wiederherstellungsprozess verbessert, indem es eine<br />
Möglichkeit bietet, Daten zu vergleichen, die in Snapshots oder Sicherungen zu unterschiedlichen<br />
Zeiten aufgezeichnet wurde. Sie fragen sich wahrscheinlich, warum ich das unter<br />
<strong>Sicherheit</strong>saspekten für wichtig halte. Der Grund ist recht einfach: Sie erhalten damit die<br />
Möglichkeit, Änderungen zu verfolgen, die vor einem <strong>Sicherheit</strong>svorfall durchgeführt wurden.<br />
<strong>Die</strong>s ist eine einfache Methode, forensische Untersuchungen durchzuführen, indem Sie<br />
Daten vergleichen. Für diesen Zweck verwenden Sie das neue Tool für die Active Directory-<br />
Datenbankbereitstellung (database mounting tool, Dsamain.exe), das Ihnen hilft zu entscheiden,<br />
welche Daten Sie nach einem Datenverlust wiederherstellen müssen. Für mich<br />
bedeutet dieses Feature, dass ich nicht mehrere Datensicherungen wiederherstellen muss,<br />
um die darin enthaltenen Active Directory-Daten vergleichen zu können.<br />
Hinweis <strong>Die</strong>ses Feature trug während der Produktentwicklung die Codenamen »Snapshot Viewer« und<br />
»Active Directory Data Mining Tool«. In manchen Beschreibungen finden Sie diese Bezeichnungen noch.<br />
Erst einmal müssen Sie wissen, dass das Active Directory-Datenbankbereitstellungstool<br />
nicht selbst gelöschte Objekte wiederherstellt. Es hilft Ihnen vielmehr, den Prozess zum<br />
Wiederherstellen von Objekten zu beschleunigen, die versehentlich gelöscht wurden. Wenn<br />
in Vorgängerversionen von Active Directory Objekte oder Organisationseinheiten versehentlich<br />
gelöscht wurden, konnten Sie nur genau feststellen, welche Objekte gelöscht wurden,
260 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
indem Sie die Daten aus Datensicherungen wiederherstellten. <strong>Die</strong>ser Ansatz hatte zwei<br />
wichtige Nachteile:<br />
Sie mussten den DC im DSRM neu starten, um eine autorisierende Wiederherstellung<br />
durchzuführen.<br />
Sofern Sie die Datensicherungen nicht auf anderen DCs wiederherstellten, hatten Sie<br />
keine Möglichkeit, die Daten in mehreren Sicherungen zu vergleichen, die zu unterschiedlichen<br />
Zeitpunkten angefertigt wurden. Das machte diese Aufgabe sehr mühsam.<br />
Das Active Directory-Datenbankbereitstellungstool erlaubt Ihnen, AD DS-Daten, die in<br />
Snapshots oder Datensicherungen gespeichert sind, online anzusehen. Sie können Daten in<br />
Snapshots oder Datensicherungen vergleichen, die zu unterschiedlichen Zeitpunkten angefertigt<br />
wurden. So können Sie besser entscheiden, welche Daten wiederhergestellt werden<br />
müssen. Das Active Directory-Datenbankbereitstellungstool ermöglicht es Ihnen, gelöschte<br />
AD DS oder AD LDS (Active Directory Lightweight Directory Services) in Form von Snapshots<br />
zu retten, die vom Volumeschattenkopiedienst (Volume Shadow Copy, VSS) angefertigt<br />
wurden. Das Tool stellt die gelöschten Objekte und Container nicht wirklich her, dafür<br />
müssen Sie eine separate Datenwiederherstellung durchführen.<br />
Weil Datensicherungen vertrauliche Daten enthalten, werden die Sicherungen schreibgeschützt<br />
gespeichert, und nur Mitglieder der Gruppen Domänen-Admins und Organisations-<br />
Admins dürfen sich einen Snapshot mit einem LDAP-Tool (Lightweight Directory Access<br />
Protocol) wie zum Beispiel Ldp.exe ansehen. Ich empfehle, dass Sie Verschlüsselung oder<br />
andere Datensicherheitsmaßnahmen für AD DS-Snapshots nutzen, um die Gefahr zu verringern,<br />
dass jemand unautorisiert auf AD DS-Snapshots zugreift.<br />
Gehen Sie folgendermaßen vor, um das Active Directory-Datenbankbereitstellungstool zu<br />
verwenden:<br />
1. Planen Sie eine Aufgabe, die regelmäßig Ntdsutil.exe ausführt und Snapshots des Volumes<br />
anfertigt, das die AD DS-Datenbank enthält. <strong>Die</strong>ser Schritt ist optional. Sie können<br />
dies auch von Hand erledigen, wenn Sie möchten, ich empfehle aber, es automatisch erledigen<br />
zu lassen.<br />
2. Führen Sie Ntdsutil.exe aus, um die verfügbaren Snapshots aufzulisten und den Snapshot<br />
bereitzustellen, den Sie untersuchen wollen.<br />
3. Führen Sie Dsamain.exe aus, um das Snapshotvolume als LDAP-<strong>Server</strong> anzeigen zu<br />
lassen. Falls ich zum Beispiel meinen letzten Snapshot im Standardpfad ansehen will,<br />
lautet der Befehl: dsamain <strong>–</strong>dbpath c:\$snap_200711201220_volumec$\windows\ntds\ntds.<br />
dit -ldapport 41389. Daraufhin wird der Snapshot für Ldp.exe auf Port 41389 zur Verfügung<br />
gestellt. Dsamain.exe hat folgende Parameter:<br />
AD DS-Datenbankpfad (Ntds.dit). <strong>Die</strong>ser Pfad muss im ASCII-Format angegeben<br />
werden, in der Standardeinstellung wird er schreibgeschützt geöffnet.<br />
Protokollpfad. Sie müssen Schreibzugriff auf diesen Pfad haben.<br />
4 Portnummern für LDAP, LDAP-SSL, globalen Katalog und Globaler-Katalog-<br />
SSL. Der einzige Port, der unbedingt angegeben werden muss, ist der LDAP-Port.<br />
Falls Sie keine anderen Ports angeben, werden LDAP+1, LDAP+2 und LDAP+3<br />
verwendet. Falls Sie also den LDAP-Port 41389 angeben, aber keine anderen Portwerte,<br />
ist der LDAP-SSL-Port 41390, der Globale-Katalog-Port 41391 und der<br />
Globale-Katalog-SSL-Port 41392. Auch wenn das seltsam für jemanden aussieht,<br />
der die Standardports kennt, funktioniert es tatsächlich.
AD DS-Überwachung 261<br />
4. Stellen Sie mit Ldp.exe eine Verbindung zum LDAP-Port des Snapshots her, den Sie<br />
angegeben haben, als Sie den Snapshot im vorherigen Schritt als LDAP-<strong>Server</strong> verfügbar<br />
gemacht haben.<br />
5. Durchsuchen Sie den Snapshot wie jeden Online-DC. Sie können Dsamain beenden,<br />
indem Sie im Eingabeaufforderungsfenster STRG+C drücken. Falls Sie den Befehl im<br />
Remotezugriff ausführen, müssen Sie das stopservice-Attribut im rootDSE-Objekt<br />
setzen.<br />
Wenn Sie wissen, welche Organisationseinheiten oder Objekte gelöscht wurden, können Sie<br />
die gelöschten Objekte in den Snapshots suchen und aufzeichnen, welche Attribute und<br />
Rückwärtsverknüpfungen zu den gelöschten Objekten gehören. Dann erwecken Sie diese<br />
Objekte mit dem »Tombstone«-Feature wieder zum Leben. Einzelheiten zu diesem Vorgang<br />
finden Sie im Microsoft TechNet-Artikel »Reanimating Active Directory Tombstone Objects«<br />
unter http://www.microsoft.com/technet/technetmag/issues/2007/09/Tombstones/<br />
default.aspx.<br />
Anschließend müssen Sie bei diesen Objekten von Hand die entfernten Attribute und Rückwärtsverknüpfungen<br />
hinzufügen, wie sie in den Snapshots vorliegen. Auch wenn Sie die<br />
entfernten Attribute und Rückwärtsverknüpfungen von Hand neu erstellen müssen, ermöglicht<br />
es Ihnen das Active Directory-Datenbankbereitstellungstool, gelöschte Objekte und<br />
ihre Rückwärtsverknüpfungen wiederherzustellen, ohne den DC in der Verzeichnisdienstwiederherstellung<br />
neu zu starten. Das spart eine Menge Zeit, das kann ich Ihnen versichern!<br />
Sie können das Tool auch verwenden, um bestimmte Aspekte vorheriger Konfigurationen<br />
von AD DS nachzusehen, zum Beispiel eingestellte Berechtigungen. Das kann eine große<br />
Hilfe sein, wenn Sie eine Wiederherstellung durchführen müssen. <strong>Die</strong>ses Feature ist auch<br />
sehr nützlich, falls Ihr AD DS nicht mehr läuft und Sie wissen wollen, wie er konfiguriert<br />
war, als er zuletzt funktionierte.<br />
AD DS-Überwachung<br />
<strong>Die</strong>ser Abschnitt behandelt ausschließlich die AD DS-Überwachung. Weitere Informationen<br />
über die Überwachung in <strong>Windows</strong> finden Sie in Kapitel 8, »Überwachung«.<br />
Meine Kunden haben oft nach einer Möglichkeit gesucht, alte und neue Werte zu protokollieren,<br />
wenn eine Änderung durchgeführt wird. Sie können jetzt die AD DS-Überwachung<br />
mit einer neuen Überwachungsrichtlinien-Unterkategorie namens Verzeichnisdienständerungen<br />
(engl. directory service changes) einrichten. Dabei werden die bisherigen und neuen<br />
Werte aufgezeichnet, wenn Änderungen an AD DS-Objekten und ihren Attributen vorgenommen<br />
werden. Das hilft Ihnen bei forensischen Untersuchungen und wenn Sie die Ereignisse<br />
verfolgen wollen, die vor einem <strong>Sicherheit</strong>svorfall aufgetreten sind.<br />
Hinweis <strong>Die</strong>ses neue Überwachungsfeature steht auch für AD LDS zur Verfügung.<br />
Indem Sie die Systemzugriffssteuerungsliste (System Access Control List, SACL) eines<br />
Objekts verändern, können Sie steuern, welche Operationen überwacht werden. Das liefert<br />
Ihnen die Details, die Sie schon immer haben wollten. Falls Sie diese Richtlinieneinstellung<br />
definieren, indem Sie die Standarddomänencontrollerrichtlinie entsprechend ändern, können<br />
Sie festlegen, ob erfolgreiche Aktionen, fehlgeschlagene Aktionen oder gar keine Aktionen<br />
überwacht werden. Bei der Erfolgsüberwachung wird ein Überwachungseintrag generiert,<br />
wenn ein Benutzer erfolgreich auf ein Objekt zugreift, für das eine SACL definiert ist.
262 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
Bei der Fehlerüberwachung wird ein Überwachungseintrag generiert, wenn ein Benutzer<br />
erfolglos versucht, auf ein Objekt zuzugreifen, für das eine SACL definiert ist.<br />
Bisher zeichnete die AD DS-Überwachung nur den Namen des Attributs auf, das geändert<br />
wurde. Erst in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-AD DS werden der bisherige und der neue Wert des<br />
Attributs protokolliert. Das hilft Ihnen, Änderungen und bisherige Werte zu ermitteln, sodass<br />
die Ereignisprotokolle noch nützlicher dabei werden, Änderungen über die Lebensdauer<br />
eines Objekts nachzuverfolgen.<br />
Überwachen von AD DS-Zugriffen<br />
Sie wissen vielleicht, dass <strong>Windows</strong> 2000 <strong>Server</strong> und <strong>Windows</strong> <strong>Server</strong> 2003 nur eine<br />
Überwachungsrichtlinie hatten (Verzeichnisdienstzugriff überwachen), die steuerte, ob die<br />
Überwachung für Verzeichnisdienstereignisse aktiviert oder deaktiviert war. In <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> ist diese Richtlinie in vier Unterkategorien untergliedert:<br />
Verzeichnisdienstzugriff<br />
Verzeichnisdienständerungen<br />
Verzeichnisdienstreplikation<br />
Detaillierte Verzeichnisdienstreplikation<br />
Wenn Sie Änderungen an Objekten überwachen wollen, müssen Sie die Unterkategorie<br />
Verzeichnisdienständerungen aktivieren. Tabelle 9.1 listet die Operationen auf, die überwacht<br />
werden können.<br />
Tabelle 9.1 AD DS-Operationen<br />
Typ Ereignis-ID Beschreibung<br />
Ändern 5136 Wird aufgezeichnet, sobald ein Attribut erfolgreich geändert wurde.<br />
Erstellen 5137 Wird aufgezeichnet, wenn ein neues Objekt erstellt wurde.<br />
Löschen rück-<br />
gängig machen<br />
5138 Wird aufgezeichnet, wenn ein gelöschtes Objekt wiederhergestellt wird.<br />
Verschieben 5139 Wird aufgezeichnet, wenn ein Objekt innerhalb der Domäne verschoben wird.<br />
Hinweis <strong>Die</strong> Löschoperation ist in Wirklichkeit eine Änderungsoperation. Das Attribut isDeleted wird auf<br />
True gesetzt, wenn ein Objekt gelöscht wird.<br />
<strong>Die</strong>se Operationen sind Änderungen, die an einem Objekt durchgeführt werden. <strong>Die</strong> entsprechenden<br />
Ereignisse werden im <strong>Sicherheit</strong>sprotokoll aufgezeichnet.<br />
Als Beispiel ändere ich in der Konsole Active Directory-Benutzer und -Computer das Büro-<br />
Attribut für einen Benutzer namens Jimmy Andersson. Daraufhin tauchen die zwei folgenden<br />
Ereignisse im <strong>Sicherheit</strong>sprotokoll auf:<br />
1. Das erste Ereignis teilt mit, dass ich den Wert für das Attribut physicalDeliveryOffice-<br />
Name gelöscht habe. <strong>Die</strong>s ist der tatsächliche Attributname, in dem das Büro-Feld in der<br />
Konsole Active Directory-Benutzer und -Computer seine Werte speichert.<br />
Ein Verzeichnisdienstobjekt wurde geändert.<br />
Antragsteller:<br />
<strong>Sicherheit</strong>s-ID: SECRESKIT08\Administrator
Kontoname: Administrator<br />
Kontodomäne: SECRESKIT08<br />
Anmelde-ID: 0x438594<br />
Verzeichnisdienst:<br />
Name: secreskit08.prv<br />
Typ: Active Directory-Domänendienste<br />
AD DS-Überwachung 263<br />
Objekt:<br />
DN: CN=Jimmy Andersson,OU=AuditPolicy,DC=secreskit08,DC=prv<br />
GUID: CN=Jim Andersson,OU=AuditPolicy,DC=secreskit08,DC=prv<br />
Klasse: user<br />
Attribut:<br />
LDAP-Anzeigename: physicalDeliveryOfficeName<br />
Syntax (OID): 2.5.5.12<br />
Wert: Uppsala HQ<br />
Vorgang:<br />
Typ: Wert wurde gelöscht<br />
Korrelations-ID: {31e232b9-35df-4b26-8bd0-e5797f5172b4}<br />
Anwendungskorrelations-ID: -<br />
2. Das zweite Ereignis verrät mir erneut, dass am selben Attribut etwas geändert wurde,<br />
und wie der neue Wert lautet:<br />
Ein Verzeichnisdienstobjekt wurde geändert.<br />
Antragsteller:<br />
<strong>Sicherheit</strong>s-ID: SECRESKIT08\Administrator<br />
Kontoname: Administrator<br />
Kontodomäne: SECRESKIT08<br />
Anmelde-ID: 0x438594<br />
Verzeichnisdienst:<br />
Name: secreskit08.prv<br />
Typ: Active Directory-Domänendienste<br />
Objekt:<br />
DN: CN=Jimmy Andersson,OU=AuditPolicy,DC=secreskit08,DC=prv<br />
GUID: CN=Jim Andersson,OU=AuditPolicy,DC=secreskit08,DC=prv<br />
Klasse: user<br />
Attribut:<br />
LDAP-Anzeigename: physicalDeliveryOfficeName<br />
Syntax (OID): 2.5.5.12<br />
Wert: HQ<br />
Vorgang:<br />
Typ: Wert wurde hinzugefügt<br />
Korrelations-ID: {31e232b9-35df-4b26-8bd0-e5797f5172b4}<br />
Anwendungskorrelations-ID: -
264 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
Alle Veränderungen, die in der Datenbank auftreten, werden als eigene Ereignisse aufgezeichnet,<br />
sobald etwas in die Datenbank geschrieben wird. Meine Änderung umfasst in<br />
Wirklichkeit zwei Schritte. Erst wird das Attribut gelöscht, und das nächste Ereignis zeigt,<br />
dass ein Wert hinzugefügt wurde.<br />
Aber falls Sie zum Beispiel einen Benutzer von einer Organisationseinheit in eine andere<br />
verschieben, zeigt das Ereignis sowohl den alten als auch den neuen Wert:<br />
Ein Verzeichnisdienstobjekt wurde verschoben.<br />
Antragsteller:<br />
<strong>Sicherheit</strong>s-ID: SECRESKIT08\Administrator<br />
Kontoname: Administrator<br />
Kontodomäne: SECRESKIT08<br />
Anmelde-ID: 0x438594<br />
Verzeichnisdienst:<br />
Name: secreskit08.prv<br />
Typ: Active Directory-Domänendienste<br />
Objekt:<br />
Alter DN: CN=Jimmy Andersson,OU=AuditPolicyExample,DC=secreskit08,DC=prv<br />
Neuer DN: CN=Jimmy Andersson,OU=Test,DC=secreskit08,DC=prv<br />
GUID: CN=Jim Andersson,OU=AuditPolicy,DC=secreskit08,DC=prv<br />
Klasse: user<br />
Vorgang:<br />
Korrelations-ID: {d8ed2341-aaa1-4d3c-9485-67a69de53622}<br />
Anwendungskorrelations-ID: -<br />
<strong>Die</strong>s war das Verhalten in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> RC1. Ich weiß nicht, ob dies in der endgültigen<br />
Version ebenfalls so ist oder ob Microsoft bei allen Änderungsarten die alten und<br />
neuen Attribute einträgt, wie im obigen Beispiel beim Verschieben eines Benutzers.<br />
Falls Sie das neue Überwachungsfeature nutzen wollen, sollten Sie die Steuermöglichkeiten<br />
verwenden, die ich in den nächsten Abschnitten beschreibe. Ich empfehle, dass Sie alle Objekte<br />
genau überwachen, die Sie in Ihrer AD DS-Implementierung als kritisch einstufen. Auf<br />
diese Weise können Sie alle Änderungen verfolgen und die Ursache von <strong>Sicherheit</strong>s- und<br />
anderen Problemen ermitteln, die zum Beispiel durch Veränderungen oder Löschaktionen<br />
ausgelöst werden. Sie sollten außerdem alle Veränderungen an privilegierten Konten und<br />
Gruppen genau beobachten.<br />
Globale Überwachungsrichtlinien<br />
Wenn Sie alle Unterkategorien für die Verzeichnisdienstrichtlinien aktivieren wollen, können<br />
Sie einfach die globale Überwachungsrichtlinie Verzeichnisdienstzugriff überwachen<br />
aktivieren. Sie stellen diese globale Überwachungsrichtlinie in der Standarddomänencontrollerrichtlinie<br />
unter <strong>Sicherheit</strong>seinstellungen\Lokale Richtlinien\Überwachungsrichtlinie ein.<br />
<strong>Die</strong> zwei Überwachungsunterkategorien sind unabhängig voneinander, daher können Sie<br />
Verzeichnisdienstzugriff deaktivieren, bekommen aber trotzdem noch die Ereignisse zu sehen,<br />
die generiert werden, wenn die Unterkategorie Verzeichnisdienständerungen aktiviert ist.
AD DS-Überwachung 265<br />
Dasselbe gilt, wenn Sie Verzeichnisdienständerungen deaktivieren, aber Verzeichnisdienstzugriff<br />
aktivieren.<br />
Leider gibt es kein GUI-Tool, um die Überwachungsrichtlinien-Unterkategorien anzusehen<br />
oder zu verwalten. Sie müssen das Befehlszeilentool Auditpol.exe verwenden, wenn Sie die<br />
Unterkategorien von Überwachungsrichtlinien anzeigen oder ändern möchten. Der folgende<br />
Befehl aktiviert die Überwachungsunterkategorie Verzeichnisdienständerungen:<br />
auditpol /set /subcategory:"Verzeichnisdienständerungen" /success:enable<br />
Hinweis Mit dem Befehl auditpol /get /category:* können Sie sich eine Liste aller Kategorien und<br />
ihre aktuellen Einstellungen anzeigen lassen.<br />
SACL<br />
SACL ist der Teil in der <strong>Sicherheit</strong>sbeschreibung eines Objekts, der festlegt, welche Operationen<br />
überwacht werden. Um die Überwachung von Verzeichnisdienstereignissen zu aktivieren,<br />
müssen Sie die Überwachung für die entsprechende Unterkategorie von Ereignissen<br />
aktivieren und außerdem eine passende SACL konfigurieren. Falls Sie zum Beispiel Änderungsüberwachungsereignisse<br />
aufzeichnen wollen, muss ein Zugriffssteuerungslisteneintrag<br />
(Access Control List Entry, ACE) in der SACL vorhanden sein und die Überwachung für die<br />
Unterkategorie Verzeichnisdienständerungen muss aktiviert sein. <strong>Die</strong>ser ACE definiert, dass<br />
Attributänderungen aufgezeichnet werden, sogar wenn die Unterkategorie Verzeichnisdienständerungen<br />
aktiviert ist. Was das bedeutet, beschreibe ich am Beispiel des mobile-Attributs<br />
(Rufnummer im Feld Mobil).<br />
Falls es keinen ACE in einer SACL gibt, der Eigenschaft schreiben-Zugriff auf das mobile-<br />
Attribut erfordert, werden keine Überwachungsereignisse generiert, wenn das mobile-<br />
Attribut geändert wird. Das gilt sogar dann, wenn die Unterkategorie Verzeichnisdienständerungen<br />
aktiviert ist.<br />
Weitere Informationen zu SACLs und Überwachung finden Sie in Kapitel 8.<br />
Schema<br />
Falls Sie alle Ereignisse überwachen, wird eine enorme Zahl von Ereignissen generiert.<br />
Daher wird dies nicht empfohlen. Um dieses Problem zu vermeiden, erlaubt Ihnen ein zusätzliches<br />
Steuerelement im Schema, Ausnahmen zu definieren, die festlegen, was nicht<br />
überwacht wird. Falls Sie zum Beispiel Änderungen an allen Attributveränderungen eines<br />
Benutzerobjekts sehen, aber ein oder zwei Attribute ausnehmen wollen, können Sie mit der<br />
Eigenschaft searchFlag des Attributs definieren, ob es überwacht werden soll. <strong>Die</strong>s ist ein<br />
Flag, das Sie im Schema für das Attribut setzen können. <strong>Die</strong> searchFlags-Eigenschaft jedes<br />
Attributs definiert eine Reihe von Verhaltensweisen für das jeweilige Attribut. Falls Bit 9<br />
(Wert 256) für ein Attribut gesetzt ist, protokolliert AD DS keine Änderungsereignisse, wenn<br />
dieses Attribut geändert wird. Lesen Sie sich aber bitte die Microsoft-Onlinedokumentation<br />
unter http://msdn2.microsoft.com/en-us/library/ms679765.aspx durch, bevor Sie den search-<br />
Flags-Wert ändern. <strong>Die</strong>s kann nämlich große Auswirkungen auf Ihre AD DS-Implementierung<br />
haben.
266 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
Grundlagen von AD LDS<br />
AD LDS (Active Directory Lightweight Directory Services) war früher unter dem Namen<br />
Active Directory-Anwendungsmodus (Active Directory Application Mode, ADAM) bekannt.<br />
Ich nutze es, um einen Verzeichnisdienst bereitzustellen, den verzeichnisfähige Anwendungen<br />
einsetzen können, ohne sich mit dem Verwaltungsaufwand von Gesamtstrukturen<br />
und Domänen zu belasten. AD LDS ist ein LDAP-Verzeichnisdienst ohne die Abhängigkeiten,<br />
die für AD DS nötig sind. So erhalten Sie flexible Unterstützung für verzeichnisfähige<br />
Anwendungen, ohne eine Domäne mit DCs einrichten zu müssen. Trotzdem erhalten Sie<br />
fast dieselbe Funktionalität wie mit AD DS. Eines der Dinge, die ich an AD LDS am meisten<br />
schätze, ist die Fähigkeit, auf einem einzigen Computer gleichzeitig mehrere Instanzen<br />
mit unabhängigen Schemas auszuführen. Auf diese Weise kann ich pro Anwendung ein<br />
eigenes AD LDS einsetzen. Im Bezug auf <strong>Sicherheit</strong> heißt das, dass ich mehrere Instanzen<br />
auf einem einzigen physischen <strong>Server</strong> habe, obwohl sie nicht miteinander verbunden sind<br />
und sich daher keinerlei Daten teilen.<br />
Wie Sie wissen, stellt AD DS Verzeichnisdienste sowohl für verzeichnisfähige Anwendungen<br />
als auch Microsoft <strong>Windows</strong> <strong>Server</strong>-Betriebssysteme zur Verfügung. AD DS speichert<br />
wichtige Informationen über die Netzwerkinfrastruktur, Benutzer, Gruppen, Netzwerkdienste<br />
und so weiter. Zu diesem Zweck braucht AD DS ein einziges Schema, das überall in der<br />
gesamten Gesamtstruktur gilt. Dadurch verlieren Sie etwas Flexibilität. Aber wenn Sie die<br />
<strong>Server</strong>rolle Active Directory Lightweight Directory Services verwenden, können Sie verzeichnisfähige<br />
Anwendungen Verzeichnisdienste zur Verfügung stellen, ohne dass dafür eine<br />
Active Directory-Gesamtstruktur erforderlich ist. Es gibt noch ein weiteres nettes Feature:<br />
Falls Sie bereits AD DS haben, können Sie es für die Authentifizierung von <strong>Windows</strong>-<strong>Sicherheit</strong>sprinzipalen<br />
einsetzen. Das ist zum Beispiel nützlich, wenn Sie eine Anwendung haben,<br />
die das Schema erweitern muss, aber Sie diese Operation aus irgendwelchen Gründen nicht<br />
durchführen dürfen oder wollen. Sie können dann das AD LDS-Schema erweitern und die<br />
Informationen dort speichern. Anschließend lassen Sie die Benutzer über AD DS authentifizieren,<br />
stellen die Verbindung zur Anwendung her und lassen die anwendungsspezifischen<br />
Werte von AD LDS speichern.<br />
Verzeichnisspeicher<br />
Alle verzeichnisfähigen Anwendungen können AD LDS als Verzeichnisspeicher nutzen,<br />
weil AD LDS eine LDAP-Verzeichnislösung ist, die für den Unternehmenseinsatz entworfen<br />
wurde. AD LDS wird oft eingesetzt, um private Verzeichnisdaten in einem lokalen Verzeichnisdienst<br />
zu speichern. Das hat den Vorteil, dass Sie keine Daten zu replizieren brauchen, die<br />
nur für die tatsächliche Anwendung relevant sind, und in manchen Szenarien können Sie die<br />
Daten auch auf demselben <strong>Server</strong> ablegen wie die Anwendung. Indem Sie AD LDS verwenden,<br />
können Sie den Replikationsverkehr zwischen DCs im Netzwerk verringern (der meiner<br />
Meinung nach ausschließlich genutzt werden sollte, um die Domäneninfrastruktur zu<br />
verwalten). Aber in manchen Fällen müssen Sie auch Daten zwischen mehreren AD LDS-<br />
Instanzen replizieren.<br />
Unternehmensanwendungen müssen oft persönliche Daten speichern, die mit authentifizierten<br />
Benutzern in AD DS verknüpft sind. Falls Sie diese Daten in AD DS speichern, sind Sie<br />
häufig gezwungen, das AD DS-Schema zu verändern. Denken Sie daran, dass Änderungen<br />
am AD DS-Schema für die komplette Gesamtstruktur gelten, selbst wenn Sie nur eine<br />
Anwendung mit einem bestimmten DC verbinden. Ich verwende in so einem Fall normaler-
Grundlagen von AD LDS 267<br />
weise AD LDS, um anwendungsspezifische Daten zu speichern, zum Beispiel Richtlinien-<br />
und Verwaltungsinformationen. Dann verwende ich die Benutzerprinzipale in AD DS für die<br />
Authentifizierung und für die Zugriffssteuerung auf Objekte in AD LDS. <strong>Die</strong>se Lösung<br />
macht es überflüssig, für jedes AD LDS-Verzeichnis eine eigene Benutzerdatenbank anzulegen.<br />
Somit vermeiden Sie, dass jedes Mal, wenn eine neue verzeichnisfähige Anwendung im<br />
Netzwerk eingeführt wird, die Zahl von Benutzer-IDs und Kennwörtern für Endbenutzer<br />
ansteigt. Nicht nur Endbenutzer, sondern auch die Administratoren profitieren davon.<br />
Extranetauthentifizierungsspeicher<br />
AD LDS kann in vielen Szenarien nützlich sein, zum Beispiel für ein Webportal, wo AD LDS<br />
Individualisierungsdaten für Benutzer speichert, die sich über AD DS authentifiziert haben.<br />
In diesem Fall speichern Sie Benutzer-IDs in AD DS und persönliche Daten in AD LDS.<br />
Indem Sie diese Informationen trennen, brauchen Sie das Schema im globalen AD DS nicht<br />
zu erweitern. Und Sie brauchen dort auch keine persönlichen Daten zu speichern, die nur für<br />
die eine Portalanwendung benötigt werden. Das verringert den Netzwerkverkehr für AD DS<br />
(insbesondere wenn sich die Daten häufig ändern). Falls Sie die persönlichen Daten aus<br />
Redundanzgründen auf mehreren <strong>Server</strong>n speichern wollen, können Sie eine weitere Instanz<br />
von AD LDS einrichten und die Replikation zwischen ihnen konfigurieren.<br />
Sie können AD LDS auch als Extranetauthentifizierungsspeicher in Kombination mit Active<br />
Directory-Verbunddiensten (Active Directory Federation Services, AD FS) bereitstellen, um<br />
einmaliges Anmelden (Single-Sign-On, SSO) im Web zu ermöglichen, damit Benutzer sich<br />
gegenüber mehreren Webanwendungen mit einem einzigen Benutzerkonto authentifizieren<br />
können. Im Abschnitt »Grundlagen der Active Directory-Verbunddienste« weiter unten in<br />
diesem Kapitel finden Sie dazu weiter Informationen.<br />
Konsolidieren von Identitätssystemen<br />
Meine letzten Projekte haben sich damit beschäftigt, unterschiedliche Identitätssysteme<br />
zu konsolidieren. Daher will ich Ihnen ein Beispiel schildern. Ein Projekt betraf eine internationale<br />
Organisation mit mehreren Gesamtstrukturen in verschiedenen Ländern, die<br />
jeweils mehrere Domänen enthalten. Jede Domäne hatte mehrere Identitätssysteme, zum<br />
Beispiel Active Directory, SAP-Datenbanken, Telefonsysteme, spezielle Anwendungen<br />
mit eigenen Identitätssystemen und so weiter. Um alle diese Systeme mit sämtlichen<br />
Informationen in ein gemeinsames System zu konsolidieren, verwendeten meine Kollegen<br />
und ich AD LDS in Kombination mit einem Metaverzeichnis (engl. metadirectory).<br />
Microsoft stellt zwei Versionen von Metaverzeichnissen zur Verfügung: MIIS (Microsoft<br />
Identity Integration <strong>Server</strong>) und IIFP (Microsoft Identity Integration Feature Pack). IIFP<br />
ist eine kostenlose Version von MIIS, aber mit deutlich abgespeckten Features. Das<br />
Metaverzeichnis erlaubt uns, verzeichnisfähigen Anwendungen eine einheitliche Ansicht<br />
aller bekannten Identitätsinformationen über Unternehmensbenutzer, Anwendungen und<br />
Netzwerkressourcen zur Verfügung zu stellen. Dazu wurden Identitäten zusammengefasst,<br />
Kennwörter synchronisiert und Verzeichnisse sowie Konten zwischen AD DS und<br />
AD LDS zusammengefasst beziehungsweise aufgetrennt.
268 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
Entwicklungsumgebung für AD DS und AD LDS<br />
AD LDS ist eine sehr gute Wahl für Entwickler, die verschiedene Active Directory-integrierte<br />
Anwendungen erstellen und testen wollen, weil AD LDS dasselbe Programmiermodell<br />
verwendet und fast genau so administriert wird wie AD DS. Wenn eine Anwendung<br />
in Entwicklung ist, benötigt sie oft ein anderes Schemas als im aktuellen AD DS des <strong>Server</strong>betriebssystems.<br />
Der Anwendungsentwickler kann der Anwendung mithilfe von AD LDS<br />
ein maßgeschneidertes Schema bereitstellen, ohne die Konfiguration der Active Directory-<br />
Produktivbereitstellung verändern zu müssen. Entwickler können mit einer lokalen Instanz<br />
von AD LDS auf einem Entwicklercomputer arbeiten und die Anwendung dann später auf<br />
AD DS verschieben, nachdem sie vollständig getestet und genehmigt wurde.<br />
AD LDS spart Entwicklern Zeit, weil es ein simples Verzeichnis ist, in das sie problemlos<br />
schreiben können, ohne während des Entwicklungsprozesses ein aufwendiges Setup oder<br />
Hardwareunterstützung zu benötigen. AD LDS kann auf der Arbeitsstation eines Entwicklers<br />
einfach installiert oder deinstalliert werden. Und es kann während des Anwendungsprototyping-<br />
und Entwicklungsprozesses blitzschnell in einem sauberen Zustand wiederhergestellt<br />
werden.<br />
Konfigurationsspeicher für verteilte Anwendungen<br />
Falls Sie eine verteilte Anwendung haben, die einen Konfigurationsspeicher mit Multimasterupdate-<br />
und Replikationsfähigkeiten benötigt, um ihre zahlreichen Komponenten zu bedienen<br />
(zum Beispiel eine Workflowanwendung, die auf Unternehmensdaten zugreift), kann<br />
es sinnvoll sein, AD LDS als unkomplizierten Konfigurationsspeicher einzusetzen. In einem<br />
Szenario wie diesem können Sie AD LDS in den Installationsvorgang der Anwendung aufnehmen,<br />
um sicherzustellen, dass die Anwendung sofort nach der Installation Zugriff auf ein<br />
Verzeichnis hat. <strong>Die</strong> Anwendung konfiguriert und verwaltet AD LDS dann selbst, oder es kann<br />
teilweise verwaltet werden. Das hängt davon ab, wie die Anwendung geschrieben wurde.<br />
Wie erstellen Sie eine AD LDS-Instanz?<br />
<strong>Die</strong> Rolle Active Directory Lightweight Directory Services bringt Features mit, die es Ihnen<br />
einfach machen, Ihre AD LDS-Instanzen einzurichten und zu verwalten. Es gibt einen Assistenten,<br />
der Sie durch den Erstellungsprozess leitet. Außerdem stehen Befehlszeilentools zur<br />
Verfügung, mit denen Sie unbeaufsichtigte Installationen und Deinstallationen von Instanzen<br />
durchführen, aber auch Instanzen verwalten, synchronisieren und auffüllen können. Es steht<br />
sogar ein MMC-Snap-In zum Konfigurieren und Verwalten Ihrer Instanzen und des Schemas<br />
bereit. Aber vergessen Sie nicht, dass Sie auch viele der AD DS-Tools benutzen können, um<br />
AD LDS-Instanzen zu administrieren!<br />
Neue Features für AD LDS in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
<strong>Die</strong> neuen Features sind unter anderem:<br />
<strong>Die</strong> Überwachung von AD LDS-Änderungen funktioniert auf dieselbe Weise wie in<br />
AD DS.<br />
Das Data-Mining-Tool funktioniert auf dieselbe Weise wie in AD DS.<br />
Unterstützung für Active Directory-Standorte und -<strong>Die</strong>nste. Damit Sie diese Konsole<br />
verwenden können, müssen Sie erst das Schema mit den Klassen erweitern, die Sie in<br />
MS-ADLDS-DisplaySpecifiers.ldf finden. Anschließend können Sie Active Directory-
Grundlagen der Active Directory-Verbunddienste 269<br />
Standorte und -<strong>Die</strong>nste verwenden, um die Replikation zwischen AD LDS-Instanzen zu<br />
verwalten.<br />
Generieren von IFM (Install From Media). Mit diesem Feature können Sie einen kompakten<br />
Ntdsutil.exe- oder Dsdbutil.exe-Prozess nutzen, um Installationsmedien für die<br />
nächsten Installationen zu erstellen.<br />
Da während des Instanzsetups eine dynamische Liste von LDIF-Dateien (LDAP Data<br />
Interchange Format) zur Verfügung steht, können Sie während des AD LDS-Setups benutzerdefinierte<br />
LDIF-Dateien verwenden. Sie brauchen sie lediglich zum Verzeichnis<br />
%SystemRoot%\adam hinzuzufügen, dann werden sie zusätzlich zu den Standard-LDIF-<br />
Dateien ausgeführt.<br />
Mithilfe rekursiver Abfragen zu verknüpften Attributen können Sie die Gruppenmitgliedschaft<br />
und den Stammbaum mit einer einzigen LDAP-Abfrage ermitteln.<br />
Grundlagen der Active Directory-Verbunddienste<br />
Ich werde immer häufiger gefragt, wie sich eine Lösung für Identitäten entwickeln lässt, die<br />
über mehrere Plattformen hinweg funktioniert, sogar in Nicht-<strong>Windows</strong>-Umgebungen. Kunden<br />
wollen eine Lösung, die sich ins Internet skalieren lässt, flexibel erweiterbar ist und eine<br />
Identitätszugrifflösung enthält, die so sicher wie möglich ist. In diesen Fällen untersuche ich<br />
immer, ob die <strong>Server</strong>rolle Active Directory-Verbunddienste (Active Directory Federation<br />
Services, AD FS) geeignet ist, die im Betriebssystem Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthalten<br />
ist. In den folgenden Abschnitten gebe ich einen Überblick über AD FS. AD FS soll<br />
die Möglichkeit bieten, einen Benutzer über einmaliges Anmelden (Single-Sign-On, SSO)<br />
gegenüber mehreren Webanwendungen über die gesamte Dauer einer bestimmten Sitzung zu<br />
authentifizieren. AD FS erreicht das, indem es eine digitale Identität auf sichere Weise über<br />
<strong>Sicherheit</strong>sgrenzen zur Verfügung stellt. Meines Wissens ist dies die sicherste Lösung.<br />
Was ist AD FS?<br />
Es ist nichts Ungewöhnliches, wenn man sich mehrere digitale Identitäten merken muss.<br />
Das passiert mir oft, wenn ich versuche, eine Anwendung zu benutzen, die sich nicht in dem<br />
Netzwerk befindet, in dem ich normalerweise arbeite. In diesem Fall liegen Ihre Anmeldeinformationen<br />
(mit denen Sie sich bereits an Ihrem Netzwerk angemeldet haben) nicht im<br />
selben Bereich (engl. realm) wie die Anwendung. Daher öffnet sich oft ein weiteres Anmeldedialogfeld,<br />
in dem Sie noch einmal Anmeldeinformationen eingeben müssen, wenn Sie<br />
auf die Anwendung zugreifen. <strong>Die</strong>se sekundären Anmeldeinformationen stehen für die Identität<br />
Ihres Benutzers in dem Bereich, in dem sich die Anwendung befindet. Der Webserver,<br />
der die Anwendung hostet, braucht diese Anmeldeinformationen normalerweise, um die<br />
Autorisierungsentscheidung zu treffen, ob er Ihnen Zugriff erlaubt oder verweigert.<br />
AD FS macht sekundäre Konten und ihre Anmeldeinformationen unnötig, weil es eine Vertrauensstellung<br />
zur Verfügung stellt, mit der Sie die digitale Identität eines Benutzers und<br />
die Zugriffsrechte auf Ihre vertrauenswürdigen Partner schützen können. In einer sogenannten<br />
Verbundumgebung (engl. federated environment) verwaltet jede Organisation ihre eigenen<br />
Identitäten (Benutzer). Jede Organisation erlaubt aber auch, Identitäten auf andere Organisationen<br />
zu übertragen und von anderen Organisationen zu übernehmen. Das macht den<br />
Vorgang für Endbenutzer nahtlos. Ein anderes häufiges Szenario ist die Bereitstellung von<br />
Verbundservern in mehreren Organisationen, um B2B-Transaktionen (Business-to-Business)
270 Kapitel 9: Optimieren der Active Directory-Domänendienste für <strong>Sicherheit</strong><br />
zwischen Ihren vertrauenswürdigen Partnern zu ermöglichen. B2B-Verbundpartnerschaften<br />
erlauben Ihnen, Geschäftspartner als eine der folgenden Organisationstypen einzustufen:<br />
Ressourcenorganisation (engl. resource organization) <strong>Die</strong>s ist eine Organisation,<br />
die die Ressourcen besitzt und verwaltet, auf die aus dem Internet zugegriffen werden<br />
kann. Eine Ressourcenorganisation kann AD FS-Verbundserver und AD FS-fähige Webserver<br />
bereitstellen, die den Zugriff auf geschützte Ressourcen für vertrauenswürdige<br />
Partner verwalten.<br />
Kontenorganisation (engl. account organization) <strong>Die</strong>s ist eine Organisation, die<br />
Benutzerkonten besitzt und verwaltet. Eine Kontenorganisation kann AD FS-Verbundserver<br />
bereitstellen, die lokale Benutzer authentifizieren und <strong>Sicherheit</strong>stoken erstellen,<br />
die die Verbundserver in der Ressourcenorganisation auswerten, um Autorisierungsentscheidungen<br />
zu treffen.<br />
Der Prozess, bei dem eine Authentifizierung gegenüber einem Netzwerk durchgeführt wird,<br />
aber auf Ressourcen in einem anderen Netzwerk zugegriffen wird, ohne dafür mehrere Anmeldungen<br />
durchführen zu müssen, wird als einmaliges Anmelden (Single-Sign-On, SSO)<br />
bezeichnet. AD FS stellt eine webbasierte SSO-Lösung zur Verfügung, die Benutzer gegenüber<br />
mehreren Webanwendungen authentifiziert, aber nur während derselben Browsersitzung.<br />
Das macht es den Endbenutzern einfacher: Sie brauchen sich nur ein Kennwort zu merken.<br />
Was ist neu in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>?<br />
In AD FS unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> hat Microsoft die neue Funktionalität so entworfen,<br />
dass der Verwaltungsaufwand erleichtert und die Unterstützung für Anwendungen erweitert<br />
wird. Folgende Features sind die wichtigsten Elemente:<br />
Installation AD FS ist jetzt als <strong>Server</strong>rolle enthalten.<br />
Anwendungsunterstützung Bietet jetzt bessere Integration in Microsoft Office Share-<br />
Point <strong>Server</strong> 2007 und die Active Directory-Rechteverwaltungsdienste (Active Directory<br />
Rights Management Services, AD RMS).<br />
Benutzerzufriedenheit beim Einrichten von Verbundvertrauensstellungen Microsoft<br />
hat die Funktionen zum Importieren und Exportieren von Vertrauensrichtlinien verbessert,<br />
sodass Sie Probleme bei der Konfiguration minimieren können.<br />
AD FS-Rollendienste<br />
Wenn wir über die <strong>Server</strong>rolle Active Directory-Verbunddienste reden, vergessen wir oft,<br />
dass sie eigentlich mehrere <strong>Die</strong>nste umfasst, zum Beispiel Verbunddienste, Proxydienste und<br />
Webagentendienste. Sie müssen diese <strong>Die</strong>nste konfigurieren, um Web-SSO zu ermöglichen,<br />
Web-Ressourcen zu einem Verbund zusammenzuschalten, den Zugriff anzupassen und zu<br />
verwalten, wie vorhandene Benutzern autorisiert werden, um auf Anwendungen zuzugreifen.<br />
Abhängig von Ihren Anforderungen können Sie <strong>Server</strong> bereitstellen, die beliebige der<br />
folgenden <strong>Die</strong>nste ausführen:<br />
Verbunddienst Mindestens ein oder mehrere Verbundserver, die sich eine gemeinsame<br />
Vertrauensrichtlinie teilen. Sie nutzen die Verbundserver, um Authentifizierungsanforderungen<br />
von Benutzerkonten an andere Organisationen weiterzuleiten.<br />
Ansprüche unterstützender Agent Wird auf einem Webserver benutzt, der eine<br />
Ansprüche unterstützende Anwendung hostet, um die Abfrage von AD FS-<strong>Sicherheit</strong>stokenansprüchen<br />
zu ermöglichen. Damit die Anwendung Ansprüche unterstützt, muss
Weitere Informationen 271<br />
sie Ansprüche einsetzen, die in einem AD FS-<strong>Sicherheit</strong>stoken vorhanden sind, um<br />
Autorisierungsentscheidungen zu treffen und Anwendungen individuell anzupassen.<br />
Verbunddienstproxy <strong>Die</strong>s ist ein Proxy für den Verbunddienst im Grenznetzwerk.<br />
Der Verbunddienstproxy setzt WS-F-PRP-Protokolle (WS-Federation Passive Requestor<br />
Profile) ein, um Benutzeranmeldeinformationen von Browserclients zu sammeln. Dann<br />
sendet er die Benutzeranmeldeinformationen im Namen der Benutzer an den Verbunddienst.<br />
<strong>Windows</strong>-Token-basierter Agent Wird auf einem Webserver benutzt, der eine<br />
<strong>Windows</strong> NT-Token-basierte Anwendung hostet, um die Konvertierung von einem<br />
AD FS-<strong>Sicherheit</strong>stoken in ein <strong>Windows</strong> NT-Zugriffstoken auf Identitätswechselebene<br />
zu ermöglichen. Eine <strong>Windows</strong> NT-Token-basierte Anwendung ist eine Anwendung, die<br />
<strong>Windows</strong>-Autorisierungsmechanismen einsetzt.<br />
Sie verwalten <strong>Server</strong>rollen im MMC-Snap-In. Wenn Sie AD FS installieren, können Sie im<br />
Snap-In Active Directory-Verbunddienste die Rollendienste Verbunddienst und Verbunddienstproxy<br />
verwalten. Den Rollendienst <strong>Windows</strong>-Token-basierter Agent verwalten Sie im<br />
Internetinformationsdienste-Manager.<br />
Zusammenfassung<br />
Alle diese neuen Features in Active Directory helfen Ihnen bei Ihrer täglichen Aufgabe, Ihre<br />
Umgebung zu schützen. Damit Sie Ihre Umgebung so sicher wie möglich machen können,<br />
müssen Sie vor allem die eingesetzten Technologien beherrschen. Aber vergessen Sie niemals,<br />
dass »sicher« nur ein Eintrag im Wörterbuch ist. Nichts ist für alle Zeiten sicher (nur<br />
wenn Sie es erstmals implementieren und nur, bevor die Technologie allgemein bekannt wird),<br />
weil jemand versuchen wird, es zu hacken, sobald es verfügbar wird. Wir können niemals<br />
wissen, was morgen passiert. Aus diesem Grund ist es so wichtig, dass wir die zugrunde<br />
liegende Technologie und die größte Bedrohung von allen kennen: Benutzer.<br />
Weitere Informationen<br />
Microsoft Corporation (2007): <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Homepage unter<br />
http://www.microsoft.com/windowsserver<strong>2008</strong>/default.mspx.<br />
Microsoft Corporation (2006, 2007): »New Networking Features in <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong> and <strong>Windows</strong> Vista« unter http://technet.microsoft.com/en-us/library/<br />
bb726965.aspx.<br />
Microsoft Corporation (2007): »<strong>Windows</strong> Firewall with Advanced Security <strong>–</strong> Diagnostics<br />
and Troubleshooting« unter http://technet2.microsoft.com/<strong>Windows</strong>Vista/en/library/<br />
9428d113-ade8-4dbe-ac05-6ef10a6dd7a51033.mspx?mfr=true.<br />
Microsoft Corporation (2007): <strong>Server</strong> and Domain Isolation-Homepage unter<br />
http://technet.microsoft.com/en-us/network/bb545651.aspx.<br />
Microsoft Corporation (2007): Network Access Protection-Homepage unter<br />
http://technet.microsoft.com/en-us/network/bb545879.aspx.
K A P I T E L 1 0<br />
Implementieren der Active Directory-<br />
Zertifikatdienste<br />
Von Brian Komar<br />
In diesem Kapitel:<br />
Was ist neu in der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-PKI? ............................... 274<br />
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten ................. 275<br />
Schützen von Zertifikatdiensten .......................................... 286<br />
Empfehlungen ..................................................... 288<br />
Zusammenfassung .................................................. 289<br />
Weitere Informationen ................................................ 289<br />
<strong>Die</strong>ses Kapitel soll Sie in die Lage versetzen, die neuen Features zu erkennen, die in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> zu den Active Directory-Zertifikatdiensten hinzugefügt wurden, die<br />
Bedrohungen für Active Directory-Zertifikatdienste und die Abwehrmöglichkeiten zum<br />
Verringern dieser Bedrohungen zu identifizieren, physische <strong>Sicherheit</strong>smaßnahmen zum<br />
Schutz von Zertifizierungsstellen kennenzulernen und Verfahrensempfehlungen für Bereitstellungen<br />
der Active Directory-Zertifikatdienste zu bewerten.<br />
<strong>Die</strong> Installation der Active Directory-Zertifikatdienste ermöglicht Ihnen, in einem Microsoft-<br />
Netzwerk eine Zertifizierungsstelle (engl. Certification Authority, CA) zu konfigurieren, die<br />
digitale Zertifikate an Benutzer und Computer ausstellt. <strong>Die</strong> Active Directory-Zertifikatdienste<br />
sind die Kernkomponente der Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-PKI (Public Key<br />
Infrastructure).<br />
Active Directory-Zertifikatdienste erlauben es, zwei Arten von Zertifizierungsstellen zu<br />
installieren: eigenständige Zertifizierungsstellen (engl. stand-alone certification authority)<br />
und Unternehmenszertifizierungsstellen (engl. enterprise certification authority). Eine eigenständige<br />
Zertifizierungsstelle wird normalerweise für Offlinezertifizierungsstellen eingesetzt<br />
(Zertifizierungsstellen, die nicht in das Netzwerk eingebunden sind, um die <strong>Sicherheit</strong> zu<br />
erhöhen). Eine Unternehmenszertifizierungsstelle wird normalerweise eingesetzt, um Zertifikate<br />
an Benutzer, Computer und Netzwerkgeräte auszustellen.<br />
Weitere Informationen Zertifikatdienste<br />
<strong>Die</strong>ses Kapitel konzentriert sich darauf, wie Sie Ihre Zertifikatdienstebereitstellung schützen. Einzelheiten,<br />
wie Sie Ihre PKI entwerfen, Zertifikatdienste implementieren, Zertifikatsvorlagen entwickeln und Zertifikate<br />
für übliche Anwendungen bereitstellen, finden Sie in Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> <strong>–</strong> PKI und Zertifikatsicherheit<br />
(Microsoft Press, <strong>2008</strong>).<br />
273
274 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
Was ist neu in der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-PKI?<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> führt einige neue Features für die PKI ein, darunter folgende:<br />
Cryptography Next Generation (CNG) Cryptography Next Generation ersetzt als<br />
Kryptografie-API die ursprüngliche <strong>Windows</strong> CryptoAPI. <strong>Die</strong> neuen APIs erlauben den<br />
Einsatz neuerer, stärkerer Verschlüsselungs- und Signaturalgorithmen bei der Implementierung<br />
von Kryptografie. Das bekannteste Feature von CNG ist die Implementierung<br />
der Suite-B-Algorithmen. Suite-B-Algorithmen wurden von der United States National<br />
Security Agency (NSA) im Jahr 2005 angekündigt. Sie stellen verbesserte Standards für<br />
symmetrische Verschlüsselung, Schlüsselaustausch, digitale Signaturen und Hash-Algorithmen<br />
zur Verfügung. <strong>Die</strong> Algorithmen sind zwar öffentlich bekannt, aber trotzdem<br />
sehr sicher. Das sind unter anderem ECDH (Elliptical Curve Diffie-Hellman) für Schlüsselaustausch,<br />
ECDS (Elliptical Curve Digital Signing) zum Signieren von Daten, längere<br />
SHA (Shivest Hash Algorithm) und AES (Advanced Encryption Standard) für symmetrische<br />
Verschlüsselung.<br />
Online Certificate Status Protocol (OCSP) Online Certificate Status Protocol erlaubt<br />
es Clients, sofortigen Sperrstatus für ein bestimmtes Zertifikat zu empfangen. Der OCSP-<br />
Client sendet die Anforderung an einen OCSP-Responder. Der OCSP-Responder ruft<br />
Sperrinformationen direkt von der Zertifizierungsstelle ab und antwortet mit dem Status<br />
des angefragten Zertifikats. OCSP bietet aktuellere Sperrinformationen als die üblichen<br />
Zertifikatsperrlisten (Certificate Revocation List, CRL) und generiert bekannte Datenverkehrsmuster,<br />
weil die Größe von Anforderung und Antwort bekannt ist. Der OCSP-<br />
Responder in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> funktioniert mit <strong>Windows</strong>-Zertifizierungsstellen<br />
und Nicht-<strong>Windows</strong>-Zertifizierungsstellen.<br />
Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Services,<br />
NDES) <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> implementiert das SCEP (Simple Certificate Enrollment-Protokoll)<br />
von Cisco System als Standardkomponente des Betriebssystems. Während<br />
in <strong>Windows</strong> <strong>Server</strong> 2003 Add-On-Software aus dem <strong>Windows</strong> <strong>Server</strong> 2003 Resource<br />
Kit erforderlich war, steht NDES nun über den Assistenten "Rollen hinzufügen" zur<br />
Verfügung. NDES erlaubt es Netzwerkgeräten, die SCEP unterstützen, Zertifikate automatisch<br />
von einer <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Zertifizierungsstelle anzufordern, auch wenn<br />
sie kein Computerkonto in Active Directory haben.<br />
Version-3-Zertifikatsvorlagen <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bietet weitere Anpassungsmöglichkeiten<br />
für Zertifikatsvorlagen, indem es Version-3-Zertifikatsvorlagen einführt. Version-3-Zertifikatsvorlagen<br />
ermöglichen es Ihnen, CNG-Algorithmen innerhalb von Zertifikaten<br />
zu implementieren, die auf der Version-3-Zertifikatsvorlage basieren. Wegen der<br />
Anforderung, dass CNG-Algorithmen zur Verfügung stehen, können Version-3-Zertifikatsvorlagen<br />
nur von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Unternehmenszertifizierungsstellen herausgegeben<br />
werden.
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten 275<br />
Bedrohungen für Zertifikatdienste und<br />
Eindämmungsmöglichkeiten<br />
Wenn Sie Zertifikatdienste bereitstellen, müssen Sie eine Reihe neuer Bedrohungen beachten,<br />
die in diesem Zusammenhang auftauchen. <strong>Die</strong>se Bedrohungen sind unter anderem:<br />
Kompromittierung des Schlüsselpaars einer Zertifizierungsstelle<br />
Verhinderung von Zertifikatsperrprüfungen<br />
Versuche, die Konfiguration der Zertifizierungsstelle zu verändern<br />
Versuche, eine Zertifikatsvorlage zu verändern<br />
Hinzufügen nichtvertrauenswürdiger Zertifizierungsstellen zum Speicher der vertrauenswürdigen<br />
Stammzertifizierungsstellen<br />
Registrierungs-Agenten, die nichtautorisierte Zertifikate ausstellen<br />
Kompromittierung einer Zertifizierungsstelle durch einen einzelnen Administrator<br />
Unautorisierte Wiederherstellung des privaten Schlüssels eines Benutzers aus der Zertifizierungsstellendatenbank<br />
Wir beginnen dieses Kapitel damit, dass wir uns diese Bedrohungen genauer ansehen und<br />
aufzeigen, welche Methoden zur Verfügung stehen, um die Bedrohungen einzudämmen.<br />
Kompromittierung des Schlüsselpaars einer Zertifizierungsstelle<br />
Jede Zertifizierungsstelle in einer Zertifizierungsstellenhierarchie hat ein digitales Zertifikat,<br />
das die Zertifizierungsstelle repräsentiert. Das Zertifikat enthält einen öffentlichen Schlüssel<br />
und den zugehörigen privaten Schlüssel. Falls Angreifer es schaffen, sich Zugriff auf den<br />
privaten Schlüssel einer Zertifizierungsstelle zu verschaffen und das Zertifikat mit den zugehörigen<br />
Schlüsseln zu exportieren, können Sie eine Kopie der Zertifizierungsstelle aufbauen<br />
und im Netzwerk gültige Zertifikate ausstellen. Sie müssen alle Paare aus privaten<br />
und öffentlichen Schlüsseln der Zertifizierungsstelle schützen, damit Angreifer niemals<br />
Zugriff darauf bekommen.<br />
Falls Sie einen softwarebasierten Kryptografiedienstanbieter (Cryptographic Service Provider,<br />
CSP) einsetzen, kann jedes Mitglied der lokalen Gruppe Administratoren den privaten<br />
Schlüssel und die Zertifikate der Zertifizierungsstelle in ein portables Dateiformat exportieren.<br />
<strong>Die</strong>ser exportierte private Schlüssel kann dann auf jedem Computer importiert werden,<br />
der darauf in der Lage ist, Zertifikate auszustellen, denen im Netzwerk Ihrer Organisation<br />
vertraut wird. Und weil die echte Zertifizierungsstelle die gefälschten Zertifikate gar nicht<br />
kennt, können sie nicht ohne Weiteres gesperrt werden. <strong>Die</strong> einzige Methode, einen solchen<br />
Angriff unwirksam zu machen, besteht darin, das Zertifikat der Zertifizierungsstelle zu sperren,<br />
eine Ersatzzertifizierungsstelle einzurichten und alle Zertifikate, die von der angegriffenen<br />
Zertifizierungsstelle ausgestellt wurden, neu auszustellen.<br />
Sie können folgende Maßnahmen ergreifen, um die Zertifizierungsstellen in Ihrer Zertifizierungsstellenhierarchie<br />
gegen diese Art Angriff zu schützen:<br />
Überwachen und Kontrollieren Sie die Mitgliedschaft in der lokalen Gruppe Administratoren.<br />
Indem Sie die Mitgliedschaft in der lokalen Gruppe Administratoren kontrollieren,<br />
können Sie einschränken, welche Benutzerkonten auf den privaten Schlüssel der Zertifizierungsstelle<br />
zugreifen dürfen. Außerdem sollten Sie die Mitgliedschaft überwachen,<br />
um festzustellen, ob ein nichtautorisierter Benutzer hinzugefügt wurde.
276 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
Implementieren Sie FIPS-140-2-Level-2 (Federal Information Processing Standards)<br />
oder -Level-3-Hardwareschutz für die privaten Schlüssel der Zertifizierungsstelle. Ein<br />
Hardwaresicherheitsmodul (Hardware Security Module, HSM) schützt den privaten<br />
Schlüssel der Zertifizierungsstelle in einem dedizierten Hardwaregerät. Das private<br />
Schlüsselmaterial wird mit <strong>Sicherheit</strong>stoken geschützt, die erzwingen, dass mehrere Personen<br />
anwesend sind, um auf den privaten Schlüssel der Zertifizierungsstelle zugreifen<br />
zu können.<br />
Verhinderung von Zertifikatsperrprüfungen<br />
Zertifikatbasierte Anwendungen überprüfen Zertifikate normalerweise, bevor sie die Zertifikate<br />
für Authentifizierung, Signierung oder Verschlüsselung einsetzen. Bei einer der durchgeführten<br />
Überprüfungen wird festgestellt, ob das vorgelegte Zertifikat vor seinem normalen<br />
Ablaufdatum gesperrt wurde. Wenn ein Zertifikat gesperrt wird, werden die Seriennummer<br />
des Zertifikats, der Sperrzeitpunkt und ein Grund für die Sperrung in einer Zertifikatsperrliste<br />
(Certificate Revocation List, CRL) aufgezeichnet.<br />
Ein Angreifer hat drei Möglichkeiten, eine solche Zertifikatsperrprüfung zu verhindern:<br />
Der Angreifer kann die Anwendung daran hindern, die Zertifikatsperrung zu prüfen.<br />
Bei diesem Angriff verhindert der Angreifer, dass die Anwendung den Sperrstatus eines<br />
Zertifikats überprüft. Zum Beispiel hat der Internet Explorer 7.0 sicherere Standardeinstellungen,<br />
sodass er automatisch den Sperrstatus für die Zertifikate von Anwendungsherausgebern<br />
und SSL-geschützten (Secure Sockets Layer) Websites prüft. Wie<br />
in Abbildung 10.1 zu sehen, kann für heruntergeladene Anwendungen und Websitezertifikate<br />
geprüft werden, ob sie gesperrt wurden.<br />
Abbildung 10.1 Aktivieren der Zertifikatsperrprüfung im Internet Explorer
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten 277<br />
Sie können diesen Angriff verhindern, indem Sie die Anwendungen sperren, um sicherzustellen,<br />
dass sie eine Zertifikatsperrprüfung erzwingen. Zum Beispiel können Sie in<br />
Internet Explorer die Zertifikatsperrprüfung über Gruppenrichtlinien aktivieren.<br />
Sie können ein Gruppenrichtlinienobjekt definieren, das die Einstellung Benutzerkonfiguration\Administrative<br />
Vorlagen\<strong>Windows</strong>-Komponenten\Internet Explorer\Internetsystemsteuerung\Seite<br />
"Erweitert"\Auf gesperrte <strong>Server</strong>zertifikate überprüfen aktiviert,<br />
um die Zertifikatsperrprüfung für alle Webserverzertifikate zu erzwingen. Genauso können<br />
Sie die Einstellung Benutzerkonfiguration\ Administrative Vorlagen\<strong>Windows</strong>-Komponenten\Internet<br />
Explorer\Internetsystemsteuerung\Seite "Erweitert"\Installation bzw.<br />
Ausführung von Software zulassen, auch wenn die Signatur ungültig ist aktivieren, um<br />
die Zertifikatsperrprüfung für Anwendungen zu erzwingen.<br />
Ein Angreifer kann den Zugriff auf die <strong>Server</strong> unterbinden, die die CRLs oder Zertifizierungsstellenzertifikate<br />
hosten. Falls eine Anwendung keine zwischengespeicherten,<br />
aktuellen Versionen der Zertifikatsperrliste oder Zertifizierungsstellenzertifikate hat,<br />
versucht die Anwendung, eine neue Version herunterzuladen. Dabei geht sie nach folgendem<br />
Schema vor:<br />
AIA-URLs (Authority Information Access) erlauben den Download von aktualisierten<br />
Zertifizierungsstellenzertifikaten, falls ein Zertifizierungsstellenzertifikat<br />
erneuert oder noch nicht auf den Client heruntergeladen wurde.<br />
Zertifikatsperrlisten erlauben den Download von aktualisierten Basis-CRLs oder<br />
Delta-CRLs (eine gekürzte Liste, die nur Zertifikate umfasst, die seit der Veröffentlichung<br />
der letzten Basis-CRL gesperrt wurden).<br />
Hinweis Bei der Zertifikatsperrprüfung müssen das Client- oder <strong>Server</strong>zertifikat und alle Zertifizierungsstellenzertifikate<br />
in der Zertifikatkette geprüft werden. Falls irgendein Zertifikat in der Kette die<br />
Zertifikatsperrprüfung nicht besteht, gilt das Client- oder <strong>Server</strong>zertifikat als gesperrt. Falls irgendeine<br />
Zertifikatsperrliste nicht verfügbar ist, wird das Zertifikat als nicht vertrauenswürdig eingestuft. <strong>Die</strong> Anwendung<br />
zeigt daraufhin meist eine Meldung an, dass der Sperrstatus nicht ermittelt werden kann.<br />
Ein Angreifer kann den Zugriff auf den <strong>Server</strong>cluster verhindern, der als OCSP-Responder<br />
(Online Certificate Status-Protokoll) agiert. OCSP ist ein Protokoll, das benutzt wird,<br />
um bei einem OCSP-Responder den Zertifikatstatus eines einzelnen Zertifikats abzufragen,<br />
dessen Seriennummer dabei angegeben wird. Der OCSP-Responder antwortet mit<br />
einer von drei möglichen Nachrichten: »OK«, »Gesperrt« (revoked) oder »Sperrstatus<br />
kann nicht ermittelt werden« (cannot determine revocation status). Falls der OCSP-<br />
Client nicht mit dem OCSP-Responder kommunizieren kann, stuft die Anwendung das<br />
Zertifikat als gesperrt ein, mit dem Grund »Sperrstatus kann nicht ermittelt werden«.<br />
Direkt von der Quelle: Vorsicht bei HTTP-URLs auf mehreren <strong>Server</strong>n<br />
Passen Sie auf, wenn Sie Zertifizierungsstellenzertifikate oder CRLs auf mehreren <strong>Server</strong>n<br />
hosten. <strong>Die</strong> Batchdatei, die das Zertifizierungsstellenzertifikat und die CRLs auf den<br />
Hostwebserver überträgt, muss sicherstellen, dass das Zertifizierungsstellenzertifikat oder<br />
die Zertifikatsperrliste auf alle <strong>Server</strong> im Cluster oder in der <strong>Server</strong>gruppe kopiert wird.<br />
Falls Zertifizierungsstellenzertifikat oder Zertifikatsperrliste nur auf einigen der Knoten<br />
im Cluster zur Verfügung steht, erhalten einige Clients bei der Sperrprüfung einen Fehler.
278 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
Bei Clients, die Verbindungen zu einem Knoten herstellen, dessen Zertifizierungsstellenzertifikat<br />
oder Zertifikatsperrliste abgelaufen oder nicht vorhanden ist, schlägt die Zertifikatsperrprüfung<br />
fehl, was unter Umständen die Ausführung der Anwendung verhindert.<br />
Etwa 80 Prozent der Anrufe beim Produktsupport zum Thema Zertifikatnutzung werden<br />
durch falsch veröffentlichte Zertifizierungsstellenzertifikat- und Zertifikatsperrlisteninformationen<br />
verursacht.<br />
Seth Scruggs, PSS Support Engineer<br />
Am besten können Sie Zertifikatsperrprüfungsangriffe verhindern, indem Sie sicherstellen,<br />
dass alle Benutzer jederzeit auf Veröffentlichungspunkte für die Zertifikatsperrprüfung zugreifen<br />
können. Das Zertifikatverkettungsmodul muss Zugriff auf die Zertifikatsperrliste<br />
und das Zertifizierungsstellenzertifikat jeder Zertifizierungsstelle in der Zertifikatkette oder<br />
auf den OCSP-Responder für jede Zertifizierungsstelle in der Kette haben, falls OCSP für<br />
die Zertifikatsperrprüfung eingesetzt wird. Falls irgendeine Zertifizierungsstelle in der Zertifikatsperrliste<br />
der Zertifikatkette, irgendein Zertifizierungsstellenzertifikat oder irgendein<br />
OCSP-Responder nicht verfügbar ist, verhindert das Verkettungsmodul, dass dieses Zertifikat<br />
benutzt wird (sofern die Zertifikatsperrung aktiviert ist). Sie können sicherstellen, dass<br />
die Clients Kontakt mit dem Zertifikatsperrlisten-Verteilungspunkt oder dem OCSP-Responder<br />
bekommen, indem Sie die URLs auf <strong>Server</strong>clustern oder Lastverteilungsclustern mit<br />
sehr hoher Verfügbarkeit hosten.<br />
Abbildung 10.2 <strong>Die</strong> Reihenfolge der URLs ist sehr wichtig<br />
für die CDP- und AIA-Erweiterungen
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten 279<br />
Wenn Sie die CDP- und AIA-URLs definieren, sollten Sie sicherstellen, dass Sie die URLs<br />
so sortieren, dass die Mehrzahl der Anwendungen, die eine Zertifikatsperrprüfung durchführen,<br />
auf die primäre URL zugreifen. In Abbildung 10.2 sind die URLs so angeordnet, dass<br />
eine HTTP-URL die primäre URL ist und LDAP die sekundäre URL. <strong>Die</strong>se Reihenfolge<br />
erlaubt es Nicht-<strong>Windows</strong>-Computern, über die primäre URL auf Zertifikatsperrliste oder<br />
Zertifizierungsstellenzertifikat zuzugreifen, ohne auf die sekundäre URL zurückgreifen zu<br />
müssen.<br />
Falls Sie OCSP für die Zertifikatsperrprüfung implementieren, müssen Sie sicherstellen,<br />
dass der OCSP-Responder für alle Zertifikatsperrprüfungen zur Verfügung steht. Sie können<br />
Netzwerklastenausgleich implementieren, um sicherzustellen, dass der OCSP-Responder<br />
hochverfügbar ist.<br />
Versuche, die Konfiguration der Zertifizierungsstelle zu verändern<br />
Falls es einem Angreifer gelingt, sich auf dem Computer, der die Active Directory-Zertifikatdienste<br />
ausführt, Zugriff als lokaler Administrator zu verschaffen, kann er die Konfiguration<br />
der Zertifizierungsstelle verändern. Dabei kann er zum Beispiel die URLs für die Veröffentlichung<br />
von Zertifikatsperrlisten ändern, echte Zertifikate sperren und Zertifikate an ungültige<br />
Computer oder Benutzer ausstellen.<br />
Sie können solche Manipulationen an der Konfiguration der Zertifizierungsstelle verhindern,<br />
indem Sie die Mitgliedschaft in den Verwaltungsgruppen der Zertifizierungsstelle einschränken.<br />
<strong>Die</strong> Konfigurationsänderungen werden als Registrierungseinträge gespeichert. Nur Mitglieder<br />
der lokalen Gruppe Administratoren und Gruppen, denen die Berechtigung Zertifizierungsstelle<br />
verwalten für die Zertifizierungsstelle zugewiesen wurde, können Änderungen<br />
an der Konfiguration der Zertifizierungsstelle vornehmen. Das Problem ist, dass ein<br />
Mitglied der Gruppe Administratoren Änderungen an der Konfiguration der Zertifizierungsstelle<br />
vornehmen kann. Um feststellen zu können, wer eine autorisierte oder unautorisierte<br />
Änderung an der Konfiguration der Zertifizierungsstelle vorgenommen hat, sollten Sie die<br />
Überwachung auf der Zertifizierungsstelle aktivieren. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> können Sie<br />
definieren, welche Verwaltungsvorgänge im <strong>Sicherheit</strong>sprotokoll der Zertifizierungsstelle<br />
aufgezeichnet werden. Um sicherzustellen, dass alle Ereignisse im Bereich der Active Directory-Zertifikatdiensteüberwachung<br />
im <strong>Sicherheit</strong>sprotokoll aufgezeichnet werden, sollten<br />
Sie Erfolgs- und Fehlerereignisse für Objektzugriffsversuche auf der Zertifizierungsstelle<br />
aktivieren. <strong>Die</strong> Einstellungen können Sie direkt in der Konsole Lokale <strong>Sicherheit</strong>srichtlinie<br />
vornehmen, Sie können aber auch ein Gruppenrichtlinienobjekt (Group Policy Object, GPO)<br />
mit den erforderlichen Überwachungseinstellungen anwenden.<br />
Sobald Sie die Objektzugriffsüberwachung aktiviert haben, können Sie einzelne Überwachungseinstellungen<br />
in der Konsole Zertifizierungsstelle aktivieren. Wie in Abbildung 10.3<br />
gezeigt, können Sie folgende Überwachungsoptionen auf der Registerkarte Überwachung<br />
im Eigenschaftendialogfeld der Zertifizierungsstelle aktivieren:<br />
Datenbank der Zertifizierungsstelle sichern/wiederherstellen Protokolliert alle<br />
Versuche, die Zertifizierungsstellendatenbank zu sichern oder wiederherzustellen, im<br />
<strong>Windows</strong>-<strong>Sicherheit</strong>sprotokoll.<br />
Zertifizierungsstellenkonfiguration ändern Protokolliert alle Versuche, die Konfiguration<br />
der Zertifizierungsstelle zu verändern. Das umfasst unter anderem die Definition<br />
von AIA- (Authority Information Access) und CDP-URLs (CRL Distribution Point) oder<br />
eines Schlüsselwiederherstellungs-Agenten.
280 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
<strong>Sicherheit</strong>seinstellungen der Zertifizierungsstelle ändern Protokolliert alle Versuche,<br />
Berechtigungen der Zertifizierungsstelle zu ändern, zum Beispiel durch Hinzufügen<br />
von Zertifizierungsstellenadministratoren oder Zertifikatverwaltungen.<br />
Zertifikatanforderungen verwalten und ausstellen Protokolliert alle Versuche einer<br />
Zertifikatverwaltung, Zertifikatanforderungen zu gewähren oder zu verweigern, deren<br />
Genehmigung aussteht.<br />
Zertifikate sperren und Sperrlisten veröffentlichen Protokolliert alle Versuche einer<br />
Zertifikatverwaltung, ein ausgestelltes Zertifikat zu sperren, oder Versuche eines Zertifizierungsstellenadministrators,<br />
eine aktualisierte Zertifikatsperrliste zu veröffentlichen.<br />
Archivierte Schlüssel sichern und abrufen Protokolliert alle Versuche, während des<br />
Registrierungsprozesses private Schlüssel in der Zertifizierungsstellendatenbank zu archivieren,<br />
oder Versuche von Zertifikatverwaltungen, archivierte private Schlüssel aus<br />
der Zertifizierungsstellendatenbank abzurufen.<br />
Active Directory-Zertifikatdienste starten/beenden Protokolliert alle Versuche eines<br />
Zertifizierungsstellenadministrators, die Zertifikatdienste zu starten und zu beenden.<br />
Abbildung 10.3 Überwachungsoptionen für eine<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Zertifizierungsstelle<br />
Versuche, eine Zertifikatsvorlage zu verändern<br />
Zertifikatsvorlagen können Sie sich als Baupläne für Zertifikate vorstellen, die eine <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>-Unternehmenszertifizierungsstelle ausstellt. Falls Angreifer Zugriff auf der<br />
Ebene eines Unternehmensadministrators erhält (oder auf der Ebene eines Administrators<br />
für die Stammdomäne der Gesamtstruktur), kann er die Eigenschaften einer Zertifikatsvorlage<br />
im Container CN=Certificate Templates,CN=Public Key Services,CN=Services,<br />
CN=Configuration, verändern, wobei der
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten 281<br />
LDAP-Name (Lightweight Directory Access Protocol) der Gesamtstruktur-Stammdomäne<br />
ist. Wie umfangreich die Änderungen sind, die ein Angreifer vornehmen kann, hängt davon<br />
ab, welche Art von Zertifikatsvorlage er manipuliert:<br />
Bei Version-1-Zertifikatsvorlagen kann ein Angreifer lediglich die Berechtigungen für<br />
die einzelnen Zertifikatsvorlagen verändern. Das ermöglicht es dem Angreifer, ein Zertifikat<br />
auszustellen, das erhöhte Berechtigungen gewährt (zum Beispiel ein Zertifikat für<br />
einen Registrierungs-Agenten). So kann der Angreifer zusätzliche Zertifikate im Namen<br />
anderer Benutzer anfordern.<br />
Version-2- oder Version-3-Zertifikatsvorlagen, die von Unternehmenszertifizierungsstellen<br />
veröffentlicht werden, die unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Enterprise Edition oder Datacenter<br />
Edition laufen, verschaffen einem Angreifer viele Möglichkeiten, die Konfiguration<br />
zu manipulieren. Zum Beispiel kann er den gesamten Zweck des Zertifikats,<br />
Anwendungsrichtlinien, Schlüsselarchivierungsanforderungen, Gültigkeitsdauer und<br />
Format des Antragstellernamens verändern. So kann ein Angreifer zum Beispiel den<br />
Zweck der Zertifikatsvorlage so ändern, dass die Schlüsselarchivierung aktiviert wird,<br />
sofern die Zertifikatsvorlage verschlüsselungsfähig ist.<br />
Hinweis Weitere Informationen zur Bedeutung von Zertifikatsvorlagen in einem Microsoft <strong>Windows</strong>-<br />
Netzwerk finden Sie im Whitepaper »Implementing and Administering Certificate Templates in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>« unter http://go.microsoft.com/fwlink/?LinkID=92522.<br />
Sie sollten regelmäßig die Zertifikatsvorlagendefinitionen für die Zertifikatsvorlagen überprüfen,<br />
die Sie in Ihrer Gesamtstruktur bereitstellen. Stellen Sie sicher, dass die Einstellungen<br />
Ihrem Entwurf entsprechen. Achten Sie besonders auf Berechtigungszuweisungen, um<br />
sicherzustellen, dass unautorisierte Benutzer keine Lesen- und Registrieren-Berechtigungen<br />
für eine Zertifikatsvorlage zugewiesen bekommen. Zum Beispiel könnte ein Angreifer versuchen,<br />
sich Zugriff auf ein Zertifikat mit besonderen Privilegien zu verschaffen, zum Beispiel<br />
ein Registrierungs-Agent-Zertifikat. Das Registrierungs-Agent-Zertifikat erlaubt dem<br />
Besitzer, das Zertifikat im Namen eines anderen Benutzers anzufordern. Wenn ein Angreifer<br />
über ein Registrierungs-Agent-Zertifikat verfügt, kann er ein Zertifikat für jeden Benutzer in<br />
der Gesamtstruktur anfordern, ohne Konto oder Kennwort des Benutzers wissen zu müssen.<br />
Hinzufügen nichtvertrauenswürdiger Zertifizierungsstellen zum Speicher<br />
der vertrauenswürdigen Stammzertifizierungsstellen<br />
Falls Angreifer ein nicht vertrauenswürdiges Zertifizierungsstellenzertifikat zum Speicher<br />
der vertrauenswürdigen Stammzertifizierungsstellen hinzufügen kann, werden alle Zertifikate,<br />
deren Zertifikatkette zu diesem Stammzertifizierungsstellenzertifikat zurückführen, als<br />
vertrauenswürdig eingestuft. Ein Zertifikat, das auf ein vertrauenswürdiges Stammzertifizierungsstellenzertifikat<br />
zurückführt, gilt für alle Zwecke als vertrauenswürdig. Ein vertrauender<br />
Partner vertraut einem solchen Zertifikat genauso wie er einem Zertifikat vertraut, das<br />
von einer gültigen Zertifizierungsstelle in derselben Hierarchie ausgestellt wurde.<br />
Stattdessen könnte ein Angreifer auch versuchen, eine Zertifikatvertrauensliste (Certificate<br />
Trust List, CTL) zu erstellen. <strong>Die</strong>s ist eine Liste der Zertifizierungsstellenzertifikate, die<br />
nicht von der Zertifizierungsstellenhierarchie Ihres Unternehmens ausgestellt werden, denen<br />
aber für bestimmte Zwecke und bestimmte Zeiträume vertraut wird. Das ermöglicht es dem<br />
Angreifer, in Ihrem Netzwerk ein Zertifikat zu benutzen, das von einer fremden, nicht ver-
282 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
trauenswürdigen Zertifizierungsstelle ausgestellt wurde. Wenn ein ahnungsloser Client die<br />
Zertifikatvertrauensliste lädt, vertraut er dem Zertifikat des Angreifers.<br />
In der Standardeinstellung bieten <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> folgende<br />
Mechanismen zum Schutz gegen die Installation eingeschleuster Stammzertifizierungsstellenzertifikate:<br />
Benutzerkontensteuerung (User Account Control, UAC) Nur Mitglieder der lokalen<br />
Gruppe Administratoren können ein Stammzertifizierungsstellenzertifikat zum Speicher<br />
der vertrauenswürdigen Stammzertifizierungsstellen des Computers hinzufügen.<br />
Falls der Angreifer eine Verknüpfung auf sein eingeschleustes Stammzertifikat angibt,<br />
warnt die UAC den Client, dass administrative Privilegien erforderlich sind, um das<br />
Stammzertifikat zu installieren.<br />
Gruppenrichtlinien für vertrauenswürdige Stammzertifizierungsstellen Über<br />
Gruppenrichtlinien können Sie Regeln definieren, wie Stammzertifizierungsstellenzertifikate<br />
hinzugefügt werden dürfen. Wie in Abbildung 10.4 zu sehen, können Sie festlegen,<br />
ob ein vom Benutzer hinzugefügtes Stammzertifikat verwendet werden kann, um<br />
Zertifikate zu validieren. Sie können auch steuern, ob der Client Peervertrauenszertifikaten<br />
vertrauen kann und ob die Clientcomputer sowohl kommerziellen als auch Stammzertifizierungsstellen<br />
des Unternehmens vertrauen oder nur Stammzertifizierungsstellen<br />
des Unternehmens.<br />
Abbildung 10.4 Definieren von Gruppenrichtlinieneinstellungen für<br />
vertrauenswürdige Stammzertifizierungsstellen
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten 283<br />
Registrierungs-Agenten, die nichtautorisierte Zertifikate ausstellen<br />
In älteren <strong>Windows</strong>-Versionen war die Rolle Registrierungs-Agent in der Lage, Smartcard-<br />
Zertifikate für beliebige Benutzer in Active Directory auszustellen. Viele Organisationen<br />
betrachteten das als <strong>Sicherheit</strong>sproblem, weil ein Registrierungs-Agent eine Smartcard für<br />
ein privilegiertes Konto, zum Beispiel ein Mitglied von Organisations-Admins, ausstellen<br />
und dann in dieser Rolle agieren konnte. Ein Benutzer, der ein Registrierungs-Agent war,<br />
war also genauso vertrauenswürdig und mächtig wie jeder andere Benutzer in der Domäne.<br />
Bei einer Unternehmenszertifizierungsstelle, die unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Enterprise<br />
Edition oder <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Datacenter Edition läuft, können Sie Einschränkungen<br />
für Registrierungs-Agenten erzwingen. <strong>Die</strong>se Einschränkungen verhindern, dass ein<br />
Registrierungs-Agent Smartcards an unautorisierte Benutzer ausstellt.<br />
Abbildung 10.5 Einschränken von Registrierungs-Agenten<br />
Wie in Abbildung 10.5 gezeigt, können Sie Registrierungs-Agenten nun auf zwei Arten<br />
einschränken:<br />
Sie können Registrierungs-Agenten so einschränken, dass sie nur Zertifikate aus einer<br />
vordefinierten Liste von Zertifikatsvorlagen anfordern dürfen. Selbst wenn der Registrierungs-Agent<br />
versehentlich Lesen- und Registrieren-Berechtigungen für weitere<br />
Zertifikatsvorlagen zugewiesen bekommen hat, bleibt der Registrierungs-Agent auf die<br />
Liste beschränkt, die auf der Registerkarte Registrierungs-Agents definiert ist. In beiden<br />
Dialogfeldern in Abbildung 10.5 wird die Gruppe West RAs darauf beschränkt, nur<br />
Smartcard-Zertifikate auf Basis der Zertifikatsvorlagen Federal Bridge Signing und<br />
Corporate Smart Card Logon auszustellen.<br />
Sie können noch weiter einschränken, an welche Gruppen Smartcard-Zertifikate anhand<br />
von Zertifikatsvorlagen ausgestellt werden dürfen. Das linke Dialogfeld in Abbildung 10.5
284 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
zeigt, dass die Gruppe West RAs nur Zertifikate auf Basis der Zertifikatsvorlage Corporate<br />
Smart Card Logon für Mitglieder der Gruppe West Smart Card Users anfordern<br />
darf. Und im rechten Dialogfeld ist festgelegt, dass die Gruppe West RAs nur Zertifikate<br />
auf Basis der Zertifikatsvorlage Federal Bridge Signing für Mitglieder der Gruppe Federal<br />
Bridge Users anfordern darf.<br />
Tipp Sie brauchen nicht alle Zertifikatsvorlagen aufzulisten, wenn Sie einer bestimmten Registrierungs-<br />
Agent-Gruppe erlauben wollen, Zertifikate für alle Zertifikatsvorlagen oder alle Benutzer anzufordern. Sie<br />
können im Feld Zertifikatsvorlagen den Eintrag auswählen und für die Benutzer die Gruppe Jeder.<br />
Außerdem können Sie explizite Verweigern-Berechtigungen hinzufügen, um zu verhindern, dass Zertifikate<br />
an eine bestimmte Gruppe oder auf Basis einer bestimmten Zertifikatsvorlage ausgestellt werden.<br />
Kompromittierung einer Zertifizierungsstelle durch einen<br />
einzelnen Administrator<br />
In der Standardeinstellung gewährt <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> der integrierten Gruppe Administratoren<br />
Berechtigungen und Benutzerrechte, um alle administrativen Aufgaben auszuführen.<br />
Falls der Computer, auf dem die Zertifikatdienste laufen, ein eigenständiger Computer<br />
ist, werden die Berechtigungen der lokalen Gruppe Administratoren zugewiesen. Falls der<br />
Computer Mitglied einer Domäne ist, werden die Berechtigungen auch den Gruppen Organisations-Admins<br />
und Domänen-Admins der Gesamtstruktur-Stammdomäne zugewiesen.<br />
Wenn alle Verwaltungsberechtigungen einem einzigen Konto oder einer Gruppe zugewiesen<br />
werden, kann jedes Mitglied der administrativen Gruppen sämtliche Verwaltungsfunktionen<br />
durchführen, ohne Beaufsichtigung durch andere Administratoren. Es ist möglich, dass ein<br />
böswilliger Administrator Änderungen an der Konfiguration der Zertifizierungsstelle vornimmt,<br />
eine große Menge von Zertifikaten sperrt, das Überwachungprotokoll löscht, um<br />
seine Spuren zu verwischen, oder eine Datensicherung der privaten Schlüssel und Datenbank<br />
der Zertifizierungsstelle durchführt, um eine Kopie der Zertifizierungsstelle anzulegen.<br />
Sie können die Gefahr, die von einem einzelnen böswilligen Administrator ausgeht, dadurch<br />
verringern, dass Sie den Empfehlungen in »Certificate Issuing and Management Components<br />
(CIMC) Family of Protection Profiles« folgen, einem Standarddokument des National<br />
Institute of Standards and Technology (NIST). <strong>Die</strong>ses Dokument definiert Anforderungen<br />
für die Ausstellung, Sperrung und Verwaltung von X.509-Zertifikaten.<br />
Hinweis <strong>Die</strong> CIMC-Schutzprofile werden oft als Common-Criteria-Richtlinien bezeichnet.<br />
<strong>Die</strong> <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-PKI folgt den Empfehlungen im Standarddokument. Eine Organisation<br />
kann daher eine PKI bereitstellen, die das Schutzprofil der <strong>Sicherheit</strong>sstufe 4 erfüllt.<br />
<strong>Die</strong>ses Profil definiert vier PKI-Verwaltungsrollen:<br />
Zertifizierungsstellenadministrator <strong>Die</strong>se Rolle übernimmt die Aufgabe der Kontoadministration<br />
und Schlüsselgenerierung für das Schlüsselpaar des Zertifizierungsstellenzertifikats.<br />
Ein Mitglied dieser Rolle kann die Konfiguration der Zertifizierungsstelle<br />
ändern. Sie weisen diese Rolle zu, indem Sie dem Benutzer oder der Gruppe in der Konsole<br />
Zertifizierungsstelle die Berechtigung Zertifizierungsstelle verwalten zuweisen.<br />
Zertifikatverwaltung <strong>Die</strong>ser Rolle fällt die Aufgabe zu, die Zertifikate zu verwalten.<br />
Zu den Verwaltungsfunktionen gehört das Ausstellen und Sperren von Zertifikaten und<br />
das Extrahieren der Blobs für private Schlüssel aus der Zertifizierungsstellendatenbank,
Bedrohungen für Zertifikatdienste und Eindämmungsmöglichkeiten 285<br />
während Schlüsselwiederherstellungsoperationen durchgeführt werden. Sie weisen diese<br />
Rolle zu, indem Sie dem Benutzer oder der Gruppe in der Konsole Zertifizierungsstelle<br />
die Berechtigung Zertifikate ausstellen und verwalten zuweisen.<br />
Revisor <strong>Die</strong>se Rolle hat die Aufgabe, die Überwachungsprotokolle der Zertifizierungsstelle<br />
zu verwalten und zu konfigurieren. Sie weisen diese Rolle zu, indem Sie dem<br />
Benutzer oder der Gruppe entweder in der Konsole Lokale <strong>Sicherheit</strong>srichtlinie oder in<br />
einem Gruppenrichtlinienobjekt, das mit der Organisationseinheit verknüpft ist, in dem<br />
das Computerkonto der Zertifizierungsstelle liegt, das Benutzerrecht Verwalten von<br />
Überwachungs- und <strong>Sicherheit</strong>sprotokollen zuweisen.<br />
Datensicherungsoperator <strong>Die</strong>se Rolle hat die Aufgabe, Datensicherungen von PKI-<br />
Informationen vorzunehmen. Sie weisen diese Rolle zu, indem Sie dem Benutzer oder<br />
der Gruppe entweder in der Konsole Lokale <strong>Sicherheit</strong>srichtlinie oder in einem Gruppenrichtlinienobjekt,<br />
das mit der Organisationseinheit verknüpft ist, in dem das Computerkonto<br />
der Zertifizierungsstelle liegt, das Benutzerrecht Sichern von Dateien und<br />
Verzeichnissen zuweisen.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Enterprise Edition und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Datacenter Edition<br />
ermöglichen Ihnen, die Common-Criteria-Rollentrennung zu erzwingen, sodass niemals<br />
dieselbe Person mehrere Common-Criteria-Rollen übernehmen kann. Ein Benutzer kann nur<br />
eine einzige der Rollen Zertifizierungsstellenadministrator, Zertifikatverwaltung, Revisor<br />
oder Datensicherungsoperator übernehmen. Werden einem Benutzer zwei oder mehr dieser<br />
Rollen zugewiesen, wird der Benutzer von allen Zertifikatverwaltungsaktionen ausgeschlossen.<br />
In der Standardeinstellung sind Mitglieder der Gruppen Organisations-Admins, Domänen-<br />
Admins der Gesamtstruktur-Stammdomäne und der lokalen Gruppe Administratoren auf der<br />
Zertifizierungsstelle von der PKI-Verwaltung ausgeschlossen, wenn Sie die Rollentrennung<br />
aktivieren. <strong>Die</strong>ser Ausschluss wird durchgeführt, weil diese Gruppen aufgrund der Standardberechtigungszuweisungen<br />
sowohl die Rolle des Revisors als auch des Datensicherungsoperators<br />
einnehmen.<br />
Hinweis Common-Criteria-Rollentrennungserzwingung kann von einem lokalen Administrator aktiviert<br />
werden, indem er an der Eingabeaufforderung certutil <strong>–</strong>setreg CA\RoleSeparationEnabled 1 eingibt<br />
und dann die Zertifikatdienste neu startet. Denken Sie daran, dass alle Benutzer, denen mehr als eine<br />
Zertifikatadministrationsrolle zugewiesen ist, ab diesem Zeitpunkt von allen Zertifizierungsstellenverwaltungsaktivitäten<br />
ausgeschlossen sind. Das können Sie rückgängig machen, indem Sie die Erzwingung der<br />
Common-Criteria-Rollentrennung mit dem Befehl certutil <strong>–</strong>delreg CA\RoleSeparationEnabled<br />
deaktivieren und dann die Zertifikatdienste neu starten.<br />
Unautorisierte Wiederherstellung des privaten Schlüssels<br />
eines Benutzers aus der Zertifizierungsstellendatenbank<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bietet die Möglichkeit, den privaten Schlüssel, der mit dem Verschlüsselungszertifikat<br />
eines Benutzers verknüpft ist, zu archivieren (hinterlegen), sofern die<br />
Zertifizierungsstelle unter <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Enterprise Edition oder <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong> Datacenter Edition läuft. Ein Angreifer könnte das Zertifikat eines beliebigen Benutzers<br />
und den privaten Schlüssel aus der Zertifizierungsstellendatenbank abrufen, falls<br />
der Angreifer sowohl ein lokaler Administrator als auch ein vorhandener Schlüsselwieder-
286 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
herstellungs-Agent auf dem Zertifizierungsstellencomputer ist, auf dem der private Schlüssel<br />
des Benutzers archiviert ist.<br />
Falls der Angreifer Zugriff auf den privaten Schlüssel des Benutzers erlangt, kann der Angreifer<br />
alle Informationen entschlüsseln, die mit dem ausgespähten Zertifikat geschützt sind.<br />
Und falls das Zertifikat eine Signierung ermöglicht, kann der Angreifer sich für den Benutzer<br />
ausgeben, um Daten digital zu signieren.<br />
Sie können diesen Angriff verhindern, indem Sie Zertifikatverwaltungen von Schlüsselwiederherstellungs-Agenten<br />
trennen. Das hat folgende Konsequenzen:<br />
Der Inhaber der Rolle Zertifikatverwaltung stellt fest, wer der Schlüsselwiederherstellungs-Agent<br />
für den archivierten privaten Schlüssel ist, und extrahiert eine verschlüsselte<br />
PKCS#7-Blob-Datei aus der Zertifizierungsstellendatenbank. Nur der Inhaber der Rolle<br />
Zertifikatverwaltung kann diese Blob-Datei extrahieren.<br />
Der Inhaber der Rolle Schlüsselwiederherstellungs-Agent kann die verschlüsselte Blob-<br />
Datei mit dem privaten Schlüssel im Zertifikat des Schlüsselwiederherstellungs-Agenten<br />
entschlüsseln. Nur der Schlüsselwiederherstellungs-Agent hat Zugriff auf den privaten<br />
Schlüssel, der die verschlüsselte Blob-Datei entschlüsseln kann.<br />
Ein Administrator kann sich selbst zu einem Schlüsselwiederherstellungs-Agenten für vorhandene<br />
archivierte Zertifikate machen. Der Schlüsselwiederherstellungs-Agent wird zu<br />
dem Zeitpunkt bestimmt, an dem der private Schlüssel archiviert wird. Solange der private<br />
Schlüssel geschützt bleibt (indem er zum Beispiel auf einer Smartcard gespeichert wird),<br />
kann ein Administrator keinen Zugriff auf den privaten Schlüssel bekommen.<br />
Schützen von Zertifikatdiensten<br />
Um die Wahrscheinlichkeit zu verringern, dass die verschiedenen weiter oben beschriebenen<br />
Bedrohungen für einen erfolgreichen Angriff genutzt werden, können Sie folgende Maßnahmen<br />
ergreifen:<br />
Implementieren von physischen <strong>Sicherheit</strong>smaßnahmen<br />
Implementieren von logischen <strong>Sicherheit</strong>smaßnahmen<br />
Implementieren physischer <strong>Sicherheit</strong>smaßnahmen<br />
Physische <strong>Sicherheit</strong>smaßnahmen verhindern, dass Angreifer physischen Zugriff auf den<br />
Computer bekommen, der die Active Directory-Zertifikatdienste ausführt. Wenn ein Angreifer<br />
physischen Zugriff auf einen Computer erhält, ist eine Vielzahl von Angriffen möglich.<br />
Physische <strong>Sicherheit</strong>smaßnahmen können Folgendes umfassen:<br />
Verwenden Sie Offlinezertifizierungsstellen. Indem Sie eine dreischichtige Hierarchie<br />
aufbauen, können Stammzertifizierungsstelle und Zertifizierungsstellen der zweiten<br />
Ebene (auch als Richtlinienzertifizierungsstellen bezeichnet) Offlinezertifizierungsstellen<br />
sein, auf die kein Remotezugriff möglich ist. Sie brauchen nicht einmal eingeschaltet<br />
zu sein. Bei einer zweischichtigen Hierarchie kann nur die Stammzertifizierungsstelle<br />
eine Offlinezertifizierungsstelle. Eine Offlinezertifizierungsstelle ist nicht an das Netzwerk<br />
angeschlossen; sie wird nur eingeschaltet, um neue Zertifikate für untergeordnete<br />
Zertifizierungsstellen auszustellen, Zertifikate für untergeordnete Zertifizierungsstellen<br />
zu erneuern und aktualisierte CRLs zu veröffentlichen. Selbst während dieser Operationen<br />
ist sie nicht mit dem Netzwerk verbunden und braucht nicht von ihrem sicheren
Schützen von Zertifikatdiensten 287<br />
Aufstellungsort wegbewegt zu werden. <strong>Die</strong> Zertifikate und CRLs können von einem<br />
Menschen an den Ort getragen werden, wo sie bereitgestellt werden.<br />
Installieren Sie Offlinezertifizierungsstellen in physisch geschützten Orten, zum Beispiel<br />
Tresorräumen, Safes oder geschützten <strong>Server</strong>räumen, je nachdem, was die <strong>Sicherheit</strong>srichtlinie<br />
Ihres Unternehmens vorschreibt.<br />
Stellen Sie Hardwareschlüsselmodule bereit, zum Beispiel Hardwaresicherheitsmodule<br />
(Hardware Security Module, HSM), um das Schlüsselpaar der Zertifizierungsstelle zu<br />
generieren und zu schützen und alle ausgestellten Zertifikate und CRLs zu signieren.<br />
HSMs ermöglichen Ihnen, eine getrennte Schlüsselverwaltung zu implementieren, wobei<br />
mehrere Schlüsselbesitzer anwesend sein müssen, um den privaten Schlüssel einer<br />
Offlinezertifizierungsstelle zu aktivieren und zu benutzen. Zum Beispiel können Sie<br />
festlegen, dass für den Zugriff auf den privaten Schlüssel der Stammzertifizierungsstelle<br />
4 Token aus einem Pool von insgesamt 11 Token vorhanden sein müssen, wobei jedes<br />
Token von einer anderen Person aufbewahrt wird.<br />
Implementieren Sie die BitLocker-Laufwerkverschlüsselung (BitLocker Drive Encryption,<br />
BDE), um das Festplattenlaufwerk der Stammzertifizierungsstelle für den Fall zu<br />
schützen, dass das Festplattenlaufwerk aus dem Computer der Zertifizierungsstelle ausgebaut<br />
wird und jemand versucht, damit einen Offlineangriff durchzuführen. BitLocker<br />
verhindert auch den Zugriff auf den lokalen Computer, falls die Person an der Konsole<br />
das TPM-Kennwort (Trusted Platform Module) oder den BDE-Wiederherstellungsschlüssel<br />
auf einem USB-Token nicht bereitstellen kann.<br />
Warnung Wenn Sie BDE auf einer Offlinezertifizierungsstelle implementieren, können Sie den Wiederherstellungsschlüssel<br />
nicht in Active Directory speichern, weil das Computerkonto kein Mitglied<br />
einer Domäne ist. Speichern Sie unbedingt mehrere Exemplare des Wiederherstellungsschlüssels auf<br />
unterschiedlichen USB-Token und bewahren Sie die Wiederherstellungsschlüssel an sicheren Orten auf.<br />
Deaktivieren Sie Hardware im BIOS des Zertifizierungsstellencomputers. Falls Sie verhindern<br />
wollen, dass der Zertifizierungsstellencomputer an das Netzwerk angeschlossen<br />
wird, können Sie die Netzwerkkarten im BIOS des <strong>Server</strong>s deaktivieren und BDE mit<br />
einem TPM-Kennwort implementieren, um einen unautorisierten Konsolenzugriff auf<br />
die Zertifizierungsstelle zu verhindern. Außerdem können Sie die USB-Anschlüsse und<br />
andere Geräte deaktivieren, um zu verhindern, dass Daten von der Festplatte des Zertifizierungsstellencomputers<br />
kopiert werden.<br />
Warnung Es ist wirklich nicht empfehlenswert, BIOS-Startkennwörter zu nutzen, um eine Offlinezertifizierungsstelle<br />
zu schützen. BIOS-Startkennwörter können bei manchen Systemen auf ein leeres<br />
Kennwort zurückgesetzt werden, indem man die Batterie auf dem Motherboard des Computers kurzschließt.<br />
Es ist auf jeden Fall besser, BDE zu implementieren, um unautorisierten Konsolenzugriff zu<br />
verhindern.<br />
Implementieren Sie Syskey-Level-2- oder -Level-3-<strong>Sicherheit</strong>, um den Start einer Offlinezertifizierungsstelle<br />
einzuschränken. Syskey-Level-2 erfordert, dass ein Kennwort<br />
eingegeben wird, bevor auf die lokale Kontendatenbank zugegriffen wird, was erforderlich<br />
ist, damit der Offlinezertifizierungsstellencomputer starten kann. <strong>Die</strong> Syskey-Level-<br />
3-Einstellung verbessert die <strong>Sicherheit</strong>, indem erzwungen wird, dass eine Diskette, die<br />
das Syskey-Kennwort enthält, eingelegt wird, um den Computer zu starten.
288 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
Warnung Falls Sie Syskey-Level-2- oder -Level-3-<strong>Sicherheit</strong> implementieren und das Kennwort vergessen<br />
oder keinen Zugriff mehr auf das Kennwort auf dem Syskey-Datenträger haben, können Sie<br />
überhaupt nicht mehr auf den Offlinezertifizierungsstellencomputer zugreifen. Stellen Sie sicher, dass<br />
das Kennwort an einem sicheren Ort aufgezeichnet wird oder dass Kopien des Syskey-Datenträgers<br />
vorhanden sind, um solche Probleme zu vermeiden.<br />
Empfehlungen<br />
Sie sollten die folgenden Verfahrensempfehlungen beachten, um Active Directory-Zertifikatdienste<br />
zu schützen:<br />
Erhöhen Sie die <strong>Sicherheit</strong> der Stammzertifizierungsstellencomputer Sie können<br />
für diesen Zweck Offlinezertifizierungsstellen und (sofern möglich) Offlinerichtlinienzertifizierungsstellen<br />
bereitstellen, je nachdem, was die <strong>Sicherheit</strong>srichtlinie Ihres Unternehmens<br />
vorschreibt.<br />
Implementieren Sie ein Hardwaresicherheitsmodul Sie sollten dies nur tun, falls die<br />
<strong>Sicherheit</strong>srichtlinie Ihres Unternehmen oder der Organisationen, mit denen Sie Zertifikate<br />
austauschen wollen, einen starken Schutz des Schlüsselpaars der Zertifizierungsstelle<br />
fordert.<br />
Stellen Sie sicher, dass CRLs und Zertifizierungsstellenzertifikate an Stellen veröffentlicht<br />
werden, auf die zugegriffen werden kann Das Zertifikatverkettungsmodul<br />
muss Zugriff auf alle CRLs und Zertifizierungsstellenzertifikate in der Zertifikatkette<br />
haben, um ein vorgelegtes Zertifikat überprüfen zu können. Falls irgendein Zertifikat<br />
oder eine Zertifikatsperrliste nicht verfügbar ist, kann sein Status nicht bestimmt werden.<br />
Stellen Sie sicher, dass OCSP-Responder hochverfügbar sind Falls Sie OCSP implementieren,<br />
müssen Sie sicherstellen, dass die OCSP-Responder nicht nur für interne<br />
und externe Benutzer verfügbar sind, sondern hochverfügbar. Sie können die <strong>Windows</strong>-<br />
Lastausgleichsdienste implementieren, um sicherzustellen, dass der OCSP-Responder<br />
auch dann noch OCSP-Anforderungen bedienen kann, wenn ein einzelner Knoten im<br />
Cluster ausfällt.<br />
Aktivieren Sie die Zertifikatsperrlistenprüfung in allen Anwendungen <strong>Die</strong> Zertifikatsperrlistenprüfung<br />
stellt sicher, dass ein vorgelegtes Zertifikat alle Überprüfungen besteht,<br />
bevor es akzeptiert wird. Falls das Zertifikat irgendeinen Test nicht besteht, wird<br />
es als ungültig eingestuft.<br />
Wenden Sie die neuesten Service Packs und <strong>Sicherheit</strong>supdates auf Zertifizierungsstellen<br />
an Auf diese Weise stellen Sie sicher, dass die Zertifizierungsstelle gegen bekannte<br />
<strong>Sicherheit</strong>slücken geschützt ist.<br />
Trennen Sie die Rollen von Zertifikatverwaltung und Schlüsselwiederherstellungs-<br />
Agent Falls eine Person beide Rollen wahrnimmt, ist es möglich, dass dieser Benutzer<br />
einen verschlüsselten privaten Schlüssel aus einer <strong>Windows</strong> <strong>Server</strong> 2003-Zertifizierungsstelle<br />
abruft und entschlüsselt, um ihn für eigene Zwecke zu missbrauchen. Indem<br />
Sie die Rollen trennen, erzwingen Sie, dass zwei Personen am Wiederherstellungsprozess<br />
teilnehmen müssen.<br />
Implementieren Sie Rollentrennung Indem Ihre Organisation den Common-Criteria-<br />
Richtlinien folgt, kann sie sicherstellen, dass niemals eine einzige Person alle PKI-<br />
Verwaltungsrollen wahrnimmt. Wenn Sie Rollentrennung implementieren, kann der
Weitere Informationen 289<br />
PKI-Verwaltungsprozess überwacht werden, sodass sichergestellt ist, dass eine Person<br />
nicht alle Verwaltungsfunktionen ausführen kann. Falls Ihre <strong>Sicherheit</strong>srichtlinie es<br />
erfordert, müssen Sie die Rollentrennung aktivieren, um zu verhindern, dass jemand<br />
PKI-Verwaltungsaufgaben übernimmt, falls er zwei oder mehrere Common-Criteria-<br />
Rollen wahrnimmt.<br />
Aktivieren Sie alle Überwachungsoptionen in einer <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Zertifizierungsstelle<br />
Indem Sie alle Überwachungsoptionen aktivieren, stellen Sie sicher,<br />
dass alle Veränderungen an der PKI im <strong>Sicherheit</strong>sereignisprotokoll der Zertifizierungsstelle<br />
aufgezeichnet werden.<br />
Aktivieren Sie Einschränkungen für Registrierungs-Agenten Stellen Sie sicher,<br />
dass ein Registrierungs-Agent nur Zertifikate für autorisierte Benutzer anfordern kann,<br />
indem Sie die Einschränkungen für Registrierungs-Agenten aktivieren. Sie können einen<br />
Registrierungs-Agenten auf eine bestimmte Zertifikatsvorlage einschränken und erzwingen,<br />
dass er nur Zertifikate für bestimmte <strong>Sicherheit</strong>sgruppen anfordern darf.<br />
Zusammenfassung<br />
Wenn Sie Ihre <strong>Sicherheit</strong>sstrategie für Active Directory-Zertifikatdienste entwerfen, müssen<br />
Sie sicherstellen, dass Sie alle Bedrohungen identifizieren, die für Ihre Bereitstellung relevant<br />
sind. Stellen Sie für jede Bedrohung sicher, dass Sie Maßnahmen zu deren Eindämmung<br />
ergreifen, aber auch den Funktionsumfang zur Verfügung stellen, den Sie von den<br />
Zertifikatdiensten brauchen.<br />
Neben der Eindämmung von Bedrohungen sollten Sie sicherstellen, dass Sie gute physische<br />
<strong>Sicherheit</strong> für Ihre Zertifizierungsstellen gewährleisten:<br />
Offlinezertifizierungsstellen sollten niemals an das Netzwerk angeschlossen sein, und sie<br />
sollten an physisch geschützten Orten aufgestellt sein.<br />
Onlinezertifizierungsstellen sollten mit derselben physischen <strong>Sicherheit</strong> wie Domänencontroller<br />
ausgestattet sein.<br />
Und schließlich sollten Sie sicherstellen, dass Sie den Verfahrensempfehlungen für die<br />
Bereitstellung von Zertifizierungsstellen folgen.<br />
Weitere Informationen<br />
Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> <strong>–</strong> PKI und Zertifikatsicherheit von Brian Komar<br />
(Microsoft Press, <strong>2008</strong>).<br />
Microsoft Official Curriculum Course 2821: Designing and Managing a <strong>Windows</strong> Public<br />
Key Infrastructure (http://www.microsoft.com/learning/syllabi/en-us/2821Afinal.mspx).<br />
Microsoft <strong>Windows</strong> <strong>Server</strong> 2003 PKI und Zertifikatsicherheit von Brian Komar und dem<br />
Microsoft PKI-Team (Microsoft Press, 2004).<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Security Guide unter https://www.microsoft.com/downloads/<br />
details.aspx?familyid=FB8B981F-227C-4AF6-A44B-B115696A80AC&displaylang=en.<br />
Security Watch <strong>–</strong> PKI Enhancements in <strong>Windows</strong> von John Morello unter<br />
http://www.microsoft.com/technet/technetmag/issues/2007/08/SecurityWatch/.
290 Kapitel 10: Implementieren der Active Directory-Zertifikatdienste<br />
Das Whitepaper »Best Practices for Implementing a Microsoft <strong>Windows</strong> <strong>Server</strong> 2003<br />
Public Key Infrastructure« unter http://www.microsoft.com/technet/prodtechnol/<br />
windowsserver2003/technologies/security/ws3pkibp.mspx.<br />
Das Whitepaper »<strong>Windows</strong> <strong>Server</strong> Active Directory Certificate Services Step-by-Step<br />
Guide« unter http://go.microsoft.com/fwlink/?LinkID=85472.<br />
Das Whitepaper »Key Archival and Recovery in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>« unter<br />
http://go.microsoft.com/fwlink/?LinkID=92523.<br />
Das Whitepaper »Troubleshooting Certificate Status and Revocation« unter<br />
http://technet.microsoft.com/en-us/library/bb457027.aspx.<br />
»Certificate Issuing and Management Components Family of Protection Profiles« unter<br />
http://www.commoncriteriaportal.org/public/files/ppfiles/PP_CIMCPP_SL1-4_V1.0.pdf.<br />
»Installing, Configuring, and Troubleshooting Microsoft Online Responder« unter<br />
http://technet2.microsoft.com/windowsserver<strong>2008</strong>/en/servermanager/activedirectory<br />
certificateservices.mspx.<br />
nCipher HSMs (http://www.ncipher.com/cryptographic_hardware/hardware_security_<br />
modules/).<br />
SafeNet HSMs (http://www.safenet-inc.com/products/pki/index.asp).<br />
Knowledge Base-Artikel 281271, »<strong>Windows</strong> 2000 Certification Authority Configuration<br />
to Publish Certificates in Active Directory of Trusted Domain« unter<br />
http://support.microsoft.com/kb/281271.<br />
»Certificate-Related Changes for Vista« unter http://technet2.microsoft.com/<strong>Windows</strong><br />
Vista/en/library/73bdca07-a9f0-40d7-a26e-6f4f11759e4c1033.mspx?mfr=true.
K A P I T E L 1 1<br />
Implementieren der Active Directory-<br />
Rechteverwaltungsdienste<br />
Von Kurt Dillard<br />
In diesem Kapitel:<br />
Grundlagen von RMS ................................................ 293<br />
Implementieren von AD RMS ........................................... 297<br />
Integration mit Microsoft Office .......................................... 311<br />
Einsetzen von RMS, um bestimmte Anforderungen zu erfüllen ..................... 312<br />
Einschränkungen von AD RMS .......................................... 314<br />
Zusammenfassung .................................................. 314<br />
Weitere Informationen ................................................ 315<br />
Verschlüsselung wird seit vielen Jahren genutzt, um elektronische Daten vor neugierigen<br />
Augen zu schützen. Aber die verwendeten Methoden hingen stark davon ab, ob die Daten<br />
auf ein Speichermedium geschrieben oder zwischen Computern übertragen wurden. Der<br />
Austausch elektronischer Daten in Echtzeit wird als Daten im Transit (engl. data in transit)<br />
bezeichnet. Es werden zahlreiche Technologien dafür eingesetzt, zum Beispiel IPsec und<br />
SSL/TLS. Daten, die auf eine Festplatte, CD-ROM, ein Flashlaufwerk oder irgendein anderes<br />
Medium geschrieben werden, werden als Daten in Ruhe (engl. data at rest) bezeichnet.<br />
Sollen Daten in Ruhe auf sichere Weise gespeichert werden, müssen auch die Datenströme<br />
verschlüsselt werden, ohne die Vorgänge so stark zu verzögern, dass die Benutzerfreundlichkeit<br />
leidet.<br />
BitLocker, EFS und sogar die Technologien zum Schutz von Daten im Transit helfen nicht<br />
weiter, wenn es darum geht, Daten gemeinsam mit anderen Leuten zu nutzen. Falls Sarah<br />
ein EFS-geschütztes Dokument gemeinsam mit John bearbeiten möchte, muss sie es erst<br />
entschlüsseln; sobald John das ungeschützte Dokument erhalten hat, kann er damit machen,<br />
was immer er will. An diesem Punkt kommen die Active Directory-Rechteverwaltungsdienste<br />
(Active Directory Rights Management Services, AD RMS) ins Spiel. Eines ihrer zentralen<br />
Features ist die Möglichkeit, Benutzern zu erlauben, gemeinsam an verschlüsselten Dokumenten<br />
zu arbeiten. Ein Benutzer wendet eine RMS-Richtlinie auf ein Dokument an. <strong>Die</strong><br />
Richtlinie legt fest, wer mit dem Dokument was machen kann. Anders ausgedrückt: Sie<br />
können Sarah Leseberechtigungen und John Lese-, Schreib- und Druckberechtigungen gewähren.<br />
Wenn Sarah ein Exemplar des Dokuments bekommt, kann sie daran keine Änderungen<br />
vornehmen. Falls sie es an eine andere Person weiterleitet, der keine Berechtigungen<br />
in der RMS-Richtlinie zugewiesen wurden, kann diese Person das Dokument nicht einmal<br />
ansehen. John kann dagegen Änderungen am Dokument vornehmen, bevor er es an Sie zurückgibt.<br />
<strong>Die</strong> Regeln in den RMS-Richtlinien können beliebig einfach oder komplex sein.<br />
<strong>Die</strong> meisten Organisationen legen eine Liste mit nur einer Handvoll von Richtlinien fest, die<br />
291
292 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
praktisch jede vorstellbare Geschäftssituation abdeckt. Und Benutzer wählen eine dieser<br />
Richtlinien aus der Liste aus, wenn sie entscheiden, wie sie ihre Dokumente schützen sollen.<br />
Was passiert mit Ihren Daten, wenn Sie sie anderen<br />
zur Verfügung stellen?<br />
Wenn Sie Ihre Daten freigeben, gehören sie nicht mehr Ihnen, Sie haben die Kontrolle<br />
darüber verloren. Das mag offensichtlich klingen, aber es passiert ständig, dass Leute Informationen,<br />
die geheim bleiben sollten, an andere Leute versenden, denen sie vertrauen,<br />
nur um dann feststellen zu müssen, dass einer der Empfänger das Geheimnis an andere<br />
Leute, Konkurrenten oder die Medien weitergegeben hat. Wenn ich Ihnen eine peinliche<br />
Geschichte über einen Vorfall in meiner Schulzeit erzähle, was soll ich dann tun, wenn<br />
Sie diese Geschichte in Ihrem Blog in die Welt hinausposaunen? Geschäftliche und politische<br />
Kommunikation enthält oft Informationen, von denen die beteiligten Organisationen<br />
erwarten, dass sie vertraulich bleiben. <strong>Die</strong> Konsequenzen von Indiskretionen können<br />
der Verlust von viel Geld, das Ende von Karrieren, die Vernichtung von Firmen und sogar<br />
der Verlust von Menschenleben sein, wenn es sich um diplomatische Informationen handelt.<br />
Einige der bekanntesten Indiskretionen betreffen Microsoft. Zum Beispiel war Brian<br />
Valentine, früher Senior Vice President für den Bereich <strong>Windows</strong>-Entwicklung, gar nicht<br />
erfreut, als sein vertrauliches Memo über die Strategie des Unternehmens im Konkurrenzkampf<br />
mit Open-Source-Softwareprojekten im Jahr 2001 an The Register weitergeleitet<br />
wurde. The Register veröffentlichte Zitate aus dem Memo, zum Beispiel »Linux ist die<br />
langfristige Bedrohung für unser Kerngeschäft. Vergessen Sie das nie!« und »Sie sollten<br />
Ihre potenziellen Kunden aus allen Richtungen bearbeiten, und falls Sie irgendwo Linux<br />
und/oder IBM entdecken, dann konzentrieren Sie sich nur darauf. Gönnen Sie Linux<br />
nicht einen einzigen Sieg.«<br />
Es hat viele weitere Vorfälle gegeben. Erinnern Sie sich noch an die berüchtigten Halloween-Dokumente<br />
aus dem Jahr 1998? Das war eine Reihe interner Memos, die Microsofts<br />
Sorgen bezüglich der Konkurrenz durch Open-Source-Softwareprojekte dokumentierten<br />
und Strategien zu ihrer Bekämpfung vorschlugen. Etwas aktuellere Fälle waren<br />
Dell Computer, Home Depot und Northern Rock, die es mit unerfreulichen Konsequenzen<br />
zu tun bekamen, weil vertrauliche Geschäftsdokumente öffentlich gemacht wurden.<br />
(Im Abschnitt »Weitere Informationen« am Ende dieses Kapitels finden Sie Verweise auf<br />
diese Vorfälle.)<br />
In den folgenden Abschnitten dieses Kapitels erfahren Sie, wie AD RMS Ihnen helfen kann,<br />
die Gefahr solcher Indiskretionen zu minimieren. Das Wort »minimieren« habe ich in dieser<br />
Formulierung mit Bedacht gewählt: Keine Technologie kann uneingeschränkt garantieren,<br />
dass die geschützten Daten niemals öffentlich werden. AD RMS ist ein Werkzeug für die<br />
Richtlinienerzwingung, das verhindern hilft, dass ehrliche Benutzer Fehler machen. Es ist<br />
aber keine <strong>Sicherheit</strong>slösung, die böswillige Insider, die die Berechtigung zum Anzeigen<br />
eines Dokuments haben, davon abhalten kann, die gelesenen Informationen an andere weiterzugeben.
Grundlagen von RMS 293<br />
Grundlagen von RMS<br />
AD RMS-<strong>Server</strong> arbeiten mit Active Directory-Domänencontrollern zusammen, um Benutzeridentitäten<br />
zu überprüfen, Verschlüsselungsschlüssel als Reaktion auf Benutzeranforderungen<br />
auszustellen, Entschlüsselungsschlüssel für jedes Dokument zu speichern und die<br />
Entschlüsselungsschlüssel weiterzuleiten, wenn Benutzer, die autorisiert sind, ein bestimmtes<br />
Dokument zu öffnen, dies anfordern. Vertrauenswürdige Benutzer können rechtegeschützte<br />
Dokumente mit RMS-fähigen Anwendungen erstellen. Nur andere vertrauenswürdige<br />
Benutzer, denen in der RMS-Richtlinie, die auf das Dokument angewendet wird, die<br />
entsprechenden Rechte zugewiesen wurden, können sich das Dokument ansehen oder etwas<br />
anderes mit seinem Inhalt tun. Der Prozess lässt sich folgendermaßen zusammenfassen:<br />
1. Jespers Clientcomputer wird mit RMS-Clientsoftware, Zertifikat, RMS-Richtlinien und<br />
RMS-fähigen Anwendungen hochgefahren.<br />
2. Jesper erstellt ein Dokument und wendet eine RMS-Richtlinie darauf an.<br />
3. Der RMS-Client stellt sicher, dass das Dokument noch nicht geschützt ist, nimmt Kontakt<br />
zum RMS-<strong>Server</strong> auf und fordert eine Veröffentlichungslizenz an.<br />
4. Der <strong>Server</strong> überprüft, ob Jesper Dokumente veröffentlichen darf, und sendet die Lizenz<br />
an den Client. <strong>Die</strong> Lizenz umfasst die Nutzungsrechte und -bedingungen für den Inhalt.<br />
5. Der RMS-fähige Client generiert symmetrische Schlüssel, mit denen er den Inhalt verschlüsselt.<br />
6. Jesper sendet das Dokument in einer E-Mail an Devon.<br />
7. Was passiert, wenn Devon versucht, den Inhalt zu öffnen, hängt davon ab, ob er die<br />
passende RMS-fähige Anwendung hat, ob er eine vertrauenswürdige Entität in derselben<br />
RMS-Infrastruktur wie Jesper ist und ob ihm in der RMS-Lizenz, die mit dem Dokument<br />
verknüpft ist, die Rechte zugewiesen wurden, das Dokument zu öffnen. Falls er<br />
nicht die richtige Anwendung hat, bleibt das Dokument verschlüsselt und somit unbenutzbar.<br />
Falls er die richtige Anwendung hat, aber keine entsprechenden Rechte besitzt<br />
oder kein Mitglied der Infrastruktur ist, weigert sich die Anwendung, Schlüssel anzufordern,<br />
mit denen das Dokument geöffnet werden kann.<br />
8. Falls alle Bedingungen erfüllt sind, kann Devon das Dokument öffnen.<br />
9. Sofern Devon alle Bedingungen erfüllt, fordert der RMS-Client eine Lizenz beim RMS-<br />
<strong>Server</strong> an. <strong>Die</strong> Lizenz enthält den Entschlüsselungsschlüssel für dieses Dokument.<br />
RMS gibt es zwar schon einige Jahre, aber AD RMS ist die erste Version, die in <strong>Windows</strong><br />
<strong>Server</strong> eingebaut ist. <strong>Die</strong> vielen neuen Features umfassen die Verwaltung über eine Microsoft<br />
Management Console (MMC), Integration mit Active Directory-Verbunddiensten (Active<br />
Directory Federation Services, AD FS), Selbstregistrierung von AD RMS-<strong>Server</strong>n und die<br />
Fähigkeit, administrative Rollen zu delegieren. Auch die Erstinstallation und Konfiguration<br />
der <strong>Server</strong>rolle Active Directory-Rechteverwaltungsdienste wurde deutlich verbessert.
294 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Abbildung 11.1 Ablauf der Rechteverwaltung<br />
Direkt von der Quelle: Verhindern der Datenweitergabe<br />
mit RMS und IRM<br />
Wenn Alice eine Datei erstellt und Bob Lese-/Schreibzugriff geben, Phil Lesezugriff gewähren<br />
und allen anderen den Lesezugriff verweigern will, ist dafür beim herkömmlichen<br />
Ansatz eine Menge Arbeit erforderlich, die von jemand anders als Alice erledigt werden<br />
muss. Alice muss beim Netzwerkadministrator betteln und drängeln, dass er eine Dateifreigabe<br />
anlegt, zwei <strong>Sicherheit</strong>sgruppen erstellt, Bob zur einen und Phil zur anderen hinzufügt<br />
und Zugriffssteuerungseinträge in der Zugriffssteuerungsliste der Freigabe definiert.<br />
Das ist eine Menge Arbeit für jemanden, dem die Probleme von Alice eigentlich völlig<br />
egal sind. Und das reicht noch nicht: Zwar kann Eve nicht auf die Datei in der Freigabe<br />
zugreifen, aber sie kann natürlich Phil beschwatzen, dass er ihr eine Kopie überlasst. Der<br />
Lesezugriff erlaubt auch das Kopieren. Falls Phil besonders böswillig ist, kann er seine<br />
lokale Kopie des Dokuments vorher noch manipulieren. Zugriffssteuerung über Netzwerkfreigaben<br />
funktioniert eben nur so lange, wie das geschützte Objekt innerhalb des<br />
Netzwerks bleibt. Sobald jemand die Datei öffnet, gibt es für die lokale Kopie im Speicher<br />
des Computers keinerlei Einschränkungen mehr.<br />
<strong>Die</strong> <strong>Windows</strong>-Rechteverwaltungsdienste und Microsoft Office-IRM (Information Rights<br />
Management) stellen Ihnen eine andere Form der Zugriffssteuerung zur Verfügung, die<br />
direkt in den Dokumenten implementiert ist, unabhängig davon, wo sie sich befinden.<br />
Wenn Alice Bob Lese-/Schreibzugriff gewährt und Phil reinen Lesezugriff, braucht sie<br />
sich dafür überhaupt nicht an den Netzwerkadministrator zu wenden. Der Zugriff, den Sie<br />
zuweist, wird direkt im Dokument gespeichert und von IRM erzwungen. Wenn Bob das<br />
Dokument öffnet, prüft Word zuerst die Berechtigungen von Bob und deaktiviert dann<br />
ausgewählte Funktionen, damit Bob mit dem Dokument nur die Dinge tun kann, die ihm
Grundlagen von RMS 295<br />
erlaubt wurden. Im Fall von Phil weigert sich Microsoft Office Word, ihn etwas anderes<br />
tun zu lassen, als sich den Inhalt im Fenster anzuschauen.<br />
Neben der Durchsetzung der Richtlinie mit IRM schützt RMS Dokumente dadurch, dass<br />
es sie verschlüsselt. RMS-geschützte Dokumente bleiben im Speicher und bei der Übertragung<br />
verschlüsselt. Sie werden erst entschlüsselt, wenn ein autorisierter Benutzer authentifiziert<br />
wurde und seine Berechtigungen erzwungen wurden. Falls jemand außerhalb<br />
der RMS-Domäne versucht, die Datei zu öffnen, bekommt er nur Unsinn angezeigt. Sofern<br />
Ihr Computer nicht in RMS eingetragen ist und Sie sich nicht auf der Liste der autorisierten<br />
Benutzer befinden, ist dieses Dokument nutzlos für Sie. Es ist auch für Bekannte<br />
nutzlos, denen Sie Kopien auf diesen allgegenwärtigen USB-Laufwerken zukommen lassen,<br />
die sich in Ihren Schreibtischschubladen tummeln.<br />
Steve Riley, Security Evangelist, Microsoft<br />
Erforderliche Clientkomponenten<br />
Der Clientcomputer benötigt RMS-Clientsoftware und RMS-fähige Anwendungen. Zum<br />
Beispiel stellen <strong>Windows</strong> Vista, Office 2007 und Office 2003 RMS-fähige Anwendungen<br />
zur Verfügung, etwa Microsoft Office Outlook, Word und Microsoft Internet Explorer 7.0.<br />
<strong>Windows</strong> Mobile 6.0 kann genutzt werden, um RMS-geschützte E-Mails zu erstellen sowie<br />
zu lesen und RMS-geschützte Office 2007-Dokumente zu lesen. Internet Explorer 6.0 kann<br />
RMS-fähig gemacht werden, indem Sie den RMS-Client für Internet Explorer installieren.<br />
Eine große Zahl von Microsoft-Partnern stellen weitere clientseitige Fähigkeiten für RMS<br />
zur Verfügung, zum Beispiel Unterstützung für andere Anwendungen und Plattformen.<br />
Erforderliche <strong>Server</strong>rollen<br />
Wie der Name andeutet, ist AD RMS mit Active Directory integriert. Daher setzt es Active<br />
Directory-Domänencontroller und DNS-<strong>Server</strong> (Domain Name System) voraus. AD RMS<br />
benötigt außerdem eine Datenbank, zum Beispiel Microsoft SQL <strong>Server</strong>, die auf demselben<br />
oder einem anderen <strong>Server</strong> laufen kann als dem, auf dem die anderen AD RMS-Komponenten<br />
bereitgestellt werden. <strong>Die</strong> AD RMS-<strong>Server</strong> selbst setzen voraus, dass eine Reihe von<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Komponenten aktiviert sind, zum Beispiel Message Queuing und<br />
Internetinformationsdienste mit ASP.NET. Falls diese Komponenten noch nicht installiert<br />
und aktiviert sind, übernimmt der <strong>Server</strong>rollenassistent das automatisch.<br />
Vorsicht <strong>Die</strong> interne <strong>Windows</strong>-Datenbank (früher als Microsoft SQL <strong>Server</strong> Desktop Engine oder MSDE<br />
bekannt) ist eine leistungsfähige, günstige Möglichkeit zum Entwickeln und Testen Ihrer RMS-Architektur.<br />
<strong>Die</strong> interne <strong>Windows</strong>-Datenbank mag auch wie eine pfiffige Methode aussehen, etwas Geld in Ihrer Produktivumgebung<br />
zu sparen, aber ihr fehlen einige Schlüsselfeatures für eine Unternehmensarchitektur, zum<br />
Beispiel die Fähigkeit, Verbindungen über das Netzwerk herzustellen und auf Berichtsdaten zuzugreifen.<br />
Für Ihre Produktivbereitstellung sollten Sie ein voll ausgestattetes Datenbankverwaltungssystem (Database<br />
Management System, DBMS) bereitstellen, zum Beispiel Microsoft SQL <strong>Server</strong>.
296 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Denkbare Architekturen<br />
Sofern es sich nicht um eine ganz kleine Bereitstellung handelt, sollten Sie ein gewisses<br />
Maß an Lastausgleich und Redundanz implementieren, wie in Abbildung 11.2 gezeigt. In<br />
großen Unternehmen ist es sinnvoll, Lizenzierungs- und Zertifizierungsaufgaben auf unterschiedliche<br />
<strong>Server</strong> zu verteilen, um die Leistung zu verbessern. <strong>Die</strong>se Architektur wird in<br />
Abbildung 11.3 gezeigt.<br />
Der Kontozertifizierungsdienst erstellt Rechtekontozertifikate. Jedes Zertifikat verknüpft ein<br />
Benutzerkonto mit einem bestimmten Computer. <strong>Die</strong>ses Benutzerkonto ermöglicht es einem<br />
Benutzer, RMS-geschützte Dokumente auf diesem Computer zu veröffentlichen oder zu benutzen.<br />
Der Kontozertifizierungsdienst kann nur auf dem RMS-Stammzertifizierungsserver<br />
oder -cluster laufen. Der Lizenzierungsdienst kann dagegen entweder auf dem Stammzertifizierungsserver<br />
beziehungsweise -cluster oder auf einem separaten <strong>Server</strong> beziehungsweise<br />
Cluster laufen. Der Lizenzierungsdienst stellt Lizenzen aus, die es Benutzern erlauben, RMSgeschützte<br />
Dokumente zu benutzen.<br />
Abbildung 11.2 Eine typische RMS-Bereitstellung
Abbildung 11.3 Eine robustere RMS-Bereitstellung<br />
Implementieren von AD RMS 297<br />
Implementieren von AD RMS<br />
Wie bei vielen IT-Projekten sind zwei sich überlappende Planungsprojekte nötig, um eine<br />
erfolgreiche Bereitstellung von AD RMS durchzuführen. Auf der <strong>technische</strong>n Seite müssen<br />
Sie die anfänglichen Anforderungen an Hard- und Software abschätzen, dabei aber auch eine<br />
möglichst flexible Architektur entwerfen, die künftiges Wachstum nicht behindert. Auf der<br />
geschäftlichen Seite müssen Sie Entscheidungen darüber treffen, wie Sie die RMS-Richtlinien<br />
so implementieren, dass sie am besten zu den Geschäftsanforderungen Ihrer Organisation<br />
passen. Falls dieses letzte Element bei AD RMS vernachlässigt wird, wird es für die<br />
Benutzer später mühsam, Rechteverwaltung auf ihre Dokumente anzuwenden. Und das<br />
Management wird sich dann schwer überzeugen lassen, dass die Investition gerechtfertigt
298 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
war. <strong>Die</strong>ses Buch konzentriert sich zwar auf die Technologie, aber es ist auch sehr wichtig,<br />
dass Sie Ihre RMS-Richtlinien so planen, dass sie einerseits kurzfristig von den Benutzern<br />
angenommen werden und andererseits langfristig nutzbar bleiben. Das bedeutet, dass die<br />
RMS-Richtlinien, die Sie implementieren, mindestens 90 Prozent der Anwendungsfälle<br />
abdecken, die Sie dokumentieren, während Sie das Projekt mit Unternehmensmanagern aus<br />
Ihrer gesamten Organisation durchsprechen. Es soll aber auch nicht darauf hinauslaufen,<br />
dass jeder Benutzer eine Liste mit Dutzenden von Richtlinien präsentiert bekommt, wenn er<br />
ein Dokument schützen will. Unter Umständen lässt sich eine Handvoll Richtlinien für alle<br />
Benutzer anwenden, und etwa ein halbes Dutzend weitere können für jede Abteilung oder<br />
Unternehmenseinheit entwickelt werden. Wenn Benutzer versuchen, RMS zu verwenden,<br />
bekommen sie das Popupmenü aus Abbildung 11.4 angezeigt. Je länger die Liste der RMS-<br />
Richtlinien, desto mehr Zeit müssen Benutzer damit verbringen herauszufinden, welche<br />
Richtlinie sie verwenden sollen. Offensichtlich sollten Sie auch jeder Richtlinie einen aussagekräftigen<br />
Namen geben, damit ihr Zweck für jeden Benutzer sofort erkennbar ist.<br />
Abbildung 11.04 Das RMS-Richtlinienmenü in Office Word 2007<br />
Eine vollständige Beschreibung, wie Sie RMS-Richtlinien entwickeln, die die Geschäftsanforderungen<br />
von Organisationen unterschiedlicher Größen und in unterschiedlichen Branchen<br />
erfüllen, würde den Rahmen dieses Kapitels sprengen. Microsoft hat viele Partner, die<br />
Organisationen bei der Planung und Bereitstellung von RMS zur Seite stehen. Einige finden<br />
Sie auf der <strong>Windows</strong> Rights Management Partners-Website unter http://www.microsoft.com/<br />
windowsserver2003/partners/rmspartners.mspx. Der Rest dieses Abschnitts konzentriert<br />
sich auf die <strong>technische</strong>n Aspekte bei der Bereitstellung von AD RMS. Sie werden dabei<br />
durch den Prozess zum Einrichten einer Laborumgebung für Testzwecke geleitet.
Implementieren von AD RMS 299<br />
Vorbereiten der Infrastruktur<br />
AD RMS erfordert eine Active Directory-Domäne mit der Domänenfunktionsebene <strong>Windows</strong><br />
<strong>Server</strong> 2003 oder höher, damit Sie universelle Active Directory-Gruppen verwenden<br />
können. Ich setze im Folgenden voraus, dass Sie bereits einen <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<strong>Server</strong><br />
haben, der Mitglied einer solchen Domäne ist, und konzentriere mich auf die AD RMSspezifischen<br />
Tätigkeiten. <strong>Die</strong> Benutzerkonten und Gruppen für die Tests sollten jeweils eine<br />
E-Mail-Adresse in ihr Active Directory-Objekt eingetragen haben. Sie müssen ein Domänenbenutzerkonto<br />
anlegen, um den RMS-<strong>Die</strong>nst auszuführen. Der Assistent "Rollen hinzufügen"<br />
weist darauf hin, dass das Domänenkonto ein Standarddomänenbenutzerkonto ohne<br />
zusätzliche Privilegien sein soll. Sobald Sie dieses Konto angelegt haben, können Sie den<br />
Assistenten "Rollen hinzufügen" starten und die Rolle Active Directory-Rechteverwaltungsdienste<br />
zu Ihrem Mitgliedserver hinzufügen. Weil dieses <strong>Die</strong>nstkonto Privilegien auf vielen<br />
Computern in Ihrer Active Directory-Domäne hat, sollten Sie ihm unbedingt ein sehr langes<br />
und komplexes Kennwort geben, um die Gefahr zu verringern, dass ein böswilliger Benutzer<br />
es kompromittiert.<br />
Vorsicht Der Assistent "Rollen hinzufügen" weist darauf hin, dass Ihr AD RMS-<strong>Die</strong>nstkonto ein Domänenbenutzerkonto<br />
ohne zusätzliche Privilegien sein soll. Unter Release Candidate 1 von <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong> habe ich allerdings festgestellt, dass ich das <strong>Die</strong>nstkonto zur Gruppe Domänen-Admins hinzufügen<br />
musste, um die Installation der Rolle Active Directory-Rechteverwaltungsdienste erfolgreich abschließen zu<br />
können. <strong>Die</strong>ses Verhalten kann sich in der endgültigen Version von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> geändert haben,<br />
daher sollten Sie diesen Punkt prüfen. (Anmerkung des Übersetzers: Ist immer noch wie unter RC1.)<br />
Abbildung 11.5 <strong>Die</strong> Seite <strong>Server</strong>rollen auswählen im Assistenten "Rollen hinzufügen"
300 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Bereitstellen des RMS-<strong>Server</strong>s<br />
Sie haben mehrere Möglichkeiten, den Assistenten "Rollen hinzufügen" zu starten. Zum<br />
Beispiel können Sie im <strong>Server</strong>-Manager mit der rechten Maustaste auf das Objekt Rollen im<br />
linken Fensterabschnitt klicken und im Kontextmenü den Befehl Rollen hinzufügen wählen.<br />
Auf der Seite <strong>Server</strong>rollen auswählen des Assistenten finden Sie den Eintrag für die Rolle<br />
Active Directory-Rechteverwaltungsdienste (Abbildung 11.5).<br />
Vorsicht In Abbildung 11.5 können Sie sehen, dass ich auf demselben Host auch Active Directory-<br />
Domänendienste und DNS-<strong>Server</strong> installiert habe. Das ist für eine einfache Testumgebung in Ordnung,<br />
aber bei einem umfangreichen Testprojekt sollten Sie dies nicht tun. Und in Ihrer Produktivbereitstellung<br />
sollten Sie diese <strong>Die</strong>nste auf gar keinen Fall auf denselben <strong>Server</strong>n betreiben, auf denen Sie die Rolle<br />
Active Directory-Rechteverwaltungsdienste installieren.<br />
Wenn Sie die <strong>Server</strong>rolle Active Directory-Rechteverwaltungsdienste installieren, werden<br />
auch die Internetinformationsdienste (Internet Information Services, IIS) 7.0, Message<br />
Queuing, <strong>Windows</strong>-Prozessaktivierungsdienst und interne <strong>Windows</strong>-Datenbank installiert.<br />
Wenn Sie die Rolle Active Directory-Rechteverwaltungsdienste aktivieren, zeigt der Assistent<br />
ein Dialogfeld an, in dem er darauf aufmerksam macht, dass IIS, <strong>Windows</strong>-Prozessaktivierungsdienst,<br />
Message Queuing und einige ihrer Unterkomponenten erforderlich sind<br />
(Abbildung 11.6). Klicken Sie auf Erforderliche Rollendienste hinzufügen.<br />
Abbildung 11.6 Das Dialogfeld weist darauf hin, dass zusätzliche Rollen<br />
für die AD RMS-Unterstützung benötigt werden<br />
<strong>Die</strong> Seite <strong>Server</strong>rollen auswählen zeigt nun, dass die Rollen Active Directory-Rechteverwaltungsdienste<br />
und Webserver (IIS) installiert werden (Abbildung 11.7). Klicken Sie auf<br />
Weiter.
Implementieren von AD RMS 301<br />
Abbildung 11.7 <strong>Die</strong> Seite <strong>Server</strong>rollen auswählen zeigt, welche Rollen installiert werden<br />
Abbildung 11.8 <strong>Die</strong> Seite Active Directory-Rechteverwaltungsdienste im Assistenten "Rollen hinzufügen"
302 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Nun öffnet sich die erste Seite im Assistenten "Rollen hinzufügen", die sich speziell auf<br />
AD RMS bezieht (Abbildung 11.8). Eine kurze Einführung in AD RMS wird angezeigt,<br />
darin finden Sie auch einige Links auf weitere Informationen. Klicken Sie auf Weiter.<br />
<strong>Die</strong> Seite Rollendienste auswählen wird angezeigt (Abbildung 11.9). Hier können Sie auswählen,<br />
ob Sie Ihre AD RMS-Bereitstellung in die Active Directory-Verbunddienste (Active<br />
Directory Federation Services, AD FS) integrieren. Für diese Testbereitstellung führen wir<br />
keine Integration mit AD FS durch, aber falls Ihre Benutzer AD RMS-geschützte Dokumente<br />
gemeinsam mit Benutzern in anderen Organisationen verwenden wollen, sollten Sie sich mit<br />
den Verbundfähigkeiten von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> vertraut machen. Klicken Sie auf Weiter.<br />
Abbildung 11.9 <strong>Die</strong> Seite Rollendienste auswählen<br />
<strong>Die</strong> Seite Erstellen eines AD RMS-Clusters oder Beitreten zu einem AD RMS-Cluster<br />
wird angezeigt. Weil wir den ersten AD RMS-<strong>Server</strong> installieren, müssen wir einen neuen<br />
AD RMS-Cluster erstellen. <strong>Die</strong>s ist die Standardoption, wie in Abbildung 11.10 zu sehen.<br />
Klicken Sie auf Weiter.<br />
<strong>Die</strong> Seite Auswählen der Konfigurationsdatenbank wird angezeigt (Abbildung 11.11). Weil<br />
wir ein System einrichten, das nur für Testzwecke genutzt wird, reicht die Standardoption<br />
Interne <strong>Windows</strong>-Datenbank auf diesem <strong>Server</strong> verwenden. Aber in einer Produktivumgebung<br />
sollten Sie einen separaten Datenbankserver konfigurieren und auf dieser Seite den <strong>Server</strong>namen<br />
und die Datenbankinstanz angeben, die AD RMS verwenden soll. Klicken Sie auf<br />
Weiter.
Implementieren von AD RMS 303<br />
Abbildung 11.10 <strong>Die</strong> Seite Erstellen eines AD RMS-Clusters oder Beitreten zu einem AD RMS-Cluster<br />
Abbildung 11.11 <strong>Die</strong> Seite Auswählen der Konfigurationsdatenbank
304 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Nun wird die Seite Angeben des <strong>Die</strong>nstkontos angezeigt (Abbildung 11.12). Hier definieren<br />
Sie, welches Domänenbenutzerkonto der AD RMS-<strong>Die</strong>nst verwendet. Klicken Sie auf<br />
Angeben, um das Konto auszuwählen. Daraufhin öffnet sich ein Dialogfeld, in dem Sie die<br />
Anmeldeinformationen des Kontos eingeben, das Sie vorher für AD RMS angelegt haben.<br />
Klicken Sie auf Weiter.<br />
Abbildung 11.12 <strong>Die</strong> Seite Angeben des <strong>Die</strong>nstkontos<br />
<strong>Die</strong> Seite Konfigurieren des AD RMS-Clusterschlüsselspeichers wird angezeigt (Abbildung<br />
11.13). <strong>Die</strong> Standardoption Zentral verwalteten AD RMS-Schlüsselspeicher verwenden<br />
eignet sich für unsere Testumgebung, aber auch für die meisten Produktivbereitstellungen.<br />
<strong>Die</strong> zweite Option, CSP-Schlüsselspeicher verwenden, ist eine erweiterte Möglichkeit, bei<br />
der Sie den Kryptografiedienstanbieter angeben und den Schlüssel von Hand verteilen müssen,<br />
wenn Sie neue <strong>Server</strong> zum Cluster hinzufügen. <strong>Die</strong>s ist eine sicherere Möglichkeit, sie<br />
erfordert aber mehr Arbeit. Klicken Sie auf Weiter.<br />
<strong>Die</strong> Seite Angeben des AD RMS-Clusterschlüsselkennworts wird angezeigt (Abbildung 11.14).<br />
Geben Sie ein starkes Kennwort in das Feld Kennwort und dann noch einmal in Kennwort<br />
bestätigen ein und klicken Sie auf Weiter. Vergessen Sie dieses Kennwort nicht!
Abbildung 11.13 <strong>Die</strong> Seite Konfigurieren des AD RMS-Clusterschlüsselspeichers<br />
Abbildung 11.14 <strong>Die</strong> Seite Angeben des AD RMS-Clusterschlüsselkennworts<br />
Implementieren von AD RMS 305
306 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Nun wird die Seite Auswählen der AD RMS-Clusterwebsite angezeigt (Abbildung 11.15).<br />
Geben Sie die Website an, auf der AD RMS installiert wird, und klicken Sie auf Weiter. In<br />
vielen Fällen reicht es, Standardwebsite auszuwählen. Sie können aber auch eine andere<br />
Website auswählen, falls Sie diese Site in der IIS-Konsole erstellt haben, bevor Sie den Assistenten<br />
"Rollen hinzufügen" gestartet haben. Natürlich müssen Sie in diesem Fall auch die<br />
Rolle Webserver (IIS) schon installiert haben, bevor Sie die Installation der Rolle Active<br />
Directory-Rechteverwaltungsdienste beginnen.<br />
Abbildung 11.15 <strong>Die</strong> Seite Auswählen der AD RMS-Clusterwebsite<br />
<strong>Die</strong> Seite Angeben der Clusteradresse Seite wird angezeigt (Abbildung 11.16). Es wird<br />
empfohlen, dass Sie eine SSL-verschlüsselte Verbindung verwenden, was auch die<br />
Standardeinstellung ist. Sie müssen den vollqualifizierten Domänennamen (FQDN) des<br />
AD RMS-Clusters eingeben. Weil dies der erste <strong>Server</strong> ist und wir lediglich eine einfache<br />
Testumgebung einrichten, können wir den FQDN des <strong>Server</strong>s selbst verwenden. Falls Sie<br />
noch kein <strong>Server</strong>zertifikat installiert haben, bietet der Assistent Ihnen an, ein selbstsigniertes<br />
zu erstellen. Das ist für Testzwecke in Ordnung, aber für Ihre Produktivumgebung sollte Sie<br />
ein Zertifikat von einer Zertifizierungsstelle installieren, der alle Hosts in Ihrer Active Directory-Gesamtstruktur<br />
vertrauen. Klicken Sie auf Weiter.<br />
Sie müssten jetzt die Seite Benennen des <strong>Server</strong>-Lizenzgeberzertifikats angezeigt bekommen<br />
(Abbildung 11.17). <strong>Die</strong>s ist der Name des AD RMS-Clusters, den Benutzer zu sehen bekommen.<br />
Normalerweise ist dies derselbe Name wie der Hostname, den Sie auf der vorherigen<br />
Seite angegeben haben, in diesem Beispiel der erste Teil des FQDN: SERVER41. Klicken<br />
Sie auf Weiter.
Abbildung 11.16 <strong>Die</strong> Seite Angeben der Clusteradresse<br />
Abbildung 11.17 <strong>Die</strong> Seite Benennen des <strong>Server</strong>-Lizenzgeberzertifikats<br />
Implementieren von AD RMS 307
308 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Abbildung 11.18 <strong>Die</strong> Seite Registrieren des AD RMS-<strong>Die</strong>nstverbindungspunkts<br />
Abbildung 11.19 <strong>Die</strong> Seite Installationsauswahl bestätigen
Implementieren von AD RMS 309<br />
<strong>Die</strong> Seite Registrieren des AD RMS-<strong>Die</strong>nstverbindungspunkts wird angezeigt (Abbildung<br />
11.18). In den meisten Fällen sollten Sie hier den Verbindungspunkt registrieren,<br />
was auch die Standardoption ist. Klicken Sie auf Weiter.<br />
Beim Abschluss der Installation wird die Seite Installationsauswahl bestätigen angezeigt<br />
(Abbildung 11.19). <strong>Die</strong>se Seite fasst alle Einstellungen zusammen, die Sie im Assistenten<br />
ausgewählt haben. Klicken Sie auf Weiter.<br />
<strong>Die</strong> Seite Installationsstatus wird angezeigt, während die Installation durchgeführt wird.<br />
Sobald die Installation abgeschlossen ist, erscheint die Seite Installationsergebnisse (Abbildung<br />
11.20). Beachten Sie, dass die AD RMS-Installation zwar erfolgreich war, aber dass<br />
Sie sich ab- und wieder anmelden müssen, damit Sie AD RMS auf diesem Host verwalten<br />
können. Der Grund dafür ist, dass Sie das <strong>Sicherheit</strong>stoken Ihres Kontos aktualisieren<br />
müssen, weil der Assistent das Konto zur Gruppe AD RMS-Organisationsadministratoren<br />
hinzugefügt hat.<br />
Abbildung 11.20 <strong>Die</strong> Seite Installationsergebnisse<br />
Erstellen von RMS-Richtlinienvorlagen<br />
Sie können nun beginnen, AD RMS von einem Clientcomputer aus zu testen, den Sie zur<br />
selben Domäne hinzufügen. Dafür können Sie eine RMS-fähige Anwendung verwenden,<br />
zum Beispiel Office Word 2007. Sie können aber auch RMS-Richtlinienvorlagen erstellen<br />
und testen. Um die Administration der Vorlagen zu erleichtern, können Sie sie an einem<br />
zentralen Speicherort ablegen, sodass sie von dort auf die AD RMS-Clients kopiert werden<br />
können. <strong>Die</strong> meisten Organisationen verwenden eine automatisierte Verteilungsmethode,<br />
zum Beispiel Systems Management <strong>Server</strong> oder Gruppenrichtlinien. Sie können die Vorla-
310 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
gen aber auch verfügbar machen, indem Sie sie in eine Netzwerkfreigabe legen, auf die alle<br />
Clients zugreifen können. Das funktioniert für Clients, die an das interne Netzwerk angeschlossen<br />
sind, aber nicht für Clients, die im Remotezugriff arbeiten. Sie können die Vorlagen<br />
auch von Hand verteilen, indem Sie sie auf die AD RMS-Clients kopieren.<br />
Gehen Sie folgendermaßen vor, um eine neue AD RMS-Richtlinienvorlage zu erstellen:<br />
1. Öffnen Sie die Konsole Active Directory-Rechteverwaltungsdienste. Klicken Sie dazu<br />
im Startmenü auf Verwaltung und dann auf Active Directory-Rechteverwaltungsdienste.<br />
2. Falls die Konsole Active Directory-Rechteverwaltungsdienste nicht automatisch eine<br />
Verbindung zum AD RMS-<strong>Die</strong>nst herstellt, müssen Sie sie dorthin umleiten, indem Sie<br />
auf LocalHost klicken.<br />
3. Falls Sie ein selbstsigniertes Zertifikat für Ihren RMS-Cluster verwenden, wird unter Umständen<br />
eine <strong>Sicherheit</strong>swarnung angezeigt (Abbildung 11.21). Klicken Sie darin auf Ja.<br />
Abbildung 11.21 <strong>Die</strong> <strong>Sicherheit</strong>swarnung wegen des selbstsignierten Zertifikats<br />
4. Klicken Sie im Bereich Aufgaben des mittleren Fensterabschnitts auf Vorlagen für<br />
Benutzerrechterichtlinien verwalten (Abbildung 11.22).<br />
Abbildung 11.22 <strong>Die</strong> Verwaltungskonsole Active Directory-Rechteverwaltungsdienste
Integration mit Microsoft Office 311<br />
5. Klicken Sie im Fensterabschnitt Aktionen auf Eigenschaften, um den Export der AD RMS-<br />
Benutzerrechterichtlinienvorlagen zu ermöglichen.<br />
6. Aktivieren Sie das Kontrollkästchen Export aktivieren, geben Sie den UNC-Pfad für den<br />
Ordner, in dem die Richtlinienvorlagen gespeichert werden sollen, in das Feld Geben Sie<br />
den Vorlagenspeicherort an (UNC) ein und klicken Sie auf OK. Beachten Sie, dass das<br />
AD RMS-<strong>Die</strong>nstkonto Schreibberechtigungen für den Ordner und die Netzwerkfreigabe<br />
haben muss.<br />
7. Klicken Sie im Fensterabschnitt Aktionen auf Verteilte Vorlage für Benutzerrechterichtlinie<br />
erstellen, um den Assistenten Verteilte Vorlage für Benutzerrechterichtlinie erstellen<br />
zu starten.<br />
8. Klicken Sie auf Hinzufügen.<br />
9. Wählen Sie in der Dropdownliste Sprache die gewünschte Sprache für die Benutzerrechterichtlinienvorlage.<br />
10. Geben Sie im Feld Name einen Namen für die Richtlinienvorlage ein.<br />
11. Geben Sie im Feld Beschreibung eine aussagekräftige Beschreibung der Richtlinienvorlage<br />
ein und klicken Sie auf Hinzufügen.<br />
12. Klicken Sie auf Weiter.<br />
13. Klicken Sie auf Hinzufügen, geben Sie die Namen der Benutzer, die diese Vorlage verwenden<br />
dürfen, im Feld E-Mail-Adresse eines Benutzers oder einer Gruppe ein und<br />
klicken Sie auf OK.<br />
14. Aktivieren Sie das Kontrollkästchen Ansicht, um der Gruppe Lesezugriff auf alle Dokumente<br />
zu gewähren, die mithilfe dieser AD RMS-Benutzerrechterichtlinienvorlage<br />
erstellt wurden.<br />
15. Klicken Sie auf Fertig stellen.<br />
Das ist auch schon alles, was Sie tun müssen, um eine benutzerdefinierte Richtlinienvorlage<br />
mit AD RMS zu erstellen!<br />
Integration mit Microsoft Office<br />
Verschiedene Endbenutzeranwendungen von Microsoft sind RMS-fähig. <strong>Die</strong> Office 2003-<br />
Suite bietet Unterstützung in Office Outlook, Office Word, Office PowerPoint und Office<br />
Excel. In Office 2007 ist zusätzlich Office Infopath 2007 RMS-fähig. Aus Sicht des Benutzers<br />
ist es ganz einfach, RMS einzusetzen. Der Benutzer wählt lediglich die gewünschte<br />
Richtlinie aus dem Menü aus, das sich öffnet, wenn er im Untermenü Dokument für die<br />
Verteilung vorbereiten den Eintrag Berechtigung einschränken wählt (siehe Abbildung 11.4<br />
weiter oben).<br />
Außerdem ist Microsoft Office SharePoint <strong>Server</strong> 2007 mit AD RMS integriert, sodass folgende<br />
Features zur Verfügung stehen:<br />
Geschützte Dokumentbibliotheken, sodass AD RMS-Richtlinien auf alle Dokumente<br />
in der Bibliothek angewendet werden<br />
Schützen von Dokumenten beim Download<br />
Geschützte Dokumente, die trotzdem auf dem <strong>Server</strong> durchsucht werden können<br />
Standardmäßige Unterstützung für die unterschiedlichen Dateiformate, zum Beispiel<br />
Office Word, Office Excel, Office PowerPoint, Office Infopath und XPS
312 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Viele Microsoft-Partner haben RMS-fähige Plug-Ins für andere Anwendungen erstellt. Einige<br />
haben auch neue Funktionen hinzugefügt, zum Beispiel die Fähigkeit, Daten aus einem<br />
geschützten Dokument zu kopieren, sodass die Daten ihre Berechtigungen aus dem ursprünglichen<br />
Dokument beibehalten, wenn sie in ein anderes Dokument eingefügt werden.<br />
Es können also nur autorisierte Benutzer diesen geschützten Abschnitt des neuen Dokuments<br />
ansehen. Partner stellen auch Tools mit erweiterten Verwaltungsfähigkeiten zur Verfügung.<br />
Weitere Informationen über diese Fremdhersteller finden Sie auf der <strong>Windows</strong><br />
Rights Management Partners-Website unter http://www.microsoft.com/windowsserver2003/<br />
partners/rmspartners.mspx.<br />
Einsetzen von RMS, um bestimmte Anforderungen<br />
zu erfüllen<br />
Digitale Daten sind überall. Sogar bei Leuten, die gar keine Computer benutzen, sind viele<br />
oder gar alle ihrer Personendaten in digitalem Format auf Computern gespeichert, die ihrer<br />
Regierung gehören, und auch bei Unternehmen, mit denen sie zu tun haben. Während schon<br />
länger Hacker in Computer eindringen, fällt in den letzten Jahren auf, dass es immer mehr<br />
Angriffe durch Kriminelle gibt, die sich finanzielle Vorteile davon versprechen. <strong>Die</strong>se Datendiebe<br />
missbrauchen Personendaten für Identitätsdiebstahl und andere Unternehmensdaten<br />
für Erpressung, <strong>Die</strong>bstahl von geistigem Eigentum und viele andere Verbrechen aller Art.<br />
Nationale, Länder- und kommunale Regierungen haben im Lauf der letzten Jahre zahlreiche<br />
Datenschutzgesetze verabschiedet.<br />
Gesetze mit Auswirkungen darauf, wie Organisationen<br />
Aufzeichnungen archivieren<br />
Gesetze zum Schutz von Daten sind vor allem in den USA, Kanada und Europa sehr umfassend.<br />
Viele andere Länder stellen eigene gesetzliche Anforderungen, wie Computer und die<br />
darauf gespeicherten Daten geschützt werden müssen. Sogar in Ländern, wo es keine derartigen<br />
Gesetze gibt, müssen Organisationen, die international tätig sind, die gesetzlichen<br />
Anforderungen aller Länder erfüllen, in denen sie Geschäfte abwickeln. Einige der wichtigsten<br />
US-amerikanischen Gesetze werden in den folgenden Abschnitten kurz vorgestellt.<br />
USA<br />
Der Sarbanes-Oxley Act aus dem Jahr 2002 (SOX) wurde vom US-Kongress verabschiedet,<br />
nachdem eine Reihe von Unternehmensskandalen viel öffentliche Aufmerksamkeit bekamen,<br />
bei denen Aktionäre, Steuerzahler und Angestellte der betreffenden Firmen Milliarden<br />
von Dollar verloren. <strong>Die</strong>ses Gesetzespaket macht die Zuständigen von öffentlichen Firmen<br />
persönlich für Falschdarstellungen im Bereich finanzieller Daten haftbar. Als Reaktion auf<br />
SOX suchen Organisationen nach Lösungen, die unautorisierten Zugriff auf Dokumente verhindern<br />
und verfolgen, wer Aufzeichnungen ansieht und ändert.<br />
Der USA Patriot Act hat eine Vielzahl von Auswirkungen. Abschnitt 311 versucht, die Geldwäsche<br />
zu einzuschränken, indem er definiert, wie Banken und andere Finanzinstitute Aufzeichnungen<br />
vorhalten müssen, insbesondere für internationale Transaktionen. <strong>Die</strong>se Organisationen<br />
brauchen ein sicheres System zum Archivieren der Daten, aber die Daten müssen<br />
auch für den Zugriff durch autorisierte Benutzer zur Verfügung stehen, falls die Regierung<br />
sie später einer Überprüfung unterziehen will.
Einsetzen von RMS, um bestimmte Anforderungen zu erfüllen 313<br />
Der Privacy Act aus dem Jahr 1974 verpflichtet Regierungseinrichtungen, Datensätze zu<br />
schützen, die Personendaten enthalten. Allerdings gibt der Freedom of Informationen Act<br />
(FOIA) Personen das Recht, ihre Daten zu prüfen. Daher suchen Regierungseinrichtungen<br />
nach Möglichkeiten, Daten vor unautorisiertem Zugriff zu schützen, ohne dabei jedoch die<br />
gesetzlichen Verpflichtungen zu behindern. Der Financial Modernization Act aus dem Jahr<br />
1999 (auch als Gramm-Leach-Bliley Act bekannt) und der Health Insurance Portability and<br />
Accountability Act (HIPAA) aus dem Jahr 1996 schreiben kommerziellen und Regierungseinrichtungen<br />
den Schutz von Finanz- beziehungsweise Gesundheitsdaten vor. <strong>Die</strong>se Gesetze<br />
haben Auswirkungen darauf, wie Banken, Krankenhäuser, Ärzte und andere Beteiligte die<br />
Datensätze ihrer Kunden verwalten. Auf den ersten Blick fordert HIPAA genau das Gegenteil,<br />
weil dieses Gesetzespaket versucht, einerseits den Schutz der Daten zu verbessern,<br />
dabei aber auch Organisationen vorschreibt, die Daten von Patienten einfacher als Organisationen<br />
weiterzugeben, die vom Patienten dazu autorisiert wurden.<br />
Der Federal Information Security Management Act (FISMA) betrifft nicht nur alle Regierungseinrichtungen,<br />
sondern auch viele Organisationen, die mit ihnen in Geschäftsbeziehungen<br />
stehen. FISMA deckt einen weiten Bereich der Computersicherheit ab, wobei ein Teil<br />
davon Anforderungen für den Schutz vertraulicher Daten gegen unautorisierten Zugriff<br />
definiert.<br />
Gesetze in einzelnen US-Staaten<br />
Viele Staaten in den USA haben Gesetze verabschiedet, die Organisationen, die mit ihren<br />
Bürgern Geschäftsbeziehungen unterhalten, vorschreiben, Schutzmaßnahmen gegen den<br />
<strong>Die</strong>bstahl persönlicher Daten zu implementieren. <strong>Die</strong>se Vorschriften gehen teils über das<br />
hinaus, was die Bundesgesetze vorschreiben. Kalifornien ist führend in diesem Bereich.<br />
Zum Beispiel schreiben SB 1386 und Civil Code Section 1798.81.5 Unternehmen vor, die<br />
<strong>Sicherheit</strong> der persönlichen Daten kalifornischer Bürger sicherzustellen, zum Beispiel<br />
Sozialversicherungsnummern und Führerscheindaten.<br />
Andere Länder<br />
Viele Länder in Europa, dem Nahen Osten und Asien haben irgendwelche Gesetze zum<br />
Schutz von Daten verabschiedet. <strong>Die</strong>se Gesetze schreiben normalerweise den Schutz von<br />
Personendaten ihrer Bürger vor, unabhängig davon, wo und wie sie aufgezeichnet wurden.<br />
Konsequenzen, wenn die Anforderungen nicht erfüllt werden<br />
Viele bekannte Datenlecks wurden von der Presse ausführlich breitgetreten. Zum Beispiel<br />
wurden fünf der größten Investmentbanker der Welt zu einer Strafe von 8.000.000 US-<br />
Dollar verurteilt, weil sie E-Mails nicht wie im Securities Exchange Act gefordert archiviert<br />
hatten. Ein anderer jüngerer Fall könnte für einen kalifornischen Anbieter von Gesundheitsdienstleistungen<br />
eine Strafe von 250.000 US-Dollar und 10 Jahre Gefängnis bedeuten, weil<br />
er die HIPAA-Anforderungen nicht erfüllt hat. Neben der Gefahr von Gefängnis- und hohen<br />
Geldstrafen setzen Organisationen, die Daten über ihre Angestellten, Partner und Kunden<br />
nicht richtig schützen, auch ihre Umsätze und Börsenkurse einem hohen Risiko aus, wenn<br />
sich bei einem Vorfall die öffentliche Meinung gegen das Unternehmen richtet.
314 Kapitel 11: Implementieren der Active Directory-Rechteverwaltungsdienste<br />
Wie AD RMS helfen kann<br />
Organisationen mit E-Mail-Archiven und Dokumentspeichern können von den Fähigkeiten<br />
von AD RMS profitieren. Sie können AD RMS-Richtlinien implementieren, die den Zugriff<br />
auf Dokumente auf autorisierte Benutzer beschränken, aber gleichzeitig sicherstellen, dass<br />
ein Administrator oder ein anderer Verantwortlicher Jahre später ein Dokument abrufen<br />
kann, das für einen Kunden oder eine Regierungseinrichtung benötigt wird. Zum Beispiel<br />
schreibt SOX vor, dass öffentliche Firmen E-Mail-Nachrichten archivieren müssen, und<br />
zwar auch Nachrichten, die unter Umständen vertrauliche Daten enthalten. Organisationen<br />
können solche E-Mail-Archive mithilfe von AD RMS schützen und so verhindern, dass<br />
Daten versehentlich oder absichtlich öffentlich gemacht werden, aber gleichzeitig sicherstellen,<br />
dass die Nachrichten bei Bedarf abgerufen werden können.<br />
Einschränkungen von AD RMS<br />
AD RMS und andere Rechteverwaltungslösungen für den Unternehmensbereich können<br />
verhindern, dass Benutzer die geschützten Dateien weitergeben. Aber ein entschlossener<br />
Krimineller, der in der Lage ist, das Dokument zu lesen, weil er in den angewendeten RMS-<br />
Richtlinien die entsprechende Berechtigung hat, kann eine Vielzahl digitaler Angriffe durchführen.<br />
Er kann den Computermonitor abfotografieren, während er das Dokument durchblättert,<br />
er kann das Dokument einem Komplizen am Telefon vorlesen oder er kann es in eine<br />
andere Datei abtippen; wenn er ein gutes Gedächtnis hat, kann er den Inhalt möglicherweise<br />
lange, nachdem er das Dokument gelesen hat, auswendig heruntersagen. Auch digitale Angriffe<br />
sind möglich. Falls der Benutzer beliebige Anwendungen ausführen darf, könnte er<br />
einen Debugger starten und Textseiten aus dem RAM-Abschnitt kopieren, in dem das Dokument<br />
für die Anzeige in Office Word oder der verwendeten Anwendung gespeichert wird.<br />
Sie können diesen Angriff abwehren, indem Sie Richtlinien für Softwareeinschränkung<br />
definieren, die Benutzer daran hindern, unautorisierte Anwendungen wie zum Beispiel<br />
Debugger auszuführen. Aber ich will Ihnen hier vor allem klarmachen, wo AD RMS an<br />
seine Grenzen stößt, wenn Sie die Bereitstellung in Ihrer Organisation planen.<br />
Zusammenfassung<br />
<strong>Die</strong>ses Kapitel begann mit einem kurzen Überblick über Datenverschlüsselung und die<br />
Technologietypen, die sich für verschiedene Situationen am besten eignen. Dann haben wir<br />
uns die Active Directory-Rechteverwaltungsdienste angesehen, ihre Fähigkeiten, die grundlegende<br />
Architektur, Anforderungen und eine Testbereitstellung. Schließlich haben Sie einen<br />
kurzen Überblick erhalten, welche RMS-fähigen Anwendungen Microsoft zur Verfügung<br />
stellt. AD RMS unterscheidet sich von anderen Dateiverschlüsselungstechnologien dadurch,<br />
dass eines der zentralen Entwurfsziele darin bestand, die Zusammenarbeit möglichst nahtlos<br />
zu machen. AD RMS hat gegenüber anderen Rechteverwaltungslösungen für den Unternehmensbereich<br />
den Vorteil, dass es eng in Microsoft Office und Microsoft SharePoint <strong>Server</strong><br />
integriert ist und von einer Vielzahl von Microsoft-Partnern unterstützt wird, die leistungsfähige<br />
Lösungen auf Basis dieser Technologieplattform anbieten.
Weitere Informationen<br />
Weitere Informationen 315<br />
CNet Networks (2007): »Leaked memo exposes Dell’s plans« unter http://www.zdnet.<br />
com.au/news/business/soa/Leaked-memo-exposes-Dell-s-plans/0,139023166,339275194-<br />
2,00.htm.<br />
HuffingtonPost.com (2007): »Leaked Memos Turn Orange Home Depot Bright Red«<br />
unter http://www.huffingtonpost.com/al-norman/leaked-memos-turn-orange-_b_<br />
58467.html.<br />
Microsoft Corporation (2006): »AES-CBC + Elephant difuser: A Disk Encryption Algorithm<br />
for <strong>Windows</strong> Vista« unter http://www.microsoft.com/downloads/details.aspx<br />
?familyid=131dae03-39ae-48be-a8d6-8b0034c92555&displaylang=en.<br />
Microsoft Corporation (2007): »Keys to Protecting Data with BitLocker Drive Encryption«<br />
unter http://www.microsoft.com/technet/technetmag/issues/2007/06/BitLocker/<br />
default.aspx.<br />
Microsoft Corporation (2007): »Active Directory Rights Management Services« unter<br />
http://technet2.microsoft.com/windowsserver<strong>2008</strong>/en/servermanager/activedirectory<br />
rightsmanagementservices.mspx.<br />
Microsoft Corporation (2007): »Active Directory Rights Management Services Overview«<br />
unter http://technet2.microsoft.com/windowsserver<strong>2008</strong>/en/library/74272acc-<br />
0f2d-4dc2-876f-15b156a0b4e01033.mspx.<br />
Microsoft Corporation (2007): »<strong>Windows</strong> Rights Management Services« unter<br />
http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx.<br />
The Register (2001-2007): »MS promotes Linux from threat to ›the‹ threat <strong>–</strong> Memo«<br />
unter http://www.theregister.co.uk/2001/11/12/ms_promotes_linux_from_threat.<br />
Scotsman.com (2007): »Leaked memo ›could ruin Northern takeover‹« unter<br />
http://edinburghnews.scotsman.com/business.cfm?id=1803412007.
T E I L I I I<br />
<strong>Sicherheit</strong>sszenarien<br />
In diesem Teil:<br />
Kapitel 12: Schützen von <strong>Server</strong>rollen ..................................... 319<br />
Kapitel 13: Patchverwaltung ............................................ 349<br />
Kapitel 14: Schützen des Netzwerks . ...................................... 377<br />
Kapitel 15: Schützen von Zweigstellen ..................................... 405<br />
Kapitel 16: Aspekte für kleine Unternehmen ................................. 429<br />
Kapitel 17: Schützen von <strong>Server</strong>anwendungen ............................... 471
K A P I T E L 1 2<br />
Schützen von <strong>Server</strong>rollen<br />
Von Jesper M. Johansson<br />
In diesem Kapitel:<br />
Rollen und Features ................................................. 320<br />
Ihr <strong>Server</strong> vor der Installation von Rollen . ................................... 328<br />
<strong>Server</strong> Core ....................................................... 328<br />
Tools zum Verwalten von <strong>Server</strong>rollen ..................................... 333<br />
Der <strong>Sicherheit</strong>skonfigurations-Assistent .................................... 336<br />
<strong>Server</strong> mit mehreren Rollen ............................................ 346<br />
Zusammenfassung .................................................. 346<br />
Es sollte recht offensichtlich sein, dass jeder <strong>Server</strong> irgendeine Rolle wahrnimmt. Manche<br />
sind Webserver, manche Dateiserver, andere Domänencontroller (Domain Controller, DC)<br />
oder Infrastrukturserver, zum Beispiel DNS (Domain Name System) und DHCP (Dynamic<br />
Host Configuration Protocol). Und natürlich gibt es den DC/Dateiserver/Webserver/Anwendungsserver/Firewall/DHCP/DNS-<strong>Server</strong>,<br />
in kleinen Unternehmen auch als »der <strong>Server</strong>«<br />
bekannt. (Mehr zu diesem Thema finden Sie in Kapitel 16, »Aspekte für kleine Unternehmen«.)<br />
Aber keiner davon tut irgendetwas, bevor Sie nicht eine oder mehrere Rollen darauf<br />
bereitstellen.<br />
Weil jeder <strong>Server</strong> anders ist, ist klar, dass sich eine Einheitskonfiguration nicht für jeden<br />
<strong>Server</strong> eignet. Das wird relativ offensichtlich, wenn Sie sich überlegen, dass jede Rolle erfordert,<br />
dass auf dem <strong>Server</strong> bestimmte Software installiert und Einstellungen vorgenommen<br />
werden müssen. Sobald Sie neue Software auf einem <strong>Server</strong> installieren, verändern Sie, wie<br />
der <strong>Server</strong> arbeitet. Und das bedeutet, dass Sie erneut analysieren müssen, wie dieser <strong>Server</strong><br />
geschützt wird. <strong>Die</strong>s wird ausführlich in Kapitel 14, »Schützen des Netzwerks«, beschrieben.<br />
Trotz der offensichtlichen Tatsache, dass <strong>Server</strong> entsprechend ihren Rollen geschützt werden<br />
müssen, gibt es Tools und Dokumentation, die das wirklich unterstützen, erst seit relativ kurzer<br />
Zeit. Das erste Tool, das explizit für diese Aufgabe entwickelt wurde, war der <strong>Sicherheit</strong>skonfigurations-Assistent<br />
(Security Configuration Wizard, SCW), der erstmals im Jahr<br />
2005 für <strong>Windows</strong> <strong>Server</strong> 2003 Service Pack 1 zur Verfügung gestellt wurde. In diesem<br />
Kapitel beschreibe ich das Konzept der rollenbasierten <strong>Sicherheit</strong>, die Tools, mit denen Sie<br />
<strong>Server</strong>rollen in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> verwalten, und den ultimativen rollenbasierten <strong>Server</strong>:<br />
<strong>Server</strong> Core. Bevor wir damit beginnen, brauchen wir aber erst einmal Klarheit über die<br />
Terminologie.<br />
319
320 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Rollen und Features<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wird völlig über Rollen verwaltet. Das Konzept, viele separate Komponenten<br />
zu installieren, wie es in älteren <strong>Server</strong>betriebssystemen üblich war, ist ganz verschwunden.<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> entscheiden Sie, welche Rolle Ihr <strong>Server</strong> übernehmen<br />
soll, und das Tool <strong>Server</strong>-Manager stellt die dafür erforderliche Software bereit.<br />
Microsoft unterscheidet zwischen Rollen (engl. role) und Features (engl. feature). Eine Rolle<br />
ist eine Sammlung von Software, die es in ihrer Kombination dem <strong>Server</strong> ermöglicht, irgendeinen<br />
<strong>Die</strong>nst im Netzwerk zur Verfügung zu stellen. Im Allgemeinen ist eine Rolle das,<br />
wofür Sie den <strong>Server</strong> gekauft haben. Ein Beispiel für eine Rolle ist »Domänencontroller«<br />
oder »Anwendungsserver« (zum Beispiel ein Webserver mit Anwendungsframeworks). Oft<br />
kann eine Rolle in einem einzigen Schritt installiert werden, erfordert aber eine Menge Konfiguration,<br />
bis sie so arbeitet, wie Sie sich das vorstellen. Zum Beispiel können Sie einen<br />
<strong>Server</strong> ganz einfach zu einem Domänencontroller hochstufen, aber bis Sie Benutzer- und<br />
Computerkonten hinzufügen, nützt Ihnen der DC nicht besonders viel.<br />
Features sind dagegen einfacher. <strong>Die</strong>s sind Dinge, die viele <strong>Server</strong> brauchen und für deren<br />
Vorhandensein es gute Gründe gibt, die Sie aber nicht als wichtige Gründe für den Kauf des<br />
<strong>Server</strong>s einstufen. Sie beschreiben den <strong>Server</strong> nicht so, wie Rollen das tun. In manchen Fällen<br />
haben Features gar nichts mit <strong>Die</strong>nsten zu tun. Ein Beispiel ist das Feature Verbindungs-<br />
Manager-Verwaltungskit, das lediglich ein Tool ist. Andere Features sind mit <strong>Die</strong>nsten verknüpft.<br />
In vielen Fällen ist ein Feature einfach eine Möglichkeit, einem Administrator die<br />
Installation eines <strong>Die</strong>nstes zugänglich zu machen. Viele der Dinge, die Sie in der <strong>Windows</strong><br />
Vista-Systemsteuerung unter Programme und Funktionen angezeigt bekommen, werden in<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> als Features aufgelistet. In manchen Fällen ist die Grenze zwischen<br />
Rollen und Features recht fließend. Zum Beispiel sind DHCP (Dynamic Host Configuration<br />
Protocol) und DNS (Domain Name System) Rollen, aber WINS (<strong>Windows</strong> Internet Name<br />
Service) ist ein Feature. WINS verwaltet über DHCP zugewiesene IP-Adressen (Internet<br />
Protocol) und stellt für alte <strong>Windows</strong>-Netzwerke genau dieselben <strong>Die</strong>nste zur Verfügung, die<br />
DNS für aktuelle Netzwerke anbietet. Wenn Sie sich die Features ansehen, stoßen Sie auf<br />
einige optionale Komponenten, die als veraltet gekennzeichnet sind. Sie können nur noch als<br />
Features installiert werden.<br />
Einige Rollen benötigen bestimmte Features, um zu funktionieren. Zum Beispiel braucht die<br />
Rolle Active Directory-Rechteverwaltungsdienste (Active Directory Rights Management<br />
Services, AD RMS) das Feature Interne <strong>Windows</strong>-Datenbank (Microsoft SQL <strong>Server</strong> 2005<br />
Embedded Edition). Und einige Features benötigen andere Features, zum Beispiel der <strong>Windows</strong>-Systemressourcen-Manager<br />
(<strong>Windows</strong> System Resource Manager, WSRM), der ebenfalls<br />
die interne <strong>Windows</strong>-Datenbank braucht.<br />
In vielen Fällen sind die Verbindungen zwischen Features und Rollen recht verwickelt. Betrachten<br />
Sie zum Beispiel einen Anwendungsserver. Wenn Sie versuchen, diese Rolle auf<br />
einem neu eingerichteten <strong>Server</strong> zu installieren, werden Sie aufgefordert, zwei Features zu<br />
installieren: .NET Framework 3.0-Features und <strong>Windows</strong>-Prozessaktivierungsdienst (Abbildung<br />
12.1).
Rollen und Features 321<br />
Abbildung 12.1 Wenn Sie eine Rolle oder ein Feature installieren, fordert der Assistent "Rollen<br />
hinzufügen" Sie auf, zusätzlich alle Rollen und Features zu installieren, die dafür benötigt werden<br />
Sofern Sie die Standardauswahl nicht explizit ändern, werden alle Rollen und Features, die<br />
für die Kerndienste der jeweiligen Rolle benötigt werden, zusammen mit der grundlegenden<br />
Featureunterstützung installiert. Sie können Elemente abwählen, die Sie nicht haben möchten,<br />
aber falls Sie etwas deaktivieren, was unbedingt gebraucht wird, teilt Ihnen das System<br />
mit, dass Sie die Rolle in diesem Fall nicht installieren können.<br />
Standardrollen und -features<br />
Bei einem frisch installierten <strong>Server</strong> sind in der Standardeinstellung keine Rollen oder<br />
Features installiert. Es gibt insgesamt 16 Rollen in den Standard-, Enterprise- und Datacenter-Editionen;<br />
34 Features in der Standard Edition; und 35 Features in den Enterprise-<br />
und Datacenter-Editionen. Tabelle 12.1 zeigt alle Rollen, Tabelle 12.2 alle Features.<br />
Tabelle 12.1 Rollen in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Rollenname Beschreibung Abhängigkeiten<br />
Active Directory-<br />
Zertifikatdienste<br />
(Active Directory<br />
Certificate Services,<br />
AD CS)<br />
Active Directory-<br />
Domänendienste<br />
(Active Directory<br />
Domain Services,<br />
AD DS)<br />
Active Directory-<br />
Verbunddienste<br />
(Active Directory<br />
Federation Services,<br />
AD FS)<br />
Wird benutzt, um Zertifizierungsstellen einzurichten.<br />
<strong>Die</strong>se Rolle trug früher den Namen Microsoft-Zertifikatdienste.<br />
Sie wird ausführlich in Kapitel 10, »Implementieren<br />
der Active Directory-Zertifikatdienste«,<br />
beschrieben.<br />
<strong>Die</strong>se Rolle macht den <strong>Server</strong> zu einem Domänencontroller.<br />
Dazu müssen Sie diese Rolle installieren und<br />
(wie in früheren Versionen) von Hand Dcpromo.exe<br />
ausführen. <strong>Die</strong>se Rolle wird in Kapitel 9, »Optimieren<br />
der Active Directory-Domänendienste für <strong>Sicherheit</strong>«,<br />
ausführlich beschrieben.<br />
Ein Verbunddienst bietet die Möglichkeit eines einmaligen<br />
Anmeldens an mehrere Webanwendungen,<br />
zumindest während derselben Sitzung.<br />
Keine<br />
Keine, aber irgendwo im Netzwerk<br />
muss ein DNS-<strong>Server</strong> vorhanden<br />
sein.<br />
Keine, aber bestimmte Komponenten<br />
von AD FS müssen auf separaten<br />
Computern laufen. Außerdem werden<br />
AD DS und AD LDS im Netzwerk<br />
benötigt.
322 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Rollenname Beschreibung Abhängigkeiten<br />
Active Directory<br />
Lightweight Directory<br />
Services (AD<br />
LDS)<br />
Active Directory-<br />
Rechteverwaltungsdienste<br />
(Active<br />
Directory Rights<br />
Management Services,<br />
AD RMS)<br />
Ein LDAP-Anbieter für Organisationen, die Microsofts<br />
LDAP-<strong>Die</strong>nste ohne Active Directory einsetzen wollen.<br />
Ein <strong>Die</strong>nst, der es Benutzern erlaubt, Nutzungsrichtlinien<br />
für Daten festzulegen, die sie anderen Benutzern<br />
zur Verfügung stellen. So können sie einschränken,<br />
was andere Benutzer mit den Daten tun dürfen.<br />
Zum Beispiel kann ein Benutzer ein Microsoft Office<br />
Word-Dokument erstellen und darauf eine Richtlinie<br />
anwenden, die anderen das Lesen des Dokuments<br />
erlaubt, aber das Bearbeiten, Speichern und Drucken<br />
verbietet. AD RMS erledigt die Authentifizierungsaufgaben<br />
im Rahmen der Richtlinienerzwingung. <strong>Die</strong>se<br />
Rolle wird in Kapitel 11, »Implementieren der Active<br />
Directory-Rechteverwaltungsdienste«, ausführlich<br />
beschrieben.<br />
Anwendungsserver Bietet Zugriff auf Programme, die mithilfe eines Anwendungsframeworks<br />
geschrieben wurden. <strong>Die</strong>se<br />
Rolle wird normalerweise nicht allein eingesetzt, sondern<br />
in Kombination mit der Rolle Webserver (IIS).<br />
Beachten Sie, dass die Rolle Anwendungsserver das<br />
Feature <strong>Windows</strong>-Prozessaktivierungsdienst erfordert.<br />
<strong>Die</strong>ses Feature ist innerhalb des Webservers üblicherweise<br />
deaktiviert, sofern Sie es nicht explizit<br />
aktivieren.<br />
DHCP-<strong>Server</strong> Stellt Computern im gesamten Netzwerk DHCP<br />
(dynamische IP-Adresszuweisung) zur Verfügung.<br />
DNS-<strong>Server</strong> Stellt Namensauflösungsdienste für das gesamte<br />
Netzwerk zur Verfügung, die Hostnamen in IP-<br />
Adressen konvertieren.<br />
Faxserver Stellt zentralisierte Faxdienste in einem Netzwerk zur<br />
Verfügung.<br />
Dateidienste Fügt zusätzliche Dateiserverdienste hinzu, zum Beispiel<br />
das verteilte Dateisystem (Distributed File System,<br />
DFS), Verwaltungstools für freigegebene Ordner<br />
und NFS (Network File System) für Unix-Clients.<br />
Grundlegende <strong>Windows</strong>-Dateifreigabedienste stehen<br />
schon standardmäßig zur Verfügung, dafür brauchen<br />
Sie diese Rolle nicht zu installieren. Anders ausgedrückt:<br />
Falls Sie diese Rolle nicht installieren, sondern<br />
eine Freigabe von Hand anlegen, betrachtet Ihr Computer<br />
diese Rolle automatisch als installiert und öffnet<br />
die Firewall, um SMB-Protokollverkehr (<strong>Server</strong> Message<br />
Block) zu erlauben.<br />
Keine<br />
<strong>Die</strong> Computer müssen Domänenmitglieder<br />
sein.<br />
<strong>Die</strong> Features .NET Framework 3.0-<br />
Features und <strong>Windows</strong>-Prozessaktivierungsdienst.<br />
<strong>Die</strong> Rolle Webserver (IIS) ist erforderlich,<br />
falls Sie die Webserverunterstützung<br />
installieren.<br />
<strong>Die</strong> Rolle Webserver (IIS) sowie die<br />
Features .NET Framework 3.0-<br />
Features und Message Queuing sind<br />
für die Unterstützung des <strong>Windows</strong>-<br />
Prozessaktivierungsdienstes erforderlich.<br />
Keine<br />
Keine<br />
Druckdienste<br />
Keine
Rollenname Beschreibung Abhängigkeiten<br />
Netzwerkrichtlinien-<br />
und Zugriffsdienste<br />
<strong>Die</strong>se Rolle stellt die Sammlung von <strong>Die</strong>nsten zur<br />
Verfügung, die für Remotenetzwerkzugriff benötigt<br />
werden. Das umfasst Microsofts VPN-<strong>Server</strong> sowie<br />
Microsofts Netzwerkzugriffsschutzdienst (Network<br />
Access Protection, NAP), der eine Richtlinienerzwingung<br />
auf Netzwerkverbindungen zur Verfügung ermöglicht.<br />
Druckdienste Stellt erweiterte Druckerverwaltungsdienste zur Verfügung.<br />
In der Standardeinstellung umfasst diese Rolle<br />
nur das Snap-In Druckverwaltung. Sie können damit<br />
weitere Druckdienste für Unix-Computer und Clients<br />
im Internet zur Verfügung stellen. Beachten Sie, dass<br />
diese Rolle nicht erforderlich ist, um auf dem <strong>Server</strong>computer<br />
zu drucken. Sie wird auch nicht gebraucht,<br />
um Drucker im Netzwerk freizugeben oder auf freigegebene<br />
Drucker zuzugreifen. <strong>Die</strong>se Funktionen werden<br />
bereits standardmäßig unterstützt.<br />
Terminaldienste Erstellt einen Terminaldienste-Anwendungsserver ein,<br />
auf dem Benutzer Programme ausführen können.<br />
Beachten Sie, dass Sie diese Rolle in <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong> aktivieren müssen, sogar für administrative<br />
Terminaldienste.<br />
UDDI-<strong>Die</strong>nste UDDI-<strong>Die</strong>nste (Universal Description, Discovery, and<br />
Integration) sind eine Technologie, die Erkennung und<br />
Abruf von Informationen über Webdienste ermöglicht.<br />
Webserver (IIS) Falls während der Installation dieser Rolle keine Konfigurationsoptionen<br />
vorgenommen werden, bietet IIS<br />
7.0 in der Standardeinstellung nur Unterstützung für<br />
statisches HTML. In Kapitel 17, »Schützen von<br />
<strong>Server</strong>anwendungen«, finden Sie ausführliche<br />
Informationen über IIS.<br />
<strong>Windows</strong>-Bereitstellungsdienste<br />
(<strong>Windows</strong> Deployment<br />
Services,<br />
WDS)<br />
WDS ist die neueste Microsoft-Technologie für<br />
die Remotebereitstellung des Betriebssystems auf<br />
Computern im Netzwerk.<br />
Rollen und Features 323<br />
Erfordert die Rolle Webserver (IIS),<br />
falls die Integritätsregistrierungsstelle<br />
oder die Rollendienste für das Host<br />
Credential Authorization-Protokoll<br />
installiert sind.<br />
Erfordert, dass die Rolle Webserver<br />
(IIS) installiert ist, falls der Rollendienst<br />
Internetdrucken installiert wird.<br />
Erfordert die Rolle Webserver (IIS),<br />
falls die Rollendienste Terminaldienstegateway<br />
oder Terminaldienste-Webzugriff<br />
installiert werden.<br />
Der Rollendienst Terminaldienstegateway<br />
erfordert wiederum die Rolle<br />
Netzwerkrichtlinien- und Zugriffsdienste<br />
und das Feature RPC-über-<br />
HTTP-Proxy.<br />
Erfordert Interne <strong>Windows</strong>-Datenbank,<br />
falls die UDDI-<strong>Die</strong>nstedatenbank<br />
auf diesem Computer installiert<br />
wird. Erfordert außerdem die Rolle<br />
Webserver (IIS), falls die UDDI-<br />
Webdiensteanwendung installiert<br />
wird.<br />
Keine<br />
Keine
324 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Tabelle 12.2 Features in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Featurename Beschreibung Abhängigkeiten<br />
.NET Framework<br />
3.0-Features<br />
BitLocker-Laufwerkverschlüsselung <br />
BITS-<strong>Server</strong>erweiterungen<br />
Verbindungs-<br />
Manager-Verwaltungskit <br />
Desktopdarstellung <br />
Failover-Clusterunterstützung<br />
(nur Enterprise<br />
und Datacenter<br />
Edition)<br />
Gruppenrichtlinienverwaltung <br />
Internetdruckclient<br />
iSNS (Internet<br />
Storage Name<br />
<strong>Server</strong>)<br />
Eine Sammlung von Unterfeatures, die zusammen die<br />
Unterstützung für das .NET Framework 3.0-<br />
Anwendungsframework bereitstellen.<br />
BitLocker stellt eine vollständige Festplattenverschlüsselung<br />
zur Verfügung. Es wird in Kapitel 15, »Schützen<br />
von Zweigstellen«, ausführlich beschrieben.<br />
BITS-<strong>Server</strong>erweiterungen erlauben einem <strong>Server</strong>,<br />
Dateien über den intelligenten Hintergrundübertragungsdienst<br />
zu empfangen, einen asynchronen Dateiübertragungsdienst,<br />
der mit dem Ziel entwickelt wurde,<br />
Dateien effizient zu übertragen, ohne den normalen<br />
Netzwerkverkehr zu verhindern.<br />
Mit dem Verbindungs-Manager-Verwaltungskit kann<br />
ein Administrator automatisierte Verbindungsprofile<br />
erstellen, die eine Verbindung zu einem Microsoft-<br />
VPN-<strong>Server</strong> herstellen.<br />
Bewirkt, dass <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> dieselbe Benutzeroberfläche<br />
wie <strong>Windows</strong> Vista bekommt. Umfasst<br />
Designs, <strong>Windows</strong> Media Player und <strong>Windows</strong> Fotogalerie.<br />
<strong>Die</strong>ses Feature sollte auf Produktivservern<br />
niemals installiert werden.<br />
Stellt Clusterdienste für clusterfähige Anwendungen<br />
zur Verfügung.<br />
Webserver und <strong>Windows</strong>-Prozessaktivierungsdienst<br />
sind nur erforderlich,<br />
falls die WCF-Aktivierung ausgewählt<br />
ist.<br />
Keine<br />
Rolle Webserver (IIS) und Feature<br />
<strong>Windows</strong>-Prozessaktivierungsdienst.<br />
Keine<br />
Keine<br />
Keine<br />
Installiert die Konsole Gruppenrichtlinienverwaltung. Keine<br />
Installiert einen Druckclient, damit der <strong>Server</strong> über IPP<br />
(Internet Printing Protocol) auf Druckservern ausdrucken<br />
kann.<br />
Stellt Suchdienste für SAN (iSCSI Storage Area Network)<br />
bereit.<br />
LPR-Portmonitor Druckclient für LPD-Druckserver (Line Printer<br />
Daemon), wie sie in Unix eingesetzt werden.<br />
Message Queuing<br />
Stellt Nachrichtenübertragungsdienste mit sicherer,<br />
nach Prioritäten geordneter und garantierter Auslieferung<br />
zur Verfügung, sogar wenn der Empfängerdienst<br />
gerade offline ist.<br />
Keine<br />
Keine<br />
Keine<br />
Erfordert die Rolle Webserver (IIS) und<br />
das Feature <strong>Windows</strong>-Prozessaktivierungsdienst,<br />
falls HTTP-Unterstützung<br />
installiert wird. Manche <strong>Die</strong>nste werden<br />
nur in Domänenumgebungen oder auf<br />
einem DC unterstützt, zum Beispiel der<br />
Routingdienst und die <strong>Windows</strong> 2000-<br />
Clientunterstützung.
Featurename Beschreibung Abhängigkeiten<br />
Multipfad-E/A Bietet Unterstützung für mehrere E/A-Kanäle (Ein-/<br />
Ausgabe) zum selben Gerät. Wird in erster Linie auf<br />
hochleistungsfähigen Speicherservern benutzt.<br />
Netzwerklastenausgleich<br />
Peer Name Resolution-Protokoll<br />
Verbessertes<br />
<strong>Windows</strong>-<br />
Audio-/Video-<br />
Streaming<br />
Remoteunterstützung <br />
Remotedifferenzialkomprimierung<br />
Remoteserver-<br />
Verwaltungstools<br />
Wechselmedien-<br />
Manager<br />
Stellt Lastverteilungsdienste für <strong>Windows</strong> zur Verfügung.<br />
Wird vor <strong>Server</strong>clustern benutzt.<br />
Erlaubt es Peer-to-Peer-Anwendungen, Namen zu<br />
registrieren und aufzulösen, um Anwendungen leichter<br />
erkennen zu können.<br />
Stellt QoS-<strong>Die</strong>nste (Quality of Service) für das Streaming<br />
von Audio und Video über IP-Netzwerke zur<br />
Verfügung. Wird in erster Linie für Heimnetzwerke<br />
eingesetzt. Auf <strong>Server</strong>plattformen bietet qWAVE nur<br />
Flussraten- und Prioritätsdienste.<br />
Remoteunterstützung wird eingesetzt, um interaktiven<br />
<strong>technische</strong>n Support zur Verfügung zu stellen. Das<br />
Feature Remoteunterstützung umfasst Funktionalität<br />
für den Benutzer, der die Unterstützung anfordert, und<br />
den Helfer, der sie gewährt.<br />
Wird benutzt, um lediglich Differenzdaten (Deltas) von<br />
Dateien über ein Netzwerk zu übertragen.<br />
Eine Sammlung von Tools, mit denen andere <strong>Server</strong><br />
im Remotezugriff verwaltet werden können. Das Feature<br />
Remoteserver-Verwaltungstools umfasst Unterstützung<br />
für die Verwaltung der meisten Rollen und<br />
von sechs Features, ohne dass die entsprechende<br />
Rolle oder das Feature installiert werden müsste.<br />
<strong>Die</strong>se Tools stehen auch als Download unter download.microsoft.com<br />
zur Verfügung, sodass Sie sie<br />
unter <strong>Windows</strong> Vista installieren können.<br />
Verwaltet und katalogisiert Wechseldatenträger und<br />
verwaltet automatisierte Wechselmediengeräte.<br />
Keine<br />
Keine<br />
Keine<br />
Keine<br />
Keine<br />
Keine<br />
Rollen und Features 325<br />
<strong>Die</strong> Abhängigkeiten unterscheiden sich<br />
je nachdem, welche Rollen und Features<br />
Sie unterstützen wollen. <strong>Die</strong><br />
Webservertools erfordern das Feature<br />
<strong>Windows</strong>-Prozessaktivierungsdienst.<br />
<strong>Die</strong> BITS-<strong>Server</strong>erweiterungstools<br />
erfordern die Rolle Webserver (IIS) und<br />
das Feature <strong>Windows</strong>-Prozessaktivierungsdienst.<br />
<strong>Die</strong> SMTP-<strong>Server</strong>tools<br />
erfordern die Rolle Webserver (IIS).<br />
Keine
326 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Featurename Beschreibung Abhängigkeiten<br />
RPC-über-HTTP-<br />
Proxy<br />
Einfache TCP/IP-<br />
<strong>Die</strong>nste<br />
Unterstützt die Fähigkeit, RPC-Verbindungen (Remote<br />
Procedure Call, Remoteprozeduraufruf) über HTTP-<br />
(Hypertext Transport Protocol) und HTTPS-<br />
Verbindungen zu tunneln. <strong>Die</strong>ses Feature wird zum<br />
Beispiel eingesetzt, um Outlook Anywhere-Zugriff zu<br />
ermöglichen, sodass Benutzer von Microsoft Office<br />
Outlook von überall im Internet aus auf ihren Microsoft<br />
Exchange <strong>Server</strong> zugreifen können. Das mag wie ein<br />
<strong>Sicherheit</strong>sproblem klingen, aber wenn es richtig<br />
implementiert wird, kann es die Netzwerksicherheit<br />
deutlich verbessern.<br />
<strong>Die</strong> große Mehrheit der VPN-Verbindungen wird ausschließlich<br />
für E-Mail-Zugriff benutzt, bietet dem Benutzer<br />
aber vollständigen Zugriff auf das Unternehmensnetzwerk.<br />
Indem Organisationen nur RPC<br />
über HTTP zur Verfügung stellen und Benutzern die<br />
Verbindung mit Microsoft Outlook erlauben, werden<br />
viele dieser VPN-Verbindungen überflüssig. Das verringert<br />
die Gefahr, dass Malware über eine VPN-<br />
Verbindung in das Unternehmensnetzwerk eindringt.<br />
Wurde ursprünglich entwickelt, um eine Problembehandlung<br />
für TCP/IP-Verbindungen durchzuführen, als<br />
solche Verbindungen noch sehr unzuverlässig waren.<br />
Heutzutage gibt es keinen Grund mehr, das Feature<br />
Einfache TCP/IP-<strong>Die</strong>nste in einem Netzwerk zu installieren.<br />
<strong>Die</strong> <strong>Die</strong>nste umfassen einen Zeichengenerator,<br />
die Befehle Daytime, Discard (ein <strong>Die</strong>nst, der beliebige<br />
Eingaben annimmt und schlicht verwirft), Echo und<br />
Quote of the day. Falls diese <strong>Die</strong>nste installiert sind,<br />
kann ein Angreifer ganz einfach alle Netzwerkoperationen<br />
in einem Host zum Erliegen bringen, indem er<br />
Ausgaben vom Zeichengenerator in den Echodienst<br />
leitet.<br />
SMTP-<strong>Server</strong> Stellt Mailübertragungsdienste und -Relays zur Verfügung.<br />
SNMP-<strong>Die</strong>nst SNMP (Simple Network Management Protocol) ist ein<br />
sehr häufig genutztes Protokoll, um Überwachungsinformationen<br />
von Netzwerkgeräten abzurufen und zu<br />
sammeln.<br />
Speicher-Manager<br />
für SANs<br />
Subsystem für<br />
Unix-basierte<br />
Anwendungen<br />
(Subsystem for<br />
Unix-based Applications,<br />
SUA)<br />
Rolle Webserver (IIS) und Feature<br />
<strong>Windows</strong>-Prozessaktivierungsdienst.<br />
Keine<br />
Rolle Webserver (IIS) und Feature Remoteserver-Verwaltungstools.<br />
Keine<br />
Verwaltungstool für SANs. Keine<br />
Enthält ein POSIX-Subsystem. Ein Satz von Unix-<br />
Tools, darunter eine Bash-Shell, steht als Download<br />
bei Microsoft bereit.<br />
Keine
Featurename Beschreibung Abhängigkeiten<br />
Telnet-Client Ein Telnet-Client für Remotebefehlszeilenzugriff auf<br />
Telnet-<strong>Server</strong>n.<br />
Telnet-<strong>Server</strong> Ein Telnet-<strong>Server</strong>. Es wird dringend davon abgeraten,<br />
dieses Feature zu installieren und zu nutzen. Telnet ist<br />
ein Klartextprotokoll, es gilt als sehr unsicher, sofern<br />
der Kanal nicht verschlüsselt ist. Verwenden Sie stattdessen<br />
die Terminaldienste.<br />
TFTP-Client Ein Client für TFTP (Trivial File Transfer Protocol).<br />
TFTP ist ein schlankes, Dateiübertragungsprotokoll,<br />
das völlig ohne Authentifizierung arbeitet. Es wird von<br />
Angreifer hauptsächlich benutzt, um Dateien auf einen<br />
kompromittierten <strong>Server</strong> zu übertragen. Es sollte niemals<br />
auf einem <strong>Server</strong> installiert sein.<br />
Interne <strong>Windows</strong>-<br />
Datenbank<br />
<strong>Windows</strong> Power-<br />
Shell<br />
<strong>Windows</strong>-Prozessaktivierungsdienst<br />
<strong>Windows</strong> <strong>Server</strong>-<br />
Sicherungsfeatures<strong>Windows</strong>-Systemressourcen-<br />
Manager (WSRM)<br />
Eine Version der Microsoft SQL <strong>Server</strong> Embedded<br />
Edition. Es stellt Datenbankdienste für andere <strong>Die</strong>nste<br />
zur Verfügung und sollte nicht als eigenständige<br />
Datenbank eingesetzt werden.<br />
Keine<br />
Keine<br />
Keine<br />
Keine<br />
Eine sehr leistungsfähige Befehlsshell. Keine<br />
Stellt Remoteprozessdienste für Anwendungen über<br />
WCF (<strong>Windows</strong> Communication Foundation) zur Verfügung.<br />
Früher stand diese Möglichkeit nur für HTTP-<br />
Anwendungen über IIS zur Verfügung. Indem diese<br />
<strong>Die</strong>nste in ein separates Feature ausgelagert wurden,<br />
konnte die Abhängigkeit von IIS entfernt werden.<br />
Im Unterschied zu <strong>Windows</strong> <strong>Server</strong> 2003 und älteren<br />
Versionen werden die Datensicherungstools nicht<br />
standardmäßig installiert. <strong>Die</strong>ses Feature installiert sie.<br />
Erlaubt Ihnen, die Ressourcenzuweisung innerhalb<br />
des Systems zu verwalten.<br />
WINS-<strong>Server</strong> WINS stellt Hostnamenauflösung für ältere <strong>Windows</strong>-<br />
Netzwerke zur Verfügung. Seit <strong>Windows</strong> 2000 wird<br />
WINS nicht mehr benötigt, seine Funktionalität wurde<br />
von DNS übernommen. <strong>Die</strong>ser <strong>Die</strong>nst sollte nicht<br />
installiert werden, sofern keine zwingenden Gründe<br />
bestehen.<br />
WLAN-<strong>Die</strong>nst Stellt Konfigurationsunterstützung für Drahtlosnetzwerkkarten<br />
zur Verfügung. <strong>Die</strong>ser <strong>Die</strong>nst wird nicht<br />
benötigt, falls der <strong>Server</strong> keine Drahtlosnetzwerkkarten<br />
eingebaut hat.<br />
Keine<br />
Rollen und Features 327<br />
<strong>Die</strong> Befehlszeilentools erfordern die<br />
<strong>Windows</strong> PowerShell.<br />
Interne <strong>Windows</strong>-Datenbank.<br />
Keine<br />
Keine<br />
Auf der CD Auf der CD finden Sie ein Dokument, das die <strong>Die</strong>nste den verschiedenen Rollen und<br />
Features zuordnet, sodass Sie genau sehen können, welche <strong>Die</strong>nste von einer bestimmten Rolle und<br />
einem Feature benutzt werden. Sie finden dieses Dokument in den Materialien zu Kapitel 6.
328 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Beachten Sie, dass die Spalte »Abhängigkeiten« zwar gesamte Rollen auflistet, in vielen<br />
Fällen aber nur ein kleiner Teil dieser Rolle für eine andere Rolle oder ein Feature benötigt<br />
wird. Zum Beispiel benötigt der SMTP-<strong>Server</strong> nur die IIS 6.0-Verwaltungstools aus der<br />
Rolle Webserver (IIS) und die SMTP-<strong>Server</strong>tools aus dem Feature Remoteserver-Verwaltungstools.<br />
Welche Abhängigkeiten tatsächlich bestehen, können Sie nur herausfinden, indem Sie<br />
versuchsweise einzelne Features deaktivieren.<br />
Ihr <strong>Server</strong> vor der Installation von Rollen<br />
Wenn Sie zusätzliche Rollen oder Features installieren, brauchen Sie dazu nicht das Installationsmedium<br />
einzulegen. Alle Daten, die erforderlich sind, um sämtliche Rollen und Features<br />
bereitzustellen, werden nämlich während der Erstinstallation auf die Festplatte kopiert.<br />
Das bedeutet, dass die Dateien eigentlich schon vorhanden sind. Sie befinden sich aber noch<br />
nicht in ihrer endgültigen Form an den normalen Speicherorten des Dateisystems. Stattdessen<br />
sind sie im Verzeichnis %SystemRoot%\winsxs gespeichert. Das ist wichtig für Features<br />
wie zum Beispiel Telnet-Client und TFTP-Client. <strong>Die</strong>se Features sind nichts anderes als<br />
ausführbare Dateien, die im Dateisystem bereitliegen. Damit Sie diese Programme starten<br />
können, müssen auch die zugehörigen Katalog- und Manifestdateien installiert sein. Und<br />
genau diese Dateien werden erst dann installiert, wenn das Feature selbst installiert wird.<br />
Natürlich kann ein Krimineller, der über administrativen Zugriff verfügt, das Feature problemlos<br />
installieren, daher brächte es kaum einen <strong>Sicherheit</strong>svorteil, würden die Dateien bei<br />
der Erstinstallation nicht auf die Festplatte übertragen.<br />
<strong>Die</strong>ses Konzept, alle Dateien, die irgendwann möglicherweise benötigt werden, gleich bei<br />
der Erstinstallation auf der Festplatte verfügbar zu machen, ist in Microsoft Office seit der<br />
Version Office 2003 üblich. Letztlich wird dafür weniger Festplattenplatz benötigt, als sie<br />
wahrscheinlich glauben, aber dennoch eine ganze Menge: <strong>Die</strong> 32-Bit-Editionen von <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> belegen etwa 5,3 GByte (gemessen an einer der der letzten Prerelease-<br />
Versionen). Dagegen kam <strong>Windows</strong> <strong>Server</strong> 2003 R2 mit 1,72 GByte aus.<br />
Standardmäßig installierte <strong>Die</strong>nste<br />
Schon bevor Sie einen <strong>Server</strong> konfigurieren, indem Sie verschiedene Rollen und Features<br />
hinzufügen, führt er eine ganze Menge <strong>Die</strong>nste aus. In der Standardeinstellung gibt es<br />
105 <strong>Die</strong>nste, von denen 42 automatisch gestartet werden, 55 manuell und 8 deaktiviert sind.<br />
Bei einer Neuinstallation von <strong>Windows</strong> <strong>Server</strong> 2003 R2 waren dagegen standardmäßig<br />
86 <strong>Die</strong>nste installiert, von denen 34 automatisch gestartet wurden, 32 bei Bedarf und 20<br />
deaktiviert waren. Trotz der Definition von Rollen und der Verringerung der standardmäßig<br />
bereitgestellten Rollen ist der Umfang von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> also deutlich angewachsen.<br />
Daher müssen Sie besonders sorgfältig sein, wenn Sie das System absichern. Weitere<br />
Informationen über die <strong>Die</strong>nsthärtung finden Sie in Kapitel 6, »<strong>Die</strong>nste«.<br />
<strong>Server</strong> Core<br />
Wir haben <strong>Server</strong> Core bereits einige Male erwähnt. Es ist eine abgespeckte Version von<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, die keine grafische Benutzeroberfläche enthält und nur einen Teil der<br />
Rollen und Features unterstützt. <strong>Die</strong> Benutzeroberfläche in <strong>Server</strong> Core ist eine schlichte<br />
Befehlszeile (Abbildung 12.2).
Abbildung 12.2 <strong>Server</strong> Core ist eine abgespeckte Version von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, die nur<br />
einen Teil der Rollen unterstützt<br />
<strong>Server</strong> Core 329<br />
Abbildung 12.3 <strong>Server</strong> Core ist eine Installationsoption, die während des Setups angeboten wird
330 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
<strong>Server</strong> Core ist genau genommen keine separate Version, sondern eine Installationsoption,<br />
die während des Setups angeboten wird. Sobald Sie Ihren Product Key eingegeben haben,<br />
können Sie auswählen, ob Sie die vollständige Version oder die <strong>Server</strong> Core-Version der<br />
gekauften Edition installieren wollen. Das Auswahldialogfeld sehen Sie in Abbildung 12.3.<br />
<strong>Server</strong> Core ist eine hervorragende Wahl für viele Infrastrukturserver, weil Sie damit die<br />
Möglichkeit bekommen, diese <strong>Server</strong> mit möglichst wenigen Features zu betreiben.<br />
Hinweis <strong>Server</strong> Core hat in der Standardeinstellung ein leeres Administratorkennwort. Das Kennwort für<br />
den lokalen Administrator wird während der ersten Anmeldung dieses Benutzers festgelegt. Weil Sie sich<br />
normalerweise am Computer anmelden, um ihn zu einer Domäne hinzuzufügen, werden Sie normalerweise<br />
bei dieser Gelegenheit aufgefordert, das Kennwort zu ändern. Trotzdem ist es wichtig zu wissen, dass<br />
anfangs ein leeres Kennwort verwendet wird.<br />
Es ist nicht unbedingt schlecht, das Kennwort für das integrierte Administratorkonto leer zu lassen. Falls der<br />
Computer physisch sicher ist, bieten Sie dadurch keine wesentliche Angriffsfläche, weil Konten mit leeren<br />
Kennwörtern nicht im Remotezugriff benutzt werden können. Andererseits wird die Verwaltung der Kennwörter<br />
für die lokalen Administratorkonten auf Hunderten oder Tausenden von <strong>Server</strong>n in einem Datencenter<br />
deutlich einfacher, wenn Sie das Kennwort leer lassen. Analysieren Sie Ihre Situation: Falls Sie auf die<br />
physische <strong>Sicherheit</strong> Ihrer <strong>Server</strong> vertrauen, kann es am sinnvollsten sein, das Kennwort leer zu lassen.<br />
Das ist wahrscheinlich deutlich sicherer, als auf Tausenden von <strong>Server</strong>n dasselbe Kennwort zu verwenden.<br />
Falls irgendeiner dieser Tausenden von <strong>Server</strong>n kompromittiert wird, müssen alle als kompromittiert betrachtet<br />
werden. <strong>Die</strong>se Art von <strong>Sicherheit</strong>sabhängigkeit wird in Kapitel 14 beschrieben.<br />
In <strong>Server</strong> Core unterstützte Rollen<br />
<strong>Server</strong> Core unterstützt nur einen Teil der Rollen, die in einer vollständigen Installation zur<br />
Verfügung stehen. Es wurde in erster Linie für den Einsatz als Infrastrukturserver entworfen.<br />
<strong>Server</strong> Core unterstützt folgende Rollen:<br />
Active Directory-Domänendienste<br />
Active Directory Lightweight Directory Services (einfach LDAP, früher ADAM)<br />
DHCP-<strong>Server</strong><br />
DNS-<strong>Server</strong><br />
Dateidienste<br />
IIS<br />
Druckdienste<br />
<strong>Die</strong> meisten Rollen werden mit dem Befehl OCSetup.exe installiert, der auf den Paketmanager<br />
(pkgmgr.exe) zurückgreift. In Anleitungen können beide Programme genannt werden,<br />
um Rollen zu installieren. Beachten Sie, dass das Befehlszeilenprogramm <strong>Server</strong>Manager-<br />
Cmd.exe, das bei einer vollständigen Installation vorhanden ist, in <strong>Server</strong> Core nicht zur<br />
Verfügung steht.<br />
Welche Rollen verfügbar sind, können Sie sich mit OCList.exe anzeigen lassen. <strong>Die</strong>ses Tool<br />
steht nur in <strong>Server</strong> Core zur Verfügung. Zum Beispiel können Sie mit dem folgenden Befehl<br />
die Rolle DNS-<strong>Server</strong> installieren:<br />
start /w ocsetup DNS-<strong>Server</strong>-Core-Role<br />
Sie müssen ocsetup hier über den Befehl start ausführen, weil ocsetup andernfalls sofort<br />
zurückkehrt und Sie keine Rückmeldung erhalten, ob die Installation erfolgreich war. Indem
<strong>Server</strong> Core 331<br />
Sie ocsetup innerhalb von start /w aufrufen, stellen Sie sicher, dass die Befehlszeile erst<br />
dann zurückkehrt, wenn die Installation abgeschlossen ist.<br />
Es gibt eine Ausnahme für diese Installationsprozedur: die Rolle Active Directory-Domänendienste.<br />
Wenn Sie diese Rolle installieren, wird der Computer nicht automatisch zu einem<br />
Domänencontroller hochgestuft. Sie schaffen damit lediglich die Voraussetzung, diese Hochstufung<br />
anschließend durchzuführen, indem Sie wie in älteren <strong>Windows</strong>-Versionen das Tool<br />
DCPromo ausführen. In <strong>Server</strong> Core liegt das Problem darin, dass Sie eine Anwortdatei<br />
einsetzen müssen, um die Active Directory-Domänendienste zu installieren, es gibt nämlich<br />
keinen GUI-Assistenten. Weitere Informationen, wie Sie eine <strong>Server</strong> Core-Installation auf<br />
Active Directory hochstufen und wie Sie <strong>Server</strong> Core generell verwalten, finden Sie im<br />
Artikel »<strong>Server</strong> Core Installation Option of <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Step-by-Step Guide«<br />
auf Microsoft TechNet unter http://technet2.microsoft.com/windowsserver<strong>2008</strong>/en/library/<br />
47a23a74-e13c-46de-8d30-ad0afb1eaffc1033.mspx?mfr=true.<br />
In <strong>Server</strong> Core unterstützte Features<br />
<strong>Server</strong> Core unterstützt auch nur einen Teil der Features, die in den vollständigen Editionen<br />
von <strong>Windows</strong> <strong>Server</strong> zur Verfügung stehen. Folgende Features sind in <strong>Server</strong> Core enthalten:<br />
Datensicherung<br />
BitLocker-Laufwerkverschlüsselung<br />
Failover-Clusterunterstützung (nur Enterprise und Datacenter Edition)<br />
Multipfad-E/A<br />
Netzwerklastenausgleich<br />
Wechselmedien-Manager<br />
Verbessertes <strong>Windows</strong>-Audio-/Video-Streaming<br />
SNMP-<strong>Die</strong>nst<br />
Subsystem für UNIX-basierte Anwendungen<br />
Telnet-Client<br />
WINS-<strong>Server</strong><br />
Was in <strong>Server</strong> Core nicht enthalten ist<br />
Es gibt eine ganze Menge, was in <strong>Server</strong> Core nicht enthalten ist. Am deutlichsten fällt das<br />
Fehlen von <strong>Windows</strong>-Explorer und Internet Explorer auf. <strong>Server</strong> Core ist die erste <strong>Windows</strong>-Version<br />
seit vielen Jahren, die keinen Webbrowser mitbringt. <strong>Server</strong> Core enthält auch<br />
keine Version des <strong>Windows</strong> Media Player, und die meisten anderen Tools, die sich nur an<br />
Endverbraucher richten, fehlen völlig. Wichtig ist allerdings, dass <strong>Server</strong> Core weniger<br />
<strong>Die</strong>nste ausführt und weniger Festplatteplatz benötigt. Im Vergleich zur vollständigen Installation,<br />
die 5,3 GByte Festplattenplatz benötigt, kommt <strong>Server</strong> Core mit gut 1 GByte aus.<br />
Außerdem werden in <strong>Server</strong> Core nur 38 <strong>Die</strong>nste automatisch gestartet, weitere 30 starten<br />
bei Bedarf und einer (Browser) ist deaktiviert. <strong>Die</strong> 37 <strong>Die</strong>nste, die in Tabelle 12.3 aufgelistet<br />
sind, fehlen in einer <strong>Server</strong> Core-Installation gegenüber einer vollständigen Installation desselben<br />
Produkts.
332 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Für Minimalisten und alle, die ihren Computer nur für eine einzige Aufgabe brauchen, ist<br />
<strong>Server</strong> Core offensichtlich das Mittel der Wahl.<br />
Tabelle 12.3 <strong>Die</strong>nste, die gegenüber der vollständigen Installation in <strong>Server</strong> Core fehlen<br />
Kurzbezeichnung <strong>Die</strong>nst<br />
alg Gatewaydienst auf Anwendungsebene<br />
appinfo Anwendungsinformationen<br />
AudioEndpointBuilder <strong>Windows</strong>-Audio-Endpunkterstellung<br />
Audiosrv <strong>Windows</strong>-Audio<br />
clr_optimization_ Microsoft .NET Framework<br />
CscService Offlinedateien<br />
dot3svc Automatische Konfiguration (verkabelt)<br />
EapHost Extensible Authentication-Protokoll<br />
fdPHost Funktionssuchanbieter-Host<br />
FDResPub Funktionssuche-Ressourcenveröffentlichung<br />
IPBusEnum PNP-X-IP-Busauflistung<br />
MMCSS Multimediaklassenplaner<br />
Netman Netzwerkverbindungen<br />
RasAuto Verwaltung für automatische RAS-Verbindung<br />
RasMan RAS-Verbindungsverwaltung<br />
RemoteAccess Routing und RAS<br />
RpcLocator RPC-Locator<br />
SharedAccess Gemeinsame Nutzung der Internetverbindung<br />
ShellHWDetection Shellhardwareerkennung<br />
SLUINotify SL-Benutzerschnittstellen-Benachrichtigungsdienst<br />
Spooler Druckwarteschlange<br />
SSDPSRV SSDP-Suche<br />
SstpSvc SSTP-<strong>Die</strong>nst<br />
SysMain Superfetch<br />
TapiSrv Telefonie<br />
Themes Designs<br />
Threadorder <strong>Server</strong> für Threadsortierung<br />
TrkWks Überwachung verteilter Verknüpfungen (Client)<br />
UI0Detect Erkennung interaktiver <strong>Die</strong>nste<br />
upnphost UPnP-Gerätehost<br />
UxSms Sitzungs-Manager für Desktopfenster-Manager<br />
wercplsupport Unterstützung in der Systemsteuerung unter Lösungen für Probleme<br />
WerSvc <strong>Windows</strong>-Fehlerberichterstattungsdienst<br />
WPDBusEnum Enumeratordienst für tragbare Geräte<br />
wudfsvc <strong>Windows</strong> Driver Foundation <strong>–</strong> Benutzermodus-Plattformbibliothek
Tools zum Verwalten von <strong>Server</strong>rollen 333<br />
Tools zum Verwalten von <strong>Server</strong>rollen<br />
<strong>Windows</strong> <strong>Server</strong> 2003 R2 lieferte erstmals den neuen <strong>Server</strong>verwaltungs-Assistenten mit.<br />
<strong>Die</strong>s war das erste Tool, mit dem Administratoren ihre <strong>Server</strong> einfach konfigurieren konnten,<br />
um beliebige Rollen zu unterstützen. <strong>Die</strong> Tools in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wurden etwas<br />
leistungsfähiger und der Funktionsumfang ist gestiegen. In diesem Abschnitt sehen wir uns<br />
die drei zentralen Tools an, mit denen Sie <strong>Server</strong>rollen in einer vollständigen Installation<br />
von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> verwalten. Insbesondere achten wir dabei darauf, welche <strong>Sicherheit</strong>saspekte<br />
jeweils wichtig sind.<br />
Aufgaben der Erstkonfiguration<br />
Das erste Tool, mit dem Sie wahrscheinlich zu tun haben, hieß unter <strong>Windows</strong> <strong>Server</strong> 2003<br />
<strong>Server</strong>verwaltungs-Assistent. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> trägt es den Namen Aufgaben der<br />
Erstkonfiguration (Initial Configuration Tasks, ICT). Es wird geöffnet, sobald Sie sich zum<br />
ersten Mal anmelden. Wie in Abbildung 12.4 zu sehen, zeigt dieses Tool grundlegende Konfigurationsinformationen<br />
zu Ihrem <strong>Server</strong> an und gibt Ihnen die Möglichkeit, die Assistenten<br />
zum Hinzufügen von Rollen und Features zu starten.<br />
Abbildung 12.4 Das neue Tool Aufgaben der Erstkonfiguration zeigt einige nützliche Informationen über<br />
Ihren <strong>Server</strong> an und gibt Ihnen Zugriff auf die Konfigurationstools
334 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Das Tool Aufgaben der Erstkonfiguration ist recht nützlich für die ersten Schritte. Es liefert<br />
außerdem einige brauchbare Informationen, sogar auf einem stabilen, konfigurierten <strong>Server</strong>.<br />
Der <strong>Server</strong>-Manager enthält die meisten dieser Informationen ebenfalls, aber seine Seite ist<br />
viel größer. Es kann durchaus sinnvoll sein, das Fenster Aufgaben der Erstkonfiguration<br />
offen zu lassen.<br />
<strong>Die</strong> Assistenten Rollen hinzufügen und Features hinzufügen<br />
Wenn Sie im Tool Aufgaben der Erstkonfiguration auf Rollen hinzufügen oder Features<br />
hinzufügen klicken, wird der entsprechende Assistent gestartet. <strong>Die</strong>se Assistenten leiten Sie<br />
durch die Schritte, die erforderlich sind, um eine bestimmte Rolle beziehungsweise ein Feature<br />
auf dem <strong>Server</strong> zu aktivieren.<br />
Sie können Rollen und Features auch über die Befehlszeile mit dem Befehl <strong>Server</strong>Manager-<br />
Cmd.exe hinzufügen. In einer <strong>Server</strong> Core-Installation müssen Sie natürlich die Befehlszeile<br />
verwenden, weil es dort keine grafische Benutzeroberfläche (Graphical User Interface, GUI)<br />
gibt. Wenn Sie Rollen unter <strong>Server</strong> Core verwalten, verwenden Sie aber gewöhnlich Pkgmgr.exe<br />
oder Ocsetup.exe. <strong>Die</strong> meisten Administratoren entscheiden sich aber für einen der<br />
zwei Assistenten Rollen hinzufügen und Features hinzufügen. Sie sind sich sehr ähnlich<br />
und können entweder in Aufgaben der Erstkonfiguration oder im <strong>Server</strong>-Manager gestartet<br />
werden.<br />
Abbildung 12.5 Der <strong>Server</strong>-Manager versammelt die meisten Tools, die Sie für die Verwaltung eines<br />
<strong>Server</strong>s brauchen, in einer Konsole
Tools zum Verwalten von <strong>Server</strong>rollen 335<br />
<strong>Server</strong>-Manager<br />
Der <strong>Server</strong>-Manager (Abbildung 12.5) kombiniert die Features des Systemsteuerungsmoduls<br />
Programme hinzufügen/entfernen, des <strong>Windows</strong>-<strong>Sicherheit</strong>scenters, der Konsole Computerverwaltung<br />
und verschiedener MMC-Snap-Ins <strong>–</strong> alles in einem einzigen Tool.<br />
Wenn Sie eine Rolle installieren wollen, können Sie entweder im <strong>Server</strong>-Manager oder<br />
in Aufgaben der Erstkonfiguration auf Rollen hinzufügen klicken. Daraufhin wird eine Seite<br />
mit einigen Erklärungen angezeigt. Klicken Sie auf Weiter. Nun sehen Sie die Seite aus<br />
Abbildung 12.6.<br />
Abbildung 12.6 Rollen wählen Sie auf der Hauptseite im Assistenten "Rollen hinzufügen" aus<br />
Auf der Seite aus Abbildung 12.6 treffen Sie die wichtigsten Entscheidungen. Vergessen Sie<br />
aber nicht, dass danach noch etliche Seiten folgen können. Falls Sie zum Beispiel die Rolle<br />
Anwendungsserver auswählen, öffnet sich das Dialogfeld aus Abbildung 12.1 weiter oben in<br />
diesem Kapitel. Sie können hier nichts ändern, sondern nur die vorgeschlagenen Einstellungen<br />
bestätigen. Nachdem Sie einige Male auf Weiter geklickt haben, wird die Seite aus<br />
Abbildung 12.7 angezeigt.<br />
In Abbildung 12.7 werden mehrere Elemente angeboten, die Sie wahrscheinlich nicht auf<br />
Ihrem Anwendungsserver brauchen. Abhängig von der Rolle können Sie einige davon entfernen,<br />
andere nicht. Zum Beispiel können Sie darauf verzichten, COM+-Netzwerkzugriff<br />
zu installieren, aber in manchen Fällen sind die Abhängigkeiten fest einprogrammiert. Daher<br />
müssen Sie den Rollendienst Application <strong>Server</strong> Foundation aktiviert lassen. Welche<br />
Abhängigkeiten bestehen, hängt von der jeweiligen Rolle ab, die Sie installieren wollen.
336 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Abbildung 12.7 Im Rahmen der Rolleninstallation können Sie auswählen, welche Rollendienste<br />
Sie konfigurieren wollen<br />
Der <strong>Sicherheit</strong>skonfigurations-Assistent<br />
<strong>Die</strong> neue Einteilung in Rollen und Features für die <strong>Server</strong>verwaltung ist recht nützlich und<br />
hilft dabei, einen <strong>Server</strong> so zu konfigurieren, dass er eine möglichst kleine Angriffsfläche<br />
bietet. Aber während die Assistenten Rollen hinzufügen und Features hinzufügen Ports in der<br />
Firewall öffnen, können Sie in diesen Assistenten die Zugriffe nicht auf bestimmte Hosts<br />
einschränken. <strong>Die</strong> Assistenten schließen die Ports auch nicht wieder, wenn Sie eine Rolle<br />
entfernen. Sie installieren lediglich die Rollen/Features, konfigurieren die benötigten <strong>Die</strong>nste<br />
und andere Einstellungen und öffnen die verwendeten Ports für alle im Netzwerk. Um die<br />
<strong>Sicherheit</strong> zu erhöhen, müssen Sie die Firewall so konfigurieren, dass der Zugriff auf den<br />
<strong>Server</strong> eingeschränkt wird. Das war früher sehr schwierig und erforderte eine ausgefeilte<br />
Analyse, welche Ports für welche Computer und in welchen <strong>Die</strong>nsten geöffnet werden<br />
mussten. Dann erschien in <strong>Windows</strong> <strong>Server</strong> 2003 Service Pack 1 erstmals der <strong>Sicherheit</strong>skonfigurations-Assistent<br />
(Security Configuration Wizard, SCW).<br />
Direkt von der Quelle: Der <strong>Sicherheit</strong>skonfigurations-Assistent<br />
Der <strong>Sicherheit</strong>skonfigurations-Assistent ist ein Tool, mit dem Sie die Angriffsfläche verringern<br />
können. Es wurde erstmals für die <strong>Windows</strong> <strong>Server</strong> 2003-Familie entwickelt. Es<br />
stellt fest, welche Funktionalität für die Rolle oder Rollen eines <strong>Server</strong>s mindestens erforderlich<br />
ist, und deaktiviert die Funktionalität, die nicht gebraucht wird. Vor dem Erscheinen<br />
des SCW stammten die meisten Leitfäden zur <strong>Server</strong>konfiguration bei unseren
Der <strong>Sicherheit</strong>skonfigurations-Assistent 337<br />
Kunden aus mehreren Quellen, und sie bestanden aus umfangreichen Dokumenten. Es<br />
war für Administratoren keine leichte Aufgabe, ihre <strong>Server</strong> abhängig von der Rolle und<br />
der Umgebung des Computers optimal zu schützen. Wir entwickelten SCW als De-facto-<br />
Tool zum Formulieren einer <strong>Sicherheit</strong>srichtlinie für <strong>Windows</strong>-<strong>Server</strong>. Es erlaubt nicht<br />
nur Systemadministratoren, die Richtlinie für jede Computerrolle zu definieren, sondern<br />
unterstützt auch die Unternehmensbereitstellung dieser Richtlinien über Gruppenrichtlinien<br />
oder direkte Client/<strong>Server</strong>-Kommunikation. Alle Computerrollen, die in SCW enthalten<br />
sind, wurden von unseren Produktgruppen getestet. Sie sind außerdem erweiterbar,<br />
sodass Administratoren eigene Computerrichtlinien auf Basis der Standardvorlagen definieren<br />
können. Der <strong>Sicherheit</strong>skonfigurations-Assistent ist ein hervorragendes Tool für<br />
unsere Kunden!<br />
Lara Sosnosky, Senior Program Manager<br />
<strong>Windows</strong> Experience<br />
SCW wählt für die <strong>Server</strong>härtung einen ganz anderen Ansatz als bisherige Tools. SCW verwendet<br />
ebenfalls eine Einteilung in Rollen, um das System so zu konfigurieren, dass es die<br />
gewählten Rollen unterstützt, aber darüber hinaus so wenig Angriffsfläche wie möglich bietet.<br />
SCW hilft Ihnen nicht nur, die Firewall zu konfigurieren, er deaktiviert auch unnötige <strong>Die</strong>nste<br />
und konfiguriert einige <strong>Sicherheit</strong>seinstellungen. Und während die Assistenten Rollen hinzufügen<br />
und Features hinzufügen nur die Rollen installieren und konfigurieren können, die<br />
in <strong>Windows</strong> integriert sind, ist SCW flexibel erweiterbar. Ein Entwickler oder Administrator<br />
kann eine benutzerdefinierte Rollen- und/oder Featurekonfigurationsdatei schreiben und<br />
dann beliebige Produkte mit dem SCW konfigurieren.<br />
Sie können sich die Assistenten Rollen hinzufügen und Features hinzufügen als Tools vorstellen,<br />
die einen Standardserver so konfigurieren, dass er auf sichere Weise die von Ihnen<br />
gewünschten Rollen und Features unterstützt. Der SCW ist dagegen ein Tool, das Ihren <strong>Server</strong><br />
so konfiguriert, dass er ausschließlich die von Ihnen ausgewählten Rollen und Features<br />
unterstützt. SCW hat auch eine pädagogische Wirkung, weil er Ihnen hilft, besser zu verstehen,<br />
wie der <strong>Server</strong> konfiguriert ist. Daher empfehle ich Ihnen dringend, den SCW auszuführen,<br />
sobald Sie den <strong>Server</strong> mit den vorgesehenen Rollen und Features konfiguriert haben.<br />
Überwachen und Verbessern der <strong>Sicherheit</strong> aller <strong>Server</strong>rollen mit dem SCW<br />
SCW sollte ausgeführt werden, sobald Sie alle Rollen und Features installiert haben, die für<br />
den <strong>Server</strong> vorgesehen sind. Um zu demonstrieren, wie der SCW arbeitet, habe ich einen<br />
<strong>Server</strong> mit folgenden Rollen und Features konfiguriert:<br />
Rollen<br />
Anwendungsserver<br />
DNS-<strong>Server</strong><br />
Webserver (IIS)<br />
Features<br />
.NET Framework 3.0-Features<br />
<strong>Windows</strong>-Prozessaktivierungsdienst<br />
Offensichtlich ist das keine besonders logische Kombination von Rollen und Features, aber<br />
sie soll ja auch nur demonstrieren, wie die Tools arbeiten. Den SCW können Sie im Menü
338 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Verwaltung mit dem Befehl <strong>Sicherheit</strong>skonfigurations-Assistent starten. Daraufhin bekommen<br />
Sie die Seite aus Abbildung 12.8 angezeigt.<br />
Abbildung 12.8 Der SCW fragt erst einmal, welchen Vorgang Sie durchführen wollen<br />
Im ersten Schritt wählen Sie aus, ob Sie eine neue <strong>Sicherheit</strong>srichtlinie erstellen, eine vorhandene<br />
Richtlinie bearbeiten oder anwenden oder die vorherige Richtlinie wiederherstellen<br />
wollen, sodass das System auf die ursprünglichen Einstellungen zurückgesetzt wird. <strong>Die</strong><br />
Optionen sind eigentlich selbsterklärend. Wenn Sie Neue <strong>Sicherheit</strong>srichtlinie erstellen wählen,<br />
erstellt der SCW eine neue Richtlinie, wobei er einen Computer als Vorlage hernimmt,<br />
die festlegt, was die Richtlinie unterstützen muss. Er analysiert dann den Computer, stellt<br />
fest, welche Features und Rollen er unterstützt, und stellt sicher, dass diese Features und<br />
Rollen funktionieren, aber unnötige Features nicht unterstützt werden. Denken Sie immer<br />
daran, dass der SCW nach diesem Prototypansatz arbeitet. Sie sollten den Computer daher<br />
so konfigurieren, dass er das tut, was Sie von ihm wollen, bevor Sie den SCW starten. Der<br />
SCW soll Ihren Computer sicher für die Rollen konfigurieren, die Sie ausgewählt haben.<br />
Er installiert keine Rollen für Sie.<br />
Sie können eine Richtlinie auf einem System erstellen und dann auf mehrere Systeme anwenden.<br />
Falls Sie ein Netzwerk mit vielen Systemen aufbauen, empfiehlt es sich, Hostklassen<br />
zu definieren, die separat konfiguriert werden. Dann können Sie eine Richtlinie erstellen,<br />
die ein System als Prototyp verwendet, und die Richtlinie ohne oder mit geringen Änderungen<br />
auf die anderen Systeme anwenden.<br />
Wenn Sie auf Weiter klicken, fragt der SCW, welchen Computer Sie als Basis oder Prototyp<br />
für die neue Richtlinie verwenden wollen. Normalerweise wählen Sie hier den lokalen<br />
Computer, aber Sie können auch einen Remotecomputer verwenden. Während der Analysephase<br />
listet der SCW auf, welche Rollen und Features installiert sind, und vergleicht sie mit<br />
einer Datenbank der Rollen und Features. <strong>Die</strong> Datenbank enthält Informationen darüber,<br />
welche <strong>Die</strong>nste von jeder Rolle und jedem Feature benutzt werden, welche Netzwerkports<br />
sie brauchen und andere Konfigurationsinformationen. Sobald die Analyse abgeschlossen
Der <strong>Sicherheit</strong>skonfigurations-Assistent 339<br />
ist, können Sie auf Konfigurationsdatenbank anzeigen klicken (Abbildung 12.9) und sich<br />
ansehen, was der SCW herausgefunden hat. <strong>Die</strong>s ist eine schreibgeschützte Ansicht, die Sie<br />
nicht ändern können, aber Sie liefert eine Fülle von Informationen über die Konfiguration<br />
des Computers.<br />
Abbildung 12.9 Sobald der SCW Ihren Computer analysiert hat,<br />
können Sie sich die Konfigurationsdatenbank ansehen<br />
Wenn Sie auf Weiter klicken, gelangen Sie in den ersten der vier Abschnitte im SCW, Rollenbasierte<br />
<strong>Die</strong>nstkonfiguration (Abbildung 12.10.) Hier entscheiden oder bestätigen Sie,<br />
welche Rollen Ihr <strong>Server</strong> unterstützen soll. <strong>Die</strong> Antworten, die Sie in diesem Abschnitt eingeben,<br />
sind sehr wichtig, weil sie steuern, was Sie später im Netzwerkabschnitt angezeigt<br />
bekommen. <strong>Die</strong> Erkennungslogik ist aber recht gut und normalerweise ist der richtige Satz<br />
von Rollen ausgewählt. Beachten Sie auch, dass Sie in der Standardeinstellung die Ansicht<br />
Installierte Rollen angezeigt bekommen. Das sind die Rollen, die der <strong>Server</strong> in seiner<br />
momentanen Konfiguration unterstützen kann. Sie können sich auch alle Rollen anzeigen<br />
lassen, indem Sie in der Dropdownliste den Eintrag Alle Rollen auswählen.<br />
In Abbildung 12.11 fällt Ihnen wahrscheinlich auf, dass die Rollen, die im SCW angezeigt<br />
werden, etwas anders aussehen als in den anderen Rollentools. <strong>Die</strong> Rollen, die Sie im Assistenten<br />
"Rollen hinzufügen" installieren können, finden Sie zum größten Teil wieder, aber es<br />
gibt etliche zusätzliche, und einige fehlen auch. Zum Beispiel ist die Rolle Anwendungsserver,<br />
die wir für das Beispiel ausgewählt haben, nicht vorhanden. Der SCW verwendet nämlich<br />
eine etwas andere Rolleneinteilung als der Assistent "Rollen hinzufügen". <strong>Die</strong>se Diskrepanz<br />
in der Rolleneinteilung ist recht verwirrend und gewöhnungsbedürftig. Auch andere<br />
Programme, die Sie installieren, fügen unter Umständen Rollen und Features zum SCW<br />
hinzu. Falls Sie Ihre eigenen Rollen- und Featuredefinition schreiben wollen, informieren<br />
Sie sich im Dokument »Extending the Security Configuration Wizard« unter<br />
http://www.microsoft.com/downloads/details.aspx?FamilyID=903fd496-9eb9-4a45-aa00-<br />
3f2f20fd6171&DisplayLang=en.
340 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
Abbildung 12.10 Jeder Abschnitt im SCW wird mit einer Seite<br />
eingeleitet, die erklärt, was Sie in diesem Abschnitt tun<br />
Abbildung 12.11 Im SCW wählen Sie aus, welche Rollen Ihr <strong>Server</strong> unterstützen soll<br />
Nach der Rollenkonfiguration wählen Sie aus, welche Clientfeatures Sie unterstützen wollen.<br />
Der Featuresatz ist dem weiter oben erwähnten Assistenten "Features hinzufügen" ähnlich,<br />
aber nicht mit ihm identisch. Im SCW sind weniger Features aufgeführt. Auch hier gilt,<br />
dass die Features anders untergliedert sind und dass sich der SCW erweitern lässt. Wie Sie<br />
in Abbildung 12.12 sehen, ist ein »Feature« im SCW etwas, das der Computer tut, während<br />
er als Client agiert. Dagegen ist eine »Rolle« etwas, das er tut, wenn er als <strong>Server</strong> agiert.
Abbildung 12.12 Im SCW ist ein »Feature« immer ein Clientfeature<br />
Der <strong>Sicherheit</strong>skonfigurations-Assistent 341<br />
Das ist ein anderes Schema als in den anderen Tools, wo eine Rolle eine Sammlung von<br />
<strong>Die</strong>nsten ist, Features als eine Einheit definiert sind und ein Feature etwas ist, das Rollen<br />
unterstützt. <strong>Die</strong> beiden unterschiedlichen Definitionen für denselben Begriff führen leider<br />
immer wieder zu Verwirrung.<br />
Normalerweise haben Sie auf der Seite aus Abbildung 12.11 bereits den richtigen Satz von<br />
Rollen ausgewählt. Überprüfen Sie, ob die Analyse das erwartete Ergebnis geliefert hat. Ist<br />
das nicht der Fall, müssen Sie prüfen, ob die Rolle installiert wurde. Bei Bedarf müssen Sie<br />
die fehlende Rolle installieren und dann den SCW erneut ausführen. Falls Sie einen Fehler<br />
machen, ist das nicht weiter schlimm. Der SCW kann die Einstellungen auf den Zustand<br />
zurücksetzen, die gültig waren, bevor Sie eine Richtlinie angewendet haben.<br />
Wenn Sie auf der Seite Clientfeatures im SCW auf Weiter klicken, können Sie Verwaltungs-<br />
und weitere Optionen auswählen (Abbildung 12.13).<br />
Eine Option ist im SCW etwas, auf das die Bezeichnung Rolle oder Feature nicht passt. Sie<br />
kann administrative Unterstützung zur Verfügung stellen oder ein einziger <strong>Die</strong>nst sein, zum<br />
Beispiel der <strong>Die</strong>nst Erkennung interaktiver <strong>Die</strong>nste. Auch hier gilt wieder, dass die Standardoptionen<br />
normalerweise richtig sein dürften. Sehen Sie sich aber auch die Dropdownliste<br />
an. Sie führt Optionen auf, die für die Rollen und Features relevant sind, die Sie vorher<br />
ausgewählt haben. Der Inhalt dieser Liste kann sich daher von Computer zu Computer<br />
unterscheiden.<br />
Auf der nächsten Seite, Nicht angegebene <strong>Die</strong>nste verwenden (Abbildung 12.14), können<br />
Sie auswählen, was mit <strong>Die</strong>nsten geschehen soll, die Sie nicht konfigurieren. <strong>Die</strong>se Option<br />
ist nur relevant, falls Sie die erstellte Richtlinie auf einen anderen Computer anwenden.<br />
Falls auf diesem Computer andere <strong>Die</strong>nste konfiguriert sind als auf dem, auf dem Sie die<br />
Richtlinie erstellen, muss der SCW wissen, was er mit diesen <strong>Die</strong>nsten tun soll. Eine Option<br />
ist, sie unverändert zu lassen, dies ist die Standardeinstellung. <strong>Die</strong> andere Option ist, sie zu<br />
deaktivieren. Das ist sicherer, kann aber dazu führen, dass etwas nicht mehr funktioniert.<br />
Falls Sie den Rat befolgen, Richtlinien nur auf <strong>Server</strong> anzuwenden, die exakt so konfiguriert
342 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
sind, wie der, auf dem Sie die Richtlinie erstellt haben, ist es egal, welche Option Sie auf<br />
dieser Seite auswählen.<br />
Abbildung 12.13 <strong>Die</strong> Seite Verwaltungs- und weitere Optionen auswählen<br />
führt weitere <strong>Die</strong>nste und Features auf<br />
Abbildung 12.14 Auf der Seite Nicht angegebene <strong>Die</strong>nste verwenden legen Sie fest,<br />
wie <strong>Die</strong>nste behandelt werden, die nicht in der SCW-Datenbank beschrieben sind<br />
Damit ist der Rollenkonfigurationsabschnitt im SCW abgeschlossen. Der Assistent listet auf,<br />
welche Einstellungen Sie vorgenommen haben. Wie Sie in Abbildung 12.15 sehen, verringern<br />
Sie die Angriffsfläche des Computers recht deutlich, selbst wenn Sie sich einfach mit
Der <strong>Sicherheit</strong>skonfigurations-Assistent 343<br />
Weiter durch die Seiten geklickt haben. Weil dieser Computer zum Beispiel kein Druckserver<br />
ist und keine Drucker installiert hat, gibt es keinen Grund, den <strong>Die</strong>nst Druckwarteschlange<br />
zu installieren. Der SCW deaktiviert alle <strong>Die</strong>nste, die nicht benötigt werden. Auf<br />
unserem Testserver deaktiviert SCW 17 <strong>Die</strong>nste, die den Starttyp Automatisch hatten, und<br />
deaktiviert 42 <strong>Die</strong>nste, die vorher den Starttyp Manuell hatten. <strong>Die</strong> Ergebnisse bei Ihrem<br />
Computer dürften natürlich etwas anders aussehen, je nachdem, wie Ihr <strong>Server</strong> konfiguriert<br />
ist, aber der SCW ermöglicht Ihnen offensichtlich, recht einfach eine Richtlinie auf Ihre<br />
spezifischen <strong>Server</strong> zuzuschneidern.<br />
Abbildung 12.15 Am Ende jedes Abschnitts listet der SCW auf,<br />
was Sie in diesem Abschnitt geändert haben<br />
Sie kommen jetzt zum wahrscheinlich wichtigsten Abschnitt im SCW: Netzwerksicherheit.<br />
Nach der Einführungsseite bekommen Sie die Seite aus Abbildung 12.16 angezeigt, die alle<br />
Firewallregeln auflistet, die SCW vorschlägt. <strong>Die</strong> vorgeschlagenen Regeln basieren auf der<br />
Rollenunterstützung, die Sie auf den vorherigen Seiten ausgewählt haben. Falls Sie keine<br />
weitere Konfiguration im Netzwerkabschnitt vornehmen, stellt der SCW Firewallregeln zusammen,<br />
die alle Netzwerkschnittstellen so blockieren, dass nur diese Rollen und Features<br />
unterstützt werden, aber alle Clients darauf zugreifen können. In Kapitel 14 sehen wir uns<br />
an, wie Sie diese Angriffsfläche mithilfe der Gefahrenmodellierung minimieren können. Der<br />
SCW ist ein wertvolles Werkzeug bei diesem Prozess.<br />
Sie können Einschränkungen für die vorgeschlagenen Regeln konfigurieren, indem Sie eine<br />
Regel auswählen und auf die Schaltfläche Bearbeiten klicken. Daraufhin öffnet sich das<br />
Dialogfeld aus Abbildung 12.17. Auf den vier Registerkarten können Sie weitere Einschränkungen<br />
für die Netzwerkregel definieren. Zum Beispiel können Sie IPsec-Authentifizierung<br />
verpflichtend machen, wie in Abbildung 12.17 gezeigt. In diesem Fall können Sie auch den<br />
Port an bestimmte Endpunkte binden. Falls Sie zum Beispiel Remoteverwaltung nur von<br />
bestimmten Hosts aus erlauben wollen, können Sie dies mit SCW konfigurieren.<br />
<strong>Die</strong>se Fähigkeit, Regeln auf Basis der ausgewählten Rollen zu erstellen, erfüllt zwei wichtige<br />
Aufgaben. Erstens ist es eine hervorragende Möglichkeit zu erfahren, was Ihre <strong>Server</strong>
344 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
tun. Sie brauchen einen <strong>Server</strong> dazu nicht einmal fertig zu konfigurieren. Führen Sie einfach<br />
den Assistenten aus, nehmen Sie unterschiedliche Einstellungen vor und sehen Sie sich an,<br />
wie sie sich auf die Optionen in den späteren Seiten auswirken. Zweitens können Sie das sehr<br />
abstrakte Konzept eines Ports mit dem wesentlich realistischeren Konzept eines <strong>Die</strong>nstes<br />
verknüpfen und Netzwerkeinschränkungen anhand der Aufgaben konfigurieren, die das<br />
System tatsächlich erfüllt. Wenn Sie dies sorgfältig machen, können Sie eine sehr strikte<br />
Konfiguration für Ihre <strong>Server</strong> erstellen. Im Netzwerkabschnitt des SCW sollten Sie zweifellos<br />
am meisten Zeit verbringen, während Sie die <strong>Sicherheit</strong>srichtlinie Ihrer <strong>Server</strong> zusammenstellen.<br />
Abbildung 12.16 Der Abschnitt Netzwerksicherheit enthält eine Liste<br />
aller Regeln, die SCW als erforderlich vorschlägt<br />
Abbildung 12.17 Sie können im SCW Firewall- und IPsec-Regeln<br />
definieren, ohne den Assistenten zu verlassen
Der <strong>Sicherheit</strong>skonfigurations-Assistent 345<br />
In den übrigen Abschnitten des SCW können Sie Überwachung und einige Registrierungseinstellungen<br />
konfigurieren. Im Allgemeinen reichen die Standardeinstellungen bei diesen<br />
Parametern für die meisten Organisationen aus. Sofern Sie keine speziellen Anforderungen<br />
haben, brauchen Sie hier nicht viel zu tun. <strong>Die</strong> Rollen- und Firewalleinstellungen sind bei<br />
Weitem die wichtigsten.<br />
Wenn Sie Ihre Richtlinie erstellt haben, können Sie sie speichern und auf diesen Computer<br />
oder andere Computer anwenden. Sie können Ihre Richtlinie auch mit dem Befehl scwcmd.exe<br />
/transform in ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) umwandeln. Falls<br />
Sie allerdings computerspezifische Einstellungen in der Richtlinie haben, verläuft das unter<br />
Umständen nicht erfolgreich <strong>–</strong> möglicherweise erhalten Sie auch nur sehr seltsame Ergebnisse.<br />
Falls Sie zum Beispiel im Netzwerkabschnitt Endpunkteinschränkungen erstellen, die<br />
lokale Adapter betreffen, gilt die Richtlinie als computerspezifisch und lässt sich nicht erfolgreich<br />
konvertieren. SCW lässt sich viel besser für einzelne <strong>Server</strong> einsetzen, und es ist<br />
ein hervorragendes Lernmittel. In großen <strong>Server</strong>farmen können Sie SCW einsetzen, um sich<br />
über die Computer zu informieren und eine grundlegende Richtlinie zu entwickeln. Dann<br />
nehmen Sie diese Richtlinie und erstellen Sie neu, sodass sie mit dem Tool angewendet<br />
werden kann, das Sie für die Konfiguration Ihrer <strong>Server</strong> einsetzen, zum Beispiel Gruppenrichtlinien<br />
oder ein EMS (Enterprise Management System) wie Microsoft Systems Center.<br />
Direkt von der Quelle: Leichen im SCW-Keller<br />
Zu jedem Produkt gibt es einige Anekdoten von seiner Entwicklung zu berichten. Bei<br />
SCW ist das nicht anders. Hier sind ein paar:<br />
Der ursprüngliche Codename für SCW war »Secure <strong>Server</strong> Roles« (Sichere <strong>Server</strong>rollen).<br />
<strong>Die</strong>ser Name ist noch nicht völlig in der Versenkung verschwunden. Wenn Sie<br />
dcomcnfg.exe ausführen und den Knoten DCOM-Konfiguration aufklappen, sehen Sie<br />
eine Klasse namens Ssr DCOM Back-end classes.<br />
Wenn Sie sich die TCP/IP-Eigenschaften dieser Klasse ansehen, stellen Sie fest, dass<br />
die SSR-DCOM-Komponente einen fest einprogrammierten Port überwacht, wenn sie<br />
aktiviert ist: 64129. <strong>Die</strong>se Portnummer leitet sich von meinem Geburtsdatum ab, dem<br />
29. Oktober 1964. Ich sagte den Entwicklern, sie sollten irgendeine Portnummer wählen,<br />
die sie wollten, solange sie vorübergehend war und eine Websuche nichts lieferte,<br />
das diese Nummer benutzte. Das kam dabei heraus!<br />
SCW wurde beinahe SPW getauft, für »Security Policy Wizard« (<strong>Sicherheit</strong>srichtlinien-Assistent),<br />
um seine Aufgabe als Richtlinienerstellungstool zu unterstreichen.<br />
Ein anderer Namensvorschlag war FSW für »Firewall and Service Wizard« (Firewall-<br />
und <strong>Die</strong>nstassistent).<br />
Ursprünglich hatten wir keinen Verantwortlichen für die Benutzeroberfläche von<br />
SCW. Erst als ich meine eigenen Entwürfe für die Benutzeroberfläche präsentierte,<br />
kam Bewegung in die Sache und die Stelle wurde bewilligt.<br />
Der UI-Designer erfand ein neues Steuerelement für den Assistenten. Das Konzept<br />
stammte aus dem Web. Den nach rechts zeigenden Pfeil (>) bekommen Sie in anderen<br />
<strong>Windows</strong>-Anwendungen nicht zu sehen.<br />
Kirk Soluk, ursprünglicher SCW Program Manager,<br />
derzeit Senior University Security Analyst, University of Michigan
346 Kapitel 12: Schützen von <strong>Server</strong>rollen<br />
<strong>Server</strong> mit mehreren Rollen<br />
Bevor wird das Kapitel abschließen, sollte ich noch einige Punkte zu <strong>Server</strong>n mit mehreren<br />
Rollen (engl. multi-role server) anmerken. <strong>Die</strong>s sind <strong>Server</strong>, die mehr als eine Rolle unterstützen.<br />
Zum Beispiel ist ein DNS-<strong>Server</strong>, der auch ein Active Directory-Domänencontroller<br />
ist, ein <strong>Server</strong> mit mehreren Rollen. In Fällen wie diesem Beispiel sind <strong>Server</strong> mit mehreren<br />
Rollen akzeptabel und werden sogar empfohlen. Generell verringen <strong>Server</strong> mit mehreren<br />
Rollen die erzielbare <strong>Sicherheit</strong>, daher wird davon abgeraten, sie einzusetzen. Bei einem<br />
<strong>Server</strong> mit mehreren Rollen wird die Verwaltung komplexer, weil Sie berücksichtigen müssen,<br />
wie jede Rolle sich beim Vorhandensein anderer Rollen verhält. Unter Umständen ist es<br />
daher aufwendiger, den <strong>Server</strong> auf dem neuesten Stand zu halten. Sie stellen möglicherweise<br />
fest, dass bestimmte dringend empfohlene <strong>Sicherheit</strong>seinstellungen für eine Rolle nicht<br />
funktionieren, falls eine andere Rolle vorhanden ist. Aus diesem Grund sollten Sie, falls<br />
irgend möglich, <strong>Server</strong> mit mehreren Rollen vermeiden. Im Vergleich zu den Aufräumkosten<br />
nach einem Einbruch, der einfacheren Konfiguration und den niedrigeren Verwaltungskosten<br />
sind eine Handvoll zusätzlicher <strong>Server</strong> oder virtualisierter <strong>Server</strong> relativ billig.<br />
Es gibt zwei wichtige Ausnahmen von dieser Regel: <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong><br />
und <strong>Windows</strong> Essential Business <strong>Server</strong>, die <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Edition für kleinere<br />
Unternehmen. Beides sind <strong>Server</strong> mit mehreren Rollen, die daher Kompromisse beim Thema<br />
<strong>Sicherheit</strong> eingehen. Allerdings müssen diese Nachteile im Kontext ihrer Bereitstellungsszenarien<br />
bewertet werden. Sie wurden für Organisationen ohne große IT-Abteilungen entworfen,<br />
deren Personal über keine umfangreichen Kenntnisse in den Bereichen <strong>Server</strong>verwaltung<br />
und <strong>Sicherheit</strong> verfügt. Es wäre natürlich möglich, ein Netzwerk mit mehreren<br />
<strong>Server</strong>n aufzubauen, die dieselben Funktionen wie <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong><br />
übernehmen, aber das würde die Kompetenz der IT-Zuständigen in kleinen Unternehmen<br />
überfordern (ganz zu schweigen von ihrem Budget). Und gäbe es diese Produkte nicht, würden<br />
diese Organisationen versuchen, dieselben <strong>Die</strong>nste in Eigenregie auf einem oder wenigen<br />
<strong>Server</strong>n zusammenzufassen. Das Ergebnis wäre fast immer viel unsicherer als die vorgefertigte<br />
Konfiguration von <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Essential<br />
Business <strong>Server</strong>. In einem Fall brauchte ein Consultant drei Tage, um Microsoft Exchange<br />
<strong>Server</strong> so zu konfigurieren, dass es auf einem einzelnen Computer läuft, und das gelang ihm<br />
auch erst, als er <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> als Vorbild untersuchen konnte. Für<br />
ihre Zielgruppen füllen <strong>Server</strong> mit mehreren Rollen eine wichtige Lücke. Wenn Sie alle<br />
diese Faktoren berücksichtigen, füllen <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong><br />
Essential Business <strong>Server</strong> eine wichtige Marktnische, auch wenn sie Kompromisse im Bereich<br />
der <strong>Sicherheit</strong> eingehen.<br />
Zusammenfassung<br />
<strong>Die</strong> nach Rollen untergliederte <strong>Server</strong>verwaltung ist heutzutage eines der wichtigsten Konzepte<br />
im Bereich der <strong>Sicherheit</strong>. Moderne <strong>Server</strong> sind viel zu komplex für den normalen Administrator,<br />
und die Interaktionen und Abhängigkeiten zwischen den verschiedenen <strong>Die</strong>nsten<br />
und Features sind so schwer zu durchschauen und zu modellieren, dass eine simplere Abstraktion<br />
gebraucht wird. Rollenbasierte Verwaltung bietet genau das. Sie erlaubt es, uns auf<br />
eine kleine Zahl von Rollen zu konzentrieren, statt uns mit über 100 <strong>Die</strong>nsten auseinandersetzen<br />
zu müssen. Entscheidungen können auf dieser Abstraktionsebene getroffen werden.<br />
Bei Bedarf können wir aber auch eine Ebene tiefer gehen und die <strong>Die</strong>nste einzeln verwalten.
Zusammenfassung 347<br />
Der Begriff »Rolle« ist leider nicht allzu eindeutig, was Sie daran sehen können, dass die<br />
Assistenten Rollen hinzufügen und Features hinzufügen andere Rollen- und Featuredefinitionen<br />
verwenden als der SCW. Der Begriff kann für unterschiedliche Leute unterschiedliche<br />
Bedeutung haben. Das macht die Verwaltung etwas schwieriger, aber immer noch viel einfacher,<br />
als sie ohne Rollen wäre.
K A P I T E L 1 3<br />
Patchverwaltung<br />
Von Brian M. Lich<br />
In diesem Kapitel:<br />
<strong>Die</strong> vier Phasen der Patchverwaltung ...................................... 349<br />
Der Aufbau eines <strong>Sicherheit</strong>supdates ...................................... 356<br />
Tools für Ihr Patchverwaltungsarsenal ..................................... 358<br />
Zusammenfassung .................................................. 376<br />
Weitere Informationen ................................................ 376<br />
Patchverwaltung ist der Prozess, bei dem Softwareupdates auf Computern in Ihrem Netzwerk<br />
bereitgestellt werden. Softwareupdates können viele Bereiche betreffen, zum Beispiel<br />
Leistung, Zuverlässigkeit und <strong>Sicherheit</strong>. Es ist wichtig, dass Sie eine Patchverwaltungsstrategie<br />
entwerfen, um sicherzustellen, dass Updates innerhalb akzeptabler Zeiträume bereitgestellt<br />
werden und dabei möglichst wenig oder keine negativen Auswirkungen auf Ihren Geschäftsbetrieb<br />
auftreten.<br />
In diesem Kapitel sehen wir uns an, welche vier Phasen Sie bei der Entwicklung Ihrer<br />
Patchverwaltungsstrategie durcharbeiten müssen. Nach einem Überblick über die Patchverwaltung<br />
sehen wir uns einige der <strong>Die</strong>nste und Produkte an, die Microsoft zur Verfügung<br />
stellt, damit Sie Computer identifizieren können, auf denen die erforderlichen Updates nicht<br />
installiert sind. Dazu gehören das Microsoft Download Center, Microsoft Update-Katalog,<br />
<strong>Windows</strong> Update (WU), Automatische Updates (AU), Microsoft Security Baseline Analyzer<br />
(MBSA), <strong>Windows</strong> <strong>Server</strong> Update Services (WSUS) und System Center Essentials 2007.<br />
Hinweis <strong>Die</strong> meisten der in diesem Kapitel genannten Informationsquellen stehen nur auf Englisch zur<br />
Verfügung.<br />
<strong>Die</strong> vier Phasen der Patchverwaltung<br />
Patchverwaltung hat vier Phasen, wie in Abbildung 13.1 gezeigt. Wenn Sie jede Phase einzeln<br />
analysieren, kann Ihnen das beim Entwickeln Ihrer Patchverwaltungsstrategie helfen.<br />
<strong>Die</strong> folgende Liste gibt einen Überblick über jede Phase. Ausführliche Erklärungen zu den<br />
einzelnen Phasen folgen in den nächsten Abschnitten.<br />
Phase 1: Bewerten <strong>Die</strong> Bewertungsphase dient dazu, Informationen über die Computer<br />
in Ihrem Netzwerk zu sammeln, Richtlinien und Prozeduren zum Festlegen von<br />
<strong>Sicherheit</strong>sstandards in Ihrer Organisation zu beurteilen (oder zu erstellen, falls nötig)<br />
und zu entscheiden, mit welcher Infrastruktur Updates verwaltet und bereitgestellt werden.<br />
Phase 2: Identifizieren <strong>Die</strong> Identifizierungsphase ist der Prozess, bei dem Sie über<br />
neue Updates benachrichtigt werden, sobald sie freigegeben werden. Nach dieser<br />
349
350 Kapitel 13: Patchverwaltung<br />
Benachrichtigung prüfen Sie, ob das Update für die Computertypen in Ihrem Netzwerk<br />
relevant ist, und legen die Priorität fest (innerhalb Ihres Änderungsverwaltungsprozesses),<br />
mit der das Update auf Computern in Ihrem Produktivnetzwerk bereitgestellt werden<br />
soll.<br />
Phase 3: Auswerten und Planen In der Auswertungs- und Planungsphase treffen Sie<br />
die letzte Entscheidung, wie und wann das Update bereitgestellt wird. <strong>Die</strong>se Phase umfasst<br />
auch ausreichende Tests in einer separaten Umgebung, um sicherzustellen, dass das<br />
Update keine negativen Auswirkungen auf irgendwelche unternehmenskritischen Anwendungen<br />
hat.<br />
Phase 4: Bereitstellen <strong>Die</strong> Bereitstellungsphase ist die letzte Phase, in der das Update<br />
auf Computern im Netzwerk Ihrer Organisation bereitgestellt wird. <strong>Die</strong>se Phase entscheidet<br />
über den Erfolg der Bereitstellung, darin wird unter anderem geprüft, ob das<br />
Update tatsächlich erfolgreich installiert wurde.<br />
Abbildung 13.1 <strong>Die</strong> vier Phasen der Patchverwaltung<br />
Phase 1: Bewerten<br />
Das Ziel dieser Phase besteht darin, den aktuellen Zustand Ihrer Organisation zu ermitteln<br />
und Lücken zu identifizieren, die durch Ihre Patchverwaltungsstrategie geschlossen werden<br />
müssen.<br />
Zuerst müssen Sie detaillierte Informationen über die Computer in Ihrem Netzwerk sammeln.<br />
Das Inventar sollte Informationen über Hardwarekonfiguration, Betriebssystemversion und<br />
alle auf dem Computer installierten Anwendungen umfassen. Wenn ein neues Update freigegeben<br />
wird, helfen Ihnen diese Informationen, schnell festzustellen, ob ein Update für<br />
Ihre Organisation von Bedeutung ist. In großen Organisationen kann es schwierig sein, das<br />
Inventar aller Computer immer auf dem aktuellen Stand zu halten, weil sich diese Liste<br />
ständig verändert. Stattdessen können Sie Computer in Form von Klassen zu logischen<br />
Gruppen zusammenfassen und Updates entsprechend der jeweiligen Klasse bereitstellen.<br />
Zum Beispiel könnte die Klasse »IIS-Webserver« (Internet Information Services, Internetinformationsdienste)<br />
alle IIS-Webserver in Ihrer Organisation umfassen. Wenn ein IIS-Update<br />
herausgegeben wird, können Sie sich bei Ihrer Patchverwaltung auf diese Klasse von
<strong>Die</strong> vier Phasen der Patchverwaltung 351<br />
Computern konzentrieren. Genauso können Sie für Apache-Webserver, Datei- und Druckserver,<br />
Domänencontroller und so weiter vorgehen.<br />
Hinweis Sie können System Center Essentials 2007 verwenden, um Inventardaten zu sammeln. Weitere<br />
Informationen über die System Center-Produktfamilie finden Sie unter http://www.microsoft.com/system<br />
center.<br />
Prüfen Sie anschließend die <strong>Sicherheit</strong>sstandards Ihrer Organisation und stellen Sie fest, ob<br />
sie auf dem aktuellen Stand sind. Falls sie veraltet (oder gar nicht vorhanden) sind, müssen<br />
Sie diese Phase nutzen, um diese Richtlinien und Prozeduren zu formalisieren und an alle<br />
Benutzer innerhalb Ihrer Organisation zu verteilen. Nehmen Sie darin Elemente wie zum<br />
Beispiel Standards für starke Kennwörter, Anwendungssicherheitseinstellungen, Betriebssystemsicherheitseinstellungen<br />
und so weiter auf. Wenn die Richtlinien und Prozeduren<br />
definiert sind, sollten sie mit automatisierten Tools durchgesetzt werden, die erkennen, falls<br />
ein Computer die Anforderungen nicht mehr erfüllt. Wenn das passiert, sollte der Besitzer<br />
benachrichtigt und aufgefordert werden, das Problem zu beseitigen.<br />
Der letzte Schritt in der Bewertungsphase besteht darin, sich Ihre aktuelle Infrastruktur<br />
anzusehen und festzustellen, welche Produkte für Ihre Organisation am nützlichsten sind.<br />
Es gibt verschiedene Produkte, die auf unterschiedliche Unternehmensanforderungen zugeschnitten<br />
sind. Im Abschnitt »Tools für Ihr Patchverwaltungsarsenal« weiter unten in diesem<br />
Kapitel stelle ich einige Angebote von Microsoft vor.<br />
Phase 2: Identifizieren<br />
Sie haben die Auswahl zwischen mehreren Benachrichtigungsmethoden, um herauszufinden,<br />
dass ein neues <strong>Sicherheit</strong>supdate herausgegeben wurde. Sie können sich über <strong>Sicherheit</strong>supdates<br />
von Microsoft benachrichtigen lassen, indem Sie die Microsoft Technical Security<br />
Notifications abonnieren. Sie können dabei zwischen E-Mail- oder RSS-Feed-Benachrichtigung<br />
wählen. <strong>Die</strong> Microsoft Technical Security Notifications liefern Ihnen frühzeitig<br />
Informationen über alle <strong>Sicherheit</strong>supdates, die im nächsten <strong>Sicherheit</strong>supdatezyklus herausgegeben<br />
werden, detaillierte <strong>technische</strong> Informationen über die <strong>Sicherheit</strong>supdates, sobald<br />
sie freigegeben wurden, und alle Advisories, die vom Microsoft Security Response Center<br />
(MSRC) veröffentlicht werden. Sie können die Microsoft Technical Security Notifications<br />
abonnieren unter http://www.microsoft.com/technet/security/bulletin/notify.mspx.<br />
Folgende Hersteller unterhalten ebenfalls Websites, auf denen Sie benachrichtigt werden,<br />
sobald neue Updates verfügbar sind:<br />
Adobe (http://www.adobe.com/support/security/)<br />
Apple (http://docs.info.apple.com/article.html?artnum=61798)<br />
Sun Microsystems (http://sunsolve.sun.com/show.do?target=patches/patch-access)<br />
Oracle (http://www.oracle.com/technology/deploy/security/alerts.htm)<br />
Mozilla Firefox (http://www.mozilla.org/security/)<br />
Apache (http://httpd.apache.org/security_report.html)<br />
<strong>Die</strong> folgenden Websites helfen Ihnen, auf dem neuesten Stand zu bleiben, was veröffentlichte<br />
<strong>Sicherheit</strong>sempfehlungen betrifft. Einige dieser Sites liefern unter Umständen frühere Vorwarnungen,<br />
weil <strong>Sicherheit</strong>slücken dort zum ersten Mal öffentlich beschrieben werden:
352 Kapitel 13: Patchverwaltung<br />
MSRC-Blog Das MSRC-Blog wird immer aktualisiert, wenn eine <strong>Sicherheit</strong>sempfehlung<br />
veröffentlicht wird. Ein Blogeintrag kann viel schneller geschrieben und veröffentlicht<br />
werden als die anderen Kommunikationsmethoden. Sie sollten diesen Blog unter<br />
http://blogs.technet.com/msrc regelmäßig besuchen.<br />
Microsoft TechNet Security Center Das TechNet Security Center ist eine Sammlung<br />
von Links, die sich darauf konzentrieren, Microsoft-Software sicher zu halten. Von hier<br />
aus gelangen Sie zu Seiten mit <strong>Sicherheit</strong>sbulletins und -Advisories, oder Sie können<br />
sich über die neuesten Updatetools, die Microsoft anbietet, und viele andere Bereiche informieren,<br />
die für IT-Experten von Interesse sind. Sie finden das Microsoft TechNet<br />
Security Center unter http://www.microsoft.com/technet/security/default.mspx.<br />
United States Computer Emergency Readiness Team (US-CERT) Das US-CERT<br />
veröffentlicht <strong>Sicherheit</strong>sempfehlungen für eine Vielzahl von Produkten, sowohl von<br />
Microsoft als auch anderen Herstellern. Sie finden diese Website unter http://www.<br />
us-cert.gov.<br />
Full Disclosure-Mailingliste Hersteller haben es zwar lieber, wenn <strong>Sicherheit</strong>sforscher<br />
mit ihnen zusammenarbeiten, um entdeckte <strong>Sicherheit</strong>slücken auf verantwortungsvolle<br />
Weise zu veröffentlichen, aber das passiert nicht immer. Stattdessen werden Details<br />
zu <strong>Sicherheit</strong>slücken (und manchmal sogar der Exploit-Code) im Internet veröffentlicht.<br />
Dadurch vergrößert sich die Bedrohung für Ihre Organisation gewaltig, weil die Angreifer<br />
genauso schnell von der Lücke erfahren wie der Hersteller, sodass noch kein <strong>Sicherheit</strong>supdate<br />
zur Verfügung steht. Es ist trotzdem wichtig, informiert zu bleiben und genauso<br />
schnell wie die Angreifer zu wissen, welche Verwundbarkeiten bekannt sind. Full<br />
Disclosure ist eine Mailingliste, die <strong>Sicherheit</strong>slücken für eine große Bandbreite von<br />
Produkten behandelt. Sie finden sie unter http://archives.neohapsis.com/archives/<br />
fulldisclosure/.<br />
Hinweis Full Disclosure verschafft Ihnen einen guten Eindruck, womit Angreifer sich beschäftigen.<br />
Vergessen Sie aber nicht, dass die Mailingliste auch viel Geschwätz enthält. Nicht alles, was in der<br />
Liste geschrieben wird, ist auch richtig.<br />
SANS Internet Storm Center Diary Im SANS Internet Storm Center Diary schreiben<br />
mehrere unterschiedliche Autoren Einträge zu den Ereignissen des Tages. <strong>Die</strong>ses »Tagebuch«<br />
ist eine gute Stelle, um sich über neue Trends zu informieren und gelegentlich<br />
Tipps zu bekommen, wie Sie Ihr Netzwerk sicherer machen können. Das SANS Internet<br />
Storm Center finden Sie unter http://isc.sans.org.<br />
Festlegen, welche <strong>Sicherheit</strong>supdates für Sie relevant sind<br />
Nicht jedes <strong>Sicherheit</strong>supdate ist für alle Organisationen relevant. Manche <strong>Sicherheit</strong>supdates<br />
betreffen nur bestimmte Komponenten und werden nur gebraucht, falls diese Komponenten<br />
installiert sind. Daher müssen Sie in der Lage sein festzustellen, ob ein <strong>Sicherheit</strong>supdate<br />
relevant ist. Sie können dazu das <strong>Sicherheit</strong>sbulletin lesen, das im <strong>Sicherheit</strong>supdate enthalten<br />
ist, und die Angaben mit Ihrem Inventar vergleichen.<br />
Jedes <strong>Sicherheit</strong>supdate wird von einem <strong>Sicherheit</strong>sbulletin begleitet. Das Bulletin liefert<br />
detaillierte Informationen über das <strong>Sicherheit</strong>supdate, untergliedert in verschiedene<br />
Abschnitte, die in Tabelle 13.1 beschrieben sind.
Tabelle 13.1 Abschnitte eines <strong>Sicherheit</strong>sbulletins<br />
Abschnitt Beschreibung<br />
Allgemeine<br />
Informationen<br />
Verwundbarkeits-<br />
informationen<br />
Update-<br />
informationen<br />
Andere<br />
Informationen<br />
<strong>Die</strong> vier Phasen der Patchverwaltung 353<br />
<strong>Die</strong>ser Abschnitt enthält eine kurze Zusammenfassung der Verwundbarkeit, eine Empfehlung,<br />
wann dieses Update angewendet werden sollte, eventuelle bekannte Probleme und eine Tabelle<br />
der Produktversionen, die von der Verwundbarkeit betroffen sind oder nicht.<br />
<strong>Die</strong>ser Abschnitt enthält alle <strong>technische</strong>n Details, die Microsoft zu dieser Verwundbarkeit veröffentlicht<br />
hat, darunter häufig gestellte Fragen, Eindämmungsfaktoren, die Ihnen helfen können, die<br />
Angriffsfläche zu verkleinern, und eventuelle provisorische Abhilfemaßnahmen, die auf Ihren<br />
Computern angewendet werden können, bis das <strong>Sicherheit</strong>supdate erfolgreich bereitgestellt<br />
wurde.<br />
<strong>Die</strong>ser Abschnitt listet die unterschiedlichen Erkennungs- und Bereitstellungstools auf, die Microsoft<br />
zur Verfügung stellt, und beschreibt, ob sie dieses <strong>Sicherheit</strong>supdate erkennen oder bereitstellen<br />
können. Außerdem listet dieser Abschnitt die unterstützten Befehlszeilenargumente auf,<br />
die einzelnen Dateien (und Dateiversionen), die bei diesem Update ersetzt werden, und die<br />
Registrierungseinträge, mit denen verfolgt werden kann, ob die Installation erfolgreich war.<br />
<strong>Die</strong>ser Abschnitt nennt <strong>Sicherheit</strong>sforscher, denen das Aufdecken der <strong>Sicherheit</strong>slücke gelungen<br />
ist, und ein Änderungsprotokoll für die Versionen des <strong>Sicherheit</strong>sbulletins selbst.<br />
Sie sollten die Informationen im <strong>Sicherheit</strong>sbulletin sorgfältig lesen und mit Ihrer Inventarliste<br />
vergleichen, um festzustellen, ob dieses <strong>Sicherheit</strong>supdate für Ihre Organisation relevant<br />
ist. Falls Sie feststellen, dass das <strong>Sicherheit</strong>supdate in Ihrer Umgebung benötigt wird,<br />
sollten Sie die Priorität für seine Installation festlegen.<br />
Festlegen der Priorität für die Installation<br />
Welche Priorität Sie für die Installation des <strong>Sicherheit</strong>supdates festlegen, hängt von der Infrastruktur<br />
Ihrer Organisation ab. Wenn Sie die Priorität bestimmen, sollten Sie alle provisorischen<br />
Lösungen untersuchen, die im <strong>Sicherheit</strong>sbulletin beschrieben sind, und überprüfen,<br />
ob Sie eine davon nutzen können, während die festgelegten Änderungsverwaltungsrichtlinien<br />
eingehalten werden. Für den Fall, dass keine der provisorischen Lösungen in Ihrer<br />
Organisation hilft und der Schweregrad des <strong>Sicherheit</strong>sbulletins als kritisch angegeben ist,<br />
sollten Sie einen Prozess vorbereitet haben, mit dem Sie die Installation eines <strong>Sicherheit</strong>supdates<br />
auf kürzestem Weg in Ihrer Produktivumgebung vornehmen können.<br />
Vorsicht Auch falls Sie sich entscheiden, ein <strong>Sicherheit</strong>supdate beschleunigt und unter Umgehung der<br />
üblichen Verfahren einzuspielen, müssen Sie ausreichende Tests durchführen, um sicherzustellen, dass<br />
das <strong>Sicherheit</strong>supdate mit Ihren kritischen Unternehmensanwendungen funktioniert. Wenn Sie das <strong>Sicherheit</strong>supdate<br />
nicht ausreichend testen, kann das Datenverlust und Produktionsausfall zur Folge haben. Wie<br />
schnell Sie ein Update bereitstellen, ist eine Risikomanagemententscheidung. Sie sollten feststellen, ob<br />
das Update wichtig genug ist, das Risiko einzugehen, dass wertvolle Computer nicht mehr richtig funktionieren,<br />
falls das Update nicht erfolgreich verläuft.<br />
Phase 3: Auswerten und Planen<br />
<strong>Die</strong>se Phase kann in drei Teile untergliedert werden: Feststellen der erforderlichen Änderungen,<br />
die sich für die Anforderungen Ihrer Organisation am besten eignen, Planen der Bereitstellung,<br />
indem Sie potenzielle Hindernisse identifizieren, und zuletzt Entscheiden, wie das<br />
Softwareupdate innerhalb Ihrer Produktivumgebung bereitgestellt wird.
354 Kapitel 13: Patchverwaltung<br />
Der beste Ansatz, um die Verwundbarkeit einzudämmen<br />
Ihnen stehen eine Reihe unterschiedlicher Möglichkeiten zur Verfügung, wenn Sie feststellen,<br />
wie sich eine Verwundbarkeit am wirksamsten eindämmen lässt. Zum Beispiel können<br />
Sie das <strong>Sicherheit</strong>supdate bereitstellen oder die Verwundbarkeit eindämmen, indem Sie<br />
Gegenmaßnahmen anwenden, die die Angriffsfläche verkleinern.<br />
Falls die Binärdateien, die von der Verwundbarkeit betroffen sind, auf dem Computer installiert<br />
sind, ist es meist am besten, wenn Sie das <strong>Sicherheit</strong>supdate bereitstellen. Indem Sie<br />
das <strong>Sicherheit</strong>supdate bereitstellen, reparieren Sie direkt die Dateien, die für die Verwundbarkeit<br />
verantwortlich sind. Falls die Binärdateien allerdings mit einem <strong>Die</strong>nst verbunden<br />
sind, den Sie nicht verwenden, kann es sinnvoller sein, diesen <strong>Die</strong>nst einfach zu entfernen.<br />
Falls zum Beispiel IIS auf einem Computer installiert ist, Sie diesen Computer aber gar<br />
nicht als Webserver nutzen, können Sie IIS einfach deinstallieren. Dann brauchen Sie das<br />
<strong>Sicherheit</strong>supdate nicht bereitzustellen, weil die betroffenen Dateien gar nicht mehr auf dem<br />
Computer vorhanden sind. Das Anwenden von Gegenmaßnahmen sollte nur eine provisorische<br />
Lösung sein, bis Sie das <strong>Sicherheit</strong>supdate installieren. Zwei Beispiele für Gegenmaßnahmen<br />
sind das Deaktivieren von <strong>Die</strong>nsten und das Aktivieren der Internet Explorer-<br />
»Kill Bits«. Weitere Informationen über die Internet Explorer-Kill-Bits finden Sie unter<br />
http://support.microsoft.com/kb/240797. Provisorische Lösungen für ein bestimmtes <strong>Sicherheit</strong>supdate,<br />
die von Microsoft getestet und freigeben wurden, werden im Abschnitt mit den<br />
Verwundbarkeitsinformationen im entsprechenden <strong>Sicherheit</strong>sbulletin aufgeführt.<br />
Hinweis Oft kann Ihre Analyse der Priorität eines <strong>Sicherheit</strong>supdates helfen, sich für eine Eindämmungsstrategie<br />
zu entscheiden. Falls Sie zum Beispiel entschieden haben, dass ein bestimmtes <strong>Sicherheit</strong>supdate<br />
für Ihre Organisation kritisch ist, haben Sie unter Umständen nicht genug Zeit, um es ausgiebig zu<br />
testen. Wenn Sie sich die verfügbaren provisorischen Lösungen ansehen, entscheiden Sie möglicherweise,<br />
eine dieser Lösungen anzuwenden, während das <strong>Sicherheit</strong>supdate den vollständigen Testzyklus durchläuft.<br />
Stellen Sie aber auf jeden Fall sicher, dass die Analyse anhand der entsprechenden Computerklassen<br />
durchgeführt wird. Zum Beispiel ist ein Angriff, bei dem im Remotezugriff Code über QuickTime ausgeführt<br />
werden kann, für eine Arbeitsstation kritisch, aber falls sich jemand auf Ihren Domänencontrollern YouTube-<br />
Filmchen ansieht, haben Sie ein ganz anderes Problem, das Sie schleunigst angehen müssen.<br />
Planen der Bereitstellung<br />
Sobald Sie entschieden haben, wie Sie vorgehen wollen, ist der nächste Schritt das Planen<br />
der Änderungsverwaltung. Zuerst müssen Sie herausfinden, wie viele Computer von der<br />
Verwundbarkeit betroffen sind. An dieser Stelle ist das Inventar wieder sehr nützlich. Anschließend<br />
sollten Sie eventuelle Hindernisse identifizieren, die eine Bereitstellung verhindern<br />
können. Einige dieser Bereitstellungshindernisse sind zum Beispiel nicht ausreichender<br />
Festplattenplatz auf den Computern, die das <strong>Sicherheit</strong>supdate benötigen, Gruppenrichtlinienobjekte,<br />
die eine Softwareinstallation blockieren, oder Wartungsfenster im Rahmen<br />
der Änderungsverwaltung auf <strong>Server</strong>n, für die hohe Verfügbarkeitsanforderungen bestehen.<br />
Wichtig Stellen Sie sicher, dass Sie alle Wartungsfenster der Änderungsverwaltung berücksichtigen,<br />
wenn Sie die Bereitstellung von <strong>Sicherheit</strong>supdates planen.
<strong>Die</strong> vier Phasen der Patchverwaltung 355<br />
Festlegen des Bereitstellungsmechanismus<br />
Glücklicherweise haben die meisten <strong>Sicherheit</strong>supdates von Microsoft standardisierte Befehlszeilenparameter<br />
und Bereitstellungsmethoden. Das ist nützlich, wenn Sie diese <strong>Sicherheit</strong>supdates<br />
über ein Startskript der Active Directory-Domänendienste bereitstellen. <strong>Die</strong><br />
Befehlszeilenparameter werden weiter unten in diesem Kapitel beschrieben.<br />
WSUS lädt Microsoft-<strong>Sicherheit</strong>supdates automatisch auf einen internen Updateserver herunter,<br />
sodass Sie die Bereitstellung flexibler steuern können. WSUS berücksichtigt allerdings<br />
nur <strong>Sicherheit</strong>supdates, die von Microsoft herausgegeben werden.<br />
Hinweis WSUS unterstützt nur Microsoft-Produkte. Für Anwendungen anderer Hersteller sollten Sie sich<br />
System Center Essentials 2007 ansehen, mit dem Sie benutzerdefinierte Bereitstellungspakete erstellen<br />
können.<br />
Phase 4: Bereitstellen<br />
In der Bereitstellungsphase machen Sie die Änderung inklusive der konkreten Bereitstellungszeiten<br />
bekannt, testen das <strong>Sicherheit</strong>supdate auf einer kleinen Gruppe von Computern<br />
und führen dann die Bereitstellung auf allen Computern in Ihrer Organisation durch. <strong>Die</strong><br />
Bereitstellungsphase entscheidet, ob ein <strong>Sicherheit</strong>supdate ein Erfolg oder ein Fehlschlag<br />
wird.<br />
Bekanntmachen der Änderung<br />
Das Bekanntmachen der Änderung ist ein wichtiger Aspekt innerhalb der Updateverwaltung.<br />
Sie müssen sicherstellen, dass jeder, der davon unter Umständen betroffen wird, Bescheid<br />
weiß, wann das <strong>Sicherheit</strong>supdate bereitgestellt wird. Und Sie müssen einen Rücknahmeplan<br />
für den Fall entwickeln, dass die Dinge nicht verlaufen wie erwartet. Sie sollten<br />
sich die Details von den Zuständigen genehmigen lassen, zum Beispiel den Zeitpunkt, an<br />
dem das <strong>Sicherheit</strong>supdate bereitgestellt wird, und wann die Computer neu gestartet werden.<br />
Wenn Sie sich zu diesen Details nicht die Zustimmung einholen oder die Änderungen nicht<br />
ausreichend vermitteln, kann das zu Unzufriedenheit führen, was möglicherweise künftige<br />
Bereitstellungen verzögert.<br />
In großen Umgebungen ist es nicht immer möglich, die Änderung innerhalb eines überschaubaren<br />
Zeitraums bekannt zu machen. In einem solchen Fall können Sie eine Lösung<br />
über eine Serviceabteilung implementieren, die Änderungen verfolgt und die entsprechenden<br />
Leute benachrichtigt, wenn eine Änderung angefordert wird. System Center Service<br />
Manager ist ein Microsoft-Produkt, das diese Funktionalität zur Verfügung stellt. Zum Zeitpunkt,<br />
als dieses Kapitel geschrieben wurde, war dieses Produkt noch in der Betaphase, aber<br />
Sie können sich auf der Microsoft-Website unter http://www.microsoft.com/systemcenter/<br />
svcmgr/default.mspx darüber informieren.<br />
Testen des <strong>Sicherheit</strong>supdates auf einer kleinen Gruppe von Computern<br />
Alle Probleme vorherzusehen, die durch Konflikte zwischen unternehmenskritischen Anwendungen<br />
und dem <strong>Sicherheit</strong>supdate auftreten könnten, ist eine der wichtigsten Aufgaben<br />
innerhalb Ihrer gesamten Patchverwaltungsstrategie. Anwendungskompatibilitätsprobleme<br />
können Sie im Vorfeld nur herausfinden und beseitigen, indem Sie das <strong>Sicherheit</strong>supdate<br />
zusammen mit Ihren Anwendungen testen.
356 Kapitel 13: Patchverwaltung<br />
Ein Ansatz für diese Aufgabe lautet, einige Computer zur Hand zur haben, auf denen die<br />
entsprechenden Anwendungen installiert sind. Installieren Sie das <strong>Sicherheit</strong>supdate auf<br />
diesen Computern und testen Sie so viele Szenarien wie möglich. <strong>Die</strong>se Methode kann allerdings<br />
zu unerwarteten Problemen führen, falls der Mitarbeiter, der die Anwendung testet,<br />
nicht wirklich alles ausprobiert. Ein besserer Ansatz besteht darin, das <strong>Sicherheit</strong>supdate auf<br />
einer Gruppe von Computern zu installieren, die für die ganz normale Arbeit eingesetzt werden.<br />
Stellen Sie sicher, dass die Benutzer über die Installation des <strong>Sicherheit</strong>supdates auf<br />
ihren Computern informiert sind, und lassen Sie sich eventuell auftretende Probleme sofort<br />
melden. Wenn Sie mehrere Benutzer mit unterschiedlichen Aufgaben innerhalb Ihrer Organisation<br />
aussuchen, sind Ihre Chancen größer, alle Szenarien abzudecken, als wenn nur ein<br />
Grüppchen von IT-Personal die festgelegten Anwendungsfälle von Hand durchgeht. Aber<br />
selbst bei diesem Ansatz ist unwahrscheinlich, dass wirklich alle Szenarien abgedeckt werden,<br />
die getestet werden sollten.<br />
Hinweis Falls Sie Ihre <strong>Sicherheit</strong>supdates über WSUS bereitstellen, können Sie eine Testcomputergruppe<br />
einrichten, Ihre Testclientcomputer zu dieser Gruppe hinzufügen und dann die Updates ausschließlich<br />
für diese Gruppe bereitstellen.<br />
Bereitstellen des <strong>Sicherheit</strong>supdates für alle Benutzer<br />
Wenn <strong>Sicherheit</strong>supdates bereitgestellt werden, sollte dies innerhalb eines vorher geplanten<br />
Wartungsfensters geschehen. <strong>Die</strong> Änderungswartung sollte allen betroffenen Benutzern<br />
bekannt gemacht werden, damit sie darüber informiert sind, dass ein Update zu erwarten ist.<br />
Sobald dies erledigt ist, sollten Sie das <strong>Sicherheit</strong>supdate testen, bis Sie überzeugt sind, dass<br />
keine unerwarteten Probleme auftreten. Nun können Sie sich das Update von den Zuständigen<br />
genehmigen lassen. Schließlich ist der Zeitpunkt gekommen, den großen, grünen Los<br />
geht’s-Schalter zu drücken.<br />
Nach der Bereitstellung sollten Sie den Prozess mit den Zuständigen der betroffenen Abteilungen<br />
und dem IT-Management noch einmal durchgehen und feststellen, ob irgendwelche<br />
Verbesserungen oder Optimierungen an Ihrer Updateverwaltungsstrategie erforderlich sind.<br />
<strong>Die</strong> Updateverwaltung ist ein Prozess, der sich ständig weiterentwickelt und immer wieder<br />
aufs Neue überprüft werden sollte.<br />
Der Aufbau eines <strong>Sicherheit</strong>supdates<br />
Bei <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> liegen <strong>Sicherheit</strong>supdates in Form einer einzigen<br />
MSU-Datei vor. Das Paket wird über das eigenständige <strong>Windows</strong>-Updateinstallationsprogramm<br />
(<strong>Windows</strong> Update Stand-Alone Installer Process, wusa.exe) installiert. Es enthält<br />
eine Cabinet-Datei (.cab) mit dem Update, eine XML-Datei, die das Update beschreibt, und<br />
einer Eigenschaftendatei, die die vom Installer verwendeten Texte enthält. (Falls ein Paket<br />
mehrere Updates umfasst, ist für jedes Update eine eigene CAB-Datei enthalten.)<br />
Unterstützte Befehlszeilenparameter<br />
Im Unterschied zu den Vorgängerversionen der <strong>Sicherheit</strong>supdatepakete funktioniert das<br />
Befehlszeilenargument /X nicht mehr. Sie können das erweiterte Befehlszeilenprogramm<br />
verwenden, das im Betriebssystem <strong>Windows</strong> enthalten ist, oder eine Dateiarchivierungsanwendung<br />
von einem anderen Hersteller, die mit MSU-Dateien umgehen kann, zum Beispiel
Der Aufbau eines <strong>Sicherheit</strong>supdates 357<br />
7-Zip (http://www.7-zip.org/). Tabelle 13.2 beschreibt alle verfügbaren Befehlszeilenparameter,<br />
die vom eigenständigen <strong>Windows</strong>-Updateinstallationsprogramm unterstützt werden.<br />
Tabelle 13.2 Befehlszeilenparameter von wusa.exe<br />
Parameter Beschreibung<br />
/?, /help oder /h Zeigt die Befehlszeilenhilfe für das eigenständige <strong>Windows</strong>-Updateinstallationsprogramm an.<br />
/quiet Stiller Modus. Zeigt während der Installation keine Benutzeroberfläche an.<br />
/norestart Verhindert das Neustarten des Computers, sofern erforderlich.<br />
Eine praktische Neuerung beim neuen MSU-Paket ist die Möglichkeit, das <strong>Sicherheit</strong>supdate<br />
mithilfe des Paketmanagers (pkgmgr.exe) zu installieren. Das folgende Beispiel zeigt,<br />
wie das geht:<br />
Expand <strong>–</strong>F:* “%TEMP%\X86-all-windows6.0-kb941651-x86_cf2d8dd55a356b9d27b75ead67ff45c<br />
f3d2d9a14.msu” %TEMP%<br />
Pkgmgr /n:%TEMP%\<strong>Windows</strong>6.0-KB941651-x86.xml<br />
Integrieren von MSU-Dateien in eine <strong>Windows</strong>-Abbilddatei<br />
Sie können die <strong>Sicherheit</strong>supdates in ein Offlineabbild integrieren, sodass bei allen neuen<br />
Computern, bei denen dieses Abbild (engl. image) eingespielt wurde, das <strong>Sicherheit</strong>supdate<br />
bereits installiert ist. Gehen Sie folgendermaßen vor, um <strong>Sicherheit</strong>supdates in eine <strong>Windows</strong>-Abbilddatei<br />
(<strong>Windows</strong> Image, WIM) zu integrieren:<br />
Wichtig Bevor Sie diese Schritte durcharbeiten, sollten Sie das <strong>Windows</strong> Automated Installation Toolkit<br />
herunterladen und installieren, das unter http://www.microsoft.com/downloads/details.aspx?familyid=<br />
C7D4BC6D-15F3-4284-9123-679830D629F2&displaylang=en zur Verfügung steht.<br />
1. Laden Sie die MSU-Dateien herunter, die Sie in die WIM integrieren wollen. In dieser<br />
Beispielanleitung speichern wir alle Updates im Ordner %TEMP%.<br />
2. Entpacken Sie die MSU-Dateien. Wiederholen Sie diesen Schritt für jede heruntergeladene<br />
<strong>Sicherheit</strong>supdatedatei.<br />
Expand <strong>–</strong>F:* “%TEMP%\X86-all-windows6.0-kb941651-x86_cf2d8dd55a356b9d27b75ead67ff45c<br />
f3d2d9a14.msu” %TEMP%<br />
3. Stellen Sie die Abbilddatei bereit, in die Sie diese Updates integrieren wollen.<br />
Imagex /mountrw d:\imaging\vista.wim c:\mounted_images<br />
4. Fügen Sie die MSU-Dateien zur bereitgestellten Abbilddatei hinzu.<br />
Peimg /import=%TEMP%\<strong>Windows</strong>6.0-KB941651-x86.cab c:\mounted_images\mount\windows<br />
5. Installieren Sie die Pakete in der WIM-Datei.<br />
Peimg /install=*Package* c:\mounted_images\mount\windows<br />
6. Bestätigen Sie Ihre Änderungen und heben Sie die Bereitstellung der WIM-Datei auf.<br />
Imagex /unmount /commit c:\mounted_images
358 Kapitel 13: Patchverwaltung<br />
Tools für Ihr Patchverwaltungsarsenal<br />
Microsoft stellt eine Vielzahl von Produkten zur Verfügung, die Ihnen dabei helfen, <strong>Sicherheit</strong>supdates<br />
in Ihrer Organisation bereitzustellen.<br />
Microsoft Download Center<br />
Das Microsoft Download Center (http://www.microsoft.com/downloads/) ist eine Website,<br />
die ausschließlich Updates, Tools, Trialsoftware und Dokumente zur Verfügung stellt, und<br />
zwar zu fast allem. Im Bereich von <strong>Sicherheit</strong>supdates ist das Microsoft Download Center<br />
wichtig, weil Sie darin nach einem bestimmten <strong>Sicherheit</strong>supdate suchen und es herunterladen<br />
können. Sobald das Update heruntergeladen ist, können Sie es von Hand installieren,<br />
in selbstentwickelte Skripts einbauen oder für die Bereitstellung über ein Patchverwaltungssystem<br />
vorbereiten. Beispiele für VBScript- oder PowerShell-Skripts, die Ihnen bei<br />
der Bereitstellung von Updates helfen, finden Sie im Microsoft Script Repository unter<br />
http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true.<br />
Microsoft Update-Katalog<br />
Der Microsoft Update-Katalog (http://catalog.update.microsoft.com/) ist eine Website, auf<br />
der Sie praktisch alles finden, was der Microsoft Update-<strong>Die</strong>nst anbietet. <strong>Die</strong> angebotenen<br />
Downloads umfassen <strong>Sicherheit</strong>supdates, Gerätetreiberupdates, Updates für andere Microsoft-Produkte<br />
und Hotfixes, die früher nur für Kunden verfügbar waren, die sich an Microsoft<br />
Customer Service and Support (CSS) wandten. Der Microsoft Update-Katalog bietet<br />
folgende Features:<br />
Auswahlkorb Im Microsoft Update-Katalog können Sie mehrere Downloads in einen<br />
Auswahlkorb legen und dann gemeinsam herunterladen.<br />
Volltextsuche Sie können nach Schlüsselwort, Produkt, Knowledge Base-Artikelnummer,<br />
MSRC-Bulletinnummer, Gerätetreiberhersteller, Gerätetreibermodell und<br />
Gerätetreiberversion suchen.<br />
RSS-Feeds Der Microsoft Update-Katalog unterstützt RSS-Feeds (Really Simple<br />
Syndication), sodass Sie Ihre Suche in einem RSS-Feed speichern können. Sie werden<br />
benachrichtigt, wenn neue Downloads verfügbar werden, die Ihren Kriterien entsprechen.<br />
BITS-Unterstützung Der intelligente Hintergrundübertragungsdienst (Background<br />
Intelligent Transfer Service, BITS) ist ein <strong>Die</strong>nst, der die gerade von Ihnen verwendete<br />
Bandbreite überwacht und die Downloadrate entsprechend anpasst. Außerdem bietet<br />
BITS die Möglichkeit, unterbrochene Downloads fortzusetzen. Falls also Ihre Internetverbindung<br />
abbricht, wenn Sie mit einem Download halb (oder gar zu 98%) fertig sind,<br />
wird der Download an dieser Stelle fortgesetzt, sobald die Verbindung wieder verfügbar<br />
ist.<br />
<strong>Die</strong> Startseite des Microsoft Update-Katalogs sehen Sie in Abbildung 13.2.
Tools für Ihr Patchverwaltungsarsenal 359<br />
Abbildung 13.2 Sie können den Microsoft Update-Katalog durchsuchen, um alle <strong>Sicherheit</strong>supdates<br />
herunterzuladen, die vom Microsoft Update-<strong>Die</strong>nst zur Verfügung gestellt werden<br />
<strong>Windows</strong> Update und Microsoft Update<br />
<strong>Windows</strong> Update ist eine Anwendung, mit der Sie prüfen, ob Updates auf Ihrem Computer<br />
fehlen, und sie dann bei Bedarf installieren. Optional können Sie mit Microsoft Update auch<br />
Updates für das 2007 Office-System, Gerätetreiberupdates und andere Microsoft-Produkte<br />
einspielen.<br />
<strong>Sicherheit</strong>swarnung Sie müssen Mitglied der lokalen Gruppe Administratoren sein, um <strong>Windows</strong> Update<br />
auszuführen.<br />
<strong>Die</strong> Benutzeroberfläche von <strong>Windows</strong> Update sehen Sie in Abbildung 13.3.<br />
<strong>Windows</strong> Update bietet Ihnen mehrere Optionen, wenn Sie das Systemsteuerungsapplet<br />
<strong>Windows</strong> Update öffnen.<br />
Updates für weitere Produkte Wenn Sie auf diese Schaltfläche klicken, wird die<br />
Microsoft Update-Website geöffnet, sodass Sie den Microsoft Update-<strong>Die</strong>nst installieren<br />
können.
360 Kapitel 13: Patchverwaltung<br />
Nach Updates suchen Damit können Sie den <strong>Windows</strong> Update- oder Microsoft<br />
Update-<strong>Die</strong>nst nach neuen Updates abfragten, die für Ihren Computer zur Verfügung<br />
stehen.<br />
Einstellungen ändern Hier können Sie die Einstellungen für die automatischen<br />
<strong>Windows</strong>-Updates ändern (mehr dazu im nächsten Abschnitt).<br />
Updateverlauf anzeigen Zeigt Ihnen alle Updates an, die auf diesem Computer installiert<br />
sind, sowie den Status eines Updates (ob es erfolgreich installiert wurde), den Typ<br />
des Updates und den Zeitpunkt, zu dem es installiert wurde.<br />
Ausgeblendete Updates anzeigen Sie können <strong>Windows</strong> Update anweisen, Sie über<br />
bestimmte Updates nicht mehr zu informieren. Mit der Option Ausgeblendete Updates<br />
anzeigen können Sie solche Updates reaktivieren, sodass sie wieder aufgelistet werden.<br />
Updates: Häufig gestellte Fragen Öffnet die Hilfe und Support-Seite, die beschreibt,<br />
welche Änderungen an <strong>Windows</strong> Update in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
vorgenommen wurden.<br />
Abbildung 13.3 Mit <strong>Windows</strong> Update können Sie Ihren Computer auf dem neuesten Stand halten<br />
Automatische <strong>Windows</strong>-Updates<br />
Wie bereits erwähnt, wurde das Feature Automatische Updates (auch als Automatische<br />
Updates für <strong>Windows</strong> bezeichnet) in das Systemsteuerungsapplet <strong>Windows</strong> Update integriert,<br />
wo Sie die automatischen Updates konfigurieren können, indem Sie auf Einstellungen<br />
ändern klicken. Das Einstellungsfenster von Automatische Updates sehen in Abbildung<br />
13.4.<br />
<strong>Die</strong> Standardeinstellungen sehen Sie in Abbildung 13.4, sie eignen sich aber nicht für alle<br />
Organisationen. Zum Beispiel brauchen <strong>Server</strong> Hochverfügbarkeit und daher genauere<br />
Steuerungsmöglichkeiten, wann Updates installiert und der <strong>Server</strong> neu gestartet wird. In<br />
diesem Fall können Sie die automatischen Updates von Hand mit den Einstellungen in<br />
Abbildung 13.4 ausschalten oder mithilfe von Gruppenrichtlinien auf mehreren Computern<br />
deaktivieren.
Tools für Ihr Patchverwaltungsarsenal 361<br />
Abbildung 13.4 Sie können Automatische Updates für <strong>Windows</strong> so konfigurieren, dass alle<br />
<strong>Sicherheit</strong>supdates zu einer bestimmten Uhrzeit heruntergeladen und installiert werden<br />
Es gibt vier Optionen, mit denen Sie konfigurieren können, wie Updates auf Ihrem Computer<br />
heruntergeladen und installiert werden:<br />
Updates automatisch installieren Bei dieser Option werden die Updates zu dem<br />
Zeitpunkt, der im Feld Installationszeitpunkt für neue Updates angegeben ist, heruntergeladen<br />
und installiert.<br />
Updates herunterladen, aber Installation manuell durchführen Bei dieser Option<br />
werden Updates heruntergeladen und Sie werden benachrichtigt, wenn sie für die Installation<br />
bereitstehen. Sie können entscheiden, ob Sie die Updates installieren wollen oder<br />
nicht.<br />
Nach Updates suchen, aber Zeitpunkt zum Herunterladen und Installieren manuell<br />
festlegen Bei dieser Option werden Sie benachrichtigt, sobald neue Updates als Download<br />
zur Verfügung stehen. Nachdem Sie die Updates heruntergeladen haben, können Sie<br />
sie installieren.<br />
Nie nach Updates suchen Damit schalten Sie die automatischen <strong>Windows</strong>-Updates<br />
aus. Auf Clientcomputern wird diese Option nicht empfohlen. Auf <strong>Server</strong>n, wo Sie genau<br />
kontrollieren wollen, welche Updates heruntergeladen und installiert werden, kann<br />
es sinnvoll sein, diese Option auszuwählen.<br />
In der Standardeinstellung benachrichtigt die automatische <strong>Windows</strong>-Updatefunktion Sie<br />
nur, wenn neue <strong>Sicherheit</strong>supdates verfügbar sind. Sie können das Kontrollkästchen Empfohlene<br />
Updates beim Herunterladen, Installieren und bei Benachrichtigungen einschließen<br />
aktivieren, um auch empfohlene Updates mit aufzunehmen. Empfohlene Updates sind
362 Kapitel 13: Patchverwaltung<br />
Updates, die keine <strong>Sicherheit</strong>slücke schließen, aber für Ihren Computer nützlich sein könnten.<br />
Das sind zum Beispiel neue Versionen von .NET Framework, <strong>Windows</strong> Media Player oder<br />
DirectX.<br />
Wenn die Updates installiert sind, fragt Automatische Updates für <strong>Windows</strong> nach, ob Sie den<br />
Computer jetzt neu starten oder damit noch warten wollen. <strong>Die</strong>se Frage wird nur gestellt,<br />
wenn ein Neustart erforderlich ist.<br />
Microsoft Baseline Security Analyzer<br />
Der Microsoft Baseline Security Analyzer (MBSA) ist ein Tool, das Ihr Netzwerk analysiert<br />
und Sie benachrichtigt, falls bei Computern <strong>Sicherheit</strong>seinstellungen falsch konfiguriert sind<br />
oder <strong>Sicherheit</strong>supdates fehlen. MBSA 2.1 war die erste Version, die Unterstützung für <strong>Windows</strong><br />
Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> bot.<br />
Hinweis MBSA 2.1 war noch in der Betaphase, als dieses Buch geschrieben wurde. In der endgültigen<br />
Version könnten sich daher einige Details ändern. Außerdem stand die Betaversion nur in englischer Sprache<br />
zur Verfügung, von der endgültigen Version dürfte wie beim Vorgänger auch wieder eine deutsche<br />
Version angeboten werden.<br />
MBSA 2.1 steht als kostenloser Download auf der MBSA-Website unter<br />
http://www.microsoft.com/mbsa zur Verfügung.<br />
Das Startfenster von MBSA sehen Sie in Abbildung 13.5.<br />
Abbildung 13.5 Mit MBSA können Sie einen Computer oder mehrere gleichzeitig untersuchen
Tools für Ihr Patchverwaltungsarsenal 363<br />
MBSA-Analyse im interaktiven Modus<br />
Wenn Sie die Analyse im interaktiven Modus durchführen, stehen mehrere Optionen zur<br />
Verfügung (Abbildung 13.6).<br />
Abbildung 13.6 Bei der Analyse im interaktiven Modus stehen etliche Optionen zur Verfügung<br />
Vorsicht Ihr Benutzerkonto muss auf jedem Computer, den Sie untersuchen wollen, Mitglied der lokalen<br />
Gruppe Administratoren sein.<br />
Gehen Sie folgendermaßen vor, um im interaktiven Modus ausschließlich nach fehlenden<br />
<strong>Sicherheit</strong>supdates zu suchen:<br />
1. Starten Sie den Microsoft Baseline Security Analyzer. Klicken Sie im Startmenü auf Alle<br />
Programme und dann auf Microsoft <strong>Sicherheit</strong> Baseline Analyzer 2.1.<br />
2. Klicken Sie auf Scan a computer. Falls Sie mehrere Computer gleichzeitig untersuchen<br />
wollen, die Sie anhand des Domänennamens oder IP-Adressbereichs auswählen, können<br />
Sie stattdessen auf Scan multiple computers klicken.<br />
3. Geben Sie im Feld Computer name den Computer ein, den Sie untersuchen wollen. Als<br />
Standardeinstellung ist hier der lokale Computer eingetragen. Falls Sie lieber über die<br />
IP-Adresse angeben, welcher Computer untersucht werden soll, können Sie die Adresse<br />
im Feld IP address eingeben.<br />
4. Deaktivieren Sie folgende Kontrollkästchen:<br />
a. Check for <strong>Windows</strong> administrative vulnerabilities (nach administrativen <strong>Windows</strong>-<br />
Verwundbarkeiten suchen)
364 Kapitel 13: Patchverwaltung<br />
b. Check for weak passwords (nach schwachen Kennwörtern suchen)<br />
c. Check for IIS administrative vulnerabilities (nach administrativen IIS-<br />
Verwundbarkeiten suchen)<br />
d. Check for SQL administrative vulnerabilities (nach administrativen SQL <strong>Server</strong>-<br />
Verwundbarkeiten suchen)<br />
Hinweis MBSA kann noch wesentlich mehr Informationen liefern als lediglich Daten über fehlende<br />
<strong>Sicherheit</strong>supdates. Wenn Sie Analysen im Rahmen einer <strong>Sicherheit</strong>sbewertung durchführen, sollten<br />
Sie die in Schritt 4 deaktivierten Kontrollkästchen aktivieren.<br />
5. Klicken Sie auf Start scan.<br />
Sobald die Untersuchung abgeschlossen ist, wird ein Bericht angezeigt, der die Ergebnisse<br />
zusammenfasst (Abbildung 13.7).<br />
Abbildung 13.7 MBSA liefert Ihnen einen zusammenfassenden Bericht, sobald die Analyse<br />
abgeschlossen ist<br />
Tipp <strong>Die</strong> MBSA-Berichte werden in Ihrem Benutzerprofil im Ordner SecurityScans gespeichert. <strong>Die</strong>se<br />
Berichte liegen im XML-Format mit der Dateierweiterung .mbsa vor.<br />
MBSA-Analysen von der Eingabeaufforderung<br />
Der MBSA bietet auch die Möglichkeit, eine Analyse von der Eingabeaufforderung aus zu<br />
starten. Dafür steht die Befehlszeilenversion Mbsacli.exe zur Verfügung. Das ist nützlich,<br />
wenn Sie Analysen im Startskript eines Gruppenrichtlinienobjekts durchführen und den
Tools für Ihr Patchverwaltungsarsenal 365<br />
Bericht in einer Netzwerkfreigabe abspeichern wollen. Wenn Sie Mbsacli.exe benutzen,<br />
erhalten Sie denselben Funktionsumfang wie bei einer interaktiven Analyse.<br />
Sie können Mbsacli.exe folgende Argumente übergeben:<br />
/target Domäne\Computer Untersucht den Computer mit dem angegebenen Computernamen.<br />
/target IP-Adresse Untersucht den Computer mit der angegebenen IP-Adresse.<br />
/r IP-Bereich Untersucht alle Computer im angegebenen IP-Adressbereich (in der<br />
Form 10.0.0.1<strong>–</strong>10.0.0.100).<br />
/listfile Datei Untersucht Computer, deren Computernamen oder IP-Adressen aus<br />
einer Textdatei gelesen werden.<br />
/d Domäne Untersucht alle Computer in der angegebenen Domäne. Der Parameter Domäne<br />
muss in der Form des NETBIOS-Namens angegeben werden, nicht als FQDN.<br />
/n Option Legt fest, welche Prüfungen bei dieser Analyse nicht durchgeführt werden.<br />
Der Parameter Option kann die folgenden Werte annehmen, die sich mit einem Pluszeichen<br />
(+) ohne Leerzeichen zwischen den Werten auch kombinieren lassen:<br />
OS Prüft keine administrativen <strong>Windows</strong>-Verwundbarkeiten.<br />
Password Prüft nicht, ob schwache Kennwörter verwendet werden.<br />
IIS Prüft keine administrativen IIS-Verwundbarkeiten.<br />
SQL Prüft keine administrativen SQL <strong>Server</strong>-Verwundbarkeiten.<br />
Updates Sucht nicht nach fehlenden <strong>Sicherheit</strong>supdates.<br />
/wa Falls der Computer so konfiguriert ist, dass er Updates von einem WSUS-<strong>Server</strong><br />
installiert, sucht MBSA nur nach Updates, die auf WSUS genehmigt wurden.<br />
/wi Falls der Computer so konfiguriert ist, dass er Updates von einem WSUS-<strong>Server</strong><br />
installiert, sucht MBSA nach genehmigten und ungenehmigten Updates.<br />
/nvc Prüft nicht, ob eine neue Version von MBSA verfügbar ist.<br />
/o Dateiname Gibt den Pfad der XML-Datei an, die für die Ausgabe verwendet wird. In<br />
der Standardeinstellung verwendet Mbsacli.exe das Muster %D <strong>–</strong> %C <strong>–</strong> (%T).<br />
/qp Zeigt keine Fortschrittsmeldungen an.<br />
/qt Zeigt keinen Bericht an, wenn die Analyse abgeschlossen ist.<br />
/qe Zeigt keine Fehlerliste an.<br />
/qr Zeigt keine Berichtsliste an.<br />
/q Zeigt keine Fortschrittsmeldungen an, keinen Bericht, wenn die Analyse abgeschlossen<br />
ist, keine Fehlerliste und keine Berichtsliste.<br />
/Unicode <strong>Die</strong> Ausgabedatei enthält Unicodetext.<br />
/u Benutzername <strong>Die</strong> Analyse wird unter dem angegebenen Benutzernamen ausgeführt.<br />
/p Kennwort <strong>Die</strong> Analyse wird mit dem angegebenen Kennwort ausgeführt.<br />
/catalog Dateiname Gibt die Datenquelle an, die Daten über die <strong>Sicherheit</strong>supdates<br />
enthält.<br />
/ia Aktualisiert bei Bedarf den <strong>Windows</strong> Update-Agent auf dem untersuchten Computer,<br />
bevor die Analyse gestartet wird.
366 Kapitel 13: Patchverwaltung<br />
/mu Konfiguriert den untersuchten Computer so, dass er Microsoft Update statt <strong>Windows</strong><br />
Update verwendet.<br />
/nd Lädt bei der Analyse keine Dateien von der Microsoft-Website herunter.<br />
/xmlout Bei der Analyse wird ausschließlich geprüft, ob Updates vorhanden sind.<br />
/l Listet alle verfügbaren Berichte auf.<br />
/ls Listet die Berichte der letzten Analyse auf.<br />
/lr Zeigt den zusammenfassenden Bericht an.<br />
/ld Zeigt den detaillierten Bericht an.<br />
/? Zeigt die Befehlszeilenhilfe für Mbsacli.exe an.<br />
<strong>Windows</strong> <strong>Server</strong> Update Services<br />
WSUS (<strong>Windows</strong> <strong>Server</strong> Update Services) setzt einen <strong>Server</strong> ein, um Updates zu hosten, die<br />
auf Computern bereitgestellt werden, die unter Microsoft <strong>Windows</strong> <strong>Server</strong> 2003, <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>, <strong>Windows</strong> Vista, Microsoft <strong>Windows</strong> XP und <strong>Windows</strong> 2000 mit Service Pack 4<br />
laufen.<br />
Der WSUS-<strong>Server</strong> stellt den WSUS-Clients die Updates mithilfe eines Webdienstes bereit.<br />
<strong>Die</strong> Clients können in einem Gruppenrichtlinienobjekt (Group Policy Object, GPO) oder<br />
durch eine manuelle Änderung in der Registrierung des Clientcomputers so konfiguriert<br />
werden, dass sie die Verbindung zum WSUS-<strong>Server</strong> herstellen. <strong>Die</strong>ses Kapitel beschreibt die<br />
Methode mit der GPO-Bereitstellung. Weitere Informationen, wie Sie WSUS auf einem<br />
Client von Hand mithilfe der Registrierung konfigurieren können, finden Sie unter<br />
http://technet2.microsoft.com/windowsserver/en/library/1776f85d-a326-4f1d-a2ed-<br />
2fdd21d590d71033.mspx.<br />
Ein Administrator muss alle Updates genehmigen, bevor die WSUS-Clients sie installieren<br />
können. Wenn ein WSUS-Client Kontakt mit dem WSUS-<strong>Server</strong> aufnimmt, bekommt er<br />
eine Liste der Updates, die für seine Versionen von Betriebssystem und Microsoft-Produkten<br />
genehmigt wurden, die auf dem Computer installiert sind. Wenn der WSUS-Client ein Update<br />
erfolgreich installiert hat, benachrichtigt er den WSUS-<strong>Server</strong> und das Ereignis wird in<br />
der WSUS-Datenbank aufgezeichnet. So kann ein Administrator Berichte über den aktuellen<br />
Updatestatus aller Computer zusammenstellen, die vom WSUS-<strong>Server</strong> verwaltet werden.<br />
Was ist neu in WSUS 3.0<br />
WSUS 3.0 stellt viele neue Features zur Verfügung, die Administratoren dabei helfen,<br />
Updates auf ihren WSUS-Clients besser zu verwalten. <strong>Die</strong>se Features sind zum Beispiel:<br />
<strong>Die</strong> neue MMC-Verwaltungskonsole (Microsoft Management Console)<br />
<strong>Die</strong> Fähigkeit, die WSUS-Verwaltungskonsole auf anderen Computern als dem WSUS-<br />
<strong>Server</strong> zu installieren<br />
Verbesserte Berichterstattung, zum Beispiel Updatestatusberichte über WSUS-Clients<br />
In WSUS unterstützte Microsoft-Produkte<br />
Mit jeder neuen Version von WSUS wird Unterstützung für noch mehr Microsoft-Produkte<br />
verfügbar. Tabelle 13.3 listet die Produkte auf, die in WSUS 3.0 unterstützt werden.
Tabelle 13.3 In WSUS 3.0 unterstützte Produkte<br />
<strong>Windows</strong> 2000 mit Service Pack 4<br />
<strong>Windows</strong> XP (32-Bit-, IA-64- und x64-Edition)<br />
<strong>Windows</strong> Vista<br />
<strong>Windows</strong> <strong>Server</strong> 2003<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
<strong>Windows</strong> Small Business <strong>Server</strong> 2003<br />
Exchange <strong>Server</strong> 2000<br />
Exchange <strong>Server</strong> 2003<br />
Exchange <strong>Server</strong> 2007<br />
Computer Cluster<br />
CAPICOM SDK Components<br />
Microsoft Core XML Service<br />
Visual Studio 2005<br />
<strong>Windows</strong>-Defender<br />
<strong>Windows</strong> Live<br />
Office XP<br />
Office 2003<br />
Das 2007 Office-System<br />
Office Communications <strong>Server</strong> 2007<br />
Microsoft Internet Security and Acceleration <strong>Server</strong> 2004<br />
Microsoft Internet Security and Acceleration <strong>Server</strong> 2006<br />
Microsoft Data Protection Manager 2006<br />
System Center Virtual Machine Manager 2007<br />
Microsoft ForeFront<br />
Network Monitor 3<br />
Systems Management <strong>Server</strong> 2003<br />
Virtual PC 2007<br />
Virtual <strong>Server</strong> 2005<br />
SQL <strong>Server</strong> 2005<br />
Tools für Ihr Patchverwaltungsarsenal 367<br />
Voraussetzungen für WSUS 3.0<br />
Damit Sie WSUS 3.0 auf einem <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Computer installieren können, müssen<br />
Sie sicherstellen, dass folgende Voraussetzungen erfüllt sind:<br />
Falls Sie keinen <strong>Server</strong> haben, der SQL <strong>Server</strong> ausführt und den Sie für WSUS verwenden<br />
können, ist es möglich, die interne <strong>Windows</strong>-Datenbank zu verwenden.<br />
Vorsicht <strong>Die</strong> interne <strong>Windows</strong>-Datenbank unterstützt keine Remoteverbindungen, daher können Sie<br />
die WSUS-Verwaltungskonsole nicht auf einem anderen Computer installieren, falls Sie die interne<br />
<strong>Windows</strong>-Datenbank verwenden.
368 Kapitel 13: Patchverwaltung<br />
Weil WSUS auf einem Webdienst aufsetzt, müssen Sie die Rolle Webserver (IIS) konfigurieren,<br />
bevor Sie die Installation starten.<br />
Falls Sie nicht WSUS 3.0 mit Service Pack 1 oder neuer verwenden, muss die Webserver-Konfigurationsdatei<br />
geändert werden, um das Modul für benutzerdefinierte Fehler<br />
zu entfernen.<br />
Hinweis Um auf bestimmte WSUS-Berichte zugreifen zu können, müssen Sie Microsoft Report Viewer<br />
Redistributable 2005 installieren, das unter http://go.microsoft.com/fwlink/?LinkId=70410 zur Verfügung<br />
steht.<br />
Installieren der internen <strong>Windows</strong>-Datenbank<br />
WSUS kann alle seine Daten in der internen <strong>Windows</strong>-Datenbank speichern. Sie können die<br />
interne <strong>Windows</strong>-Datenbank in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> mit dem <strong>Server</strong>-Manager installieren:<br />
1. Klicken Sie im Startmenü auf Verwaltung und dann auf <strong>Server</strong>-Manager.<br />
2. Klicken Sie auf Features und dann auf Features hinzufügen.<br />
3. Aktivieren Sie auf der Seite Features auswählen das Kontrollkästchen Interne <strong>Windows</strong>-<br />
Datenbank.<br />
4. Klicken Sie auf Ja und dann auf Weiter.<br />
5. Klicken Sie auf Installieren.<br />
6. Warten Sie, bis die Installation abgeschlossen ist, und klicken Sie dann auf Schließen.<br />
Installieren der Rolle Webserver (IIS)<br />
Sie installieren die Rolle Webserver (IIS) in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> mit dem <strong>Server</strong>-Manager.<br />
Nicht alle Komponenten der Rolle Webserver (IIS) sind erforderlich, damit WSUS einwandfrei<br />
funktioniert. Sie sollten die Standardrollendienste aktiviert lassen und zusätzlich<br />
ASP.NET, <strong>Windows</strong>-Authentifizierung und IIS 6-Verwaltungskompatibilität aktivieren.<br />
Weitere Informationen darüber, wie Sie Rollen mit dem <strong>Server</strong>-Manager installieren, finden<br />
Sie in Kapitel 12, »Schützen von <strong>Server</strong>rollen«.<br />
Konfigurieren von WSUS-Voraussetzungen mit<br />
<strong>Server</strong>ManagerCmd.exe<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> führt ein neues Feature namens <strong>Server</strong>-Manager ein. Der <strong>Server</strong>-<br />
Manager ist eine zentrale Konsole, in der Sie die auf Ihrem <strong>Server</strong> installierten Rollen<br />
und Features verwalten können. Auch eine Befehlszeilenversion des <strong>Server</strong>-Managers,<br />
<strong>Server</strong>ManagerCmd.exe, ist vorhanden. Sie können mit <strong>Server</strong>ManagerCmd.exe einzelne<br />
Rollen installieren oder eine Antwortdatei (im XML-Format) erstellen, um bestimmte<br />
Rollen, Rollendienste und Features installieren zu lassen. Der folgende Befehl übergibt<br />
eine Antwortdatei an <strong>Server</strong>ManagerCmd.exe:<br />
servermanagercmd -inputpath Antwortdatei.xml<br />
Der folgende Code ist eine XML-Antwortdatei, mit der Sie die Rollendienste und Features<br />
installieren können, die für WSUS benötigt werden:
Tools für Ihr Patchverwaltungsarsenal 369<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Ändern der Webserverkonfigurationsdatei<br />
Falls Sie nicht WSUS 3.0 mit Service Pack 1 oder neuer einsetzen, müssen Sie das benutzerdefinierte<br />
Fehlermodul aus der Konfigurationsdatei des Webservers entfernen, bevor Sie<br />
WSUS installieren. Dafür können Sie einen Texteditor verwenden, in dem Sie eine neue<br />
Zeile in das Tag einfügen. Gehen Sie dazu folgendermaßen<br />
vor:<br />
1. Wechseln Sie in den Ordner %WinDir%\System32\inetsrv\config.<br />
2. Öffnen Sie im <strong>Windows</strong>-Editor die Datei namens applicationHost.config.<br />
3. Löschen Sie im Tag die Zeile , sofern sie vorhanden ist.<br />
4. Fügen Sie im Tag die Zeile ein. Speichern und schließen Sie die Datei.<br />
5. Geben Sie in einer Eingabeaufforderung den Befehl iisreset ein und drücken Sie die<br />
EINGABETASTE.<br />
Voraussetzungen für WSUS 3.0-<strong>Server</strong><br />
Tabelle 13.4 listet die Hardware- und Softwaremindestvoraussetzungen für WSUS 3.0 auf.
370 Kapitel 13: Patchverwaltung<br />
Tabelle 13.4 Mindestvoraussetzungen für WSUS 3.0 <strong>Server</strong><br />
Anforderung Details<br />
Betriebssystem <strong>Windows</strong> <strong>Server</strong> 2003 SP1 oder neuer<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Vorinstallierte<br />
Software-<br />
komponenten<br />
Internetinformationsdienste<br />
Interne <strong>Windows</strong>-Datenbank oder Microsoft SQL <strong>Server</strong> 2005 mit Service Pack 1 (SP1)<br />
.NET Framework 2.0<br />
Microsoft Management Console 3.0<br />
Microsoft Report Viewer<br />
Festplattenplatz 1 GByte auf der Systempartition<br />
2 GByte auf dem Datenbankvolume<br />
20 GByte auf dem Volume, auf dem die Updates gespeichert werden<br />
Installieren und Konfigurieren von WSUS 3.0<br />
Sie können WSUS entweder mit der internen <strong>Windows</strong>-Datenbank oder einem dedizierten<br />
Datenbankserver installieren. Für eine Produktivumgebung wird dringend empfohlen, einen<br />
dedizierten Datenbankserver einzusetzen. Gehen Sie folgendermaßen vor, um WSUS zu<br />
installieren :<br />
1. Laden Sie WSUS 3.0 von http://www.microsoft.com/downloads/details.aspx?FamilyID=<br />
e4a868d7-a820-46a0-b4db-ed6aa4a336d9&DisplayLang=en herunter.<br />
2. Starten Sie die Installation, indem Sie doppelt auf WSUS3Setup.exe kilcken.<br />
3. Klicken Sie auf der Seite Willkommen beim Setup-Assistenten für <strong>Windows</strong> <strong>Server</strong><br />
Update Services 3.0 auf Weiter.<br />
4. Wählen Sie die Option Vollständige <strong>Server</strong>installation einschließlich Verwaltungskonsole<br />
aus und klicken Sie auf Weiter.<br />
5. Wählen Sie Ich stimme den Bedingungen des Lizenzvertrags zu aus und klicken Sie auf<br />
Weiter.<br />
6. Wählen Sie den Speicherort aus, an dem WSUS Updates speichern soll, und klicken Sie<br />
auf Weiter.<br />
7. Wählen Sie die Option Es wird ein vorhandener Datenbankserver auf einem Remotecomputer<br />
verwendet aus, geben Sie den Computernamen des Datenbankservers ein und<br />
klicken Sie auf Weiter. <strong>Die</strong>sen Schritt sehen Sie in 12.8.<br />
8. Klicken Sie auf der Seite Verbindungsherstellung mit der SQL <strong>Server</strong>-Instanz auf Weiter.<br />
9. Wählen Sie die Option <strong>Die</strong> vorhandene IIS-Standardwebsite verwenden aus und klicken<br />
Sie auf Weiter.<br />
10. Klicken Sie auf Fertig stellen, um die Installation zu beginnen.<br />
11. Warten Sie, bis die Installation abgeschlossen ist, und klicken Sie dann auf Fertig stellen.<br />
12. Der Assistent für die Konfiguration von <strong>Windows</strong> <strong>Server</strong> Update Services wird automatisch<br />
angezeigt, sobald die Installation beendet ist. Klicken Sie auf der Seite Vorbemerkung<br />
auf Weiter.
Abbildung 13.8 WSUS kann eine vorhandene SQL <strong>Server</strong>-Datenbank<br />
oder die interne <strong>Windows</strong>-Datenbank verwenden<br />
Abbildung 13.9 Sie können Ihre Updates vom Microsoft Update-<strong>Die</strong>nst<br />
oder einem anderen WSUS-<strong>Server</strong> innerhalb Ihrer Organisation beziehen<br />
Tools für Ihr Patchverwaltungsarsenal 371<br />
13. Wählen Sie die Option Ja, ich möchte am Programm zur Verbesserung von Microsoft<br />
Update teilnehmen, falls Sie sich an diesem Programm beteiligen wollen, und klicken<br />
Sie auf Weiter.
372 Kapitel 13: Patchverwaltung<br />
14. Wählen Sie die Option Synchronisieren von Microsoft Update aus und klicken Sie auf<br />
Weiter (Abbildung 13.9). Falls Sie einen anderen WSUS-<strong>Server</strong> innerhalb Ihrer Organisation<br />
betreiben, können Sie stattdessen auch diesen <strong>Server</strong> für die Synchronisation verwenden.<br />
15. Falls Ihre Organisation einen Proxyserver verwendet, um die Verbindung zum Internet<br />
herzustellen, können Sie auf der nächsten Seite die Proxyinformationen eingeben. Klicken<br />
Sie andernfalls einfach auf Weiter.<br />
16. Klicken Sie auf Verbindung starten. Warten Sie, bis die Verbindung steht, und klicken<br />
Sie dann auf Weiter.<br />
17. Wählen Sie aus, in welchen Sprachen die Updates lokal auf Ihrem WSUS-Computer<br />
gespeichert werden sollen, und klicken Sie auf Weiter.<br />
18. Geben Sie an, für welche Produkte Sie Updates wollen, und klicken Sie auf Weiter.<br />
19. Legen Sie die Klassen von Updates fest, die Sie synchronisieren wollen. In der Standardeinstellung<br />
sind nur die Typen Updates mit hoher Priorität und <strong>Sicherheit</strong>supdates<br />
ausgewählt.<br />
20. Stellen Sie den Synchronisierungszeitplan ein und klicken Sie auf Weiter. In der Standardeinstellung<br />
ist eine manuelle Synchronisierung eingestellt, aber Sie können Ihren<br />
WSUS-<strong>Server</strong> auch täglich mit dem Microsoft Update-<strong>Die</strong>nst synchronisieren.<br />
21. Falls Sie jetzt eine Synchronisierung durchführen wollen, können Sie das Kontrollkästchen<br />
Erstsynchronisierung starten aktivieren und auf Weiter klicken. Wie lange es dauert,<br />
die Synchronisierung zwischen Ihrem lokalen WSUS-<strong>Server</strong> und dem Microsoft<br />
Update-<strong>Die</strong>nst oder einem anderen WSUS-<strong>Server</strong> in Ihre Organisation durchzuführen,<br />
hängt von der verfügbaren Bandbreite ab. Im Durchschnitt dürfte es mehrere Minuten<br />
dauern.<br />
22. Klicken Sie auf Fertig stellen.<br />
Abbildung 13.10 zeigt die WSUS-Verwaltungskonsole nach einer erfolgreichen Installation.<br />
Abbildung 13.10 In der WSUS-Verwaltungskonsole können Sie <strong>Sicherheit</strong>supdates genehmigen,<br />
Clientcomputer verwalten und Berichte anzeigen
Tools für Ihr Patchverwaltungsarsenal 373<br />
Konfigurieren von WSUS-Clients<br />
Ein WSUS-Client ist ein Clientcomputer in Ihrem Netzwerk, dessen Updates von einem<br />
WSUS-<strong>Server</strong> verwaltet werden. WSUS-Clients verwenden das Feature Automatische<br />
Updates, um Updates vom WSUS-<strong>Server</strong> zu erhalten. Sie können die WSUS-Clients mit<br />
einem Gruppenrichtlinienobjekt (Group Policy Object, GPO) konfigurieren. <strong>Die</strong> GPO-<br />
Einstellungen für WSUS finden Sie im Knoten Computerkonfiguration\Administrative<br />
Vorlagen\<strong>Windows</strong>-Komponenten\<strong>Windows</strong> Update.<br />
Es stehen mehrere Richtlinieneinstellungen zur Verfügung, um <strong>Windows</strong> Update zu konfigurieren.<br />
Für WSUS sind die beiden Einstellungen Automatische Updates konfigurieren und<br />
Internen Pfad für den Microsoft Updatedienst angeben nötig.<br />
Abbildung 13.11 zeigt die Richtlinieneinstellung Automatische Updates konfigurieren.<br />
Abbildung 13.11 In der Richtlinieneinstellung Automatische Updates konfigurieren<br />
können Sie <strong>Windows</strong> Update für alle Clientcomputer in Ihrem Netzwerk konfigurieren<br />
Sie können in der Richtlinieneinstellung Automatische Updates konfigurieren folgende Einstellungen<br />
wählen:<br />
Vor Herunterladen und Installation benachrichtigen Updates werden nicht automatisch<br />
heruntergeladen oder installiert. Falls ein Benutzer, der Mitglied der lokalen<br />
Gruppe Administratoren ist, am Clientcomputer angemeldet ist, wird er benachrichtigt,<br />
dass Updates zum Herunterladen und Installieren bereitstehen.<br />
Autom. Herunterladen, aber vor Installation benachrichtigen Updates werden<br />
automatisch heruntergeladen, aber nicht installiert. Falls ein Benutzer, der Mitglied der<br />
lokalen Gruppe Administratoren ist, am Clientcomputer angemeldet ist, wird er benachrichtigt,<br />
dass Updates heruntergeladen wurden und zur Installation bereitstehen.<br />
Autom. Herunterladen und laut Zeitplan installieren Updates werden automatisch<br />
heruntergeladen und installiert. Der Zeitpunkt dafür wird durch die Felder Geplanter<br />
Installationstag und Geplante Installationszeit konfiguriert.
374 Kapitel 13: Patchverwaltung<br />
Lokalen Administratoren ermöglichen, Einstellung auszuwählen Benutzer, die<br />
Mitglieder der lokalen Gruppe Administratoren sind, können konfigurieren, wie Updates<br />
auf dem Clientcomputer verarbeitet werden. Es ist ihnen aber nicht erlaubt, Automatische<br />
Updates zu deaktivieren.<br />
In der Richtlinieneinstellung Internen Pfad für den Microsoft Updatedienst angeben leiten<br />
Sie den Clientcomputer so um, dass er keine Verbindung zu <strong>Windows</strong> Update herstellt, sondern<br />
Ihren WSUS-<strong>Server</strong> benutzt. Sie müssen Adressen sowohl in Interner Updatedienst<br />
zum Ermitteln von Updates als auch Intranetserver für die Statistik eintragen, aber sie können<br />
beide Male denselben <strong>Server</strong> angeben. <strong>Die</strong> Richtlinieneinstellung Internen Pfad für den<br />
Microsoft Updatedienst angeben sehen Sie in Abbildung 13.12.<br />
Abbildung 13.12 <strong>Die</strong>se Richtlinieneinstellung konfiguriert die Clientcomputer so,<br />
dass Sie statt <strong>Windows</strong> Update Ihren WSUS-<strong>Server</strong> benutzen<br />
Wenn Sie die Gruppenrichtlinieneinstellungen konfiguriert haben, können Sie warten, bis<br />
die Clientcomputer sie automatisch aktualisieren, oder auf einem Client eine Aktualisierung<br />
erzwingen, indem Sie an einer Eingabeaufforderung auf dem Clientcomputer den Befehl<br />
gpupdate /force eingeben. Nachdem die Gruppenrichtlinieneinstellungen konfiguriert wurden,<br />
sollten Sie etwa 20 Minuten warten, bis ein Clientcomputer automatisch Kontakt zum<br />
WSUS-<strong>Server</strong> aufnimmt. Mit dem Befehl wuauclt.exe /detectnow können Sie den Client<br />
auch zwingen, sofort eine Verbindung zum WSUS-<strong>Server</strong> herzustellen.<br />
System Center Essentials 2007<br />
Der Großteil dieses Kapitels konzentriert sich auf kostenlose Produkte, die Microsoft zur<br />
Verfügung stellt, um Ihnen bei der Patchverwaltung zu helfen. Microsoft bietet auch ein<br />
Produkt an, das alles innerhalb einer einzigen Anwendung erledigt. Microsoft System Center<br />
Essentials 2007 ist ein Verwaltungsprodukt, das für mittelgroße Unternehmen entworfen<br />
wurde. Es soll Ihnen die Aufgabe erleichtern, Computer in Ihrem Netzwerk zu verwalten.<br />
System Center Essentials 2007 bietet eine einheitliche Oberfläche, proaktive Verwaltung<br />
und bessere Effizienz für tägliche Arbeiten. In diesem Abschnitt sehen wir uns an, wie sich
Tools für Ihr Patchverwaltungsarsenal 375<br />
System Center Essentials 2007 in Ihre Patchverwaltungsstrategie einfügt. Große Organisationen<br />
sollten Microsoft System Center Configuration Manager 2007 einsetzen. Weitere<br />
Informationen über die System Center-Produktfamilie finden Sie unter http://www.micro<br />
soft.com/systemcenter.<br />
Wir sind noch nicht auf das Problem eingegangen, wie Sie ein genaues Inventar aller Computer<br />
in Ihrem Netzwerk erhalten. System Center Essentials 2007 gibt Ihnen die Möglichkeit,<br />
ein Hardware- und Softwareinventar zu erstellen und zu verwalten. System Center<br />
Essentials 2007 bietet folgende Inventarfeatures:<br />
Automatische Erkennung System Center Essentials 2007 kann Active Directory<br />
abfragen und feststellen, ob irgendwelche neuen Computer zu Ihrer Domäne hinzugekommen<br />
sind, die noch nicht inventarisiert wurden. Werden neue Computer gefunden,<br />
kann System Center Essentials 2007 sie ins Inventar aufnehmen, sobald sie das nächste<br />
Mal mit dem Netzwerk verbunden sind.<br />
Ausführliche Berichte Das Berichterstellungsmodul ermöglicht Ihnen, detaillierte<br />
Daten über die Computer in Ihrem Netzwerk zusammenzustellen. Außerdem lassen sich<br />
die Berichte anpassen, sodass Sie brandaktuelle Berichte erstellen können, die einen<br />
Eindruck vom momentanen Aufbau Ihres Netzwerks vermitteln.<br />
Da Sie nun ein genaues Computerinventar haben, können Sie diese Informationen nutzen,<br />
um Updates für die Computer in Ihrem Netzwerk bereitzustellen. Dafür steht in System<br />
Center Essentials 2007 der Updatekonfigurationsassistent zur Verfügung. Er bietet folgende<br />
Features, die in den bisher in diesem Kapitel beschriebenen Produkten fehlen:<br />
Unterstützung für Nicht-Microsoft-Updates Sie können Updates bereitstellen, die<br />
von beliebigen Softwareherstellern herausgegeben wurden. So können Sie sicherstellen,<br />
dass Sie alle Ihre Software pflegen, die auf Computern innerhalb Ihres Netzwerks installiert<br />
ist.<br />
Termin für die Updatebereitstellung Zu jedem Update können Sie einen Termin<br />
festlegen, an dem das Update unbedingt installiert sein muss. Falls das Update zu diesem<br />
Zeitpunkt nicht installiert ist, bietet System Center Essentials 2007 dem Benutzer nicht<br />
mehr an, das Update zu installieren. Es wird zwangsweise installiert und der Computer<br />
wird bei Bedarf neu gestartet.<br />
Installieren bei Bedarf System Center Essentials 2007 ermöglicht Ihnen, das <strong>Sicherheit</strong>supdate<br />
sofort zu installieren, ohne auf den geplanten Installationszeitpunkt warten<br />
zu müssen. Das kann praktisch sein, falls ein <strong>Sicherheit</strong>supdate freigegeben wurde, das<br />
eine ernste <strong>Sicherheit</strong>slücke schließt.<br />
Gemeinsam genutztes Updateschema System Center Essentials 2007 unterstützt die<br />
Verwendung eines gemeinsam genutzten Updateschemas, mit dem Sie Kataloge von anderen<br />
Updateanbietern als Microsoft importieren können.<br />
Weitere Informationen über System Center Essentials 2007 finden Sie auf der Microsoft<br />
System Center Essentials 2007-Homepage unter http://www.microsoft.com/sce.
376 Kapitel 13: Patchverwaltung<br />
Zusammenfassung<br />
Sie sollten eine Patchverwaltungsstrategie entwickeln, damit Sie geeignete Richtlinien und<br />
Prozeduren sowie die richtigen Tools für diese Aufgabe bereitstehen haben. Das erfordert<br />
ausgiebige Planung, das zahlt sich aber später aus, weil die Produktivität Ihres Unternehmens<br />
deutlich weniger gestört wird.<br />
<strong>Die</strong>ses Kapitel hat die vier Phasen beim Entwickeln einer Patchverwaltungsstrategie vorgestellt:<br />
Bewerten, Identifizieren, Auswerten & Planen und Bereitstellen. Jeder Schritt ist<br />
wichtig, um den Erfolg einer Patchverwaltungsstrategie sicherzustellen, die für alle in Ihrer<br />
Organisation Beschäftigten Vorteile bringt. Außerdem hat dieses Kapitel einige Microsoft-<br />
Produkte und -Tools vorgestellt, die Ihnen sicherstellen helfen, dass die Computer in Ihrem<br />
Netzwerk auf dem neuesten Stand bleiben, wenn Updates veröffentlicht werden.<br />
Ein Produkt, das in diesem Kapitel nicht behandelt wurde, ist der Netzwerkzugriffsschutz<br />
(Network Access Protection, NAP). Sie können mit NAP sicherstellen, dass auf allen Heimcomputern,<br />
die über VPN eine Verbindung zu Ihrem Netzwerk herstellen, bestimmte Updates<br />
installiert sind, bevor sie in das Netzwerk gelassen werden. Weitere Informationen,<br />
wie Sie mit NAP die Updateausstattung von Heimcomputern, die Verbindung zu Ihrem<br />
Netzwerk herstellen, steuern können, finden Sie in Kapitel 5, »<strong>Windows</strong>-Firewalls«.<br />
Weitere Informationen<br />
Microsoft Corporation (<strong>2008</strong>): »Security Guidance for Patch Management« unter<br />
http://www.microsoft.com/technet/security/guidance/patchmanagement.mspx.<br />
Microsoft Corporation (2007): »Patch Management Process« unter http://www.microsoft.<br />
com/technet/security/guidance/patchmanagement/secmod193.mspx.<br />
Microsoft Corporation (<strong>2008</strong>): »Microsoft Update Catalog« unter http://catalog.update.<br />
microsoft.com/v7/site/Home.aspx.<br />
Microsoft Corporation (<strong>2008</strong>): »Microsoft Download Center« unter http://download.<br />
microsoft.com.<br />
Microsoft Corporation (<strong>2008</strong>): »Microsoft Baseline Security Analyzer« unter<br />
http://www.microsoft.com/mbsa.<br />
Microsoft Corporation (<strong>2008</strong>): »Update Management Center« unter http://technet.<br />
microsoft.com/en-us/library/bb466251.aspx.<br />
Microsoft Corporation (<strong>2008</strong>): »Microsoft Update« unter http://update.microsoft.com.<br />
Microsoft Corporation (<strong>2008</strong>): »<strong>Windows</strong> <strong>Server</strong> Software Update Services« unter<br />
http://technet.microsoft.com/en-us/wsus/default.aspx.<br />
Microsoft Corporation (<strong>2008</strong>): »System Center Essentials 2007« unter<br />
http://www.microsoft.com/sce.<br />
Microsoft Corporation (<strong>2008</strong>): »Microsoft Security Tools« unter http://www.microsoft.<br />
com/technet/security/tools/default.mspx.
K A P I T E L 1 4<br />
Schützen des Netzwerks<br />
Von Jesper M. Johansson<br />
In diesem Kapitel:<br />
Einführung in <strong>Sicherheit</strong>sabhängigkeiten . ................................... 380<br />
Abhängigkeitstypen .................................................. 385<br />
Eindämmen von Abhängigkeiten ......................................... 389<br />
Zusammenfassung .................................................. 403<br />
Weitere Informationen ................................................ 404<br />
Ich werde oft gefragt, wie die Arbeitsstationen in einem Netzwerk geschützt werden sollen.<br />
<strong>Die</strong>se Frage wird meist anlässlich des neuesten Angrifftyps gestellt, der gerade auf irgendeiner<br />
Konferenz demonstriert wurde. Zum Beispiel sind momentan viele Leute sehr besorgt<br />
wegen der allgegenwärtigen USB-Flashspeicher. Das sind die unglaublich praktischen, winzig<br />
kleinen Festspeichergeräte, die inzwischen in fast schon absurden Kapazitäten erhältlich<br />
sind. Viele Leute haben Angst vor einem Angriff, bei dem ein Angreifer ein USB-Flashlaufwerk<br />
an einen Computer ansteckt oder den Benutzer dazu bringt, das zu tun. Das USB-<br />
Flashlaufwerk enthält eventuell Malware, die entweder automatisch oder nach minimaler<br />
Benutzerinteraktion auf dem Computer ausgeführt wird.<br />
Sich so auf die USB-Flashlaufwerke zu konzentrieren, greift zu kurz, wenn Sie bedenken,<br />
dass es viel größere Probleme mit Wechselmediengeräten gibt: CDs, DVDs, FireWire-Laufwerke,<br />
Parallelanschlussgeräte (hat irgendwer so etwas noch?) und praktisch jeder andere<br />
Anschluss am Computer, über den ein Zugriff auf externe Inhalte möglich ist. Allzu oft machen<br />
sich Leute nur Sorgen wegen ihrer Arbeitsstationen, aber nicht wegen des übrigen<br />
Netzwerks. Ich denke, dass die Frage nicht lauten sollte, wie Sie verhindern, dass Arbeitsstationen<br />
gehackt werden, sondern wie Sie verhindern können, dass der Rest des Netzwerks<br />
umfällt wie Dominosteine, sobald das einmal passiert ist. Sehen wir uns ein paar Zahlen an.<br />
Nehmen wir an, Sie haben 10.000 Endbenutzer in einem Netzwerk. Wie groß ist die Wahrscheinlichkeit,<br />
dass Sie all diese Arbeitsstationen sicher halten können? Nehmen wir ruhig<br />
an, dass jede dieser Arbeitsstationen auf dem aktuellen Stand ist, was <strong>Sicherheit</strong>supdates<br />
betrifft, vollständig verwaltet ist und von Benutzern bedient wird, die genug über <strong>Sicherheit</strong><br />
wissen, dass sie in 99,99 Prozent der Zeit keine böswilligen Inhalte ausführen. Ignorieren<br />
wir erst einmal die vollständig absurden Annahmen und konzentrieren wir uns auf das errechnete<br />
Ergebnis. Bei 10.000 Arbeitsstationen bedeuten diese Zahlen, dass die Wahrscheinlichkeit,<br />
zu irgendeinem bestimmten Zeitpunkt ein sicheres Netzwerk zu haben, 37 Prozent<br />
beträgt. Bei 20.000 Arbeitsstationen sinken Ihre Chancen auf etwa 13 Prozent. Wenn wir<br />
etwas realistischere Annahmen treffen, mit welcher Wahrscheinlichkeit Ihre Arbeitsstationen<br />
sicher sind, stellen Sie fest, dass die Wahrscheinlichkeit, sie alle gleichzeitig sicher halten zu<br />
können, mit zunehmender Größe Ihres Netzwerks asymptotisch gegen 0 geht.<br />
377
378 Kapitel 14: Schützen des Netzwerks<br />
Natürlich ist es absolut unverzichtbar, das Netzwerk als Ganzes vor der Kompromittierung<br />
einer einzelnen Arbeitsstation zu schützen. Als IT-Manager behaupte ich, dass das wichtigste,<br />
was Sie tun können, um die <strong>Sicherheit</strong> Ihre Betriebsumgebung zu verbessern, darin besteht,<br />
die Abhängigkeiten in Ihrem Netzwerk so zu verwalten, dass Einbrüche isoliert bleiben.<br />
Ein Element bei diesen Maßnahmen ist, dass Sie die Kommunikation innerhalb Ihres<br />
Netzwerks einschränken. Microsoft nennt dies <strong>Server</strong>- und Domänenisolierung. Das Puzzle<br />
enthält aber noch einige weitere Teile.<br />
Direkt von der Quelle: <strong>Server</strong>- und Domänenisolierung<br />
<strong>Server</strong>- und Domänenisolierung ist eines der versteckten <strong>Sicherheit</strong>shighlights in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>, das einen genaueren Blick verdient. In älteren Versionen hatten Sie<br />
zwar schon die Möglichkeit, virtuelle Netzwerke über Endpunktauthentifizierung einzurichten,<br />
aber in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> haben wir viel dafür getan,<br />
dass dies noch einfacher bereitzustellen ist. Indem wir IPsec-Verbindungssicherheitsregeln<br />
mit <strong>Windows</strong>-Firewallfiltern kombinieren, geben wir <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<br />
Administratoren ein leistungsfähiges Tool an die Hand, um die <strong>Sicherheit</strong> in ihren Netzwerken<br />
zu verbessern und ihre wichtigen Daten besser zu schützen. Und all das steht zur<br />
Verfügung, ohne neue Software installieren zu müssen.<br />
Chris Black, Program Manager<br />
<strong>Windows</strong> Networking<br />
Viele Organisationen vertrauen nach wie vor viel zu sehr darauf, dass ihre Grenzfirewall das<br />
Problem für sie löst. Aber Grenzfirewalls sind in den heutigen Umgebungen praktisch bedeutungslos.<br />
Um zu verstehen, warum das so ist, müssen wir uns einmal ansehen, was es<br />
alles für Zugangspunkte zu Ihrem Netzwerk gibt. Falls Sie ein mittelgroßes oder großes<br />
Netzwerk haben, wette ich ein Essen in einem sehr guten Restaurant, dass Sie bei der letzten<br />
Analyse einige Wege zum Herausschmuggeln von Daten gefunden haben, von denen Sie<br />
bisher nichts wussten. Jeder Computer in einem virtuellen privaten Netzwerk (VPN) ist ein<br />
potenzieller Einbruchsweg. Jedes System, das Sie nicht aktualisiert haben, ist ein potenzieller<br />
Eindringpunkt. Jede unsichere, speziell entwickelte Software ist ein potenzieller Eindringpunkt.<br />
Jedes falsch konfigurierte Gerät, ob Router, Firewall, VPN-Gerät und Drahtloszugriffspunkt,<br />
ist ein potenzieller Eindring- und Ausgangspunkt.<br />
Wichtig Das Prinzip der gestaffelten Verteidigung (engl. defense in depth) fordert, dass Sie erheblichen<br />
Aufwand betreiben, um die Auswirkungen einer Kompromittierung in Ihrem Netzwerk gering zu halten.<br />
Eine offensichtliche Möglichkeit, das Problem durch den Missbrauch von Wechseldatenträgern<br />
zu beseitigen, besteht darin, alles zu verbieten, was sich unter Umständen für unlautere<br />
Zwecke missbrauchen lässt. USB-Flashlaufwerk sind nur ein kleiner Teil davon. Wir müssten<br />
alle Wechseldatenträgergeräte verbieten, inklusive allem, was sich an irgendeinen Gerätebus<br />
im Computer anstecken lässt. Ich habe schon öfters erklärt, am besten ließe sich das<br />
Problem mit einer gigantischen Tube Harz lösen, mit der Sie alle Öffnungen zukleben, die<br />
Sie vorne und hinten, rechts und links, oben und unten am Computer finden.<br />
<strong>Die</strong>ser Ansatz verursacht einige Probleme. Erstens könnte es passieren, dass Ihre Benutzer<br />
Sie auf dem Weg zu Ihrem Auto abfangen und lynchen, falls Sie so etwas wirklich durchziehen.<br />
Zweitens lägen ihre Benutzer damit gar nicht so falsch. Viele der erwähnten Geräte
Schützen des Netzwerks 379<br />
werden für die normale Arbeit benötigt. Zum Beispiel ist allgemein anerkannt, dass die<br />
sicherste Konfiguration der BitLocker-Verschlüsselungstechnologie in <strong>Windows</strong> Vista darin<br />
besteht, einen externen Schlüssel auf einem USB-Flashlaufwerk zu verwenden. Das würde<br />
deutlich erschwert, wenn Sie die USB-Anschlüsse mit Harz verkleben. Natürlich könnten<br />
Sie das USB-Flashlaufwerk im Anschluss festkleben, aber das würde Sinn und Zweck der<br />
externen Speicherung des Schlüssels zunichte machen. Dasselbe Argument gilt für die meisten<br />
Anschlüsse eines modernen Computers.<br />
Sofern es sich nicht um eine extrem kritische Umgebung handelt, ist es wahrscheinlich deutlich<br />
sinnvoller, die Gefahr bestmöglich abzuwehren und Einbrüche zu begrenzen. Wir müssen<br />
hier eine unwiderlegbare Tatsache akzeptieren. Gesetz 3 der »10 unveränderlichen Gesetzen<br />
der <strong>Sicherheit</strong>« (siehe http://www.microsoft.com/technet/archive/community/<br />
columns/security/essays/10imlaws.mspx?mfr=true) gilt nach wie vor:<br />
Falls ein Angreifer uneingeschränkten physischen Zugriff auf Ihren Computer bekommt,<br />
ist das nicht mehr Ihr Computer.<br />
Falls ein Angreifer Zugriff auf Ihren Computer hat (oder jemals hatte), muss dieser Computer<br />
als kompromittiert eingestuft werden. <strong>Die</strong>se Art von Angriff kann sogar aus der Ferne<br />
gelingen, wenn der Angreifer Sie dazu bringt, böswilligen Code auf Ihrem Computer auszuführen.<br />
Gesetz 1 der unveränderlichen Gesetze besagt:<br />
Falls ein Angreifer Sie überzeugen kann, sein Programm auf Ihrem Computer auszuführen,<br />
ist das nicht mehr Ihr Computer.<br />
Wenn wir es als gegeben nehmen, dass diese unveränderlichen Gesetze weiterhin gelten (das<br />
können wir wahrscheinlich, weil sie sich als erstaunlich widerstandsfähig erwiesen haben<br />
und kaum anzunehmen ist, dass sie sich als ungültig erweisen, solange es keine grundlegenden<br />
Umwälzungen bei der Funktionsweise von Computern gibt), können wir es nicht dabei<br />
belassen, einige Registrierungseinstellungen zu konfigurieren, um Wechseldatenträger unschädlich<br />
zu machen. Wir müssen ganz offensichtlich zusätzliche Schutzebenen einziehen.<br />
Schon wenn wir einfach die recht vernünftige Annahme treffen, dass viele unserer Clientcomputer<br />
entweder bereits kompromittiert sind oder von Leuten bedient werden, denen<br />
unsere <strong>Sicherheit</strong>sinteressen nicht sonderlich wichtig sind (oder beides), kommen wir zu<br />
dem Schluss, dass wir die Auswirkungen auf den Rest des Netzwerks eindämmen müssen.<br />
Dafür müssen wir zwangsläufig die <strong>Sicherheit</strong>sabhängigkeiten kennen, analysieren und<br />
eindämmen.<br />
<strong>Sicherheit</strong>swarnung: Über die Wirksamkeit von <strong>Sicherheit</strong>sleitfäden<br />
<strong>Die</strong> letzten ca. 15 Jahre über wurde ein unglaublicher Aufwand betrieben, um <strong>Sicherheit</strong>sleitfäden<br />
zusammenzustellen. Ich habe im Lauf der Jahre selbst an einem halben<br />
Dutzend davon mitgearbeitet. <strong>Die</strong>se Leitfäden umfassen eine Liste verschiedener <strong>Sicherheit</strong>soptimierungen,<br />
die Sie (so behaupten die Autoren) an der Standardinstallation irgendeiner<br />
Software durchführen müssen, um irgendeine <strong>Sicherheit</strong>sanforderung zu erfüllen.<br />
Welche Anforderung das ist, wird oft gar nicht erwähnt, und viele Leitfäden sind<br />
lediglich Listen aller möglichen Optimierungen, von denen die Autoren dachten, dass sie<br />
möglicherweise irgendeine winzige Auswirkung auf die <strong>Sicherheit</strong> haben. Meist wurde<br />
dabei überhaupt nicht berücksichtigt, welche Funktionalität Ihre Computer zur Verfügung<br />
stellen müssen oder welchen Bedrohungen Ihre Computer ausgesetzt sind. Oft funktionie-
380 Kapitel 14: Schützen des Netzwerks<br />
ren die Einstellungen, die solche Leitfäden empfehlen, nicht wirklich bei der Software,<br />
für die der Leitfaden geschrieben wurde.<br />
<strong>Die</strong> besten dieser Leitfäden machen ganz deutlich, was die Einstellungen tun, welche<br />
Auswirkungen auf die Anwendungskompatibilität Sie davon erwarten können und welche<br />
konkreten Bedrohungen sie eindämmen. Aber sogar die besten Leitfäden lassen das Problem<br />
der Netzwerksicherheit als Gesamtes weitgehend außen vor. <strong>Die</strong> Leitfäden konzentrieren<br />
sich fast ausschließlich darauf, einen einzelnen Computer gegen Angriffe zu<br />
schützen, ohne wirklich zu berücksichtigen, in welcher Umgebung dieser Computer bereitgestellt<br />
wird. Der wichtigste Punkt ist: Sobald ein Angreifer erst einmal in einem<br />
Netzwerk Fuß gefasst hat, sind sämtliche Einstellungen im <strong>Sicherheit</strong>sleitfaden völlig<br />
egal. Darüber, dass die Kontosperrung nach drei Falscheingaben unbegrenzt aktiviert<br />
wird (was jeden Benutzer in den Wahnsinn treibt), kann ein Angreifer, der über administrative<br />
Privilegien verfügt, nur lachen.<br />
Statt Ihre Anstrengungen darauf zu konzentrieren, welche Optimierungen Sie an Ihren<br />
Computern vornehmen sollten, ist es sinnvoller, wenn Sie einfach annehmen, dass ein<br />
Teil Ihres Netzwerks nicht vertrauenswürdig ist und das auch immer so bleiben wird. <strong>Die</strong><br />
Realität sieht so aus, dass heutige Unternehmensnetzwerke irgendwo zwischen feindlich<br />
und vertrauenswürdig einzuordnen sind, sagen wir mal halb-feindlich. Akzeptieren wir<br />
das als bedauerliche, aber unvermeidliche Tatsache und finden wir uns damit ab. Wir<br />
kümmern uns um dieses Problem, indem wir das Netzwerk als Ganzes gegen die wenigen<br />
böswilligen Elemente schützen. Sie können eine Gesellschaft nicht dadurch sicher machen,<br />
dass Sie Regeln formulieren und eine feste Mauer um die Gesellschaft bauen. Sie<br />
brauchen auch eine Polizei. Das Vorhandensein von Polizisten beweist im Grunde, dass<br />
die Gesellschaft akzeptiert, dass ein Teil ihrer Mitglieder sich weigert, die festgelegten<br />
Grenzen zu respektieren. In Ihrem Netzwerk ist das nicht anders.<br />
Einführung in <strong>Sicherheit</strong>sabhängigkeiten<br />
Eine <strong>Sicherheit</strong>sabhängigkeit (engl. security dependency) tritt auf, wenn die <strong>Sicherheit</strong> eines<br />
Computers von der <strong>Sicherheit</strong> eines anderen abhängt. Das ist nichts Ungewöhnliches und in<br />
vielen Fällen sogar erwünscht. Zum Beispiel ist Ihnen wahrscheinlich bekannt, dass Ihr gesamtes<br />
Netzwerk gehackt wurde, falls ein Angreifer es schafft, Ihren Domänencontroller<br />
(Domain Controller, DC) zu hacken. Das bedeutet schlicht, dass die <strong>Sicherheit</strong> aller Domänenmitglieder<br />
von den DCs abhängt. Falls der Domänencontroller nicht geschützt wird,<br />
können die Mitgliedscomputer unmöglich sicher sein. Ein Angreifer, der die <strong>Sicherheit</strong>skonfiguration<br />
der Domäne ändern kann, kann jeden Computer in der Domäne übernehmen. Er<br />
kann zum Beispiel neue Konten zur Gruppe Administratoren auf einem Mitgliedscomputer<br />
hinzufügen. Das erklärt, warum jede sogenannte Verwundbarkeit, die es einem Administrator<br />
erlaubt, ein System oder Netzwerk zu kompromittieren, nicht wirklich eine <strong>Sicherheit</strong>slücke<br />
ist. Ein Administrator soll schließlich definitionsgemäß vollständigen Zugriff auf das<br />
System oder Netzwerk haben, das er verwaltet.<br />
Abhängigkeiten in Computersystemen lassen sich offensichtlich nicht vermeiden. Das heißt<br />
aber nicht, dass sie grundsätzlich akzeptabel sind: Manche sind akzeptabel und sogar erwünscht,<br />
andere dagegen inakzeptabel. Bevor wird die unterschiedlichen Arten von Abhängigkeiten<br />
untersuchen und uns ansehen, wie sie sich eindämmen lassen, müssen wir erst<br />
einmal wissen, welche Arten von Abhängigkeiten akzeptabel sind und welche nicht.
Einführung in <strong>Sicherheit</strong>sabhängigkeiten 381<br />
Akzeptable Abhängigkeiten<br />
Akzeptable Abhängigkeiten lassen sich mit folgender Regel aus Protect Your <strong>Windows</strong> Network<br />
zusammenfassen:<br />
<strong>Die</strong> <strong>Sicherheit</strong> eines weniger kritischen Systems darf von einem kritischeren System abhängen.<br />
Computer (und Systeme im Allgemeinen) können anhand ihrer <strong>Sicherheit</strong>sanforderungen in<br />
Klassen eingeteilt werden. Ein System, das kritischer ist, hat höhere <strong>Sicherheit</strong>sanforderungen,<br />
und eines, das weniger kritisch ist, benötigt weniger <strong>Sicherheit</strong>. Wie die Klassen in einer<br />
bestimmten Umgebung konkret aussehen, ist für diese allgemeine Beschreibung irrelevant.<br />
Wichtig ist nur, dass es inhärente Klassifizierungen gibt. Nehmen wir aus Gründen der Anschaulichkeit<br />
an, dass wir zwei Klassen von Systemen haben: Arbeitsstationen und Domänencontroller.<br />
<strong>Die</strong> DCs sind offensichtlich viel kritischer als die Arbeitsstationen. Falls Sie<br />
eine Arbeitsstation kontrollieren, dürften Sie theoretisch nur Zugriff auf die Daten bekommen,<br />
die in dieser Arbeitsstation benutzt werden. Falls Sie dagegen einen DC kontrollieren,<br />
haben Sie den Schlüssel zur Stadt: Sie bekommen vollständigen Zugriff auf alle Elemente in<br />
der Gesamtstruktur. In diesem Fall ist es akzeptabel, dass die <strong>Sicherheit</strong> der Arbeitsstationen<br />
von den DCs abhängt. <strong>Die</strong> DC-Klasse ist viel kritischer als die Arbeitsstationen, sie muss<br />
daher entsprechend aufwendiger geschützt werden. <strong>Die</strong>s ist eine Form einer akzeptablen<br />
Abhängigkeit.<br />
Dasselbe gilt für Benutzerkonten. Es ist akzeptabel, dass ein Administrator auf Daten zugreifen<br />
kann, die einem Benutzer gehören, das ist schließlich der Grund, warum es überhaupt<br />
einen Administrator gibt. Administratoren haben uneingeschränkten (wenn auch nicht immer<br />
direkten und offensichtlichen) Zugriff auf den Computer und alles, was sich darauf befindet.<br />
Wenn uns das klar ist und wir die Computer entsprechend verwalten, ergibt sich daraus kein<br />
Problem.<br />
Software kann genauso analysiert werden. Eine weniger kritische Software, zum Beispiel<br />
ein Webbrowser, kann von einer kritischeren Software abhängen, zum Beispiel dem Betriebssystem<br />
selbst. Das ist akzeptabel. Falls das Betriebssystem einen Bug hat, ist es nicht<br />
weiter verwunderlich, wenn der Webbrowser gegen ein neues Problem verwundbar ist.<br />
Wenn das passiert, ist der Webbrowser wahrscheinlich ein recht kleines Problem. Das hilft<br />
uns zu verstehen, wo Bugfixes wirksam werden müssen. Der Bug sollte so nah wie möglich<br />
am Problem beseitigt werden, damit die Schutzwirkung so groß wie möglich ist. Statt das<br />
Problem im Webbrowser zu umgehen, sollten Sie es lieber im Betriebssystem reparieren.<br />
Stattdessen können Sie auch den Webbrowser so umschreiben, dass er weniger Abhängigkeiten<br />
von Funktionalität im Betriebssystem aufweist. <strong>Die</strong>ser Ansatz ist sinnvoll, falls die<br />
Funktionalität im Betriebssystem niemals für den Zweck gedacht war, für den sie eingesetzt<br />
wird, oder falls die Funktionalität gar nicht dazu entworfen wurde, vor dem konkreten Angriff<br />
zu schützen, dem der Webbrowser ausgesetzt ist.<br />
Inakzeptable Abhängigkeiten<br />
Was inakzeptable Abhängigkeiten sind, sollte jetzt offensichtlich sein. Noch einmal ein Zitat<br />
aus Protect Your <strong>Windows</strong> Network:<br />
<strong>Die</strong> <strong>Sicherheit</strong> eines kritischeren Systems darf niemals von einem weniger kritischen System<br />
abhängen.
382 Kapitel 14: Schützen des Netzwerks<br />
Wenn wir wieder Klassen festlegen, um zu bestimmen, wie kritisch ein System ist, lässt sich<br />
diese Aussage leicht verstehen. Falls die Kompromittierung einer Arbeitsstation dazu führt,<br />
dass die <strong>Sicherheit</strong> des Domänencontrollers zusammengebrochen ist, haben wir ein gewaltiges<br />
<strong>Sicherheit</strong>sproblem. Wie bereits erwähnt, ist es unmöglich, ein Netzwerk zu schützen,<br />
falls seine Gesamtsicherheit davon abhängt, dass jeder einzelne Computer in diesem Netzwerk<br />
sicher ist. <strong>Die</strong> Wahrscheinlichkeit, dass das Netzwerk sicher ist, ist umgekehrt exponentiell<br />
zur Größe des Netzwerks. Ein etwas größeres Netzwerk ist praktisch niemals völlig<br />
sicher. Das macht es so wichtig, dass kritischere Systeme vor weniger kritischen geschützt<br />
werden.<br />
<strong>Die</strong>ses Prinzip lässt sich auch auf Benutzerkonten und Software anwenden. Zum Beispiel<br />
erlaubt der neue Terminaldiensteclient für <strong>Windows</strong> die Speicherung von Benutzernamen<br />
und Kennwörtern, um eine praktisch transparente Terminaldiensteanmeldung zu ermöglichen.<br />
<strong>Die</strong>se Anmeldeinformationen werden mithilfe der Credential Manager API gespeichert,<br />
geschützt durch die Anmeldeinformationen, die für die primäre Anmeldesitzung eingegeben<br />
wurden.<br />
Um zu sehen, wie dies eine <strong>Sicherheit</strong>sabhängigkeit erzeugen kann, wollen wir den Fall<br />
betrachten, dass ein Netzwerkadministrator sich an seiner persönlichen Arbeitsstation anmeldet.<br />
Er benutzt diese Arbeitsstation für E-Mail, Webbrowser und andere typische Arbeiten<br />
eines Angestellten im IT-Bereich. Selbstverständlich benutzt er für diesen Zweck ein<br />
Domänenkonto mit geringen Privilegien. Irgendwann an diesem Tag stellt er eine Verbindung<br />
zu einem der Domänencontroller her, um eine Verwaltungsaufgabe durchzuführen. Er<br />
benutzt dafür den Terminaldiensteclient und entscheidet sich, sein Kennwort zu speichern,<br />
damit die Verbindung künftig einfacher hergestellt werden kann. Das erzeugt mindestens<br />
eine, möglicherweise sogar zwei inakzeptable <strong>Sicherheit</strong>sabhängigkeiten. <strong>Die</strong> erste ist, dass<br />
die Anmeldeinformationen für sein administratives Domänenkonto jetzt durch die Anmeldeinformationen<br />
seines Standardbenutzerkontos geschützt werden, das nur geringe Privilegien<br />
hat. Falls sein Standardbenutzerkonto kompromittiert wird, wird auch sein administratives<br />
Domänenkonto kompromittiert, und damit ist die gesamte Domäne kompromittiert.<br />
<strong>Die</strong> zweite Abhängigkeit ergibt sich aus der Tatsache, dass er die Anmeldeinformationen für<br />
ein administratives Domänenkonto auf einem Computer eingibt, der kein Domänencontroller<br />
ist. Sofern seine persönliche Arbeitsstation nicht mindestens genauso gut geschützt ist<br />
wie Domänencontroller (kaum anzunehmen), haben wir eine Abhängigkeitssituation, bei der<br />
die <strong>Sicherheit</strong> des Domänencontrollers von der <strong>Sicherheit</strong> der persönlichen Arbeitsstation<br />
des Benutzers abhängt. Falls zum Beispiel ein verärgerter Angestellter, der im selben Büro<br />
arbeitet, einen Hardware-Keystroke-Logger in der Arbeitsstation des Netzwerkadministrators<br />
installiert hat, sind die Anmeldeinformationen für das administrative Domänenkonto<br />
jetzt in diesem Keystroke-Logger gespeichert. Jedes Mal, wenn Sie Anmeldeinformationen<br />
für ein administratives Domänenkonto auf einem Nicht-Domänencontroller eintippen, haben<br />
Sie die gesamte Domäne allen <strong>Sicherheit</strong>slücken auf diesem Nicht-Domänencontroller ausgesetzt.<br />
Falls zum Beispiel ein Angreifer ein Wechsellaufwerk an einen Computer anschließt,<br />
auf dem ein Domänenadministrator gerade angemeldet ist, auf dem er früher einmal angemeldet<br />
war oder auf dem er sich in Zukunft anmelden wird, ist das Konto des Domänenadministrators<br />
kompromittiert, und damit ist es auch die gesamte Domäne. Es ist absolut unverzichtbar,<br />
dass Sie verstehen, wie diese Abhängigkeiten funktionieren. Nur so können Sie<br />
verhindern, dass sie in Ihrem Netzwerk entstehen. Das heißt zum Beispiel, dass Sie sehr<br />
vorsichtig sein müssen, welche Computer Sie benutzen, um kritische Computer im Netzwerk<br />
zu administrieren.
Einführung in <strong>Sicherheit</strong>sabhängigkeiten 383<br />
<strong>Die</strong>se Analyse führt uns zu zwei ganz konkreten Ratschlägen. Erstens sollten Sie niemals<br />
einen Computer benutzen, um Daten, die kritischer sind als der Computer selbst, einzugeben,<br />
abzurufen, zu verarbeiten oder zu speichern. Denken Sie daran, dass jedes Datenelement,<br />
das von einem Computer verarbeitet wird, unter Umständen jedem offensteht, der<br />
diesen Computer jemals benutzt hat oder benutzen wird. Wenn Sie Anmeldeinformationen<br />
auf einem Computer speichern, bei dem sie allen Benutzern vertrauen, ist das sicher. Wenn<br />
Sie solche Daten auf einem Computer speichern, der möglicherweise von nichtvertrauenswürdigen<br />
Benutzern bedient wird oder auf dem irgendwann Malware installiert werden<br />
könnte, ist das unsicher.<br />
Zweitens sollten Sie niemals einen kritischen Computer von einem Computer aus verwalten,<br />
der weniger kritisch ist. Für die Praxis bedeutet das, dass Sie dedizierte Verwaltungsstationen<br />
verwenden sollten, auf denen hochkritische Computer wie zum Beispiel Domänencontroller<br />
administriert werden. Wenn Sie lediglich runas oder die Benutzerkontensteuerung<br />
(User Account Control, UAC) einsetzen, bietet das keine ausreichende <strong>Sicherheit</strong>.<br />
Dasselbe gilt natürlich für Software. Nehmen wir zum Beispiel an, wir wollen einen hochsicheren<br />
Webbrowser schreiben. <strong>Die</strong>ser Browser soll viel sicherer sein als der integrierte<br />
Browser. In diesem Fall können wir überhaupt keine Funktionen nutzen, die der integrierte<br />
Browser zur Verfügung stellt. Im Fall von <strong>Windows</strong>, wo der Browser einen Großteil der<br />
clientseitigen Internetfunktionalität des Betriebssystems implementiert, dürfen wir nicht<br />
einmal die integrierten URL-Überprüfungsfunktionen (Uniform Resource Locator) oder<br />
irgendwelche HTML-Anzeigefunktionen (Hypertext Markup Language) nutzen, die das<br />
Betriebssystem zur Verfügung stellt, weil dies in Wirklichkeit Komponenten des Internet<br />
Explorers sind. Wenn wir auf Funktionalität zurückgreifen, die der integrierte Browser zur<br />
Verfügung stellt, haben wir eine <strong>Sicherheit</strong>sabhängigkeit vom integrierten Browser. Da unser<br />
Ziel lautet, mehr <strong>Sicherheit</strong> als der integrierte Browser zu bieten, ist diese Abhängigkeit<br />
inakzeptabel.<br />
Abhängigkeitsanalyse eines Angriffs<br />
An diesem Punkt dürfte es nützlich sein, einen kleinen Abstecher zu machen und einen Angriff<br />
aus Sicht der Abhängigkeitsproblematik zu analysieren. Weiter oben haben wir gesehen,<br />
was passieren kann, wenn ein Wechseldatenträger in böser Absicht an den Computer<br />
angeschlossen wird. Weniger offensichtlich ist, was mit dem Netzwerk geschieht, an das<br />
dieser Computer angeschlossen ist. Nehmen wir an, dass der betroffene Computer ein<br />
Domänenmitglied ist, wie in Abbildung 14.1 gezeigt.<br />
Abbildung 14.1 zeigt ein Abhängigkeitsdiagramm für den Idealfall. <strong>Die</strong> Pfeile geben die<br />
Richtung der Abhängigkeit an: <strong>Die</strong> <strong>Sicherheit</strong> der Arbeitsstation hängt von der <strong>Sicherheit</strong><br />
des Domänencontrollers ab, und die <strong>Sicherheit</strong> des Benutzers hängt von der <strong>Sicherheit</strong><br />
der Arbeitsstation ab. Der Angreifer ist möglicherweise in der Lage, die Arbeitsstation zu<br />
kompromittieren, wodurch auch alle Informationen kompromittiert werden, die der Benutzer<br />
auf dieser Arbeitsstation gespeichert hat. Aber die Kompromittierung bleibt auf diesem<br />
Computer isoliert.<br />
Ändern wir das Szenario ein wenig. Nehmen wir an, der Benutzer, der sich an der Arbeitsstation<br />
anmeldet, ist ein Mitglied der lokalen Gruppe Administratoren auf dem <strong>Server</strong>. Und<br />
nehmen wir weiter an, dass sich häufiger ein Domänenadministrator am <strong>Server</strong> anmeldet.<br />
<strong>Die</strong> fetten Pfeile in Abbildung 14.2 stehen für diese neuen Abhängigkeiten.
384 Kapitel 14: Schützen des Netzwerks<br />
Abbildung 14.1 Abhängigkeiten in einer Domäne<br />
Abbildung 14.2 Inakzeptable Abhängigkeiten in einer Domäne<br />
Wie Sie in Abbildung 14.2 erkennen, können wir die <strong>Sicherheit</strong> des gesamten Netzwerks<br />
schlicht dadurch verletzen, dass wir einfach die Annahme ändern, wer sich an welchem<br />
Computer anmeldet. Weil sich ein Domänenadministrator am <strong>Server</strong> anmeldet, hängt die<br />
<strong>Sicherheit</strong> des Domänencontrollers (und damit der Domäne) von der <strong>Sicherheit</strong> des <strong>Server</strong>s<br />
ab. Das wäre akzeptabel, wenn der <strong>Server</strong> genauso sicher verwaltet würde wie der Domänencontroller.<br />
Aber ein Benutzer, der sich an der Arbeitsstation anmeldet, ist ein Mitglied<br />
der Gruppe Administratoren auf dem <strong>Server</strong>, sodass die <strong>Sicherheit</strong> des <strong>Server</strong>s von der Arbeitsstation<br />
abhängt. Abhängigkeiten sind transitiv, das bedeutet, dass nun die <strong>Sicherheit</strong> der<br />
gesamten Domäne von der <strong>Sicherheit</strong> der Arbeitsstation abhängt, wo der Benutzer dummerweise<br />
gerade die böswilligen Tools des Angreifers ausgeführt hat. Aus diesem Grund ist es<br />
so wichtig, dass Sie Ihre Abhängigkeiten richtig verwalten.
Abhängigkeitstypen 385<br />
Abhängigkeitstypen<br />
Sie müssen viele unterschiedliche Arten von Abhängigkeiten verwalten. Einige würden den<br />
Rahmen dieses Buchs sprengen, zum Beispiel inhärente Abhängigkeiten aus der Softwareentwicklung.<br />
Zum Beispiel hängt die <strong>Sicherheit</strong> des Codes auf einer Website davon ab, dass<br />
in den Webbrowsern, die von allen Besuchern benutzt werden, eine geeignete Isolierung<br />
erzwungen wird. Es gibt aber mehrere unterschiedliche Abhängigkeitstypen, die für ein<br />
Netzwerk relevant sind. In diesem Abschnitt will ich sie vorstellen und beschreiben, wie Sie<br />
diese Abhängigkeiten mithilfe von Standardanalysetechniken eindämmen können und wie<br />
diese Techniken in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> implementier t sind.<br />
Nutzungsabhängigkeiten<br />
<strong>Die</strong> erste und einfachste Art der Abhängigkeit ist die Nutzungsabhängigkeit (engl. usage<br />
dependency). Eine Nutzungsabhängigkeit ergibt sich daraus, dass Computerressourcen und<br />
-daten auf eine Weise benutzt werden, die nicht den Vertrauensstufen dieser Ressourcen<br />
entspricht. Das erste Beispielszenario in diesem Kapitel, der Wechseldatenträger, ist ein<br />
Beispiel für eine Nutzungsabhängigkeit. Ein Benutzer, der einen Wechseldatenträger verwendet,<br />
erzeugt eine Nutzungsabhängigkeit auf diesem Gerät. Jedes Mal, wenn ein Benutzer<br />
auf einer Vertrauensstufe eine Ressource verwendet, die sich auf einer anderen Vertrauensstufe<br />
befindet, ergibt sich das Potenzial für Nutzungsabhängigkeiten.<br />
Es gibt auch andere Arten von Nutzungsabhängigkeiten. Ein hervorragendes Beispiel ist die<br />
Nutzung derselben Anmeldeinformationen an mehreren Stellen. Nehmen wir zum Beispiel<br />
an, Ihr Netzwerk ist in eine Datencenter-Gesamtstruktur und eine Unternehmens-Gesamtstruktur<br />
untergliedert. Alle Benutzer in der Datencenter-Gesamtstruktur haben auch Konten<br />
in der Unternehmens-Gesamtstruktur. <strong>Die</strong> Wahrscheinlichkeit, dass zumindest ein Benutzer<br />
für beide Konten denselben Benutzernamen und dasselbe Kennwort verwendet, ist sehr<br />
hoch. Aber das macht den Zweck zunichte, weswegen überhaupt die zwei Gesamtstrukturen<br />
eingeführt wurden: Es sollte sichergestellt werden, dass eine Kompromittierung in einer<br />
Gesamtstruktur nicht dazu führt, dass die andere ebenfalls kompromittiert wird. Indem ein<br />
Befehl dasselbe Kennwort an beiden Stellen verwendet, hat er eine mögliche Verbindung<br />
zwischen den beiden geschaffen. Ein Angreifer, der in einen Computer in einer Gesamtstruktur<br />
einbricht, die dieser Benutzer verwendet, kann den Kennworthashwert extrahieren<br />
und sich damit an Ressourcen in der anderen Gesamtstruktur authentifizieren.<br />
So funktioniert’s: Kennworthashwerte sind klartextäquivalent<br />
Praktisch jedes moderne Computersystem akzeptiert in wenigstens einigen Fällen eine<br />
Kennwortauthentifizierung. In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> (wie schon in älteren <strong>Windows</strong> <strong>Server</strong>-Versionen)<br />
können Sie eine Domäne so konfigurieren, dass Smartcards für die Authentifizierung<br />
bestimmter Benutzer erforderlich sind. Aber aus Kapitel 2, »Authentifizierung<br />
und Authentifizierungsprotokolle«, wissen Sie, dass es sogar in diesem Fall einen<br />
Kennworthashwert für den Benutzer gibt. <strong>Die</strong>ser Hashwert wird jedes Mal, wenn sich der<br />
Benutzer authentifiziert, an den Client übertragen, um einen automatischen Zugriff auf<br />
NTLM-geschützte Ressourcen zu ermöglichen. Das bedeutet, dass ein Angreifer, der<br />
Zugriff auf diesen Hashwert hat, als dieser Benutzer auf Netzwerkressourcen zugreifen<br />
kann. Weitere Informationen dazu finden Sie in Kapitel 2.
386 Kapitel 14: Schützen des Netzwerks<br />
Zugriffsabhängigkeiten<br />
Eine Zugriffsabhängigkeit (engl. access-based dependency) tritt auf, wenn ein Benutzer auf<br />
einer Vertrauensstufe so auf eine Ressource zugreift, dass der Benutzer von der <strong>Sicherheit</strong><br />
dieser Ressource abhängig wird. Zugriffsabhängigkeiten ergeben sich aus dem Zugriff<br />
selbst, nicht aus der Nutzung einer Ressource oder eines Datenverarbeitungsgeräts. Oft ergeben<br />
sie sich daraus, dass ein Benutzer oder eine Entität einer anderen Entität vertraut, bei<br />
der ein <strong>Sicherheit</strong>sproblem besteht.<br />
Nehmen wir zum Beispiel an, Benutzerin Alice greift auf eine Netzwerkressource zu. <strong>Die</strong><br />
Netzwerkressource liegt auf dem <strong>Server</strong> LOKE, der (was Alice nicht weiß) einige Stunden<br />
vorher von Bob gehackt wurde. Bob hat ein Rootkit auf dem <strong>Server</strong> installiert, das dafür<br />
sorgt, dass Authentifizierungen in eine unsichere Form der Authentifizierung umgewandelt<br />
werden. Der Computer von Alice läuft unter <strong>Windows</strong> XP, das standardmäßig so konfiguriert<br />
ist, dass es eine Authentifizierung aushandelt, auf die sich <strong>Server</strong> und Client einigen<br />
können. Dabei sendet Alice eine Frage-Antwort-Sequenz (engl. challenge-response), die der<br />
Angreifer erneut gegenüber dem Computer von Alice abspielen kann, wodurch er sich<br />
Zugriff auf ihren Computer verschafft. Dabei erhält er dieselben Privilegien wie Alice.<br />
Anhand von Abbildung 14.3 können Sie sich diesen Ablauf klarmachen; hier sehen Sie<br />
erst einmal den normalen Authentifizierungsfluss von einem Client zu einem <strong>Server</strong>.<br />
Abbildung 14.3 Ein normaler Frage-Antwort-Fluss von einem Client zu einem <strong>Server</strong>
Abhängigkeitstypen 387<br />
Beim normalen Ablauf baut ein Client eine Verbindung zum <strong>Server</strong> auf. Der <strong>Server</strong> antwortet<br />
mit einer Frage. Der Client generiert die Antwort auf die Frage, indem er eine kryptografische<br />
Operation mit dem Authentifizierer (normalerweise einem Kennworthashwert) und<br />
der Frage durchführt und das Ergebnis als Antwort zurücksendet. Der <strong>Server</strong> führt dieselbe<br />
Berechnung durch und vergleicht die Ergebnisse. Falls sie übereinstimmen, war die Authentifizierung<br />
erfolgreich.<br />
Sehen Sie sich jetzt Abbildung 14.4 an. In diesem Fall antwortet der <strong>Server</strong> nicht, wie er<br />
sollte.<br />
Abbildung 14.4 Mithilfe eines Reflektionsangriffs kann der Client die Frage des<br />
<strong>Server</strong>s an den Client »zurückspiegeln«, um eine gültige Antwort zu erhalten<br />
In Abbildung 14.4 versucht der Client wie zuvor, eine Verbindung herzustellen. An diesem<br />
Punkt sollte der <strong>Server</strong> eine Frage zurücksenden. Aber der <strong>Server</strong> antwortet stattdessen<br />
mit seinem eigenen Verbindungsversuch in Fluss 2. Der Client antwortet auf diesen Verbindungsversuch<br />
mit einer Frage (Fluss 3), die der <strong>Server</strong> wieder zurück an den Client spiegelt,<br />
sodass dies die Frage für die Verbindung wird, die der Client angefordert hat (Fluss 4). Der<br />
Client bekommt also dieselbe Frage, die er ursprünglich hingesendet hat. Ohne dass dem<br />
Client etwas auffällt, berechnet er eine gültige Antwort auf diese Frage, die er selbst ursprünglich<br />
gesendet hat, und schickt sie an den <strong>Server</strong> für die Verbindung zurück, die der<br />
Client eingeleitet hat (Fluss 5). Der <strong>Server</strong> nimmt diese Antwort und gibt sie als Antwort auf<br />
die Frage zurück, die der Client für die eingehende Verbindung (Fluss 6) ausgestellt hat. Das<br />
Ergebnis ist, dass wir jetzt zwei erfolgreiche Verbindungen haben: eine vom Client zum
388 Kapitel 14: Schützen des Netzwerks<br />
<strong>Server</strong> und eine zweite vom <strong>Server</strong> zum Client. <strong>Die</strong>s wird als Reflektionsangriff (engl. reflection<br />
attack) bezeichnet. In <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wird dieser Angriff<br />
durch die statusbehaftete Frage-Antwort-Verwaltung unwirksam gemacht. Das bedeutet,<br />
dass der Computer keine eingehende Frage annimmt, die einer ausstehenden Frage entspricht,<br />
die er selbst gesendet hat. In älteren Versionen lässt sich der Angriff mithilfe verschiedener<br />
<strong>Sicherheit</strong>seinstellungen abwehren.<br />
<strong>Die</strong>ser Angriff funktioniert aufgrund einer Zugriffsabhängigkeit. Es gibt andere Formen<br />
dieser Abhängigkeit. Ein Benutzer könnte an einem öffentlichen Kioskcomputer über Microsoft<br />
Office Outlook-Webzugriff seine E-Mail abrufen. Öffentliche Kioskcomputer sind oft<br />
die am meisten mit Malware verseuchten, am wenigsten vertrauenswürdigen, gefährlichsten<br />
Computer überhaupt. Sie sollten davon ausgehen, dass auf jede Ressource, die Sie in einem<br />
öffentlichen Kioskcomputer verwenden, jeder Benutzer zugreifen kann, der jemals auf diesen<br />
Computer zugegriffen hat oder das in Zukunft tut. Hier entsteht eine Zugriffsabhängigkeit<br />
zwischen der <strong>Sicherheit</strong> des öffentlichen Kioskcomputers (auf die Sie keinen Einfluss<br />
haben) und jeder Ressource, auf die Sie mithilfe von Anmeldeinformationen zugreifen, die<br />
Sie an diesem öffentlichen Computer eingeben.<br />
Administrative Abhängigkeiten<br />
Einer der häufigsten Abhängigkeitstypen ist eine administrative Abhängigkeit (engl. administrative<br />
dependency), die auftritt, wenn dasselbe Konto benutzt wird, um zwei unterschiedliche<br />
Ressourcen zu verwalten. Wenn Sie zum Beispiel ein administratives Domänenkonto<br />
benutzen, um Mitgliedserver zu verwalten (wie in Abbildung 14.2 weiter oben), erzeugen<br />
Sie eine administrative Abhängigkeit. Das mag ganz ähnlich wie eine Nutzungsabhängigkeit<br />
aussehen, und das ist es auch. Aber es gibt einen wichtigen Unterschied: Administrative<br />
Abhängigkeiten müssen nicht nutzungsbasiert sein. Nehmen wir an, dass die<br />
Gruppe Administratoren auf <strong>Server</strong> A die Benutzer Teddy, Maggie und Alex umfasst, und die<br />
Gruppe Administratoren auf <strong>Server</strong> B die Benutzer Maggie, Jesper und Jennifer. Nehmen<br />
wir außerdem an, dass Maggie sich noch nie an <strong>Server</strong> A angemeldet hat. Aber nun wird<br />
<strong>Server</strong> B kompromittiert. Wenn Maggie sich an <strong>Server</strong> B anmeldet, hat der Angreifer, der<br />
<strong>Server</strong> B kompromittiert hat, Zugriff auf die Anmeldeinformationen von Maggie. Er kann<br />
damit nun auch auf <strong>Server</strong> A zugreifen.<br />
<strong>Die</strong>nstkontoabhängigkeiten<br />
<strong>Die</strong>nstkontoabhängigkeiten (engl. service account dependency) treten auf, wenn dieselbe<br />
Identität benutzt wird, um einen <strong>Die</strong>nst an mehreren Orten auszuführen. Nehmen wir an, Sie<br />
setzen eine netzwerkweite EMS (Enterprise Management Solution) ein. Das EMS-Paket<br />
enthält einen Agenten, der auf allen Computern läuft, um die Remotebereitstellung von<br />
Software, Remoteverwaltung und etliche weitere praktische Features zu ermöglichen. Der<br />
Agent läuft unter dem Konto _DomainTools. Das Konto _DomainTools muss offensichtlich<br />
erhöhte Privilegien auf allen Mitgliedcomputern haben, damit diese Art der Remoteverwaltung<br />
möglich ist. Das erzeugt eine <strong>Die</strong>nstkontoabhängigkeit zwischen allen Computern, auf<br />
denen das Konto _DomainTools hohe Privilegien hat. Falls irgendeiner dieser Computer<br />
kompromittiert wird, werden möglicherweise alle kompromittiert, weil der Angreifer jetzt<br />
Zugriff auf ein Konto mit hohen Privilegien hat.
Eindämmen von Abhängigkeiten 389<br />
Betriebsabhängigkeiten<br />
Schließlich haben wir noch die Betriebsabhängigkeit (engl. operational dependency). Betriebsabhängigkeiten<br />
entstehen aufgrund der Art und Weise, wie ein Netzwerk betrieben<br />
wird. Zum Beispiel erzeugt Active Directory automatisch eine Betriebsabhängigkeit. <strong>Die</strong><br />
<strong>Sicherheit</strong> jedes Elements innerhalb einer Gesamtstruktur hängt von der Gesamtstruktur ab.<br />
Falls die Gesamtstruktur kompromittiert wird, gilt dies auch für alle Elemente innerhalb<br />
der Gesamtstruktur. <strong>Die</strong> <strong>Sicherheit</strong> der Gesamtstruktur hängt wiederum von allen Domänen<br />
in der Gesamtstruktur ab. Falls eine Domäne kompromittiert wird, gilt das auch für die<br />
Gesamtstruktur.<br />
<strong>Sicherheit</strong>swarnung <strong>Die</strong> Gesamtstruktur, nicht die Domäne, ist und war immer die <strong>Sicherheit</strong>sgrenze<br />
in Active Directory.<br />
Eine andere sehr häufige Abhängigkeit in einem Netzwerk entsteht durch das Softwareverteilungssystem.<br />
Sehr oft wird eine einzige <strong>Server</strong>freigabe oder ein Satz von DFS-Freigaben<br />
(Distributed File System, Verteiltes Dateisystem) benutzt, um Software an Computer im<br />
Netzwerk zu verteilen. Falls ein Angreifer den oder die <strong>Server</strong> kompromittiert, die diese<br />
Software hosten, werden möglicherweise alle Computer kompromittiert, die Software von<br />
diesen <strong>Server</strong>n erhalten. <strong>Die</strong> Betriebsabhängigkeit hat eine Zugriffsabhängigkeit in den<br />
Softwareverteilungsservern erzeugt.<br />
Kategorien für Abhängigkeiten<br />
Inzwischen ist Ihnen sicherlich aufgefallen, dass die Grenzen zwischen den unterschiedlichen<br />
Abhängigkeitstypen nicht immer deutlich sind und dass eine einzige Abhängigkeit<br />
zu mehreren Kategorien gehören kann. Zum Beispiel ist ein <strong>Die</strong>nstkonto, das auf mehreren<br />
Computern benutzt wird, sowohl eine <strong>Die</strong>nstkontoabhängigkeit als auch eine administrative<br />
Abhängigkeit. <strong>Die</strong> Einteilung der Abhängigkeiten in verschiedene Typen soll es<br />
einfacher machen, damit umzugehen. Der eine Abhängigkeitstyp ist nicht zwangsläufig<br />
wesentlich schlimmer als ein anderer. Einzelne Fälle von Abhängigkeiten können mehr<br />
oder weniger schwerwiegend sein, aber dafür sind die Merkmale dieser konkreten Abhängigkeit<br />
verantwortlich, nicht die Abhängigkeitskategorie, zu der er gehört. Verwenden<br />
Sie die Kategorien als Richtlinie, die Ihnen bei der Vorstellung von der Untergliederung<br />
Ihres Netzwerks hilft, nicht als aufgezwungenes Schema, in das die Dinge unbedingt gezwungen<br />
werden müssen. Falls Sie feststellen, dass eine andere Einteilung für Sie nützlicher<br />
ist, sollten Sie sie ruhig verwenden.<br />
Es gibt hier nur eine Regel: Alles, was Sie tun, sollte die <strong>Sicherheit</strong> Ihres Netzwerks<br />
verbessern.<br />
Eindämmen von Abhängigkeiten<br />
Nachdem Sie fast in der Mitte dieses Kapitels angelangt sind, kommen wir endlich zu der<br />
Frage, wie Sie das Problem lösen. Es hat so lange gedauert, weil die Konzepte, mit denen<br />
wir uns bisher beschäftigt haben, in den meisten Dokumenten zum Thema <strong>Sicherheit</strong> kaum<br />
angesprochen werden. Oft werden diese Probleme nicht einmal am Rand erwähnt.
390 Kapitel 14: Schützen des Netzwerks<br />
Eine der heute wichtigsten Techniken für die Eindämmung von <strong>Sicherheit</strong>sabhängigkeiten<br />
ist die Isolierung von Computern, die nicht miteinander kommunizieren müssen. Dadurch<br />
wird es solchen Computern unmöglich gemacht, überhaupt miteinander zu kommunizieren.<br />
Microsoft bezeichnet dies als <strong>Server</strong>- und Domänenisolierung (engl. server and domain<br />
isolation). Eine entsprechende Strategie lässt sich am besten schrittweise entwickeln:<br />
1. Definieren Sie ein Klassifizierungsschema.<br />
2. Modellieren Sie Ihr Netzwerk.<br />
3. Analysieren Sie Ihr Netzwerkmodell im Bezug auf das Klassifizierungsschema.<br />
4. Passen Sie das Klassifizierungsschema bei Bedarf an und analysieren Sie es erneut.<br />
5. Definieren Sie eine Isolierungsstrategie, die Ihrer Risikomanagementstrategie folgt.<br />
6. Leiten Sie eine Betriebsstrategie aus Ihrer Isolierungsstrategie ab.<br />
7. Bauen Sie eine <strong>Server</strong>implementierung auf Basis Ihrer Isolierungsstrategie auf.<br />
<strong>Die</strong>se 7 Schritte sind deutlich komplizierter, als sie auf den ersten Blick wohl aussehen. Vor<br />
allem müssen Sie sich klarmachen, dass sich dies nicht mal eben an einem ruhigen Nachmittag<br />
erledigen lässt. Sie müssen sich viel eingehender mit der Struktur und den Nutzungsmustern<br />
in Ihrem Netzwerk vertraut machen, als es in den meisten Organisationen üblich ist.<br />
Selbst wenn das einzige Ergebnis darin besteht, dass Sie Ihr Netzwerk besser verstehen,<br />
haben Sie schon eine Menge gewonnen. Der Rest dieses Kapitels beschreibt, wie Sie mithilfe<br />
dieser Konzepte eine <strong>Server</strong>isolierungsstrategie entwerfen und implementieren.<br />
Wichtig Bevor wir fortfahren, müssen wir unbedingt den Begriff <strong>Server</strong>isolierung (engl. server isolation)<br />
genauer definieren. Als Microsoft diesen Begriff prägte, geschah das in Kombination mit dem Begriff Domänenisolierung<br />
(engl. domain isolation). Domänenisolierung bedeutete einfach, dass Sie ein Domänenmitglied<br />
sein mussten, um mit irgendeinem anderen Domänenmitglied kommunizieren zu können (es gab<br />
allerdings ein paar Ausnahmen). <strong>Die</strong>se Art der Isolierung ist recht simpel. Sie ist zwar nützlich, hat aber<br />
auch etliche gewaltige Lücken, weil sie annimmt, dass alle Domänenmitglieder wohlerzogen und nett sind.<br />
<strong>Server</strong>isolierung ist der nächste Schritt. Bei der <strong>Server</strong>isolierung wird bei jedem <strong>Server</strong> der eingehende<br />
Verkehr eingeschränkt, normalerweise mit IPsec, sodass nur der Verkehr zugelassen wird, den der <strong>Server</strong><br />
benötigt, um die vorgesehenen Aufgaben zu erfüllen. Das bietet in der Tat eine sehr gute Isolierung.<br />
Als Microsoft und andere Kunden begannen, diese Isolierungsmechanismen zu implementieren, stellten sie<br />
fest, dass Domänenisolierung zwar ein simples Prinzip ist, die Implementierung der <strong>Server</strong>isolierung aber<br />
deutlich einfacher war, weil IPsec in einem großen Netzwerk sehr schwierig zu beherrschen ist. Daher<br />
begannen sie im Allgemeinen mit der <strong>Server</strong>isolierung.<br />
Was die meisten Beobachter aber bei der <strong>Server</strong>isolierung vergessen, ist die Tatsache, dass jeder <strong>Windows</strong>-Computer<br />
ein <strong>Server</strong> ist. Jede Arbeitsstation führt standardmäßig auch den <strong>Server</strong>dienst aus, und<br />
falls Sie den eingehenden Verkehr nicht einschränken, haben Sie ein Netzwerk, in dem jeder Client jeden<br />
anderen Client angreifen (mit ihm kommunizieren) kann. Das gilt sogar dann, wenn Sie Domänenisolierung<br />
nutzen. Vergessen Sie daher nicht, Clients in Ihre <strong>Server</strong>isolierungsstrategie einzubeziehen.<br />
Schritt 1: Erstellen eines Klassifizierungsschemas<br />
Der erste Schritt beim Erstellen einer <strong>Server</strong>isolierungsstrategie besteht darin, Systeme zu<br />
klassifizieren. Sie können sich das so vorstellen, dass die Netzwerkschutzmechanismen<br />
in einem bestimmten Spektrum angeordnet sind. Nehmen wir zum Beispiel administrative<br />
Konten. Ein Ende des Spektrums besteht darin, ein einziges Konto für alle Aufgaben zu
Eindämmen von Abhängigkeiten 391<br />
benutzen, auf allen Computern, von allen Administratoren. Beim anderen Extrem haben Sie<br />
ein Konto pro Administrator pro Aufgabe pro Computer, mit jeweils gerade so vielen Privilegien,<br />
wie unbedingt nötig sind, um die Aufgabe auszuführen. Auch wenn das erste Beispiel<br />
in der Praxis durchaus vorkommen kann, verletzt es mehr <strong>Sicherheit</strong>sprinzipien, als wir hier<br />
auflisten können. Das zweite Beispiel ist zwar sehr sicher, aber kaum zu verwalten und so<br />
umständlich zu benutzen, dass es wahrscheinlich von allen Beteiligten ignoriert wird. Für<br />
alle anderen Techniken gibt es ähnliche Spektren. Zum Beispiel können Sie beim Einschränken<br />
der Kommunikation natürlich jeden einzelnen Computer analysieren und den<br />
Zugriff auf jeden einzelnen so einschränken, dass er gerade noch seine speziellen Aufgaben<br />
erfüllen kann. Aber in einem Netzwerk mit vielen Tausend Computern ist das praktisch unmöglich.<br />
Sie würden gehackt werden, lange bevor Sie die Analyse abgeschlossen haben.<br />
Weit sinnvoller ist es, ein Klassifizierungsschema zu erstellen. <strong>Die</strong>ses Schema kann beliebig<br />
einfach oder komplex sein. Das Konzept, Computer in Kategorien einzuteilen, ist sinnvoll<br />
für ein Unternehmen. Klassifizierungen können viele Formen annehmen. Im militärischen<br />
Bereich ist es üblich, ein zweidimensionales Klassifizierungsschema zu verwenden, ein<br />
Beispiel sehen Sie in Tabelle 14.1.<br />
Tabelle 14.1 Ein militärisches Klassifizierungsschema<br />
Klasse<br />
Nicht geheim Geheim Streng geheim<br />
Stufe Stufe 1<br />
Stufe 2<br />
Stufe 3<br />
<strong>Die</strong> Klassifizierung im militärischen Stil lässt sich recht leicht so anpassen, dass sie auf<br />
Computer passt. Eine Variante zeigt Tabelle 14.2.<br />
Tabelle 14.2 Systemklassifizierung anhand der Rolle<br />
Klasse<br />
Öffentlich Arbeitsstationen <strong>Server</strong><br />
Stufe Kioskcomputer Arbeitsstationen für Sachbearbeiter Domänencontroller<br />
Infrastrukturserver Entwicklerarbeitsstationen Dateiserver<br />
Tabelle 14.2 zeigt einen Ausschnitt aus einer Computerklassifizierung, die auf der Rolle der<br />
Systeme basiert. Unabhängig davon, wie Sie Ihre Klassifizierungen entwerfen, drängt sich<br />
praktisch immer das Konzept auf, als Basis die Rolle zu nehmen, die der Computer erfüllt.<br />
Je detaillierter Sie das Klassifizierungsschema machen (das heißt, je näher Sie an eine einzige<br />
Rolle kommen), desto sicherer wird die darauf aufbauende Implementierung. Übertreiben<br />
Sie es aber nicht mit dieser Klassifizierung. Erstens müssen Sie Ihr Schema wahrscheinlich<br />
noch einmal überarbeiten, sobald Sie mit der Analyse Ihres Netzwerks beginnen und feststellen,<br />
dass Sie etwas vergessen haben und einige Rollen nicht sonderlich sinnvoll sind.<br />
Zweitens sollten Sie dies als Risikomanagementaufgabe behandeln. Falls Sie ein Klassifizierungsschema<br />
für eine Umgebung mit sehr großen Gefahren entwickeln, ist es angebracht,<br />
mehr ins Detail zu gehen. Falls Sie eine Umgebung mit geringen Gefahren haben, reicht<br />
wahrscheinlich ein gröberes System aus.
392 Kapitel 14: Schützen des Netzwerks<br />
Abbildung 14.5 Ein Klassifizierungssystem im Stil eines Organisationsdiagramms<br />
ist nützlich für komplexe Umgebungen, wo viele Untertypen benötigt werden, um die<br />
<strong>Sicherheit</strong>sanforderungen der Computer angemessen wiederzugeben
Eindämmen von Abhängigkeiten 393<br />
Möglicherweise ist Ihnen aufgefallen, dass ein potenzielles Problem bei der Verwendung<br />
eines zweidimensionalen Klassifizierungssystems, das sich aus dem militärischen Schema<br />
ableitet, darin besteht, dass Sie nicht berücksichtigen können, welche Daten ein bestimmter<br />
Computer eines bestimmten Typ verarbeitet und um welchen <strong>Server</strong>typ es sich handelt. Zum<br />
Beispiel sind nicht alle Datenbankserver gleich. Manche verarbeiten sehr kritische persönliche<br />
Daten, zum Beispiel Ausweisnummer. Andere speichern öffentlich verfügbare Informationen,<br />
zum Beispiel Webseiten, die von allen Benutzern gelesen, aber nur von wenigen<br />
geändert werden können. Wieder andere <strong>Server</strong> können völlig öffentlich sein und werden<br />
einfach als zentrale Temporärordner genutzt. Sie können für jeden Computertyp weitere<br />
Zeilen zur Klassifizierung hinzufügen, aber weil viele Parameter, die Sie auf Computer<br />
innerhalb eines Haupttyps anwenden müssen, sehr ähnlich sind, ist das keine besonders<br />
elegante Methode.<br />
Etwas sauberer lässt sich der Untertyp von Computern berücksichtigen, indem Sie eine andere<br />
Modellierungsmethode verwenden. Ich mag die Abbildung als Organisationsdiagramm.<br />
Es ist unendlich erweiterbar und erlaubt die einfache Definition von Untertypen. Sie können<br />
natürlich auch ein komplizierteres Modellierungsschema verwenden, aber weil ich Übersichtlichkeit<br />
in diesem Punkt wichtiger finde als die Verfügbarkeit von Hunderten von Modellierungskonstrukten,<br />
neige ich dazu, einfache Modellierungsschemas zu verwenden. Wenn<br />
wir ein Organisationsdiagramm als Vorbild nehmen, ergibt sich zum Beispiel ein Aufbau wie<br />
in Abbildung 14.5.<br />
Wie Abbildung 14.5 zeigt, kann ein Klassifizierungsmodell im Stil eines Organisationsdiagramms<br />
schnell sehr groß werden. Daher eignet es sich nicht für alle Umgebungen. Beachten<br />
Sie auch, dass viele Kategorien wahrscheinlich gar keine Computer enthalten. Während<br />
zum Beispiel <strong>Server</strong> eine nützliche abstrakte Klasse ist, sollten ihr keine Computer zugewiesen<br />
werden. Alle Computer sollten einer spezielleren Klasse zugeordnet werden. Bei der<br />
Beschreibung von <strong>Server</strong>rollen (siehe Kapitel 12, »Schützen von <strong>Server</strong>rollen«) kann diese<br />
Art von hierarchischer Zuordnung aber sehr nützlich sein.<br />
Sobald Sie ein vorläufiges Klassifizierungsmodell haben, sollten Sie beginnen, es auf Herz<br />
und Nieren zu prüfen, indem Sie Ihre Analyse durchführen. Eine nützliche Technik für die<br />
Analysephase ist die Netzwerkgefahrenmodellierung, die erstmals in Protect Your <strong>Windows</strong><br />
Network beschrieben wurde.<br />
Schritte 2 und 3: Netzwerkgefahrenmodellierung<br />
Im nächsten Schritt prüfen Sie, wie gut Ihr Klassifizierungsmodell auf die tatsächlichen<br />
Computer in Ihrem Netzwerk passt. Falls Sie noch keine Übersicht Ihres Netzwerks haben,<br />
sollten Sie jetzt eine erstellen. Sie sollte alle wichtigen Elemente in Ihrem Netzwerk aufführen,<br />
allerdings können Sie identische Elemente zu Gruppen zusammenfassen. Das Ziel besteht<br />
darin, Ihnen etwas an die Hand zu geben, was Ihnen zeigt, wie Ihr Netzwerk aussieht.<br />
Abbildung 14.6 zeigt ein Beispiel.<br />
Der nächste Schritt besteht darin, das Klassifizierungsschema auf die Netzwerkübersicht<br />
anzuwenden. Wie Ihnen sicherlich schon aufgefallen ist, basiert Abbildung 14.6 auf dem<br />
Hardwareentwurf des Netzwerks, wobei die Standorte voneinander getrennt sind und es<br />
manche <strong>Server</strong>typen in mehreren Standorten gibt. Bei der Netzwerkgefahrenmodellierung<br />
interessieren wir uns nicht für die einzelnen <strong>Server</strong>. Unser Ziel besteht darin, die Typen von<br />
Computern kennenzulernen, nicht die einzelnen Computer. Zu diesem Zweck nehmen wir<br />
unser Klassifizierungsschema und führen es mit unserer Netzwerkübersicht zusammen.
394 Kapitel 14: Schützen des Netzwerks<br />
Dabei geht wahrscheinlich die Trennung zwischen den Standorten verloren. Aber sofern die<br />
<strong>Sicherheit</strong>sanforderungen ähnlicher Computertypen in unterschiedlichen Standorten gleich<br />
sind, haben wir genau das erreicht, was wir wollten. In dieser Phase versuchen wir, eine<br />
höhere Abstraktionsebene bei unserem Verständnis des Netzwerks zu erreichen. Das Ergebnis<br />
müsste ein Bild wie in Abbildung 14.7 sein.<br />
Abbildung 14.6 Für die Gefahrenmodellierung brauchen Sie eine Übersicht Ihres Netzwerks<br />
Abbildung 14.7 fasst Computer anhand unserer Klassifizierung zu Typen zusammen. Beachten<br />
Sie, dass wir einen neuen Computertyp haben, der bisher noch nicht aufgetaucht ist:<br />
Personalabteilungs-Arbeitsstationen. In diesem Unternehmen haben wir entschieden, dass<br />
wir diese Computer mit besonderer <strong>Sicherheit</strong> ausstatten müssen, weil die Mitarbeiter der<br />
Personalabteilung Zugriff auf vertrauliche Informationen über alle Angestellten haben. Nur<br />
einige wenige Mitglieder des Clientbetriebsteams, das Clients verwaltet, bekommt Zugriff<br />
auf diese Computer. So wird verhindert, dass alle Clientbetriebsmitarbeiter indirekt Zugriff<br />
auf persönliche Daten der Unternehmensangestellten erhalten.
Eindämmen von Abhängigkeiten 395<br />
Abbildung 14.7 Beginnen Sie die Gefahrenmodellierung damit, dass Sie die Netzwerkhierarchie flacher<br />
machen und Computer im Klassifizierungsschema zu Gruppen zusammenfassen<br />
Wenn Sie ein Klassifizierungsschema haben, haben Sie ein wichtiges Zwischenziel bei der<br />
Netzwerkgefahrenmodellierung erreicht. Sie sollten nun in der Lage sein, den verschiedenen<br />
Computertypen Einstufungen bezüglich ihrer Schutzwürdigkeit zuzuweisen. <strong>Die</strong>se Einstufungen<br />
hängen davon ab, welche Art von Daten auf dem Computer gespeichert ist und welche<br />
Art von Zugriff auf andere Computer ein Angreifer bekommt, falls es ihm gelingt, diesen<br />
Computer zu kompromittieren. Ich habe hier numerische Werte verwendet, aber Sie<br />
können natürlich beliebige Einstufungen verwenden.<br />
Domänencontroller sind offensichtlich die wichtigsten Computer von allen. Daher haben sie<br />
die Schutzwürdigkeitseinstufung 10. Für sich genommen bedeutet diese Zahl überhaupt<br />
nichts. Sie dient lediglich dazu, die Schutzwürdigkeit eines Computertyps relativ zu einem<br />
anderen festzulegen. Weil Arbeitsstationen von den meisten Benutzern verwendet werden<br />
und einem hohen Risiko ausgesetzt sind, sollten sie die am wenigsten wichtigen Computer<br />
im Netzwerk sein. Das bedeutet nicht, dass die Gefahr, dass sie angegriffen werden, am<br />
geringsten ist, ganz im Gegenteil: Sie werden am wahrscheinlichsten angegriffen. Daher<br />
sollten sie am unwichtigsten sein. Anders ausgedrückt: <strong>Die</strong>se Computer sollten Ihnen Zugriff<br />
auf möglichst wenig Informationen im Netzwerk verschaffen.<br />
Wenn Sie alle Computer mit einer Einstufung versehen haben, sollten Sie einen recht guten<br />
Eindruck haben, wie die Betriebsmuster im Netzwerk aussehen. Das bildet später die Grundlage<br />
für Ihre Isolierungsstrategie. Vorerst müssen wir mit der Analyse der Kommunikationsmuster<br />
in der Umgebung fortfahren. Dazu stellen wir ein Diagramm zusammen, das ähnlich<br />
wie in Abbildung 14.8 aussieht.
396 Kapitel 14: Schützen des Netzwerks<br />
Abbildung 14.8 Wenn Sie die Systeme zu Gruppen zusammengefasst haben, können Sie ihre<br />
Kommunikationsmuster analysieren<br />
Abbildung 14.8 ist ein einfaches Datenflussdiagramm (Data Flow Diagram, DFD) des<br />
Netzwerks. Das Diagramm in Abbildung 14.7 eignet sich nicht gut, um Kommunikationsmuster<br />
zu dokumentieren. Dagegen ist ein DFD geradezu maßgeschneidert für diesen<br />
Zweck.<br />
Wenn wir ein Netzwerkdiagramm in ein DFD konvertieren wollen, setzen wir erst einmal<br />
die Computertypen in Prozesse um (die Kreise in Abbildung 14.8). Sogar Datenbanken sind<br />
Prozesse, weil in Wirklichkeit der Datenbankserver die Verarbeitung aller Datenbankanfragen<br />
durchführt. Abbildung 14.8 demonstriert auch einen kleinen Trick, der das Bild ver-
Eindämmen von Abhängigkeiten 397<br />
ständlicher macht. Beachten Sie den Prozess namens »Alle Domänenmitglieder«. Er ist als<br />
mehrfache Entität markiert. Er steht für alle Nicht-DC-Computer in der Domäne. Er dient<br />
als ganz einfacher Platzhalter, um das Diagramm übersichtlicher zu machen, sodass wir alle<br />
Kommunikationsmuster erfassen können, die auf allen Computern in der gesamten Domäne<br />
stattfinden. Zum Beispiel müssen alle Computer in der Domäne auf die DCs zugreifen. Statt<br />
Linien von jedem Computertyp zu den DCs zu zeichnen, ziehen wir einfach eine von »Alle<br />
Domänenmitglieder«. Und statt all die unterschiedlichen Verkehrstypen aufzulisten, die<br />
Domänenmitglieder an DCs senden müssen, verwenden wir einen einzigen Pfeil, der mit<br />
»DC-Verkehr« beschriftet ist. Mit diesen Vereinfachungen reicht eine einzige Linie aus,<br />
wofür wir sonst etwa 30 gebraucht hätten.<br />
Tipp Über die Verkehrstypen, die für den Zugriff auf unterschiedliche <strong>Server</strong>typen nötig sind, finden Sie<br />
weitere Informationen im Knowledge Base-Artikel KB 832017, »<strong>Die</strong>nste und Port-Anforderungen für das<br />
Microsoft <strong>Windows</strong>-<strong>Server</strong>system«, unter http://support.microsoft.com/kb/832017.<br />
Beachten Sie auch, dass alle Kommunikationslinien eine Richtung haben. <strong>Die</strong> Tatsache, dass<br />
Domänenmitglieder auf DCs zugreifen müssen, bedeutet nicht, dass DCs umgekehrt auch<br />
auf Domänenmitglieder zugreifen müssen, das ist kaum jemals der Fall. Falls Sie sorgfältig<br />
darauf achten, Ihre DCs nicht als Arbeitsstationen oder Verwaltungsstationen zu benutzen,<br />
müssen Sie von den DCs aus möglicherweise nie auf andere Computer zugreifen.<br />
Schritt 4: Analysieren, waschen und wiederholen, bis sauber<br />
Während Sie die Netzwerkgefahrenmodellierung durchgearbeitet haben, ist Ihnen vielleicht<br />
aufgefallen, dass das Klassifizierungsschema Schwächen hat. Wahrscheinlich gibt es Computertypen,<br />
die nicht benutzt werden, und fast immer stellen Sie fest, dass einige Typen fehlen.<br />
Falls nicht, haben Sie wahrscheinlich die <strong>Sicherheit</strong>sanforderungen Ihrer Systeme nicht<br />
ausreichend durchdacht. Denken Sie daran, dass zwei Faktoren die Basis für das Klassifizierungsschema<br />
bilden: Erstens müssen Sie die Kommunikationsmuster auswerten. Einem<br />
Computer, der nicht auf bestimmte Weise mit einem anderen Computer kommunizieren<br />
muss, sollte das ganz verboten werden. Zweitens sollten Computer mit unterschiedlicher<br />
Schutzwürdigkeitseinstufung unterschiedlich verwaltet werden, um sicherzustellen, dass bei<br />
der Kompromittierung des einen der andere nicht ebenfalls dem Angriff zum Opfer fällt.<br />
Häufig wird der Fehler gemacht, Datenbankserver nicht von Anwendungsservern zu trennen.<br />
Eine ordentlich geschriebene Datenbank-Middleware ruft nur genau definierte Speicherprozeduren<br />
in den Datenbanken auf und verwendet dazu möglichst geringe Privilegien.<br />
Anwendungsserver sind daher meist unkritischer als Datenbankserver. Uneingeschränkter<br />
Zugriff auf einen Datenbankserver bedeutet, dass Sie vollständigen Zugriff auf alle Daten<br />
haben, die darauf gespeichert sind. Uneingeschränkter Zugriff auf einen Anwendungsserver<br />
bedeutet, dass Sie nur Zugriff auf das erhalten, was die Datenbank Ihnen gibt.<br />
Falls das Klassifizierungsschema nicht ausreicht, um den Aufbau Ihres Netzwerks auf geeignete<br />
Weise darzustellen, ist die Lösung einfach: Ändern Sie das Klassifizierungsschema<br />
oder Ihre Annahmen. Das Klassifizierungsschema eignet sich möglicherweise auch nicht für<br />
Ihre Risikomanagementstrategie. In diesem Fall können Sie das Klassifizierungsschema so<br />
ändern, dass es besser zur Risikomanagementstrategie passt. Oder Sie entscheiden, dass Ihre<br />
Risikomanagementstrategie auf dem Papier zwar gut aussieht, aber in der Praxis unmöglich<br />
oder nur mit unvertretbarem Aufwand umzusetzen ist. Viele Organisationen haben eine<br />
Risikomanagementstrategie entwickelt, die in einer Präsentation mit vielen bunten Dia-
398 Kapitel 14: Schützen des Netzwerks<br />
grammen ganz toll aussieht, aber in Wirklichkeit unmöglich zu implementieren ist. Das ist<br />
Ihre Chance zu überprüfen, wie gut Ihre Strategie tatsächlich implementiert werden kann.<br />
Falls Sie keine Risikomanagementstrategie haben, sollten Sie wahrscheinlich diese Gelegenheit<br />
nutzen, um eine zu formulieren.<br />
Hinweis Vielleicht ist Ihnen aufgefallen, dass wir die stillschweigende Annahme gemacht haben, dass es<br />
keinen Unterschied bei der Zugriffsebene auf einen bestimmten Computer gibt. Oder genauer: dass dieser<br />
Unterschied für die Netzwerkgefahrenmodellierung nicht relevant ist. <strong>Windows</strong> bietet aber in beträchtlichem<br />
Umfang Isolierungsmechanismen, die verhindern, dass jemand mit bloßem Standardbenutzerzugriff auf<br />
einen Computer diesen Computer vollständig kontrollieren kann. <strong>Die</strong> Netzwerkgefahrenmodellierung ist<br />
aber ohnehin schon kompliziert genug; wenn wir diesen Faktor auch noch einbeziehen, wird das Modell<br />
noch viel komplexer. Stattdessen gehen wir von einer Worst-Case-Annahme aus: Wir bauen unsere Isolierungstechniken<br />
darauf auf, was ein Angreifer mit vollständiger Kontrolle über einen Computer mit diesem<br />
Computer tun kann. Zum Beispiel: Falls ein Angreifer vollständige Kontrolle über einen Teamworkserver<br />
hat, welchen Zugriff gibt ihm das auf die Datenbankserver? <strong>Die</strong> Antwort hängt davon ab, wie wir das Netzwerk<br />
verwalten (welche Benutzer sich an den Teamworkservern anmelden) und welcher Verkehr zwischen<br />
den beiden Computern erlaubt ist.<br />
Schritt 5: Entwerfen der Isolierungsstrategie<br />
Wenn Sie ein Netzwerkgefahrenmodell haben, das Sinn ergibt, können Sie damit beginnen,<br />
die Isolierungsstrategie abzuleiten. <strong>Die</strong> Isolierungsstrategie basiert in weiten Teilen auf den<br />
Kommunikationsmustern, die Sie in Abbildung 14.8 identifiziert haben. Sie sollten so restriktiv<br />
wie möglich sein, aber natürlich dürfen Sie es nicht übertreiben. Sie können das<br />
Ergebnis in einer Tabelle dokumentieren, die die <strong>Server</strong>typen und Kommunikationsmuster<br />
aufführt. <strong>Die</strong> Tabelle listet auf: Quell- und Zielhosts, Ports, Protokolle, ob der Verkehr authentifiziert<br />
und/oder verschlüsselt sein muss und ob die Verbindung auch in umgekehrter<br />
Richtung (gespiegelt) verlaufen kann. Hier wird es wirklich konkret. Statt einfach »DC-<br />
Verkehr« zu sagen, müssen Sie die Ports und Protokolle auflisten. Eine sehr nützliche <strong>Referenz</strong><br />
für diese Phase ist der Microsoft Knowledge Base-Artikel 832017, »<strong>Die</strong>nste und Port-<br />
Anforderungen für das Microsoft <strong>Windows</strong>-<strong>Server</strong>system«.<br />
Das Endergebnis dieses Schritts sollte eine Tabelle sein, die alle erforderlichen Kommunikationsmuster<br />
in Ihrem Netzwerk auflistet. Ihre Tabelle sollte ähnlich wie Tabelle 14.3 aussehen,<br />
aber natürlich wird sie viel länger sein.<br />
Wie Sie sehen, können die Daten in dieser Tabelle recht umfangreich werden. Aber wenn<br />
Sie das Netzwerk angemessen untergliedert haben, müsste das Zusammenstellen der Daten<br />
mühsam, aber nicht schwierig sein. Wenn Sie damit fertig sein, haben Sie die IPsec-Implementierung<br />
der <strong>Server</strong>isolierung in Ihrem Netzwerk fast abgeschlossen. Beachten Sie, dass<br />
die Spaltenüberschriften in Tabelle 14.3 genau die Informationen wiedergeben, die Sie für<br />
Ihre IPsec-Regeln brauchen. Wenn Sie echte Initiative zeigen wollen, können Sie Tabelle 14.3<br />
in eine Tabellenkalkulation eingeben und sie dann mit einem Makro in einer Reihe von<br />
IPsec-Befehlen konvertieren, die die erforderlichen IPsec-Richtlinien generieren. Sie können<br />
IPsec auf der Befehlszeile konfigurieren, indem Sie den Befehl netsh advfirewall consec add<br />
rule aufrufen. Weitere Informationen zu IPsec finden Sie auf der Microsoft-IPsec-Site unter<br />
http://technet.microsoft.com/en-us/network/bb531150.aspx.
Tabelle 14.3 Netzwerkkommunikationsmuster<br />
Beschreibung Quelle Ziel Quell-<br />
port<br />
DC-SMB-Verkehr Alle Domänen-<br />
mitglieder<br />
DC-RPC-EP-<br />
Mapper<br />
. . .<br />
Anwendungsserver- <br />
Datenbankzugriff<br />
Alle Domänen-<br />
mitglieder<br />
SharePoint-<br />
<strong>Server</strong><br />
Dateiserverzugriff Arbeitsstationen <br />
Personalabteilungs- <br />
Lohnbuchhaltungs-<br />
zugriff<br />
. . .<br />
Personal-<br />
abteilungs-<br />
Arbeitsstationen<br />
Ziel-<br />
port<br />
Eindämmen von Abhängigkeiten 399<br />
Protokoll<br />
Authentifizierung<br />
verpflichtend<br />
Verschlüsselung<br />
verpflichtend<br />
Gespiegelt<br />
Alle DCs Alle 445 TCP Nein Nein Nein<br />
Alle DCs Alle 135 TCP Nein Nein Nein<br />
SharePoint-<br />
Datenbankserver<br />
Dateiserver Alle (139),<br />
445<br />
Buchhaltungs-<br />
server<br />
Alle 1433 TCP Ja Nein Nein<br />
TCP Ja Nein Nein<br />
Alle 80 TCP Ja Ja Nein<br />
Beachten Sie, dass diese Art der Analyse einige Zeit braucht. Es ist nicht ungewöhnlich,<br />
dass bei einem Computer um die 50 Ports offen sind. Je standardisierter Ihre Betriebssystemabbilder<br />
sind, desto einfacher ist es, die benötigten Informationen zusammenzustellen.<br />
Wenn Sie diese Art Analyse einmal begonnen haben, wird Ihnen garantiert bewusst, wie<br />
wertvoll es ist, wenn die Softwarehersteller übersichtlich dokumentieren, welche Ports für<br />
welche Features benutzt werden.<br />
Schritt 6: Ableiten einer Betriebsstrategie<br />
<strong>Die</strong> Betriebsstrategie baut darauf auf, wie Sie die verschiedenen Computer in Ihrem Netzwerk<br />
verwalten. <strong>Die</strong> Strategie muss die administrativen Anforderungen der Computer sowie<br />
alle <strong>Die</strong>nste und anderen Schritte widerspiegeln, die Sie durchführen. Zum Beispiel brauchen<br />
Sie wahrscheinlich irgendeine Datensicherungsstrategie für Ihr Netzwerk. Falls Sie<br />
aber ein einzelnes, zentralisiertes Datensicherungssystem für alle Computer einsetzen, haben<br />
Sie wahrscheinlich einen großen Teil der Isolierung zerstört, weil Sie jetzt einen Datensicherungsserver<br />
haben, der Zugriff auf alles im Netzwerk hat und seinerseits von jedem Computer<br />
im Netzwerk angegriffen werden kann. Daher sollten Sie das Risiko analysieren, das ein<br />
solcher Schritt mit sich bringt. <strong>Die</strong>se Analyse könnte zu der Entscheidung führen, Computer<br />
lieber anhand ihrer Schutzwürdigkeit zu Gruppen zusammenzufassen und die Datensicherungen<br />
dann innerhalb jeder Schutzwürdigkeitsstufe durchzuführen. Sie können zum Beispiel<br />
eine einzige Datensicherungslösung für alle Computer mit der Schutzwürdigkeitsstufe 6<br />
einrichten.
400 Kapitel 14: Schützen des Netzwerks<br />
<strong>Die</strong>selbe Analyse müssen Sie für die Administration durchführen. Es würde dem Zweck der<br />
ganzen Aktion zuwiderlaufen, wenn Sie ein einziges administratives Domänenkonto verwenden,<br />
um auf alle Computer in der Domäne zuzugreifen. Damit setzen Sie das eine administrative<br />
Konto Angriffen durch alle Computer aus. <strong>Die</strong> logische Folgerung lautet, unterschiedliche<br />
Administratorkonten für unterschiedliche Zwecke zu verwenden. Sie könnten<br />
zum Beispiel ein Konto pro Schutzwürdigkeitsstufe verwenden. Oder Sie weisen Ihren Systemadministratoren<br />
unterschiedliche Schutzwürdigkeitsstufen zu. Dann können Sie unterschiedliche<br />
Systemadministratoren unterschiedlichen Computern zuweisen, statt allen zu<br />
erlauben, sämtliche Computer zu verwalten. Sie können sogar separate Administrationsstationen<br />
für jede Schutzwürdigkeitsstufe einrichten. Sie müssen entscheiden, wie viel Mühe<br />
Sie auf sich zu nehmen bereit sind, um Ihr Netzwerk zu verwalten. <strong>Die</strong>se Entscheidung ist<br />
eine wichtige Basis für alle weiteren Entscheidungsprozesse. In Bezug auf <strong>Sicherheit</strong> müssen<br />
Sie (wie überall) einen Kompromiss zwischen mehr <strong>Sicherheit</strong> und mehr Arbeitsaufwand<br />
finden. Dabei müssen Sie aber immer im Auge behalten, welche Funktionalität Sie<br />
letztendlich brauchen. Vor allem müssen Sie bei diesem Prozess sicherstellen, dass Sie die<br />
Isolierung auf eine Weise implementieren, bei der Sie Computer einer Schutzwürdigkeitsstufe<br />
keinen unnötigen Angriffen durch Computer auf einer anderen Schutzwürdigkeitsstufe<br />
aussetzen.<br />
Schritt 7: Implementieren von Einschränkungen<br />
Nun ist endlich der Punkt gekommen, an dem Sie Ihre Strategie implementieren. In dieser<br />
Phase des Prozesses sollten Sie einen vollständigen Entwurf haben, der die Verwaltung Ihres<br />
Netzwerks beschreibt und angibt, welche Kommunikationsmuster Sie innerhalb des Netzwerks<br />
erlauben wollen. <strong>Die</strong> Implementierung sollte ab hier recht einfach sein. Sie müssen<br />
allerdings sicherstellen, dass bestimmte Dinge auch erledigt werden.<br />
Wenn es Ihnen wie den meisten Netzwerkmanagern geht, bricht Ihnen der Angstschweiß<br />
aus, wenn es daran geht, Änderungen durchzuführen, die die gesamte Kommunikation zum<br />
Erliegen bringen könnten. Wie jeder leidgeplagte Administrator weiß, ruft niemand beim<br />
Helpdesk an, um mitzuteilen, dass heute alles einwandfrei funktioniert (falls doch, haben Sie<br />
ganz andere Probleme vor sich).<br />
Glücklicherweise gibt es einen Trick. Offensichtlich wollen Sie, dass irgendwann bei allen<br />
oder den meisten Netzwerkverbindungen Authentifizierung zwingend erforderlich ist. Aber<br />
Sie können damit beginnen, dass Sie stattdessen erst einmal die Authentifizierung anfordern.<br />
Auf diese Weise können Sie die Richtlinien testen, überwachen, wo die IPsec-Aushandlung<br />
fehlschlägt, und bei Bedarf Korrekturen vornehmen. Dabei bleibt die Konnektivität vollständig<br />
erhalten. Sie können auf diese Weise eine sicherere Bereitstellung durchführen, bei<br />
der die Gefahr viel geringer ist, dass unerfreuliche Dinge geschehen und Ihre Chancen auf<br />
das Ausscheiden aus dem Netzwerkmanagement entscheidend sinken.<br />
Nach diesen Vorbemerkungen hier eine Reihe anderer Einschränkungen, die Sie in Ihrem<br />
Plan berücksichtigen müssen.<br />
Minimieren des Gültigkeitsbereichs von Konten<br />
Verringern Sie den Gültigkeitsbereich Ihrer Konten. Das gilt besonders für Konten mit hohen<br />
Privilegien. Jeder, der auf Computer unterschiedlicher Schutzwürdigkeitseinstufungen<br />
zugreift, sollte auf diesen Computern jeweils eigene Konten haben, zumindest wenn sie<br />
höhere Privilegien auf diesen Computern haben. Zum Beispiel könnte ein sehr vertrauens-
Eindämmen von Abhängigkeiten 401<br />
würdiger <strong>Server</strong>administrator ein administratives Domänenkonto für die Verwaltung der<br />
DCs brauchen, ein administratives Konto der Stufe 7 für die Verwaltung der <strong>Server</strong> auf<br />
Schutzwürdigkeitsstufe 7 und ein normales Benutzerkonto für E-Mail und Websurfen. Ein<br />
Angestellter der Personalabteilung braucht ein Konto für seine direkten Aufgaben und ein<br />
anderes Konto, mit dem er E-Mail liest und Präsentationen erstellt. Stattdessen können Sie<br />
auch angesichts Ihrer Risikomanagementphilosophie und der Tatsache, dass beide auf einer<br />
sehr niedrigen Privilegebene liegen, entscheiden, dass in diesem Fall ein einziges Konto<br />
genügt. Sie sollten aber niemals erlauben, dass ein Konto, das administrative Privilegien auf<br />
einer Schutzwürdigkeitsstufe besitzt, dazu benutzt wird, um auf Ressourcen auf einer anderen<br />
Schutzwürdigkeitsstufe zuzugreifen. Administrative Konten auf jeder Stufe dürfen nur<br />
benutzt werden, um Computer auf dieser Stufe zu verwalten.<br />
Änderungen an der <strong>Sicherheit</strong>srichtlinie der Organisation<br />
Ein großer Teil der Isolierung ergibt sich aus <strong>Sicherheit</strong>srichtlinien der Organisation, nicht<br />
unbedingt aus <strong>technische</strong>n Richtlinien. Viele Isolierungsentscheidungen lassen sich einfach<br />
nicht technisch erzwingen. Zum Beispiel sind Ihre Domänen-Admins innerhalb des Bereichs<br />
Ihres Netzwerks allmächtig. Sie können nicht verhindern, dass sie im Netzwerk alles sehen<br />
oder tun können. Sie können aber Regeln und Richtlinien festlegen, die sie befolgen müssen,<br />
und die Einhaltung dieser Richtlinien überwachen. Sie müssen auch Strafen für den Fall<br />
festsetzen, dass diese Richtlinien verletzt werden. Ein Administrator, der sich weigert, die<br />
nötigen Schritte zu unternehmen, um Ihr Netzwerk zu schützen, sollte sich bald auf dem<br />
freien Arbeitsmarkt wiederfinden.<br />
Separate <strong>Die</strong>nstkonten<br />
<strong>Die</strong>nstkonten sind ein häufiges Problem in <strong>Windows</strong>. Es ist allgemein bekannt, dass jeder<br />
Administrator eines beliebigen Computers Zugriff auf das Klartextkennwort aller <strong>Die</strong>nste<br />
(und aller interaktiver Benutzer) auf diesem Computer hat. Es gibt keine Standardprotokolldatei,<br />
wo diese wertvollen Informationen gespeichert sind, aber mit allgemein verfügbaren<br />
Hackingtools ist es kein Problem, an diese Daten zu gelangen.<br />
Aus diesem Grund ist es so wichtig, <strong>Die</strong>nstkonten richtig zu verwalten. Es ist immer noch<br />
recht verbreitet, dass <strong>Die</strong>nste, die auf vielen Computern in einem Netzwerk laufen, unter<br />
dem Konto eines Domänenadministrators ausgeführt werden. Das macht das Konto eines<br />
Domänenadministrators auf jedem Computer im Netzwerk zugänglich. Aus diesem Grund<br />
muss der Gültigkeitsbereich von <strong>Die</strong>nstkonten eingeschränkt werden. Eine naheliegende<br />
Möglichkeit besteht darin, <strong>Die</strong>nstkonten nur innerhalb einer Schutzwürdigkeitsstufe zu verwenden.<br />
Zum Beispiel könnte der oben erwähnte Datensicherungsdienst auf Computern der<br />
Schutzwürdigkeitsstufe 7 unter einem <strong>Die</strong>nstkonto und auf Computern der Stufe 9 unter<br />
einem anderen Konto ausgeführt werden.<br />
Wollen Sie eine Datensicherung für Arbeitsstationen?<br />
Wollen Sie wirklich eine Datensicherung für Arbeitsstationen durchführen? Viele Organisationen<br />
diskutieren heutzutage über diese Frage. Benutzer speichern natürlich Daten auf<br />
ihren Arbeitsstationen, aber wollen Sie das wirklich? Im Idealfall sollten nur sehr wenige<br />
Daten, die nirgends sonst im Netzwerk vorhanden sind, auf den Arbeitsstationen liegen.<br />
Mithilfe von Techniken wie zum Beispiel servergespeicherten Benutzerprofilen und Ordnerumleitung<br />
können die Standardspeicherorte für Benutzer in das Netzwerk gelegt werden.
402 Kapitel 14: Schützen des Netzwerks<br />
Mit Offlinedateien werden diese Dateien automatisch im Netzwerk gesichert, stehen den<br />
Benutzern aber auch offline zur Verfügung, während sie unterwegs sind. Mit einer Kombination<br />
dieser Strategien können Sie sicherstellen, dass auf Arbeitsstationen nur noch<br />
zwei Arten von Daten liegen, die gesichert werden müssen: solche, die Benutzer erstellt<br />
haben, während sie nicht mit dem Netzwerk verbunden waren, und Daten, die sie aus<br />
irgendwelchen Gründen lokal speichern <strong>–</strong> möglicherweise unter Verletzung von Standardbetriebsvorschriften.<br />
Wenn Sie dann noch (zum Beispiel) eine robuste Abbildstrategie<br />
und die <strong>Windows</strong>-Bereitstellungsdienste nutzen, sind Sie an einem Punkt angelangt, wo<br />
Sie keine Daten von Arbeitsstationen mehr sichern müssen. Unter Umständen müssen Sie<br />
noch nicht einmal eine aufwendige Problembehandlung durchführen. Falls bei einer Arbeitsstation<br />
etwas schiefgeht, gehen Sie bei der Problembehandlung genauso vor wie bei<br />
<strong>Server</strong>n. <strong>Die</strong>ser simple Prozess sieht folgendermaßen aus:<br />
1. Sie starten den <strong>Die</strong>nst neu, sofern in diesem Fall zutreffend.<br />
2. Falls dies das Problem nicht beseitigt, starten Sie den Computer neu.<br />
3. Falls dies das Problem nicht beseitigt, spielen Sie ein neues Abbild auf dem Computer<br />
ein.<br />
4. Falls dies das Problem nicht beseitigt, senden Sie den Computer zurück an den Hersteller<br />
und stellen neue Hardware bereit.<br />
Wenn Sie sich nicht um Daten kümmern müssen, die auf Arbeitsstationen gespeichert<br />
sind, können Sie sie im Notfall einfach verwerfen.<br />
Beachten Sie, dass es Disziplin erfordert, bis zu diesem Punkt zu gelangen. Sie brauchen<br />
auch Hardware, die Ihnen erlaubt, eine solche Strategie zu implementieren. <strong>Die</strong>s ist aber<br />
eine Geschäftsentscheidung, die Sie treffen müssen. Wollen Sie Ihre Desktopbetriebsprozeduren<br />
dramatisch vereinfachen, müssen Sie geeignete Hardware und Software kaufen<br />
und einige wirklich große Speicherserver anschaffen. Oder scheuen Sie die Investition<br />
und nehmen dafür komplizierte und teure Desktopbetriebsprozeduren in Kauf?<br />
Verwalten von Privilegien<br />
Sie dürfen nicht vergessen, Ihre Privilegien richtig zu verwalten, wenn Sie Ihre Isolierungsstrategie<br />
implementieren. Benutzer mit bestimmten Privilegien können genauso viel Macht<br />
haben wie Administratoren. Zum Beispiel ist ein Benutzer, das das Privileg Annehmen der<br />
Clientidentität nach Authentifizierung besitzt, genauso mächtig wie jeder Benutzer, der im<br />
Remotezugriff eine Verbindung zum Computer herstellt. Ein Benutzer, das das Privileg Wiederherstellen<br />
von Dateien und Verzeichnissen besitzt, kann jede beliebige Datei auf dem<br />
Computer ersetzen. Weil der Benutzer damit Code kontrolliert, der von Administratoren<br />
ausgeführt wird, hat ein solcher Benutzer implizit dieselben Rechte wie Administratoren.<br />
Aus diesem Grund ist es sehr sinnvoll, Sicherungs-Operatoren von Wiederherstellungs-<br />
Operatoren zu trennen. <strong>Die</strong>s sind zwei unterschiedliche Aufgaben, die auf ganz unterschiedlichen<br />
Schutzwürdigkeitsstufen liegen. Privilegien werden in Kapitel 3, »Objekte: Was Sie<br />
wollen«, beschrieben.<br />
Einschränken der Kommunikation<br />
Nach unserer Beschäftigung mit der Netzwerkgefahrenmodellierung sollte offensichtlich<br />
sein, dass wir die Kommunikation einschränken wollen. In diesem Schritt nutzen wir IPsec
Zusammenfassung 403<br />
und <strong>Windows</strong>-Firewall, um eingehenden Verkehr auf einem Computer einzuschränken. Das<br />
verringert die Gefahr, die einem System von anderen Systemen droht, ganz gewaltig. Nehmen<br />
wir zum Beispiel einen Datenbankserver, auf den ein Middlewareserver zugreift. Nehmen<br />
wir nun an, es gibt eine SQL-Injection-Lücke in der Middleware, die es einem Angreifer<br />
ermöglicht, beliebigen Code auf dem Datenbankserver auszuführen. Welchen Zugriff hat<br />
der Angreifer auf den Middlewareserver, wenn der Datenbankserver einmal kompromittiert<br />
wird? Falls Sie die <strong>Windows</strong>-Firewall auf dem Middlewareserver so eingerichtet haben, dass<br />
sie allen unangefordert eingehenden Verkehr verwirft (genauer gesagt: nur genau den Verkehr<br />
annimmt, der für die eigentliche Aufgabe erforderlich ist), lautet die Antwort »gar keinen«.<br />
Sie können den Angriff direkt an dieser Stelle aufhalten. Verwenden Sie die vorher erstellte<br />
Tabelle mit Ihren Kommunikationsmustern und entwerfen Sie auf dieser Basis einen<br />
Satz von IPsec-Richtlinien. Stellen Sie diese Richtlinien mithilfe von Gruppenrichtlinien<br />
oder einer anderen Methode bereit, die in Ihrer Umgebung sinnvoll ist. Weitere Informationen<br />
über <strong>Windows</strong>-Firewall und IPsec sowie die Bereitstellung von Richtlinien finden Sie in<br />
Kapitel 5, »<strong>Windows</strong>-Firewalls«.<br />
Einschränken des Ressourcenzugriffs<br />
Zuletzt können Sie das Detailwissen, das Sie sich erarbeitet haben, und die Isolierungsstrategie,<br />
die Sie entworfen haben, dazu nutzen, eine Daten- und Ressourcenzugriffstrategie zu<br />
erstellen, die das Prinzip der geringstmöglichen Rechte erzwingt. Sie müssten an diesem<br />
Punkt über eine ziemlich detaillierte Benutzerkontenstrategie verfügen. Sie können dies<br />
nutzen, um Zugriff zu verhindern und die Isolierungsstrategie zu erzwingen. Nehmen wir<br />
zum Beispiel an, dass vor dem Start dieses Projekts die Mitarbeiter Ihrer Personalabteilung<br />
Zugriff auf die Exchange-<strong>Server</strong>, alle Dateiserver, die internen SharePoint-<strong>Server</strong> und die<br />
Lohnbuchhaltungsanwendungen hatten <strong>–</strong> alles über das eine Konto, das Sie ihnen gegeben<br />
haben. Nachdem Sie die Isolierungsstrategie definiert haben, verfügen Sie über die Möglichkeit,<br />
ihnen den Zugriff auf Lohnbuchhaltungsanwendungen nur zu erlauben, wenn sie<br />
ihre Personalabteilung-Konten verwenden <strong>–</strong> und möglicherweise sogar nur dann, wenn sie<br />
auf einer bestimmten Arbeitsstation in der Personalabteilung arbeiten.<br />
Zusammenfassung<br />
Nur wenige Strategien, die Ihnen heutzutage zur verfügung stehen, haben so große Auswirkungen<br />
auf die <strong>Sicherheit</strong> Ihres Netzwerk und seiner Daten wie eine ordentliche Netzwerkuntergliederung<br />
und <strong>Server</strong>isolierungsstrategie. Indem Sie den in diesem Kapitel beschriebenen<br />
Prozess durcharbeiten, können Sie ein Netzwerk erstellen, das genau das tut, was Sie<br />
wollen, aber nichts anderes. Falls Sie keine Fehler machen, ist das Netzwerk trotzdem noch<br />
so flexibel, dass es neue Anwendungen unterstützt. Dafür sind nur geringfügige Änderungen<br />
notwendig.<br />
Hat diese Strategie auch Auswirkungen auf die Aufgaben Ihrer Endbenutzer und Administratoren?<br />
Ganz bestimmt. Aber in der Umgebung, in der wir uns heute bewegen, könnte das die<br />
einzige Möglichkeit sein, Ihr Netzwerk zu schützen. Der herkömmliche Ansatz, ein völlig<br />
flaches Netzwerk aufzubauen, in dem jeder ein Konto hat, das ihm Zugriff auf alles verschafft,<br />
was er braucht, aber auch auf viel mehr, ist in praktisch allen modernen Umgebungen<br />
zu unsicher. Wie weit Sie sich von diesem Modell absetzen können, hängt von Ihrer<br />
Risikotoleranz und den <strong>Sicherheit</strong>sanforderungen in Ihrer Umgebung ab.
404 Kapitel 14: Schützen des Netzwerks<br />
Weitere Informationen<br />
Johansson, J. M.: Protect Your <strong>Windows</strong> Network. (Addison-Wesley, 2005).<br />
Knowledge Base-Artikel 832017, »<strong>Die</strong>nste und Port-Anforderungen für das Microsoft<br />
<strong>Windows</strong>-<strong>Server</strong>system« unter http://support.microsoft.com/kb/832017.<br />
»The Immutable Laws of Security« unter http://www.microsoft.com/technet/archive/<br />
community/columns/security/essays/10imlaws.mspx?mfr=true.
K A P I T E L 1 5<br />
Schützen von Zweigstellen<br />
Von Byron Hynes<br />
In diesem Kapitel:<br />
Einführung in die Probleme von Zweigstellen . ................................ 405<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle . ................................... 409<br />
Andere <strong>Sicherheit</strong>smaßnahmen . ......................................... 426<br />
Zusammenfassung .................................................. 427<br />
Weitere Informationen ................................................ 427<br />
In diesem Kapitel untersuchen wir die Probleme einer Zweigstelle und sehen uns an, mit<br />
welchen Lösungen, Techniken und Tools sie sich bewältigen lassen. Wir beginnen damit,<br />
dass wir die Merkmale einer Zweigstelle definieren und untersuchen, warum sie besondere<br />
Schwierigkeiten verursacht. Dann sehen wir uns einige der üblichen Szenarien für die<br />
Optimierung der Infrastruktur an, die für Zweigstellen relevant sein können. Wir gehen die<br />
Features in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> durch, die Zweigstellen unterstützen, und zeigen auf,<br />
welche besonders dabei helfen können, Zweigstellen zu schützen. Dabei konzentrieren wir<br />
uns auf die schreibgeschützten Domänencontroller (Read Only Domain Controller, RODC)<br />
und die BitLocker-Laufwerkverschlüsselung.<br />
Einführung in die Probleme von Zweigstellen<br />
IT-<strong>Sicherheit</strong> erweckt oft den Eindruck, dass es dabei um sorgfältig gewartete Datencenter<br />
geht, in denen IT-Experten ständig danach streben, Richtlinien, Prozeduren, Einstellungen<br />
und Software zu verbessern, um die physischen und informations<strong>technische</strong>n Aktiva in ihrer<br />
Verantwortung zu schützen. Nur wenige Leute dürfen mit ihren Smartcards das Allerheiligste<br />
betreten, wo Reihen ordentlich ausgerichteter Computer effizient vor sich hinbrummen,<br />
während sie sorgfältig überwacht werden.<br />
Viele unserer Leser <strong>–</strong> Sie vermutlich auch <strong>–</strong> streben danach, diese Art Umgebung einzurichten.<br />
Aber ist Ihnen klar, dass ein Drittel der IT-Budgets für Zweigstellen oder Remotestandorte<br />
ausgegeben wird? Zwischen einem Viertel und einem Drittel der <strong>Server</strong>, die unter <strong>Windows</strong><br />
<strong>Server</strong>-Software laufen, sind an Orten installiert, die wir als Zweigstelle bezeichnen.<br />
Zweigstellen (engl. branch office) finden sich in vielen verschiedenen Umgebungen. Ich<br />
habe für einen Kunden in der Fastfoodbranche gearbeitet, der <strong>Windows</strong>-<strong>Server</strong> in Tausenden<br />
Restaurants hatte, über die ganze USA verteilt. Ein Kollege von mir arbeitete an einem Active<br />
Directory-Entwurfs- und -Bereitstellungsprojekt mit Domänencontrollern in jeder der<br />
800 Zweigstellen einer großen europäischen Bank. Zweigstellen können Verkaufsfilialen<br />
sein, Arztpraxen, Hotels <strong>–</strong> vielleicht sogar das Büro im Kindergarten oder der Grundschule<br />
Ihrer Kinder, wo eine Angestellte festhält, wer heute anwesend ist.<br />
405
406 Kapitel 15: Schützen von Zweigstellen<br />
Warum sind Zweigstellen wichtig?<br />
Zweigstellen werden nicht so bald verschwinden, ganz im Gegenteil. In Zweigstellen wird<br />
eine Großteil der Aufträge eines Unternehmens an Land gezogen (oder auch nicht), und dort<br />
werden die eigentlichen <strong>Die</strong>nste von gemeinnützigen Organisationen und Behörden erbracht.<br />
Neben Onlinediensten werden vor allem in Zweigstellen Geschäftsdaten gesammelt<br />
und interpretiert, und dort erwarten mündige Verbraucher, dass das Personal vor Ort Entscheidungen<br />
treffen kann.<br />
Leider gibt es aber auch eine Reihe von Merkmalen, die den Nutzen von Zweigstellen einschränken<br />
oder sich sogar negativ auswirken sein können.<br />
Was ist anders in einer Zweigstelle?<br />
Zweigstellen gibt es in vielen unterschiedlichen Formen, aber die meisten haben folgende<br />
Merkmale gemeinsam:<br />
Remoteanbindung über ein WAN Während die Netzwerkgeschwindigkeiten ständig<br />
steigen, hängen die meisten Zweigstellen von einem extern kontrollierten Netzwerk ab,<br />
zum Beispiel einer Standleitung, Frame-Relay-Verbindung oder einem gemeinsam genutzten<br />
Glasfasernetz. Manche Zweigstellen sind nur über das öffentliche Internet angebunden,<br />
wobei sie ein virtuelles privates Netzwerk (VPN) einsetzen. Wenn Sie von<br />
einem anderen Unternehmen abhängig sind, zum Beispiel einem Telefon- oder Netzwerkanbieter,<br />
haben Sie keine Kontrolle darüber, was mit Ihren Daten in diesem Netzwerk<br />
passiert.<br />
Geringere physische <strong>Sicherheit</strong> <strong>Server</strong> in Zweigstellen werden nur selten mit demselben<br />
Maß an physischer <strong>Sicherheit</strong> geschützt wie die in einem Datencenter des Unternehmens.<br />
Ich hoffe, dass Ihre <strong>Server</strong> nicht unter dem Empfangstisch in einem öffentlich<br />
zugänglichen Bereich oder auf einem Regal in der Toilette stehen, aber ich habe beides<br />
schon erlebt.<br />
Mangel an kompetentem IT-Personal vor Ort In einer Zweigstelle, besonders in<br />
kleinen, stellen Sie oft fest, dass ein Mitarbeiter mit nur geringen oder überhaupt keinen<br />
IT-Kenntnissen die Pflege Ihrer <strong>Server</strong> in der Zweigstelle »erbt«. Das kann ein Filialleiter<br />
sein (oder der höchstrangige Angestellte am Standort), der lokale Technikbegeisterte<br />
oder sogar der Mitarbeiter, der »immer da« ist und niemals in einem Meeting herumhängt.<br />
Entfernung Nicht nur gibt es in einer Zweigstelle oft keine IT-Experten, auch geografisch<br />
ist die Zweigstelle oft weit vom IT-Support entfernt. Vielleicht ist es nicht einmal<br />
möglich, einen Ihrer eigenen Analytiker oder Techniker innerhalb von ein, zwei Tagen<br />
zum Standort zu bringen.<br />
Reduzierte Infrastruktur Im Unterschied zum Datencenter mit seiner Klimaanlage,<br />
einer ausfallsicheren Stromversorgung und mehreren Kommunikationspfaden wurden<br />
Zweigstellen oft nicht mit demselben Maß an Fehlertoleranz entworfen. Das betrifft sowohl<br />
die IT-Systeme als auch die kommunale Infrastruktur, zum Beispiel Strom und<br />
Kommunikation.<br />
Zweigstellen sind zunehmendem Druck ausgesetzt, darunter Kosten- und Leistungsdruck,<br />
dem Druck, <strong>Sicherheit</strong> zu gewährleisten, die ständig anschwellenden Gesetze und Regularien<br />
zu erfüllen und agil und schnell auf Geschäftsbedürfnisse zu reagieren. Zum Beispiel
Einführung in die Probleme von Zweigstellen 407<br />
haben Zweigstellen hohe Kosten für die Wartung komplexer, heterogener und oft nicht<br />
integrierter Hardwaresätze. Dazu kommt, dass hohe Kosten auftreten, wenn bei Bedarf<br />
IT-Support angefordert wird, entweder vom Datencenter oder vielleicht von teuren lokalen<br />
Supportdienstleistern. Natürlich wissen Zweigstellenmanager (und sicherlich das Verwaltungsteam<br />
in der Zentralstelle), welche Gefahren durch Datenverlust oder Angriffe gegen<br />
das System drohen und welche Schwierigkeit eine Wiederherstellung nach einem Ausfall<br />
und der Schutz der lokal gesammelten Daten bereiten. (Warum sollte ein Angreifer auch auf<br />
Jespers perfekt gehärtete <strong>Server</strong> losgehen <strong>–</strong> Sie wissen schon, die in seinem Datencenter, die<br />
rund um die Uhr von bewaffnetem Werkschutz bewacht werden <strong>–</strong>, wenn ein viel unsicherer<br />
<strong>Server</strong> in der lokalen Zweigstelle steht.)<br />
Aber trotz all dieser Schwierigkeiten ist zu erwarten, dass Zweigstellen immer mehr Informationen<br />
als »Point of Service« verwalten, wo die Daten gesammelt, analysiert und benutzt<br />
werden, um sofortige Ergebnisse zu liefern, während sie aber trotzdem ständig über das<br />
gesamte Unternehmen synchronisiert bleiben. Ich erinnere mich noch daran, wie ich als<br />
Teenager ein Bankkonto eröffnet habe. Das wurde von Hand in einem Kontenbuch verzeichnet.<br />
Und natürlich konnte ich nur in dieser einen Zweigstelle an mein Konto. Ich kann<br />
mir kaum vorstellen, dass Banken heutzutage mit einer solchen Einschränkung konkurrenzfähig<br />
wären! (Und damit Sie jetzt nicht glauben, ich wäre steinalt, sollte ich hinzufügen,<br />
dass ich schnell zu einer Konkurrenzbank wechselte, die Computer hatte und ihre <strong>Die</strong>nste in<br />
allen Zweigstellen verfügbar machte.)<br />
Alles in allem stellt eine Zweigstelle geringe Herausforderungen an einen kompetenten IT-<br />
Experten. Sie brauchen lediglich Remotedaten zu schützen und darauf zuzugreifen, Systeme<br />
schützen und sichere Konnektivität bei kaum vorhandenem Vor-Ort-Support, einfachen<br />
Datensicherungen und effizienter Nutzung von Hardware und Bandbreite zur Verfügung zu<br />
stellen. Und natürlich müssen Sie gleichzeitig Ihre Infrastruktur verbessern, schnell neue<br />
Fähigkeiten zur Verfügung stellen und eine Plattform für die Zukunft bereitstellen, dabei<br />
aber die Kompatibilität gewährleisten. (Uff!)<br />
IDC beschreibt es folgendermaßen:<br />
Zweigstellen streben oft nach einem hohen Maß an Flexibilität und Selbständigkeit bei der<br />
Implementierung von IT-Lösungen. <strong>Die</strong> Ausweitung der Unternehmensanforderungen erfordert<br />
aber eine zentralisierte Verwaltung, verbesserte <strong>Sicherheit</strong> und Einhaltung zahlreicher<br />
Regeln.<br />
Quelle: IDC White Paper, »Addressing Operational Efficiencies in Branch Office« vom Mai<br />
2006, zu finden unter http://download.microsoft.com/download/6/d/0/6d032455-bf07-42acb006-ee0e4c8ab606/idc_branch_whitepaper.pdf.<br />
Aufbauen von Zweigstellen<br />
Eine Reihe von Entwurfsszenarien befasst sich mit der Situation von Zweigstellen. Im<br />
Grunde reichen sie von einem oder mehrere riesigen <strong>Server</strong>n in der Zweigstelle bis zum<br />
Konzept »keine <strong>Server</strong> in der Zweigstelle, wir machen alles im Remotezugriff«. Wie Sie<br />
sich denken können, hat jeder dieser Lösungsansätze seine Stärken und Schwächen.<br />
Damit ich noch etwas Platz in diesem Kapitel übrig habe, um etwas über das Schützen von<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in einer Zweigstelle zu schreiben, biete ich hier nur einen knappen<br />
Überblick über die Entwurfsansätze. Einige dieser Ansätze sind sehr verbreitet, andere werden<br />
nur selten genutzt. Manche werden beliebter, weil die Kosten sinken und sich neue
408 Kapitel 15: Schützen von Zweigstellen<br />
Technologien verbreiten. Und viele Zweigstellen nutzen eine Kombination von Elementen<br />
aus mehreren der folgenden Optionen.<br />
Virtualisierte <strong>Server</strong> in der Zweigstelle Ein <strong>Server</strong>, der ein virtuelles <strong>Server</strong>abbild<br />
für jede Aufgabe ausführen kann, bietet maximale Flexibilität und Konfigurierbarkeit.<br />
Bei einer solchen Lösung können alle Aufgaben und <strong>Die</strong>nste auf einem einzigen physischen<br />
<strong>Server</strong>computer betrieben werden. <strong>Die</strong>se Option eignet sich am besten, wenn es<br />
zahlreiche eigenständige <strong>Server</strong> gibt, die in einer einzigen Einheit konsolidiert werden<br />
können. <strong>Die</strong>nste werden intern ausgeführt, um 100 Prozent Uptime und Funktionalität<br />
sicherzustellen, sogar wenn WAN (Wide Area Network) oder VPN offline sind. Indem<br />
Sie nur einen <strong>Server</strong> verwalten, können Sie die Verwaltung und Datensicherung ein<br />
Stück weit zentralisieren.<br />
Einzelner <strong>Server</strong> Wird ein <strong>Server</strong> verwendet, bietet das den Vorteil, dass zwar ein<br />
<strong>Server</strong> in der Zweigstelle vorhanden ist, es werden aber die Kosten und die Komplexität<br />
für die Unterstützung von Virtualisierung und <strong>Server</strong>konsolidierung eingespart. In diesem<br />
Fall können <strong>Die</strong>nste, die ständig verfügbar sein müssen oder möglichst niedrige<br />
Latenz erfordern, innerhalb der Zweigstelle ausgeführt werden, während andere im<br />
Datencenter zentralisiert werden. Sie müssen einen Kompromiss zwischen Abhängigkeit<br />
von WAN-Uptime, Remoteverwaltung, zentralisierter Datensicherung und lokaler<br />
Reaktionsfähigkeit finden.<br />
Zweigstellen-Appliances Zweigstellen-Appliances sollen eine vollständige Lösung<br />
zur Verfügung stellen, die einfach bereitzustellen und problemlos zu konfigurieren ist.<br />
<strong>Die</strong>se Geräte stellen üblicherweise WAN-Beschleunigung und HTTP-Komprimierung<br />
bereit und machen es einfacher, Aufgaben wie zum Beispiel Speicherung und Datenbanken<br />
zu zentralisieren. <strong>Die</strong> Zweigstellen-Appliances sind bereits mit einigen Branchenanwendungen<br />
oder anderen <strong>Die</strong>nsten ausgestattet, sodass die Zweigstelle auch während<br />
eines WAN-Ausfalls weiterarbeiten kann. Appliances sind oft so entworfen, dass sie die<br />
Verbindung zu einem WAN herstellen oder das Internet für VPN-Verbindungen nutzen.<br />
Sichere Zentralisierung Bei diesem Entwurf wird der <strong>Server</strong> aus der Zweigstelle<br />
entfernt und alle Aufgaben werden zentralisiert. Anwendungsvirtualisierung (wie sie<br />
zum Beispiel von Microsoft SoftGrid Application Virtualization zur Verfügung gestellt<br />
wird) wird eingesetzt, damit LOB-Anwendungen (Line Of Business) im Datencenter<br />
verarbeitet, aber auf dem lokalen Desktop ausgeführt werden. Das verringert den Aufwand<br />
für die Bereitstellung und Verwaltung von Updates für diese virtualisierten Anwendungen.<br />
Eine <strong>Sicherheit</strong>-Appliance, also eine intelligente Firewall oder ein Gateway,<br />
ermöglicht sichere Konnektivität (inklusive Paketfilterung und VPN-Zugriff) mit dem<br />
Datencenter.<br />
Keine Infrastruktur In diesem Fall hat die Zweigstelle schlicht gar keine <strong>Server</strong> oder<br />
aufwendige Netzwerkhardware. Alle sind von der Netzwerkkonnektivität mit dem Datencenter<br />
abhängig, das die gesamte Bürofunktionalität am Remotestandort zur Verfügung<br />
stellt. Im Grunde ist jeder ein Netzwerkclient. Angestellte im Remotebüro sind<br />
entweder über ein WAN an dasselbe Unternehmensnetzwerk angeschlossen wie die<br />
Zentralstelle oder sie stellen über VPN eine Verbindung zum Datencenter her, um auf<br />
Anwendungen zuzugreifen. Manchmal werden auch alle Zweigstellenbenutzer als Internetbenutzer<br />
behandelt und die Anwendungen werden über geschützte Internetprotokolle<br />
verfügbar gemacht. Dabei reduziert sich die Bereitstellung der Remoteinfrastruktur auf<br />
ein bloßes Minimum, und eine Verwaltung von Remoteservern ist nicht mehr nötig.
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 409<br />
Microsoft bietet eine Reihe von Produkten und Lösungen für Zweigstellen an. Außerdem<br />
gibt es einen ausführlichen Leitfaden zur Infrastrukturoptimierung (IO), der Ihnen hilft, eine<br />
effektive und sichere Remote- oder Zweigstelleninfrastruktur auszuwählen und aufzubauen.<br />
Im Rest dieses Kapitels konzentrieren wir uns auf die Features und Verbesserungen in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong>, die für Zweigstellen relevant sind, insbesondere auf diejenigen, die direkt<br />
mit der <strong>Sicherheit</strong> der Zweigstelle zu tun haben. Weitere Informationen über Zweigstellen<br />
im Allgemeinen und den Einsatz von <strong>Windows</strong> <strong>Server</strong>-Produkten in Zweigstellen finden Sie<br />
unter http://technet.microsoft.com/en-us/branchoffice/default.aspx.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle<br />
<strong>Die</strong> Verbesserung der Situation in Zweigstellen war eines der wichtigsten Ziele bei der Entwicklung<br />
von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. Etliche Features in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> sollen Probleme<br />
von Zweigstellen in drei Bereichen beseitigen: Kosten, <strong>Sicherheit</strong> und Flexibilität.<br />
Tabelle 15.1 fasst die Features in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zusammen, die Schwierigkeiten von<br />
Zweigstellen beseitigen helfen.<br />
Tabelle 15.1 Zweigstellentypische Schwierigkeiten und Lösungen in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Schwierigkeit Anforderung <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Features<br />
Kostenkontrolle<br />
Reduzieren der Kosten für Verwaltung und Support<br />
in Zweigstellen (inklusive möglichst effizienter<br />
Nutzung von Netzwerkverbindungen)<br />
<strong>Server</strong> Core-Installation<br />
Schreibgeschützter Domänencontroller (RODC)<br />
<strong>Server</strong> Message Block (SMB) 2.0<br />
Datensicherheit (Sicherung)<br />
<strong>Windows</strong> <strong>Server</strong>-Virtualisierung<br />
<strong>Sicherheit</strong> Verbessern der <strong>Sicherheit</strong> von Daten und Zugriff BitLocker-Laufwerkverschlüsselung<br />
Schreibgeschützter Domänencontroller (RODC)<br />
<strong>Server</strong> Message Block (SMB) 2.0<br />
Flexibilität Bereitstellen einer flexiblen Infrastruktur, die die<br />
IT-Investitionen optimal nutzt<br />
<strong>Server</strong> Message Block (SMB) 2.0<br />
TCP/IP-Neuentwurf<br />
Features, die nicht mit <strong>Sicherheit</strong> zu tun haben<br />
Ich möchte hier vor allem <strong>Sicherheit</strong>sfeatures vorstellen, aber einige andere Features verdienen<br />
ebenfalls eine Erwähnung. Schließlich ist es oft schwierig <strong>–</strong> und normalerweise kontraproduktiv<br />
<strong>–</strong>, <strong>Sicherheit</strong>saspekte völlig isoliert zu betrachten. Wenn Sie wissen, wie alle Teile<br />
zusammenpassen, können Sie effektiver sein <strong>–</strong> und das bringt mehr <strong>Sicherheit</strong>.<br />
Praktisch betrachtet ist es auch sehr sinnvoll, wenn Sie sich bemühen, Ihre Netzwerklösungen<br />
kostengünstig, agil, zuverlässig und verfügbar zu halten. Wenn Ihre Lösungen die Anforderungen<br />
(oder Erwartungen) der Endbenutzer nicht erfüllen, suchen Ihre Endbenutzer<br />
(und insbesondere das Management) nach provisorischen Lösungen oder Abkürzungen.<br />
<strong>Die</strong>se Abkürzungen sind nur äußerst selten sicher. Das soll nicht heißen, dass diese Benutzer<br />
böswillig sind. Sie werden allerdings einen Umweg um Sie oder Ihre <strong>Sicherheit</strong> machen,<br />
wenn die Verfahren, die Sie implementiert haben, nicht das erlauben, was die Benutzer<br />
brauchen oder was Sie glauben zu brauchen.
410 Kapitel 15: Schützen von Zweigstellen<br />
<strong>Server</strong> Core-Installation<br />
<strong>Server</strong> Core ist eine minimalistische <strong>Server</strong>installationsoption für <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, die<br />
nur einen Teil der ausführbaren Dateien enthält und nur wenige <strong>Server</strong>rollen zur Verfügung<br />
stellt. <strong>Server</strong> Core läuft auf 32-Bit- oder 64-Bit-Architekturen.<br />
Ich betrachte <strong>Server</strong> Core als <strong>Sicherheit</strong>sfeature, weil es die Angriffsfläche des <strong>Server</strong>s verringert.<br />
Es sind nur die ausführbaren Dateien vorhanden, die für die Rolle und das Basisbetriebssystem<br />
erforderlich sind. Das bedeutet, dass im Allgemeinen weniger Prozesse laufen.<br />
Aber <strong>Server</strong> Core senkt auch die Kosten, weil es die Wartungs- und Verwaltungsanforderungen<br />
verringert.<br />
<strong>Die</strong> <strong>Server</strong> Core-Installationsoption installiert nur einen Teil der ausführbaren Dateien und<br />
DLLs (Dynamic-Link Library). Konkret werden nur die Features installiert, die für 9 bestimmte<br />
<strong>Server</strong>rollen erforderlich sind. Unter den Komponenten, die nicht installiert werden,<br />
sind die grafische Benutzeroberfläche (Graphical User Interface, GUI), die .NET Framework-CLR<br />
(Common Language Runtime), die <strong>Windows</strong>-Explorer-Benutzeroberfläche und<br />
Internet Explorer. Weil es keine GUI gibt, müssen Administratoren auf alle <strong>Die</strong>nste über<br />
eine lokale Befehlsshell zugreifen, entweder im Remotezugriff von einem Verwaltungsserver<br />
oder einer Arbeitsstation aus (mit einer Remotebefehlsshell oder einem Remotetool wie<br />
zum Beispiel einem MMC-Snap-In), mithilfe des neuen Remoteverwaltungsfeatures namens<br />
WS-Verwaltung oder mithilfe der WMI (<strong>Windows</strong> Management Instrumentation).<br />
Einer der größten Vorteile einer <strong>Server</strong> Core-Installation ist, dass der Bedarf für Updates<br />
sinkt. Während Updates der Schrecken aller IT-Experten im Datencenter sind, hält das Aktualisieren<br />
von Remote- und Zweigstellen seine eigenen Probleme bereit. Aufgrund von Vergleichen<br />
mit <strong>Windows</strong> <strong>Server</strong> 2003 schätzt Microsoft, dass auf eine <strong>Server</strong> Core-Installation<br />
weniger als 60 Prozent der Updates angewendet werden müssen, die bei einer vollständigen<br />
Installation von <strong>Windows</strong> <strong>Server</strong> erforderlich sind (das gilt für den hypothetischen Fall, es<br />
gäbe in <strong>Windows</strong> <strong>Server</strong> 2003 eine solche Installationsoption). <strong>Server</strong> Core ist in Kapitel 12,<br />
»Schützen von <strong>Server</strong>rollen«, genauer beschrieben.<br />
Hyper-V (<strong>Windows</strong> <strong>Server</strong>-Virtualisierung)<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Hyper-V, früher als <strong>Windows</strong> <strong>Server</strong>-Virtualisierung bezeichnet, ist<br />
eine Virtualisierungsplattform, die Flexibilität über eine dynamische, zuverlässige und skalierbare<br />
Plattform zur Verfügung stellt. Sie können einen einzigen Satz integrierter Verwaltungstools<br />
benutzen, um sowohl physische als auch virtuelle <strong>Server</strong>ressourcen zu verwalten.<br />
Hyper-V ist in den meisten <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Lizenzen enthalten, aber Sie müssen es<br />
eventuell separat von Microsoft herunterladen.<br />
Eine vollständige Beschreibung der Virtualisierung würde den Umfang dieses Kapitels<br />
sprengen. Aber weil viele Zweigstellenszenarien von der <strong>Server</strong>virtualisierung profitieren,<br />
sollten Sie sich darüber im Web unter http://www.microsoft.com/windowsserver<strong>2008</strong>/<br />
virtualization/default.mspx informieren.<br />
Durchgreifende Überarbeitung des TCP/IP-Stacks<br />
Auch als »Next Generation TCP/IP Stack« bezeichnet, bietet der verbesserte Netzwerkstack<br />
in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista einige direkte Vorteile für eine Zweigstelle.<br />
Indem die Netzwerkkommunikation zwischen <strong>Server</strong>n im Datencenter und der Zweigstelle<br />
sowie zwischen Remoteclients und zentralisierten <strong>Die</strong>nsten verbessert wurde, können Sie<br />
die Nutzung der WAN-Verbindungen maximieren.
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 411<br />
Unter <strong>Sicherheit</strong>saspekten sollten Sie folgende Bereiche der neuen TCP/IP-Funktionalität<br />
kennen:<br />
Erweiterte IPsec-Integration und einfachere IPsec-Verwaltungstools<br />
TCP/IP umfasst eine integrierte Filterungsplattform. <strong>Windows</strong> nutzt diese Plattform für<br />
<strong>Windows</strong>-Firewall und IPsec, aber auch andere Anwendungen und Hersteller können auf<br />
die <strong>Windows</strong>-Filterplattform (<strong>Windows</strong> Filtering Platform, WFP) zugreifen.<br />
<strong>Die</strong>se beiden Punkte werden in Kapitel 5, »<strong>Windows</strong>-Firewalls« und Kapitel 14, »Schützen<br />
des Netzwerks«, genauer beschrieben. Außerdem wurde der überarbeitete TCP/IP-Stack<br />
online in TechNet ((http://technet.microsoft.com/en-us/network/bb545475.aspx) und in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> <strong>–</strong> TCP/IP-Protokolle und -<strong>Die</strong>nste von Joseph Davies (Microsoft Press,<br />
<strong>2008</strong>) ausführlich beschrieben.<br />
<strong>Server</strong> Message Block<br />
Zum Bereich Konnektivität und Protokolle gehört auch, dass <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ein<br />
neues Remotedateifreigabeprotokoll mitbringt: <strong>Server</strong> Message Block 2.0 (SMB 2.0). SMB<br />
ist das Protokoll, das im Allgemeinen zwischen <strong>Windows</strong>-Computern benutzt wird, zum<br />
Beispiel <strong>Windows</strong> XP, <strong>Windows</strong> Vista, <strong>Windows</strong> <strong>Server</strong> 2003 und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>.<br />
SMB 2.0 verbessert die Skalierbarkeit gegenüber SMB 1.0 ganz deutlich und vergrößert die<br />
Zahl offener Dateien sowie erlaubter Freigaben. <strong>Die</strong> Protokolle wurden so verbessert, dass<br />
sie weniger Verwaltungsdaten durch die Gegend schicken, was die Dateifreigabe in einem<br />
WAN manchmal recht mühsam macht. Praxisnahe Tests haben gezeigt, dass große Dateien<br />
mit SMB 2.0 bis zu 35 Mal schneller kopiert werden als mit SMB 1.0. Allerdings werden<br />
die Vorteile von SMB 2.0 nur sichtbar, wenn die Kommunikation zwischen <strong>Windows</strong> <strong>Server</strong><br />
<strong>2008</strong>-Computern oder zwischen <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista-Clients stattfindet.<br />
SMB 2.0 ist nicht separat für ältere <strong>Windows</strong>-Betriebssysteme erhältlich.<br />
Über die WAN-Leistungsoptimierungen in SMB 2.0 erfahren Sie mehr im TechNet-Webcast<br />
»Wide Area Network Performance Improvements in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>« unter<br />
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=<br />
1032348651&CountryCode=US.<br />
Datensicherheit: <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> <strong>Server</strong>-Sicherung<br />
Vergessen Sie nicht, dass zur <strong>Sicherheit</strong> auch gehört, Daten verfügbar zu halten und sie nach<br />
Ausfällen wiederherstellen zu können. <strong>Die</strong> <strong>Windows</strong> <strong>Server</strong>-Sicherung nutzt den Volumeschattenkopie-<strong>Die</strong>nst<br />
(Volume Shadow Copy Service, VSS) und Datensicherungstechnologie<br />
auf Blockebene, um Ihre <strong>Server</strong> lokal oder im Remotezugriff mit weniger Ausfallzeit zu<br />
sichern. Außerdem wurde Unterstützung für die Sicherung auf optische Medien (DVD) und<br />
andere Dateiserver hinzugefügt.<br />
<strong>Sicherheit</strong>sfeatures für die Zweigstelle<br />
Zwei wesentliche Komponenten von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> haben direkte Auswirkung<br />
auf die <strong>Sicherheit</strong> Ihrer Zweigstellen: schreibgeschützte Domänencontroller (Read-Only<br />
Domain Controller, RODC) und BitLocker-Laufwerkverschlüsselung.
412 Kapitel 15: Schützen von Zweigstellen<br />
RODC<br />
RODC ist ein neues Feature in den Active Directory-Domänendiensten (Active Directory<br />
Domain Services, AD DS) von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. In Kapitel 9, »Optimieren der Active<br />
Directory-Domänendienste für <strong>Sicherheit</strong>«, finden Sie einen Überblick über AD DS-Features<br />
und Informationen über die Nutzung und Installation von RODCs. In diesem Kapitel<br />
will ich mich darauf konzentrieren, die <strong>Sicherheit</strong>saspekte eines RODCs in einer Zweigstelle<br />
zu beschreiben.<br />
Schreibgeschützte Datenbank, Replikation und Gruppenzugehörigkeiten<br />
Wie der Name andeutet, sind RODCs schreibgeschützte Kopien der AD DS-Datenbank.<br />
Das bedeutet, dass sie nur eine unidirektionale Replikation in Active Directory benötigen.<br />
Dasselbe gilt für den Dateireplikationsdienst und DFS-Replikation (Distributed File System<br />
Replication).<br />
Unidirektionale Replikation bedeutet einen <strong>Sicherheit</strong>svorteil. Wenn aufgrund einer Kompromittierung<br />
oder anderer Probleme manipulierte Daten in die lokale Kopie der AD DS-<br />
Datenbank auf dem RODC eingeschleust werden, können diese Daten nicht vom betroffenen<br />
RODC zurück in die übrige Organisation repliziert werden. Das ist sicherlich eine Eindämmung,<br />
die verhindern kann, dass ein lokales Problem zu einem globalen wird! Trotzdem<br />
müssen Sie aufpassen: Falls Malware, Angriffe oder andere Probleme dazu führen können,<br />
dass ihr lokaler Domänencontroller manipuliert oder von einem Angreifer übernommenen<br />
wurde (auch wenn er schreibgeschützt ist), haben Sie trotzdem ein gewaltiges Problem zu<br />
lösen!<br />
Es wurden zusätzliche Anstrengungen unternommen, um die Probleme zu minimieren, die<br />
durch einen manipulierten RODC verursacht werden könnten. Jeder RODC hat sein eigenes,<br />
einmaliges KrbTGT-Konto für das Schlüsselverteilungscenter (Key Distribution Center,<br />
KDC), sodass das System unterscheiden kann, ob ein Ticket von einem RODC ausgestellt<br />
wurde (und von welchem) oder von einem normalen, beschreibbaren Domänencontroller.<br />
<strong>Die</strong>s ist eine Form der kryptografischen Isolierung; diesen Begriff werden Sie gelegentlich<br />
im Zusammenhang mit RODCs hören.<br />
Unidirektionale Replikation bringt auch Vorteile für den Entwurf Ihrer Replikationstopologie<br />
und die Steuerung des Replikationsverkehrs. Bridgeheads und Hubs brauchen den RODC<br />
nicht nach Änderungen abzufragen. Der RODC führt die normale eingehende Replikation<br />
für AD DS und FRS sowie alle DFSR-Änderungen aus.<br />
Weil der RODC Mitglied der Domäne ist, hat er manchmal gute Gründe, um in Active Directory<br />
zu schreiben. Er schreibt aber nicht in die lokale Datenbankkopie, sondern stellt eine<br />
Verbindung zu einem beschreibbaren DC her, genau wie eine Arbeitsstation. Das RODC-<br />
Computerkonto ist ein Arbeitsstationskonto, daher hat es nur sehr eingeschränkte Rechte<br />
beim Schreibzugriff auf AD DS. Auch das soll wieder die Schäden im Unternehmens-AD<br />
DS minimieren für den Fall, dass der RODC kompromittiert wird. Weil RODC-Computerkonten<br />
in diesem Sinne »Arbeitsstationen« sind, sind sie keine Mitglieder der Gruppen<br />
Domänencontroller der Organisation oder Domänencontroller.<br />
Zwischenspeicherung von Datenbankinhalt und Anmeldeinformationen<br />
Mit Ausnahme der Kontokennwörter und der Attribute, die speziell zum gefilterten Attributsatz<br />
hinzugefügt wurden, speichert ein RODC alle AD DS-Objekte und -Attribute, die auch<br />
ein beschreibbarer Domänencontroller speichert.
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 413<br />
Lokale Anwendungen, die Lesezugriff auf die Verzeichnisinformationen der Domäne anfordern,<br />
können direkt auf den RODC zugreifen, während LDAP-Anwendungen (Lightweight<br />
Directory Access Protocol), die einen Schreibzugriff anfordern, einen LDAP-Verweis als<br />
Antwort erhalten. <strong>Die</strong>se Antwort verweist sie direkt an einen beschreibbaren Domänencontroller,<br />
der sich normalerweise an einem zentralen Standort befindet.<br />
In der Domänendatenbank hat jeder <strong>Sicherheit</strong>sprinzipal (Benutzer, Computer oder iNet-<br />
OrgPerson) einen Satz von bis zu 10 Kennwörtern oder Geheimnissen, die generell als Anmeldeinformationen<br />
(engl. credentials) bezeichnet werden. Ein RODC speichert diese Anmeldeinformationen<br />
nicht, abgesehen von seinem eigenen Computerkonto und dem speziellen<br />
krbtgt-Konto für jeden RODC. Der RODC wird als Schlüsselverteilungscenter für seinen<br />
Standort angekündigt, der normalerweise die Zweigstelle ist, in der er aufgestellt ist. Wenn<br />
der RODC ein TGT (Ticket-Granting Ticket) ausstellt und signiert, benutzt er dazu sein<br />
eigenes krbtgt-Konto samt den zugehörigen Schlüsseln, das sich vom krbtgt-Konto unterscheidet,<br />
das sich die KDCs auf allen beschreibbaren Domänencontroller in der Domäne<br />
teilen.<br />
Wenn ein Benutzer zum ersten Mal versucht, sich an einem RODC zu authentifizieren, sendet<br />
der RODC die Anforderung an einen beschreibbaren Domänencontroller im zentralen<br />
Standort. Falls die Authentifizierung erfolgreich ist, fordert der RODC auch eine Kopie der<br />
entsprechenden Anmeldeinformationen an. Der beschreibbare Domänencontroller erkennt,<br />
dass die Anforderung von einem RODC stammt, und wertet die Kennwortreplikationsrichtlinie<br />
aus, die für diesen RODC gilt.<br />
<strong>Die</strong> Kennwortreplikationsrichtlinie legt fest, ob die Anmeldeinformationen auf den RODC<br />
repliziert und dort gespeichert werden dürfen. Ist das der Fall, sendet ein beschreibbarer<br />
Domänencontroller die Anmeldeinformationen an den RODC und der RODC speichert sie<br />
für die künftige Verwendung in seinem Cache. Wenn die Anmeldeinformationen auf dem<br />
RODC zwischengespeichert sind, kann der RODC die Anforderung beim nächsten Anmeldeversuch<br />
des Benutzers direkt bedienen, jedenfalls bis sich die Anmeldeinformationen<br />
ändern.<br />
Offensichtlich muss der RODC dafür wissen, ob er eine Kopie der Anmeldeinformationen<br />
zur Verfügung hat. Um überflüssige Suchvorgänge zu vermeiden, prüft der RODC die Signatur<br />
in verschiedenen Anforderungen. Falls ein TGT mit seinem eigenen krbtgt-Konto<br />
signiert wurde, erkennt der RODC sofort, dass er eine zwischengespeicherte Kopie der Anmeldeinformationen<br />
besitzt. Falls dagegen ein anderer DC das TGT signiert hat, leitet der<br />
RODC die entsprechenden Anforderungen immer weiter.<br />
<strong>Die</strong> Gefahr bei der Installation von RODCs in Zweigstellen lässt sich vor allem dadurch<br />
verringern, dass mit der Kennwortreplikationsrichtlinie gesteuert wird, welche Anmeldeinformationen<br />
zwischengespeichert werden. In der Standardeinstellung werden Anmeldeinformationen<br />
von Benutzern nicht auf einem RODC zwischengespeichert, aber das ist ein<br />
ineffizienter Entwurf. Wenn Sie sich die meisten Domänen mit einer Zweigstelle ansehen,<br />
stellen Sie fest, dass sogar in einer großen Zweigstelle (sagen wir mal 100 Benutzer) diese<br />
Benutzer nur ein winziger Teil der gesamten Benutzer in der Domäne sind. Falls Sie<br />
20.000 Benutzer in der Domäne haben, handelt es sich um eine halbes Prozent.<br />
Weil nur für wenige Domänenbenutzer Anmeldeinformationen auf einem bestimmten RODC<br />
zwischengespeichert werden müssen, sollten Sie über die Kennwortreplikationsrichtlinie<br />
festlegen, bei welchen Gruppen von Benutzern die Zwischenspeicherung in Frage kommt.<br />
Indem Sie die RODC-Zwischenspeicherung auf Benutzer beschränken, die häufig in dieser
414 Kapitel 15: Schützen von Zweigstellen<br />
Zweigstelle sind, können Sie die potenziellen Auswirkungen einer Kompromittierung einschränken.<br />
Sie können <strong>–</strong> und sollten <strong>–</strong> auch explizit die Zwischenspeicherung von Anmeldeinformationen<br />
für Konten mit hohen Privilegien sperren. Indem Sie zum Beispiel die Zwischenspeicherung<br />
der Konten von Domänen-Admins verbieten, garantieren Sie, dass die<br />
Anmeldeinformationen von Domänenadministratoren niemals auf dem RODC in dieser<br />
Zweigstelle gespeichert werden. <strong>Die</strong>s ist ein deutlicher <strong>Sicherheit</strong>sgewinn gegenüber <strong>Windows</strong><br />
<strong>Server</strong> 2003, wo Sie keine Wahl hatten und eine lokale Kopie für alle Konten in jeder<br />
Zweigstelle speichern mussten. <strong>Die</strong>s bedeutet einen riesigen <strong>Sicherheit</strong>sgewinn.<br />
Sie greifen auf die Kennwortreplikationsrichtlinie zu, indem Sie das Eigenschaftendialogfeld<br />
des RODC-Computerobjekts öffnen. In Abbildung 15.1 sehen Sie, dass nur Konten in<br />
einer Gruppe, die die Benutzer der Zweigstelle enthält, zwischengespeichert werden dürfen;<br />
die Zwischenspeicherung von Anmeldeinformationen mit hohen Privilegien wird explizit<br />
verboten.<br />
Abbildung 15.1 <strong>Die</strong> Eigenschaftenseiten eines RODCs<br />
zeigen seine Kennwortreplikationsrichtlinie an<br />
Nehmen wir einmal das undenkbare an: Ihr RODC wird gestohlen. Der <strong>Die</strong>b stellt die AD DS-<br />
Datenbank bereit und versucht, mit einem allgemein verfügbaren <strong>–</strong> nun ja <strong>–</strong> »<strong>Sicherheit</strong>stesttool«<br />
Kennwörter zu extrahieren. Aber statt mehr und mehr Kennwörter aufzulisten,<br />
zeigt das Kennwortknackertool nur leere Kennwörter für fast alle Konten an.<br />
Falls früher Ihr DC gestohlen wurde, hatten Sie wirklich keine Wahl, als alle Kennwörter in<br />
der Domäne zurückzusetzen. Eine mühselige Aufgabe, wenn Sie Tausende von Benutzern<br />
hatten. In diesem Fall brauchen Sie sich aber nur um die Konten zu kümmern, die auf diesem<br />
einen RODC zwischengespeichert wurden. Um es deutlich zu sagen: Mit einem RODC<br />
wissen Sie genau, welche Kennwörter zwischengespeichert wurden. Sie können prüfen,<br />
welche auf den RODC repliziert wurden, indem Sie sich das Dialogfeld Kennwortreplikationsrichtlinie<br />
ansehen. Anfangs werden nur Kennwörter für den Computer selbst und das
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 415<br />
spezielle KRBTG-Konto lokal gespeichert, wie Sie in Abbildung 15.2 sehen können. Sobald<br />
sich die ersten Clients beim RODC authentifizieren, werden unter Umständen weitere Kennwörter<br />
gespeichert, wie in Abbildung 15.3 zu sehen.<br />
Abbildung 15.2 Anfangs sind nur die Kennwörter zu zwei Konten auf dem RODC gespeichert<br />
Abbildung 15.3 Sie können weitere Kennwörter auf dem RODC speichern<br />
Sie können auch feststellen, welche Benutzer versucht haben, sich beim RODC zu authentifizieren,<br />
deren Kennwörter aber nicht zwischengespeichert werden durften. Zum Beispiel<br />
sehen Sie in den Abbildungen 15.2 und 15.3, dass für das Konto Administrator kein Kenn-
416 Kapitel 15: Schützen von Zweigstellen<br />
wort zwischengespeichert wurde. Aber in Abbildung 15.4 hat sich der Administrator an dem<br />
Standort angemeldet, für den der RODC zuständig ist.<br />
Abbildung 15.4 Benutzer, die sich beim RODC authentifiziert haben, deren<br />
Kennwörter aber nicht zwischengespeichert wurden<br />
In Abbildung 15.5 sehen Sie schließlich, für welche Konten die Kennwörter auf dem RODC<br />
zwischengespeichert werden dürfen und für welche nicht.<br />
Abbildung 15.5 Informationen über die Kennwortzwischenspeicherung<br />
auf der Seite Richtlinienergebnis
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 417<br />
Wir haben es viel einfacher gemacht, fehlende Domänencontroller, auch RODCs, zu entfernen.<br />
Dafür steht eine einfache Schnittstelle zur Verfügung, in der Sie den früheren RODC<br />
aus der Domäne entfernen (es müssen keine Metadaten mehr aufgeräumt werden!) und auch<br />
automatisch die potenziell kompromittierten Kennwörter zurücksetzen können. Wenn Sie<br />
das Computerobjekt eines RODCs löschen wollen, öffnet sich der Dialog aus Abbildung 15.6.<br />
Abbildung 15.6 Entfernen eines RODCs, der in AD DS nicht online gebracht werden kann<br />
Sie sollten auch den Abschnitt zur BitLocker-Laufwerkverschlüsselung weiter unten in diesem<br />
Kapitel lesen. Wenn Sie BitLocker auf dem <strong>Windows</strong>-Volume des RODCs benutzen,<br />
können Sie verhindern, dass der <strong>Die</strong>b überhaupt auf die lokale Kopie der AD DS-Datenbank<br />
zugreifen kann. Das verschafft Ihnen zumindest die Zeit, die Sie brauchen, um die Kennwörter<br />
ordentlich zurückzusetzen.<br />
Administrative Rollentrennung<br />
Mithilfe der Rollentrennung können Sie die Rolle des lokalen Administrators auf einem<br />
RODC-Computer an einen beliebigen Domänenbenutzer delegieren, ohne diesem Benutzer<br />
irgendwelche Rechte für die Domäne selbst oder andere Domänencontroller zu gewähren. In<br />
<strong>Windows</strong> <strong>Server</strong> 2003 hatten DCs keinen lokalen Administrator; wenn Sie einen DC administrieren<br />
konnten, war es auch möglich, die gesamte Domäne zu administrieren.<br />
Administrative Rollentrennung erlaubt es einem Benutzer in einer lokalen Zweigstelle, sich<br />
an einem RODC anzumelden und Wartungsaufgaben auf dem <strong>Server</strong> durchzuführen, zum<br />
Beispiel einen Treiber zu aktualisieren, ohne dass dieser Benutzer sich an irgendeinem anderen<br />
Domänencontroller anmelden oder die Domäne verwalten kann.<br />
Vorteile von RODCs<br />
RODCs bieten eine Möglichkeit, Domänencontroller in einer Zweigstelle sicherer bereitzustellen,<br />
weil sie für den Einsatz an Orten entworfen wurden, die schnelle, zuverlässige und<br />
robuste Authentifizierungsdienste benötigen, aber auch Einschränkungen bezüglich der<br />
<strong>Sicherheit</strong> aufweisen, die eine Bereitstellung von beschreibbaren Domänencontrollern einschränkt<br />
oder verhindert. Mit einem RODC kann eine Organisation die Risiken bei der<br />
Bereitstellung eines Domänencontrollers an Orten eindämmen, wo die physische <strong>Sicherheit</strong><br />
nicht garantiert werden kann.
418 Kapitel 15: Schützen von Zweigstellen<br />
Das RODC-Feature wurde offensichtlich gezielt für Zweigstellen entwickelt, es ist aber<br />
auch ein integraler Bestandteil von AD DS. In Kapitel 9 finden Sie weitere Informationen<br />
zur Installation eines RODCs, dem Einsatz des gefilterten RODC-Attributsatzes und der<br />
Konfiguration von schreibgeschütztem DNS.<br />
BitLocker-Laufwerkverschlüsselung<br />
<strong>Die</strong> BitLocker-Laufwerkverschlüsselung (BitLocker Drive Encryption) ist eine Komponente<br />
des Betriebssystems in <strong>Windows</strong> Vista Enterprise Edition und <strong>Windows</strong> Vista Ultimate Edition,<br />
sie ist auch als Feature in allen Editionen von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthalten. Sie wissen<br />
wahrscheinlich bereits, dass Daten auf Clientfestplatten geschützt werden sollten, aber<br />
diese Möglichkeit kann auch für <strong>Server</strong> wichtig sein, insbesondere in einer Zweigstelle.<br />
Laut einer Untersuchung von Forrester kommen Datenlecks teuer: »<strong>Die</strong> Kosten für einen<br />
einzigen, schweren <strong>Sicherheit</strong>seinbruch können Millionen oder sogar Milliarden von Dollar<br />
betragen«. (»Calculating the Cost of a Security Breach«, Khalid Kark, 10. April 2007, unter<br />
http://www.forrester.com/Research/Document/Excerpt/0,7211,42082,00.html). Und leider<br />
sind solche Vorfälle auch recht häufig: »34% der Befragten hatten zumindest einmal ein<br />
Datenleck erlebt, bei dem persönliche Daten bekannt wurden.« (»Aligning Data Protection<br />
Priorities with Risk«, Jonathan Penn, 13. April 2006, unter http://www.forrester.com/Research/<br />
Document/Excerpt/0,7211,39257,00.html)<br />
<strong>Die</strong> meisten IT-Experten sind sich der Gefahr bewusst, dass das Notebook eines Benutzers<br />
im Taxi vergessen oder gestohlen wird. Vermutlich ist die Gefahr geringer, dass Sie einen<br />
Produktivserver in einem Taxi liegen lassen. Aber haben Sie sich schon einmal überlegt, was<br />
passiert, wenn Ihre <strong>Server</strong> gestohlen werden? Ich habe einmal bei einem Kunden in der Rüstungsindustrie<br />
gearbeitet, der mir erzählte, dass seine Organisation die Domänencontroller<br />
mit C4-Sprengsätzen versehen hat, weil sie »im Feld« bereitgestellt wurden. Und da wäre es<br />
besser, ihre Zerstörung in Kauf zu nehmen, als zu riskieren, dass Authentifizierungsdaten in<br />
Feindeshand fallen. Bei Ihnen ist die Gefahr wahrscheinlich nicht ganz so dramatisch wie<br />
auf dem Schlachtfeld, aber es gibt immer ein gewisses Risiko, und das ist nicht rein hypothetisch.<br />
Ein Kollege von mir (na gut, es war Jesper) hatte einmal mit einem Kunden zu tun,<br />
dessen Unternehmen erleben musste, wie ein <strong>Die</strong>b einen Lastwagen rückwärts durch die<br />
Gebäudewand setzte und ihre <strong>Server</strong> stahl.<br />
BitLocker ist ein Werkzeug, das Ihnen hilft, das Risiko auf das erforderliche Maß einzudämmen.<br />
Ich hoffe allerdings, dass Sie über die Grenzen des Datencenters hinaus denken.<br />
Hier einige Beispiele aus meiner eigenen Erfahrung:<br />
Ich besuchte einmal einen Kunden, dessen Datencenter in einem 100 Jahre alten, früheren<br />
Sanatorium lag. <strong>Die</strong> <strong>Server</strong> standen hinter 70 cm dicken Mauern und wurden rund<br />
um die Uhr bewacht. Es wäre sehr schwierig, diese <strong>Server</strong> zu stehlen.<br />
Ich half einmal bei einer großen Veranstaltung für Jugendliche aus, wo sich das »Datencenter«<br />
in einem Zelt befand. <strong>Server</strong> verteilten sich über riesigen Flächen und verloren<br />
die Konnektivität, wenn jemand eine Heizplatte in dieselbe Verteilerdose wie den Glasfaser-Repeater<br />
einsteckte.<br />
Damit niemand mein zweites Beispiel als unbedeutend abtut, will ich darauf hinweisen, dass<br />
beide <strong>Server</strong> vertrauliche persönliche Informationen enthielten, darunter medizinische Daten<br />
über Klienten beziehungsweise Teilnehmer <strong>–</strong> und beide waren an einem Ort, wo sie sein<br />
mussten, um die konkreten Aufgaben zu erfüllen.
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 419<br />
Was ist nun die BitLocker-Laufwerkverschlüsselung und wie kann sie Ihnen helfen, die<br />
Daten auf Ihren <strong>Server</strong>n zu schützen? BitLocker erfüllt zwei Funktionen:<br />
BitLocker verschlüsselt alle Daten, die auf dem <strong>Windows</strong>-Betriebssystemvolume gespeichert<br />
sind (und auf konfigurierten Datenvolumes). Das umfasst das Betriebssystem<br />
<strong>Windows</strong>, Ruhezustands- und Auslagerungsdateien, Anwendungen und Daten, die von<br />
den Anwendungen benutzt werden.<br />
BitLocker ist standardmäßig so konfiguriert, dass es einen TPM-Chip (Trusted Platform<br />
Module) nutzt, um die Integrität der Startkomponenten sicherzustellen (Komponenten,<br />
die in den allerersten Phasen des Startprozesses zum Einsatz kommen). Es sperrt alle mit<br />
BitLocker geschützten Volumes, sodass sie sogar dann geschützt bleiben, wenn der<br />
Computer manipuliert wurde, während das Betriebssystem nicht lief.<br />
BitLocker-Konfiguration in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ist BitLocker eine optionale Komponente, die installiert werden<br />
muss, bevor sie benutzt werden kann. (Im <strong>Server</strong>-Manager werden optionale Komponenten<br />
als Features bezeichnet.) Sie können BitLocker installieren, indem Sie das Feature Bit-<br />
Locker-Laufwerkverschlüsselung im <strong>Server</strong>-Manager hinzufügen oder an einer Eingabeaufforderung<br />
folgenden Befehl eingeben: <strong>Server</strong>ManagerCmd -install BitLocker-restart.<br />
Wenn Sie BitLocker auf einem Produktivserver installieren wollen, müssen einige Punkte<br />
beachtet werden. BitLocker umfasst in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> zwei optionale Komponenten<br />
(Optional Component, OC). <strong>Die</strong> BitLocker-OC dient dazu, Volumes auf diesem konkreten<br />
<strong>Server</strong> zu schützen. Außerdem gibt es eine Remoteverwaltungs-OC namens RSAT-BitLocker.<br />
Sie installiert die Dateien und Befehlszeilenskripts, die nötig sind, um BitLocker auf Remoteservern<br />
zu verwalten. (RSAT steht für Remote <strong>Server</strong> Administration Tool.) Falls Sie<br />
das BitLocker-Feature mit dem <strong>Server</strong>-Manager installieren oder entfernen, werden beide<br />
OCs installiert beziehungsweise entfernt. Falls Sie nur das Remotetool installieren wollen,<br />
müssen Sie entweder den Befehl pkgmgr oder den Befehl ocsetup verwenden. Weil der <strong>Server</strong>-Manager<br />
in einer <strong>Server</strong> Core-Installation nicht zur Verfügung steht, müssen Sie pkgmgr<br />
oder ocsetup verwenden, um BitLocker auf <strong>Server</strong> Core zu installieren.<br />
Weil BitLocker einen Filtertreiber für die Ver- und Entschlüsselung benutzt, muss der Computer<br />
nach dem Installieren oder Entfernen von BitLocker neu gestartet werden. Wird lediglich<br />
die Komponente RSAT-BitLocker installiert, ist kein Neustart erforderlich. Sobald die<br />
Komponente installiert ist, können Sie BitLocker mit dem Befehlszeilentool manage-bde.wsf<br />
oder der Systemsteuerung auf bestimmten Volumes aktivieren.<br />
BitLocker unterscheidet sich von vorhandenen Technologien wie EFS: Sobald Sie BitLocker<br />
aktiviert haben, arbeitet es automatisch und transparent, und es umfasst das gesamte Volume.<br />
(Beachten Sie, dass BitLocker vollständig kompatibel zu EFS ist und Sie die beiden kombinieren<br />
können, um unterschiedliche Risiken einzudämmen. <strong>Die</strong> Active Directory-Rechteverwaltungsdienste<br />
(Active Directory Rights Management Services, AD RMS) bilden das dritte<br />
Element in der Datenverschlüsselungsstrategie von Microsoft. Eine Beschreibung von EFS<br />
und RMS würde den Rahmen dieses Kapitels sprengen.)<br />
BitLocker erfordert, dass ein Computer mit mehreren Volumes (Partitionen) konfiguriert<br />
wird. Ein Computer startet von der aktiven Partition, auch als Systempartition oder Systemvolume<br />
bezeichnet. Das Betriebssystem wird auf einem zweiten Volume installiert, das in<br />
der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Dokumentation normalerweise das <strong>Windows</strong>-Betriebssystemvolume<br />
genannt wird, in älterer Dokumentation auch Startpartition. (Wenn Sie genau aufge-
420 Kapitel 15: Schützen von Zweigstellen<br />
passt haben: Es stimmt, Sie starten Ihren Computer niemals von der Startpartition, und auf<br />
der Systempartition befinden sich keine <strong>Windows</strong>-Systemdateien.)<br />
<strong>Die</strong> aktive Partition ist nicht verschlüsselt, das <strong>Windows</strong>-Betriebssystemvolume schon. Anders<br />
ausgedrückt: BitLocker verschlüsselt alles, was in ein geschütztes Volume geschrieben<br />
wird, also Code, Daten und Temporärdateien.<br />
<strong>Die</strong> BitLocker-Verschlüsselung des gesamten Volumes bietet Schutz gegen Offlineangriffe,<br />
bei denen jemand versucht, das Betriebssystem zu umgehen. Es ist sehr wichtig, dass Bit-<br />
Locker ein laufendes Betriebssystem nicht schützt. Wenn das <strong>Windows</strong>-Betriebssystemvolume<br />
beim Start entsperrt wurde, verschlüsselt und entschlüsselt BitLocker die Sektoren<br />
transparent. Das geschieht immer, wenn eine Anwendung oder das Betriebssystem selbst<br />
Daten auf einem geschützten Volume liest oder schreibt. Weitere Schutzfunktion führt<br />
BitLocker nicht aus. Aber BitLocker bietet eben Schutz gegen Offlineangriffe, wenn zum<br />
Beispiel die Festplatte (oder der gesamte <strong>Server</strong>) gestohlen wird.<br />
Ohne BitLocker ist es ganz einfach, die Festplatte aus dem <strong>Server</strong> aus- und in einen anderen<br />
Computer einzubauen. So lassen sich die NTFS-Berechtigungen und ähnliche Schutzmechanismen<br />
aushebeln. Mit BitLocker kann aber auch in einem anderen Computer nichts<br />
Sinnvolles von der Festplatte ausgelesen werden, sofern Sie nicht das erforderliche Wiederherstellungskennwort<br />
haben, um das Volume zu entsperren. Es stimmt, dass auch Dateien,<br />
die durch RMS und EFS geschützt sind, nicht einfach gelesen werden können, aber BitLocker<br />
dehnt diesen Schutz auf das gesamte Volume aus, inklusive der Dateien, die nicht durch<br />
RMS oder EFS geschützt werden können (zum Beispiel die Active Directory-Datenbank<br />
oder die Registrierung).<br />
Direkt von der Quelle: Automatisches Entsperren von Datenvolumes<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> hat Microsoft Unterstützung für Datenvolumes zu BitLocker<br />
hinzugefügt. Ergänzt wird das durch die Fähigkeit, alle verschlüsselten Datenvolumes<br />
automatisch aufzusperren. Dazu speichert BitLocker Schlüssel für verschlüsselte Datenvolumes<br />
in der Systemregistrierung, wo sie von BitLocker ausgelesen werden können,<br />
um das Volume zu entsperren.<br />
Es ist sehr wichtig, diese Schlüssel für die automatische Entsperrung gut zu schützen, da<br />
sie benutzt werden können, um das Volume zu entschlüsseln. Daher werden diese Schlüssel<br />
selbst immer verschlüsselt, bevor sie in der Registrierung gespeichert werden. Sie<br />
werden dabei mit einem neuen Schlüssel verschlüsselt, dem AMK (Auto-Unlock Master<br />
Key). Der AMK ist dem FVEK sehr ähnlich. Der FVEK dient dazu, die Daten auf dem<br />
Volume zu verschlüsseln, der AMK wird dagegen benutzt, um die Daten in der Registrierung<br />
zu verschlüsseln. Wie der FVEK wird auch der AMK mit dem VMK des Betriebssystemvolumes<br />
verschlüsselt. Das erklärt, warum BitLocker erst auf dem Betriebssystemvolume<br />
aktiviert werden muss, bevor es auf irgendwelchen Datenvolumes aktiviert werden<br />
kann.<br />
Dank dieses Entwurfs können Sie BitLocker auf sichere Weise auf einem Datenvolume<br />
aktivieren und dieses Volume für die automatische Entsperrung einrichten (das ist die<br />
Standardeinstellung), ohne erst warten zu müssen, bis das Betriebssystemvolume vollständig<br />
verschlüsselt ist.
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 421<br />
Und wenn Sie das Betriebssystemvolume entschlüsseln, erzwingen wir auch die Entschlüsselung<br />
aller bereitgestellten Datenvolumes, bei denen die automatische Entsperrung<br />
aktiviert ist, weil der AMK beim Entschlüsseln des Betriebssystemvolumes gelöscht<br />
wird und daher die Schlüssel für die automatische Entsperrung in der Registrierung<br />
unbrauchbar werden.<br />
Narendra S. Acharya<br />
Software Design Engineer in Test (SDET)<br />
System Integrity, Core OS Division<br />
BitLocker-Verschlüsselungsalgorithmen und -Schlüssel<br />
BitLocker benutzt den AES-Algorithmus (Advanced Encryption Standard) mit einem 256-<br />
Bit-Schlüsselraum. In der Standardeinstellung werden allerdings nur 128 Bit des Schlüssels<br />
benutzt. Um stärkere Verschlüsselung zu erreichen, kann die Schlüssellänge auf 256 Bit<br />
vergrößert werden. <strong>Die</strong>se Konfiguration können Sie über Gruppenrichtlinien oder den Bit-<br />
Locker-WMI-Anbieter (<strong>Windows</strong> Management Instrumentation) vornehmen. Wie immer bei<br />
Verschlüsselung bedeuten stärkere Verschlüsselung und längere Schlüssel, dass mehr Rechenleistung<br />
benötigt wird. (Alle Änderungen an den Verschlüsselungseinstellungen werden<br />
erst wirksam, nachdem BitLocker für ein Volume erneut aktiviert wurde.)<br />
Bevor Daten an den AES-Algorithmus übergeben werden, werden sie durch zwei separate<br />
Diffuser-Schritte geleitet. Ein Diffuser ist ein komplexer kryptografischer Algorithmus, der<br />
einen einzigen Zweck verfolgt: <strong>Die</strong> Diffuser stellen sicher, dass jede Änderung (selbst wenn<br />
es nur ein einziges Bit ist) am Klartext dazu führt, dass der gesamte Block im verschlüsselten<br />
Ciphertext geändert wird. Das macht es schwieriger, unter Umständen sogar unmöglich,<br />
Schlüssel dadurch zu erraten, dass Änderungen im Klartext vorgenommen und dann der<br />
generierte Ciphertext analysiert wird.<br />
BitLocker verschlüsselt jeden Sektor im Volume einzeln. Ein Teil des Verschlüsselungsschlüssels<br />
wird aus der Sektornummer abgeleitet. Das bedeutet, dass zwei Sektoren mit denselben<br />
unverschlüsselten Daten zwei völlig unterschiedliche verschlüsselte Blöcke ergeben,<br />
wenn sie auf die Festplatte geschrieben werden. Das macht es schwieriger, die Schlüssel zu<br />
ermitteln, indem bekannte Datenstücke verschlüsselt werden.<br />
Niels Ferguson, einer der Entwickler des Algorithmus und ein geachteter Kryptografieexperte,<br />
der an BitLocker gearbeitet hat, veröffentlichte einen Artikel zu den Details des BitLocker-<br />
Verschlüsselungsalgorithmus. Sie können ihn auf der Begleit-CD zu diesem Buch und online<br />
unter http://www.microsoft.com/downloads/details.aspx?familyid=131dae03-39ae-48bea8d6-8b0034c92555&displaylang=en<br />
lesen: »AES-CBC + Elephant Diffuser: A Disk<br />
Encryption Algorithm for <strong>Windows</strong> Vista«. Abbildung 15.7 zeigt einen vereinfachten<br />
Überblick.<br />
Wie bereits erwähnt, wird jeder Sektor individuell verschlüsselt, wobei ein Teil des Schlüssels<br />
aus der Sektornummer abgeleitet wird. Der symmetrische Verschlüsselungsschlüssel,<br />
der für den größten Teil der Verschlüsselung benutzt wird, ist der sogenannte FVEK (Full-<br />
Volume Encryption Key). Der FVEK wird einem Benutzer oder Administrator gegenüber<br />
niemals offengelegt. Für den Fall, dass der FVEK kompromittiert wird, schreiben <strong>Sicherheit</strong>sempfehlungen<br />
vor, alles, was mit diesem Schlüssel verschlüsselt wurde, zu entschlüsseln<br />
und anschließend mit einem neuen Schlüssel wieder zu verschlüsseln. Weil davon eine<br />
sehr große Datenmenge betroffen sein kann, wäre das ein zeitaufwendiger Prozess (und
422 Kapitel 15: Schützen von Zweigstellen<br />
während dieses Vorgangs bricht die Leistung deutlich ein). Stattdessen ist der FVEK ein sehr<br />
streng gehütetes Geheimnis, und das System arbeitet mit einem anderen Schlüssel, dem<br />
sogenannten VMK (Volume Master Key). Der VMK wird benutzt, um den FVEK zu verschlüsseln.<br />
<strong>Die</strong> verschlüsselte Kopie des FVEK wird in die Volumemetadaten geschrieben.<br />
(Sie kann auch als Element eines Binärschlüsselpakets in AD DS gesichert werden.) Das<br />
bedeutet nicht, dass der Schlüssel unter die Türmatte gelegt wird. Es ist eher, als ob Sie<br />
Schlüssel in einem Tresor lassen, der in einem Zwei-Tonnen-Block verankert und dann unter<br />
der Türmatte versteckt wird. Selbst wenn der VMK irgendwie kompromittiert wird, können<br />
Sie den FVEK sehr schnell mit einem neuen VMK verschlüsseln.<br />
Abbildung 15.7 Vereinfachte Darstellung des BitLocker-Verschlüsselungsalgorithmus<br />
Um Sektoren zu entschlüsseln, muss das System an den FVEK kommen. Und dazu muss das<br />
System erst einmal an den VMK kommen. Der VMK ist ebenfalls in den Volumemetadaten<br />
gespeichert und auch er wird niemals auf die Festplatte geschrieben, ohne vorher selbst stark<br />
verschlüsselt zu werden.<br />
Der VMK kann mit einer beliebigen Zahl von Schlüsselschutzmechanismen oder -authentifizierern<br />
verschlüsselt werden. Der Standardschutz für den Schlüssel ist das TPM (Trusted<br />
Platform Module) des Computers, was in den folgenden Abschnitten genauer beschrieben<br />
wird. Sie können das TPM mit einem PIN-Code oder einem partiellen Schlüssel kombinieren,<br />
der auf einem USB-Stick gespeichert ist. Und Sie können diese beiden Mechanismen<br />
ebenfalls kombinieren. Weil eine PIN oder ein USB-Stick benötigt werden, haben Sie hier<br />
eine Zwei-Komponenten-Authentifizierung.<br />
Falls der Computer kein kompatibles TPM hat, können Sie BitLocker so konfigurieren, dass<br />
es einen Schlüsselschutz vollständig auf einem USB-Flashlaufwerk speichert. (Dabei ist<br />
allerdings keine Systemstartintegritätsprüfung möglich, mehr dazu weiter unten.) Der VMK<br />
wird außerdem mit einem 48-stelligen Wiederherstellungskennwort verschlüsselt, das in<br />
AD DS gesichert, in einer Datenbank gespeichert oder für eine Notfallwiederherstellung<br />
ausgedruckt werden kann.
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 423<br />
Und für den Fall, dass Sie BitLocker deaktivieren, das Laufwerk aber nicht vollständig entschlüsseln<br />
wollen, verwendet BitLocker einen Schlüsselschutz, der ein Klartextschlüssel ist.<br />
Den Klartextschlüssel können Sie sich so vorstellen, dass der Haustürschlüssel unter die<br />
Fußmatte gelegt wird. Der VMK wird mit einem neuen Schlüssel verschlüsselt, aber dieser<br />
Schlüssel wird im Klartext auf dem Volume gespeichert. Das ist nützlich für Operationen,<br />
bei denen BitLocker deaktiviert sein muss, zum Beispiel bei bestimmten Upgrades. Sie sparen<br />
sich dabei den Zeitaufwand zum Entschlüsseln und Neuverschlüsseln des Volumes. Weil<br />
der VMK in diesem Zustand allzu leicht ausgespäht werden könnte, sollten Sie BitLocker<br />
aber nicht länger als unbedingt nötig in diesem deaktivierten Zustand lassen.<br />
BitLocker-Start<br />
Beim Start des Computers sind alle mit BitLocker geschützten Volumes gesperrt und können<br />
nicht benutzt werden, nicht einmal das Betriebssystem kann gestartet werden. Startcode im<br />
Start-Manager und dem <strong>Windows</strong>-Ladeprogramm sucht nach einem passenden Schlüsselschutz,<br />
indem er das TPM abfragt, die USB-Anschlüsse überprüft und bei Bedarf den Benutzer<br />
auffordert, eine PIN oder ein Wiederherstellungskennwort einzugeben. Wenn <strong>Windows</strong><br />
den Schlüsselschutz gefunden hat, kann es den VMK entschlüsseln, der wiederum den<br />
FVEK entschlüsselt. Ab diesem Punkt ist die Festplatte entsperrt und der BitLocker-Filtertreiber<br />
entschlüsselt die auf der Festplatte gespeicherten Daten, während ein Sektor gelesen<br />
wird.<br />
BitLocker-Integritätsprüfung<br />
Damit ein <strong>Server</strong> starten kann, müssen die Komponenten, die ganz am Anfang des Startprozesses<br />
stehen, unverschlüsselt vorliegen, damit sie auch beim Start benutzt werden können.<br />
Schafft es ein Angreifer, den Code in den frühesten Startkomponenten zu manipulieren, ist<br />
es viel einfacher, ein System zu kompromittieren. Nach diesem Prinzip arbeiten viele Rootkits.<br />
Sobald ein System erst einmal auf diese Weise kompromittiert wurde, können Geheimnisse<br />
wie zum Beispiel Kennwörter viel einfacher ausgespäht werden.<br />
Im Fall eines Systems, das durch BitLocker geschützt wird, könnte eine Kompromittierung<br />
der frühesten Startkomponenten dazu führen, dass der VMK oder FVEK bekannt wird. Das<br />
würde den BitLocker-Schutz aushebeln, obwohl die Daten auf der Festplatte verschlüsselt<br />
sind.<br />
Falls der Computer ein kompatibles TPM hat, kann BitLocker die Integritätsprüfung nutzen,<br />
um diese Art von Angriff zu verhindern. Ist ein TPM vorhanden, untersuchen alle Startkomponenten<br />
<strong>–</strong> zum Beispiel BIOS, Master Boot Record (MBR), Startsektor und Start-Managercode<br />
<strong>–</strong> bei jedem Computerstart den Code, der ausgeführt werden soll, berechnen einen<br />
Hashwert und speichern den Wert in bestimmten TPM-Registern, den PCRs (Platform Configuration<br />
Register). Ist ein Wert einmal in einem PCR gespeichert, kann der Wert nicht<br />
mehr geändert oder gelöscht werden, ohne das System neu zu starten.<br />
Ein TPM kann Daten (in diesem Fall den VMK) verschlüsseln und diese Verschlüsselung<br />
mit bestimmten PCR-Werten verknüpfen. <strong>Die</strong>s wird als Versiegeln (engl. sealing) eines<br />
Schlüssels im TPM bezeichnet. Ist ein Schlüssel einmal versiegelt, kann nur dieses spezielle<br />
TPM den Schlüssel wieder entschlüsseln. Und das TPM entschlüsselt den Schlüssel nur,<br />
falls die aktuellen PCR-Werte den Werten entsprechen, die eingetragen wurden, als der<br />
Schlüssel versiegelt wurde.<br />
In der Standardeinstellung versiegelt BitLocker Schlüssel in den PCRs, die CRTM (Core<br />
Root of Trust Measurement), BIOS und alle Plattformerweiterungen, Option-ROM-Code,
424 Kapitel 15: Schützen von Zweigstellen<br />
MBR-Code, NTFS-Startsektor und Start-Manager aufzeichnen. Falls irgendeines dieser<br />
Elemente sich unerwartet geändert hat, entschlüsselt das TPM seinen Schlüsselschutz nicht<br />
und BitLocker kann das Volume nicht entsperren. So wird verhindert, dass jemand auf das<br />
Volume zugreift oder es entschlüsselt.<br />
In der Standardeinstellung ist BitLocker so konfiguriert, dass es nach einem TPM sucht und<br />
es verwendet. Sie können BitLocker über Gruppenrichtlinien oder eine lokale Richtlinieneinstellung<br />
erlauben, auch ohne ein TPM zu arbeiten und Schlüssel auf einem externen<br />
USB-Flashlaufwerk zu speichern. Aber ohne ein TPM kann BitLocker die Systemintegrität<br />
nicht überprüfen.<br />
BitLocker in der Zweigstelle<br />
Gut und schön, denken Sie sich jetzt möglicherweise, das ist bestimmt sehr nützlich für<br />
Notebooks. Aber was hat das mit meinem <strong>Server</strong> in der Zweigstelle zu tun? Gut, dass Sie<br />
fragen.<br />
Es gibt mehrere Szenarien, in denen BitLocker für <strong>Server</strong> sehr nützlich ist. Das gilt besonders<br />
für Computer, die nicht im zentralen Datencenter aufgestellt sind. Das sind zum Beispiel<br />
folgende Szenarien:<br />
Verringern der Gefahr durch Malwareinfektion, insbesondere Rootkits <strong>Die</strong> meisten<br />
Rootkits und andere Malware, die Ihre <strong>Server</strong> ernsthaft beschädigen können, müssen<br />
den Computer neu starten, um sich zu installieren. Wenn ein TPM und die BitLocker-<br />
Integritätsprüfung eingesetzt werden, startet der <strong>Server</strong> nicht, falls die Startkomponenten<br />
manipuliert wurden. (Nachdem BitLocker das Volume entsperrt hat, übernehmen <strong>Windows</strong>-Codeintegritätfeatures<br />
die Aufgabe, das Betriebssystem vor unautorisierten Änderungen<br />
zu schützen.) Es stimmt, dass dies für einen Denial-of-Service-Angriff genutzt<br />
werden kann, weil der <strong>Server</strong> sich weigert, neu zu starten, aber es ist im Allgemeinen<br />
besser, einen Produktivserver anzuhalten als zuzulassen, dass er mit aktiver Malware<br />
läuft.<br />
<strong>Die</strong>bstahl eines <strong>Server</strong>s <strong>Die</strong>be konzentrieren sich auf Notebooks und mobile Geräte,<br />
weil es bequeme Ziele sind. Manche <strong>Die</strong>be stehlen Notebook zwar auch, weil sie irgendwelche<br />
interessanten Daten enthalten, aber die meisten Notebookdiebstähle dienen der<br />
Hardwarebeschaffung. <strong>Die</strong> viel wertvolleren Daten darauf werden meist ignoriert. Aber<br />
ein <strong>Server</strong> oder seine Datenträger können für einen ausgekochten <strong>Die</strong>b eine Goldmine<br />
sein. Ein Domänencontroller könnte Geheimnisse über Tausende von Benutzern enthalten<br />
(siehe den Abschnitt zu RODCs), ein Dateiserver könnte mit dem geistigen Eigentum<br />
Ihres Unternehmens gefüllt sein, ein Datenbankserver könnte Unmengen persönlicher<br />
Daten enthalten <strong>–</strong> ungemein praktisch für Identitätsdiebstahl und Betrug, um nur<br />
zwei Risiken zu nennen. Wenn Sie sich wirksam vor der Gefahr schützen wollen, dass<br />
der gesamte <strong>Server</strong> gestohlen wird, reicht der standardmäßige TPM-Schutz nicht aus.<br />
<strong>Die</strong>bstahl einer Festplatte Oft ist es viel einfacher, ein einzelnes Laufwerk zu stehlen<br />
als den gesamten <strong>Server</strong>. <strong>Die</strong> meisten <strong>Server</strong>laufwerke lassen sich einfach herausziehen,<br />
dadurch sind sie im Nu gestohlen. Wie ein <strong>Server</strong> enthält ein Laufwerk wertvolle Informationen<br />
und sollte geschützt werden.<br />
Versenden eines <strong>Server</strong>s (oder eines Laufwerks) an einen Remotestandort In vielen<br />
Fällen werden <strong>Server</strong> erst einmal in der Zentralstelle eingerichtet oder große Datenmengen<br />
müssen zu einem Remoteserver geschafft werden. In beiden Fällen können Sie<br />
im Datencenter BitLocker auf dem Volume aktivieren und das Volume dann an den
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> in der Zweigstelle 425<br />
Remotestandort schaffen lassen. Wenn es sich um einen gesamten <strong>Server</strong> handelt, kann<br />
er so konfiguriert werden, dass eine PIN zum Starten eingegeben werden muss. Bei<br />
einem einzelnen Volume können alle Schlüsselschutzdaten außer dem Wiederherstellungskennwort<br />
gelöscht werden. Wenn dann autorisiertes Personal den <strong>Server</strong> oder das<br />
Laufwerk am Bestimmungsort in Empfang genommen habt, können PIN oder Wiederherstellungskennwort<br />
über Telefon, Fax oder E-Mail übermittelt werden. Wenn der <strong>Server</strong><br />
im Produktivbetrieb läuft, können Sie bei Bedarf den PIN-Schutz entfernen oder das<br />
Volume sogar entschlüsseln. Falls das Laufwerk oder der <strong>Server</strong> unterwegs verloren geht<br />
oder gestohlen wird, kann niemand auf die Daten zugreifen.<br />
Sichere Ausmusterung Irgendwann wird ein <strong>Server</strong> oder ein Laufwerk außer <strong>Die</strong>nst<br />
gestellt. Es ist unerlässlich, dass Sie sicherstellen, dass kein <strong>Server</strong>laufwerk mit Unternehmensdaten<br />
Ihren Besitz verlässt, während diese Daten noch lesbar sind. <strong>Die</strong> meisten<br />
Prozesse, die vertrauliche Daten von Festplattenlaufwerken löschen, sind zeitaufwendig,<br />
teuer oder haben die dauerhafte Zerstörung der Hardware zur Folge. Statt die Daten am<br />
Ende zu löschen, können Sie mit BitLocker sicherstellen, dass vertrauliche Daten erst<br />
gar nicht so auf einem Laufwerk gespeichert werden, dass sie ausgelesen werden können.<br />
Weil alles, was auf dem Laufwerk steht, verschlüsselt ist, können Sie die Daten<br />
dauerhaft unlesbar machen, indem Sie schlicht alle Exemplare des Verschlüsselungsschlüssels<br />
löschen. <strong>Die</strong> Festplatte selbst bleibt völlig unbeschädigt und kann wiederverwendet<br />
werden. Das Entfernen und Zerstören der Schlüssel in den Volumemetadaten ist<br />
blitzschnell getan und kann lokal oder im Remotezugriff von einem Administrator erledigt<br />
werden. Das Format-<strong>Die</strong>nstprogramm in <strong>Windows</strong> Vista und <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
löscht die Volumemetadaten und überschreibt diese Sektoren, damit alle BitLocker-<br />
Schlüssel garantiert gelöscht werden. (Beachten Sie, dass Sie nicht die Format-<strong>Die</strong>nstprogramme<br />
aus älteren <strong>Windows</strong>-Versionen als <strong>Windows</strong> Vista verwenden können, um<br />
diese Aufgabe durchzuführen.)<br />
Problembereiche<br />
Wenn Sie erwägen, BitLocker auf Ihren <strong>Server</strong>n einzusetzen, müssen Sie einige Punkte<br />
beachten.<br />
Denken Sie daran, dass BitLocker Schutz gegen ganz bestimmte Bedrohungen bietet: Offlineangriffe.<br />
Es ist unverzichtbar, dass andere <strong>Sicherheit</strong>smaßnahmen, zum Beispiel starke<br />
Kennwörter, weiterhin verwendet werden. BitLocker verhindert auch nicht, dass Daten zerstört<br />
oder Denial-of-Service-Angriffe durchgeführt werden. Datensicherungen sind nach wie<br />
vor wichtig. Wenn Sie nicht sicherstellen, dass der Zugriff auf Wiederherstellungskennwörter<br />
möglich ist, könnte BitLocker sogar verhindern, dass Sie selbst auf Ihre Daten zugreifen!<br />
Wir empfehlen, die integrierte Fähigkeit von BitLocker zu nutzen, Wiederherstellungsinformationen<br />
in AD DS zu sichern. Weitere Informationen über das Sichern von Wiederherstellungsinformationen<br />
finden Sie in »Configuring Active Directory to Back Up <strong>Windows</strong> Bit-<br />
Locker Drive Encryption and Trusted Platform Module Recovery Information« unter<br />
http://technet2.microsoft.com/<strong>Windows</strong>Vista/en/library/3dbad515-5a32-4330ad6fd1fb6dfcdd411033.mspx?mfr=true.<br />
In <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Vista SP1 benutzt BitLocker eine kryptografische<br />
Signatur, um zu prüfen, ob bestimmte Arten gezielter Angriffe vorliegen. Falls einer dieser<br />
Angriffe auftritt, wird die kryptografische Signatur ungültig und BitLocker sperrt das Wiederherstellungskennwort<br />
sowie die üblichen Schlüsselschutzelemente. Das passiert nur, falls<br />
der Angreifer physischen Zugriff auf das Volume oder den Computer hat. Falls Sie das
426 Kapitel 15: Schützen von Zweigstellen<br />
Volume wiederbekommen, können Sie das BitLocker-Reparaturtool und eine Sicherungskopie<br />
des FVEK sowie das Wiederherstellungskennwort verwenden, um Ihre Daten wieder<br />
zu entsperren. Daher sollten Sie sicherstellen, dass diese Elemente über das AD DS-System<br />
oder den WMI-Anbieter gesichert werden.<br />
Denken Sie auch daran, dass BitLocker in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ein optionales Feature ist.<br />
Weil die Verschlüsselungs- und Entschlüsselungsoperationen in einem Filtertreiber implementiert<br />
sind, können Sie BitLocker nur nutzen, wenn Sie das Feature explizit installieren,<br />
wie weiter oben in diesem Kapitel beschrieben. Beachten Sie aber, dass Sie den <strong>Server</strong> neu<br />
starten müssen, wenn Sie BitLocker installieren oder entfernen.<br />
BitLocker unterstützt keine Cluster. Falls Sie <strong>Server</strong> in Failoverclustern konfigurieren, können<br />
Sie BitLocker nicht einsetzen, um freigegebene Volumes zu schützen.<br />
Wie alle Verschlüsselungsprodukte und -technologien benötigt BitLocker Rechenleistung. In<br />
den meisten Benutzerszenarien ist dieser Leistungsabfall kaum zu bemerken, üblicherweise<br />
beträgt er unter 5 Prozent. Falls Ihr <strong>Server</strong> allerdings laufwerksintensive Operationen durchführt<br />
oder sehr stark ausgelastet ist, müssen Sie diesen Faktor unter Umständen bei der Kapazitätsplanung<br />
berücksichtigen.<br />
Bei der <strong>Sicherheit</strong> müssen oft Kompromisse gefunden werden. Beim Einsatz von BitLocker<br />
muss beispielsweise entschieden werden, ob der Benutzer beim Start gezwungen wird, aktiv<br />
zu werden. In der Standardeinstellung nutzt BitLocker das TPM als Schlüsselschutz. Sofern<br />
die Integritätsprüfung erfolgreich verläuft, entsperrt BitLocker das <strong>Windows</strong>-Betriebssystemvolume,<br />
ohne dass der Benutzer tätig werden muss. Das bedeutet aber, dass ein <strong>Die</strong>b, der<br />
den gesamten <strong>Server</strong> stiehlt, ihn ebenfalls einschalten kann, ohne dass BitLocker ihn daran<br />
hindert.<br />
Um diese Gefahr einzudämmen, sollten Sie TPM mit einer PIN, einem USB-Flashlaufwerk<br />
(dem sogenannten Startschlüssel) oder beidem kombinieren. Das verbessert die <strong>Sicherheit</strong><br />
ganz entscheidend. Es bedeutet aber auch, dass ein <strong>Server</strong> nicht automatisch neu gestartet<br />
werden kann. (Es wäre idiotisch, einen Startschlüssel ständig am <strong>Server</strong> zu lassen.) Weil<br />
<strong>Server</strong> normalerweise laufen, ist das vermutlich kein Problem <strong>–</strong> bis ein Stromausfall dazu<br />
führt, dass die Zweigstelle lahmgelegt wird, weil der eine Manager, der die PIN kennt, gerade<br />
im Urlaub ist.<br />
Ich empfehle in den meisten Fällen, ein TPM und eine PIN zu benutzen, aber sicherzustellen,<br />
dass eine Betriebsprozedur definiert, wer die PIN kennt, wie sie benutzt wird und wie<br />
die PIN bei Bedarf vom zentralen Support angefordert werden kann. Das erfordert auch,<br />
dass eventuell geplante Neustarts (zum Beispiel für ein Betriebssystem-Upgrade oder<br />
Update) so geplant werden, dass zu diesem Zeitpunkt jemand vor Ort ist, der die PIN eingeben<br />
kann. Nur Ihre Organisation kann entscheiden, welche Gefahr größer ist: die einer<br />
längeren Ausfallzeit oder die eines <strong>Die</strong>bstahls des <strong>Server</strong>s.<br />
Andere <strong>Sicherheit</strong>smaßnahmen<br />
Ich denke, dass Sie sich mit zwei anderen Bereichen befassen müssen, um Ihre Zweigstellenserver<br />
zu schützen: physische <strong>Sicherheit</strong> und Benutzerschulung.<br />
Features wie RODC und BitLocker helfen zwar, die Gefahr einzudämmen, aber wenn ein<br />
Angreifer physischen Zugriff auf Ihre <strong>Server</strong> hat, ist das trotzdem ein gewaltiges Problem.<br />
Selbst wenn er es nicht schafft, auf die Daten zuzugreifen, kann er möglicherweise verhin-
Weitere Informationen 427<br />
dern, dass Ihre Benutzer darauf Zugriff bekommen. Schon moderate Investitionen im Bereich<br />
der physischen <strong>Sicherheit</strong> können die Verfügbarkeit der <strong>Die</strong>nste erhöhen.<br />
Ich höre ständig Geschichten, wie das Reinigungspersonal das Stromkabel von <strong>Server</strong>n<br />
abzieht, wie vermeidbare Wasserschäden auftreten und wie <strong>Server</strong> versehentlich heruntergefahren<br />
werden. Verwenden Sie Schränke oder Nebenräume, die ein vernünftiges Schloss<br />
haben. Sorgen Sie für Schutz durch eine USV. Stellen Sie sicher, dass die Be- und Entlüftung<br />
einwandfrei funktioniert. In großen Unternehmen mag das offensichtlich erscheinen,<br />
aber weiß man bei einem großen Unternehmen wirklich immer über den genauen Zustand<br />
jedes einzelnen <strong>Server</strong>s Bescheid, zum Beispiel dem in der LKW-Werkstatt oder in der<br />
Fabrikhalle?<br />
Investieren Sie auch in die Schulung der Benutzer. Erklären Sie, wie wichtig <strong>Sicherheit</strong> ist<br />
und wie die anvertrauten physischen und Datenaktiva mit Sorgfalt behandelt werden. Das<br />
dürfte in kleinen Zweigstellen noch wichtiger sein, dort, wo kein dediziertes IT-Personal<br />
vorhanden ist, geschweige denn jemand die Einhaltung von Richtlinien und <strong>Sicherheit</strong>smaßnahmen<br />
überwacht.<br />
Zusammenfassung<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wurde von Grund auf dafür entworfen, Zweigstellen zu unterstützen.<br />
Es bringt Tools mit, die es einfacher als je zuvor machen, Zweigstellen zu schützen. <strong>Die</strong><br />
Features RODC und BitLocker sind wichtige Waffen in Ihrem Verteidigungsarsenal.<br />
Weitere Informationen<br />
»<strong>Windows</strong> BitLocker Drive Encryption Frequently Asked Questions« unter<br />
http://technet2.microsoft.com/<strong>Windows</strong>Vista/en/library/58358421-a7f5-4c97-ab41-<br />
2bcc61a58a701033.mspx.<br />
»BitLocker Drive Encryption Technical Overview« unter http://technet2.microsoft.com/<br />
<strong>Windows</strong>Vista/en/library/ba1a3800-ce29-4f09-89ef-65bce923cdb51033.mspx.<br />
Data Encryption Toolkit for Mobile PCs unter http://www.microsoft.com/technet/<br />
security/guidance/clientsecurity/dataencryption/default.mspx.<br />
»BitLocker Drive Encryption Glossary« unter http://technet2.microsoft.com/<strong>Windows</strong><br />
<strong>Server</strong><strong>2008</strong>/en/library/af7c60f4-0a30-4aa1-af4f-304d58527c7b1033.mspx.<br />
»BitLocker Drive Encryption« in »Changes in Functionality from <strong>Windows</strong> <strong>Server</strong> 2003<br />
with SP1 to <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>« unter http://technet2.microsoft.com/windowsserver<br />
<strong>2008</strong>/en/library/0e0d96cd-935b-48d0-b5ba-c70a979fadbc1033.mspx<br />
»BitLocker Drive Encryption Step-by-Step Guide for <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>« unter<br />
http://technet2.microsoft.com/<strong>Windows</strong><strong>Server</strong><strong>2008</strong>/en/library/cbc28269-5146-4672-<br />
9161-8872697897061033.mspx.<br />
»<strong>Windows</strong> BitLocker Drive Encryption Step-by-Step Guide« (für <strong>Windows</strong> Vista) unter<br />
http://technet.microsoft.com/en-us/windowsvista/aa905089.aspx?id=2387.<br />
»<strong>Windows</strong> BitLocker Drive Encryption Design and Deployment Guides« unter<br />
http://www.microsoft.com/downloads/details.aspx?FamilyID=41BA0CF0-57D6-4C38-<br />
9743-B7F4DDBE25CD.
428 Kapitel 15: Schützen von Zweigstellen<br />
»Configuring Active Directory to Back Up <strong>Windows</strong> BitLocker Drive Encryption and<br />
Trusted Platform Module Recovery Information« unter http://www.microsoft.com/<br />
downloads/details.aspx?familyid=3A207915-DFC3-4579-90CD-86AC666F61D4<br />
»BitLocker Drive Encryption Events and Errors« unter http://technet2.microsoft.com/<br />
windowsserver<strong>2008</strong>/en/library/578ff4fb-1690-4e44-8955-73d146884c731033.mspx.<br />
»AD DS: Read-Only Domain Controllers« unter http://technet2.microsoft.com/windows<br />
server<strong>2008</strong>/en/library/ce82863f-9303-444f-9bb3-ecaf649bd3dd1033.mspx?mfr=true<br />
»Step-by-Step Guide for Read-Only Domain Controllers« unter http://technet2.microsoft.<br />
com/windowsserver<strong>2008</strong>/en/library/ea8d253e-0646-490c-93d3-b78c5e1d9db71033.<br />
mspx?mfr=true<br />
»Branch Office Infrastructure Solution for Microsoft <strong>Windows</strong> <strong>Server</strong> 2003 Release 2«<br />
unter http://www.microsoft.com/technet/solutionaccelerators/branch/default.mspx
K A P I T E L 1 6<br />
Aspekte für kleine Unternehmen<br />
Von Susan E. Bradley<br />
In diesem Kapitel:<br />
Betreiben von <strong>Server</strong>n bei knappem Budget ................................. 430<br />
<strong>Server</strong> für kleine Firmen ............................................... 433<br />
Verletzen aller Prinzipien mit <strong>Server</strong>n, die mehrere Rollen übernehmen . .............. 439<br />
Empfehlungen für kleine Unternehmen ..................................... 447<br />
Zusammenfassung .................................................. 468<br />
Weitere Informationen ................................................ 468<br />
Warum wird in kleinen bis mittelgroßen Organisationen <strong>Server</strong>sicherheit benötigt? Treffen<br />
Leute bessere Geschäftsentscheidungen, weil die Organisation sichere <strong>Server</strong> hat? In der<br />
Praxis sieht es bei vielen Organisationen so aus, dass die Budgets für <strong>Sicherheit</strong>sentscheidungen<br />
meist durch Regularien und Vorschriften gesteuert werden, und nicht weil es sinnvoll<br />
ist, Computersysteme zu schützen. PCI/DSS (Payment Card Industry Data Security<br />
Standards), HIPAA (Health Insurance Portability and Accountability Act) und andere Industriesicherheitsstandards<br />
haben sogar auf kleine Unternehmen Auswirkungen. Das Problem<br />
eines engen Budgets für den Bereich <strong>Sicherheit</strong> betrifft nicht nur kleine Organisationen, aber<br />
hier ist es normalerweise drängender.<br />
Können Sie das Netzwerk einer kleinen Organisation mit <strong>Server</strong>isolierung (siehe Kapitel 14,<br />
»Schützen des Netzwerks«), IPsec-Bereitstellung (siehe Kapitel 14), Rechteverwaltung,<br />
sicherem Drahtlosnetzwerkzugriff mit Authentifizierung über digitale Zertifikate (siehe<br />
Kapitel 10, »Implementieren der Active Directory-Zertifikatdienste«), BitLocker (siehe<br />
Kapitel 15, »Schützen von Zweigstellen«) und Bereitstellung von schreibeschützten<br />
Domänencontrollern (siehe Kapitel 15) einrichten, um maximalen Schutz zu gewährleisten?<br />
Natürlich ist das möglich. Heißt das auch, dass dies die beste Methode ist, das Technikbudget<br />
dieser kleinen Organisation aufzubrauchen? Oder sollte das Budget genutzt werden,<br />
um <strong>Sicherheit</strong>sbedrohungen zu verhindern, weil der Nachwuchsadministrator vor Ort den<br />
Domänencontroller so einrichtet, dass er in der Mittagspause Musik tauschen, BitTorrent<br />
betreiben oder Quake spielen kann? Ein Teil dieses Budgets wird möglicherweise sinnvoller<br />
verwendet, wenn Sie den Benutzern klarmachen, welche Gefahren ihre Aktionen für eine<br />
kleine Organisation bedeuten können. Vielleicht sollten Sie auch einen Teil des Budgets für<br />
die Anwaltskosten vorsehen, die mit der Entlassung oder Resozialisierung des erwähnten<br />
Nachwuchsadministrators verbunden sind.<br />
<strong>Die</strong>ses Kapitel liefert nicht alle Antworten, die Sie brauchen, um sichere <strong>Server</strong>lösungen<br />
bereitstellen zu können. Es leitet Sie aber durch den Prozess, die Risiken für ein kleines<br />
Unternehmen zu analysieren und die notwendigen Schritte einzuleiten, um diese Gefahren<br />
auf ein vernünftiges Maß zu senken. <strong>Sicherheit</strong> in einem kleinen Netzwerk bedeutet, die<br />
429
430 Kapitel 16: Aspekte für kleine Unternehmen<br />
Anforderungen des Unternehmens zu kennen, sodass Sie eine Lösung mit akzeptabler<br />
<strong>Sicherheit</strong> entwickeln können, die auf der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Produktfamilie aufbaut.<br />
Betreiben von <strong>Server</strong>n bei knappem Budget<br />
Das erste Probleme, das Sie beim Bereitstellen einer sicheren <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Lösung<br />
in einer kleinen Organisation anpacken müssen, ist die Frage von Kosten und Budgets. Gehen<br />
Sie das Problem der Budgets und Preise so an, dass Sie aktuelle und künftige Kosten<br />
abschätzen, inklusive Implementierung, Überwachung und Wartung, kombiniert mit akzeptablen<br />
Ausfallzeiten und akzeptablen Risiken. Verliert eine kleine Organisation Umsatz,<br />
wenn ein <strong>Sicherheit</strong>svorfall passiert und sie aufgrund von Vorschriften ihre Kunden darüber<br />
informieren muss? In der Praxis verstehen Kunden von Firmen, bei denen Daten abhanden<br />
gekommen sind, erstaunlicherweise recht genau, dass die Möglichkeit eines Identitätsdiebstahls<br />
besteht, wenn Datensicherungsbänder, Notebooks und ähnliche Datenträger verloren<br />
gehen. Vorfälle, bei denen Daten in unbefugte Hände gelangen, haben letztlich weniger<br />
finanzielle Auswirkungen auf die Organisationen, als Sie möglicherweise denken, wenn Sie<br />
sich die Schwere der <strong>Sicherheit</strong>svorfälle vor Augen führen. (Ein Beispiel ist in »The TJX<br />
Effect« von Larry Greenemeier in Information Week beschrieben.) <strong>Sicherheit</strong>svorfälle haben<br />
mehr dem Ruf der Consultants geschadet, die die Netzwerke bereitgestellt haben, als den<br />
betroffenen Firmen selbst. (Siehe zum Beispiel »Medical IT Contractor Folds After Breaches«,<br />
Tim Wilson, Dark Reading.)<br />
Falls die Organisation allerdings von einer Virusinfektion betroffen ist, die das Netzwerk<br />
weitläufig lahmlegt, sind die Folgen einfacher zu berechnen. In diesem Beispiel können Sie<br />
den Umsatzausfall pro Stunde beziffern. Multiplizieren Sie diese Zahl mit der Zahl der<br />
Stunden, die diese Organisation von dem <strong>Sicherheit</strong>svorfall betroffen ist, und fragen Sie den<br />
Kunden, ob diese Kosten akzeptabel sind. <strong>Die</strong> herkömmliche Formel für die Risikoberechnung<br />
lautet ALE = SLE * ARO, wobei ALE (Annualized Loss Expectancy) der Verlust im<br />
Gesamtjahr, SLE (Single Loss Expectancy) der bei einem einzelnen Vorfall zu erwartende<br />
Verlust und ARO (Annualized Rate of Occurrence) die Wahrscheinlichkeit ist, dass der Vorfall<br />
innerhalb eines Jahres auftritt. Dabei wird der Wert der Eindämmung nicht berücksichtigt.<br />
Außerdem wird das Problem ignoriert, wie schwierig es ist, das »was wäre, wenn« abzuschätzen.<br />
Das Konzept dieser überarbeiteten Risikoanalyse wird in einem Blogeintrag von<br />
Dr. Jesper Johansson vom Mai 2006 diskutiert.<br />
Es ist keine einfache Aufgabe, einem Klienten die Bedeutung der <strong>Sicherheit</strong> zu vermitteln,<br />
wenn noch kein Vorfall passiert ist. Das erinnert mich daran, was Bruce Turbeyville vom<br />
California Fire Safe Council in einem Interview nach einem verheerenden Brand sagte, bei<br />
dem im Lake Tahoe-Gebiet Ende 2007 Hunderte von Häusern zerstört wurden. Er klagte:<br />
»Warum ist immer genug Geld da, um das Feuer zu bekämpfen? Weil wir sie immer bekämpfen<br />
und sie immer gelöscht werden. Aber es ist niemals genug Geld da, um das Feuer<br />
zu verhindern.« <strong>Die</strong>selbe Klage stimmen viele Netzwerkadministratoren von kleinen Organisationen<br />
an. In einem kleinen Unternehmen hat derjenige, der die Technologie implementiert,<br />
gegenüber dem Kollegen im großen Netzwerk sicherlich einen Vorteil: Wenn das<br />
Management die vorgeschlagene <strong>Sicherheit</strong>slösung einmal genehmigt hat, haben diejenigen,<br />
die das Netzwerk implementieren, die völlige Kontrolle über das Netzwerk; sie brauchen<br />
sich nicht mit anderen Abteilungen, Organisationen oder Administratoren für bestimmte<br />
<strong>Server</strong>rollen abzustimmen.
Betreiben von <strong>Server</strong>n bei knappem Budget 431<br />
Direkt aus der Praxis: <strong>Die</strong> sehr reale Gefahr<br />
Wenn ich eine Risikobewertung für kleine und mittelgroße Unternehmen unter unseren<br />
Kunden durchführe, stelle ich meist fest, dass der größte Schwachpunkt bei solchen Organisationen<br />
darin besteht, dass sie nicht wissen, welche Datenaktiva tatsächlich in ihrem<br />
Unternehmen vorhanden sind und welchen Wert diese Aktiva im Arbeitsablauf des Unternehmens<br />
eigentlich haben.<br />
Es ist ziemlich sinnlos, die <strong>technische</strong>n <strong>Sicherheit</strong>seinrichtungen zum Schutz der Datenaktiva<br />
eines Unternehmens zu diskutieren, bevor wir wissen, welchen Bedrohungen das<br />
Unternehmen ausgesetzt ist. Und wir können die Dynamik solcher Bedrohungen erst bewerten,<br />
wenn wir tatsächlich wissen, welcher Schaden einem Unternehmen entsteht, falls<br />
solche Aktiva versehentlich oder absichtlich zerstört werden oder nicht mehr zugänglich<br />
sind. Wir müssen auch untersuchen, auf welche Aktiva ein Angreifer möglicherweise<br />
Zugriff bekommen möchte, und abschätzen, wie viel Aufwand er wohl investiert, um sich<br />
diesen Zugriff zu verschaffen. Erst dann können wir uns daran machen, den realen Wert<br />
der Daten zu beziffern, und zu entscheiden, welche Beträge für Schutzmaßnahmen aufgewendet<br />
werden sollen, um diese Risiken auf ein Maß einzudämmen, das für das Unternehmen<br />
noch akzeptabel ist.<br />
Dana Epp, Microsoft Security MVP<br />
Scorpion Software<br />
Auswählen der richtigen Plattformen und Rollen<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> macht eine Vielzahl von Auswahlmöglichkeiten verfügbar. Das reicht<br />
von der <strong>Windows</strong> <strong>Server</strong> Core-Installationsoption, die sich perfekt für viele Domänencontroller<br />
und <strong>Server</strong> an sicherheitskritischen Orten eignet, bis zu den unterschiedlichen Editionen,<br />
zum Beispiel Standard, Enterprise und Data Center, und <strong>Windows</strong> Web <strong>Server</strong> <strong>2008</strong>.<br />
Der schwierigste Teil beim Einrichten eines sicheren Netzwerks ist oft die Auswahl des<br />
richtigen Betriebssystems. Allerdings haben viele kleine Unternehmen dadurch auch die<br />
Möglichkeit, die billigeren Varianten zu nutzen, die auf dem Markt angeboten werden. Es<br />
gibt außerdem eine Vielzahl von Lizenzierungsbundles, die sich an unterschiedliche Organisationen<br />
richten, von Softwareherstellern über gemeinnützige Organisationen bis zu Lizenzmodellen<br />
für Entwicklungsländer. Machen Sie sich aber eines bewusst: Wenn der Preis des<br />
Produkts so günstig ist, dass Sie das kaum glauben können, gibt es dafür wahrscheinlich<br />
gute Gründe: Sie gehen das Risiko ein, dass der <strong>Server</strong> mit Raubkopien betrieben wird.<br />
Wenn Sie eine Raubkopie von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> einsetzen, kann das dazu führen, dass<br />
der <strong>Server</strong> in einen Modus mit eingeschränkter Funktionalität versetzt wird.<br />
Meist ist der größte Feind eines kleinen Netzwerks der Hersteller einer Branchenanwendung<br />
(Line-Of-Business, LOB), der versehentlich falsche Berechtigungen einstellt und so die<br />
Stabilität des Netzwerks gefährdet. Virtualisierungstechnologien erlauben einer kleinen<br />
Firma, diese Risiken zu verringern, ohne dabei das Hardwarebudget zu überziehen.<br />
Wenn Sie einen <strong>Server</strong> bereitstellen, sollten Sie nur die Rollen installieren, die unbedingt<br />
erforderlich sind, damit der <strong>Server</strong> seine Aufgaben erfüllen kann. Der Assistent "Rollen<br />
hinzufügen" in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> macht es Ihnen einfach, jederzeit eine Rolle hinzuzufügen.
432 Kapitel 16: Aspekte für kleine Unternehmen<br />
32- und 64-Bit-Versionen von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Im Desktopmarkt beginnen sich die 64-Bit-Plattformen nur zögerlich auszubreiten, aber der<br />
<strong>Server</strong>markt ist bereit für den Umstieg. <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> wird zwar sowohl als 32-Bit-<br />
als auch 64-Bit-Version geliefert, aber sogar für kleine Unternehmen lautet die Empfehlung,<br />
jetzt den Umstieg auf 64 Bit durchzuführen. <strong>Die</strong> <strong>Sicherheit</strong> ist zwar ein Faktor bei dieser<br />
Entscheidung, aber vor allem dürfte die Unterstützung für großen Arbeitsspeicher den Ausschlag<br />
für den Einsatz von 64-Bit-<strong>Windows</strong> geben. RAM ist billig. Datenbanken brauchen<br />
Arbeitsspeicher. Außerdem ist die Standard Edition von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> nicht mehr<br />
auf 4 GByte RAM beschränkt. Zu den Vorteilen der 64-Bit-Version gehört, dass kein Inplace-<br />
Upgrade von einer 32-Bit-Plattform durchgeführt werden kann. Ein altes Netzwerk, das mit<br />
32-Bit-<strong>Windows</strong>-<strong>Server</strong>n eingerichtet ist, kann also nicht direkt auf 64 Bit aktualisiert werden.<br />
Das mag wie ein Nachteil aussehen, es bringt aber einen wichtigen Vorteil im Bereich<br />
der <strong>Sicherheit</strong>: Berechtigungen. Wenn ein System im Inplace-Verfahren von einer älteren<br />
Version des Betriebssystems aktualisiert wurde, blieb früher immer eine Mischung aus den<br />
Berechtigungen des neuen und des alten Betriebssystems zurück. Sogar wenn der <strong>Server</strong><br />
von einem OEM-Anbieter vorinstalliert wurde, kann es sinnvoll sein, ihn von Grund auf neu<br />
zu installieren, um für den Notfall die erforderlichen Wiederherstellungstechniken einzuüben.<br />
In einer kleinen Organisation ist das oft eine gute Gelegenheit, den Notfallwiederherstellungsplan<br />
anhand des <strong>Server</strong>s, dessen Ausfall der Organisation am wenigsten Probleme<br />
bereitet, zu üben und zu dokumentieren.<br />
Hinweis Wenn Sie die 64-Bit-Version auswählen, sind einige Punkte im Bezug auf signierte Treiber und<br />
Netzwerkgeräte, Drucker oder andere Peripheriegeräte zu beachten, die direkt an den <strong>Server</strong> angeschlossen<br />
sind. Der Microsoft Knowledge Base-Artikel KB 895612 unter http://support.microsoft.com/kb/895612<br />
beschreibt, welche Probleme beim Einsatz von 64-Bit-<strong>Windows</strong>-Versionen auftreten können. Wie Sie in Abbildung<br />
16.1 sehen, steht in der 32-Bit-Version von <strong>Windows</strong> die Möglichkeit zur Verfügung, einen unsignierten<br />
Treiber trotzdem zu installieren, aber in der 64-Bit-Version lassen sich solche Treiber nicht installieren.<br />
Abbildung 16.1 Unsignierte Treiber haben in der Ära der 64-Bit-Plattformen große Auswirkungen<br />
Überprüfen Sie Ihre Netzwerkdrucker, USB-Geräte und andere Geräte, die Sie auf dem<br />
<strong>Server</strong> installieren wollen, und stellen Sie sicher, dass sie digital signierte Treiber haben.<br />
Unsignierte Treiber lassen sich nicht installieren. Weitere Informationen zu diesem Thema<br />
finden Sie im <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Application Compatibility Cookbook unter http://msdn2.<br />
microsoft.com/en-us/library/Aa480152.aspx. Früher waren unsignierte Treiber in <strong>Server</strong>n<br />
vor allem bei älteren Drucker- und Faxtreibern ein Thema, aber wie Sie in Abbildung 16.1<br />
sehen, kann sogar die Installation einer neuen externen USB-Festplatte dazu führen, dass<br />
die Installation durch diese Warnung unterbrochen wird.
<strong>Server</strong> für kleine Firmen 433<br />
Bei vielen Organisationen sind die Hauptaufgaben für einen <strong>Server</strong> eine LOB-Datenbankanwendung<br />
und eine Messaging-Plattform mit einem gemeinsam genutzten Kalender. Weil<br />
Microsoft Exchange <strong>Server</strong> 2007 nur in einer 64-Bit-Version zur Verfügung steht, brauchen<br />
Sie dafür zwangsläufig einen 64-Bit-<strong>Server</strong> als Basisbetriebssystem. Exchange 2007 SP1<br />
wird auf der 64-Bit-Version von <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> vollständig unterstützt.<br />
<strong>Die</strong> <strong>Server</strong>versionen für kleine Unternehmen<br />
<strong>Die</strong> folgenden <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Versionen eignen sich am besten für kleine Organisationen:<br />
<strong>Windows</strong> Web <strong>Server</strong> <strong>2008</strong> eignet sich, um öffentliche Websites zu hosten.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Standard eignet sich als Allzweck-<strong>Server</strong>plattform.<br />
<strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> ist ein <strong>Server</strong> mit mehreren Rollen, der speziell<br />
für kleine Organisationen entwickelt wurde.<br />
<strong>Windows</strong> Essential Business <strong>Server</strong> ist ein neues Bundle aus drei <strong>Server</strong>n, das speziell<br />
für mittelgroße Organisationen entwickelt wurde.<br />
<strong>Server</strong> für kleine Firmen<br />
Wenn Sie eine sichere Lösung einrichten wollen, besteht der erste Schritt darin, eine geeignete<br />
Grundlage auszuwählen, auf der Sie Ihre Lösung aufbauen. Berücksichtigen Sie die<br />
Expansionspläne des Unternehmens und wählen Sie eine geeignete Plattform.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Web Edition<br />
Wenn Sie eine öffentlich zugängliche Website einrichten, müssen Sie das richtige Werkzeug<br />
für diese Aufgabe wählen. <strong>Die</strong> Internetinformationsdienste 6 (Internet Information Services,<br />
IIS) sind zwar eine grundsolide Webplattform mit einer rekordverdächtigen <strong>Sicherheit</strong>, und<br />
von den Internetinformationsdiensten 7 ist dasselbe zu erwarten, aber der gesunde Menschenverstand<br />
gebietet einfach, eine öffentlich zugängliche Website nicht auf Ihrem kritischen<br />
Unternehmensserver zu hosten. Greifen Sie entweder auf einen externen Hoster zurück<br />
(es gibt Unmengen von Anbietern, auch <strong>Windows</strong> Live steht zur Auswahl) oder kaufen<br />
Sie die Web Edition und richten Sie einen separaten <strong>Server</strong> ein. Kleine Organisationen betreiben<br />
zwar manchmal Webdienste auf Domänencontrollern, um Remotezugriff und E-Mail<br />
zu ermöglichen, Sie sollten aber Websites, die anonyme Verbindungen zulassen, von authentifizierten<br />
trennen, um die Risiken zu minimieren.<br />
<strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong><br />
Seit vielen Jahren stellt Microsoft eine <strong>Server</strong>plattform zusammen, die <strong>Server</strong>verwaltung<br />
und Computerarbeitsplatztechnologien für bis zu 75 Benutzer oder Geräte zusammenfassen.<br />
In der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Familie wird die <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong>-<br />
Plattform nur auf 64-Bit-Plattformen zur Verfügung gestellt. Sie kombiniert Microsoft<br />
SQL <strong>Server</strong>, <strong>Windows</strong> SharePoint Services, <strong>Windows</strong> Softwareupdate Services und Teile<br />
von Forefront, Microsofts <strong>Sicherheit</strong>ssuite für Exchange, <strong>Windows</strong> SharePoint Services<br />
und <strong>Windows</strong>-Clients.
434 Kapitel 16: Aspekte für kleine Unternehmen<br />
Wie in der <strong>Windows</strong> <strong>Server</strong> 2003-Familie kann die Standardversion von <strong>Windows</strong> Small<br />
Business <strong>Server</strong> <strong>2008</strong> keine Vertrauensbeziehungen zu anderen Domänen herstellen, und die<br />
enthaltenen Produkte lassen sich nicht auf andere <strong>Server</strong> auslagern (das wird auch im Endbenutzerlizenzvertrag<br />
untersagt). In der Standardinstallation des Produkts muss alles auf<br />
einem einzigen <strong>Server</strong> liegen. Remotezugriff auf Arbeitsstationen, E-Mail und <strong>Windows</strong><br />
SharePoint Services wird über ein SSL-geschütztes (Secure Sockets Layer) Webportal mit<br />
dem Namen Remote Web Workplace zur Verfügung gestellt.<br />
Ebenfalls im Produkt enthalten sind die bekannten Administrationsassistenten. Sie werden<br />
von den meisten geliebt, von einigen aber auch gehasst. <strong>Die</strong>se Assistenten sind skriptgesteuerte<br />
Routinen zum Installieren, Einrichten und Bereitstellen von DNS (Domain Name System),<br />
Active Directory (AD), Internetverbindungen und anderen Netzwerk- und Bereitstellungsaufgaben.<br />
Außerdem stellen sie sicher, dass sich die Bereitstellung einfach, konsistent<br />
und sicher reproduzieren lässt. Grundlegende Aufgaben des <strong>Server</strong>s werden für den lokalen<br />
Administrator oder den Remoteconsultant klar und deutlich definiert (Abbildung 16.2).<br />
Abbildung 16.2 Aufgabenverwaltung in <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong><br />
<strong>Die</strong> größte Änderung an der <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong>-Plattform ist, dass sie<br />
mit einer Netzwerkschnittstellenkarte bereitgestellt wird und eine externe Firewall erfordert.<br />
ISA <strong>Server</strong>, die Firewallsoftware von Microsoft, kann nicht mehr auf einem einzelnen Small<br />
Business <strong>Server</strong> <strong>2008</strong>-<strong>Server</strong> installiert werden. Auf dem <strong>Server</strong> kann auch nicht die RRASbasierte<br />
(Routing and Remote Access Service, Routing- und RAS-<strong>Die</strong>nst) Firewall eingerichtet<br />
werden, die früher in der Standardversion verwendet wurde, um alternative Firewallfunktionalität<br />
zur Verfügung zu stellen. Da die <strong>Windows</strong>-Firewall aktiviert ist, wird die<br />
RRAS-basierte IP-Paketfilterungsfirewall nicht mehr unterstützt und auch nicht empfohlen.<br />
Wie in Abbildung 16.3 gezeigt, muss diese separate Firewall jetzt außerhalb des Domänencontrollers<br />
angeordnet werden, sodass <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> die Richtlinien<br />
erfüllt, die empfehlen, die Firewall vom Domänencontroller zu trennen und so eine <strong>Server</strong>rolle<br />
aus dem System zu entfernen.<br />
Kunden mit Software Assurance bekommen den ISA <strong>Server</strong>, für den sie eine Lizenz besitzen,<br />
separat geliefert.
Abbildung 16.3 Der Netzwerkaufbau wird in <strong>Windows</strong> Small<br />
Business <strong>Server</strong> <strong>2008</strong> deutlich verändert<br />
<strong>Server</strong> für kleine Firmen 435<br />
Auswählen einer Firewall<br />
In <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> gibt es die neue Fähigkeit, eine verstärkte externe<br />
Firewall zu verwenden, die den <strong>Server</strong> ergänzt. Besprechen Sie mit dem Firmeninhaber,<br />
welche Nutzung des Internets er toleriert. Fragen Sie, ob in der Organisation in<br />
der Vergangenheit <strong>Sicherheit</strong>svorfälle aufgetreten sind und wodurch Viren-, Malware-<br />
und andere Probleme verursacht wurden. Überzeugen Sie den Inhaber, dass es vermutlich<br />
sinnvoller ist, das Netzwerkbudget mit einer teureren Firewall für den Unternehmenseinsatz<br />
zu belasten, die für etwa für 200 bis 800 Euro zu haben ist. Sie gibt der Firma die<br />
Fähigkeit, ein- und ausgehende Verbindungen flexibler zu filtern als das 40-Euro-Modell<br />
für Heimanwender, dem solche Möglichkeiten fehlen. Das kann die beste Investition sein,<br />
die diese Organisation tätigt. <strong>Die</strong> Möglichkeit, eine geeignete Firewall auszuwählen, die<br />
sich für die Anforderungen der Organisation am besten eignet, gewährleistet maximale<br />
Flexibilität und Nutzen für den Bereich kleiner Organisationen, die auf diese Weise einen<br />
maßgeschneiderten Schutz einrichten können. <strong>Die</strong>se Fähigkeit war in früheren Versionen<br />
dieser Produktlinie nicht vorhanden.<br />
Genau wie in älteren Versionen können Sie einen zusätzlichen <strong>Server</strong> für weitere Domänencontroller,<br />
Anwendungsserver, Datei- und Druckserver oder sonstige Aufgaben hinzufügen.<br />
Weitere Informationen über die <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong>-Plattform finden Sie<br />
auf der Microsoft Small Business <strong>Server</strong>-Website unter http://www.microsoft.com/sbs.
436 Kapitel 16: Aspekte für kleine Unternehmen<br />
Direkt von der Quelle: Sicher von Anfang an<br />
Bei der Entwicklung des <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> war <strong>Sicherheit</strong> ein zentrales<br />
Entwurfsziel, das sich vom Setup bis zum Ausmustern des Produkts zieht. Viele<br />
<strong>Sicherheit</strong>sverbesserungen sind in diesem neuen <strong>Server</strong>produkt Standardeinstellungen.<br />
Beispiele dafür sind:<br />
Sichere Kennwortrichtlinien<br />
Anlegen eines neuen Administratorkontos, sodass das Administratorkonto nicht allgemein<br />
bekannt ist<br />
Eine lokale Hostfirewalllösung, die auf der neuesten Version der <strong>Windows</strong>-Firewall<br />
aufbaut und Kernfunktionalität zur Verfügung stellt<br />
SSL-basierte Websicherheit mithilfe von kostenlosen (selbstausgestelltes Zertifikat)<br />
oder von kommerziellen Zertifizierungsstellen ausgestellten Zertifikaten, um den<br />
Webverkehr zu schützen<br />
Antispamfeatures durch Exchange <strong>Server</strong> 2007<br />
Integrierter WSUS 3.0 mit Richtlinien für automatische Genehmigung von kritischen,<br />
<strong>Sicherheit</strong>s- und Updates für das gesamte Netzwerk<br />
Zentrale Verwaltung auf dem <strong>Server</strong>, um <strong>Sicherheit</strong>sdienste zu überwachen und zu<br />
steuern<br />
<strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> kann nur als interner <strong>Server</strong> bereitgestellt werden,<br />
wobei eine einzige Netzwerkschnittstelle verwendet wird. Indem <strong>Windows</strong> Small Business<br />
<strong>Server</strong> <strong>2008</strong> als interner <strong>Server</strong> bereitgestellt wird, kann flexibel eine Firewalllösung<br />
gewählt werden, die sich für das Unternehmen eignet. Abhängig von der Wichtigkeit der<br />
Daten und der Bedeutung des Internetzugriffs kann das Unternehmen entweder eine einzelne<br />
Hardwarefirewall bereitstellen, um das Netzwerk zu schützen, oder Microsofts ISA<br />
<strong>Server</strong> (Internet Security and Acceleration) auf einem separaten Computer einrichten, um<br />
authentifizierten Zugriff auf das Internet zu ermöglichen und paketgefilterten Verkehr aus<br />
dem Internet hineinzulassen. <strong>Die</strong>se Flexibilität ermöglicht es dem Unternehmen, frei zu<br />
wählen, wo es wertvolle Ressourcen investieren will, um eine Lösung mit maßgeschneiderter<br />
<strong>Sicherheit</strong> für das Unternehmen zu erreichen.<br />
In <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> erfolgt Remotezugriff auf das Unternehmen in<br />
erster Linie über HTTPS-Webverkehr über Remote Web Workplace. Benutzer können<br />
sicher auf Web-E-Mail, interne Websites und die Dateien und Ordner ihres Benutzerprofils<br />
zugreifen, die auf dem <strong>Server</strong> abgelegt sind. Außerdem haben sie sicheren, verschlüsselten<br />
Zugriff auf ihren Desktopcomputer über das Remote Desktop Protocol. Wenn die<br />
Benutzer Domänenadministratoren sind, können sie auf diesem Weg auch auf den <strong>Server</strong><br />
zugreifen.<br />
<strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> ist die sicherste Version des Small Business <strong>Server</strong>s.<br />
Sie wird demnächst erhältlich sein.<br />
Sean Daniel, Program Manager<br />
Microsoft Corporation
<strong>Server</strong> für kleine Firmen 437<br />
<strong>Windows</strong> Essential Business <strong>Server</strong><br />
Das nächste <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Produkt, das die Produktfamilie ergänzen wird, ist der<br />
Microsoft <strong>Windows</strong> Essential Business <strong>Server</strong>. Er enthält eigentlich gleich drei <strong>Server</strong>: einen<br />
mit der Verwaltungsrolle, der primäre Active Directory-<strong>Die</strong>nste zur Verfügung stellt, den<br />
sogenannten Messaging-<strong>Server</strong>, der Exchange 2007 und zusätzliche Domänencontrolleraufgaben<br />
zur Verfügung stellt, und den <strong>Sicherheit</strong>sserver, auf dem ISA <strong>Server</strong> und bestimmte<br />
Edge-Messaging-Komponenten für Exchange bereitgestellt werden. Der ISA <strong>Server</strong> auf dem<br />
Edge-System wird mit zwei Netzwerkschnittstellenkarten in einer Domänenkonfiguration<br />
bereitgestellt, die sich für die Rollen- und Risikoabwägung in kleineren Organisationen<br />
eignet (Abbildung 16.4).<br />
Abbildung 16.4 <strong>Windows</strong> Essential Business <strong>Server</strong><br />
Wie sein kleinerer Verwandter, <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong>, steht auch <strong>Windows</strong><br />
Essential Business <strong>Server</strong> nur als 64-Bit-Version für alle drei <strong>Server</strong> zur Verfügung. <strong>Die</strong> drei<br />
<strong>Server</strong> bilden ein sicheres Netzwerk, das mit dem Ziel entworfen wurde, es einem lokalen<br />
Administrator einfacher zu machen, das Netzwerk mit möglichst wenig Problempotenzial<br />
bereitzustellen und zu schützen. Tools wie System Center Essentials 2007 sind eingebaut,<br />
um sicherzustellen, dass die <strong>Sicherheit</strong>sanforderungen mittelgroßer Organisation erfüllt sind<br />
und alle Verfahrensempfehlungen zur Isolierung von <strong>Die</strong>nsten und Rollen unter den <strong>Server</strong>n<br />
eingehalten werden.<br />
<strong>Die</strong>se Plattform ist kein aufgebohrter SBS <strong>2008</strong>, sondern Microsoft liefert damit eine<br />
Lösung für mittelgroße Unternehmen, die sowohl von Anforderungen als auch Regelwerken<br />
eingeengt werden, sodass Verwaltungsaufgaben entstehen, die es früher in dieser Form nicht<br />
gab. <strong>Die</strong> Aufgaben wurden so entworfen, dass die Administratoren Software einfacher bereitstellen,<br />
Desktopcomputer schützen und sicherstellen können, dass die Netzwerkrichtlinien<br />
eingehalten werden. Netzwerkverwaltung und -kontrolle sind ein Hauptziel bei diesem<br />
<strong>Server</strong>produkt. Es stellt auch ein Remotezugriffsportal für <strong>Die</strong>nste und Arbeitsstationen<br />
zur Verfügung, das den standardisierten Begutachtungsprozess Microsoft Secure Development<br />
Lifecycle durchlaufen hat. Da außerdem schon standardmäßig die Messaging-Hygiene-<br />
Technologien aus Exchange Edge <strong>Server</strong> bereitgestellt werden, um die Anforderungen einer<br />
solchen Organisation zu erfüllen, wird <strong>Windows</strong> Essential Business <strong>Server</strong> zweifellos eine<br />
sehr interessante Ergänzung in der Familie der sichereren <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Produkte.
438 Kapitel 16: Aspekte für kleine Unternehmen<br />
Gehostete <strong>Server</strong><br />
Das Konzept der gehosteten <strong>Server</strong> ist relativ neu im Bereich der kleinen Unternehmen. Bei<br />
einem gehosteten <strong>Server</strong> wird ein <strong>Server</strong>, der unter einer <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Version<br />
läuft, in einem Datencenter bereitgestellt. Ein gehosteter <strong>Server</strong> kann interessant sein, wenn<br />
die Anforderungen eines Kunden sich nur dadurch erfüllen lassen, dass Anwendungen gemeinsam<br />
genutzt werden. Dabei werden VPN-Verbindungen, Outlook Anywhere (früher als<br />
RPC über HTTP bekannt) und <strong>Windows</strong> SharePoint Services eingesetzt. Voraussetzung ist,<br />
dass die Konnektivität und Geschwindigkeit der angeschlossenen Arbeitsstationen optimal<br />
sind. Für gehostete <strong>Server</strong> sind etwas andere <strong>Sicherheit</strong>saspekte zu berücksichtigen. Weil die<br />
<strong>Server</strong> physisch in einem Datencenter stehen, sind die <strong>Sicherheit</strong>srichtlinien dieses Datencenters<br />
der entscheidende Faktor. Viele Datencenter lassen ihre <strong>Sicherheit</strong>sprozesse von<br />
externen Gutachtern bewerten, in den ISA zum Beispiel mit einem »Report on the Processing<br />
of Transactions by Service Organizations«, bekannter unter der Bezeichnung SAS 70-<br />
Audit. Bitten Sie Ihr Hostingunternehmen, Ihnen eine Kopie eines solchen Berichts zuzuschicken.<br />
Virtualisierung<br />
Wenn Sie vor der Entscheidung stehen, welche <strong>Server</strong>plattform Sie als Ausgangsbasis für<br />
Ihre <strong>Sicherheit</strong>slösung verwenden sollen, gibt es schließlich noch eine weitere Möglichkeit:<br />
Virtualisierung. Sie bringt wiederum eigene Probleme und Vorteile mit sich. In einer kleinen<br />
Umgebung sind üblicherweise gar nicht die Ressourcen für Clustering vorhanden, und das<br />
Wiederherstellen von Daten auf einem nackten <strong>Server</strong> braucht Zeit und birgt Risiken, wenn<br />
die Wiederherstellung auf anderer Hardware durchgeführt werden muss. Wenn Sie die gesamte<br />
<strong>Server</strong>plattform auf einen virtuellen <strong>Server</strong> verlagern, kann die Wiederherstellung<br />
auch nach Hardwareproblemen schnell durchgeführt werden. Bei jedem Virtualisierungsprojekt<br />
gibt es aber auch Risiken, darunter Probleme der physischen <strong>Sicherheit</strong>, richtige Netzwerkkonfiguration<br />
und vor allem Supportfragen. Im Bereich der kleinen Unternehmen wird<br />
die Virtualisierung auf einer Nicht-Microsoft-Plattform nur unterstützt, falls Sie einen<br />
Premier Support-Vertrag haben.<br />
Weitere Informationen zur Virtualisierung<br />
Das Thema »Virtualisierung von Produktivservern« würde den Rahmen dieses Buchs<br />
sprengen. Wenn Sie sich für das Thema interessieren, finden Sie hier weitere Informationen:<br />
Lesen Sie den Leitfaden in »Microsoft Virtual <strong>Server</strong> Support Policy« unter http://<br />
support.microsoft.com/kb/897613 und »<strong>Windows</strong> <strong>Server</strong> System Software Not Supported<br />
within a Microsoft Virtual <strong>Server</strong> Environment« unter http://support.microsoft.<br />
com/kb/897614/. Dort wird beschrieben, welche Plattformen in einer virtuellen Umgebung<br />
unterstützt werden.<br />
Einzelheiten zur Supportrichtlinie für Virtualisierung auf Nicht-Microsoft-Plattformen<br />
finden Sie in »Support Policy for Microsoft Software Running in Non-Microsoft<br />
Hardware Virtualization Software« unter http://support.microsoft.com/kb/897615 und<br />
»Support Policy for Microsoft Programs That Are Running in a Third-party Application<br />
or Software Redirection Program or in a Third-party Application or Software Virtualization<br />
Environment« unter http://support.microsoft.com/kb/924287.
Verletzen aller Prinzipien mit <strong>Server</strong>n, die mehrere Rollen übernehmen 439<br />
Verletzen aller Prinzipien mit <strong>Server</strong>n, die mehrere<br />
Rollen übernehmen<br />
Ein <strong>Sicherheit</strong>sexperte bekommt es ernsthaft mit der Angst zu tun, wenn er sich ansieht,<br />
welche Menge von <strong>Die</strong>nsten auf einem typischen <strong>Server</strong> in einem kleinen Unternehmen<br />
läuft. <strong>Die</strong> meisten <strong>Sicherheit</strong>sexperten (insbesondere Experten, die sich nicht gut mit den<br />
Anforderungen und Risiken kleiner Unternehmen auskennen) haben vor allem wegen der<br />
Angriffsfläche Bedenken, die von all diesen <strong>Die</strong>nste erzeugt wird, und wegen des kumulativen<br />
Effekts aufgrund der fehlenden Isolierung. Ich habe einmal gezählt, wie viele <strong>Server</strong><br />
nötig wären, wenn die Verfahrensempfehlungen strikt befolgt werden: Es waren insgesamt<br />
12 <strong>Server</strong>. Offensichtlich ist ein solche Zahl von <strong>Server</strong>n für eine typische kleinere Organisation<br />
nicht machbar. Abbildung 16.5 zeigt acht Beispielrollen, die viele Multi-Rollen-<br />
<strong>Server</strong> ausführen. Das sind Datei-, E-Mail-, Datenbank-, Web-, Active Directory-, Druck-,<br />
Mobility-<strong>Server</strong> und natürlich die berühmteste Rolle, der »<strong>Server</strong> für alles andere«, im englischen<br />
Sprachraum auch als »Kitchen-Sink-<strong>Server</strong>« (Ausgussbecken) bekannt.<br />
Abbildung 16.5 Der typische Multi-Rollen-<strong>Server</strong><br />
Bei einer kleinen Organisation ist aber normalerweise die Gefahr einer Fehlkonfiguration<br />
größer (zum Beispiel dass jemand den Remotezugriff falsch einrichtet) als die Gefahr, mehrere<br />
Rolle auf demselben <strong>Server</strong> bereitzustellen. Als Gesamtpaket ist bei einem richtig konfigurierten<br />
Multi-Rollen-<strong>Server</strong> mit einfachen Schritt-für-Schritt-Anleitungen die Chance<br />
größer, dass er sicher ist, als bei einem selbst zusammengestellten, von Hand installierten<br />
<strong>Server</strong> in einer kleinen Organisation ohne dediziertes und gut ausgebildetes IT-Personal.<br />
Für jemanden, der das System wartet, zählt vor allem das Problem, dass sich Updates und<br />
erforderliche Neustarts häufen. Der Microsoft-Mitarbeiter Jose Barreto hat in seinem Blog<br />
http://blogs.technet.com/josebda festgestellt, dass bei einer typischen <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-<br />
Installation weniger als 50 <strong>Die</strong>nste laufen. Aber auf dem üblichen <strong>Windows</strong> Small Business<br />
<strong>Server</strong> <strong>2008</strong> laufen über 100 <strong>Die</strong>nste, und das sogar, bevor irgendwelche LOB-Anwendungen<br />
auf dem Computer bereitgestellt werden. Unter SBS 2003 waren es noch 67 <strong>Die</strong>nste,
440 Kapitel 16: Aspekte für kleine Unternehmen<br />
die in der Normalkonfiguration liefen. Zwar erfordert jeder laufende <strong>Die</strong>nst Zeit und Aufwand,<br />
um die Berechtigungen und Rechte richtig zu konfigurieren (in Kapitel 6, »<strong>Die</strong>nste«,<br />
finden Sie weitere Informationen über einzelne <strong>Die</strong>nste), aber Sie müssen eine fundamentale<br />
Tatsache akzeptieren, wenn Sie einen Multi-Rollen-<strong>Server</strong> einrichten: Sie brauchen Wartungsfenster<br />
für diese Art <strong>Server</strong>. Falls die Organisation null Ausfallzeit vorschreibt, ist ein<br />
Multi-Rollen-<strong>Server</strong> nicht geeignet.<br />
Akzeptable Rollen<br />
Wenn Sie eine Lösung mit akzeptabler <strong>Sicherheit</strong> implementieren sollen, müssen Sie festlegen,<br />
welche Rollen und Aufgaben auf diesem <strong>Server</strong> akzeptabel sind und welche nicht.<br />
Prüfen Sie, welche Anwendungen Sie für das Netzwerk bereitstellen wollen. In vielen Organisationen<br />
wird für wichtige LOB-Anwendungen, die auf einer Datenbankplattform aufbauen,<br />
nicht empfohlen, sie auf dem Domänencontroller in <strong>Windows</strong> Small Business <strong>Server</strong><br />
<strong>2008</strong> oder dem Dateiserver in der <strong>Windows</strong> Essential Business <strong>Server</strong>-Plattform zu betreiben,<br />
sondern stattdessen einen dedizierten <strong>Server</strong> für diese Anwendung einzusetzen. Normalerweise<br />
ist es einfacher, ein solches System zu schützen und geeignete NTFS-Dateisystemberechtigungen<br />
dafür festzulegen. Es ist dann auch einfacher, die Speichernutzung<br />
der Anwendung im Zaum zu halten. Wenn Sie Virtualisierung einsetzen, sollten Sie sich<br />
vom Konzept echter Hardware für solche Multi-<strong>Server</strong>bereitstellungen lösen. Es gibt nichts<br />
daran auszusetzen, viele dieser LOB-Anwendungen auf virtuelle <strong>Server</strong> zu verlegen. Außerdem<br />
wurde schon so manches Netzwerk destabilisiert, weil ein Hersteller eine SQL <strong>Server</strong>-<br />
Datenbank auf einem laufenden <strong>Server</strong> installierte und unbewusst alle Anwendungen plattmachte,<br />
die bereits die Standard-SQL-Instanz benutzten.<br />
<strong>Server</strong>komponenten<br />
Viele Parameter bei der <strong>Server</strong>bereitstellung werden durch die Rolle des Messaging entschieden.<br />
In der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Produktfamilie hat sich gegenüber der <strong>Windows</strong><br />
<strong>Server</strong> 2003-Familie vor allem geändert, dass das Modell der <strong>Server</strong>rollen übernommen<br />
wurde, das in Microsoft Exchange <strong>Server</strong> 2007 eingeführt wurde. <strong>Die</strong> Rollen umfassen<br />
Mailboxserver, Clientzugriffsserver, Hubtransportserver, Unified-Messaging-<strong>Server</strong> und<br />
Edge-Transportserver. <strong>Die</strong> Rolle des Edge-Transportservers verarbeitet den Fluss der gesamten<br />
Internetmail für eine Organisation. Sie muss auf einem separaten, eigenständigen <strong>Server</strong><br />
liegen, um die Angriffsfläche des Exchange-<strong>Server</strong>s zu verkleinern. Sie können alle fünf<br />
Rollen auf fünf unterschiedliche <strong>Server</strong> verteilen, wenn Sie möchten, oder vier davon zusammenfassen.<br />
Aber die Edge-Transportserverrolle sollte auf einem separaten <strong>Server</strong> betrieben<br />
werden (Abbildung 16.6). <strong>Die</strong> Ausnahme von dieser Regel ist die <strong>Windows</strong> Small Business<br />
<strong>Server</strong> <strong>2008</strong>-Plattform. Augrund einer speziellen Konfiguration ist sie in der Lage, die<br />
entsprechende Funktionalität auf einem einzigen <strong>Server</strong> bereitzustellen.<br />
Wenn Sie die vielen Artikel lesen, die über die Bereitstellung dieser Edge-Rolle geschrieben<br />
wurden, stellen Sie fest, dass viele davon darauf bestehen, dass die Edge-Rolle nicht in<br />
einer Domäne liegen sollte, um die sicherste Konfiguration zu erreichen. Microsofts eigene<br />
Dokumente zur Bereitstellung der <strong>Server</strong>rolle weisen klugerweise darauf hin, dass nicht alle<br />
Unternehmen diese »sicherste« Konfiguration benötigen, um ein akzeptabel geschütztes<br />
Netzwerk zu betreiben.
Verletzen aller Prinzipien mit <strong>Server</strong>n, die mehrere Rollen übernehmen 441<br />
Abbildung 16.6 <strong>Die</strong> Rollen von Microsoft Exchange <strong>Server</strong> 2007<br />
Einen ausführlicheren Überblick über die Anforderungen für die Bereitstellung von Exchange<br />
<strong>Server</strong> 2007 in Ihrer Organisation finden Sie in den folgenden Microsoft Press-<br />
Büchern: Microsoft Exchange <strong>Server</strong> 2007 <strong>–</strong> Das Handbuch von Walter Glenn (2007)<br />
und Microsoft Exchange <strong>Server</strong> 2007 <strong>–</strong> Taschenratgeber für Administratoren von William<br />
Stanek (2007).<br />
Risikofaktoren<br />
Weiter oben in diesem Kapitel haben Sie erfahren, dass alle Anwendungen und Rollen unter<br />
<strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> auf demselben <strong>Server</strong> laufen müssen. Aber hier reden<br />
wir nun darüber, welche Rollen akzeptabel sind und dass Microsoft die Edge-<strong>Server</strong>rolle auf<br />
einen separaten <strong>Server</strong> ausgelagert hat, um die Angriffsfläche von Exchange <strong>Server</strong> zu verkleinern.<br />
Offensichtlich sind dies zwei völlig widersprüchliche Ansätze. Nicht nur der<br />
Microsoft-Leitfaden rät, dass Exchange <strong>Server</strong> eine Edge-Rolle braucht und dass Domänencontroller<br />
keine Dateiserver sein sollten; auch alle anderen Leitfäden und Empfehlungen,<br />
die einem Consultant für kleine Unternehmen zur Verfügung stehen, geben entsprechende<br />
<strong>Sicherheit</strong>srichtlinien und Regeln aus. Wie also lässt sich Ihre Multi-Rollen-Lösung rechtfertigen?<br />
Der Schlüssel besteht darin, die Risiken sinnvoll abzuwägen.<br />
Eindämmung über gehostetes Messaging<br />
<strong>Die</strong> erste empfohlene Eindämmung besteht darin, die Datei-, Druck- und Datenbankrollen<br />
auf dem <strong>Server</strong> bereitzustellen, aber die gesamte Messaging-Komponente auf eine gehostete<br />
Exchange-Lösung auszulagern. Das bedeutet aber, dass jemand außerhalb Ihrer Organisation<br />
Zugriff auf die gesamte E-Mail-Kommunikation und alle Meetingtermine Ihrer Organisation<br />
hat. Das ist für viele Organisationen ein Hinderungsgrund. Dank RPC über HTTPS (jetzt als
442 Kapitel 16: Aspekte für kleine Unternehmen<br />
Outlook Anywhere bezeichnet) bietet Outlook 2007 (und sogar 2003) praktisch nahtlose<br />
Möglichkeiten, einen leistungsfähigen Messaging-Client in einer gehosteten Umgebung zu<br />
benutzen. Mit Outlook Web Access 2007 hat sich OWA von einem unbeholfenen Möchtegern-Outlook<br />
zu einer leistungsfähigen browserbasierten Webmaillösung gewandelt, die<br />
sogar vergleichbare Suchfähigkeiten bietet wie sein Desktopgegenstück.<br />
Das Technologieproblem<br />
Steve Riley, Senior Security Strategist bei Microsoft, schreibt unter http://blogs.technet.<br />
com/steriley/archive/2007/07/02/protect-your-data-everything-else-is-just-plumbing.aspx<br />
in seinem Blog, dass alle Anstrengungen, die wir für die Diskussion über Technologie<br />
aufwenden, besser auf andere Aufgaben gerichtet werden sollte. Wenn Sie sich ansehen,<br />
wodurch <strong>Sicherheit</strong>svorfälle in kleinen Organisationen in der Vergangenheit meist ausgelöst<br />
wurden, stellen Sie fest, dass der Großteil der <strong>Sicherheit</strong>sprobleme durch laxe Kontrolle<br />
auf der Stufe von Arbeitsstationen entstanden, nicht durch Remoteangriffe auf den<br />
<strong>Server</strong>. Für eine kleine Organisation ist Malware, die durch leichtsinniges Browsen, Anklicken<br />
von E-Postkarten-Links in E-Mails und Phishing-Angriffe in das Netzwerk gelangt,<br />
viel gefährlicher als ein direkter zielgerichteter Angriff. Malwarecocktails der Vergangenheit<br />
zielten auf verschiedene <strong>Sicherheit</strong>slücken in Apple QuickTime und Flash und<br />
betteten diese Malwarecocktails in Webbanneranzeigen und andere Stellen ein. (Einzelheiten<br />
finden Sie unter http://blog.washingtonpost.com/securityfix/2007/06/the mother<br />
of all exploits 1.html.) Abbildung 16.7 zeigt, wo bei einer kleinen Organisation die<br />
eigentliche Gefahr lauert.<br />
Abbildung 16.7 Das Arbeitsstations-Risiko<br />
Der stärksten Gefahr ist oft nicht der <strong>Server</strong> ausgesetzt, sondern die Arbeitsstation, wo<br />
der Chef die persönliche E-Mail in Webmail liest, regelmäßig Social-Networking-Sites<br />
besucht, alle diese »Nackte tanzende Schweine«-Bildschirmschoner herunterlädt und jede<br />
eingetrudelte »Achtung! Ihr Konto bei der Woodgrove Bank wurde aufgrund verdächtiger<br />
Aktivitäten gesperrt!«-E-Mail öffnet. Verschwenden Sie Ihre Zeit nicht damit, technologische<br />
Lösungen für ein Problem zu finden, bevor Sie in Ruhe die zugrunde liegende Ursache<br />
für den <strong>Sicherheit</strong>svorfall analysiert haben. Ich habe zu oft erlebt, dass Leute mich<br />
fragen, wie sie den <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> härten können, wenn er bereits<br />
ausreichend sicher ist. Vielmehr muss in den meisten kleinen bis mittelgroßen Organisationen<br />
den Arbeitsstationen mehr Aufmerksamkeit gewidmet werden, weil von ihnen die<br />
größte Gefahr für das Netzwerk ausgeht.
Verletzen aller Prinzipien mit <strong>Server</strong>n, die mehrere Rollen übernehmen 443<br />
Eindämmung mit dem SDL-Prozess<br />
Wenn Sie einen <strong>Server</strong> mit mehreren Rollen zur Verfügung stellen wollen, der eine<br />
Messaging-Komponente enthält, steht als zweite Eindämmungstechnik die Möglichkeit zur<br />
Verfügung, <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> zu wählen. Nein, das ist kein Marketingtrick,<br />
um Sie dazu zu bringen, <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> zu kaufen. Es ist die<br />
Anerkennung, dass dieses Produkt denselben Gefahrenmodellierungs- und Codesicherheitsprozess<br />
durchläuft wie alle anderen Microsoft-Anwendungen und -Plattformen. <strong>Die</strong>ser<br />
SDL-Prozess (Security Development Lifecycle) stellt sicher, dass bei der Entwicklung der<br />
entsprechenden Produkte die <strong>Sicherheit</strong> ausreichende berücksichtigt wurde. Wenn diese<br />
Plattform daher ausgeliefert wird, hat sie bereits eine akzeptable Risikobewertung hinter<br />
sich. Sie wurde entwickelt, um einen Multi-Rollen-<strong>Server</strong> für kleine Organisationen zu<br />
implementieren, der einen vernünftigen Kompromiss im Bereich der <strong>Sicherheit</strong> findet, aber<br />
trotzdem die Anforderung kleiner Unternehmen erfüllt. <strong>Die</strong>s ist die einzige <strong>Server</strong>lösung,<br />
die in der Lage ist, das Risiko der Edge-Rolle einzudämmen, während sich diese Rolle auf<br />
demselben <strong>Server</strong> befindet. Man könnte sagen, dass <strong>Windows</strong> Essential Business <strong>Server</strong>,<br />
Microsofts Plattform für mittelgroße Unternehmen, dasselbe Ziel für eine Bereitstellung mit<br />
3 <strong>Server</strong>n erreicht. Beide Produkte liefern Ihnen einen sicheren Basisserver, auf dem Sie<br />
sichere Netzwerklösungen aufbauen können.<br />
Grenzserver<br />
Das Schlüsselelement bei all diesen Multi-Rollen-Bereitstellungen (aber nicht Multi-<strong>Server</strong>-<br />
Bereitstellungen) ist zu überprüfen, was Sie in die Grenzposition (engl. edge) legen müssen<br />
oder wollen. Analysieren Sie die Anforderungen der Organisation, um diese Grenzposition<br />
zu schützen und eine geeignete Lösung bereitzustellen. <strong>Die</strong>se Lösung kann eine ISA-Firewall<br />
sein, die Pakete untersucht, bevor sie in das Netzwerk gelassen werden. Es kann aber<br />
auch ein billiges Firewallgerät eines Fremdherstellers sein oder eine billige ISA-basierte<br />
Hardwarefirewall. Unabhängig davon, welches Gerät an der Grenze Ihres Netzwerks aufgestellt<br />
ist, wird dringend empfohlen, dass Sie prüfen, auf welche Weise es Verkehr protokolliert,<br />
der über diese Verbindung läuft. Falls Sie Kapitel 8, »Überwachung«, gelesen haben,<br />
aber noch nicht überzeugt sind, dass Überwachung wichtig ist, sollten Sie dieses Kapitel<br />
gleich noch einmal lesen. Sobald (und ich schreibe bewusst nicht »falls«) ein <strong>Sicherheit</strong>svorfall<br />
in einer Organisation passiert, können Sie sich nur dann ein vollständiges Bild davon<br />
machen, wie die relevanten Elemente in und aus Ihrer Organisation gelangt sind, wenn dieses<br />
Grenzgerät die Aktivitäten protokolliert hat. Es ist egal, ob diese Organisation ein Großunternehmen<br />
mit einem lokalen Forensikteam oder eine kleine Organisation ist, die bei<br />
Microsofts <strong>Sicherheit</strong>sabteilung der Customer Support Services anruft und darum bittet, eine<br />
forensische Onlineanalyse durchzuführen. Außerdem kann die Lösung, die Sie in der Grenzposition<br />
installieren, bei der Eindämmung von Angriffen helfen, wenn Richtlinien vorhanden<br />
sind, die zum Beispiel nur E-Mail vom Mailserver zulassen und jegliche E-Mail von<br />
internen Arbeitsstationen sperren (um Arbeitsstations-Zombies zu verhinder).
444 Kapitel 16: Aspekte für kleine Unternehmen<br />
Proaktive Internet- und Zugriffsrichtlinien<br />
Wenn Sie dabei sind, Richtlinien für die Einschränkung des Internetzugriffs zu formulieren,<br />
sollten Sie auch versuchen, vorbeugend dafür zu sorgen, dass die Arbeitsstationen im<br />
Netzwerk nichts tun können, was sie nicht tun sollen. Zum Beispiel sollte eine Arbeitsstation<br />
in einem typischen Netzwerk keinen Verkehr über Port 25 senden. Falls das geschieht,<br />
wurde sie wahrscheinlich in einen Spam-Zombie verwandelt. Aber Sie können<br />
vorbeugende Schritte unternehmen, um diesen Verkehr zu verhindern. Abbildung 16.8<br />
zeigt ein Beispiel für eine Einschränkungsregel, die im ISA <strong>Server</strong> definiert wird.<br />
Abbildung 16.8 Im ISA <strong>Server</strong> können Sie Edge-Richtlinien definieren<br />
<strong>Die</strong> Beispielrichtlinie sieht so aus:<br />
Aktion: Verweigern, Anforderung protokollieren<br />
Protokolle: Ausgewählt: SMTP<br />
Von: LAN (ein definierter IP-Adressbereich der Arbeitsstationen, aber ohne<br />
<strong>Server</strong>-, Drucker- und Scanner-IPs, die explizit definiert und im DHCP-<strong>Server</strong><br />
als Ausschlüsse eingetragen sind)<br />
An: Alle<br />
Benutzer: Alle<br />
Zeitplan: Immer<br />
Ergreifen Sie die Initiative<br />
Kleine Unternehmen neigen anfangs oft dazu, Einschränkungen für die Internetnutzung<br />
abzulehnen. Daher sieht der übliche Entwurf für den Netzwerkzugriff so aus, dass alle<br />
authentifizierten Arbeitsstationen vollständigen Webzugriff haben. Später wird dem Unternehmensinhaber<br />
bewusst, dass die Angestellten zu viel Zeit auf Social-Networking-Websites<br />
oder beim Austausch von Instant-Messaging verbringen. Daher werden Sie später oft beauftragt,<br />
den Internetzugriff einzuschränken. Das geschieht nicht vorbeugend, sondern als reine<br />
Reaktion, weil das Internet für arbeitsfremde Zwecke genutzt wird. Ihre beste <strong>Sicherheit</strong>slösung<br />
ist immer vorbeugend und vorausschauend, keine reine Reaktion. Versuchen Sie, die<br />
Bedrohungen richtig vorherzusagen.<br />
Falls Sie schon einmal die Kommentare in einem Onlineforum zum Thema <strong>Sicherheit</strong> überflogen<br />
haben, ist Ihnen vermutlich aufgefallen, dass eine Empfehlung darin besteht, <strong>Die</strong>nste<br />
auf andere Ports zu verlegen. Bei großen Organisationen ist das relativ nutzlos, weil die<br />
Angreifer nach ungewöhnlich hohem Verkehr suchen, ganz egal, über welchen Port er läuft.<br />
In einer kleinen Organisation kann das ein gewisser <strong>Sicherheit</strong>sgewinn sein, aber im Allgemeinen<br />
sollten Sie lieber sicherstellen, dass möglichst wenige Ports auf externe Anforderungen<br />
antworten.
Verletzen aller Prinzipien mit <strong>Server</strong>n, die mehrere Rollen übernehmen 445<br />
Support und Updates<br />
Kapitel 13, »Patchverwaltung«, beschreibt, was Sie über <strong>Sicherheit</strong>supdates wissen müssen,<br />
aber bei Multi-Rollen-<strong>Server</strong>n sind bezüglich Support und Updateverwaltung einige Besonderheiten<br />
zu beachten. Wegen der großen Zahl von <strong>Die</strong>nsten, die auf demselben System<br />
laufen, ist die Problembehandlung schwieriger. Das bedeutet nicht, dass Probleme sich nicht<br />
beseitigen lassen, aber wenn sie auftauchen, sollten Sie sicherstellen, dass der Hersteller, mit<br />
dem Sie zusammenarbeiten, darüber informiert ist, dass es sich um einen Multi-Rollen-<strong>Server</strong><br />
handelt. Zum Beispiel setzen manche Fremdherstelleranwendungen möglicherweise voraus,<br />
dass unterschiedliche Versionen von .NET installiert sind. Und Hersteller müssen wissen,<br />
dass ihre Anwendung auf einem gemeinsam genutzten <strong>Server</strong> läuft, sodass sie keine unangemessenen<br />
Änderungen an Berechtigungen vornehmen, ihr Produkt über vorhandene Websites<br />
installieren oder einen der vielen anderen Fehler machen, mit dem Hersteller in der<br />
Vergangenheit schon so manchen Multi-Rollen-<strong>Server</strong> lahmgelegt haben.<br />
Tipp Virtualisierung von LOB-Anwendungen<br />
Wenn Sie eine LOB-Anwendung installieren, sollten Sie sich überlegen, ob Sie Virtual <strong>Server</strong> verwenden<br />
können. Dann läuft die Anwendung getrennt von Ihren anderen <strong>Server</strong>rollen. So ist sichergestellt, dass der<br />
Hersteller die Wartung des Multi-Rollen-<strong>Server</strong>s, auf dem Sie die Anwendung ausführen, nicht behindern<br />
kann.<br />
Rechnungen für die Updateverwaltung<br />
Falls Sie Consulting für kleine Unternehmen anbieten, ist es häufig schwierig, die Kunden<br />
davon zu überzeugen, dass eine Updateverwaltung unverzichtbar ist. Den Nutzen eines Service<br />
Packs für eine kleine Organisation zu beziffern, kann sehr schwierig sein. Es kann den<br />
Betrieb stören. Es verursacht Kosten für den Kunden. Außerdem bringt ein Service Pack<br />
unter Umständen nicht die Vorteile, die der Inhaber eines kleinen Unternehmens anerkennt.<br />
Consultants können normalerweise eine kleine Organisation überzeugen, dass eine <strong>Sicherheit</strong>supdateverwaltung<br />
gebraucht wird. Aber es ist schon schwieriger, sie davon zu überzeugen,<br />
dass ein großes Service Pack gebraucht wird, das auch größere Risiken für Ausfallzeiten<br />
birgt. Am besten lässt sich dieses Problem lösen, wenn Sie es vom Standpunkt des Supportaufwands<br />
angehen. Es wird zwar dringend empfohlen, Service Packs für <strong>Server</strong> nicht<br />
gleich mittags an dem Tag zu installieren, an dem das Service Pack veröffentlicht wird, aber<br />
es ist sinnvoll, solche Service Packs innerhalb eines nicht allzu großen Zeitraums nach der<br />
Freigabe bereitzustellen. Wenn ein neues Service Pack für ein <strong>Server</strong>produkt freigegeben<br />
wird, ist das normalerweise ein Zeichen dafür, dass der Support für irgendeine Vorgängerversion<br />
bald eingestellt wird. Sie sollten das Ziel verfolgen, niemals zwangsweise ein<br />
Service Pack bereitstellen zu müssen, nur um Hilfe von den Microsoft Customer Support<br />
Services zu erhalten. Befassen Sie sich mit den Produktlebenszyklen und Service Pack-<br />
Roadmaps (http://www.microsoft.com/windows/lifecycle/servicepacks.mspx) und bleiben<br />
Sie immer in dem Zeitrahmen, für den Support angeboten wird.<br />
Tipp Testen bei der Updateverwaltung<br />
Nutzen Sie die Leistungsfähigkeit der Virtualisierung, um Nachbildungen Ihres Netzwerks aufzubauen. Sie<br />
können Abbilder von Datenträgern erstellen und praktisch alles außer den Benutzern selbst von der physischen<br />
in die virtuelle Welt kopieren. Das ist sehr nützlich, um <strong>Sicherheit</strong>supdates zu testen.
446 Kapitel 16: Aspekte für kleine Unternehmen<br />
Wenn Sie Updates im Netzwerk eines kleinen Unternehmens einspielen, brauchen Sie unbedingt<br />
einen guten Rücknahmeplan. Updates von <strong>Server</strong>betriebssystemen können deinstalliert<br />
werden. Anwendungsupdates für <strong>Windows</strong> SharePoint Services und Exchange <strong>Server</strong> können<br />
normalerweise nicht deinstalliert werden. Updates für Arbeitsstationen haben üblicherweise<br />
weniger Auswirkungen auf das Netzwerk. Falls Sie ein <strong>Sicherheit</strong>supdate installiert<br />
haben und anschließend schwerwiegende Auswirkungen auf dem <strong>Server</strong> sichtbar werden,<br />
sollten Sie es deinstallieren. Falls das Update der Schuldige war, werden die Netzwerkfunktionen<br />
normalerweise vollständig wiederhergestellt.<br />
Tipp Remoteupdateverwaltung<br />
Sie können die meisten <strong>Sicherheit</strong>supdates erfolgreich installieren, ohne das Netzwerk großer Gefahr<br />
auszusetzen. Bei Service Packs und allen Updates, die Auswirkungen auf ein Grenzgerät (zum Beispiel<br />
ISA <strong>Server</strong>) haben, ist das Risiko höher, den Remotezugriff während des Updateprozesses zu verlieren.<br />
Melden Sie sich immer an der Terminalserver-Konsolensitzung an, wenn Sie eine Remoteupdateverwaltung<br />
durchführen.<br />
Abbildung 16.9 Hinzufügen des Sicherungsfeatures zu <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Wiederherstellen des <strong>Server</strong>s<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthält eine neu entwickelte Datensicherungsoftware. NTbackup ist<br />
veraltet und wird nur mit Lesezugriff installiert, um die Wiederherstellung von alten Medien<br />
zu ermöglichen. Neu bei der <strong>Server</strong>sicherung ist eine Datensicherung auf Blockebene. Falls<br />
Sie in <strong>Windows</strong> Vista schon eine Datensicherung durchgeführt haben, kennen Sie das Prinzip<br />
bereits. <strong>Die</strong> native <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Sicherung bietet keine Verschlüsselung. Daher
Empfehlungen für kleine Unternehmen 447<br />
muss überprüft werden, wie die Sicherungsmedien langfristig außerhalb des Standorts<br />
geschützt gelagert werden können.<br />
Halten Sie immer eine Wiederherstellungsrichtlinie bereit (vorzugsweise getestet und<br />
dokumentiert) für den Fall, dass ein Multi-Rollen-<strong>Server</strong> wiederhergestellt werden muss.<br />
Bei <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Essential Business <strong>Server</strong> werden<br />
externe USB- und FireWire-Geräte unterstützt und es ist ein Sicherungssetup-Assistent<br />
enthalten. Wie in Abbildung 16.9 gezeigt, müssen Sie in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> das Feature<br />
<strong>Windows</strong> <strong>Server</strong>-Datensicherung installieren. Wenn der Notfall erst einmal eingetreten ist,<br />
ist das sicher nicht der richtige Zeitpunkt, um Prozesse für die Notfallwiederherstellung und<br />
die Fortsetzung des Geschäftsbetriebs zu entwickeln.<br />
Systemstatussicherung<br />
Vielleicht fragen Sie sich, wo die Systemstatussicherung in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> geblieben<br />
ist. Sie ist nach wir vor in der Befehlszeile zu finden:<br />
wbadmin start systemstatebackup<br />
wbadmin start systemstaterecovery<br />
wbadmin delete systemstatebackup<br />
Anwendungsbeispiel: wbadmin start systemstaterecovery <strong>–</strong>backupTarget:f:<br />
Vor jeder größeren Änderung am <strong>Server</strong> wird für kleine bis mittelgroße Organisationen<br />
empfohlen, eine schnelle Systemzustandssicherung durchzuführen, wie in Abbildung<br />
16.10 gezeigt.<br />
Abbildung 16.10 Befehlszeile für die Systemstatussicherung<br />
Da Sie wahrscheinlich nicht mit dem Update warten wollen, bis eine vollständige Volumedatensicherung<br />
fertig ist, sollten Sie diesen kleinen Befehl in die Änderungsverwaltung<br />
für einen Multi-Rollen-<strong>Server</strong> aufnehmen. <strong>Die</strong> geplante Änderungsverwaltung ist<br />
ein Schlüsselfaktor für Stabilität und <strong>Sicherheit</strong> eines Multi-Rollen-<strong>Server</strong>s.<br />
Empfehlungen für kleine Unternehmen<br />
Wenn Sie Verfahrensempfehlungen für kleine Unternehmen entwerfen, sollten Sie eine<br />
potenzielle Falle vermeiden: Eine <strong>Sicherheit</strong>scheckliste, die von einer großen Beraterfirma<br />
erstellt wurde, die sich nie die Anforderungen und Risiken Ihrer kleinen Organisation angesehen<br />
hat, ist unter Umständen nicht die optimale Checkliste. Es passiert einfach zu leicht,<br />
dass Sie sich in Einzelheiten verlieren und den Wald vor lauter Bäumen nicht sehen.
448 Kapitel 16: Aspekte für kleine Unternehmen<br />
Warnung Verfahrensempfehlungen<br />
<strong>Die</strong>ser Abschnitt hat zwar den Begriff »Empfehlungen« im Titel, aber entscheiden Sie immer selbst, welche<br />
Empfehlungen für die Organisation, die Sie gerade analysieren, tatsächlich die besten sind. Nur weil Verfahrensempfehlungen<br />
in irgendwelchen Checklisten oder Dokumenten stehen, heißt das noch lange nicht,<br />
dass Sie tatsächlich für Ihren konkreten Fall optimal sind.<br />
<strong>Die</strong>ses Buch beschäftigt sich zwar mit <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, was sich ja schon aus dem<br />
Titel ergibt, aber Sie dürfen sich nicht zu sehr darauf konzentrieren, wie Sie den <strong>Server</strong> härten,<br />
wenn Sie dabei völlig vergessen, wie unsicher das übrige Netzwerk ist. Ein Consultant<br />
muss sich auch mit den Kunden auseinandersetzen. Der Kunde (oder Ihr Chef) hat nicht<br />
immer recht, aber er zahlt Ihr Gehalt. Wenn Sie beauftragt werden, etwas bereitzustellen, das<br />
Sie für fragwürdig halten, müssen Sie selbst entscheiden, ob Sie die Gelegenheit nutzen<br />
sollten, etwas Aufklärung zu betreiben, oder dem Kunden einfach den Rücken kehren und<br />
einen anderen Auftrag suchen. Und umgekehrt müssen Sie bereit sein, sich hinter Ihre<br />
Lösung zu stellen. Dazu sollten Sie Ihre Eindämmung dokumentieren und bereit sein, Ihre<br />
Entscheidungen zu begründen, wenn externe Auditoren Ihre bereitgestellte Lösung in<br />
Frage stellen.<br />
Befolgen von Leitfäden zur <strong>Server</strong>härtung<br />
Vor langer, langer Zeit trat ich einmal einer Gruppe von Branchenexperten bei, als ich nach<br />
einer richtungsweisenden Liste der Dinge suchte, die ich an meinem Small Business <strong>Server</strong><br />
2003 optimieren könnte. Wie viele andere war ich fasziniert von der Aussicht, dass die Tweaks<br />
und Optimierungen mich schützen würden. Und natürlich war es aufregend, mich in die<br />
unerforschte Wildnis der Registrierung vorzukämpfen. Schließlich weisen die Scripting<br />
Guys (so nennen sich die Autoren des Tools) in der Dokumentation des Tools Tweakomatic<br />
eindringlich darauf hin, welch grässliche Dinge einem zustoßen, wenn man auch nur den<br />
kleinsten Fehler macht.<br />
Bei näherem Hinsehen stellte ich allerdings fest, dass niemand wirklich wusste, was mit<br />
meinem <strong>Server</strong> und den darauf laufenden LOB-Anwendungen passieren würde, wenn ich<br />
diese Tweaks vornahm. Im Allgemeinen kennen sich die Leute, die diese Tweaks entwerfen,<br />
perfekt mit den Details aus, haben aber keine Ahnung, wie sie sich auf eine Anwendung<br />
auswirken. Umgekehrt weiß ein Anwendungsentwickler selten, von welchen Tweaks der<br />
Code abhängt. Würde mein <strong>Server</strong> überleben? Oder würde ich durch die Änderungen in der<br />
Registrierung versehentlich Microsoft Bob erzeugen, wie die Scripting Guys vorhersagen?<br />
(Siehe http://www.microsoft.com/technet/scriptcenter/tools/twkmatic.mspx.) Viele der Einstellungen<br />
verrieten mir zwar, dass der <strong>Server</strong> weiterhin als Domänencontroller funktionieren<br />
würde, aber sie konnten mir nicht sagen, ob die kritische Software, die für mich unverzichtbar<br />
war, ihre Arbeit einstellte, wenn ich mit irgendwelchen Einstellungen herumspielte,<br />
die interessant klangen. Und während der Telefonkonferenzen in den nächsten Wochen, bei<br />
denen die Experten die Auswirkungen jeder Einstellung diskutierten, kristallisierte sich heraus,<br />
dass alle <strong>Sicherheit</strong>sexperten für den Fall, dass die sichersten Härtungseinstellungen<br />
benutzt wurden (»Supersicherheit <strong>–</strong> Eingeschränkte Funktionalität«), praktisch garantieren<br />
konnten, dass irgendetwas nicht mehr funktionierte. Letztlich müssen Sie sich für eine Seite<br />
entscheiden: Ihre Geschäftsbedürfnisses oder Ihre Paranoia.
Empfehlungen für kleine Unternehmen 449<br />
Vorsicht <strong>Die</strong> Gefahr von <strong>Sicherheit</strong>sleitfäden<br />
Sie können beliebig viele Leitfäden und Checklisten von Fremdherstellern hernehmen und auf <strong>Server</strong><br />
beliebiger Größe anwenden, aber falls Ihnen nicht absolut klar ist, dass nun nur noch Sie allein den Support<br />
für diesen <strong>Server</strong> erledigen können, riskieren Sie in leichtsinniger Weise die Wartbarkeit dieses <strong>Server</strong>s<br />
und letztlich die Umsätze des Unternehmens.<br />
Falls Sie versucht sind, Änderungen anhand von <strong>Sicherheit</strong>sleitfäden vorzunehmen, würde<br />
ich dringend empfehlen, solche Änderungen erst einmal in einem Testnetzwerk (mit guter<br />
Datensicherung) auszuprobieren. Lesen Sie dieses Buch. Lesen Sie <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Security Guide, <strong>Windows</strong> Vista Security Guide und <strong>Windows</strong> XP Security Guide, die Sie alle<br />
im Microsoft Download Center unter http://www.microsoft.com/downloads finden. Falls<br />
eine Einstellung interessant klingt, können Sie sie ausprobieren, aber Sie müssen sich immer<br />
bewusst sein, dass Sie anschließend alles testen müssen. Sie haben nämlich gerade Ihre<br />
eigene Version des Betriebssystems gebaut. Und künftig müssen Sie alle Updates oder Installation<br />
auf Ihrem speziell angepassten <strong>Server</strong> testen. Fragen Sie sich selbst, ob die vorgenommene<br />
Optimierung dieses Netzwerk wirklich sicherer gemacht hat. Sie haben jetzt die<br />
Gefahr erzeugt, dass der <strong>Server</strong> künftig nicht mehr gewartet werden kann, aber im Bezug<br />
auf wirkliche <strong>Sicherheit</strong> kaum etwas erreicht.<br />
Jedem, der die Zuweisung des Privilegs Auslassen der durchsuchenden Überprüfung geändert<br />
und dann Microsofts <strong>Sicherheit</strong>sbulletin 05-051 angewendet hat, wurde das äußerst<br />
schmerzlich bewusst, wie in KB 909444 dokumentiert ist: »Bei Systemen, in denen die<br />
Standardberechtigungen für Zugriffssteuerungslisten im Verzeichnis "%WinDir%\registration"<br />
geändert wurden, können nach der Installation von Microsoft Security Bulletin MS05-<br />
051 für COM+ und MS DTC verschiedene Probleme auftreten« (siehe http://support.micro<br />
soft.com/kb/909444/). Insbesondere auf einem Multi-Rollen-<strong>Server</strong> haben die Entwickler die<br />
<strong>Sicherheit</strong>sanforderungen bereits gegen die Funktionalität des <strong>Server</strong>s abgewogen und einen<br />
sinnvollen Kompromiss gefunden. Sie müssen lediglich die Richtlinien festlegen, die Auswirkungen<br />
auf die Endbenutzer haben. Solange Sie die Installations- und Bereitstellungsassistenten<br />
nutzen, ist der <strong>Server</strong> selbst geschützt.<br />
Auch Leitfäden, die sich an größere Unternehmen richten, können verwirrend sein, weil sie<br />
davon ausgehen, dass die <strong>Server</strong> nur eine einzige Rolle übernehmen. Wenn Sie die <strong>Windows</strong>-<strong>Sicherheit</strong>sleitfäden,<br />
dann den Exchange-Leitfaden und schließlich den SQL <strong>Server</strong>-<br />
Leitfaden lesen, können Sie gar nicht mehr so einfach sagen, welchen Empfehlungen<br />
Sie denn nun folgen sollen. Sie müssen sich klarmachen, dass dies nur Richtlinien sind.<br />
Sie dürfen sie nicht als verpflichtend betrachten.<br />
Spezielle Härtung für kleine Netzwerke<br />
Sie haben dieses Kapitel also aufgeschlagen in der Hoffnung, eine Checkliste zu finden.<br />
Gut, hier wird Ihr Wunsch erfüllt. Ja, sie ist recht kurz. Wenn Sie die Assistenten in <strong>Windows</strong><br />
Small Business <strong>Server</strong> <strong>2008</strong> und <strong>Windows</strong> Essential Business <strong>Server</strong> verwenden,<br />
um Ihre <strong>Server</strong>lösungen einzurichten, sparen Sie eine Menge Zeit, die Sie nutzen können,<br />
um die eigentliche Quelle aller <strong>Sicherheit</strong>sprobleme anzugehen: die Desktopcomputer,<br />
auf denen die Endbenutzer nach wie vor mit den Rechten eines Systemadministrators<br />
arbeiten. Und dann müssen Sie sich gemeinsam mit dem Unternehmensinhaber hinsetzen<br />
und feststellen, wo seine Schmerzgrenze überschritten wird. Dabei können Sie nicht blind<br />
einer Checkliste folgen, die für Großunternehmen entwickelt wurde. Welcher konkrete
450 Kapitel 16: Aspekte für kleine Unternehmen<br />
Leitfaden wird nun für kleine Netzwerke empfohlen? Hier folgen einige spezifische »Verfahrensempfehlungen«,<br />
die Sie beachten sollten. Sie alle sind speziell für kleine Unternehmen<br />
sinnvoll. Einige dieser Empfehlungen gebietet der gesunde Menschenverstand.<br />
Andere sind Vorschläge für Änderungen am <strong>Server</strong>, die Verfahrensempfehlungen (engl.<br />
best practices) sind und auch in PCI/DSS-Richtlinien auftauchen:<br />
1. Legen Sie die Richtlinien für Passphrasen so fest, dass sie sich für das Unternehmen<br />
eignen. Wenn sie längere und komplexere Passphrasen erzwingen, können Sie den<br />
Zeitraum zwischen obligatorischen Kennwortänderungen verlängern.<br />
2. Schränken Sie den externen Zugriff auf <strong>Server</strong> und Desktopcomputern ein, indem Sie<br />
sowohl eine externe Firewall als auch interne hostbasierte Firewalls einsetzen.<br />
3. Verwenden Sie bei Bedarf einen externen Mailsäuberungsdienst, um den externen<br />
Zugriff auf Port 25 und Ihre Mailserver einzuschränken.<br />
4. Öffnen Sie in der Firewall nur die externen Ports, die unbedingt benötigt werden.<br />
Stellen Sie mit einem Portscanner sicher, dass die Ports geöffnet sind, die Sie tatsächlich<br />
verwenden wollen.<br />
5. Schränken Sie den Terminalserverzugriff auf dem <strong>Server</strong> entweder dadurch ein, dass<br />
Sie eine VPN-Verbindung erzwingen, oder indem Sie den Zugriff auf bestimmte statische<br />
IP-Ports begrenzen. Stellen Sie sicher, dass die externe Firewall, die Sie verwenden,<br />
die Fähigkeit bietet, den Zugriff auf bestimmte Ports einzuschränken.<br />
6. Wenn Sie dafür sorgen, dass alle Arbeitsstationen unter <strong>Windows</strong> XP oder <strong>Windows</strong><br />
Vista laufen, können Sie strengere Authentifizierung erzwingen.<br />
7. Schränken Sie den Internetzugriff auf solche Websites ein, die für die Aufgaben im<br />
Unternehmen benötigt werden. Diskutieren Sie mit dem Unternehmensinhaber, wie<br />
weit er die private Nutzung von Firmeneigentum tolerieren will, und richten Sie die<br />
entsprechenden Beschränkungen ein.<br />
8. Prüfen Sie alle Fremdherstellersoftware, die auf dem <strong>Server</strong> und auf Arbeitsstationen<br />
installiert ist. Stellen Sie fest, ob die Software die Gefahr für das Netzwerk erhöht und<br />
ob es bei Bedarf eine Updatemöglichkeit gibt.<br />
9. Stellen Sie sicher, dass der <strong>Server</strong> nur für <strong>Server</strong>aufgaben benutzt wird. Surfen Sie<br />
damit nie im Web und nutzen Sie den <strong>Server</strong> nicht als Arbeitsstation.<br />
10. Schulen Sie Endbenutzer zum Thema <strong>Sicherheit</strong>. Bringen Sie ihnen bei, dass sie bezüglich<br />
E-Mail-Anhängen, Links und anderen Verlockungen gesundes Misstrauen<br />
walten lassen. Ein kompetenter Endbenutzer ist in einem kleinen Netzwerk oft der<br />
größte <strong>Sicherheit</strong>sgewinn.<br />
11. Formulieren Sie einen Notfallwiederherstellungsplan und testen Sie ihn. Testen Sie<br />
ihn richtig.<br />
12. Installieren Sie das Zertifikat einer anerkannten Zertifizierungsstelle, das für den<br />
Remotezugriff auf den <strong>Server</strong> benutzt wird. Sowohl <strong>Windows</strong> Small Business <strong>Server</strong><br />
<strong>2008</strong> als auch <strong>Windows</strong> Essential Business <strong>Server</strong> stellen ein Remotezugriffportal zur<br />
Verfügung, das sicheren Zugriff über eine SSL-Verbindung ermöglicht. <strong>Die</strong> <strong>Server</strong><br />
können zwar mit selbstausgestellten Zertifikaten bereitgestellt werden, aber Sie sollten<br />
ein externes Zertifikat von einer anerkannten Zertifizierungsstelle kaufen und es<br />
installieren. Einen detaillierten Leitfaden mit Schritt-für-Schritt-Anleitungen zu dieser<br />
Aufgabe finden Sie auf der Begleit-CD.
Empfehlungen für kleine Unternehmen 451<br />
13. Passen Sie das SChannel-Protokoll so an, dass es nur SSL3 unterstützt. PCI/DSS-Dokumente<br />
empfehlen das, und moderne Browser unterstützen diese Einstellung. Lesen<br />
Sie den entsprechenden Leitfaden im Microsoft Knowledge Base-Artikel 187498 und<br />
auf der Begleit-CD.<br />
14. Deaktivieren Sie MS-CHAPv1-Unterstützung auf dem VPN-<strong>Server</strong> und erlauben Sie<br />
stattdessen nur die sichereren Protokolle CHAP oder MS-CHAPv2. Weitere Informationen<br />
zu den Einzelheiten finden Sie auf der Begleit-CD.<br />
Auf der CD Auf der Begleit-CD zu diesem Buch finden Sie Informationen, die bestimmte Optimierungen<br />
für die <strong>Server</strong> in kleinen Unternehmen beschreiben, darunter:<br />
Installieren eines Zertifikats auf IIS7, um Remotezugriff auf Remote Web Workplace mit einem öffentlichen<br />
Zertifikat zu ermöglichen<br />
Deaktivieren von SSLv2, um die PCI/DSS-Standards zu erfüllen<br />
Anpassen von VPN, sodass es sicherere Protokolle unterstützt<br />
Ändern des Remotedesktops, sodass er Authentifizierung auf Netzwerkebene unterstützt<br />
Empfohlene Firewalleinstellungen<br />
Tipps zu WMI-Abfragen<br />
Ändern von Einstellungen<br />
Bevor Sie durchgreifende Änderungen an einem <strong>Server</strong> vornehmen, sollte Sie genau wissen,<br />
welche Einstellungen Microsoft vorgenommen hat und warum. Ein Multi-Rollen-<strong>Server</strong> hat<br />
üblicherweise spezielle Einstellungen und sogar spezielle Hotfixes, um sicherzustellen, dass<br />
alle Rollen, die ursprünglich auf separaten <strong>Server</strong>n laufen sollten, auf einem einzigen <strong>Server</strong><br />
kombiniert werden können.<br />
Abbildung 16.11 Eine standardmäßig vorkonfigurierte<br />
<strong>Server</strong>richtlinie für anonyme SIDs<br />
Abbildung 16.11 zeigt ein klassisches Beispiel einer Standardeinstellung, die Microsoft in<br />
<strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> konfiguriert, um sicherzustellen, dass der <strong>Server</strong> richtig<br />
funktioniert. <strong>Die</strong> Richtlinie Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen<br />
ist in einem normalen <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> nicht aktiviert, aber auf einem Multi-Rollen-<br />
Domänencontroller wird sie benötigt. Manchmal sind Sie sich nicht sicher, ob eine Einstellung<br />
auf dem System die Standardeinstellung ist oder Sie etwas geändert haben, ohne es in<br />
Ihrer Änderungsverwaltung zu dokumentieren. In solchen Fällen können Sie die Standard-
452 Kapitel 16: Aspekte für kleine Unternehmen<br />
werte herausfinden, indem Sie eine virtualisierte Testumgebung einrichten, die eine Standardinstallation<br />
Ihrer <strong>Server</strong>version enthält.<br />
Sie können sogar in Erwägung ziehen, das Tool <strong>Windows</strong> System State Analyzer zu verwenden<br />
(siehe http://microsoft.mrmpslc.com/InnovateOn<strong>Windows</strong><strong>Server</strong>/redirect.aspx<br />
?d=Download/<strong>Windows</strong>SystemStateAnalyzer_x86.msi), bevor und nachdem Sie die Software<br />
installieren. So können Sie untersuchen, welche Änderungen die Anwendungen<br />
eines Herstellers am <strong>Server</strong> vornehmen.<br />
Richtlinien<br />
<strong>Die</strong> wichtigste Maßnahme zur <strong>Sicherheit</strong>shärtung in einem kleinen Netzwerk besteht darin,<br />
Richtlinien zu konfigurieren. Von Kennwortrichtlinien bis zu den Richtlinien über den Umgang<br />
mit vertraulichen Daten in einer Organisation sind Richtlinien ein zentrales Element<br />
für ein sicheres Netzwerk in einer kleinen Organisation.<br />
Kennwortrichtlinien<br />
Kennwörter sind Pflicht. In einem sicheren Netzwerk sind keine Ausnahmen davon zulässig.<br />
Erklären Sie der Organisation, warum »Kennwort« kein gutes Kennwort ist und dass es<br />
zwar lästig sein mag, STRG+ALT+ENTF drücken zu müssen, dies aber nötig ist, um sicherzustellen,<br />
dass sich tatsächlich der angegebene Benutzer im Netzwerk anmeldet. Erklären<br />
Sie, dass keine Zentralliste aller Kennwörter gebraucht wird <strong>–</strong> das bedeutet sogar eine ernste<br />
Verletzung des Datenschutzes. Es kann vorkommen, dass ein Angestellter nicht vor Ort ist,<br />
um die Remoteunterstützung zu autorisieren, bei der sein Profil auf seiner Arbeitsstation bearbeitet<br />
werden soll. Wenn diese Arbeit nun unbedingt über Remotedesktop erledigt werden<br />
muss, können Sie das Kennwort auf ein temporäres Kennwort zurücksetzen und sicherstellen,<br />
dass der Benutzer gezwungen wird, das Kennwort bei der nächsten Anmeldung zu ändern.<br />
In kleinen Organisationen haben Sie keinen Einfluss darauf, ob die Benutzer zumindest die<br />
wichtigsten Grundlagen kennen. Sie dürfen auch niemals davon ausgehen, dass dies der Fall<br />
ist. Daher kann es sinnvoll sein, einen Einführungskurs zum Thema <strong>Sicherheit</strong> vorzuschreiben,<br />
verbunden mit der Verpflichtung, seine Kenntnisse einmal jährlich aufzufrischen.<br />
Verfahrensempfehlungen für <strong>Sicherheit</strong>srichtlinien<br />
Implementieren Sie niemals Kennwortrichtlinien, ohne dass eine entsprechende Organisationssicherheitsrichtlinie<br />
vorliegt. Eine Richtlinie definiert die Position des Unternehmens<br />
im Bezug auf das Risikomanagement. Sie stellt ein Framework zur Verfügung und<br />
gibt dem IT-Personal Leitfäden an die Hand, die den Verlust ihres Arbeitsplatzes verhindern<br />
können. Ein Element dieser Richtlinie ist eine Richtlinie zum Umgang mit Daten,<br />
die definiert, auf welche Weise die geschäftlichen Aktiva der Organisation benutzt werden<br />
dürfen. Eine Beschreibung, wie solche Richtlinien formuliert werden, würde den<br />
Rahmen dieses Buchs sprengen. Weitere Informationen finden Sie beim SANS-<strong>Sicherheit</strong>srichtlinienprojekt<br />
unter http://www.sans.org/resources/policies/ und im Buch Information<br />
Security Policies Made Easy von Charles Cresson Wood (Information Shield,<br />
2005).
Empfehlungen für kleine Unternehmen 453<br />
Abgestimmte Kennwortrichtlinie<br />
<strong>Die</strong> gute Nachricht in der <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Ära ist, dass Sie Kennwortrichtlinien individuell<br />
für bestimmte Benutzergruppen festlegen können, wie in »Step-by-Step Guide for<br />
Fine-Grained Password and Account Lockout Policy Configuration« unter http://technet2.<br />
microsoft.com/windowsserver<strong>2008</strong>/en/library/2199dcf7-68fd-4315-87cc-ade35f8978ea1033.<br />
mspx?mfr=true dokumentiert. Kapitel 2, »Authentifizierung und Authentifizierungsprotokolle«,<br />
beschreibt diesen Vorgang im Detail. Lassen Sie sich übrigens nicht abschrecken, es<br />
gibt Fremdherstellertools mit grafischer Benutzeroberfläche, die diese Konfiguration ganz<br />
einfach machen. Abbildung 16.12 zeigt ein solches Tool von SpecCops (siehe http://technet2.<br />
microsoft.com/windowsserver<strong>2008</strong>/en/library/2199dcf7-68fd-4315-87cc-ade35f8978ea1033.<br />
mspx?mfr=true).<br />
Abbildung 16.12 Konfigurieren von abgestimmten Kennwortrichtlinien<br />
<strong>Die</strong> Standardrichtlinie in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> schreibt vor, dass Kennwörter alle 42 Tage<br />
geändert werden müssen. Sehen Sie sich die Geschäftsabläufe der Organisation genau an<br />
und drängen Sie darauf, die Länge der Kennwörter zu erhöhen. Auf diese Weise sind die<br />
Passphrasen besser und stärker, sodass sie nicht mehr so oft geändert werden müssen.<br />
42 Tage ist ein Zeitraum, mit dem Sie sich nicht gerade beliebt machen. Eine schnelle<br />
Änderung an der Kennwortrichtlinie stellt sicher, dass Kennwörter bereitwilliger benutzt<br />
werden (Abbildung 16.13).
454 Kapitel 16: Aspekte für kleine Unternehmen<br />
Abbildung 16.13 Kennwortrichtlinien auf dem Domänencontroller<br />
Wenn Sie einen neuen <strong>Server</strong> in einer kleinen Organisation einrichten, sollten Sie diese Gelegenheit<br />
nutzen, um Benutzer darüber aufzuklären, wie wichtig es ist, sichere Kennwörter<br />
oder Passphrasen zu wählen und auf geeignete Weise zu schützen.<br />
Administratorkonten<br />
Das Konto Administrator ist zweifellos das mächtigste Element in jedem <strong>Server</strong>. Daher ist<br />
es von entscheidender Bedeutung, das Kennwort dieses Kontos zu schützen. Sie müssen<br />
eine Richtlinie festlegen, die seine Benutzung regelt. Und weil Consultants wechseln und<br />
Hersteller Zugriff bekommen, sollte das integrierte Konto Administrator in einer kleinen<br />
Organisation genauso benutzt werden wie bei großen Bereitstellungen: praktisch nie, sodass<br />
man meinen könnte, es hätte die Beulenpest. Legen Sie ein besonders starkes Kennwort fest,<br />
deaktivieren Sie das Konto und benutzen Sie nur ein anderes Administratorkonto, wenn Sie<br />
den Computer im Remotezugriff verwalten. <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> nimmt<br />
genau diese Konfiguration in der Standardeinstellung vor. Noch besser ist, wenn Sie eine<br />
Zwei-Faktoren-Authentifizierung für alle Konten mit administrativem Zugriff auf <strong>Server</strong><br />
implementieren. Sehen Sie sich Technologien wie zum Beispiel RSA Secure ID und die<br />
Tokenschlüsseltechnologie AuthAnvil von Scorpion Software an, wenn Sie zusätzlichen<br />
Schutz brauchen. Jede Person, die Privilegien eines Domänenadministrators braucht, sollte<br />
ihr eigenes Administratorkonto haben, damit sichergestellt ist, dass alle Zugriffe nachverfolgt<br />
werden können.<br />
Verfahrensempfehlungen für Hersteller<br />
In einer kleinen Organisation wird für die IT-Beschaffung normalerweise ein externer Hersteller<br />
ausgewählt. Der Rückgriff auf solche Hersteller birgt potenziell neue Gefahren für ein<br />
Netzwerk, die bewertet werden müssen.<br />
Administratorzugriff durch Hersteller<br />
Geben Sie einem externen Hersteller niemals Zugriff auf ein vorhandenes Administratorkonto.<br />
Richten Sie stattdessen immer ein separates Konto für genau diesen Zweck ein, wenn der<br />
Hersteller Remotezugriff benötigt. Und falls ein Hersteller von Geräten wie Drucker oder<br />
Scanner darum bittet, ihm eine Liste aller Benutzernamen, Kennwörter und IP-Adressen im<br />
Netzwerk zu faxen, damit seine Netzwerktechniker das Gerät schon fertig einrichten können,<br />
sollten Sie sich freundlich für einen so tollen Service bedanken und ein Angebot bei<br />
einem anderen Hersteller anfordern.
Empfehlungen für kleine Unternehmen 455<br />
Remotezugriff durch Hersteller<br />
Falls Sie Unternehmen beliefern und Consultingdienste zur Verfügung stellen, müssen Sie<br />
genau darauf achten, dass die Systeme, die Sie für den Remotezugriff auf Ihre Clients einsetzen,<br />
geschützt sind und ihre <strong>Sicherheit</strong> auch für die Zukunft gewährleistet bleibt. Alle<br />
Anmeldeinformationen, die Sie auf einem kompromittierten Computer eintippen, sind kompromittiert.<br />
Notebooks und WLAN-Karten sind günstig zu haben und bieten die Fähigkeit,<br />
sichere Remoteverbindungen aufzubauen.<br />
Tipp Verfahrensempfehlung für Remotezugriff<br />
Richten Sie die Firewall so ein, dass Terminalserverzugriffe nur von bestimmten statischen IP-Adressen im<br />
Netzwerk des Remoteconsultants oder Herstellers angenommen werden.<br />
Outsourcing<br />
Falls Sie denken, dass kleine Organisationen nicht von Outsourcing betroffen sind, weil sie<br />
nur IT-Support von lokalen Administratoren oder lokalen Consultants bekommen, liegen Sie<br />
falsch. Externe Consultants, die standardisierte <strong>Die</strong>nstleistungen anbieten, greifen immer<br />
mehr auf outgesourcte Anbieter zurück. Manche Branchen (zum Beispiel einige Buchprüfer)<br />
fordern, dass Sie die Klienten der Organisation informieren, wenn outgesourcte Organisationen<br />
auf ihre vertraulichen Daten zugreifen. Wägen Sie die Risiken entsprechend ab.<br />
Wichtig Verantwortung können Sie nicht outsourcen<br />
»Letztlich gilt: Auch wenn eine Organisation einige ihrer Geschäftsprozesses und damit Teile ihrer Haftung<br />
für den Datenschutz outsourcen kann, ist es nicht möglich, die Verantwortung für Datenschutz outzusourcen«.<br />
(Marilyn Prosch, Outsourcing and Private: 10 Critical Questions Top Management Should Ask)<br />
Trennen von Aufgabenbereichen<br />
In einer kleinen Organisation ist es nicht ganz so wichtig wie in großen Organisationen, die<br />
administrativen Pflichten zwischen Exchange, <strong>Windows</strong>-Firewall und Live Communication<br />
<strong>Server</strong> (oder Unified Communication <strong>Server</strong>) aufzuteilen. Meist gibt es ohnehin nur einen<br />
IT-Administrator. Es wird trotzdem empfohlen, mehrere Konten mit möglichst geringen<br />
Privilegien zu verwenden, aber das ist im Allgemeinen recht schwierig zu implementieren,<br />
sodass es den Aufwand nicht rechtfertigt.<br />
Änderungen an Ihrem Netzwerk auf Anforderung eines Herstellers<br />
Falls ein Hersteller empfiehlt, dass Sie die <strong>Windows</strong> XP- oder <strong>Windows</strong> Vista-Firewall innerhalb<br />
des Netzwerks deaktivieren, weil die externe Firewall angeblich ausreichend Schutz<br />
für eine kleine Organisation bietet, sollten Sie freundlich fordern, dass er dokumentiert, welche<br />
Ausnahmen in der Firewall konfiguriert werden müssen, damit die Software einwandfrei<br />
funktioniert. Auch manche Hersteller von Antivirensoftware brauchen Programm- und Portausnahmen.<br />
Vergessen Sie nie, dass Anwendungssoftware in einem Netzwerk einwandfrei<br />
funktionieren kann, wenn die richtigen Ausnahmen konfiguriert sind. Wenn ein Hersteller<br />
etwas fordert, das Sie für nicht vertretbar halten, sollten Sie Ihre Möglichkeiten mit dem<br />
Unternehmensinhaber besprechen. Ich selbst habe schon bei Telefonaten mit dem Support<br />
von LOB-Anwendungen nach dem Geschäftführer verlangt, wenn die Forderungen hanebüchen<br />
und aus <strong>Sicherheit</strong>sgründen nicht zu verantworten waren. Eine standardisierte Änderungsverwaltung<br />
wird umso wichtiger, je mehr Hersteller unterschiedliche <strong>Die</strong>nste zur Verfügung<br />
stellen.
456 Kapitel 16: Aspekte für kleine Unternehmen<br />
Remotezugriff<br />
Eine kleine Firma muss entscheiden, ob Remotezugriff so wichtig ist, dass die dadurch verursachte<br />
Gefahr in Kauf genommen werden muss. Welche Probleme müssen bedacht werden?<br />
Und wie können Sie trotzdem bestmögliche <strong>Sicherheit</strong> erreichen?<br />
Remotekonnektivität und <strong>Sicherheit</strong>sfragen<br />
<strong>Die</strong> größte Gefahr für das Netzwerk eines kleinen Unternehmens besteht darin, dass die<br />
Benutzer dieses Netzwerks nicht die Kompetenz besitzen, die richtigen Entscheidungen zu<br />
treffen. Falls Sie drakonische Richtlinien festlegen, diese Richtlinien aber verhindern, dass<br />
die Arbeit erledigt werden kann, helfen Ihnen die besten Argumente nichts. Das betrifft auch<br />
Richtlinien bezüglich des Remotezugriffs. In einer kleinen Organisation, bei der einige Angestellte<br />
unverzichtbar sind, müssen Sie sicherstellen, dass es den Benutzern möglich ist,<br />
ihren Computer aus der Firma mitzunehmen. Der Zugriff von draußen soll für die Benutzer<br />
mit möglichst wenig Aufwand möglich sein, aber trotzdem müssen Richtlinien und Zugriffseinschränkungen<br />
definiert sein. Nur so kann sichergestellt werden, dass die Angestellten<br />
der Versuchung widerstehen, öffentlich zugängliche Computer wie etwa Kioskcomputer zu<br />
benutzen.<br />
Gefahren von Kioskcomputern<br />
Als im Jahr 2003 <strong>Windows</strong> Small Business <strong>Server</strong> 2003 mit dem Remotezugriffportal<br />
namens Remote Web Workplace erschien, tönten die Marketingbroschüren, dass man mit<br />
»beliebigen« Computern auf das Netzwerk zugreifen könne. Sie versäumten es darauf<br />
hinzuweisen, dass nur einige Monate vorher ein ganz ähnlicher Zugriff über »beliebige<br />
Computer« damit endete, dass Kennwörter, Kontonummern und Kreditkartennummern<br />
gestohlen wurden, weil auf Kioskcomputern der Kette Kinko’s Keylogger installiert waren<br />
(Robert Vamosi, http://reviews.cnet.com/4520-3513 7-5053016-1.html). <strong>Die</strong> Verwendung<br />
einer Zwei-Komponenten-Authentifizierung, zum Beispiel RSA Secure ID und<br />
AuthAnvil von Scorpion Software, kann dieses Risiko eindämmen, aber je vertraulicher<br />
die Daten innerhalb der Organisation sind, desto strenger muss die Richtlinie sein. RAS-<br />
Richtlinien sollten ganz deutlich definieren, von welchen Computern aus ein Remotezugriff<br />
auf ein Netzwerk erlaubt ist. Benutzen Sie niemals einen Computer, der nicht Ihnen<br />
selbst gehört oder von dessen Systemintegrität Sie nicht absolut überzeugt sind, wenn Sie<br />
im Remotezugriff mit Netzwerkressourcen arbeiten. Punkt.<br />
Mobilgeräte verringern das Risiko<br />
Smartphones sind ein hervorragendes und sicheres Mittel, wichtigen Angestellten eine Remoteverbindung<br />
zu ermöglichen, ohne unnötige Gefahren durch Remotezugriff auf die <strong>Server</strong>umgebung<br />
eingehen zu müssen. Es ist für eine Organisation sicherer, Technologien wie<br />
Outlook über https (jetzt als Outlook Anywhere bezeichnet) bereitzustellen, als Outlook über<br />
eine VPN-Verbindung zu benutzen. Nur zu oft nehmen wir uns in einer kleinen Organisation<br />
nicht die Zeit, VPN-Verbindungen so anzupassen, dass die Verbindung eingeschränkt wird.<br />
So passiert es, dass die Arbeitsstationen eine uneingeschränkte Verbindung auf die Netzwerkschicht<br />
(Schicht 3) zurück zum <strong>Server</strong> aufbauen. Welche Remotetechnologie gewählt<br />
wird, ist von entscheidender Bedeutung dabei, ob für kleine Organisationen sicherer und
Empfehlungen für kleine Unternehmen 457<br />
kostengünstiger Remotezugriff ermöglicht wird. Technologien wie Remote Web Workplace,<br />
die sicherere Protokolle einsetzen und lediglich Bildschirminhalte übertragen, stellen sicher,<br />
dass das Netzwerk insgesamt sicherer wird. Mit Remote Web Workplace und jetzt in <strong>Windows</strong><br />
<strong>Server</strong> <strong>2008</strong> können Terminalservergateway-Verbindungen von vertrauenswürdigen<br />
Systemen aus hergestellt werden, was sicheren und einfach administrierbaren Zugriff ermöglicht.<br />
Kontosperrung<br />
In großen Unternehmen kann die Praxis, ein Konto zu sperren, wenn ein Benutzer mehrmals<br />
das falsche Kennwort eingegeben hat, eine Menge Aufwand beim Helpdesk verursachen. In<br />
solchen Unternehmen ist diese Richtlinie daher möglicherweise nicht besonders effektiv. Bei<br />
kleinen Unternehmen kann eine Kontosperrungsrichtlinie dagegen so viel <strong>Sicherheit</strong>sgewinn<br />
bringen, dass es die Nachteile aufwiegt. Normalerweise wird eine Kontosperrung in einer<br />
kleinen Organisation nicht durch einen Angriff verursacht, sondern dadurch, dass ein Kennwort<br />
irgendwo gespeichert und automatisch eingetragen wird. Aber wenn Konten gesperrt<br />
werden, kann Sie das auf einen falsch konfigurierten Router oder möglicherweise einen Ex-<br />
Angestellten aufmerksam machen, der versucht, in die Organisation einzubrechen. Kontosperrung<br />
kann auch den Unternehmensinhaber überzeugen, dass das System Portscanangriffe<br />
abwehren kann. Das passiert manchmal in kleinen Netzwerken: Falls Sie einen Port haben,<br />
der gegenüber dem Internet offen bleiben muss, wird er von normalen Portscans getroffen.<br />
In der Praxis sollten Kennwörter stark genug sein, um solchen wahllosen Angriffen zu widerstehen,<br />
aber so mancher Unternehmensinhaber schläft besser, wenn er weiß, dass die<br />
Angreifer bei ihren automatisierten Scans nur wenige Versuche haben. Auch wenn die Verwendung<br />
besserer Kennwörter die beste Eindämmung ist, wollen viele Unternehmensinhaber<br />
diese Portscanner ausfindig machen und zur Strecke bringen. Wenn Sie in diesem Fall<br />
erklären, dass es wahrscheinlich der Computer seiner eigenen Großmutter ist, der in einen<br />
Zombiecomputer verwandelt wurde, kommt das beim Kunden gewöhnlich nicht besonders<br />
gut an. Daher können Sie diese Einstellung unter der Kategorie »Trost und Beruhigung«<br />
einordnen. Sie hilft vor allem der Gemütsruhe des Unternehmensinhabers.<br />
Überwachungs- und Verwaltungs-Add-Ons<br />
In einem kleinen Netzwerk sind die wichtigsten Tools eines Consultants diejenigen, die er<br />
selbst bereitstellt, um <strong>Server</strong> zu überwachen. In der Branche wird diese Kombination von<br />
Remoteüberwachung als »Managed Services« bezeichnet. Das Ziel besteht darin, dass der<br />
Consultant sofort alarmiert wird, falls ein <strong>Server</strong> seine Aufmerksamkeit benötigt. Wenn Sie<br />
schon Netzwerke in Großunternehmen verwaltet haben, war WMI (<strong>Windows</strong> Management<br />
Instrumentation) vermutlich unverzichtbar für diese Aufgabe. Sie brauchen damit nur eine<br />
kleine Abfrage zusammenzustellen, um zu ermitteln, was in einem Netzwerk vor sich geht.<br />
Weil viele Administratoren in kleinen Unternehmen (auch ich selbst) die Skriptentwicklung<br />
für recht schwierig halten, hat Microsoft zuerst MOM (Microsoft Operations Management)<br />
veröffentlicht, um ein GUI-Tool für die Verwaltung eines Netzwerks zur Verfügung zu stellen.<br />
SCE und SCE Managed Services<br />
Microsoft hat System Center Essentials (SCE) und System Center Remote Operations Manager<br />
2007 veröffentlicht. <strong>Die</strong>se beiden Tools helfen bei der Verwaltung kleinerer Bereitstellungen.<br />
Wenn Sie als Consultant arbeiten, können Sie SCE auf einem System installieren
458 Kapitel 16: Aspekte für kleine Unternehmen<br />
und dann mit System Center Remote Operations Manager 2007 die Berichte über alle <strong>Server</strong><br />
unter Ihrer Kontrolle abrufen. Je nachdem, wie Sie Ihr <strong>Die</strong>nstleistungsangebot strukturieren,<br />
haben Sie die Möglichkeit, lediglich Überwachung anzubieten, oder Sie können Ihren Kunden<br />
ein SLA (Service Level Agreement) verkaufen, bei dem Sie eine bestimmte Uptime der<br />
<strong>Server</strong>, Arbeitsstationen und so weiter garantieren. Stattdessen können Sie diese Tools auch<br />
nur bei Bedarf einsetzen, wenn Sie Kunden haben, die sich nur an Sie wenden, wenn ein<br />
akutes Problem beseitigt werden muss. Ein Administrator kann sich anderen Aufgaben<br />
widmen, wenn ein schneller Blick auf das SCE-Dashboard (Abbildung 16.14) zeigt, dass<br />
alles einwandfrei funktioniert.<br />
Abbildung 16.14 Überwachen von Netzwerkdiensten mit SCE<br />
Fremdherstellerlösungen für Managed Services<br />
Der Markt für Managed Services scheint sich täglich zu verändern. Was gestern noch als<br />
Verfahrensempfehlung angepriesen wurde, ist morgen schon veraltet. Sie können viele<br />
Remoteaufgaben in diesem Bereich zwar mit simplen Skripts von den Microsoft Scripting<br />
Guys erledigen, oft ist es aber sinnvoller, wenn Sie sicherstellen, dass Sie ein Framework<br />
haben, das einfach gewartet und reproduzierbar verwaltet werden kann und das vor allem<br />
ein Berichterstellungstool enthält. Mit solchen Berichten können Sie sicherstellen, dass Ihre<br />
Kunden verstehen, welche Aufgaben Sie erfüllen. Wenn Sie beim Netzwerksupport so gut<br />
sind, dass es absolut problemlos läuft, glaubt Ihr Chef oder Kunde vielleicht gar nicht, dass<br />
Sie eine Menge Aufwand betreiben mussten. Händigen Sie Kunden zumindest jedes Quartal<br />
einen Bericht aus, der so biedere <strong>Sicherheit</strong>selemente wie die Zahl der erkannten Spam-<br />
Mails auflistet, die Menge der auf dem Gateway blockierten Viren, die Vorfälle, bei denen<br />
Benutzer gehindert wurden, den »Nackte-tanzende-Schweine-Bildschirmschoner 2.0« aus<br />
dem Web herunterzuladen, und so weiter. Ganz egal, welches Tool Sie für die Remoteüberwachung<br />
der <strong>Server</strong> einsetzen, sollten Sie sicherstellen, dass Sie dem Unternehmensinhaber<br />
eine Übersicht darüber geben, welche Schritte Sie unternommen haben, damit sein Netzwerk<br />
einwandfrei funktioniert. Nutzen Sie diese Zeit mit dem Kunden auch als Möglichkeit, ihn<br />
über die Konsequenzen gefährlicher Verhaltensweisen aufzuklären. Weitere Informationen<br />
über Managed Services als <strong>Die</strong>nstleistung finden Sie unter http://tech.groups.yahoo.com/<br />
group/SMBManagedServices/.<br />
Remoteverwaltung<br />
Wenn Sie ein Remoteverwaltungsprogramm verwenden, muss Ihnen bewusst sein, dass ein<br />
solches Tool möglicherweise Auswirkungen auf die <strong>Sicherheit</strong> Ihres Netzwerks hat. Bei<br />
<strong>Windows</strong> Vista ist in der Standardeinstellung der Remoteregistrierungsdienst nicht aktiviert,<br />
aber manche Verwaltungslösungen können nur dann Ereignisprotokolle im Remotezugriff<br />
anzeigen und andere Verwaltungsaufgaben für Remotebenutzer ausführen, wenn dieser<br />
<strong>Die</strong>nst läuft. Wenn Sie den Remoteregistrierungsdienst aktivieren, verändern Sie damit die
Empfehlungen für kleine Unternehmen 459<br />
<strong>Sicherheit</strong>saufstellung Ihres Netzwerks. Ziehen Sie einen Leitfaden wie zum Beispiel das<br />
Microsoft Threats and Countermeasures Guide zurate, wenn Hersteller empfehlen, Standarddienste<br />
und -registrierungseinstellungen zu verändern. Sie finden dieses Dokument<br />
unter http://www.microsoft.com/technet/security/guidance/serversecurity/tcg/tcgch00.mspx.<br />
<strong>Die</strong> Rolle des <strong>Server</strong>s bei der Kontrolle und Verwaltung<br />
der Arbeitsstationen<br />
<strong>Die</strong> beste Methode, einen <strong>Server</strong> in einem kleinen Unternehmen zu schützen, besteht darin,<br />
die Arbeitsstationen stets unter Kontrolle zu halten. Einer der wichtigsten Schritte auf dem<br />
Weg zu diesem Ziel ist, Endbenutzern keine administrativen Privilegien auf ihren Arbeitsstationen<br />
zu gewähren.<br />
Weitere Informationen Falls Sie noch kein Buch zur <strong>Windows</strong> Vista-<strong>Sicherheit</strong> gekauft haben, empfehle<br />
ich Microsoft <strong>Windows</strong> Vista <strong>–</strong> <strong>Die</strong> <strong>technische</strong> <strong>Referenz</strong> (Microsoft Press, 2007) und <strong>Windows</strong> Vista Security:<br />
Securing Vista against Malicious Attacks von Roger Grimes und Jesper Johansson (Wiley, 2007) als<br />
hervorragende Mittel, um mehr über <strong>Windows</strong> Vista-<strong>Sicherheit</strong> zu lernen.<br />
Kapitel 14 führt an, dass beim Entwurf des Netzwerks kein Aufbau gewählt werden sollte,<br />
der erfordert, dass bei den Arbeitsstationen eine Datensicherung durchgeführt wird. Sogar in<br />
einer kleinen Organisation sollten Sie versuchen, einen Verwaltungsprozess zu entwickeln,<br />
der keine angepassten Konfigurationen oder Daten auf den Arbeitsstationen speichert. <strong>Die</strong><br />
kritische LOB-Anwendung einer Organisation sollte auf dem <strong>Server</strong> liegen, wo sie besser<br />
geschützt ist und ihre Daten besser gesichert werden können. Sie sollte nie auf einer Arbeitsstation<br />
installiert sein. Prüfen Sie bei solchen Anwendungen, ob organisationsweite Verschlüsselungs-<br />
oder andere <strong>Sicherheit</strong>slösungen bereitgestellt werden müssen, wenn sie auf<br />
Arbeitsstationen installiert werden. Falls der <strong>Server</strong> an einem Ort steht, wo keine ausreichende<br />
physische <strong>Sicherheit</strong> gewährleistet werden kann, ist es unter Umständen sinnvoll,<br />
BitLocker darauf bereitzustellen.<br />
Empfohlene Gruppenrichtlinieneinstellungen für kleine Unternehmen<br />
Bevor Sie diesen Abschnitt beginnen, sollten Sie Kapitel 7, »Gruppenrichtlinien«, bereits<br />
gelesen haben. Außerdem sollten Sie als <strong>Referenz</strong> ein Exemplar der Tabelle mit den Gruppenrichtlinieneinstellungen<br />
zur Hand haben. Sie können diese Tabelle von http://download.<br />
microsoft.com/download/c/3/8/c3815ed7-aee7-4435-802b-8e855d549154/GroupPolicy<br />
Settingsfor<strong>Windows</strong>Vista.xls herunterladen.<br />
Es gibt viele neue Einstellungen, die Auswirkungen auf die <strong>Sicherheit</strong> haben und in einer<br />
kleinen Organisation nützlich sein können. Sie möchten in der Lage sein, jeden USB-Anschluss<br />
im Netzwerk zu kontrollieren? Dafür brauchen Sie <strong>Windows</strong> Vista. Sie wollen die<br />
Kennwortspeicherung und Authentifizierungsprotokolle innerhalb des Netzwerks verbessern?<br />
Dann können Sie <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, <strong>Windows</strong> <strong>Server</strong> 2003 und <strong>Windows</strong> XP-<br />
oder <strong>Windows</strong> Vista-Arbeitsstationen verwenden. Sie wissen nicht, wozu das gut sein soll?<br />
Lesen Sie Kapitel 2, dann verstehen Sie, warum Abbildung 16.15 eine der besten Einstellungen<br />
zeigt, die Sie in einem kleinen Netzwerk konfigurieren sollten. (Ein Hinweis: Sie<br />
bedeutet, dass Sie endlich alle übrig gebliebenen <strong>Windows</strong> 98-Computer aussperren, die<br />
sich möglicherweise noch im Netzwerk herumtreiben.)
460 Kapitel 16: Aspekte für kleine Unternehmen<br />
Abbildung 16.15 Keine LAN Manager-Hashwerte zu speichern,<br />
kann eine der besten Einstellungen für ein kleines Netzwerk sein;<br />
lassen Sie diese Richtlinie aktiviert<br />
Wichtig Empfehlungen für Gruppenrichtlinien<br />
Wenn Sie eine Richtlinie festlegen wollen (das gilt für jede Gruppenrichtlinie auf allen <strong>Server</strong>n), wird empfohlen,<br />
dass Sie ein neues Gruppenrichtlinienobjekt erstellen, um genau zu wissen, welche konkreten<br />
Einstellungen Sie vornehmen. Wenn Sie die Konsole Gruppenrichtlinien öffnen, wissen Sie genau, welche<br />
Richtlinien Sie zu diesem Netzwerk hinzugefügt haben. Das ist eine einfache Methode, um zu verfolgen,<br />
welche Richtlinien Sie erstellt haben und welche Richtlinien in der Standardinstallation der verschiedenen<br />
kleinen bis mittleren <strong>Server</strong>bereitstellungen vorkonfiguriert waren.<br />
<strong>Die</strong> folgenden Abschnitte stellen einige wichtige Gruppenrichtlinieneinstellungen für ein<br />
kleines Netzwerk vor.<br />
Interaktive Anmeldung: Nachricht für Benutzer, die sich anmelden wollen<br />
Eine der wohl am häufigsten übersehene Gruppenrichtlinieneinstellung für kleine Organisationen<br />
hat trotzdem gewaltige Auswirkung auf die Benutzerfreundlichkeit. In einer kleinen<br />
Organisation herrscht meist eine Atmosphäre von Kameradschaft und Teamwork. Daher<br />
wird dieses Konzept meist übersehen: Der Organisationsadministrator hat das Recht und die<br />
Autorität, alle Zugriffe, alle E-Mails, alle Websites, alle Dokumente, alle Downloads zu<br />
prüfen <strong>–</strong> praktisch alles auf dem Computer eines Mitarbeiters, weil Hardware und Software<br />
dem Unternehmen gehören. Wenn die Angestellten gelegentlich in Form einer Richtlinie<br />
daran erinnert werden, dass alle ihre Aktionen überwacht und ausgewertet werden könnten,<br />
ist das ein wirksames psychologisches Werkzeug, um zu verhindern, dass Angestellte das<br />
Netzwerk für unlautere Zwecke missbrauchen. Falls es nicht reicht, darauf schriftlich hinzuweisen,<br />
können Sie die Benutzer freundlich daran erinnern, wenn sie sich morgens an<br />
ihrem System anmelden. Dazu dient die Einstellung Interaktive Anmeldung: Nachricht für<br />
Benutzer, die sich anmelden wollen. Vergessen Sie nie die psychologischen Faktoren, wenn<br />
Sie ein Netzwerk schützen.<br />
Wichtig Andere Länder, andere Sitten<br />
Bitte beachten Sie, dass im vorstehenden Absatz Empfehlungen für die USA ausgesprochen werden.<br />
In Deutschland würden Sie sich mit einer solchen Überwachung strafbar machen.
Empfehlungen für kleine Unternehmen 461<br />
Gruppenrichtlinieneinstellungen für die <strong>Windows</strong> XP-<br />
und <strong>Windows</strong> Vista-Firewall<br />
Wenn Sie die <strong>Windows</strong> XP- und <strong>Windows</strong> Vista-Firewalleinstellungen innerhalb einer Organisation<br />
bereitstellen, müssen Sie daran denken, dass Ihre externe Firewall Sie nur vor<br />
Zugriffen schützen kann, die von außerhalb des Unternehmens kommen. Sie nützt Ihnen gar<br />
nichts, falls irgendeine grässliche Malware es schafft, in das Netzwerk zu gelangen. Ich weiß,<br />
dass die Angriffe in letzter Zeit weniger verheerend waren, aber ständig lauert irgendetwas<br />
oder irgendjemand auf die Gelegenheit, Ihr Netzwerk in eine Zombie-Armee zu verwandeln.<br />
Interne Firewalls können ihren Teil dazu beitragen, die Integrität des Netzwerks zu schützen.<br />
Weitere Informationen darüber, warum interne Firewalls so wichtig sind, finden Sie in<br />
Kapitel 14.<br />
Abbildung 16.16 Der <strong>Server</strong> definiert Gruppenrichtlinieneinstellungen für die<br />
<strong>Windows</strong> Firewall mit erweiterter <strong>Sicherheit</strong> in <strong>Windows</strong> Vista<br />
<strong>Die</strong> typischen <strong>Windows</strong> Vista-Firewalleinstellungen im Netzwerk von kleinen Unternehmen<br />
brauchen nur vier Einstellungskategorien: Kernnetzwerk, Datei- und Druckerfreigabe,<br />
Remoteunterstützung und Remotedesktop. In vielen Fällen können Sie diese Kategorien noch<br />
weiter einschränken, sodass die <strong>Die</strong>nste nur für bestimmte Hosts zugänglich sind. Je sorgfältiger<br />
Sie analysieren, wer Zugriff auf was braucht, desto stärker können Sie diese Firewalleinschränkungen<br />
anpassen und einschränken, was die Arbeitsstationen tun dürfen und was<br />
nicht. Das hilft Ihnen wiederum bei der Zeitplanung für Updates und der Eindämmung von<br />
<strong>Sicherheit</strong>sproblemen. Wenn diese Arbeitsstationen in das <strong>Sicherheit</strong>sgefüge des Netzwerks<br />
eingebunden sind, hilft das eine Menge. <strong>Die</strong> Einstellungen für die <strong>Windows</strong>-Firewall mit<br />
erweiterter <strong>Sicherheit</strong> finden Sie unter Computerkonfiguration/<strong>Windows</strong>-Einstellungen/<br />
<strong>Sicherheit</strong>seinstellungen/<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong>. In <strong>Windows</strong> Small
462 Kapitel 16: Aspekte für kleine Unternehmen<br />
Business <strong>Server</strong> <strong>2008</strong> wird Ihnen das schwierige Einrichten dieser Richtlinien abgenommen.<br />
Wie Sie in Abbildung 16.16 sehen, hat <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> eingehende<br />
Regeln aktiviert. Ausgehende Regeln sind vorbereitet, sodass Sie die ausgehende Filterung<br />
jederzeit aktivieren können. <strong>Die</strong> ausgehenden Regeln sind dabei so konfiguriert, dass die<br />
Kernaufgaben wie Netzwerkkommunikation, Drucken, Remoteunterstützung und Remotedesktop<br />
auf jeden Fall zur Verfügung stehen.<br />
<strong>Windows</strong> XP-Arbeitsstationen können sich ebenfalls an dieser Eindämmung und Einschränkung<br />
beteiligen. Das schlimmste, was Sie in einer kleinen Organisation tun können, wäre,<br />
die externe Firewall als »gut genug« zu betrachten und zu glauben, dass es keinen Grund<br />
gibt, die internen Firewalls zu aktivieren. Nehmen Sie sich die Zeit und lernen Sie, wie interne<br />
Firewalls die erforderlichen Einschränkungen erzwingen können.<br />
Sie finden die Einstellungen für <strong>Windows</strong> XP-Firewalls unter Computerkonfiguration/Administrative<br />
Vorlagen/Netzwerk/Netzwerkverbindungen/<strong>Windows</strong>-Firewall/Domänenprofil<br />
(Abbildung 16.17). Im Dokument »Small Business Tweaks« auf der Begleit-CD zu diesem<br />
Buch finden Sie Details zu empfohlenen Richtlinien für ein kleines Netzwerk. Weitere<br />
Informationen zur Leistungsfähigkeit von Gruppenrichtlinien finden Sie in Kapitel 7.<br />
Abbildung 16.17 <strong>Die</strong> vom <strong>Server</strong> definierten Gruppenrichtlinieneinstellungen für <strong>Windows</strong> XP-Firewalls<br />
Authentifizierung und Clients<br />
Eine der besten Möglichkeiten, ein kleines Netzwerk (eigentlich jedes Netzwerk) zu schützen,<br />
besteht darin, die Umgebung möglichst weit zu standardisieren. Das ist eine der <strong>Sicherheit</strong>smaßnahmen,<br />
die am schwierigsten umzusetzen ist, sie kann sogar fast unmöglich sein.<br />
Unter Umständen legen Sie damit ältere LOB-Anwendungen lahm. Trotzdem ist es ein erstrebenswertes<br />
Ziel, jede Arbeitsstation auf derselben Plattform (normalerweise das neueste<br />
Desktopbetriebssystem, das der Hersteller anbietet) und mit demselben Service Pack zu<br />
betreiben und sicherzustellen, dass auch jede Anwendung aktualisiert wird und ihr Code<br />
einer <strong>Sicherheit</strong>sbegutachtung unterzogen wurde, die dieselbe Qualität gewährleistet wie der<br />
<strong>Windows</strong> Secure Development Lifecycle. Falls Sie das Glück haben, dieses Ziel zu erreichen,<br />
können Sie zusätzliche Einstellungen vornehmen. Zum Beispiel können Sie sicherstellen,<br />
dass alle Terminaldienst- und Remotedesktopsitzungen mit Authentifizierung auf Netzwerkebene<br />
arbeiten und die höchsten Authentifizierungsstufen verwendet werden, zum Beispiel<br />
Nur NTLMv2-Antworten senden. LM & NTLM verweigern.
Empfehlungen für kleine Unternehmen 463<br />
Empfehlungen für weitere <strong>Server</strong>einstellungen und -konfigurationen<br />
Es wird davon abgeraten, blind irgendwelchen Leitfäden zur <strong>Sicherheit</strong>shärtung zu folgen.<br />
Aber das bedeutet nicht, dass Sie nicht einige Einstellungen auf dem <strong>Server</strong> an Ihre konkreten<br />
Anforderungen anpassen sollten. <strong>Die</strong> folgenden Abschnitte führen einige Empfehlungen<br />
für das Netzwerk eines kleinen Unternehmens auf.<br />
DsrmAdminLogonBehavior<br />
Wenn Sie eine Architektur mit einem einzigen Domänencontroller haben, können Sie einen<br />
neuen Registrierungswert in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> ändern: DsrmAdminLogonBehavior. Sie<br />
finden diesen Eintrag unter HKLM\System\currentcontrolset\Control\Lsa. Er ermöglicht<br />
Ihnen, sich am Domänencontroller anzumelden, auch wenn die Active Directory-Domänendienste<br />
nicht laufen. Auf das DSRM-Administratorkennwort, das separat eingerichtet wird,<br />
wenn Sie einen <strong>Server</strong> mit Dcpromo.exe zu einem Domänencontroller hochstufen, werden<br />
die Kennwortrichtlinien nicht angewendet. Als Eindämmung erlaubt <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
dem DSRM-Administrator daher nur eine Anmeldung, während die Active Directory-Domänendienste<br />
laufen. In einem typischen Netzwerk mit mehreren Domänencontrollern ist es<br />
kein Problem, wenn ein <strong>Server</strong> ausfällt, weil immer noch irgendein anderer Domänencontroller<br />
die Authentifizierung durchführen kann. Daher ist DSRMAdminLogonBehavior so<br />
konfiguriert, dass eine Anmeldung verhindert wird, wenn die Active Directory-<strong>Die</strong>nste nicht<br />
laufen. In einem Netzwerk mit lediglich einem Domänencontroller verhindert das natürlich,<br />
dass Sie sich am <strong>Server</strong> anmelden und ihn wiederherstellen können. Falls die Umgebung nur<br />
einen Domänencontroller enthält, wird daher diese Einstellung empfohlen.<br />
Abbildung 16.18 zeigt diese neue Registrierungseinstellung. Sie kann folgende Werte haben:<br />
0 Der DSRM-Administrator kann sich nur im DSRM anmelden, wenn die Active<br />
Directory-Domänendienste laufen. (<strong>Die</strong>s ist die Standardeinstellung.)<br />
1 Der DSRM-Administrator kann sich im DSRM anmelden und wenn die Active<br />
Directory-Domänendienste nicht laufen.<br />
2 Der DSRM-Administrator kann sich jederzeit anmelden.<br />
Abbildung 16.18 Der Registrierungsschlüssel DsrmAdminLogonBehavior<br />
<strong>Die</strong>se eine schnelle Einstellung bewirkt, dass Sie einen Domänencontroller nicht völlig neu<br />
starten müssen. Das ist sicherlich sinnvoll.<br />
Ältere Anwendungen schränken die Möglichkeiten der <strong>Server</strong>optimierung ein<br />
Bei meiner Suche nach absoluter <strong>Sicherheit</strong> machte ich ein Experiment. Ich versuchte, den<br />
gesamten Verkehr meines Dateiservers auf Port 445 zu beschränken. Ich stellte fest, dass<br />
sich meine Steuererklärungssoftware bitterlich beschwerte, weil keine Kommunikation über<br />
Port 135 bis 139 möglich war. Sie forderte, dass ich auf keinen Fall versuche, die SMB-<br />
Kommunikation auf diese Weise einzuschränken. Sie dürfen nie vergessen, dass ein Multi-<br />
Rollen-<strong>Server</strong> eben mehrere Aufgaben erfüllt. Insbesondere betrifft das LOB-Anwendungen,<br />
deren Programmcode schon vor vielen Jahren geschrieben wurde. Solche Anwendungen<br />
scheitern sehr oft an neueren <strong>Sicherheit</strong>sempfehlungen.
464 Kapitel 16: Aspekte für kleine Unternehmen<br />
Ausschalten der Überwachung<br />
Wenn Sie die Überwachung ausschalten, verursacht das in der Zukunft zweifellos Probleme.<br />
Wenn Sie sich die Überwachungsprotokolle eines <strong>Server</strong>s (und jetzt mit <strong>Windows</strong> Vista auch<br />
die von Arbeitsstationen) ansehen, wünschen Sie sich vermutlich als Erstes, dass Sie nicht<br />
davon erschlagen werden. <strong>Die</strong> Unmenge an Informationen, insbesondere auf einem Domänencontroller,<br />
bedeutet, dass Sie jede Sekunde oder sogar häufiger ein Ereignis erwarten<br />
können. Es ist am sinnvollsten, wenn Sie die Protokollgröße erhöhen und die Überwachungsprotokolle<br />
für den Zeitpunkt verfügbar halten, an dem Sie diese Protokolle dringend<br />
für Ihre Analyse brauchen.<br />
Einschalten der Überwachung<br />
Was denn jetzt, hieß es nicht gerade, dass es schlecht wäre, die Überwachung auszuschalten?<br />
Jetzt behaupte ich also, dass es auch schlecht ist, sie einzuschalten? Ja. Hüten Sie sich<br />
vor bestimmten Überwachungseinstellungen, zum Beispiel für Objektzugriffe, sie füllen ein<br />
Überwachungsprotokoll ganz schnell. Falls Sie ein bestimmtes Zugriffsereignis überwachen<br />
wollen, sollten Sie sicherstellen, dass Sie die Überwachung präzise konfigurieren und nicht<br />
die generelle Überwachung auf dem gesamten Domänencontroller aktivieren.<br />
Ausschalten der Benutzerkontensteuerung<br />
Wenn Sie die Benutzerkontensteuerung (User Account Control, UAC) ausschalten, ist das<br />
eines der verheerendsten Dinge, das Sie in einer kleinen Organisation tun können, und nicht<br />
nur aus <strong>Sicherheit</strong>sgründen. Falls eine Software annimmt, dass die UAC eingeschaltet ist,<br />
das aber nicht der Fall ist, lässt sich diese Software unter Umständen nicht richtig installieren.<br />
Falls Sie mithilfe von Gruppenrichtlinien irgendwelche Änderungen an der UAC für<br />
Ihre Arbeitsstationen vornehmen, sollten Sie nur eine einzige Einstellung bearbeiten, nämlich<br />
Benutzerkontensteuerung: Verhalten der Benutzeraufforderung mit erhöhten Rechten für<br />
Administratoren im Administratorbestätigungsmodus. Stellen Sie hier die Option Erhöhte<br />
Rechte ohne Eingabeanforderung ein (Abbildung 16.19). Das sollte die einzige Einstellung<br />
sein, die Sie jemals ändern. In diesem Fall bleibt der Internet Explorer mit dem geschützten<br />
Modus aktiviert. Den Internet Explorer so gut wie möglich zu schützen, ist eine der besten<br />
Maßnahmen, die Ihnen in einem kleinen Unternehmen zur Verfügung stehen. Versuchen Sie<br />
aber auf jeden Fall, die UAC eingeschaltet und aktiviert zu lassen. Wenn Sie mit der Softwareinstallation<br />
erst einmal fertig sind, dürften Sie feststellen, dass Sie kaum noch UAC-<br />
Eingabeaufforderungen bestätigen müssen.<br />
Abbildung 16.19 Anpassen der UAC-Gruppenrichtlinien
Empfehlungen für kleine Unternehmen 465<br />
Benutzerkontensteuerung auf dem <strong>Server</strong><br />
Es gibt keinen vernünftigen Grund, warum ein Domänenadministrator auf dem <strong>Server</strong> im<br />
Web surfen sollte, keinen einzigen. Sie gefährden damit Ihre gesamte Infrastruktur. Daher ist<br />
es kein Wunder, dass das SBS <strong>2008</strong>-Team nach der Analyse der Bedrohungen und Risiken<br />
für diesen <strong>Server</strong> das integrierte Konto Administrator deaktiviert und die Benutzerkontensteuerung<br />
auf dem <strong>Server</strong> aktiviert hat, anders als bei <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. UAC soll Sie<br />
daran erinnern, dass ein <strong>Server</strong> kein Ersatz für eine Arbeitsstation ist und nur als <strong>Server</strong><br />
benutzt werden sollte. Halten Sie sich an die Verfahrensempfehlung, das integrierte Konto<br />
Administrator nie zu verwenden, nicht einmal für die simpelste Administratoraufgabe. Wie<br />
Sie in Abbildung 16.20 sehen, werden Sie daran erinnert, wie wichtig Ihr Domänencontroller<br />
ist, wenn Sie diese Einstellung unverändert lassen.<br />
Abbildung 16.20 <strong>Die</strong> Gefahr, dass ein Administrator den <strong>Server</strong><br />
als Arbeitsstation missbraucht, wird durch die UAC eingedämmt<br />
Antivirensoftware und Antispyware<br />
<strong>Die</strong> einzigen Websites, die ein <strong>Server</strong> jemals besuchen sollte, sind die verschiedenen Adressen<br />
des Microsoft Update-<strong>Die</strong>nstes. Weil Sie ohnehin niemals auf dem <strong>Server</strong> im Web<br />
surfen, gibt es also auch keinen Anlass, Antispywaresoftware darauf zu installieren. Kann<br />
genauso auf Antivirensoftware verzichtet werden? Vor allem auf einem Domänencontroller<br />
müssen Sie sicherstellen, dass Sie den Leitfäden in den Knowledge Base-Artikeln folgen,<br />
die eine Liste der kritischen Dateien, Ordner und Protokollspeicherorte enthalten. So können<br />
Sie sicherstellen, dass keine Probleme durch genau die Software entstehen, die den <strong>Server</strong><br />
schützen soll. Im Allgemeinen müssen Sie Speicherorte auf dem <strong>Server</strong> ausnehmen, in denen<br />
Active Directory-, Exchange- oder andere kritische Datenbanken ihre Protokolldateien<br />
ablegen.<br />
Hinweis Als Ausgangspunkt für die Definition von Ausschlüssen sollten Sie sich die Microsoft Knowledge<br />
Base-Artikel mit den Nummern 822158, 815263, 817442, 821749, 309422, 328841, 823166 und 245822<br />
ansehen. Dort finden Sie Beispiele für Typen und Orte von Ausschlüssen. Weitere Verweise enthält der<br />
Abschnitt »Weitere Informationen« am Ende dieses Kapitels.<br />
<strong>Die</strong> PCI/DSS-Richtlinien geben an, dass Sie Antivirensoftware auf allen gewöhnlich betroffenen<br />
Systemen bereitstellen sollten. Das umfasst Arbeitsstationen und <strong>Server</strong>. Sie müssen<br />
die Verfahrensempfehlungen, Antimalwaresoftware auf solchen kritischen <strong>Server</strong> bereitzustellen,<br />
gegen das ständige Risiko abwägen, dass solche Software eine wichtige Datei oder<br />
DLL versehentlich als böswillig markiert. Genau das passierte in dem Fall, der im Knowledge<br />
Base-Artikel 924995, »When You Restart <strong>Windows</strong> <strong>Server</strong> 2003, the Computer May
466 Kapitel 16: Aspekte für kleine Unternehmen<br />
Display a Gray Screen or May Appear to Stop Responding«, beschrieben ist. Damals stufte<br />
eine Antivirensoftware lsass.exe als Virus ein und legte dadurch <strong>Server</strong> lahm. Sinnvoller ist<br />
es, die Orte zu überprüfen, wo potenziell böswillige Software in das System eindringen<br />
kann. Verwenden Sie Datensäuberungsdienste, zum Beispiel Microsofts Forefront-<strong>Die</strong>nste<br />
für SharePoint und Exchange. Und natürlich sollten Sie Antimalwaretechnologie auf allen<br />
Arbeitsstationen und Terminalservern installieren. Falls diese Technologien vorhanden sind,<br />
brauchen die meisten <strong>Server</strong> (ja, das gilt auch für Multi-Rollen-<strong>Server</strong>) keine Antimalwaresoftware,<br />
weil die vorhandenen Schutzmechanismen die Probleme ja bereits im Griff haben<br />
dürften.<br />
NAP für kleine und mittlere Unternehmen<br />
Netzwerkzugriffsschutz (Network Access Protection, NAP) ist eine neue Technologie, die<br />
großen Nutzen verspricht. NAP wird zwar standardmäßig weder auf <strong>Windows</strong> Small Business<br />
<strong>Server</strong> <strong>2008</strong> noch auf <strong>Windows</strong> Essential Business <strong>Server</strong> eingerichtet sein, aber Sie<br />
sollten es in Ihre Netzwerkstrategie miteinbeziehen. Beachten Sie aber, dass Sie NAP erst<br />
dann im Erzwingungsmodus aktivieren sollten, wenn Sie sichergestellt haben, dass für alle<br />
Geräte, mit denen Sie selbst eine Verbindung zum Netzwerk herstellen, ein MAC-Ausschluss<br />
von der Erzwingungsrichtlinie konfiguriert ist. Sie können nicht dasselbe Antivirenprogramm<br />
wie Ihre Clients benutzen, daher ist es sinnvoll, NAP erst einmal im Berichterstellungsmodus<br />
bereitzustellen, um zu prüfen, welche Ausschlüsse nötig sind, bevor Sie die<br />
vollständige Erzwingung aktivieren. Wenn Sie sich blind durch den Assistenten aus Abbildung<br />
16.21 klicken, stellen Sie möglicherweise fest, dass Sie sich selbst ausgesperrt haben,<br />
weil Sie die Anforderungen der Richtlinie nicht erfüllen, die Sie gerade für das Netzwerk<br />
Ihres Kunden eingerichtet haben.<br />
Für kleine Organisationen besteht das größte Problem mit NAP darin, die Erzwingungsrichtlinien<br />
auszuwählen. Sie können DHCP mithilfe einer geänderten IP-Konfiguration umgehen.<br />
802.1x hat <strong>Sicherheit</strong>sprobleme, wenn es in einem Kabelnetzwerk eingesetzt wird. VPN ist<br />
in einem internen Netzwerk schwierig zu erzwingen. Damit bleibt IPSec als der einzige<br />
robuste Erzwingungsmechanismus für NAP. Das bedeutet eine komplexere Architektur.<br />
In einer kleinen Firma reicht DHCP wahrscheinlich für die Anforderungen des Unternehmens<br />
aus. Für <strong>Windows</strong> Small Business <strong>Server</strong> <strong>2008</strong> wird empfohlen, NAP auf einen separaten<br />
<strong>Server</strong> zu legen.<br />
Jede Installation sollte auch eine Quarantänelösung umfassen, damit Sie Computer, die die<br />
Anforderungen nicht erfüllen, isolieren können. In der Quarantäne muss ihnen der Zugriff<br />
auf Ressourcen möglich sein, die sie brauchen, um die Anforderungen erfüllen zu können.<br />
Andere führen an, dass Malwareentwickler einfach Methoden finden, die <strong>Server</strong> auszutricksen,<br />
sodass sie glauben, die Arbeitsstationen würden die Anforderungen der Richtlinie erfüllen.<br />
Das passiert vermutlich früher oder später, da jeder Erzwingungsmechanismus beim<br />
Netzwerkzugriff dem Client vertrauen muss. <strong>Die</strong>ses Argument geht aber am Ziel am vorbei.<br />
Das Konzept von NAP besteht nicht darin, vor allem böswillige Clients auszusperren, sondern<br />
sicherzustellen, dass die Clients, die noch nicht böswillig sind, diesen Zustand beibehalten.<br />
NAP bietet Mechanismen, mit denen Sie sicherstellen können, dass gesunde Clients<br />
auch gesund bleiben.
Abbildung 16.21 Netzwerkzugriffsrichtlinie können sogar in kleinen<br />
Organisationen bereitgestellt werden<br />
Empfehlungen für kleine Unternehmen 467<br />
Wird NAP gebraucht?<br />
Netzwerkzugriffsschutz war in letzter Zeit ein vieldiskutiertes Thema, aber ich bezweifle,<br />
ob es in einer kleinen Organisation gebraucht wird, die beim Remotezugriff kein VPN<br />
einsetzt. In meiner eigenen Organisation bin ich die Einzige, die VPN für die Updateverwaltung<br />
benutzen darf. Alle anderen Remotezugriffe werden über Remote Web Workplace<br />
durchgeführt, ein Remotezugriff-Webportal, das Remotedesktop benutzt und daher<br />
weniger <strong>Sicherheit</strong>sgefahren einführt. Prüfen Sie Ihre Zugriffsanforderungen und stellen<br />
Sie fest, ob die Einrichtung von NAP mehr Risiken einer potenziellen Falschkonfiguration<br />
bringt als die <strong>Sicherheit</strong>svorteile, die es verspricht.<br />
Weitere Informationen zum Netzwerkzugriffsschutz finden Sie in Kapitel 14 sowie im NAP-<br />
Blog unter http://blogs.technet.com/nap/archive/2007/07/28/network-access-protection<br />
deployment-planning.aspx. Ein Buch zu diesem Thema ist Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
Networking und Netzwerkzugriffsschutz <strong>–</strong> <strong>Die</strong> <strong>technische</strong> <strong>Referenz</strong> von Joseph Davies und<br />
Tony Northrup (Microsoft Press, <strong>2008</strong>).
468 Kapitel 16: Aspekte für kleine Unternehmen<br />
Zusammenfassung<br />
Ein Multi-Rollen-<strong>Server</strong> ist ein Balanceakt, bei dem Sie einen Kompromiss zwischen Anforderungen,<br />
Budgets, Geschäftszielen und <strong>Sicherheit</strong> finden müssen. Manche kleine Unternehmen<br />
brauchen mehr <strong>Sicherheit</strong>, andere weniger, aber sie alle brauchen gewisse Grundlagen,<br />
und Sie können helfen, hier geeignete Voraussetzungen zu schaffen. Endbenutzer müssen<br />
gedrängt werden, bessere Kennwörter zu wählen, und die Risiken, die einem Netzwerk<br />
durch ältere Plattformen drohen, müssen verstanden werden. Das alles ist bei kleinen Unternehmen<br />
nicht anders als bei ihren größeren Verwandten. Sie alle brauchen ein Netzwerk, das<br />
ihnen erlaubt, ihre Arbeit auf sichere Weise ohne inakzeptable Risiken zu erledigen. Der<br />
schwierigste Teil besteht bei Organisationen oder Netzwerken aller Größen darin zu akzeptieren,<br />
dass es keine perfekte Lösung gibt und dass es ein ständiger Kampf ist, diese Balance<br />
zu halten. <strong>Sicherheit</strong> ist ein Prozess, der ständig neu bewertet werden muss. Risiken und<br />
Bedrohungen für Netzwerke aller Größen ändern sich dauernd. Was heute als Lösung sicher<br />
genug sein mag, ist morgen möglicherweise für die Organisation keine tragfähige Lösung<br />
mehr. <strong>Die</strong> <strong>Sicherheit</strong>sgesetze sind absichtlich vage und herstellerneutral, weil auch sie anerkennen,<br />
dass <strong>Sicherheit</strong> ein bewegliches Ziel ist.<br />
Weitere Informationen<br />
»The TJX Effect« unter http://www.infosecnews.org/hypermail/0708/13565.html.<br />
»Medical IT Contractor Folds After Breaches« unter http://www.infosecnews.org/<br />
hypermail/0708/13587.html.<br />
»Fine Grain Password Policy Tool Beta 1 Is Ready!« unter http://itbloggen.se/cs/blogs/<br />
chrisse/archive/2007/08/05/585.aspx.<br />
Blackhat-Konferenzvortrag über »Bypassing NAC 2.0« unter http://www.blackhat.com/<br />
presentations/bh-dc-07/Arkin/Presentation/bh-dc-07-Arkin-ppt-up.pdf.<br />
»Comparing Default Services on <strong>Windows</strong> <strong>Server</strong> 2003 R2 and <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
(Core and Full)« unter http://blogs.technet.com/josebda/archive/2007/08/08/comparingdefault-services-on-windows-server-2003-r2-and-windows-server-<strong>2008</strong>-core-andfull.aspx.<br />
»Are We Too Simplistic in How We Think about Risk?« unter http://blogs.technet.com/<br />
jesper_johansson/archive/2006/05/09/427845.aspx.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Networking und Netzwerkzugriffsschutz <strong>–</strong> <strong>Die</strong> <strong>technische</strong> <strong>Referenz</strong><br />
von Joseph Davies und Tony Northrup (Microsoft Press, <strong>2008</strong>).<br />
»Outsourcing and Privacy: 10 Critical Questions Top Management Should Ask« unter<br />
http://infotech.aicpa.org/Resources/Privacy/Privacy+Hot+Topics/Privacy+Outsourcing/<br />
Outsourcing+and+Privacy+10+Critical+Questions+Top+Management+Should+<br />
Ask.htm.<br />
Knowledge Base-Artikel 821749, »IIS wird aufgrund der Antivirus-Software möglicherweise<br />
unerwartet beendet« unter http://support.microsoft.com/kb/821749.<br />
Knowledge Base-Artikel 815263, »Antivirus, Backup, and Disk Optimization Programs<br />
That Are Compatible with the File Replication Service« unter http://support.microsoft.<br />
com/kb/815263.
Weitere Informationen 469<br />
»Deploying <strong>Server</strong> Roles« unter http://technet.microsoft.com/en-us/library/aa997610.<br />
aspx.<br />
Knowledge Base-Artikel 328841, »Exchange und Antivirus-Software« unter<br />
http://support.microsoft.com/kb/328841.<br />
Knowledge Base-Artikel 309422, »Guidelines for Choosing Antivirus Software to Run<br />
on the Computers That Are Running SQL <strong>Server</strong>« unter http://support.microsoft.com/<br />
kb/309422.<br />
Knowledge Base-Artikel 895612, »So finden Sie einen kompatiblen Druckertreiber für<br />
einen Computer, auf dem eine 64-Bit-Version von <strong>Windows</strong> ausgeführt wird« unter<br />
http://support.microsoft.com/kb/895612.<br />
Knowledge Base-Artikel 817442, »IIS 6.0: Antivirus Scanning of IIS Compression<br />
Directory May Result in 0-Byte File« unter http://support.microsoft.com/kb/817442.<br />
»New Features in Exchange 2007 SP1« unter http://blogs.technet.com/asiasupp/archive/<br />
2007/06/26/new-features-in-exchange-2007-sp1.aspx.<br />
Knowledge Base-Artikel 823166, »Überblick über Exchange <strong>Server</strong> 2003 und Antivirus-<br />
Software« unter http://support.microsoft.com/kb/823166.<br />
Knowledge Base-Artikel 245822, »Empfehlungen für die Problembehandlung bei einem<br />
Exchange-Computer mit installierter Antivirensoftware« unter http://support.microsoft.<br />
com/kb/245822.<br />
»Setting the LAN Manager Authentication Level on a Network That Includes RIS« unter<br />
http://technet2.microsoft.com/windowsserver/en/library/22d98712-9349-44fb-8e69-<br />
1190ea0d039a1033.mspx?mfr=true.<br />
»Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration«<br />
unter http://technet2.microsoft.com/windowsserver<strong>2008</strong>/en/library/2199dcf7-<br />
68fd-4315-87cc-ade35f8978ea1033.mspx?mfr=true.<br />
Knowledge Base-Artikel 909444, »Bei Systemen, in denen die Standardberechtigungen<br />
für Zugriffssteuerungslisten im Verzeichnis "%WinDir%\registration" geändert wurden,<br />
können nach der Installation von Microsoft Security Bulletin MS05-051 für COM+ und<br />
MS DTC verschiedene Probleme auftreten« unter http://support.microsoft.com/kb/<br />
909444.<br />
»The <strong>Windows</strong> Vista and <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Developer Story: Application Compatibility<br />
Cookbook« unter http://msdn2.microsoft.com/en-us/library/aa480152.aspx.<br />
»Tweakomatic, by the Scripting Guys« unter http://www.microsoft.com/technet/script<br />
center/tools/twkmatic.mspx#EFE.<br />
Knowledge Base-Artikel 822158, »Empfehlungen für die Suche nach Viren auf<br />
einem <strong>Windows</strong> <strong>Server</strong> 2003-, <strong>Windows</strong> 2000- oder <strong>Windows</strong> XP-Computer« unter<br />
http://support.microsoft.com/kb/822158.<br />
»What Type of Remote Access Should I Allow?« unter http://windowshelp.microsoft.<br />
com/<strong>Windows</strong>/en-US/Help/ea4680d1-6962-463b-b29b-351efa676f9e1033.mspx.<br />
Knowledge Base-Artikel 924995, »When You Restart <strong>Windows</strong> <strong>Server</strong> 2003, the<br />
Computer May Display a Gray Screen or May Appear to Stop Responding« unter<br />
http://support.microsoft.com/kb/924995.<br />
»<strong>Windows</strong> Service Pack Road Map« unter http://www.microsoft.com/windows/lifecycle/<br />
servicepacks.mspx.
470 Kapitel 16: Aspekte für kleine Unternehmen<br />
»<strong>Windows</strong> System State Analyzer Tool« unter http://www.innovateonwindowsserver.com/<br />
learnbuild.aspx.<br />
»<strong>Windows</strong> Vista Group Policy Settings« unter http://download.microsoft.com/download/<br />
c/3/8/c3815ed7-aee7-4435-802b-8e855d549154/GroupPolicySettingsfor<strong>Windows</strong>Vista.xls.<br />
»<strong>Windows</strong> Vista Security Guide« unter http://www.microsoft.com/technet/windowsvista/<br />
security/guide.mspx.<br />
»<strong>Windows</strong> XP Security Guide« unter http://www.microsoft.com/technet/security/<br />
prodtech/windowsxp/secwinxp/default.mspx.<br />
»Threats and Countermeasures Guide« unter http://www.microsoft.com/technet/security/<br />
guidance/serversecurity/tcg/tcgch00.mspx.<br />
Microsoft <strong>Windows</strong> Vista <strong>–</strong> <strong>Die</strong> <strong>technische</strong> <strong>Referenz</strong> (Microsoft Press, <strong>2008</strong>).<br />
»PCI Industry Security Standards« unter https://www.pcisecuritystandards.org/pdfs/<br />
pci_dss_v1-1.pdf.<br />
»The Dangers of Remote PC Access« unter http://reviews.cnet.com/4520-3513_7-<br />
5053016-1.html.<br />
<strong>Windows</strong> Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).<br />
Microsoft Exchange <strong>Server</strong> 2007, Taschenratgeber für Administratoren (Microsoft Press,<br />
2007).<br />
Microsoft Exchange <strong>Server</strong> 2007 <strong>–</strong> Das Handbuch (Microsoft Press, 2007).<br />
Information Security Policies Made Easy (Information Shield, 2007).
K A P I T E L 1 7<br />
Schützen von <strong>Server</strong>anwendungen<br />
Von Alun Jones<br />
In diesem Kapitel:<br />
Einführung ........................................................ 471<br />
IIS 7.0: Ein <strong>Sicherheit</strong>sstammbaum ....................................... 473<br />
Konfigurieren von IIS 7.0 .............................................. 473<br />
TCP/IP-<strong>Sicherheit</strong> ................................................... 476<br />
Einfache pfadbasierte <strong>Sicherheit</strong> ......................................... 480<br />
Authentifizierung und Autorisierung ....................................... 484<br />
Zusammenfassung .................................................. 500<br />
Weitere Informationen ................................................ 501<br />
Einführung<br />
Was ist ein <strong>Server</strong>? Es ist ein Computersystem, dessen Aufgabe es ist, einen Teil von sich<br />
selbst für die Clients zugänglich zu machen. <strong>Die</strong>ser Teil können Daten, Anwendungen oder<br />
eine Kombination der beiden sein. Ein Datenserver ist natürlich höherer Gefahr durch andere<br />
vernetzte Systeme ausgesetzt als ein Client, weil der <strong>Server</strong> einige seiner Verteidigungsmaßnahmen<br />
öffnen muss, um den Zugriff zu ermöglichen. Ein Anwendungsserver ist sogar<br />
noch größerer Gefahr ausgesetzt: Er muss nicht nur seine Verteidigungsmaßnahmen öffnen,<br />
um den Zugriff zu ermöglichen, er muss auch noch auf Anforderung anderer Systeme Aufgaben<br />
ausführen.<br />
Um einen Anwendungsserver zu schützen, müssen Sie drei Punkte beachten: Authentifizierung,<br />
Autorisierung und Überwachung. Nur wenn Sie alle drei im Auge behalten, können<br />
Sie einschränken, wer eingelassen wird und was er tun kann, und verfolgen, was er getan<br />
hat. Das ist notwendig, um sicherzustellen, dass Ihre Einschränkungen befolgt wurden.<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> stellt mehrere Methoden zur Verfügung, um Ihren Benutzern Anwendungen<br />
anzubieten. In diesem Kapitel konzentriere ich mich für diesen Zweck auf die Internetinformationsdienste<br />
7 (Internet Information Services, IIS).<br />
Auf jeden Fall müssen Sie entscheiden, wie weit Sie die Verteidigung Ihres <strong>Server</strong>s öffnen<br />
wollen, um Ihren Benutzern Anwendungen verfügbar zu machen. Um hier eine sinnvolle<br />
Entscheidung treffen zu können, müssen Sie wissen, welche Anwendungen dies sind und<br />
woher sie stammen. Und Sie müssen wissen, wer Ihre Benutzer sind und woher sie kommen.<br />
471
472 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
Direkt aus der Praxis: Coole Features in IIS 7.0<br />
Eine der besten <strong>Sicherheit</strong>sänderungen in IIS 7.0 ist das neue integrierte anonyme Konto<br />
IUSR und die Benutzergruppe IIS IUSRS. In der Vergangenheit funktionierte die XCOPY-<br />
Bereitstellung zwar, war aber nicht völlig transparent <strong>–</strong> Sie mussten sich noch um die<br />
Zugriffssteuerungslisten (Access Control List, ACL) der Inhalte kümmern, die auf den<br />
IIS-<strong>Server</strong> kopiert wurden. In IIS 7.0 hat das Produktteam das anonyme Konto in das Betriebssystem<br />
einbauen lassen. Dadurch wird die Abhängigkeit zwischen Benutzerkonto<br />
und Ressourceninhalt entkoppelt, sodass eine vollständige XCOPY-Lösung im Bezug auf<br />
die Zugriffsberechtigungen der Inhalte verfügbar ist. Sie müssen auch weniger Konten<br />
verwalten, weil auf allen IIS 7.0-Computern dieselbe SID für anonyme Benutzer vorhanden<br />
ist. Und Sie brauchen sich nicht mehr so sehr den Kopf über ablaufende Kennwörter<br />
zerbrechen wie beim alten anonymen IUSR -Konto. Außerdem ersetzt<br />
die neue Benutzergruppe IIS IUSRS die alte Benutzergruppe IIS WPG, die in IIS 6.0 mit<br />
bestimmten Privilegien und Rechten zum Starten von Arbeitsprozessen vordefiniert war.<br />
Das bedeutet, dass Sie in IIS 7.0 die Anwendungspoolidentität des Kunden nicht mehr zu<br />
einem Mitglied der Benutzergruppe IIS IUSRS zu machen brauchen. Während der Laufzeit<br />
wird die Gruppen-SID von IIS IUSRS in das Arbeitsprozesstoken eingetragen, wodurch<br />
das Konto implizit zu einem Mitglied der neuen integrierten Benutzergruppe wird.<br />
<strong>Die</strong>se Mitgliedschaft wird dynamisch eingetragen und ist in IIS 7.0 standardmäßig aktiviert.<br />
Bernard Cheah, Microsoft MVP<br />
<strong>Windows</strong> <strong>Server</strong> <strong>–</strong> IIS<br />
<strong>Sicherheit</strong>swarnung: <strong>Sicherheit</strong>, ein Nachzügler im Internet<br />
Als Internet und World Wide Web entstanden, wurden sie entwickelt, um Informationen<br />
offen miteinander zu teilen, sodass jeder vollständigen Zugriff auf die Daten aller anderen<br />
erhielt. Deswegen können Sie feststellen, dass Ihre einfachste und sicherste Konfiguration<br />
darin besteht, Ihren <strong>Server</strong> so zu konfigurieren, dass er völlig offen arbeitet und die<br />
Informationen an alle ausliefert, die eine Verbindung herstellen.<br />
Verstehen Sie mich nicht falsch, ich will nicht anregen, dass Sie die Geheimnisse Ihres<br />
Unternehmens für alle Welt offen zur Schau stellen. Ich weise nur darauf hin, dass sich<br />
ein Internetserver am einfachsten schützen lässt, wenn er nur öffentliche Informationen<br />
ausliefert oder <strong>Die</strong>nste öffentlich zur Verfügung stellt, ohne zwischen Clients unterscheiden<br />
oder Aktivitäten aufgrund der Authentifizierung der Clientbenutzer autorisieren zu<br />
müssen.<br />
Ein großer Teil des Internets besteht immer noch aus statischem Inhalt, der in regelmäßigen<br />
Abständen von Menschen aktualisiert wird, die aus dem Bereich innerhalb der Firewall<br />
neuen Inhalt auf den <strong>Server</strong> hochladen. Solange Benutzer daran gehindert werden,<br />
Daten hochzuladen (und nur Dateien zu sehen bekommen, die aus der veröffentlichten<br />
Datenquelle stammen), bekommen sie niemals etwas zu sehen, das Sie ihnen nicht zeigen<br />
wollen.
Konfigurieren von IIS 7.0 473<br />
Ihre Site behandelt Clientbenutzer möglicherweise als anonym und unterscheidet nicht<br />
zwischen den Benutzern. Und vielleicht bestehen Ihre Daten aus unveränderlichen Seiten,<br />
die nichts Komplexeres als Bilder oder Links auf andere Seiten enthalten. Aber im dynamischen<br />
Internet <strong>–</strong> wo der <strong>Server</strong> Code ausführt, abhängig von der Auswahl, die der<br />
Clientbenutzer trifft, oder wo der <strong>Server</strong> Daten vom Clientbenutzer entgegennimmt oder<br />
Zugriff für unterschiedliche Clientbenutzer authentifiziert und autorisiert <strong>–</strong> tauchen die<br />
größten Herausforderungen für die <strong>Sicherheit</strong> auf. Böswillige Clientbenutzer versuchen,<br />
Ihre Systeme zu infiltrieren, indem sie manipulierte Daten hochladen, und auf Bereiche<br />
der Website zuzugreifen, zu denen sie keine Rechte besitzen.<br />
IIS 7.0: Ein <strong>Sicherheit</strong>sstammbaum<br />
<strong>Die</strong> Internetinformationsdienste (Internet Information Services, IIS) waren ein Aushängeschild<br />
für Microsofts Trustworthy Computing-Initiative (TwC) und sichere Entwicklungsverfahren<br />
im Allgemeinen. Es braucht besondere Konzentration und Aufmerksamkeit bezüglich<br />
der Details, wenn mithilfe sicherer Entwicklungsverfahren wirklich sichere Software<br />
erstellt werden soll. Indem Microsoft IIS Version 6.0 für <strong>Windows</strong> <strong>Server</strong> 2003 entwickelte,<br />
wandte Microsoft diese Tugenden auf Entwurfs-, Entwicklungs- und Testphasen an.<br />
In praktisch jedem Microsoft-Dokument über sichere Programmierung und TwC wird daher<br />
IIS 6.0 als Beispiel angeführt, welche Vorteile es bringt, wenn sichere Entwicklungsverfahren<br />
angewendet werden. Wie viel Mühe in IIS 6.0 investiert wurde, zeigt die Tatsache, dass<br />
es seit der Freigabe im Jahr 2003 nur zwei <strong>Sicherheit</strong>supdates für IIS 6.0 gab. Beide betrafen<br />
Add-On-Komponenten, und eines eine Kernkomponente von <strong>Windows</strong>, die nur in IIS ans<br />
Tageslicht kam. (Einige externe <strong>Sicherheit</strong>sbewertungen listen möglicherweise mehr <strong>Sicherheit</strong>slücken<br />
in IIS 6.0 auf, falls sie etwas unspezifischer definieren, welche Komponenten<br />
Teil von IIS 6.0 sind.)<br />
IIS 7.0 baut auf diesem Erbe auf: Gefahrenmodellierung, rigorose Standards bei den Programmierverfahren,<br />
radikale Entfernung und Ersatz unsicherer Bibliotheksfunktionsaufrufe,<br />
standardisierte und häufige Codebegutachtungen, Testen mit zufälligen Daten (fuzz testing)<br />
und so viele andere Methoden, dass sie gar nicht alle aufgezählt werden können. Das alles<br />
hat dazu geführt, dass IIS 7.0 ein würdiger Nachfolger für die eindrucksvolle <strong>Sicherheit</strong>sgeschichte<br />
von IIS 6.0 ist.<br />
Konfigurieren von IIS 7.0<br />
IIS 7.0 verwendet eine ganz andere Konfigurationsarchitektur als IIS 6.0. In IIS 6.0 wurden<br />
alle Konfigurationsdaten in proprietärem Format in einer Datenbank gespeichert, die als<br />
Metabasis bekannt ist. IIS 7.0 nutzt das XML-Format für seinen Konfigurationsdatenspeicher.<br />
Und wo IIS 6.0 alle Daten in einer einzigen Metabasisdatei speicherte, verteilt IIS 7.0<br />
die Datenspeicherung auf die Schichten, in denen die Konfiguration angewendet wird:<br />
global auf dem Webserver, lokal in einer Website oder spezifisch in einem virtuellen Verzeichnis<br />
oder einer Anwendung.<br />
Eine ausführliche Beschreibung, wo diese XML-Konfigurationsdatendateien gespeichert<br />
sind, wie sie bearbeitet werden und welche Beziehung zwischen den Konfigurationsdateien<br />
und der Oberfläche des Internetinformationsdienste-Managers besteht, finden Sie in Internet<br />
Information Services (IIS) 7.0 Resource Kit. Für dieses Kapitel sollten Sie zumindest wissen,
474 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
dass Sie die richtige Position eines Attributsatzes herausfinden können, indem Sie immer<br />
IIS_Schema.xml in IIS_Schema.xml in %SystemRoot%\system32\inetsrv\config\schema als<br />
autorisierend betrachten.<br />
IIS 7.0 bietet auch eine völlig überarbeitete (aber trotzdem MMC-basierte) Konfigurationsschnittstelle<br />
<strong>–</strong> die Konsole Internetinformationsdienste-Manager. Wie Sie in Abbildung 17.1<br />
sehen, hat sich diese Konsole gegenüber dem Internetinformationsdienste-Manager, der mit<br />
IIS 7.0 in <strong>Windows</strong> Vista veröffentlicht wurde, etwas weiterentwickelt und ist eine große<br />
Verbesserung gegenüber der Schnittstelle für IIS 6.0 in <strong>Windows</strong> <strong>Server</strong> 2003.<br />
Abbildung 17.1 <strong>Die</strong> Oberfläche des neuen IIS 7.0-Managers<br />
Featuredelegierung<br />
Aus Sicht des <strong>Sicherheit</strong>sadministrators für einen IIS-Webserver ist der interessanteste<br />
Aspekt dieses neuen Konfigurationsschamas die Fähigkeit, die Featurekonfiguration zu<br />
delegieren. Das heißt, Sie können erlauben, dass Konfigurationsentscheidungen auf der<br />
Ebene von Website oder virtuellem Verzeichnis von den Benutzern gemacht werden, die<br />
Zugriff zum Ändern des Inhalts der Website oder ihrer virtuellen Verzeichnisse haben.<br />
Wenn Sie den Konfigurationszugriff an Inhalts- und Sitebesitzer delegieren, wird die<br />
tägliche Konfiguration einer IIS-Website nun dort erledigt, wo sie hingehört: beim Besitzer<br />
der Website.<br />
Das wäre schlimm, geschähe es völlig ohne Einschränkungen; aber das war den IIS-<br />
Entwicklern natürlich bewusst. Daher stellten sie erstens sicher, dass Konfigurationen auf<br />
niedrigeren Ebenen von einer Konfiguration auf höherer Ebene geerbt werden können. Zum<br />
Beispiel erbt ein virtuelles Verzeichnis seine Standarddokumentenliste von der Website, zu<br />
der es gehört. Und die Website erbt ihre Standarddokumentenliste von dem Webserver, auf<br />
dem sie läuft. Und zweitens erlaubten die IIS-Entwickler Administratoren auf beliebiger
Konfigurieren von IIS 7.0 475<br />
Ebene zu verhindern, dass Einstellungen, die auf einer niedrigen Ebene vorgenommen werden,<br />
eine geerbte Einstellung überschreiben, die aus einer höheren Ebene stammt. Zum Beispiel<br />
kann ein Websitemanager verhindern, dass die Einstellungen einer Anwendung die<br />
Konfiguration überschreiben, die auf der Websiteebene festgelegt wurde.<br />
Sie sehen diese Vererbungshierarchie zwischen Konfigurationsdateien in Abbildung 17.2.<br />
Einstellungen für Komponenten auf niedriger Ebene stammen aus den Web.config-Dateien<br />
auf der jeweiligen Ebene, sie erben Einstellungen aus den höheren Ebenen. Indem Sie die<br />
Delegierung steuern, können Sie verhindern, dass Konfigurationsdateien auf niedrigerer<br />
Ebene Einstellungen überschreiben, die in Konfigurationsdateien auf höherer Ebene vorgenommen<br />
wurden.<br />
Abbildung 17.2 Vererbungshierarchie für Konfigurationseinstellungen<br />
<strong>Die</strong>se Delegierung mit ihrer Vererbung und <strong>Sicherheit</strong> ist besonders für Hostinganbieter und<br />
ihre Kunden interessant, die flexibel einstellen wollen, welche Konfigurationsmöglichkeiten<br />
den Kunden offenstehen, um Anpassungen vorzunehmen, und welche Konfigurationsmöglichkeiten<br />
den Hostinganbietern vorbehalten bleiben, um <strong>Sicherheit</strong> und Standards der<br />
<strong>Die</strong>nste zu gewährleisten.
476 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
Auch wenn die verteilte Konfiguration in IIS 7.0 es schwieriger macht, die Gesamtkonfiguration<br />
Ihres Webservers an einer einzigen Stelle zu ermitteln, können Sie eine falsche Konfiguration<br />
des Webservers verhindern, indem Sie die Vererbung der Einstellungen erzwingen,<br />
von denen Sie nicht wollen, dass sie geändert werden.<br />
TCP/IP-<strong>Sicherheit</strong><br />
Das Basisprotokoll, über das Webverkehr läuft, ist HTTP (Hypertext Transfer Protocol).<br />
HTTP wird im Allgemeinen über TCP/IP geleitet, das Standardinternetprotokoll in den meisten<br />
Umgebungen. IIS 7.0 unterstützt HTTP über TCP/IP Version 4 (IPv4), das verbreitetste<br />
Protokoll im heutigen Internet. <strong>Die</strong>ses Protokoll der Netzwerkschicht wurde auch schon von<br />
allen bisherigen IIS-Versionen unterstützt. IIS 7.0 fügt außerdem Unterstützung für HTTP<br />
über TCP/IP Version 6 (IPv6) hinzu, die Protokollversion für die nächste Generation der<br />
Internetunterstützung.<br />
IP-Adressensicherheit<br />
Wenn Sie Zugriff blockieren oder zulassen wollen, müssen Sie zuerst festlegen, ob die beabsichtigten<br />
Benutzer Verkehr zu und von Ihren <strong>Server</strong>n weiterleiten können. Wenn Sie eine<br />
intern weitergeleitete IP-Adresse verhindern, hilft das, Außenstehende daran zu hindern, auf<br />
eine Intranetsite zuzugreifen. Sofern die Router Ihrer Organisation richtig konfiguriert sind,<br />
kann eine intern weitergeleitete IP-Adresse als Beweis betrachtet werden, dass der Client,<br />
der eine Verbindung anfordert, sich innerhalb Ihrer Organisation befindet. Externe IP-Adressen<br />
sollten Sie nur bedingt einsetzen, um Clients zu identifizieren, weil es viele Möglichkeiten<br />
gibt, wie sie die Position eines Clients verfälschen können. Eine externe IP-Adresse<br />
könnte gestern dem einen Benutzer gehört haben, aber heute gehört sie einem anderen.<br />
Externe IP-Adressen werden von mehreren Benutzern gemeinsam genutzt, wie im Fall eines<br />
Anonymisierungsproxys, der mit dem Ziel entworfen wurde, die Identität eines Clients zu<br />
verschleiern.<br />
Whitelisting anhand der Quell-IP-Adresse (das heißt Zurückweisen aller Verbindungen, die<br />
nicht von Adressen bekannter Partner stammen) ist meist recht zuverlässig, weil es sehr<br />
schwierig ist, eine TCP-Verbindung zu fälschen, wenn damit etwas Komplexeres als ein<br />
Denial-of-Service-Angriff erreicht werden soll. Blacklisting anhand der Quell-IP-Adresse<br />
(das heißt Annehmen aller Verbindungen, die nicht von bekanntermaßen böswilligen Hosts<br />
stammen) ist im Allgemeinen nicht erfolgreich, weil Angreifer oft auf einen neuen Host<br />
wechseln können, der noch nicht in der Liste verzeichnet ist.<br />
Wenn Sie einschränken wollen, welche IP-Adressen eine Verbindung zu Ihrem Webserver<br />
herstellen dürfen, können Sie dazu das Feature Einschränkungen für IPv4-Adressen und<br />
Domänen verwenden oder die IP-<strong>Sicherheit</strong>seinstellungen in der XML-Konfigurationsdatei<br />
applicationHost.config im folgenden Abschnitt bearbeiten:<br />
<br />
<br />
<br />
TCP/IP-<strong>Sicherheit</strong> 477<br />
Das Element ipSecurity hat zwei Attribute:<br />
allowUnlisted legt fest, ob die Liste der untergeordneten Elemente von ipSecurity nach<br />
bekanntermaßen unerwünschten oder erwünschten Quell-IP-Adressen durchsucht wird.<br />
Wenn Sie allowUnlisted auf "false" setzen, können nur die untergeordneten Elemente,<br />
die mit allow markiert sind, auf diesen Webserver zugreifen; alle anderen werden abgewiesen.<br />
Wenn Sie allowUnlisted auf "true" setzen, dürfen alle IP-Adressen außer denen,<br />
die explizit mit deny markiert sind, eine Verbindung herstellen.<br />
enableReverseDns müssen Sie auf "true" setzen, falls Sie anhand des Domänennamens<br />
filtern. Weil ein Reverse-DNS-Lookup einige Zeit dauern kann, was die Verbindungen<br />
unter Umständen verzögert, sollten Sie dieses Attribut auf dem Standardwert "false"<br />
lassen, falls Sie keine Filterung anhand des Domänennamens durchführen wollen. Denken<br />
Sie daran, dass viele DNS-Zonen keine Reverse-Lookups anbieten und <strong>Windows</strong> in<br />
der Standardeinstellung keine Reverse-Lookupzonen generiert. Daher schlägt ein<br />
Reverse-DNS-Lookup sehr oft fehl.<br />
Abbildung 17.3 Zulassen des Adressbereichs 169.254.*.*<br />
im Dialogfeld Zulassungseinschränkungsregel hinzufügen<br />
Untergeordnete Elemente können Sie zur ipSecurity-Auflistung hinzufügen, indem Sie die<br />
üblichen add-, clear- oder remove-Direktiven mit den folgenden Attributen verwenden:<br />
ipAddress ist die numerische IP-Adresse des Hosts oder Netzwerks, denen der Zugriff<br />
erlaubt oder verweigert wird. Zum Beispiel steht 127.0.0.1 für localhost. Falls Sie in der<br />
Standardeinstellung den Zugriff verweigern (allowUnlisted auf "false" setzen), sollten<br />
Sie für Testzwecke im Allgemeinen den Zugriff durch 127.0.0.1 und andere lokal gebundene<br />
IP-Adressen aktivieren.<br />
subnetMask ist die numerische Subnetzmaske, die definiert, welches Netzwerk anhand<br />
der IP-Adresse angegeben wird. Zum Beispiel können Sie das gesamte 10.*.*.*-Netzwerk<br />
aussperren, indem Sie ipAddress als 10.0.0.0 und subnetMask als 255.0.0.0 definieren.<br />
Der Standardwert ist 255.255.255.255, womit eine einzelne IP-Adresse definiert<br />
wird.<br />
domainName ist der vollqualifizierte Domänenname des Hosts, auf den diese Regel angewendet<br />
werden soll.
478 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
allowed erlaubt allen Clients, auf die diese Regel zutrifft, den Zugriff, wenn es den Wert<br />
"true" hat. Ist es auf "false" gesetzt, werden alle Clients abgewiesen, auf die die Regel<br />
zutrifft. <strong>Die</strong> Regeln werden in der Reihenfolge verarbeitet, in der sie aufgelistet sind. <strong>Die</strong><br />
erste passende Regel bestimmt, was mit der eingehenden Verbindung geschieht.<br />
<strong>Die</strong> Benutzeroberfläche für diese Einstellung ist simpel. Sie unterscheidet zwischen dem<br />
Festlegen eines Zulassen- und eines Verweigern-Eintrags. In Abbildung 17.3 habe ich einen<br />
Zulassen-Eintrag für das Netzwerk 169.254.*.* eingetragen (das entspricht 169.254.0.0/16).<br />
Wie Sie in Abbildung 17.4 sehen, wird diese Regel jetzt als Zulassen-Eintrag aufgelistet. Sie<br />
können einen Zulassen-Eintrag nur in einen Verweigern-Eintrag verwandeln, indem Sie ihn<br />
entfernen und einen entsprechenden Verweigern-Eintrag neu hinzufügen.<br />
Abbildung 17.4 <strong>Die</strong> neu hinzugefügte Regel für den Zulassen-Eintrag wird angezeigt<br />
Der entsprechende XML-Code in der Datei applicationHost.config sieht folgendermaßen<br />
aus:<br />
<br />
...<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
TCP/IP-<strong>Sicherheit</strong> 479<br />
Portsicherheit<br />
In der Standardeinstellung läuft HTTP über Port 80, aber weil URLs die Portnummer enthalten<br />
können, ist es nicht ungewöhnlich, wenn Webserver über andere Ports als Port 80 arbeiten.<br />
Das Protokoll HTTPS (TP über SSL/TLS) ist standardmäßig an Port 443 gebunden.<br />
Aus Sicht der <strong>Sicherheit</strong> kann diese Verwendung von Ports nützlich sein, um den Zugriff an<br />
der Firewall einzuschränken. Falls ein <strong>Server</strong> so konfiguriert wurde, dass er eingehende<br />
Anforderungen an Port 8080 entgegennimmt und ausschließlich Intranetinhalt hostet, besteht<br />
eine offensichtliche <strong>Sicherheit</strong>smaßnahme darin, eine Firewall (entweder auf dem<br />
Host, zwischen Host und Internet oder beides) so zu konfigurieren, dass sie Zugriff auf diesen<br />
Port nur von IP-Adressen erlaubt, die bekanntermaßen im Intranet liegen.<br />
Hostheadersicherheit<br />
Hinter derselben Kombination aus IP-Adresse/Port können sich mehrere Websites befinden.<br />
Das ist möglich, indem der Hostheader ausgewertet wird, der in den HTTP- oder HTTPS-<br />
Anforderungen der Clients enthalten ist. Daraufhin wird die Anforderung an die Website<br />
geleitet, die im Hostheader angegeben ist.<br />
Das ist eigentlich keine <strong>Sicherheit</strong>smaßnahme. Wie beim Verlegen Ihrer Website auf einen<br />
anderen IP-Port handelt es sich um eine Verschleierungsmaßnahme (engl. obscurity measure).<br />
Das kann zwar simple, opportunistische oder zufällige Angriffe auf Ihre Sites verhindern,<br />
aber es sollte eigentlich als Komfortmerkmal verstanden werden, das es Ihnen erlaubt,<br />
mehrere Websites unter derselben IP-Adresse mit der Standardportzuweisung zu hosten.<br />
<strong>Die</strong> IP- und Portbindungen oder die Hostheaderbindung können Sie nur auf der Websiteebene<br />
ändern. <strong>Die</strong> Bindungen sind in der XML-Datei applicationHost.config gespeichert,<br />
wie im folgenden Beispiel zu sehen:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Für das Element binding sind unter anderem folgende Attribute verfügbar:<br />
protocol ist normalerweise "http" oder "https". Es kann auch andere Protokolldefinitionen<br />
enthalten (zum Beispiel das Protokoll "ftp", falls der IIS 7.0-FTP-<strong>Server</strong> installiert<br />
ist).<br />
bindingInformation ist eine Kombination aus IP-Adresse, Port und Hostheader, die<br />
durch Doppelpunkte getrennt werden. Sie können einen Stern (*) verwenden, der für<br />
»alle IP-Adressen« steht. Falls Sie zum Beispiel eine Bindung für das Protokoll HTTP<br />
erstellen wollen, die auf allen IP-Adressen unter Port 80 mit dem Hostheader »Marketing«<br />
arbeitet, lautet der bindingInformation-String "*:80:marketing".
480 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
Einfache pfadbasierte <strong>Sicherheit</strong><br />
In IIS-Websites werden neben Dateien auch Anwendungen gehostet und den Benutzern zur<br />
Verfügung gestellt. Wenn Sie einem Client erlaubt haben, eine TCP/IP-Verbindung zu Ihrem<br />
<strong>Server</strong> herzustellen, besteht der nächste Schritt darin, den Zugriff auf die Dateien und Anwendungen<br />
einzuschränken, die zur angeforderten Website gehören. Den Zugriff auf Dateien<br />
anhand ihres physischen Pfads auf dem <strong>Server</strong> einzuschränken, ist eine einfache Methode,<br />
um sicherzustellen, dass unterschiedliche Websites nicht versehentlich vermischt werden.<br />
Definieren und Einschränken des physischen Pfads<br />
<strong>Die</strong> allererste <strong>Sicherheit</strong>sanforderung für jeden Webserver, der unter IIS 7.0 läuft (sogar eine<br />
Website, die nur statischen Inhalt an anonyme Clientbenutzer ausliefert), besteht darin<br />
sicherzustellen, dass die Clients nur Dateien abrufen können, die explizit auf dieser Website<br />
veröffentlicht wurden.<br />
Glücklicherweise ist dies (nach dem Namen der Website) die erste Einstellung, die Sie konfigurieren<br />
müssen, wenn Sie eine neue Site anlegen (Abbildung 17.5, in der Benutzeroberfläche<br />
als Physikalischer Pfad bezeichnet).<br />
Abbildung 17.5 Im Dialogfeld Website hinzufügen geben Sie den physischen Pfad ein<br />
<strong>Die</strong> Standardwebsite, die erstellt wird, wenn Sie die Rolle Webserver (IIS) zu <strong>Windows</strong> hinzufügen,<br />
wird automatisch mit dem physischen Pfad %SystemDrive%\inetpub\wwwroot<br />
eingerichtet. Sie können das wie bei jeder Website überprüfen und ändern, indem Sie die<br />
Grundeinstellungen oder erweiterten Einstellungen der Site öffnen. <strong>Die</strong> Grundeinstellungen<br />
können Sie sich im Internetinformationsdienste-Manager ansehen, indem Sie die Website<br />
auswählen und dann im Fensterabschnitt Aktionen auf Grundeinstellungen klicken. Das<br />
Dialogfeld Erweiterte Einstellungen können Sie öffnen, indem Sie mit der rechten Maustaste<br />
auf den Namen der Website klicken, das Untermenü Website verwalten öffnen und<br />
dann den Befehl Erweiterte Einstellungen wählen oder indem Sie im Fensterabschnitt<br />
Aktionen auf Erweiterte Einstellungen klicken.
Einfache pfadbasierte <strong>Sicherheit</strong> 481<br />
Das Dialogfeld mit den Grundeinstellungen heißt Site bearbeiten, es enthält nur wenige<br />
Einstellungen (Abbildung 17.6).<br />
Abbildung 17.6 Das Dialogfeld Site bearbeiten zeigt die Grundeinstellungen<br />
Das Dialogfeld Erweiterte Einstellungen (Abbildung 17.7) enthält dieselben Grundeinstellungen,<br />
aber zusätzlich eine Reihe weiterer Einstellungen.<br />
Abbildung 17.7 Im Dialogfeld Erweiterte Einstellungen<br />
können Sie viele weitere Einstellungen konfigurieren<br />
In der Standardkonfiguration liegt der physische Pfad auf dem Startvolume des Webservercomputers.<br />
Um eine gestaffelte Verteidigung gegen potenzielle Verzeichnis-Traversal-Angriffe<br />
aufzustellen <strong>–</strong> bei denen ein Schrägstrich (/) oder Backslash (\) oder die Sequenz ..<br />
benutzt wird, um aus dem physischen Pfad herauszugelangen <strong>–</strong>, ist es sinnvoll, eine Laufwerkspartition<br />
zu erstellen, die ausschließlich für Webinhalte reserviert wird. Verzeichnis-<br />
Traversal-Angriffe verfolgen zwar das Ziel, die Verzeichnisstruktur nach oben zu durchlaufen,<br />
aber sie haben keine Möglichkeit, auf ein anderes Laufwerk zu wechseln. Natürlich hat<br />
IIS 7.0 dieselben strengen Auflagen für Anwendungsverzeichnisse, die bei IIS 6.0 schon seit<br />
Jahren zuverlässig Verzeichnis-Traversal-Angriffe verhindern. Wenn alle Webinhalte auf<br />
einer separaten Partition liegen, führt auch ein erfolgreicher Angriff, der das Hochladen von<br />
Daten ermöglicht, nicht dazu, dass System- oder Startvolumes gefüllt werden können.
482 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
Es ist auch möglich, den physischen Pfad auf eine Netzwerkfreigabe in einem anderen <strong>Server</strong><br />
zu legen. Dazu können Sie einen UNC-Pfad wie zum Beispiel \\<strong>Server</strong>\Freigabename<br />
angeben. Sie können die Dialogfelder für Grund- oder erweiterte Einstellungen verwenden,<br />
um die Anmeldeinformationen des Benutzers so zu verändern, dass sie auf Dateien im physischen<br />
Pfad der Website zugreifen. So können Sie sicherstellen, dass für die Benutzer dieser<br />
Website beim Zugriff auf Dateien die jeweiligen NTFS- und Freigabeberechtigungen angewendet<br />
werden.<br />
Vorsicht Passen Sie bei allen Optionen auf, die Anmeldeinformationen eines Benutzer für einen späteren<br />
Identitätswechsel speichern. Selbst wenn diese Anmeldeinformationen verschlüsselt sind, bleibt ein gewisses<br />
Risiko, dass jemand Lesezugriff auf die Konfiguration dieses <strong>Server</strong>s bekommt und sich als dieser<br />
andere Benutzer authentifiziert.<br />
Aus diesem Grund sollten die Anmeldeinformationen, die Sie hier angeben, zu einem Konto gehören, das<br />
keine echte Person repräsentiert. <strong>Die</strong> Rechte und Privilegien dieses Kontos sollten darauf beschränkt sein,<br />
auf die Ordner und Dateien der Website zuzugreifen.<br />
Das Kennwort für dieses Konto sollte nicht auch für irgendwelche anderen Konten benutzt werden, und es<br />
sollte zufällig generiert werden, zum Beispiel mit dem folgenden Befehl:<br />
net user Kontoname /add /domain /random<br />
<strong>Die</strong> mit dem Befehl net user /random generierten Kennwörter sind auf eine Länge von 8 Zeichen beschränkt.<br />
Falls Sie längere zufällige Kennwörter generieren wollen, empfehle ich das von Jesper Johansson<br />
entwickelte Tool Passgen, das Sie auf der Begleit-CD zu diesem Buch finden.<br />
<strong>Die</strong> Einstellungen zum physischen Pfad der Website und ihrer virtuellen Verzeichnisse<br />
finden Sie zusammen mit dem Benutzerkonto, das für den Zugriff auf den physischen Pfad<br />
verwendet wird, an folgender Stelle in der XML-Datei applicationHost.config :<br />
<br />
<br />
<br />
<br />
<br />
<br />
<strong>Die</strong>s wird in der systemweiten applicationHost.config eingestellt, nicht in der individuellen<br />
Web.config-Datei der Site. Physischer Pfad, Benutzerkonto und Kennwort sind keine Eigenschaften<br />
der Website. Sie ändern sich, falls die Website auf einen anderen Hostingdienst<br />
verlegt wird, und sie sollten im Allgemeinen nicht dem Websitebesitzer mitgeteilt werden.<br />
Attribute des Elements virtualDirectory sind unter anderem:<br />
path ist eine Zeichenfolge, die den virtuellen Pfad vom Stammverzeichnis der Website<br />
zu diesem Pfad beschreibt.<br />
physicalPath ist der physische Pfad zum Inhalt, der in diesem virtuellen Verzeichnis<br />
gespeichert ist. Für lokalen Inhalt kann der Pfad das Format "X:\Pfad1\Pfad2" haben; für<br />
Netzwerkinhalt sollte der Pfad im UNC-Format angegeben werden, zum Beispiel<br />
"\\<strong>Server</strong>\Freigabe\Pfad1\Pfad2".<br />
username ist eine Zeichenfolge, die den Namen des Benutzers angibt, dessen Anmeldeinformationen<br />
verwendet werden, um auf den physischen Pfad zuzugreifen. Falls dieses<br />
Attribut fehlt, wird Pass-Through-Authentifizierung verwendet.
Einfache pfadbasierte <strong>Sicherheit</strong> 483<br />
password ist eine AES-verschlüsselte Zeichenfolge mit dem Kennwort, das für den<br />
Zugriff auf den physischen Pfad verwendet wird. Es wird davon abgeraten, dieses Attribut<br />
von Hand zu bearbeiten. Verwenden Sie appcmd, um die Konfigurationsdatei skriptgesteuert<br />
zu verändern, oder die Konsole Internetinformationsdienste-Manager.<br />
logonMethod kann die Werte Interactive, Batch, Network oder ClearText haben. <strong>Die</strong>s gibt<br />
an, welcher Anmeldungstyp verwendet werden soll, um den Zugriff auf Dateien im Pfad<br />
dieser Anwendung zu autorisieren. ClearText ist der Standardwert, er eignet sich für die<br />
meisten Fälle. Sie können Network für den Zugriff auf Netzwerkressourcen verwenden,<br />
aber Batch und Interactive sollten Sie kaum verwenden, weil sie nicht auf geeignete<br />
Weise bekannt machen, dass die Dateien nichtinteraktiv von einem Remotebenutzer angefordert<br />
werden. Beachten Sie, dass auf manche Ressourcen nur interaktive Benutzer,<br />
Netzwerkbenutzer und so weiter zugreifen dürfen. Unter Umständen müssen die NTFS-<br />
Berechtigungen für den Inhalt geändert werden, damit sie sich für die logonMethod-Standardeinstellung<br />
ClearText eignen. Sie sollten logonMethod im Allgemeinen nicht ändern.<br />
<strong>Die</strong> im vorherigen Abschnitt beschriebenen Anmeldeinformationen und die logonMethod-<br />
Einstellung können von Anwendungen überschrieben werden, die Identitätswechsel nutzen.<br />
In diesem Fall sind die Anmeldeinformationen, die nach dem Identitätswechsel verwendet<br />
werden, die Anmeldeinformationen, mit denen auf den Inhalt der Website zugegriffen wird.<br />
Standarddokument oder Verzeichnissuche?<br />
Nehmen wir an, ein Benutzer besucht Ihre Website und sieht die folgende URL im Adressfeld:<br />
http://www.contoso.com/public/index.html<br />
Unvermeidlich setzt Neugier ein: »Was passiert, wenn ich auf ähnliche URLs zugreife?«<br />
http://www.contoso.com/public/<br />
http://www.contoso.com/<br />
Als das Web entstand, schien es logisch, sich an einigen Protokollen zu orientieren, die damals<br />
in Gebrauch waren: FTP, Gopher und so weiter. In Clients für diese Protokolle sahen<br />
Sie sich eine Verzeichnisliste an, sofern Sie keine Datei aufgerufen hatten. Daher generierten<br />
die Webserver in diesen alten Zeiten eine Seite, die den Inhalt eines Verzeichnisses auflistete.<br />
Im Allgemeinen ist es heutzutage sinnvoller, die Versuchung für Browser zu verringern,<br />
die auf gehosteten Seiten angezeigten URLs zu verlassen. Daher ist das Feature der Verzeichnissuche<br />
deaktiviert. Wenn ein Client eine URL besucht, die für ein Verzeichnis steht,<br />
gibt der Webserver eine Seite mit festem Namen zurück, die in diesem Verzeichnis abgelegt<br />
ist.<br />
IIS 7.0 verhält sich hier nicht anders. Wenn Sie ein Verzeichnis besuchen, während die Verzeichnissuche<br />
deaktiviert ist (Standardwert), wird eine der folgenden Dateien aus dem Zielverzeichnis<br />
angezeigt, je nachdem, welche zuerst gefunden wird:<br />
Default.htm<br />
Default.asp<br />
Index.htm<br />
Index.html<br />
iisstart.htm<br />
default.aspx
484 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
Sie können diese Elemente im Internetinformationsdienste-Manager auf der Ebene von <strong>Server</strong>,<br />
Site oder virtuellem Verzeichnis hinzufügen oder entfernen, indem Sie das Feature Standarddokument<br />
öffnen. Sie können dies auch in der XML-Konfiguration (in der application-<br />
Host.config des Webservers oder in der Web.config-Datei von Website, Anwendung oder<br />
virtuellem Verzeichnis) im folgenden Abschnitt einstellen:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Das Element defaultDocument hat nur ein Attribut, enabled, das "true" oder "false" sein<br />
kann. Das Element defaultDocument/files kann Elemente mit den üblichen Namen enthalten<br />
(add, remove und clear), um die Liste der Dateien in der Auflistung zu steuern, wie im<br />
vorherigen Beispiel gezeigt.<br />
Sie sollten eine serverweite Liste der Standarddokumente festlegen, weil dies die Dokumente<br />
sind, die gesucht und angezeigt werden, falls die angeforderte URL ein Verzeichnis ist.<br />
Wenn Sie sich darauf verlassen, dass ein Standarddokument weiter oben in der Liste vorhanden<br />
ist und daher verhindert, dass eines weiter unten in der Liste ignoriert wird, schlägt<br />
das wahrscheinlich fehl, falls jemand eine der Standarddateien verschiebt oder umbenennt.<br />
Falls Sie lieber eine Liste der Dateien in einem Verzeichnis anzeigen, wenn ein Verzeichnis<br />
angefordert wird und kein Standarddokument gefunden wird, können Sie im Internetinformationsdienste-Manager<br />
das Feature Verzeichnis durchsuchen öffnen und aktivieren. Oder<br />
Sie aktivieren es in der Web.config-Datei unter folgendem Pfad:<br />
<br />
<br />
<br />
Authentifizierung und Autorisierung<br />
Wenn Sie einen Webserver einrichten, lautet nach der Frage »Welchen Inhalt sollen wir<br />
hosten?« die nächste meistens: »Wem sollen wir diesen Inhalt zur Verfügung stellen?« Wenn<br />
Sie auswählen wollen, welchen Benutzern der Zugriff auf welchen Inhalt erlaubt wird, brauchen<br />
Sie einen guten Authentifizierungsmechanismus als Grundlage.<br />
Wie es sich für einen Internetstandard gehört, stellt HTTP viele Clientauthentifizierungsmechanismen<br />
zur Auswahl, die unterschiedliche Vor- und Nachteile haben. In IIS 7.0 stehen<br />
standardmäßig die Authentifizierungsmethoden anonyme Authentifizierung, Standardauthentifizierung,<br />
Clientzertifikatzuordnung, Digestauthentifizierung, Formularauthentifizierung<br />
und <strong>Windows</strong>-Authentifizierung zur Verfügung. (In Kapitel 4, »Authentifizierung<br />
und Authentifizierungsprotokolle«, finden Sie genauere Beschreibungen einiger dieser<br />
Methoden.)<br />
Anonyme Authentifizierung, Standardauthentifizierung, Clientzertifikatzuordnung, Digestauthentifizierung<br />
und Formularauthentifizierung basieren auf Internetstandarddokumenten<br />
und funktionieren mit mehreren Browsern. Manche andere Browser als Internet Explorer
Authentifizierung und Autorisierung 485<br />
bieten unter Umständen keine Unterstützung für die integrierte <strong>Windows</strong>-Authentifizierung.<br />
Nur die anonyme Authentifizierung ist in der Standardeinstellung aktiviert.<br />
Der gesamte Zugriff von IIS auf Ressourcen, die der Webserver ausliefert, wird durch <strong>Windows</strong>-NTFS-Berechtigungen<br />
gesteuert. Das bedeutet, dass jeder Zugriff über eine lokale<br />
Benutzer-ID mit den zugehörigen Gruppen durchgeführt wird. Es ist wichtig, hier zwischen<br />
dem <strong>Sicherheit</strong>skontext zu unterscheiden, den der Benutzer zu haben glaubt, und dem<br />
<strong>Sicherheit</strong>skontext, den der <strong>Server</strong> verwendet, um den Zugriff dieses Benutzers zu bedienen.<br />
Ein gutes Beispiel ist die anonyme Authentifizierung: In der Standardeinstellung ist sie<br />
mit dem IUSR-Konto verknüpft, um zu steuern, auf welche Dateien und Ressourcen zugegriffen<br />
werden kann.<br />
Authentifizierungseinstellungen werden zwar auf der Ebene von <strong>Server</strong>, Website oder virtuellem<br />
Verzeichnis aktiviert, deaktiviert und definiert, aber die meisten Konfigurationseinstellungen<br />
sind in der serverweiten Datei applicationHost.config unter dem folgenden Abschnitt<br />
gespeichert:<br />
<br />
<br />
<br />
<br />
<br />
<strong>Die</strong> Einstellungen beziehen sich auf Elemente, die serverspezifisch sind, nicht sitespezifisch,<br />
zum Beispiel physische Pfade, Benutzernamen und Domänen.<br />
Anonyme Authentifizierung<br />
Anonyme Authentifizierung ist der einzige Authentifizierungsmechanismus in IIS 7.0, der<br />
nach der Installation standardmäßig aktiviert ist. In vielen Aspekten ist dies die sicherste<br />
Konfiguration, weil Ihr Webserver dann Seiten an jeden ausliefert, der eine Verbindung<br />
herstellen kann. Sie als Webmaster stellen sicher, dass nur öffentliche Seiten ausgeliefert<br />
werden können.<br />
Wenn Sie das Element Anonyme Authentifizierung auswählen und den Befehl Bearbeiten<br />
wählen, wird nur eine Konfigurationseinstellung angeboten. Sie können einen Benutzer<br />
auswählen, dessen Konto verwendet wird, um auf Ressourcen zuzugreifen (Abbildung 17.8).<br />
Abbildung 17.8 Im Dialogfeld Anmeldeinformationen für anonyme<br />
Authentifizierung bearbeiten legen Sie fest, welche Identität für den<br />
anonymen Zugriff auf Webressourcen verwendet wird<br />
In der Standardeinstellung ist die anonyme Benutzeridentität das integrierte Konto IUSR mit<br />
der bekannten SID S-1-5-17, das in IIS 7.0 neu ist. (In Kapitel 1, »Subjekte, Benutzer und<br />
andere Akteure«, finden Sie eine Beschreibung von SIDs.) In IIS 6.0 und älteren Versionen
486 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
wurde auf jedem Computer ein neues Konto mit dem Namen IUSR_ erstellt,<br />
das eine praktisch zufällige SID hatte. Sie können ein anderes Konto auswählen oder<br />
die Identität des Anwendungspools verwenden. <strong>Die</strong>s ist das Konto, unter dem der Anwendungspool<br />
der Website ausgeführt wird.<br />
Hinweis Es ist wichtig, dass Sie den Unterschied zwischen der Identität der anonymen Authentifizierung<br />
und der Identität des Anwendungspools kennen. Sie können zwar für beide denselben Wert einstellen, aber<br />
die Identität des Anwendungspools ist der Benutzerkontokontext, in dem die Arbeitsprozesse der Anwendung<br />
ausgeführt werden, während die Identität der anonymen Authentifizierung der Benutzerkontokontext<br />
ist, in dem anonyme Anforderungen auf Websiteressourcen zugreifen.<br />
Wenn Sie ein anderes Konto als IUSR oder die Identität des Anwendungspools verwenden,<br />
kann das nützlich sein, um sicherzustellen, dass eine Site nicht auf die Ressourcen einer<br />
anderen Site verweisen kann, aber weil diese Ressourcen für alle, die diese Site erreichen,<br />
öffentlich zugänglich sind, ist das wahrscheinlich nur nützlich, falls der <strong>Server</strong> sowohl Intranet-<br />
als auch Internetinhalt hostet und derjenige, der den Inhalt für die Internetsites erstellt,<br />
unter Umständen auf Inhalt der Intranetsite verweisen könnte. In einer solchen Situation<br />
wäre es aber wohl besser, gleich unterschiedliche <strong>Server</strong> einzusetzen, um die unterschiedlichen<br />
Inhalte zu hosten, wobei der <strong>Server</strong> mit dem Intranetinhalt hinter einer Firewall steht,<br />
die verhindert, dass Internetverkehr <strong>–</strong> oder Verkehr aus dem <strong>Server</strong>, der mit dem Internet<br />
verbunden ist <strong>–</strong> auf Intranetinhalt zugreift.<br />
Der Abschnitt anonymousAuthentication in der Datei applicationHost.config enthält folgende<br />
Attribute:<br />
enabled ist "true", wenn die anonyme Authentifizierung aktiviert ist, oder "false", wenn<br />
die anonyme Authentifizierung deaktiviert ist.<br />
userName ist der Benutzername, unter dem der Zugriff bei Verwendung der anonymen<br />
Authentifizierung durchgeführt wird.<br />
password ist das Kennwort für den angegebenen Benutzernamen. Es ist mit AES verschlüsselt.<br />
logonMethod gibt die Methode an (ClearText, Network, Interactive oder Batch), mit der<br />
der Benutzer angemeldet wird, dessen Identität angenommen wird. (In der Beschreibung<br />
des Elements virtualDirectory im Abschnitt »Definieren und Einschränken des physischen<br />
Pfads« weiter oben in diesem Kapitel wird logonMethod erklärt.)<br />
Wenn Sie für userName und password leere Zeichenfolgen ("") eintragen, greift der anonyme<br />
Benutzer mithilfe des Benutzerkontextes des Anwendungspools auf die Ressourcen zu. Wie<br />
weiter oben beschrieben, ist es für die Entscheidung, ob Sie die Identität des Anwendungspools,<br />
das Standardkonto IUSR oder ein bestimmtes Benutzerkonto verwenden, wichtig,<br />
welche Berechtigungen die Dateien haben, auf die Sie zugreifen wollen, und ob Sie anonyme<br />
Zugriffe zwischen mehreren Sites voneinander trennen müssen.<br />
Standardauthentifizierung<br />
Bei der Standardauthentifizierung muss der Client seinen Benutzernamen und das zugehörige<br />
Kennwort in der HTTP-Anforderung an den <strong>Server</strong> senden. Das Kennwort ist zwar mit<br />
Base64-Kodierung verfremdet, aber das nur, um exotische Zeichen im Kennwort übertragen<br />
zu können. Base64 lässt sich leicht erkennen, daher ist die Standardauthentifizierung gleichzusetzen<br />
mit einer Übertragung Ihrer Anmeldeinformationen über das Internet im Klartext.
Authentifizierung und Autorisierung 487<br />
Sie sollten die Standardauthentifizierung nicht für Websites verwenden, die an das Protokoll<br />
HTTP gebunden sind, weil dann Anmeldeinformationen der Domänenebene im Klartext<br />
zwischen Browser und <strong>Server</strong> übertragen werden. Verwenden Sie HTTPS für alle Seiten,<br />
die Standardauthentifizierung benutzen. Auf Clients innerhalb einer Domäne können Sie<br />
verhindern, dass Standardauthentifizierung vom Internet Explorer in Nicht-HTTPS-Sites<br />
verwendet wird. Dazu können Sie mithilfe von Gruppenrichtlinien den folgenden Registrierungswert<br />
als DWORD mit dem Wert 1 auf den Clientcomputern eintragen:<br />
HKEY_CURRENT_USER\SOFTWARE\Microsoft\<strong>Windows</strong>\CurrentVersion\Internet Settings\<br />
DisableBasicOverClearChannel<br />
Folgende Einstellungen stehen für Standardauthentifizierung unter dem Abschnitt basic-<br />
Authentication in applicationHost.config zur Verfügung:<br />
enabled ist entweder "true" oder "false" und legt fest, ob die Standardauthentifizierung<br />
aktiviert ist.<br />
realm ist normalerweise der Name der Domäne, auf die Sie Benutzer zugreifen lassen.<br />
Das braucht kein echter Domänenname zu sein, es ist einfach der Text, der im Dialogfeld<br />
angezeigt wird, in dem die Benutzer ihre Anmeldeinformationen eingeben.<br />
defaultLogonDomain ist die Domäne, bei der die Authentifizierung durchgeführt wird,<br />
falls der Browser im Benutzernamen keinen Domänennamen übergibt.<br />
logonMethod kann einer der folgende Werte sein (wie bei den anderen logonMethod-<br />
Elementen): ClearText, Network, Interactive oder Batch.<br />
Clientzertifikatzuordnung<br />
Clientzertifikatzuordnung steht nur auf HTTPS-Verbindungen zur Verfügung, weil der<br />
Client dabei Zertifikatinformationen mit dem <strong>Server</strong> austauschen muss, wenn er eine neue<br />
SSL/TLS-Verbindung aufbaut.<br />
Es gibt drei Typen von Clientzertifikatzuordnung: 1:1, 1:n und Active Directory. Alle<br />
Clientzertifikatzuordnungstypen erfordern das Modul CertificateMappingAuthentication-<br />
Module.<br />
1:1-Clientzertifikatzuordnung<br />
Wie der Name andeutet, wird bei der 1:1-Zuordnung jedes Clientzertifikat, das der <strong>Server</strong><br />
als gültig anerkennt, genau einem Benutzerkonto zugeordnet. (Ein Zertifikat ist gültig, wenn<br />
die Zertifikatkette bis zu einer vertrauenswürdigen Stammzertifizierungsstelle führt und das<br />
Zertifikat einem entspricht, das in der Sitekonfiguration angegeben ist.)<br />
Weil das Zertifikat einen eindeutigen Schlüssel für die Liste der Zuordnungen bildet, können<br />
mehrere Zertifikate demselben Benutzerkonto und Kennwort zugeordnet werden. <strong>Die</strong> 1:1-<br />
Clientzertifikatzuordnung wird von der folgenden Konfigurationseinstellung in der XML-<br />
Datei applicationHost.config gesteuert:<br />
<br />
<br />
<br />
<br />
488 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
enabled hat den Wert "true", wenn die Clientzertifikatzuordnung aktiviert ist.<br />
oneToOneCertificateMappingsEnabled hat den Wert "true", wenn die 1:1-Clientzertifikatzuordnung<br />
aktiviert ist.<br />
defaultLogonDomain ist die Domäne, an der sich Benutzer authentifizieren, falls die<br />
Domäne nicht im Element userName angegeben ist.<br />
logonMethod ist die verwendete Anmeldungsmethode.<br />
oneToOneCertificateMappings ist eine Auflistung, die mit einem clear-Element gelöscht<br />
oder mit einem add-Element erweitert werden kann. <strong>Die</strong> Elemente im add-Element sind:<br />
enabled hat den Wert "true", wenn dieses Zertifikat aktiviert ist.<br />
userName ist der Benutzername, dem dieses Zertifikat zugeordnet wird. Wenn Sie die<br />
Authentifizierung an einer anderen Domäne als der durchführen wollen, die im Attribut<br />
defaultLogonDomain angegeben ist, können Sie den userName-Wert als Domäne\<br />
Benutzername angeben.<br />
password ist das Kennwort für den Benutzer in userName (verschlüsselt mit AES).<br />
certificate ist das Zertifikat (Base64-kodiert, wie in einer CER-Datei, aber mit entfernten<br />
Zeilenumbrüchen).<br />
1:n-Clientzertifikatzuordnung<br />
Verwenden Sie die 1:n-Clientzertifikatzuordnung, wenn Sie ein Zertifikat einem Benutzer<br />
anhand bestimmter Kriterien zuordnen wollen, zum Beispiel »Das Zertifikat wurde von der<br />
Contoso-Zertifizierungsstelle ausgestellt«. Weil Sie mehrere Regeln anwenden können, um<br />
zu prüfen, ob ein Clientzertifikat die Kriterien erfüllt, sodass die Anmeldung mit einem<br />
Benutzerkonto erlaubt wird, kann dies eine sehr flexible Technik sein.<br />
<strong>Die</strong> 1:n-Clientzertifikatzuordnung wird von der folgenden Konfigurationseinstellungen<br />
in der XML-Datei applicationHost.config gesteuert:<br />
<br />
<br />
<br />
<br />
<br />
enabled hat den Wert "true", wenn die Clientzertifikatzuordnung aktiviert ist.<br />
manyToOneCertificateMappingsEnabled hat den Wert "true", wenn die 1:n-<br />
Clientzertifikatzuordnung aktiviert ist.<br />
defaultLogonDomain ist die Domäne, an der sich Benutzer authentifizieren, falls die<br />
Domäne nicht im Element userName angegeben ist.<br />
logonMethod ist die verwendete Anmeldungsmethode.<br />
manyToOneCertificateMappings ist eine Auflistung, die mit einem clear-Element gelöscht<br />
oder mit einem add-Element erweitert werden kann. <strong>Die</strong> Elemente im add-Element sind:<br />
name ist der Kurzname, mit dem Sie diesen Regelsatz identifizieren.<br />
description ist eine Beschreibung dieses Regelsatzes.<br />
enabled hat den Wert "true", wenn dieser Regelsatz aktiviert ist.
Authentifizierung und Autorisierung 489<br />
permissionMode hat den Wert "Allow" oder "Deny", um festzulegen, ob Zertifikaten,<br />
die die Kriterien dieses Regelsatzes erfüllen, der Zugriff erlaubt oder verweigert<br />
wird.<br />
userName ist der Benutzername, dessen Identität für den Zugriff angenommen wird,<br />
falls dieser Regelsatz die Kriterien erfüllt und permissionMode den Wert "Allow" hat.<br />
password ist das Kennwort für den Benutzer, dessen Identität angenommen wird.<br />
rules ist eine Auflistung, die mit einem clear-Element gelöscht oder mit einem add-<br />
Element erweitert werden kann. <strong>Die</strong> Elemente im add-Element sind:<br />
certificateField hat entweder den Wert "Subject" oder "Issuer", um festzulegen,<br />
welches Zertifikatfeld untersucht wird.<br />
certificateSubField enthält das Unterfeld des ausgewählten Zertifikatfelds, zum<br />
Beispiel "CN" für Common-Name oder "O" für Organisation.<br />
matchCriteria ist ein Platzhalter, der mit dem Inhalt des angegebenen Zertifikatunterfelds<br />
verglichen wird. "*" stimmt immer überein.<br />
compareCaseSensitive hat den Wert "true", wenn beim Vergleich in matchCriteria<br />
zwischen Groß- und Kleinschreibung unterschieden wird. »Contoso« stimmt<br />
dann also nicht mit »contoso« überein. Wenn dieses Attribut den Wert "false"<br />
hat, wird beim Vergleich nicht zwischen Groß- und Kleinschreibung unterschieden.<br />
Active Directory-Clientzertifikatzuordnung<br />
Falls die Benutzer in Ihrer Organisation bereits Clientzertifikate mit ihren Benutzerkonten in<br />
Active Directory verknüpft haben, können Sie die Active Directory-Clientzertifikatzuordnung<br />
einsetzen, um sie zu authentifizieren, wenn sie sich anmelden. <strong>Die</strong> recht simple Konfigurationseinstellung<br />
für die Active Directory-Clientzertifikatzuordnung befindet sich in der<br />
Datei applicationHost.config im folgenden Abschnitt:<br />
<br />
<br />
<br />
<br />
<br />
Sie besteht aus einem einzigen Element, enabled, dessen Wert "true" oder "false" sein<br />
kann.<br />
Hinweis Andere Clientzertifikatzuordnungstypen liegen unter einem XML-Pfad, der mit iisClientCertificateMapping<br />
endet. Der XML-Pfad der Active Directory-Clientzertifikatzuordnung endet dagegen mit<br />
clientCertificateMapping.<br />
Wenn die Active Directory-Clientzertifikatzuordnung aktiviert ist, werden die Zertifikatinformationen<br />
des Clients in Active Directory gesucht und der Benutzer, der von diesem<br />
Zertifikat identifiziert wird, ist der Benutzer, unter dem der Zugriff gewährt wird. Der<br />
Zugriff wird verweigert, falls das Zertifikat des Clients nicht gefunden wird.
490 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
Digestauthentifizierung<br />
Bei der Digestauthentifizierung stellt der Client einen Benutzernamen sowie einen Hashwert<br />
bereit, der aus dem Kennwort des Benutzers und einigen zufälligen Daten generiert wird.<br />
Wie die Standardauthentifizierung wird die Digestauthentifizierung von vielen Browsern<br />
unterstützt und ist in RFC 2617 (Request für Comment) als Internetstandard definiert. Der<br />
Standard legt fest, wie der Hashwert aus dem Kennwort und zufälligen Daten (die sogenannte<br />
Nonce) generiert wird. Der Nonce-Wert wird dabei in der Frage angegeben, die der <strong>Server</strong><br />
als Antwort auf die anfängliche anonyme Anforderung des Clients zurücksendet.<br />
Weil das Kennwort bei dieser Authentifizierungsmethode nicht gesendet wird und die Nonce<br />
Schutz gegen Replay-Angriffe bietet, ist die Digestauthentifizierungsmethode der weiter<br />
oben beschriebenen Standardauthentifizierungsmethode vorzuziehen.<br />
Sie können die Digestauthentifizierung leicht über die Benutzeroberfläche aktivieren, wenn<br />
Sie das Modul DigestAuthenticationModule aktiviert haben. Der einzige Konfigurationsparameter<br />
für Digestauthentifizierung ist realm. <strong>Die</strong>s ist der Text, der dem Client in der Eingabeaufforderung<br />
angezeigt wird, wenn er nach Benutzername und Kennwort gefragt wird.<br />
Beachten Sie, dass dieser realm-Wert dem Domänennamen entsprechen soll, in dem die<br />
Kennwörter der Benutzer überprüft werden.<br />
<strong>Die</strong> Konfiguration für Digestauthentifizierung liegt im folgenden Abschnitt der XML-Datei<br />
applicationHost.config:<br />
<br />
<br />
<br />
<br />
<br />
In diesem Abschnitt gibt es zwei Elemente:<br />
enabled hat den Wert "true", wenn die Digestauthentifizierung aktiviert ist, andernfalls<br />
"false".<br />
realm ist der Name des Bereichs, nach dem in der Eingabeaufforderung des Clients gefragt<br />
wird. <strong>Die</strong>s muss dem Domänennamen entsprechen, damit der Digest generiert werden<br />
kann, der dem auf dem Domänencontroller gespeicherten Hashwert entspricht.<br />
Weitere Informationen über Digestauthentifizierung finden Sie in Kapitel 4, »Grundlagen<br />
der Benutzerkontensteuerung«.<br />
ASP.NET-Identitätswechsel<br />
ASP.NET-Identitätswechsel ist eine Möglichkeit, die Authentifizierung zu nutzen, die in<br />
einer Verbindung zu einer ASP.NET-Anwendung vorhanden ist. Wenn ASP.NET-Identitätswechsel<br />
deaktiviert ist, läuft eine ASP.NET-Anwendung im selben Benutzerkontext wie ihr<br />
Anwendungspool. Wenn Sie ASP.NET-Identitätswechsel aktivieren, können Sie entweder<br />
festlegen, dass immer die Identität eines bestimmten Benutzerkontextes angenommen wird<br />
oder die Identität des <strong>Windows</strong>-Benutzers, der authentifiziert wurde (über Standardauthentifizierung,<br />
Digest, Clientzertifikat oder sogar anonyme Authentifizierung).<br />
Sie können ASP.NET-Identitätswechsel aktivieren und konfigurieren, indem Sie das Element<br />
im folgenden Abschnitt der Web.config-Datei von Anwendung oder Website editieren:
<br />
<br />
Authentifizierung und Autorisierung 491<br />
<strong>Die</strong>ses Element hat ein erforderliches Attribut, impersonate. Setzen Sie dieses Attribut auf<br />
"true", um den ASP.NET-Identitätswechsel zu aktivieren, oder auf "false" (Standardwert),<br />
um ihn zu deaktivieren.<br />
<strong>Die</strong> folgenden optionalen Attribute können Sie verwenden, wenn Sie wollen, dass die Anwendung<br />
immer die Identität eines bestimmten Benutzers annimmt:<br />
userName ist der Name des Benutzers, dessen Identität angenommen wird.<br />
password ist das verschlüsselte Kennwort.<br />
Formularauthentifizierung<br />
Formularauthentifizierung erlaubt der Website, die Schnittstelle zu steuern, die der Benutzer<br />
zum Eingeben der Anmeldeinformationen angezeigt bekommt, statt es (wie bei Standardauthentifizierung<br />
und Digestauthentifizierung) dem Browser zu überlassen, das Anmeldedialogfeld<br />
anzuzeigen. Ein Zugriff auf eine Seite, die Formularauthentifizierung erfordert,<br />
wird anfangs auf eine Anmeldeseite umgeleitet, normalerweise ein Webformular, wo die<br />
Anmeldeinformationen eingegeben werden können. Falls der <strong>Server</strong> die Anmeldeinformationen<br />
als gültig anerkennt, wird im Browser ein Cookie gesetzt und der Browser wird<br />
zurück auf die Seite geleitet, die er ursprünglich angefordert hat. Wenn das Cookie richtig<br />
gesetzt ist, wird die Seite angezeigt, die durch Formularauthentifizierung geschützt ist.<br />
Eine Beispielanmeldeseite und der zugehörige Code wird an vielen Stellen angeboten, zum<br />
Beispiel unter http://support.microsoft.com/kb/301240.<br />
<strong>Die</strong> Konfiguration für die Formularauthentifizierung ist in der Web.config-Datei der Website<br />
oder des virtuellen Verzeichnisses unter dem folgenden Abschnitt gespeichert:<br />
<br />
<br />
<br />
<br />
Das Element authentication sollte das Attribut mode mit dem Wert "Forms" enthalten. Falls<br />
Sie nicht die Standardwerte verwenden, müssen Sie ein forms-Attribut unter dem authentication-Element<br />
einfügen, das folgende Attribute hat:<br />
cookieless hat den Standardwert "UseDeviceProfile" (Authentifizierungsinformationen<br />
werden in Cookies gespeichert, wenn bekannt ist, dass der Browser sie unterstützt, andernfalls<br />
in den URIs). Andere mögliche Werte sind "UseCookies" (Authentifizierungsinformationen<br />
werden immer in Cookies gespeichert), "UseUri" (Authentifizierungsinformationen<br />
werden immer in der URI gespeichert) und "AutoDetect" (der Browser<br />
wird untersucht, um festzustellen welche Möglichkeit genutzt werden kann).<br />
loginUrl hat den Standardwert "login.aspx". <strong>Die</strong>s ist eine URL relativ zur Ebene, auf<br />
der Sie die Authentifizierungskonfiguration festlegen, zu der der Browser umgeleitet<br />
wird, um die Anmeldeinformationen einzugeben.<br />
name hat den Standardwert ".ASPXAUTH". <strong>Die</strong>s ist der Name des Cookies (oder der URI-<br />
Komponente), das nach Authentifizierungsinformationen abgefragt wird.
492 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
protection hat den Standardwert "All". Es kann auf "None", "Encryption" oder "Validation"<br />
gesetzt sein. "Encryption" bedeutet, dass das Cookie mit dem Computerschlüssel<br />
des Webservers verschlüsselt wird; "Validation" fügt einen Überprüfungscode zum<br />
Cookie hinzu, um sicherzustellen, dass es auf dem Client nicht manipuliert wird. "All"<br />
legt fest, dass Verschlüsselung und Überprüfung durchgeführt werden.<br />
requireSSL hat den Standardwert "false". Falls es auf "true" gesetzt wird, wird das Authentifizierungscookie<br />
als sicher markiert, sodass ein kompatibler Browser es nur über<br />
eine HTTPS-Verbindung sendet. Wenn Sie dieses Attribut auf "true" setzen, wird der<br />
Browser dadurch nicht gezwungen, SSL zu benutzen, um das Formular mit Benutzername<br />
und Kennwort zu übertragen. Das müssen Sie im Rahmen Ihrer Anmeldeseite konfigurieren.<br />
slidingExpiration hat den Standardwert "true". Wenn Sie dieses Attribut auf "true"<br />
setzen, wird die Gültigkeitsdauer des Cookies bei jeder Benutzung des Cookies auf den<br />
ursprünglichen Wert zurückgesetzt. Wenn Sie dieses Attribut auf "false" setzen, legt die<br />
ursprüngliche Gültigkeitsdauer fest, wie lange der Browser die authentifizierte Verbindung<br />
offen halten kann, ohne sich erneut zu authentifizieren.<br />
timeout hat den Standardwert "30". <strong>Die</strong>s gibt an, nach wie vielen Minuten das Cookie<br />
ungültig wird und die Authentifizierung erneut durchgeführt werden muss, um weiter<br />
auf die Ressource zugreifen zu können.<br />
<strong>Windows</strong>-Authentifizierung<br />
<strong>Windows</strong>-Authentifizierung ist eine bequeme und sichere Methode, Benutzer in einer<br />
Domänenumgebung zu authentifizieren. Wenn ein Client die <strong>Windows</strong>-Authentifizierung<br />
nutzt, authentifiziert er sich beim Webserver über dieselben Protokolle (NTLM und Kerberos),<br />
die auch bei der <strong>Windows</strong>-Anmeldung eingesetzt werden. (Kapitel 4 enthält weitere<br />
Informationen über diese Protokolle.) <strong>Die</strong>se Möglichkeit wird unter Umständen nicht von<br />
allen Browsern in einer heterogenen Umgebung unterstützt, aber ihr Komfort, die Einfachheit<br />
und <strong>Sicherheit</strong> machen sie zu einer vernünftigen Option für die Authentifizierung.<br />
<strong>Die</strong> Konfiguration für die <strong>Windows</strong>-Authentifizierung ist in der Web.config-Datei der Website<br />
oder des virtuellen Verzeichnisses unter dem folgenden Abschnitt gespeichert:<br />
<br />
<br />
<br />
Das Element authentication sollte das Attribut mode mit dem Wert "<strong>Windows</strong>" enthalten.<br />
<strong>Die</strong>se Einstellung hat mehrere Konfigurationsattribute unter dem folgenden Abschnitt:<br />
<br />
<br />
<br />
<br />
<br />
<strong>Die</strong> Attribute sind:<br />
enabled können Sie auf "false" setzen, um die <strong>Windows</strong>-Authentifizierung zu deaktivieren,<br />
oder auf "true", um sie zu aktivieren.
Authentifizierung und Autorisierung 493<br />
authPersistSingleRequest können Sie auf "false" (Standardwert) setzen, um die Authentifizierung<br />
über mehrere Anforderungen innerhalb einer einzigen Sitzung aufrechtzuerhalten.<br />
Ist es auf "true" gesetzt, ist bei jeder Anforderung eine erneute Authentifizierung<br />
erforderlich, sogar innerhalb derselben Browsersitzung. Wenn Sie dieses Attribut<br />
auf irgendeinen anderen Wert als die Standardeinstellung "false" setzen, produzieren Sie<br />
damit im Allgemeinen mehr Verärgerung als <strong>Sicherheit</strong>.<br />
authPersistNonNTLM können Sie auf "false" (Standardwert) setzen, um Nicht-NTLM-<br />
Token (zum Beispiel Kerberos) über mehrere aufeinanderfolgende Anforderungen<br />
innerhalb derselben Sitzung beizubehalten. Mit "true" ist bei jeder Anforderung eine<br />
erneute Authentifizierung notwendig.<br />
useKernelMode können Sie auf "true" (Standardwert) setzen, falls die Authentifizierung<br />
im Kernmodus ausgeführt werden soll, andernfalls auf "false".<br />
providers ist eine Auflistung, in der Sie Elemente hinzufügen, einzelne Elemente oder<br />
alle Elemente löschen können. Jedes Element in der Auflistung hat ein Attribut namens<br />
value, das die Zeichenfolge "Kerberos" oder "NTLM" haben kann. <strong>Die</strong>s ist die Liste der<br />
Anbieter, die benutzt werden, um Protokolle mit dem Client auszuhandeln.<br />
Dem <strong>Server</strong> vertrauen<br />
Wir haben jetzt verschiedene Möglichkeiten beschrieben, wie der <strong>Server</strong> den Clientbrowser<br />
und den Benutzer, der daran angeblich arbeitet, identifizieren (und somit unter Umständen<br />
vertrauen) kann. Da ist es nur fair, dass wir uns auch ansehen, wie der Benutzer am anderen<br />
Ende des Clientbrowsers feststellen kann, ob Ihr <strong>Server</strong> sein Vertrauen verdient.<br />
Wer wurde zum Beispiel noch nie von seiner Bank angerufen? »Herr Mustermann, hier ist<br />
die Contoso-Bank. Ich rufe an wegen einer Abbuchung, die gerade von Ihrer Kreditkarte<br />
vorgenommen wurde.« Sind Sie sicher, dass die Person, die Sie anruft, tatsächlich bei Ihrer<br />
Bank arbeitet? Wenn Sie die Bank anrufen, wie können Sie dann sicher sein, dass Sie mit<br />
der richtigen Nummer verbunden sind? Was ist, wenn Sie sich verwählt haben oder Ihr Telefongespräch<br />
umgeleitet wurde?<br />
In der realen Welt haben wir nur wenige, oft gar keine Lösungen zur Verfügung, um dieses<br />
Problem zu lösen. Glücklicherweise ist es in der Welt des Webs mithilfe von SSL (Secure<br />
Sockets Layer) und TLS (Secure Sockets Layer) möglich, die Organisation zu identifizieren,<br />
mit der Sie tatsächlich verbunden sind.<br />
Hinweis Sie fragen sich möglicherweise, wo der Unterschied zwischen SSL und TLS liegt. TLS ist ein<br />
Nachfolger von SSL, der nicht nur einige Bugs beseitigt, sondern das Protokoll auch aus dem proprietären<br />
Status herausholt und zu einem vollständig öffentlichen und veröffentlichten IETF-Standard macht. Aus<br />
Gründen der Bequemlichkeit fasse ich beide im Folgenden unter der Bezeichnung SSL zusammen, was<br />
auch allgemein üblich ist.<br />
SSL stellt einige grundlegende Anforderungen, die in praktisch allen Umgebungen erfüllt<br />
werden, sofern sie keine völlig absurde <strong>Sicherheit</strong>skonfiguration haben:<br />
SSL-Verkehr wird verschlüsselt und führt eine Integritätsprüfung aus.<br />
Eine SSL-Verbindung verwendet Zertifikate (siehe Kapitel 10, »Implementieren der<br />
Active Directory-Zertifikatdienste«), um den <strong>Server</strong> gegenüber dem Client eindeutig zu<br />
identifizieren.
494 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
Wie wir weiter unten in diesem Kapitel noch sehen werden, können Sie andere Optionen auf<br />
SSL-Verkehr anwenden, mit denen der Client authentifiziert wird.<br />
<strong>Die</strong> erste Anforderung, dass SSL-Verkehr verschlüsselt ist und eine Integritätsprüfung durchgeführt<br />
wird, stellt sicher, dass die Kommunikation auf dem Weg zwischen Client und <strong>Server</strong><br />
nicht von jemand anders gelesen oder geändert wurde, sofern die Kommunikation zwischen<br />
Client und <strong>Server</strong> vollständig abgeschlossen wird.<br />
<strong>Die</strong> zweite Anforderung, dass die SSL-Verbindung den <strong>Server</strong> gegenüber dem Client eindeutig<br />
identifiziert, ist ein wichtiges Element, damit der Client der Kommunikation mit dem<br />
<strong>Server</strong> vertrauen kann.<br />
Konfigurieren von SSL<br />
Wenn Sie ein <strong>Server</strong>zertifikat für SSL im lokalen Computerzertifikatspeicher haben, ist es<br />
ganz einfach, SSL-Unterstützung für IIS hinzuzufügen: Fügen Sie einfach eine Bindung für<br />
https hinzu und wählen Sie das <strong>Server</strong>zertifikat aus. Markieren Sie dazu erst die Website, die<br />
Sie konfigurieren wollen, und wählen Sie den Befehl Bindungen bearbeiten, entweder im<br />
Kontextmenü der Website, indem Sie mit der rechten Maustaste auf die Website klicken,<br />
oder im Fensterabschnitt Aktionen. Daraufhin öffnet sich das Dialogfeld Sitebindungen. Weil<br />
Sie HTTPS-Unterstützung für diese Site wollen, klicken Sie auf die Schaltfläche Hinzufügen.<br />
Wählen Sie dann im Dialogfeld Sitebindung hinzufügen in der Dropdownliste Typ den Eintrag<br />
https aus. Daraufhin wird die Dropdownliste SSL-Zertifikat aktiviert (Abbildung 17.9).<br />
<strong>Die</strong>se Liste enthält alle <strong>Server</strong>zertifikate, die im lokalen Computerspeicher installiert sind.<br />
Abbildung 17.9 Das Dialogfeld Sitebindung hinzufügen zeigt<br />
die verfügbaren Zertifikate an<br />
Etwas schwieriger ist es, eine Bindung für eine SSL-Verbindung hinzuzufügen, ohne die<br />
grafische Benutzeroberfläche zu verwenden. Schlimm ist es aber auch nicht: <strong>Die</strong> Konfiguration<br />
wurde einfacher und weniger fehlerträchtig als in den IIS-Vorgängerversionen. Erst<br />
müssen Sie eine Bindung zur XML-Konfiguration für die Site hinzufügen, wie im Abschnitt<br />
»Hostheadersicherheit« weiter oben in diesem Kapitel beschrieben. Noch einmal kurz<br />
zusammengefasst: <strong>Die</strong> Bindungseinstellung für eine HTTPS-Standardbindung auf Port 443<br />
(dem Standardport für HTTPS) für alle IP-Adressen lautet:<br />
Authentifizierung und Autorisierung 495<br />
Wenn die Bindung vorhanden ist, müssen Sie das Zertifikat zur Konfiguration des<br />
HTTP.SYS-Treibers hinzufügen. Geben Sie dazu den folgenden netsh-Befehl ein:<br />
netsh http add sslcert ipport=0.0.0.0:443 certhash=Fingerabdruck appid={4dc3e181-e14b-4a21-<br />
b022-59fc669b0914}<br />
Der ipport-Wert 0.0.0.0:443 stimmt mit der Bindung *:443: überein.<br />
thumbprint muss den Hexadezimalwert für den Fingerabdruck des Zertifikats angeben.<br />
<strong>Die</strong>sen Fingerabdruck können Sie sich in den Eigenschaften des Zertifikats im Snap-In<br />
Zertifikate ansehen.<br />
Der HTTP.SYS-Treiber greift nur auf Zertifikate im lokalen Computerzertifikatspeicher zu.<br />
Wenn Sie Ihr Zertifikat importieren, sollten Sie das in einem Zertifikate-Snap-In tun, das Sie<br />
für den Gültigkeitsbereich des lokalen Computerkontos geöffnet haben.<br />
Wenn Sie Ihr Zertifikat anfordern und die Verbindung zum HTTPS-<strong>Server</strong> testen, dürfen Sie<br />
nicht vergessen, dass Webbrowser so konfiguriert sind, dass sie den Namen, der in der URL<br />
angegeben ist, mit dem Namen im Zertifikat vergleichen. Wenn Sie ein Zertifikat von Ihrem<br />
Zertifikatanbieter anfordern, müssen Sie dabei also einen Namen angeben, der dem vollqualifizierten<br />
Domänennamen entspricht, unter dem Sie das Zertifikat bereitstellen wollen.<br />
Das bedeutet letztlich, dass Sie ein Zertifikat nicht für die Internet- und Intranetanschlüsse<br />
eines Webservers gleichzeitig verwenden können. Und wenn Sie bei Tests mithilfe von localhost<br />
oder einer IP-Adresse eine Verbindung zu Ihrem Webserver herstellen, bekommen Sie<br />
einen Zertifikatfehler gemeldet, weil der Name des Zertifikats sich nicht mit dem Namen der<br />
Site deckt, zu der Sie eine Verbindung herstellen .<br />
Weitere <strong>Sicherheit</strong>saspekte für IIS<br />
Authentifizierung und Autorisierung sind die wichtigsten Elemente beim Schützen einer<br />
Website, aber damit sind Sie noch lange nicht fertig. Sie müssen noch sicherstellen, dass es<br />
keine versehentlichen Möglichkeiten gibt, aus den <strong>Sicherheit</strong>smechanismen auszubrechen,<br />
die Sie angewendet haben.<br />
Anwendungsentwicklung<br />
Wenn Sie Anwendungen für IIS entwickeln (etwa ISAPI-Module oder ASP.NET-Anwendungen),<br />
sollten Sie immer daran denken, dass Sie nur etwa die Hälfte der Software selbst<br />
schreiben. <strong>Die</strong> andere Hälfte ist der Teil, der auf dem Client läuft. Und dieser Teil wird unter<br />
Umständen von jemand anders geschrieben, dessen einziges Ziel darin besteht, Ihrem <strong>Server</strong><br />
Schaden zuzufügen.<br />
Entwickler sollten die Richtlinien für sichere Entwicklung kennen und sich daran halten.<br />
Solche Richtlinien finden Sie zum Beispiel in Writing Secure Code, 2nd Edition von Michael<br />
Howard und David LeBlanc (Microsoft Press, 2004).<br />
Anforderungsfilterung<br />
In IIS 6.0 wurde das Tool URLScan intensiv genutzt, um sicherzustellen, dass die an den<br />
Webserver übergebenen URLs einer Reihe von Regeln gehorchten, um Angriffe abzuwehren.<br />
In IIS 7.0 steht dieselbe Funktionalität über die Konfigurationseinstellung requestFiltering<br />
zur Verfügung. Momentan gibt es für diese Einstellungen keine grafische Benutzeroberfläche,<br />
aber Sie können sie unter dem folgenden Abschnitt der XML-Datei application-<br />
Host.config konfigurieren:
496 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
<br />
<br />
<br />
<br />
<strong>Die</strong> Einstellungen in diesem Konfigurationspfad gelten für HTTP- und HTTPS-Anforderungen.<br />
Außerdem kann konfiguriert werden, dass sie auch auf WebDAV-Anforderungen<br />
angewendet werden. <strong>Die</strong>se Einstellungen sind:<br />
allowDoubleEscaping dekodiert bei der Standardeinstellung "false" angeforderte URLs<br />
zweimal hintereinander. Falls die erste Dekodierung ein anderes Ergebnis bringt als die<br />
zweite, wird die Anforderung zurückgewiesen. Setzen Sie diese Einstellung auf "true",<br />
falls Sie dieses Feature deaktivieren möchten.<br />
allowHighBitCharacters können Sie auf "true" (Standardwert) setzen, falls Ihre URLs<br />
Zeichen aus dem ASCII-Bereich 127-255 verwenden, oder auf "false", um Anforderungen<br />
abzuweisen, die Zeichen aus diesem Bereich enthalten. <strong>Die</strong> meisten dieser Zeichen<br />
sind grafische oder Akzentzeichen aus diversen internationalen Zeichensätzen. In einer<br />
rein englischsprachigen Umgebung dürfte es kaum vorkommen, dass normale Anforderungen<br />
an Ihre Site Zeichen aus diesem Bereich verwenden. Indem Sie solche Anforderungen<br />
abweisen, verhindern Sie möglicherweise einen Angriff auf Ihre Site. Auch<br />
in einer internationalen Umgebung enthalten URLs meist nur Zeichen aus dem Bereich<br />
32 bis 127. Auch hier ist es daher oft sinnvoll, Zeichen aus dem oberen Bereich zu verbieten.<br />
fileExtensions ist eine Auflistung, die ein <strong>Server</strong>administrator verwalten kann, indem er<br />
Elemente hinzufügt, löscht oder die ganze Liste löscht. <strong>Die</strong> fileExtensions-Auflistung<br />
hat zwei Attribute:<br />
allowUnlisted können Sie auf "true" (Standardwert) setzen, wenn die Dateierweiterungsliste<br />
die »gefährlichen« Dateierweiterungen beschreibt, die Benutzer nicht anfordern<br />
dürfen. Wenn es den Wert "false" hat, wird alles außer den aufgeführten<br />
Dateierweiterungen abgewiesen. Es ist im Allgemeinen sinnvoll, die zweite Möglichkeit<br />
zu wählen, daher empfehlen wir, diese Einstellung auf "false" zu setzen und<br />
eine Liste der Erweiterungen zusammenzustellen, die Ihr <strong>Server</strong> Benutzern zur Verfügung<br />
stellen soll.<br />
applyToWebDAV können Sie auf "true" (Standardwert) setzen, damit diese Liste auf<br />
WebDAV-Anforderungen angewendet wird, die bei diesem <strong>Server</strong> eingehen. Wenn<br />
der Wert "false" ist, wird diese Liste nur auf Webanforderungen angefordert.<br />
Elemente, die zu dieser Auflistung hinzugefügt werden, haben zwei Attribute:<br />
fileExtension ist das wichtigste Attribut für Elemente in dieser Auflistung. Es gibt<br />
die Dateierweiterung an, die Sie erlauben oder verbieten.<br />
allowed können Sie auf "true" (Standardwert) setzen, um Anforderungen nach<br />
Dateien mit dieser Erweiterung zu erlauben, oder auf "false", um solche Anforderungen<br />
zu verbieten.<br />
requestLimits ist ein Element, das verschiedene Limits für die Anforderungen der<br />
Clients festlegt. Es hat folgende Attribute:<br />
maxAllowedContentLength ist die maximale Länge des Inhalts (in der Einheit Byte),<br />
der angefordert werden kann. Das verhindert die Möglichkeit, dass eine Anforderung
Authentifizierung und Autorisierung 497<br />
so große Ausgaben generiert, dass sie entweder Ihren <strong>Server</strong> oder einen Clientcomputer<br />
überfordert. Der Standardwert ist 30.000.000.<br />
maxURL ist die maximale Größe der URL (in der Einheit Byte), die an die Anwendung<br />
übergeben wird. Das verhindert Pufferüberläufe in IIS oder seinen gehosteten Anwendungen,<br />
wenn ein Client in böser Absicht sehr lange URLs sendet. Standardwert<br />
ist 4096.<br />
maxQueryString ist die maximale Größe (in der Einheit Byte) eines Abfragestrings,<br />
also des Teils einer URL, der hinter dem Fragezeichen (?) beginnt. Standardwert ist<br />
2048.<br />
headerLimits ist eine Auflistung, deren Elemente zwei Attribute haben: header und<br />
sizeLimit. Das Attribut header ist der Name des HTTP-Anforderungsheaders, der<br />
eingeschränkt wird, und sizeLimit ist die maximale Größe des Headers (in Byte), der<br />
übergeben werden kann.<br />
verbs ist eine Auflistung von HTTP-Anforderungsverben, die erlaubt oder abgewiesen<br />
werden. <strong>Die</strong> Attribute für ein verbs-Element sind:<br />
allowUnlisted können Sie auf "true" (Standardwert) setzen, um andere HTTP-<br />
Befehlsverben zu erlauben als die, die als verweigert aufgelistet werden. Mit "false"<br />
erlauben Sie nur die HTTP-Befehlsverben, die explizit aufgelistet werden.<br />
applyToWebDAV können Sie auf "true" (Standardwert) setzen, um die Auflage bezüglich<br />
der Verben auch auf WebDAV anzuwenden.<br />
Verben können in dieser Auflistung hinzugefügt, gelöscht und komplett gelöscht werden.<br />
Jedes Element in der verbs-Auflistung hat zwei Elemente:<br />
verb ist der Name des beschriebenen Verbs. Das am häufigsten verwendete Verb ist<br />
GET, das Sie praktisch immer erlauben. Damit Formulare funktionieren, müssen Sie<br />
normalerweise auch POST erlauben. Eine Liste häufig benutzter Anwendungen und<br />
der erforderlichen Verben finden Sie unter http://support.microsoft.com/kb/823175.<br />
allowed hat den Wert "true" (Standardwert), falls Sie dieses Verb erlauben. Bei<br />
"false" wird es zurückgewiesen.<br />
hiddenSegments ist eine Auflistung mit Elementen, die zurückgewiesen werden, falls sie<br />
in einem Segment einer angeforderten URL vorkommen. Jedes Element in dieser Auflistung<br />
enthält nur ein Attribut, segment. Sein Wert ist eine Zeichenfolge, die das blockierte<br />
Segment angibt. Falls zum Beispiel ein Segment "bin" lautet, blockiert es Anforderungen<br />
nach http://example.com/bin/scanme.pl, aber nicht die Anforderung http://example.<br />
com/rubbish-bin/image.jpg. Sie können die hiddenSegments-Auflistung auch auf Web-<br />
DAV anwenden, indem Sie das applytoWebDAV-Attribut entsprechend konfigurieren.<br />
denyUrlSequences ist eine Auflistung mit Zeichensequenzen, die zurückgewiesen werden,<br />
falls sie in einer angeforderten URL vorkommen. Sehr oft wird ".." in diese Auflistung<br />
eingefügt, um zu verhindern, dass im Verzeichnis nach oben navigiert werden kann.<br />
Elemente, die zu dieser Auflistung hinzugefügt werden, haben ein Attribut, sequence.<br />
<strong>Die</strong>s ist die Zeichenfolge, die dazu führt, dass die URL zurückgewiesen wird, falls diese<br />
Zeichenfolge irgendwo darin vorkommt.<br />
Ein recht einfaches Beispiel ist der folgende XML-Ausschnitt, der doppelte Escapezeichen<br />
und Zeichen verbietet, bei denen das oberste Bit gesetzt ist, nur die Dateierweiterungen<br />
.html, .htm, .aspx und .mspx erlaubt, weit kürzere Längenlimits für Inhalt, URL und Abfra-
498 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
gestring einstellt, dem <strong>Server</strong> die Verwendung anderer Verben als GET und POST verbietet und<br />
alle URLs blockiert, die »/../« oder »...« enthalten:<br />
<br />
...<br />
<br />
<br />
Authentifizierung und Autorisierung 499<br />
ungültig, sofern die zwei <strong>Server</strong> nicht denselben Verschlüsselungsschlüssel verwenden. In<br />
der Standardeinstellung werden ASP.NET-Computerschlüssel automatisch generiert, wenn<br />
die Anwendung startet, und jede Anwendung bekommt ihren eigenen Computerschlüssel<br />
(sodass eine Anwendung in einer gemeinsam genutzten Hostingumgebung nicht versehentlich<br />
auf den Sitzungszustand einer anderen Anwendung zugreift).<br />
In einer <strong>Server</strong>farmumgebung muss der Computerschlüssel also gemeinsam genutzt werden.<br />
Das wird mithilfe des ASP-NET-Features Computerschlüssel möglich. Dort müssen Sie das<br />
Kontrollkästchen Automatisch zur Laufzeit generieren deaktivieren. Auf einem Computer<br />
in Ihrer <strong>Server</strong>farm klicken Sie dann auf Schlüssel generieren, um einen neuen, zufälligen<br />
Computerschlüssel in die Felder für Entschlüsselungs- und Validierungsschlüssel einzutragen.<br />
Sie können diese Schlüsseleinstellungen dann auf die anderen Computer in Ihrer<br />
<strong>Server</strong>farm kopieren.<br />
Falls Sie eine große <strong>Server</strong>farm verwalten oder häufig Ihre Computerschlüssel wechseln,<br />
sollten Sie dieses Feature automatisieren. Dafür können Sie WMI verwenden oder direkt die<br />
Web.config-Datei der Website verändern, wie im folgenden Beispiel gezeigt. Der Validierungsschlüssel<br />
sollte ein zufällig generierter, 40 bis 128 Zeichen langer Hexadezimalstring<br />
sein, der eine 20 bis 64 Byte lange Zufallssequenz angibt. Der Entschlüsselungsschlüssel<br />
sollte ein hexadezimaler String mit 16 Zeichen Länge sein, wenn DES-Verschlüsselung<br />
verwendet wird, oder mit 48 Zeichen Länge, wenn Triple-DES-Verschlüsselung eingesetzt<br />
wird.<br />
<br />
<br />
<br />
Falls bei den Benutzern sporadisch der Sitzungszustand verloren zu gehen scheint, sollten<br />
Sie prüfen, ob die Computerschlüssel für die betroffene Anwendung auf allen Ihren <strong>Server</strong>n<br />
denselben Wert haben. Falls ein <strong>Server</strong> einen anderen Computerschlüssel hat, kann der Sitzungszustand<br />
eines Benutzers, der von einem anderen <strong>Server</strong> stammt, nicht vom zweiten<br />
<strong>Server</strong> gelesen werden (und umgekehrt). Alle <strong>Server</strong> müssen denselben Computerschlüssel<br />
haben, damit der Sitzungszustand in allen <strong>Server</strong>n der Farm zur Verfügung steht.<br />
Benutzerdefinierte Fehler<br />
Benutzerdefinierte Fehlerseiten sind ein zweischneidiges Schwert. Einerseits sind sie ein<br />
wertvolles Debuggingtool für die Problembehandlung, weil sie dem Clientbrowser mehr<br />
Informationen über die Probleme in der Anwendung liefern. Manche benutzerdefinierten<br />
Fehlerseiten geben aber kritische Informationen heraus, und hier liegt das <strong>Sicherheit</strong>sproblem.<br />
Prüfen Sie die benutzerdefinierten Fehlerseiten, die auf Ihren Sites verwendet werden.<br />
In der Standardeinstellung liegen sie in %SystemDrive%\inetpub\custerr\\<br />
.htm. Zum Beispiel liegt in einer deutschsprachigen Umgebung in einer Standardinstallation<br />
auf dem Laufwerk C: die Fehlerseite für einen benutzerdefinierten 401-<br />
Fehler unter C:\inetpub\custerr\de-DE\401.htm. <strong>Die</strong>se benutzerdefinierten Standardfehlerseiten<br />
sind relativ simpel und geben nur den Fehlercode an, eine kurze Beschreibung und<br />
eine allgemeine Erklärung, welches die Ursachen für den Fehler sein könnten. Wir empfehlen,<br />
diese Standardfehlerseiten zu verwenden, die keine detaillierten Informationen liefern.<br />
Für geschützte Umgebungen sollten Sie die Standardfehlermeldungen durch eine allgemeine
500 Kapitel 17: Schützen von <strong>Server</strong>anwendungen<br />
»Ein Fehler ist aufgetreten«-Seite ersetzen. Falls Code die Produktivumgebung erreicht,<br />
der solche Fehler generiert, kann er auf einem Computer ohne benutzerdefinierte Fehlermeldungen<br />
getestet werden. Abenteuerliche Naturen können die Seiten so ändern, dass sie ASP,<br />
ASP.NET oder andere serverseitige Programme nutzen, um nur dann Fehlerdetails auszugeben,<br />
wenn die Client-IP zu einer ausgewählten Gruppe von IPs gehört.<br />
FTP-<strong>Server</strong><br />
Der FTP-<strong>Server</strong>, der in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> enthalten ist, ist im Wesentlichen derselbe<br />
FTP-<strong>Server</strong> wie in IIS 6.0. Der neue FTP-<strong>Server</strong> für IIS 7.0 wurde bis zum Veröffentlichungstermin<br />
nicht ganz fertig. Er stellt aber einige <strong>Sicherheit</strong>sfeatures zur Verfügung, die seit<br />
Langem vermisst wurden. Wenn Sie also FTP-<strong>Server</strong> in Ihrem Unternehmen einsetzen und<br />
IIS7 bereitstellen, sollten Sie prüfen, ob Sie das FTP-<strong>Server</strong>-Add-On herunterladen sollten<br />
(Details dazu unter http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Using-FTP-<br />
<strong>Server</strong>-in-IIS7/Installing-and-Troubleshooting-FTP7). Falls Sie FTP einsetzen, um Ihre<br />
Website zu veröffentlichen, werden Sie sich zweifellos freuen, dass die FTP-Site ganz einfach<br />
in die Website eingebunden werden kann, genau wie beim Hinzufügen einer beliebigen<br />
anderen Bindung.<br />
Weitere neue FTP-Features sind:<br />
UTF-8-Unterstützung für Zeichensätze außerhalb von ASCII<br />
FTP über SSL/TLS (im Allgemeinen als FTPS abgekürzt, nicht zu verwechseln mit<br />
SFTP, das kein FTP-basiertes Protokoll ist) für verbesserte <strong>Sicherheit</strong>, inklusive Verschlüsselung<br />
und <strong>Server</strong>authentifizierung<br />
Unterstützung für virtuelles Hosting über den nichtstandardisierten HOST-Befehl oder das<br />
Format "example.com|Benutzer" im Benutzernamen. So können Benutzer angeben, an<br />
welcher Website sie sich anzumelden versuchen. Sie werden daraufhin zu unterschiedlichen<br />
Ordnern und Inhalten weitergeleitet, die der FTP-<strong>Server</strong> zur Verfügung stellt.<br />
Benutzerdefinierte Authentifizierung über ASP.NET-Mitgliedschaftsanbieter<br />
Unterstützung für IPv6, der nächsten Generation des Internetprotokolls<br />
Konfiguration im neuen XML-Konfigurationsformat statt über die alte Metabasis.<br />
Außerdem steht eine neue Benutzeroberfläche für die Konfiguration zur Verfügung.<br />
Zusammenfassung<br />
In diesem Kapitel haben wir gesehen, wie der Zugriff auf IIS-Websites im normalen Betrieb<br />
geschützt werden kann. Von der anonymen Authentifizierung, bei der die zur Verfügung<br />
gestellten Informationen von allen gelesen werden können, bis zu leistungsfähigen Techniken<br />
wie Clientzertifikaten und Verbundidentitätsdiensten stehen viele Methoden zur Verfügung,<br />
um die Authentifizierung sicherzustellen. Alle davon haben Vorteile und Nachteile.
Weitere Informationen<br />
Weitere Informationen 501<br />
Howard, M. und LeBlanc, D.: Writing Secure Code for <strong>Windows</strong> Vista. Redmond, WA:<br />
Microsoft Press, 2007.<br />
Howard, M. und LeBlanc, D.: Writing Secure Code, 2nd Ed. Redmond, WA: Microsoft<br />
Press, 2007.<br />
Microsoft Corporation 2007: »Fine-Tuning and Known Issues When You Use the Urlscan<br />
Utility in an Exchange 2003 Environment« unter http://support.microsoft.com/kb/<br />
823175.<br />
Microsoft Corporation 2007: »How to Implement Forms-Based Authentication in Your<br />
ASP.NET Application by Using C#.NET« unter http://support.microsoft.com/kb/301240.
Stichwortverzeichnis<br />
.bat-Erweiterung 98<br />
.bin-Erweiterung 82<br />
.cmd-Erweiterung 98<br />
.Default-SID 107<br />
.dll-Erweiterung 98<br />
.exe-Erweiterung 98<br />
.NET Framework 320, 324, 410<br />
.sys-Erweiterung 98<br />
1:1-Clientzertifikatzuordnung 487<br />
1:n-Clientzertifikatzuordnung 488<br />
10 unveränderliche Gesetze der <strong>Sicherheit</strong> 379<br />
7-Zip 356<br />
A<br />
Abgestimmte Kennwortrichtlinien 50, 453<br />
Kennwortrichtlinien, Liste 53<br />
Verwaltungstools 54<br />
Abhängigkeiten Siehe <strong>Sicherheit</strong>sabhängigkeiten<br />
Abhängigkeiten-Registerkarte, <strong>Die</strong>nste-Konsole 160<br />
ACEs (Zugriffssteuerungseinträge) Siehe Zugriffssteuerungseinträge<br />
(ACEs)<br />
Acharya, Narendra S. 421<br />
ACLs (Zugriffssteuerungslisten) Siehe Zugriffssteuerungslisten<br />
(ACLs)<br />
ACL-UI 67, 81<br />
Active Directory 4, 271<br />
Clientzertifikatzuordnung 489<br />
Data-Mining-Tool 259<br />
Datenbankbereitstellungstool 259<br />
GPOs 187<br />
Gruppenrichtlinien 186<br />
Kennwortverifizierer 25<br />
Kerberos 31<br />
LM-Hash 24<br />
Objekte 58<br />
<strong>Sicherheit</strong>sgruppen 7<br />
Smartcards 20<br />
Vererbungsmodell 7<br />
<strong>Windows</strong>-Firewall 118, 121<br />
Zertifikatdienste Siehe Zertifikatdienste<br />
Active Directory Lightweight Directory Services (AD LDS)<br />
260, 266, 322<br />
Instanz erstellen 268<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, neue Features 268<br />
Active Directory-Anwendungsmodus (ADAM) Siehe Active<br />
Directory Lightweight Directory Services (AD LDS)<br />
Active Directory-Domänendienste (AD DS) 247, 321, 330<br />
Active Directory Lightweight Directory Services (AD LDS)<br />
266, 330<br />
Active Directory-Verbunddienste 269<br />
Benutzeroberfläche 248<br />
Datenbankbereitstellungstool 259<br />
Installationsassistent 250<br />
Neustartfähige 258<br />
Rolleninstallation 331<br />
503<br />
Active Directory-Domänendienste (Fortsetzung)<br />
Schreibgeschützte Domänencontroller 252, Siehe auch<br />
Schreibgeschützte Domänencontroller (RODCs)<br />
Überwachung 261<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, neue Features 270<br />
Active Directory-Rechteverwaltungsdienste (AD RMS) 291,<br />
320, 322, 419<br />
Architekturen 296<br />
Bereitstellung 296<br />
Clientkomponenten 295<br />
Cluster 302<br />
Datenbank 295<br />
Datenlecks 313<br />
<strong>Die</strong>nstkonto 304<br />
Dokumentbibliotheken 311<br />
Dokumente 292<br />
Domänenfunktionsebene 299<br />
Einschränkungen 314<br />
Geheimnisse 292<br />
Gesetze 312<br />
Implementieren 297<br />
Infrastruktur 299<br />
Internet Protocol Security (IPsec) 291<br />
Konsole 310<br />
Lesezugriff 294<br />
Lizenzierungsserver 296<br />
Office 311<br />
Richtlinien 298<br />
Richtlinienvorlagen 309<br />
RMS-<strong>Server</strong> 300<br />
Selbstregistrierung 293<br />
<strong>Server</strong> 293<br />
<strong>Server</strong>rollen 293, 295, 300<br />
SharePoint 311<br />
Verschlüsselung 293<br />
Vorlagen 309<br />
Zertifikat 310<br />
Zertifizierungsserver 296<br />
Active Directory-Verbunddienste 267, 269, 293, 321<br />
Rollendienste 270<br />
Active Directory-Zugriff 262<br />
AD Siehe Active Directory<br />
ADAM (Active Directory-Anwendungsmodus) Siehe Active<br />
Directory Lightweight Directory Services (AD LDS)<br />
Address Space Layout Randomization (ASLR) 160, 178<br />
ADM-Dateien 197<br />
Administrative Abhängigkeiten 388<br />
Rollentrennung 417<br />
Administrative Vorlagendateien (ADMX) 186, 196<br />
Filterung 203<br />
Geräteeinschränkungen 204<br />
Kommentare 200<br />
Administratorbestätigungsmodus 104<br />
Anhebungseingabeaufforderung 108<br />
Netzlaufwerkzuordnung 104
504 Stichwortverzeichnis<br />
Administratorbestätigungsmodus (Fortsetzung)<br />
UAC 465<br />
Verfahrensempfehlungen 112<br />
Administratoren Siehe auch Verwalten<br />
DACLs 60<br />
<strong>Die</strong>nste schützen 179<br />
Festlegen von Kennwortrichtlinien 51<br />
Gruppenrichtlinieneinstellungen 197<br />
Privilegien, Verfahrensempfehlungen 112<br />
Rollentrennung 417, 455<br />
Surfen 465<br />
Zertifizierungsstelle, Kompromittierung 284<br />
Administratorkonto 5<br />
Bekannte RID 14<br />
Bekannte SID 15<br />
Cougar-Plattform 436<br />
Hersteller 454<br />
Kennwortangriffe 41<br />
UAC 465<br />
Verfahrensempfehlungen 454<br />
Zertifizierungsstelle, Kompromittierung 284<br />
Administrator-Loopback 104<br />
ADMX (Administrative Vorlagendateien) Siehe Administrative<br />
Vorlagendateien (ADMX)<br />
Adobe 351<br />
Adress- und Domäneneinschränkungen, IIS 7.0 476<br />
ADSIEdit msc 249<br />
Advanced Encryption Standard (AES) 138, 274<br />
BitLocker 421<br />
advfirewall, Netsh-Kontext 128<br />
AES (Advanced Encryption Standard) Siehe Advanced<br />
Encryption Standard (AES)<br />
AH (Authentication Header) 135<br />
AIA (Authority Information Access) Siehe Authority Information<br />
Access (AIA)<br />
AIS (Anwendungsinformationsdienst) 97<br />
Akronyme<br />
IPsec, <strong>Windows</strong>-Firewall, RRAS, Liste 147<br />
NAP 140, 147<br />
Aktualisieren, Gruppenrichtlinien 186<br />
Aktualisierung Siehe Patchverwaltung; <strong>Sicherheit</strong>supdates<br />
Algorithmen<br />
BitLocker 421<br />
CNG 274<br />
DEA 23<br />
Kryptografische 132, 138<br />
SHA 274<br />
Suite B 274<br />
Alle Einstellungen-Knoten 204<br />
allowed-Attribut 478<br />
allowUnlisted 477<br />
AMK (Auto-Unlock Master Key) 420<br />
Anderson, Jimmy 247<br />
Anforderungsfilterung, IIS 7.0 495<br />
Angriffe Siehe Kennwortangriffe; <strong>Die</strong>nste, Angriffe<br />
Anhebung 92, 94, 101<br />
Anmeldung 107<br />
Blockieren 104<br />
Blockierte 106<br />
Eingabeaufforderungen 102, 108, 110, 128<br />
FUS 113<br />
Anhebung (Fortsetzung)<br />
Kontotypen 105<br />
Nicht autorisiert 111<br />
Anmeldegruppen 10<br />
Anmelde-ID 232<br />
Anmeldeinformationen, Cache 25, 254, 412, 482<br />
Anmeldeinformationen-Eingabeaufforderungen 94, 109<br />
Sicherer Desktop 102<br />
Anmeldeinformationsverwaltung 382<br />
Anmeldekonten 152<br />
Privilegien, Liste 166<br />
Anmelden-Registerkarte, <strong>Die</strong>nste-Konsole 157<br />
Anmeldung<br />
Blockierte Anhebung 106<br />
Meldungstext 460<br />
Annualized Rate of Occurrence, Risikoberechnung 430<br />
Anonyme Authentifizierung 485<br />
Anonyme SIDs 472<br />
Anonymisierungsproxy 476<br />
Ansprüche, Agent 270<br />
Antispyware 465<br />
Antivirensoftware 465<br />
Anwendungsinformationsdienst (AIS) 97<br />
Anwendungsmanifest 100<br />
UAC-Kompatibilität 107<br />
Anwendungsserver 320, 322, 335, 397<br />
Anwendungs-Shims 100, 112<br />
Apache 351<br />
API (Programmierschnittstelle) Siehe Programmierschnittstelle<br />
(API)<br />
Apple 351<br />
QuickTime 442<br />
Application Compatibility Toolkit 108<br />
applicationHost.config 476, 482<br />
Anforderungsfilterung 495<br />
Anonyme Authentifizierung 486<br />
Digestauthentifizierung 490<br />
Standardauthentifizierung 487<br />
Zertifikatzuordnung 487<br />
Arbeitsspeicher, Kennwortspeicherung 27<br />
Arbeitsstation, <strong>Sicherheit</strong> Siehe Netzwerksicherheit<br />
Arbeitsstationen, Kontrolle 459<br />
Architektur<br />
Gestaffelte Verteidigung 11, 118, 146, 378<br />
<strong>Windows</strong>-Filterplattform 117<br />
AS (Authentifizierungsdienst) 37<br />
ASCII-Zeichen 500<br />
ASLR (Address Space Layout Randomization) 160, 178<br />
ASP.NET-Identitätswechsel 490<br />
ASP.NET-<strong>Server</strong>farm 498<br />
Assistent Features hinzufügen 334, 336<br />
Assistent Rollen hinzufügen 250, 274, 299, 321, 334<strong>–</strong>336,<br />
431<br />
AuditBaseDirectories 226<br />
AuditBaseObjects 226<br />
AuditPol.exe 222, 265<br />
Aufgaben der Erstkonfiguration (ICT) 333<br />
Aufgabenplanung, Ereignisse 234<br />
Ausführungsebenen 100<br />
Ausgehende Filterung 119, 121<br />
Auslassen der durchsuchenden Überprüfung 167, 449
Ausmusterung, <strong>Sicherheit</strong> 425<br />
Ausspähen/Sniffing-Angriffe 164<br />
AuthAnvil 454, 456<br />
Authentication Header (AH) 135<br />
Authenticode 95, 109<br />
UIAccess-Anwendungen 109<br />
Authentifizierer 17<br />
Biometrische 18<br />
Kennwort Siehe Kennwort<br />
Passphrase 48<br />
Speicherung 20<br />
Unternehmensgeeignete 20<br />
Authentifizierte Benutzer-Gruppe 10<br />
Benutzer-Gruppe 11<br />
GPO-<strong>Sicherheit</strong>sfilterung 189<br />
Token 72<br />
Authentifizierte Umgehung 138<br />
Authentifizierung 3, 17, 29, 55, Siehe auch Authentifizierer<br />
Anonyme 485<br />
Ausgespähte Informationen 43<br />
Clients 462<br />
Digest 31, 490<br />
Drahtlosnetzwerke 209<br />
Formular 491<br />
Frage-Antwort 30, 386<br />
IIS 7.0 484<br />
IPsec 134<br />
Kennwortangriffe 39<br />
Kennwortschutz 46<br />
Kennwortverwaltung 47<br />
Smartcard 38<br />
Standard 29, 486<br />
<strong>Windows</strong> 492<br />
Zwei Faktoren 18, 456<br />
Authentifizierung auf Netzwerkebene 451<br />
Authentifizierungsdienst (AS) 37<br />
Authority Information Access (AIA) 279<br />
URLs 277<br />
Autorisierung 3<br />
IIS 7.0 484<br />
Autorisierungs-Manager (AZMAN) 89<br />
Auto-Unlock Key 420<br />
Auto-Unlock Master Key (AMK) 420<br />
AZMAN (Autorisierungs-Manager) 89<br />
B<br />
B2B-Transaktionen 269<br />
Backslashzeichen (\), Befehlszeilentools 83<br />
Barreto, Jose 439<br />
Base Filtering Engine (BFE) 117<br />
Base-64-Kodierung 29, 486<br />
Baseline Security Analyzer (MBSA) 362<br />
.bat-Erweiterung 98<br />
BDE (BitLocker-Laufwerkverschlüsselung) Siehe BitLocker-<br />
Laufwerkverschlüsselung (BDE)<br />
Befehlszeilentools (CLI) 81<br />
AuditPol.exe 222, 265<br />
Backslashzeichen 83<br />
EventQuery 242<br />
SC 83<br />
<strong>Sicherheit</strong>supdates 356<br />
Stichwortverzeichnis 505<br />
Befehlszeilentools (CLI) (Fortsetzung)<br />
Systemstatusdatensicherung 447<br />
Überwachung 222<br />
<strong>Windows</strong>-Firewall (netsh) 118, 128<br />
Wusa.exe 356<br />
Bei Ausführung mit erhöhten Rechten Administratorkonten<br />
auflisten, Gruppenrichtlinieneinstellung 111<br />
Bell-LaPadula-<strong>Sicherheit</strong>smodell 61<br />
Benutzer 3f.<br />
Anonym 10<br />
Rechte und Privilegien 85<br />
Schulung 426, 450, 458<br />
Benutzerdefinierte Fehlerseiten 499<br />
Benutzerdefinierte Regeln 124<br />
Benutzer-Gruppe 11<br />
Benutzerkontensteuerung (UAC) 71, 91, 113<br />
Deaktivieren 464<br />
Gruppenrichtlinieneinstellungen 108<br />
Komponenten 94<br />
Nicht vertrauenswürdige Zertifizierungsstellen 281<br />
Remoteunterstützung, Einschränkungen 104<br />
Tokenfilterung 91<br />
Verfahrensempfehlungen 112<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>/<strong>Windows</strong> Vista 111<br />
<strong>Windows</strong>-Kompatibilitätskonfiguration 107<br />
Benutzerspezifische Autostart-Ordner 107<br />
Benutzerspezifische RUN-Schlüssel 107<br />
Benutzerspezifische Überwachung 228<br />
Berechtigungen Siehe auch Zugriffssteuerung<br />
Dateizugriff 4<br />
<strong>Die</strong>nste 11<br />
Eingeschränkte 11<br />
Entfernen 82<br />
Generische 63<br />
Gewähren 82<br />
Gruppen 7<br />
Hauptbenutzer 85<br />
Jeder-Gruppe 10<br />
Netzwerk, Drahtlos 211<br />
Suchen 82<br />
TrustedInstaller 84<br />
Verweigern 82<br />
Vollzugriff 182<br />
Wiederherstellen 82<br />
Berechtigungsverwaltung 81<br />
Cacls und Icacls 82<br />
Subinacl 83<br />
Berners-Lee, Tim 116<br />
Besitzerrechte 85<br />
Besuchercomputer, NAP 146<br />
Betriebsabhängigkeiten 389<br />
Betriebsstrategie 399<br />
Bezeichner Siehe auch <strong>Sicherheit</strong>s-ID (SIDs)<br />
.bin-Erweiterung 82<br />
Bindungen, IIS 7.0 479, 494<br />
Biometrische Authentifizierer 18<br />
BIOS, <strong>Sicherheit</strong>smaßnahmen für Zertifizierungsstellen 287<br />
BitLocker-Laufwerkverschlüsselung (BDE) 287, 291, 324,<br />
331, 379, 418<br />
Algorithmen und Schlüssel 421<br />
Integritätsprüfung 423
506 Stichwortverzeichnis<br />
BitLocker-Laufwerkverschlüsselung (BDE) (Fortsetzung)<br />
Start 423<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> Konfiguration 419<br />
Zweigstellen 424<br />
BITS (Intelligenter Hintergrundübertragungsdienst) 358<br />
BITS-<strong>Server</strong>erweiterungen 324<br />
Black, Chris 378<br />
Blacklisting 476<br />
Blaster-Wurm 162, 177, 181<br />
Blut, Beispiel für Authentifizierung 18<br />
Bradley, Susan E. 429<br />
Bugs, Cacls/Icacls/Subinacl 83<br />
Burch, Hal 163<br />
Business-to-Business-Transaktionen 269<br />
C<br />
CA Siehe Zertifizierungsstelle<br />
CAB-Datei 356<br />
Cacls 82<br />
Cailliau, Robert 116<br />
Callout-Module 117<br />
Canover, Darren 91<br />
Carpenter, Chase 81<br />
CBC (Cipher Block Chaining) 138<br />
Change ACLs (Cacls) 82<br />
Chaos Computer Club 19<br />
CHAP 27, 451<br />
Cheah, Bernard 472<br />
Chen, Raymond 114<br />
Cheswick, Bill 163<br />
Cipher Block Chaining (CBC) 138<br />
Ciphertext 20, 421<br />
Cisco 141, 274<br />
Client Side Extensions (CSEs) 196, 204<br />
Clientfrage, NTLM 34f.<br />
Clientzertifikatzuordnung 487<br />
Clientzugriffsserver 440<br />
CLI-Tools (Befehlszeilenschnittstelle) Siehe Befehlszeilentools<br />
(CLI)<br />
CLR (Common Language Runtime) 410<br />
Cluster, Active Directory-Rechteverwaltungsdienste<br />
(AD RMS) 302, 310<br />
Clusterfreigaben, Subinacl 83<br />
Clusterserverunterstützung 137<br />
.cmd-Erweiterung 98<br />
CNG (Cryptography Next Generation) 274<br />
COM+-Netzwerkzugriff 335<br />
Common Language Runtime (CLR) 410<br />
Common-Criteria-Richtlinien 225, 285<br />
Verfahrensempfehlungen 289<br />
Computer, als SIDs 7<br />
Computerbrowserdienst 165<br />
Computerkonfigurationseinstellungen, Risiken und Vorteile<br />
211<br />
Computerschlüssel, ASP.NET 498<br />
Computerspezifische Autostart-Ordner 107<br />
Computerspezifische RUN-Schlüssel 107<br />
Consec-Befehl 129<br />
Cookies 491<br />
ASP.NET 498<br />
Core Root of Trust Measurement (CRTM) 423<br />
CrashOnAuditFail 225<br />
CreateRestrictedToken 75<br />
CRL Siehe Zertifikatsperrliste (CRL)<br />
CRTM (Core Root of Trust Measurement) 423<br />
Cryptography Next Generation (CNG) 274<br />
Algorithmen 274<br />
CSEs (Client Side Extensions) 196, 204<br />
CSS (Customer Service and Support) 358<br />
Customer Service and Support (CSS) 358<br />
D<br />
DACLs (Discretionary Access Control List) Siehe Discretionary<br />
Access Control List (DACLs)<br />
Daniel, Sean 436<br />
Data Encryption Algorithm (DEA), LM-Hash 23<br />
Data Encryption Standard (DES), LM-Hash 23<br />
Data-Mining-Tool 268<br />
Datei- und Druckerfreigabeeinstellungen 461<br />
Dateidienste 322, 330<br />
Dateien 3, 58<br />
Eingabeaufforderung,, Verbesserungen 112<br />
Erweiterungen 98<br />
Subinacl 83<br />
Virtualisierung 98<br />
Dateierweiterungen 98<br />
Anforderungsfilterung 497<br />
Dateifreigabe<br />
Ereignis-IDs 235<br />
Dateireplikationsdienst 412<br />
Dateisystem, Namespaces 84<br />
Daten im Transit 291<br />
Daten in Ruhe 291<br />
Datenausführungsverhinderung (DEP) 152, 178<br />
Datenbankserver 397<br />
Datenflussdiagramm (DFD), Netzwerk 396<br />
Datenlecks 313<br />
Datenschutz 312<br />
Datensicherung<br />
BitLocker 425<br />
<strong>Server</strong> 411, 446<br />
Strategie 399, 401<br />
Datensicherung, Feature 331<br />
Datensicherungsoperator 285<br />
Datenvolumes, automatische Entsperrung 420<br />
Datenweitergabe, Verhindern 294<br />
Davies, Joseph 411, 467<br />
DBCS-Pwd 24<br />
DCs (Domänencontroller) Siehe Domänencontroller (DCs)<br />
DEA (Data Encryption Algorithm), LM-Hash 23<br />
Debuggen 499<br />
.Default-SID 107<br />
DELETE-Recht 64<br />
Denial-of-Service-Angriffe 163<br />
DEP (Datenausführungsverhinderung) 152, 178<br />
DES (Data Encryption Standard), LM-Hash 23<br />
Desktopcomputer, NAP 146<br />
Desktopdarstellung 324<br />
Detaillierte Regeln, <strong>Windows</strong>-Firewall 119<br />
Detaillierte Verzeichnisdienstreplikation 262<br />
Developer Network, Microsoft 181<br />
DFD (Datenflussdiagramm), Netzwerk 396
DFSR (Verteiltes Dateisystem, Replikation) 254, 389<br />
DH (Diffie-Hellman)<br />
Group 19 138<br />
Group 20 138<br />
DHCP (Dynamic Host Configuration Protocol) 259, 319f.<br />
Erzwingung 142<br />
<strong>Server</strong> 322<br />
DIALUP-SID 84<br />
<strong>Die</strong>bstahl<br />
Festplatte 424<br />
<strong>Server</strong> 424<br />
<strong>Die</strong>nste 11, 58, 151<br />
Änderungen, Benachrichtigung 178<br />
Angriffe Siehe auch <strong>Die</strong>nste, Angriffe<br />
Anmeldekonto 152<br />
Dektivieren/Aktivieren 180<br />
Fehler, Überwachung 183<br />
Geringstmögliche Privilegien 166, 180, 182<br />
Härtung 165<br />
Konfigurieren 155<br />
Leistung 328<br />
Listenerports 154<br />
Schutz, <strong>Windows</strong>-Firewall 118<br />
Schützen 179<br />
SIDs 15, 170<br />
Subinacl 83<br />
<strong>Die</strong>nste, Angriffe 161<br />
Abhängigkeiten 383<br />
Ausspähen/Sniffing 164<br />
Blaster-Wurm 162, 177, 181<br />
Denial-of-Service 163<br />
Fehlkonfiguration 164<br />
Kennwortkompromittierung 164, Siehe auch Kennwortangriffe<br />
Nachi-Wurm 162<br />
Nicht vertrauenswürdige Zertifizierungsstelle hinzufügen<br />
281<br />
Offline 425<br />
Portscan 457<br />
Private Schlüssel wiederherstellen, nicht autorisiert 285<br />
Pufferüberlauf 160, 162f.<br />
Reflektionsangriff 388<br />
Remoteanmeldungszugriff 164<br />
Social Engineering 165<br />
SQL Slammer 181<br />
Squatting 227<br />
Unautoritisierte Informationensweitergabe 165<br />
Verzeichnis 481<br />
Zertifikatsperrprüfung 276<br />
Zertifikatsvorlagenmanipulation 280<br />
Zertifizierungsstelle, Kompromittierung durch Administrator<br />
284<br />
Zertifizierungsstellenkonfiguration, Manipulation 279<br />
<strong>Die</strong>nste-Konsole 155<br />
<strong>Die</strong>nstkonten<br />
Abhängigkeiten 388<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
304<br />
Trennen 401<br />
<strong>Die</strong>nstname 155<br />
<strong>Die</strong>nstprinzipalnamen (SPNs) 153<br />
Stichwortverzeichnis 507<br />
<strong>Die</strong>nstprogramme, ACEs 81<br />
<strong>Die</strong>nst-SID 152<br />
<strong>Die</strong>nststatus-Feld 157<br />
<strong>Die</strong>nststeuerungs-Manager (SCM) 153<br />
Neue Features 179<br />
<strong>Die</strong>se Organisation-SID 73<br />
Diffie-Hellman (DH)<br />
Group 19 138<br />
Group 20 138<br />
Diffuser 421<br />
Digestauthentifizierung 31, 490<br />
Digest-Protokoll 27<br />
Digitale Signaturen 135<br />
Digitale Zertifikate 134<br />
Discretionary Access Control List (DACLs) 59, 90<br />
Leere und Null 77<br />
SDDL 78<br />
Überwachung 220<br />
.dll-Erweiterung 98<br />
DLLs 410<br />
DNS (Domain Name System) Siehe Domain Name System<br />
(DNS)<br />
Dokumentbibliotheken 311<br />
Domain Name System (DNS) 295, 319f.<br />
Reverse-Lookups 477<br />
Schreibgeschützt 256<br />
<strong>Server</strong> 322, 330<br />
DOMAIN_ALIAS-RIDs 92<br />
DOMAIN_GROUP-RIDs 92<br />
DomainDNSZones 256<br />
domainName 477<br />
Domäne, und Gesamtstruktur 389<br />
Domänen-Admins, Konten 15, 260<br />
Nutzung einschränken 182<br />
PKI verwalten 285<br />
Surfen 465<br />
Domänenbenutzerkonten 4<br />
Kennwortverifizierer 106<br />
Remoteverwaltung 104<br />
Domänen-Benutzer-SID 73<br />
Domänencontroller (DC) 5<br />
Abgestimmte Kennwortrichtlinien 50<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
293<br />
IPsec 137<br />
Kommunikationsmuster 397<br />
RODCs 247<br />
Schutzwürdigkeit 395<br />
<strong>Sicherheit</strong>, Angriffe 380<br />
Smartcards 20, 38<br />
UAC 465<br />
Zugriff durch Angreifer 45<br />
Domänenfunktionsebene 299<br />
Domänengruppen 7<br />
Domänenisolierung 390, Siehe auch <strong>Server</strong>- und Domänenisolierung<br />
Domänenlokale Gruppen 7<br />
Domänenprofil 120, 129, 207<br />
Domänenrelative RIDs 15<br />
Download Center, Microsoft 358, 449, 459<br />
Drahtlosadapter 137
508 Stichwortverzeichnis<br />
Drahtlosnetzwerkrichtlinie 209<br />
Druckdienste 323, 330<br />
Drucker, Subinacl 83<br />
Dsamain.exe 259<br />
DsrmAdminLogonBehavior 463<br />
Dump-Befehl 128<br />
DWORD<br />
Ereignisprotokoll 232<br />
Standardauthentifizierung 487<br />
Dynamic DNS 132<br />
Dynamisch gelinkte Bibliotheken (DLLs) 410<br />
E<br />
ECDH (Elliptic Curve Diffie-Hellman) 274<br />
ECDS (Elliptic Curve Digital Signing) 274<br />
Edge-<strong>Server</strong> 437, 443<br />
Edge-Transportserver 440<br />
Editor 242<br />
EFS, und BitLocker 291, 419<br />
Eigenschaftendatei 356<br />
Eigenständige Zertifizierungsstellen 273<br />
EIGENTÜMERRECHTE-SID 85<br />
Eindämmung Siehe Risikoeindämmung<br />
Einfache TCP/IP-<strong>Die</strong>nste 326<br />
Eingabeaufforderungen 94<br />
Anhebung 102, 109f.<br />
Befehl, Updates suchen 364<br />
Installationserkennung 102<br />
Updates suchen 364<br />
weniger bei Dateioperationen 112<br />
Eingehende Filterung 119, 121<br />
Eingeschränkte Gruppen 182<br />
Eingeschränkte SIDs 173<br />
Eingeschränkte Token 75<br />
Einmalanmeldung (SSO) 27<br />
Einschränkungen<br />
Implementieren 400<br />
Kommunikation 402<br />
Ressourcenzugriff 403<br />
Elliptic Curve Diffie-Hellman (ECDH) 274<br />
Elliptic Curve Digital Signing (ECDS) 274<br />
EMS (Enterprise Management System) 345, 388<br />
enableReverseDns 477<br />
Encapsulated Security Payload (ESP) 135<br />
Endian 58<br />
Enterprise Management System (EMS) 345, 388<br />
Entschlüsselung 20<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
293<br />
ASP.NET 498<br />
BitLocker 419<br />
Entwicklungsumgebung, AD LDS 268<br />
Epp, Dana 431<br />
Ereignisanzeige 220, 229, 236<br />
Ereignis-IDs, Listen 233, 262<br />
Ereignisprotokoll 217<br />
Verbesserungen 220<br />
Ereignisse<br />
Analyse 236<br />
IDs 230, 233<br />
Neue in <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 230<br />
Ereignisverfolgungsmodul des Kernels (ETW) 219<br />
Erkennung interaktiver <strong>Die</strong>nste 177, 341<br />
Ersteller/Besitzer-SID 85<br />
Erzwingungsserver, NAP 141<br />
ESP (Encapsulated Security Payload) 135<br />
Ethereal, Netzwerkverkehrsanalyzer 35<br />
ETW (Ereignisverfolgungsmodul des Kernels) 219<br />
EventQuery 242<br />
.exe-Erweiterung 98<br />
Excel 311<br />
Exchange <strong>Server</strong> 8, 30, 346, 433, 436f., 440f.<br />
Edge-<strong>Server</strong> 437<br />
Explorer.exe 92<br />
Export-Befehl 128<br />
Extranetauthentifizierungsspeicher 267<br />
F<br />
Failover-Clusterunterstützung 324, 331<br />
BitLocker 426<br />
Faxserver 322<br />
Features und Rollen, <strong>Server</strong> 320<br />
Federal Information Processing Standards (FIPS) 276<br />
Federal-Bridge-Signing, Zertifikatsvorlage 283<br />
Fehlkonfiguration, Angriffe 164<br />
Ferguson, Niels 421<br />
File Transfer Protocol (FTP) 29, 40, 116<br />
<strong>Server</strong> 500<br />
über SSL/TS 500<br />
FILE_xxx-Rechte 64<br />
FileList-Registrierungsschlüssel 99<br />
Filesharing 180<br />
Filterung<br />
Anforderung, IIS 7.0 495<br />
Ausgehende 119, 121<br />
Detaillierte Regeln 119<br />
Eingehende 119, 121<br />
Ereignisse, Ereignisanzeige 236<br />
GPOs, <strong>Sicherheit</strong> 189<br />
GPOs, WMI 191<br />
Plattform, Ereignisse 235<br />
Fingerabdruck, Authentifizierung 18<br />
FIPS (Federal Information Processing Standards) 276<br />
Firewall-Befehl 129<br />
Firewallclient 95<br />
Firewalls Siehe auch <strong>Windows</strong>-Firewall mit erweiterter<br />
<strong>Sicherheit</strong><br />
Anfänge 115<br />
Anwendungsschicht 115<br />
Cougar-Plattform 434f.<br />
Deaktivieren 455<br />
Externe 450, 461<br />
Hostbasierte 11, 116, 135, 450, 461<br />
ISA 443<br />
Ports 58<br />
FireWire 447<br />
Fitzgerald, Eric 217, 220<br />
Flashlaufwerke<br />
Einschränken 204<br />
<strong>Sicherheit</strong> 377<br />
Flexibilität 409<br />
ForeFront Services für SharePoint 466
ForestDNSZones 256<br />
Formularauthentifizierung 491<br />
Forrester 418<br />
FQDNs (vollqualifizierte Domänennamen) 31<br />
Frage-Antwort<br />
Authentifizierung 30, 386<br />
Kennwortangriffe 40<br />
Knacken 43<br />
Freigaben, Subinacl 83<br />
Fremdhersteller<br />
Managed Services 458<br />
Software 450<br />
FRS (Dateireplikationsdienst) 412<br />
FTP (File Transfer Protocol) 29, 40, 116<br />
FTP über SSL/TS 500<br />
FTP-<strong>Server</strong> 500<br />
Full Disclosure-Mailingliste 352<br />
FullPrivilegeAuditing 226<br />
Full-Volume Encryption Key (FVEK) 421<br />
Funktionen, unidirektional 22<br />
FUS (Schnelle Benutzerumschaltung) 113<br />
FVEK (Full-Volume Encryption Key) 421<br />
G<br />
GAP (Granular Audit Policy) 223<br />
Gäste, und authentifizierteBenutzer 10<br />
Gastkonto 5, 10<br />
RID 14f.<br />
Geerbte Berechtigungen 83<br />
Gefahrenmodelle 393<br />
Gefilterte Token 72, 91<br />
Verknüpfte 105<br />
Gefilterter Attributsatz 253<br />
Geheimnisse 20<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
292<br />
Dokumente 292<br />
Kennworthashwerte 45<br />
Umkehrbar verschlüsselte Kennwörter 27<br />
Gehostete Messagingserver 441<br />
Gehostete <strong>Server</strong> 438<br />
Gemeinsame Sitzungsschlüssel 37<br />
Genehmigte Nutzung, Richtlinien 452<br />
Generic Filter Engine (GFE) 117<br />
Generische Berechtigungen 63<br />
Geräteeinschränkungen 204<br />
Geringstmögliche Privilegien 166, 180, 182<br />
Gesamtstruktur, <strong>Sicherheit</strong> 389<br />
Geschützte Objekte 58<br />
Gesetze 312<br />
Gestaffelte Verteidigung, Architektur 11, 118, 146, 378<br />
Glass, Eric 35<br />
Glenn, Walter 441<br />
Global System for Mobile-Kommunikation (GSM) 38<br />
Globale Gruppen 7<br />
Globale Überwachungsrichtlinie 264<br />
Gopher 116<br />
GPC (Gruppenrichtliniencontainer) 195<br />
GPO Siehe Gruppenrichtlinienobjekte<br />
GPSI (Gruppenrichtlinien-Softwareinstallation) 113<br />
GPT (Gruppenrichtlinienvorlage) 195, 197<br />
Stichwortverzeichnis 509<br />
Gpupdate /force 374<br />
Granular Audit Policy (GAP) 223<br />
Greenemeier, Larry 430<br />
Grimes, Roger A. 151, 459<br />
Groß-/Kleinschreibung<br />
LM-Hash 22<br />
Gruppen<br />
als SIDs 7<br />
Anmeldung 10<br />
Verschachtelt 7<br />
Gruppenrichtlinien 28, 185f.<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
309<br />
Anmeldung, Anhebung 107<br />
Benutzerrechte und Privilegien 85<br />
BitLocker 421<br />
Computerkonfigurationseinstellungen, Risiken und Vorteile<br />
211<br />
Eingeschränkte Gruppen 182<br />
Kennwortverwaltung 49<br />
Kleine Unternehmen, Einstellungen 459<br />
LAN Manager-Authentifizierungsebene 32<br />
<strong>Sicherheit</strong>seinstellungen verwalten 211<br />
Standardauthentifizierung 487<br />
UACs 91, 108<br />
Verarbeitung 193<br />
Verfahrensempfehlung 460<br />
Versionskontrolle 195<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>/Vista, Änderungen 185, 197<br />
<strong>Windows</strong>-Firewall 122, 130<br />
Zertifikatsperrprüfung 276<br />
Gruppenrichtliniencontainer (GPC) 195<br />
Gruppenrichtlinienobjekte<br />
Lokale Siehe Lokale Gruppenrichtlinienobjekte (LGPOs)<br />
Gruppenrichtlinienobjekte (GPOs) 186<br />
Active Directory 187<br />
Filterung 189, 203<br />
Kommentare 200<br />
<strong>Sicherheit</strong>skonfigurations-Assistent 345<br />
Starter 199<br />
Versionen 195<br />
Vertrauenswürdige Stammzertifizierungstellen 281<br />
WSUS-Bereitstellung 366<br />
WSUS-Clientkonfiguration 373<br />
Zertifizierungsstelle, Manipulation 279<br />
Gruppenrichtlinien-Softwareinstallation (GPSI) 113<br />
Gruppenrichtlinienverwaltung 324<br />
Gruppenrichtlinienverwaltung-Konsole 189<br />
GPO-<strong>Sicherheit</strong>sfilterung 189<br />
Gruppenrichtlinienvorlage (GPT) 195, 197<br />
GSM-Kommunikation (Global System for Mobile) 38<br />
GUI-Kennwortverwaltungstools 54<br />
Gültigkeitsbereich, Konten 400<br />
H<br />
Halloween-Dokumente 292<br />
Handle 227<br />
Hardwaresicherheitsmodule (HSMs) 276, 287f.<br />
Hashing 20<br />
Angriffe 43, 385<br />
Kennwortangriffe 40
510 Stichwortverzeichnis<br />
Hashing (Fortsetzung)<br />
LM-Hash 22<br />
NT-Hash 24<br />
Pass-the-Hash-Angriffe 45<br />
Saltwerte 21<br />
Hauptbenutzer, Berechtigungen 85<br />
Hauptmodus, IPsec 133<br />
HCAP (Host Credential Authorization-Protokoll) 141<br />
Health Insurance Portability and Accountability Act (HIPAA)<br />
429<br />
Heimcomputer, NAP 146<br />
Hersteller, Verfahrensempfehlungen 454<br />
Hertel, Christopher R. 35<br />
highestAvailable-Stufe 101<br />
Hintergrundverarbeitung 193<br />
HIPAA (Health Insurance Portability and Accountability Act)<br />
429<br />
HKLM\SOFTWARE 99<br />
HMAC-MD5 34<br />
Host Credential Authorization-Protokoll (HCAP) 141<br />
HOST-Befehl 500<br />
Hostheader, <strong>Sicherheit</strong> 479<br />
Hostnamen, Kerberos 36<br />
Howard, Michael 495, 501<br />
HRA (Integritätsregistrierungsstelle) 136, 141<br />
HSMs (Hardwaresicherheitsmodule) 276, 287f.<br />
HTTP (Hypertext Transfer Protocol) Siehe Hypertext Transfer<br />
Protocol (HTTP)<br />
HTTPS (Secure Hypertext Transfer Protocol) 116<br />
Hubtransportserver 440<br />
Hynes, Byron 405<br />
Hypertext Transfer Protocol (HTTP) 29, 116, 476<br />
Base-64-Kodierung 486<br />
Hostheader 479<br />
HTTP.SYS-Treiber 495<br />
IPv4 476<br />
IPv6 476, 500<br />
Komprimierung 408<br />
über SSL/TLS 479<br />
Hyper-V 410<br />
I<br />
IAS (Internet Authentication <strong>Server</strong>) 140<br />
IBM, OS/2 22<br />
Icacls 82<br />
ICMP (Internet Control Message Protocol) 120<br />
ICT (Aufgaben der Erstkonfiguration) 333<br />
IDC 407<br />
Identität des Anwendungspools 486<br />
Identitätsbasierte Zugriffssteuerung 89<br />
Identitätssysteme<br />
Konsolidieren 267<br />
Lösung erstellen 269<br />
Identity Integration Feature Pack (IIFP) 267<br />
Identity Integration <strong>Server</strong>, Microsoft (MIIS) 267<br />
IDs 7<br />
<strong>Die</strong>nste 11<br />
Relative 13<strong>–</strong>15<br />
IEE 802.1x 141, 145, 209<br />
IFM (Install From Media) 258, 269<br />
IIFP (Identity Integration Feature Pack) 267<br />
IIS (Internetinformationsdienste) Siehe Internetinformationsdienste<br />
7.0 (IIS 7.0)<br />
IKE (Internet Key Exchange) 116, 134<br />
IMAP 29<br />
Import-Befehl 128<br />
Improved Cacls (Icacls) 82<br />
Indiskretionen 292<br />
Infopath 311<br />
Information Rights Management (IRM) 294<br />
Infrastruktur für öffentliche Schlüssel (PKI) 38, 134, 273<br />
Rollentrennung, Verfahrensempfehlungen 288<br />
<strong>Sicherheit</strong>sstufe 4 284<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 274<br />
Infrastrukturoptimierung (IO) 409<br />
Install From Media (IFM) 258, 269<br />
Installation<br />
Erkennung 101, 109<br />
Standardbenutzer 113<br />
Integrierte Gruppen 7<br />
Bekannte RIDs und SIDs 15<br />
Integrierte <strong>Sicherheit</strong>skonten 108<br />
Integrierte <strong>Windows</strong>-Authentifizierung 484<br />
Integrität<br />
Beschriftungen 76<br />
Überprüfen, BitLocker 423<br />
Integritätsebenen<br />
Einstellen 82<br />
UIAccess-Anwendungen 109<br />
Verbindliche 177<br />
Integritätsregistrierungsstelle (HRA) 136, 141<br />
Integritätszertifikate 136<br />
Intelligenter Hintergrundübertragungsdienst 358<br />
Intel-Prozessoren 58<br />
Interaktive Anmeldung, Einstellungen 460<br />
Interaktiv-Gruppe 10<br />
INTERAKTIV-SID 73<br />
Interne <strong>Windows</strong>-Datenbank 295, 302, 320, 327, 367<br />
Installation 368, 370<br />
Internet<br />
Anfänge 116<br />
Dynamisch und statisch 472<br />
Zugriffsrichtlinien 444, 450<br />
Internet Authentication <strong>Server</strong> (IAS) 140<br />
Internet Control Message Protocol (ICMP) 120<br />
Internet Explorer 276, 331, 410<br />
Geschützter Modus 108, 110, 464<br />
Kill-Bits 354<br />
Internet Key Exchange (IKE) 116, 134<br />
Internet Protocol Security (IPsec) 116, 133<br />
Active Directory-Rechteverwaltungsdienste 291<br />
Akronyme, Liste 147<br />
Authentifizierte Umgehung 121<br />
Ereignisse 235<br />
Erzwingungsmethoden 141, 145<br />
Integration 121<br />
Kommunikationseinschränkungen 402<br />
Konfiguration, Gruppenrichtlinien 208<br />
Netzwerkisolierung 183, 398<br />
Richtlinie 135f.<br />
TCP/IP 411<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>, Verbesserungen 135
Internet Protocol-Adresse Siehe IP-Adresse<br />
Internet Relay Chat (IRC) 40<br />
Internet Security and Acceleration <strong>Server</strong> (ISA) 30, 436<br />
Firewall 443<br />
Internetdruckclient 324<br />
Internetinformationsdienste (IIS) 31, 41, 323, 330<br />
AD FS 271<br />
Subinacl 83<br />
Versionen 433<br />
Internetinformationsdienste 7.0 (IIS 7.0) 500<br />
Anonyme SID 472<br />
Authentifizierung und Autorisierung 484<br />
IIS_IUSRS-Benutzergruppe 472<br />
Internetinformationsdienste-Manager 474<br />
IUSR, anonyme Benutzer 472<br />
Konfigurieren 473<br />
Neue Features 472f.<br />
Pfadbasierte <strong>Sicherheit</strong> 480<br />
<strong>Sicherheit</strong> 493<br />
TCP/IP-basierte <strong>Sicherheit</strong> 476<br />
XCOPY 472<br />
INTERNET-SID 84<br />
IO (Infrastrukturoptimierung) 409<br />
ipAddress 477<br />
IP-Adresse 320<br />
Bereiche 137<br />
IIS 7.0 476<br />
Intern und extern 476<br />
Kerberos 36<br />
LM/NTLM 31<br />
Remotezugriff 455<br />
IPsec (Internet Protocol Security) Siehe Internet Protocol<br />
Security (IPsec)<br />
ipSecurity 477<br />
IPv4 137, 476<br />
IPv6 121, 137, 476, 500<br />
RRAS 131<br />
IRM (Information Rights Management) 294<br />
ISAKMP 134<br />
ISA-<strong>Server</strong> (Internet Security and Acceleration) Siehe Internet<br />
Security and Acceleration <strong>Server</strong> (ISA)<br />
iSNS (Internet Storage Name <strong>Server</strong>) 324<br />
Isolierungsstrategie 398<br />
J<br />
Jeder-Gruppe 10<br />
Token 72<br />
Joeware net 54<br />
Johansson, Jesper M. 3, 17, 22, 57, 149, 167, 319, 377, 404,<br />
430, 459, 482<br />
Jones, Alun 471<br />
Jones, Jeff 179<br />
K<br />
Kabelnetzwerkrichtlinie 208<br />
KDC Siehe Schlüsselverteilungscenter (KDC)<br />
Kennwort 55<br />
als Authentifizierer 18<br />
Ändern 454<br />
Angriffe Siehe Kennwortangriffe<br />
Anmeldung von <strong>Die</strong>nstkonten 154<br />
Stichwortverzeichnis 511<br />
Kennwort (Fortsetzung)<br />
Benutzerdefinierte <strong>Die</strong>nste 181<br />
BIOS 287<br />
Datei 21<br />
Kontosperrung 457<br />
Länge 454<br />
Leere 42, 287, 330<br />
LM-Hash 22<br />
Passphrasen 48, 450<br />
Replikationsrichtlinie 254<br />
Richtlinien 49, 143, 181, 450, 452<br />
Schutz 46<br />
Smartcards 38<br />
Überwachung 181<br />
Umkehrbar verschlüsselt 27<br />
Verifizierer 25<br />
Verwaltung 47<br />
Wiederherstellung, BitLocker 425<br />
Kennwortangriffe 39, 55<br />
Arbeitsspeicher 27<br />
Hashangriffe 43, 385<br />
Kennwortlänge 46<br />
Kennwortverifizierer 25, 106<br />
Knacken von Kennwörtern 43<br />
Kompromittierung 164<br />
LM-Hash 24<br />
Man-in-the-middle 35, 132, 164<br />
Pass-the-Hash 45<br />
Umkehrbar verschlüsselte Kennwörter 27<br />
Kennwortreplikationsrichtlinie 413<br />
Kennwortverwaltungstools, GUI 54<br />
Kerberos 30, 36<br />
Active Directory 31<br />
AD DS 254<br />
Anmeldeinformationen 136<br />
Anmeldekonten 154<br />
IPsec 134<br />
Ticket Granting Service (TGS) 37<br />
Ticket Granting Ticket (krbtgt) 14, 37, 254<br />
Kernnetzwerkeinstellungen 461<br />
Kernobjekte 58<br />
Subinacl 83<br />
Überwachungsrichtlinien 228<br />
Key Distribution Center Siehe Schlüsselverteilungscenter<br />
(KDC)<br />
Kioskcomputer 388, 456<br />
Klark, Khalid 418<br />
Klartext 20, 421<br />
Kennworthashwerte 44f.<br />
Umkehrbar verschlüsselte Kennwörter 27<br />
Klassen 7<br />
Klassifizierungsschema, <strong>Server</strong>- und Domänenisolierung 390<br />
Kleinbuchstaben Siehe Groß-/Kleinschreibung<br />
Kleine Unternehmen 429, 468<br />
Multi-Rollen-<strong>Server</strong> 439<br />
<strong>Server</strong> 433<br />
<strong>Server</strong>, Budget 430<br />
Verfahrensempfehlungen 447<br />
Knowledge Base, Microsoft 11, 451, 468<br />
Kommentare, GPO 200<br />
Kommunikationseinschränkungen 402
512 Stichwortverzeichnis<br />
Kompatibilität<br />
ACEs 81<br />
Anwendung 100, 112<br />
UAC und Prä-<strong>Windows</strong> Vista 107<br />
Virtualisierung 100<br />
Konfigurationsdateien, IIS 7.0 475<br />
Konfigurationsspeicher 268<br />
Konten, Gültigkeitsbereich minimieren 400<br />
Kontenorganisation 270<br />
Kontosperrung 457<br />
Kostenkontrolle 409, 430<br />
Kryptografie 20<br />
Algorithmen 132, 138<br />
Ereignisse 235<br />
Isolierung 412<br />
Signatur 425<br />
<strong>Windows</strong>-Firewall 138<br />
L<br />
L2TP/IPsec 131<br />
Langsame Verbindung<br />
Erkennung 186<br />
Verarbeitung 194<br />
LAN-Manager 22, 31<br />
Authentifizierungsebene 32<br />
LanManager, unidirektionale Funktion Siehe LM-Hash<br />
Lastausgleich 137, 279, 288<br />
LDAP (Lightweight Directory Access Protocol) 31, 260,<br />
413<br />
LDIF (Lightweight Data Interchange Format) 269<br />
LeBlanc, David 495, 501<br />
Leere Kennwörter 42, 287, 330<br />
Leere und Null-DACLs 77<br />
Leerschlüssel 423<br />
Legacyanwendungen 463<br />
Leistung<br />
<strong>Server</strong> Core 331<br />
<strong>Server</strong>rollen/<strong>Die</strong>nste 328<br />
Leistungsindikatoren 138<br />
Leseeinschränkung 75<br />
Lesezugriff, Active Directory-Rechteverwaltungsdienste<br />
(AD RMS) 294<br />
LGPOs (Lokale Gruppenrichtlinienobjekte) 186<br />
Lightweight Data Interchange Format (LDIF) 269<br />
Line-Of-Business-Anwendungen 108, 408, 431<br />
Akzeptable Rollen 440<br />
Virtual <strong>Server</strong> 445<br />
Listenerports 154<br />
Little-endian-Betriebssystem 59<br />
Lizenzierungsserver 296<br />
LM/NTLM 30f.<br />
Ereignisanzeige 232<br />
LMCompatibilityLevel 32, 35<br />
LM-Hash 22<br />
LMOF Siehe LM-Hash<br />
LOB-Anwendungen (Line-Of-Business) Siehe Line-Of-<br />
Business-Anwendungen<br />
Local Security Authority (LSA) 219, 253<br />
Local Security Authority Sub-System (LSASS) 29<br />
Logon-SID 73<br />
LogonUI 29<br />
Lokale Administratoren, Gruppe 94<br />
PKI verwalten 285<br />
Suchen nach <strong>Sicherheit</strong>supdates 363<br />
<strong>Windows</strong> Update 359<br />
Zertifizierungsstelle, Manipulation 279<br />
Zertifizierungsstelle, Schlüsselpaarkompromittierung 275<br />
Lokale Benutzerkonten 4<br />
Remoteverwaltung 104<br />
Lokale Gruppen 7<br />
Lokale Gruppenrichtlinienobjekte (LGPOs) 186<br />
Lokale <strong>Sicherheit</strong>srichtlinie, Editor 108, 279<br />
LOKALER DIENST-Konto 152<br />
Lokales Systemkonto 152, 182<br />
Privilegien 168<br />
LOKAL-SID 73<br />
LPR-Portmonitor 324<br />
LSA (Local Security Authority) 219, 253<br />
LSASS (Local Security Authority Sub-System) 29<br />
Luafv.sys 98<br />
M<br />
MACLs (Mandatory ACLs) 60<br />
Mailboxserver 440<br />
Malware 11, 39, 91, 102, 113, 117f., 121, 161, 165, 377, 424,<br />
442<br />
Antimalwaresoftware 465<br />
Managed Services 457<br />
Fremdhersteller 458<br />
Remotezugriff 458<br />
Manifeste 100<br />
Man-in-the-middle-Angriffe 35, 132, 164<br />
MBSA (Microsoft Baseline Security Analyzer) 362<br />
Mbsacli.exe 364<br />
MD5-Hash 31<br />
Melber, Derek 199<br />
Message Queuing 324<br />
Messaging-Hygiene-Technologien 437<br />
Methoden, IPsec 135<br />
Microsoft<br />
Baseline Security Analyzer (MBSA) 362<br />
Bedrohungen und Gegenmaßnahmen 459<br />
Customer Service and Support (CSS) 358<br />
Developer Network 181<br />
Download Center 358, 449, 459<br />
Exchange <strong>Server</strong> Siehe Exchange <strong>Server</strong><br />
Firewallclient 95<br />
ForeFront Services für SharePoint 466<br />
Identity Integration Feature Pack (IIFP) 267<br />
Identity Integration <strong>Server</strong> (MIIS) 267<br />
Informationsquellen 114, 149, 165, 179f., 184, 192, 215,<br />
223, 225, 228, 265, 281, 289, 315, 339, 351, 354f., 375f.,<br />
398, 404, 410, 427, 432, 438, 442, 445, 449, 459, 465,<br />
468, 501<br />
Internet Security and Acceleration <strong>Server</strong> (ISA) 30, 436,<br />
443<br />
Knowledge Base 11, 451, 468<br />
LM-Hash, Versionen 22<br />
Office 2003 311<br />
Office 2007 311<br />
Office, IRM (Information Rights Management) 294<br />
Operations Management (MOM) 457
Microsoft (Fortsetzung)<br />
Produktlebenszyklen, Service Pack-Roadmap 445<br />
Report Viewer Redistributable 2005 368<br />
Script Repository 358<br />
Secure Development Lifecycle (SDL) 437, 443<br />
Security Response Center (MSRC) 351<br />
Small Business <strong>Server</strong>-Website 435<br />
Software-Installer-<strong>Die</strong>nst (MSI) 113<br />
Solution Accelerator Team 81<br />
System Center Configuration Manager 179, 375<br />
System Center Essentials (SCE) 351, 355, 374, 437, 457<br />
System Center Remote Operations Manager 457<br />
System Center Service Manager 355<br />
Systems Center 345<br />
Systems Management <strong>Server</strong> (SMS) 179<br />
TechNet 108, 230, 261, 352, 409, 411, 425, 453, 468<br />
Technical Security Notifications 351<br />
Update-Katalog 358<br />
Updates 181<br />
Update-Website 359<br />
Verwaltungskonsole (MMC) 95, 101, 118, 123, 259,<br />
366<br />
Microsoft <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-PKI 273<br />
MIIS (Microsoft Identity Integration <strong>Server</strong>) 267<br />
Militärisches Klassifizierungsschema 391<br />
MMC (Microsoft Management Console) 95, 101, 118, 123,<br />
259, 293, 366<br />
MOM (Operations Management) 457<br />
Monitor-Befehl 129<br />
Morello, John 146<br />
Morris-Wurm 115<br />
Moses, Wole 114<br />
Mozilla Firefox 351<br />
MS-CHAP 451<br />
msDS-AuthenticatedToAccountList 256<br />
msDS-Kennwortrichtlinien 53<br />
msDS-NeverRevealGroup 256<br />
msDS-RevealedList 256<br />
msDS-Reveal-OnDemandGroup 256<br />
Msg.exe 160<br />
MSI (Microsoft Software-Installer-<strong>Die</strong>nst) 113<br />
MSRC (Microsoft Security Response Center) 351f.<br />
MSU-Datei 356f.<br />
<strong>Windows</strong>-Abbilddatei 357<br />
Multipfad-E/A 325, 331<br />
Multi-Rollen-<strong>Server</strong> 346, 439, 468<br />
Einstellungen 451<br />
N<br />
Nachi-Wurm 162<br />
Nachrichtenhosting 441<br />
Named Pipes 154, 165<br />
Nameserver (NS) 256<br />
Namespaces 84<br />
NAP (Netzwerkzugriffsschutz) Siehe Netzwerkzugriffsschutz<br />
(NAP)<br />
NAT (Network Address Translation) Siehe Network Address<br />
Translation (NAT)<br />
National Institute of Standards and Technology (NIST) 284<br />
National Security Agency (NSA) 274<br />
NDES (Registrierungsdienst für Netzwerkgeräte) 274<br />
Stichwortverzeichnis 513<br />
NDF (Netzwerkdiagnose-Framework) 132<br />
.NET Framework 320, 324, 410<br />
NET SEND-Befehl 160<br />
Net.msmq 154<br />
Netsh advfirewall cinsec add-Befehl 398<br />
Netsh.exe 118, 128<br />
Network Access Control, Cisco 141<br />
Network Address Translation (NAT) 131<br />
IPsec 135<br />
Network Location Awareness Siehe NLA (Network Location<br />
Awareness)<br />
Netzlaufwerkzuordnung 104<br />
Netzwerkbedrohungsmodellierung 393<br />
Netzwerkdiagnose-Framework (NDF) 132<br />
Netzwerkdienst-Konto 152<br />
Netzwerk-Gruppe 10<br />
Netzwerkisolierung 183<br />
Netzwerkkommunikationsmuster 397f.<br />
Netzwerklastenausgleich 279, 325, 331<br />
Netzwerkprofile 129<br />
Netzwerkrichtlinie, Kabel und Drahtlos 208<br />
Netzwerkrichtlinien- und Zugriffsdienste 323<br />
Netzwerkrichtlinienserver (NPS) 140<br />
Ereignis-IDs 234<br />
Netzwerksicherheit 377, 403<br />
<strong>Sicherheit</strong>sabhängigkeiten 380, Siehe auch <strong>Sicherheit</strong>sabhängigkeiten<br />
Netzwerkstandort-SIDs 84<br />
Netzwerkzugriff, einschränken 175<br />
Netzwerkzugriffsschutz (NAP) 126, 139<br />
Administrationsserver 141<br />
Akronyme 140, 147<br />
Architektur 139<br />
Erzwingungsclients 143, 466<br />
Erzwingungsserver 141<br />
Implementierung 143<br />
Integritätszertifikate 136<br />
Kleine Unternehmen 466<br />
Nachrichtenpfade 144<br />
RRAS 131<br />
<strong>Sicherheit</strong>supdates 376<br />
Szenarien 146<br />
Next-Generation-TCP/IP-Stack 410<br />
NIST (National Institute of Standards and Technology) 284<br />
NLA (Network Location Awareness) 129<br />
Langsame Verbindung 194<br />
Nonce 31, 490<br />
None-SID 73, 173<br />
Northrup, Tony 467<br />
Notebooks, NAP 146<br />
Notfallwiederherstellungsplan 450<br />
NPS (Netzwerkrichtlinienserver) Siehe Netzwerkrichtlinienserver<br />
(NPS)<br />
NS (Nameserver) 256<br />
NSA (National Security Agency) 274<br />
NT-AUTORITÄT\<strong>Die</strong>nst-SID 170<br />
NTBackup 446<br />
Ntdsutil.exe 258<br />
NT-Hash 24<br />
NTLM 30f.<br />
Ereignisanzeige 232
514 Stichwortverzeichnis<br />
NTLM v2 32<br />
Anmeldeinformationen 136<br />
Ereignisanzeige 232<br />
NTLM++ 35<br />
NTOWF 24<br />
Null-DACLs 77<br />
Nutzungsabhängigkeiten 385<br />
O<br />
Oakley 134<br />
Objekte 3, 57, Siehe auch Zugriffssteuerung<br />
Besitzer ändern 82<br />
Geschützte 58<br />
Löschen 83<br />
Rechte, Liste 65<br />
Subjekt/Objekt/Aktion 3<br />
Zugriffsereignisse 233<br />
Objekt-Manager 219<br />
Objektorientierte Programmierung 7<br />
Objektzugriffsversuche, Ereignisse 219<br />
OCList.exe 330<br />
OCSetup.exe 330, 419<br />
OCSP (Online Certificate Status-Protokoll) Siehe Online<br />
Certificate Status-Protokoll (OCSP)<br />
Oechslin, Philippe 43<br />
Öffentliches Profil 120, 207<br />
Office Word 2007 309<br />
Offlineangriffe 425<br />
Offlinedateien 402<br />
Offlinezertifizierungsstellen 287<br />
Online Certificate Status-Protokoll (OCSP) 274<br />
Verfahrensempfehlungen 288<br />
Zertifikatsperrung 277<br />
Operations Management (MOM) 457<br />
Ophcrack 43<br />
Oracle 351<br />
Organisation Siehe Kleine Unternehmen<br />
Organisations-Admins 260<br />
PKI verwalten 285<br />
Zertifikatsvorlagen, Manipulationsangriffe 280<br />
Organisationsdiagramm-Klassifizierungsschema 393<br />
Organisationseinheit (OU) 249<br />
Outlook 2007 442<br />
Outlook Anywhere 438, 442, 456<br />
Outlook Web Access (OWA) 2007 442<br />
Outsourcing 455<br />
P<br />
Pakete 117<br />
Anfänge 115<br />
IPsec 133<br />
Paketmanager 357<br />
PAP (Password Authentication Protocol) 29<br />
Passgen-Tool 482<br />
Passphrase 48, 450<br />
Password Appraiser 43<br />
Password Authentication Protocol (PAP) 29<br />
Password Safe 19, 48<br />
Password Settings Container (PSC) 51<br />
Password Settings Objects (PSOs) 51<br />
Vorrang 55<br />
Patchverwaltung 349, 376<br />
Aufwand 445<br />
Phasen 349<br />
<strong>Sicherheit</strong>supdates 356<br />
Tools 358<br />
Payment Card Industry Data Security Standards (PCI/DSS)<br />
429<br />
PCR (Platform Configuration Register) 423<br />
Peer Name Resolution-Protokoll 325<br />
Peer-to-Peer-Filesharing 165, 180<br />
Penn, Jonathan 418<br />
Persönliche Daten 394<br />
Pfadbasierte <strong>Sicherheit</strong>, IIS 7.0 480<br />
PID (Prozess-ID) 232<br />
PIN-Code 38<br />
BitLocker 422, 426<br />
Pkgmgr.exe 357, 419<br />
PKI (Infrastruktur öffentlicher Schlüssel) Siehe Infrastruktur<br />
öffentlicher Schlüssel (PKI)<br />
Platform Configuration Register (PCR) 423<br />
POP 29, 40<br />
Popupdialogfelder 119<br />
Portregeln 124<br />
Ports<br />
Alternative 444<br />
Einschränken 463<br />
Hostheader, <strong>Sicherheit</strong> 479<br />
Internetzugriffsrichtlinien 444, 450<br />
Listener 154<br />
Port 80 479<br />
Port 443 479<br />
Port 8080 479<br />
Scan 450, 457<br />
<strong>Sicherheit</strong>, IIS 7.0 479<br />
<strong>Sicherheit</strong>skonfigurations-Assistent 336<br />
Statische IP 450<br />
POSIX 59<br />
PowerGUI 54<br />
PowerPoint 311<br />
PowerShell 54, 327, 358<br />
PPP-Verkehr 131<br />
Private Schlüssel<br />
Archivieren 280, 285<br />
Wiederherstellung 285<br />
Privates Profil 120, 207<br />
Privilegien 11<br />
Ändern, Risiken 89<br />
Benutzer 85<br />
Deaktiviert/aktiviert, Anmeldekonten 168<br />
<strong>Die</strong>nsthärtung 166<br />
Eingeschränkte, UAC 93<br />
Geringstmögliche Siehe Benutzerkontensteuerung<br />
(UAC)<br />
Liste 86, 166<br />
Rechte 167<br />
Token 72<br />
Verwalten 402<br />
Process Explorer 86<br />
<strong>Die</strong>nstprivilegien 169<br />
Überwachungsrichtlinien 228<br />
Produktlebenszyklen, Service Pack-Roadmap 445
Programmierschnittstelle (API) 40, 75<br />
<strong>Die</strong>nste, geänderte 178<br />
<strong>Windows</strong>-Filterplattform 116<br />
Programmregeln 124<br />
Prosch, Marilyn 455<br />
Prozesse 58<br />
Subinacl 83<br />
Prozess-ID (PID) 232<br />
Prüfsumme 20<br />
PSC (Password Settings Container) 51<br />
PSOs Siehe Password Settings Objects (PSOs)<br />
Pufferüberlaufangriffe 160, 162f.<br />
Q<br />
Quakenbush, Gerals 43<br />
Quarantäne 466<br />
QWAVE 331<br />
R<br />
RA (Remoteunterstützung) Siehe Remoteunterstützung (RA)<br />
RADIUS (Remote Authentication Dial-In User Service) 140<br />
Rainbow Crack 44<br />
Rainbow-Table-Angriffe 44<br />
RAM, <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>-Versionen 432<br />
RBAC (Rollenbasierte Zugriffssteuerung) 89<br />
RD (Remotedesktop) Siehe Remotedesktop (RD)<br />
READ_CONTROL-Recht 64<br />
Rechte<br />
Benutzer 85<br />
Besitzer 85<br />
Objektspezifische 64<br />
Privilegien 167<br />
<strong>Sicherheit</strong>shärtung, Risiken und Vorteile 211<br />
Standard 63<br />
Rechteverwaltung Siehe Active Directory-Rechteverwaltungsdienste<br />
(AD RMS)<br />
Reflektionsangriffe 388<br />
Regeln, <strong>Sicherheit</strong><br />
Ausgehende 130, 175, 207<br />
Eigenschaften 125<br />
Eingehende 207<br />
Eingeschränkter Netzwerkzugriff 175<br />
IPsec 135<br />
Typen 123<br />
Umgehung 138<br />
Verbindung 137<br />
Registerkarte Allgemein, <strong>Die</strong>nste-Konsole 155<br />
Registrierungs-Agent, Einschränkung 283<br />
Verfahrensempfehlungen 289<br />
Registrierungsdienst für Netzwerkgeräte (NDES) 274<br />
Registrierungs-Editor 103<br />
Registrierungsschlüssel 99<br />
Subinacl 83<br />
Registrierungsvirtualisierung 98f.<br />
Relative IDs (RIDs) 13f.<br />
Bekannte, domänenrelative 15<br />
Eingeschränkte, UAC 91<br />
Remote Web Workplace 434, 436, 451, 457, 467<br />
Remoteanmeldung, Angriffe 164<br />
Remotedesktop (RD) 103, 436, 452, 467<br />
Einstellungen 461<br />
Stichwortverzeichnis 515<br />
Remotedifferenzialkomprimierung 325<br />
Remoteregistrierung 458<br />
Remoteserver-Verwaltungstools 325, 419<br />
Remotestandorte Siehe Zweigstellen<br />
Remoteunterstützung (RA) 103, 112, 325, 452<br />
Einschränkungen, UAC 104<br />
Einstellungen 461<br />
Remoteverwaltung 458<br />
Remotezugriff<br />
Hersteller 455<br />
Kioskcomputer 456<br />
Kontosperrung 457<br />
Mobility 456<br />
<strong>Sicherheit</strong> 456<br />
Replikation 412<br />
Replikation, Attribute 253<br />
Report Viewer Redistributable 2005 368<br />
Request für Comment (RFC) 2617 490<br />
requestedExecutionLevel-Stufe 101<br />
requireAdministrator-Stufe 101<br />
RequiredPrivileges-Registrierungsschlüssel 168<br />
Reset-Befehl 128<br />
Ressource<br />
Zugriffseinschränkungen 403<br />
Ressourcenorganisation 270<br />
Revisor 285<br />
RFC (Request für Comment) 2617 490<br />
Richtlinien 452<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
298, 309<br />
Drahtlos/Kabelnetzwerk 208<br />
Genehmigte Nutzung 452<br />
Internetzugriff 444, 450<br />
IPsec 135f.<br />
Kennwort 49, 143, 181, 254, 450, 452, 457<br />
Netzwerk 208<br />
Überwachung 221, 264<br />
Unternehmenssicherheit 401, 452<br />
<strong>Windows</strong>-Firewall 235<br />
Zertifizierungsstellen 286<br />
RIDs (relative Bezeichner) Siehe Relative Bezeichner<br />
(RIDs)<br />
Riley, Steve 122, 149, 442<br />
Risikobewertung 431<br />
Arbeitsstationen 442<br />
Berechnung 431<br />
<strong>Server</strong>rollen 441<br />
Risikoeindämmung<br />
Gehostete Messagingserver 441<br />
Security Development Lifecycle (SDL) 443<br />
RMS-<strong>Server</strong> 300<br />
RODCs (Schreibgeschützte Domänencontroller) Siehe<br />
Schreibgeschützte Domänencontroller (RODCs)<br />
Rollen und Features, <strong>Server</strong> 320<br />
Rollenbasierte Zugriffssteuerung (RBAC) 89<br />
Rollentrennung 417, 455<br />
Rootkits 424<br />
Router 476<br />
Routing- und RAS-<strong>Die</strong>nste (RRAS) 130<br />
Akronyme, Liste 147<br />
RPC/HTTPS 29
516 Stichwortverzeichnis<br />
RPC-Schnittstelle 117<br />
Ereignis-IDs 235<br />
Listenerports 154<br />
RPC-über-HTTP-Proxy 326, 438, 441<br />
RRAS (Routing- und RAS-<strong>Die</strong>nste) Siehe Routing- und RAS-<br />
<strong>Die</strong>nste (RRAS)<br />
RSA Secure ID 18, 454, 456<br />
RSAT-BitLocker 419<br />
Russinovich, Mark 114<br />
S<br />
SACLs (Systemzugriffssteuerungslisten) Siehe Systemzugriffssteuerungslisten<br />
(SACLs)<br />
Saltwerte 21, 44<br />
SANS<br />
Internet Storm Center 352<br />
<strong>Sicherheit</strong>srichtlinienprojekt 452<br />
Sarbanes-Oxley 312<br />
SAS (Secure Attention Sequence) 29, 110<br />
SAS 70 438<br />
sc showsid-Befehl 15<br />
Sc.exe 169, 179, 181<br />
SC-Befehlszeilenprogramm 83<br />
SCE (<strong>Sicherheit</strong>skonfigurations-Editor) 70, 78<br />
SCE (System Center Essentials) 351, 355, 374, 437, 457<br />
SCEP (Simple Certificate Enrollment-Protokoll) 274<br />
SChannel-Protokoll 451<br />
Schema, AD DS 265f.<br />
Schemamaster 254<br />
Schildsymbol 97<br />
Schlüssel<br />
AMK 420<br />
ASP.NET 498<br />
Auto-Unlock 420<br />
BitLocker 421<br />
Computer 498<br />
FVEK 421<br />
Leer 423<br />
Paare 275, 288<br />
Private 280, 285<br />
Registrierung 83, 99<br />
Sitzung 37<br />
Start 423, 426<br />
Versiegeln 423<br />
Vorinstallierte 134<br />
Schlüsselmodule, Hardwarebasierte 287<br />
Schlüsselpaare<br />
Kompromittierung 275<br />
Verfahrensempfehlungen 288<br />
Schlüsselverteilungscenter (KDC) 37<br />
Anmeldeinformationen, Cache 254<br />
Zweigstellen 412<br />
Schlüsselwiederherstellungs-Agent 279, 285<br />
Verfahrensempfehlungen 289<br />
Schlüsselwort, Installationserkennung 101<br />
Schneier, Bruce 119<br />
Schnelle Benutzerumschaltung (FUS) 113<br />
Schnellmodus, IPsec 133<br />
Schreibeinschränkung 75<br />
Schreibgeschützte Domänencontroller (RODCs) 247, 252<br />
Anmeldeinformationen, Cache 254<br />
Datenbank 253<br />
Gefilterter Attributsatz 253<br />
Installation 257<br />
Schreibgeschütztes DNS 256<br />
Unidirektionale Replikation 254<br />
Zweigstellen 412<br />
Schreibgeschütztes DNS 256<br />
Schwache Kryptografie 132<br />
SCM (<strong>Die</strong>nststeuerungs-Manager) Siehe <strong>Die</strong>nststeuerungs-<br />
Manager (SCM)<br />
Scorpion Software 454, 456<br />
Script Repository 358<br />
Scruggs, Seth 278<br />
SCW (<strong>Sicherheit</strong>skonfigurations-Assistent) 180, 319, 336<br />
SDDL (Security Descriptor Definition Language) Siehe<br />
Security Descriptor Definition Language (SDDL)<br />
SDK (Software Development Kit) 67<br />
SDL (Secure Development Lifecycle) 437, 443<br />
searchFlag-Eigenschaft 265<br />
Secure Attention Sequence (SAS) 29, 110<br />
Secure Development Lifecycle (SDL) 437, 443<br />
Secure Hypertext Transfer Protocol (HTTPS) 116<br />
Secure Socket Layer (SSL) 276, 434<br />
IIS 7.0 493<br />
v2 451<br />
VPN 131<br />
Secure Socket Tunneling Protocol (SSTP) 131<br />
Security Descriptor Definition Language (SDDL) 78<br />
ACE-Flags 62<br />
Anzeigen 83<br />
Steuerflags 59<br />
Security Response Center, Microsoft (MSRC) 351<br />
Security Service Provider Interface (SSPI) 253<br />
Security Support Provider (SSP) 36<br />
SecurityScans-Ordner 364<br />
Seki, Hidenobu 35<br />
Se-Privilegien<br />
Eingeschränkte, UAC 93<br />
Liste 86, 166<br />
Überwachungsrichtlinien 226<br />
<strong>Server</strong><br />
Auswahl 431<br />
Datensicherung 411<br />
<strong>Die</strong>bstahl 424<br />
Gehostete 438<br />
Konfiguration Siehe <strong>Server</strong>konfiguration<br />
Rollen Siehe <strong>Server</strong>rollen<br />
UAC 465<br />
Wiederherstellung 446<br />
<strong>Server</strong> Core 151, 328, 410<br />
BitLocker-Installation 419<br />
Entfernte <strong>Die</strong>nste 331<br />
Features, unterstützte 331<br />
Leistung 331<br />
Rollen, unterstützte 330<br />
<strong>Server</strong> Message Block (SMB) 41, 411<br />
<strong>Server</strong>- und Domänenisolierung 378, 389
<strong>Server</strong>farm 498<br />
<strong>Server</strong>konfiguration, Kleine Unternehmen 459<br />
Antivirus/Antispyware 465<br />
DsrmAdminLogonBehavior 463<br />
Legacyanwendungen 463<br />
NAP 466<br />
UAC 464<br />
Überwachung ein/ausschalten 464<br />
<strong>Server</strong>-Manager 335, 368<br />
BitLocker-Installation 419<br />
<strong>Server</strong>ManagerCmd.exe 330, 334, 368<br />
<strong>Server</strong>rollen 319, 346<br />
Active Directory-Rechteverwaltungsdienste 293, 295, 300<br />
Entstehung 328<br />
Kleine Unternehmen 440<br />
Multi-Rollen-<strong>Server</strong> 346, 439<br />
Rollen und Features 320<br />
<strong>Server</strong> Core 328<br />
<strong>Sicherheit</strong>skonfigurations-Assistent (SCW) 336<br />
Verwaltungstools 333<br />
<strong>Server</strong>verwaltungs-Assistent 333<br />
Service Level Agreements (SLAs) 458<br />
Service Packs Siehe Patchverwaltung; <strong>Sicherheit</strong>supdates<br />
Services msc 155<br />
Set-Befehl 128<br />
SHA (Shivest Hash-Algorithmus) 274<br />
Shadow-Kennwortdatei 21<br />
SharePoint 311<br />
SHAs (Systemintegritätsagenten) 142<br />
Shims 100, 112<br />
Shivest Hash-Algorithmus (SHA) 274<br />
Show-Befehl 128<br />
SHVs (Systemintegritätsprüfungen) 140, 142<br />
Sichere Programmierung 473<br />
Sichere Tastenkombination 110<br />
Sicherer Desktop 102, 110f.<br />
<strong>Sicherheit</strong>, kleine Unternehmen Siehe Kleine Unternehmen<br />
<strong>Sicherheit</strong>, Netzwerk Siehe Netzwerksicherheit<br />
<strong>Sicherheit</strong>sabhängigkeiten 380<br />
Akzeptable 381<br />
Angriffsanalyse 383<br />
Eindämmen 389<br />
Inakzeptable 381<br />
Typen 385<br />
<strong>Sicherheit</strong>sbeschreibungen 58, 265<br />
SIDs 69<br />
Steuerflags 59<br />
<strong>Sicherheit</strong>sereignisprotokoll Siehe Ereignisprotokoll<br />
<strong>Sicherheit</strong>sfilterung, GPOs 189<br />
<strong>Sicherheit</strong>sgruppen 7<br />
<strong>Sicherheit</strong>shärtung 448<br />
Checkliste 450<br />
Risiken und Vorteile 211<br />
<strong>Sicherheit</strong>s-IDs (SIDs) 3, 12<br />
Anonym 472<br />
Autoritäten 13<br />
Bekannte 15<br />
<strong>Die</strong>nst 15<br />
<strong>Die</strong>nsthärtung 170<br />
Stichwortverzeichnis 517<br />
<strong>Sicherheit</strong>s-IDs (SIDs) (Fortsetzung)<br />
Eingeschränkte Token 75<br />
Ereignisanzeige 232<br />
Ersetzen 82<br />
Komponenten 13<br />
Netzwerkstandort 84<br />
Schreibeinschränkung 173<br />
SDDL 78<br />
<strong>Sicherheit</strong>sbeschreibungen 69<br />
Token 71<br />
<strong>Sicherheit</strong>skonfigurations-Assistent (SCW) 180, 319, 336<br />
<strong>Sicherheit</strong>skonfigurations-Editor (SCE) 70, 78<br />
<strong>Sicherheit</strong>skontenverwaltung (SAM) 4, 253<br />
LM-Hash 22<br />
Subinacl 83<br />
<strong>Sicherheit</strong>sleitfäden 379<br />
<strong>Sicherheit</strong>sprinzipale 3f.<br />
Typen 4<br />
<strong>Sicherheit</strong>sregeln erstellen, <strong>Windows</strong>-Firewall 124, 137<br />
<strong>Sicherheit</strong>srichtlinie des Unternehmens 401, 452<br />
<strong>Sicherheit</strong>sstufe 4, PKI 284<br />
<strong>Sicherheit</strong>stoken 71<br />
<strong>Sicherheit</strong>supdates 288, Siehe auch Patchverwaltung<br />
Aufwand 445<br />
Elemente 353, 357<br />
Multi-Rollen-<strong>Server</strong> 445<br />
Nicht-Microsoft 352, 355, 357, 375<br />
Priorität 353<br />
Suchen 363<br />
Testen 353, 355<br />
Websites 351<br />
<strong>Sicherheit</strong>svorfälle 430<br />
<strong>Sicherheit</strong>szuordnungen (SAs) 137<br />
SIDs (<strong>Sicherheit</strong>s-ID) Siehe <strong>Sicherheit</strong>s-ID (SIDs)<br />
Signierte Treiber 432<br />
Simple Certificate Enrollment-Protokoll (SCEP) 274<br />
Simple Network Management Protocol (SNMP) 326, 331<br />
Single Loss Expectancy, Risikoberechnung 430<br />
Sitzung-0-Isolierung 177<br />
Sitzungszustand, ASP.NET 498<br />
SKEME 134<br />
SLAs (Service Level Agreements) 458<br />
Small Business <strong>Server</strong>-Website 435<br />
Smartcard<br />
Authentifizierung 20, 38<br />
Registrierung, Einschränkung 283<br />
Smartcardanmeldung, Zertifikatsvorlage 283<br />
Smartphones 456<br />
SMB (<strong>Server</strong> Message Block) 41, 411<br />
SMS (Systems Management <strong>Server</strong>) 179, 309<br />
SMTP-<strong>Server</strong> 326, 328<br />
Snapshot-Viewer 259<br />
Sniffing/Ausspähen, Angriffe 164<br />
SNMP (Simple Network Management Protocol) 326, 331<br />
Social-Engineering-Angriffe 165<br />
Software Development Kit (SDK) 67<br />
Software Update Services/<strong>Windows</strong> <strong>Server</strong> Update Services<br />
(SUS/WSUS) 162<br />
Software, Fremdhersteller 450
518 Stichwortverzeichnis<br />
Software-Installer-<strong>Die</strong>nst, Microsoft (MSI) 113<br />
Softwareupdates Siehe Patchverwaltung; <strong>Sicherheit</strong>supdates<br />
SoH (Statement of Health) 140<br />
SoHR (Statement of Health Response) 140<br />
Soluk, Kirk 345<br />
Solution Accelerator Team 81<br />
Sosnosky, Lara 337<br />
Spam 118<br />
SpecCops 453<br />
Speichermanager für SANs 326<br />
Spezialidentitäten 9<br />
SPNs (<strong>Die</strong>nstprinzipalnamen) 153<br />
Spoofing 102, 110<br />
Spyware 39<br />
SQL <strong>Server</strong> 295, 440<br />
SQL Slammer-Angriff 181<br />
Squatting-Angriffe 227<br />
SSL (Secure Socket Layer) Siehe Secure Socket Layer (SSL)<br />
SSO (Einmalanmeldung) 27<br />
SSoHR (System Statement of Health Response) 140<br />
SSP (Security Support Provider) 36<br />
SSPI (Security Service Provider Interface) 253<br />
SSTP (Secure Socket Tunneling Protocol) 131<br />
Standard User Analyzer 108<br />
Standardauthentifizierung 29, 486<br />
Standardbenutzer 85<br />
Anhebung, Verfahrensempfehlungen 113<br />
Privilegien 168<br />
Standardbenutzertoken 91<br />
Standarddokument 474, 483<br />
Standardisierung, Authentifizierung 462<br />
Stanek, William 441<br />
Startmodus, <strong>Die</strong>nste 154<br />
Startparameter-Feld 157<br />
Startprogramme, Blockierte 106<br />
Startschlüssel 423, 426<br />
Starttyp-Feld 157<br />
Statement of Health Response (SoHR) 140<br />
Steuerflags 59<br />
Stimmerkennung, Authentifizierung 18<br />
Stringliterale 239<br />
Strukturbeziehungen 69<br />
SUA (Subsystem für Unix-basierte Anwendungen) 326, 331<br />
Subauthentifizierungspakete, Kennwortangriffe 40<br />
Subinacl 83<br />
Subjekte 3, Siehe auch <strong>Sicherheit</strong>sprinzipale<br />
Subjekt/Objekt/Aktion 3<br />
subnetMask 477<br />
Subsystem für Unix-basierte Anwendungen (SUA) 326, 331<br />
Suite-B-Algorithmen 274<br />
Sullivan, Kevin 201<br />
Sun Microsystems 351<br />
SUS/WSUS (Software Update Services/<strong>Windows</strong> <strong>Server</strong><br />
Update Services) 162<br />
Svchost.exe 76<br />
Synchronisierung, Kerberos 37<br />
SYNCHRONIZE-Recht 64<br />
.sys-Erweiterung 98<br />
Syskey-<strong>Sicherheit</strong> 288<br />
System Center Configuration Manager 179, 375<br />
System Center Essentials (SCE) 351, 355, 374, 437, 457<br />
System Center Remote Operations Manager 457<br />
System Center Service Manager 355<br />
Systemintegritätsagenten (SHAs) 142<br />
Systemintegritätsprüfungen (SHVs) 140, 142<br />
Systems Center 345<br />
Systems Management <strong>Server</strong> (SMS) 179, 309<br />
Systemstatusdatensicherung 447<br />
Systemzugriffssteuerungslisten (SACLs) 59, 61<br />
AD DS-Überwachung 265<br />
Integritätsebenen 77<br />
Überwachungsrichtlinien 220, 227, 261<br />
Systemzustandssicherung 180<br />
T<br />
Tastatureingaben, Aufzeichnung 19, 39, 456<br />
TCO (Total Cost of Ownership) 113<br />
TCP (Transmission Control Protocol) Siehe Transmission<br />
Control Protocol (TCP)<br />
TCP/IP (Transmission Control Protocol/Internet Protocol<br />
Siehe Transmission Control Protocol/Internet Protocol<br />
(TCP/IP)<br />
TechNet 108, 230, 261, 331, 352, 409, 411, 425, 453, 468<br />
Technical Security Notifications 351<br />
Teilautoritäten 13f.<br />
Bekannte, Liste 14<br />
Telnet 29, 40<br />
Client 327f., 331<br />
<strong>Server</strong> 327<br />
Terminaldienste 41, 168, 253, 323, 382<br />
Terminalserver 194, 455<br />
Terminalservergateway 142, 457<br />
TFTP-Client 327f.<br />
TGS (Ticket Granting Service) 37, 413<br />
TGT (Ticket Granting Ticket) 37, 254<br />
Threads 58<br />
Ticket Granting Service (TGS) 37, 413<br />
Ticket Granting Ticket (TGT) 37<br />
Anmeldeinformationen, Cache 254<br />
Tipprhythmus<br />
Authentifizierung 18<br />
Tastatureingaben, Aufzeichnung 39<br />
Tissieres, Cedric 43<br />
TLS (Transport Layer Security) 116, 493<br />
Token 16, 71<br />
als Authentifizierer 18<br />
Eingeschränkte 75<br />
Filterung 91<br />
Zugriffsprüfungen 74<br />
Token-basierte Anwendungen 271<br />
Toleranz, Abweichung der Computeruhren 37<br />
Total Cost of Ownership (TCO) 113<br />
TPM (Trusted Platform Module) Siehe Trusted Platform<br />
Module (TPM)<br />
Transmission Control Protocol (TCP) 120<br />
Listenerports 154<br />
Transmission Control Protocol/Internet Protocol (TCP/IP)<br />
116<br />
IIS 7.0 476<br />
Next-Generation-Stack 410<br />
Transport Layer Security (TLS) 116, 493<br />
Transportmodus, IPsec 134
Triple-DES-Verschlüsselung 499<br />
Trusted Platform Module (TPM) 287, 419<br />
BitLocker 422<br />
TrustedInstaller 84, 177<br />
Trustworthy Computing (TwC) 473<br />
TS-Gateway (Terminalserver) 142, 457<br />
Tunnelmodus, IPsec 134<br />
Turbeyville, Bruce 430<br />
TwC (Trustworthy Computing) 473<br />
U<br />
UAC (Benutzerkontensteuerung) Siehe Benutzerkontensteuerung<br />
(UAC)<br />
Überwachung 3, 217, 242, 443<br />
Active Directory-Domänendienste (AD DS) 261<br />
Aktivieren/Deaktivieren 464<br />
Benutzerspezifische Überwachung 228<br />
<strong>Die</strong>nstfehler 183<br />
Ereignisanalyse 236<br />
Kennwort 181<br />
Richtlinie entwickeln 229<br />
Richtlinie, global 264<br />
Richtliniendelegierung 228<br />
Richtlinieneinstellung 221<br />
Richtlinienoptionen 225<br />
<strong>Sicherheit</strong>skonfigurations-Assistent 337<br />
Überwachungslisten 218<br />
Verfahrensempfehlungen 289<br />
Überwachungsereignisse, IPsec 138<br />
UDDI-<strong>Die</strong>nste 323<br />
UDP (User Datagram Protocol) 120<br />
Ui0detect 177<br />
UIAccess-Anwendungen 109, 111<br />
UIPI (User Interface Privilege Isolation) 102<br />
Umgehungsregeln 138<br />
Umkehrbar verschlüsselte Kennwörter 27<br />
Unautorisierte Informationensweitergabe, Angriffe 165<br />
Uneingeschränkte SIDs 173<br />
Unidirektionale Funktionen 22<br />
Unidirektionale Replikation 254<br />
Unified-Messaging-<strong>Server</strong> 440<br />
United States Computer Emergency Readiness Team<br />
(US-CERT) 352<br />
Universelle Gruppen 7<br />
Unix 21<br />
Unsignierte Treiber 432<br />
Unternehmensgeeignete Authentifizierer 18<br />
Unternehmenszertifizierungsstellen 273<br />
Update-Katalog, Microsoft 358<br />
Updatekonfigurationsassistent 375<br />
Update-Website, Microsoft 359<br />
URLs<br />
Anforderungsfilterung 495<br />
ASP.NET 498<br />
Zertifikatsperrprüfung 276<br />
URLScan-Tool 495<br />
USB-Flashlaufwerke<br />
Einschränken 204<br />
Schlüsselspeicherung 422, 426<br />
<strong>Server</strong>datensicherung 447<br />
<strong>Sicherheit</strong> 377<br />
Stichwortverzeichnis 519<br />
US-CERT (United States Computer Emergency Readiness<br />
Team) 352<br />
USENET 116<br />
User Datagram Protocol (UDP) 120<br />
User Interface Privilege Isolation (UIPI) 102<br />
user32.exe 29<br />
UTF-8 500<br />
V<br />
Vamosi, Robert 456<br />
VBScript 358<br />
Verarbeitung, Gruppenrichtlinien 193<br />
Verben, Anforderungsfilterung 497<br />
Verbessertes <strong>Windows</strong>-Audio-/Video-Streaming 325<br />
Verbindungs-Manager-Verwaltungskit 132, 324<br />
Verbunddienst 270<br />
Verbunddienstproxy 271<br />
Vererbung 69<br />
Konfigurationsdateien, IIS 7.0 475<br />
Vererbungsmodell, Active Directory 7<br />
Verfahrensempfehlungen<br />
Kleine Unternehmen 447<br />
UAC 112<br />
Zertifikatdienste 288<br />
Vergleichsangriffe 21<br />
Verknüpfte Zugriffstokens 105<br />
Veronica-Suchmaschine 116<br />
Verschlüsselung 20<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
293<br />
BitLocker 419<br />
Dokumente 293<br />
LM-Hash 23<br />
Schlüssel, ASP.NET 498<br />
Umkehrbare 27<br />
Versiegeln, Schlüssel 423<br />
Version-3-Zertifikatsvorlagen 274<br />
Versionen, Gruppenrichtlinien 195<br />
Verteilergruppen 8<br />
Verteiltes Dateisystem, Replikation (DFSR) 254, 389<br />
Vertrauenswürdige Stammzertifizierungstellen, Hinzufügen<br />
281<br />
Vertrauenswürdiger Pfad für Anmeldeinformationseintrag<br />
erforderlich, Gruppenrichtlinieneinstellung 110<br />
Verwalten<br />
Arbeitsstationen, Kontrolle 459<br />
Berechtigungen 81<br />
Fremdhersteller 458<br />
Remotezugriff 458<br />
System Center Essentials (SCE) 457<br />
Verwalten von Überwachungs- und <strong>Sicherheit</strong>sprotokollen,<br />
Privileg 228<br />
Verwaltungskonsole, Microsoft (MMC) 95, 101, 118, 123,<br />
259, 366<br />
Verweigern-SIDs 74<br />
Verwundbarkeit 354<br />
Verzeichnis durchsuchen 484<br />
Verzeichnisdienst 233<br />
Verzeichnisdienständerungen 261f.<br />
Verzeichnisdienstreplikation 262<br />
Verzeichnisdienstwiederherstellung (DSRM) 5, 252
520 Stichwortverzeichnis<br />
Verzeichnisdienstzugriff überwachen 264<br />
Verzeichnisse 58<br />
Angriffe 481<br />
Durchsuchen, IIS 7.0 483<br />
Verzeichnisspeicher 266<br />
Virtual <strong>Server</strong> 445<br />
virtualDirectory, IIS 7.0 482<br />
Virtualisierte <strong>Server</strong> 408, 410<br />
Virtualisierung 445<br />
Datei und Registrierung 98, 110<br />
<strong>Server</strong> 438<br />
Virtuelle Private Netzwerke (VPN) 456<br />
Erzwingungsmethoden 141<br />
MS-CHAP 451<br />
RRAS 131f.<br />
<strong>Sicherheit</strong> 378<br />
Zertifikatprüfung 132<br />
Zugriffseinschränkungen 450<br />
Zweigstellen 406<br />
Virtueller Speicher, Verzeichnis 98<br />
Virtuelles Hosting 500<br />
Vollqualifizierte Domänennamen (FQDNs) 31<br />
Vollständige Zugriffstoken 91<br />
Verknüpfte 105<br />
Vollzugriff, Berechtigungen 182<br />
Volume Master Key (VMK) 422<br />
Volumeschattenkopiedienst (VSS) 260, 411<br />
Vordefinierte Regeln 124<br />
Vordergrundverarbeitung 193<br />
Vorinstallierte Schlüssel 134<br />
Vorlagen, RMS-Richtlinien 309<br />
Vorrang<br />
Abgestimmte Kennwortrichtlinien 55<br />
GPOs 188<br />
VPN (Virtuelles Privates Netzwerk) Siehe Virtuelle Private<br />
Netzwerke (VPN)<br />
VSS (Volumeschattenkopiedienst) 260, 411<br />
W<br />
WAIS (Wide-Area Information <strong>Server</strong>) 116<br />
WANs (Wide Area Network) 406, 408, 410f.<br />
Ward, Richard B. 13<br />
Wartung, Multi-Rollen-<strong>Server</strong> 445<br />
Wartungsserver 141<br />
Wbadmin-Befehle 447<br />
WDS (<strong>Windows</strong>-Bereitstellungsdienste) 323, 402<br />
Web.config-Dateien, IIS 7.0 475<br />
ASP.NET-Identitätswechsel 490<br />
ASP.NET-<strong>Server</strong>farm 499<br />
Formularauthentifizierung 491<br />
<strong>Windows</strong>-Authentifizierung 492<br />
Webbannerwerbung 442<br />
Webbrowser 331<br />
WebDAV 496<br />
Webmail 442<br />
Webserver 323, 328, 476, Siehe auch Internetinformationsdienste<br />
7.0 (IIS 7.0)<br />
Installation 368<br />
Websites<br />
Authentifizierte und anonyme 433<br />
Erstellen 433, 474, 500<br />
Websites (Fortsetzung)<br />
Pfadbasierte <strong>Sicherheit</strong>, IIS 7.0 480<br />
<strong>Sicherheit</strong>supdates 351<br />
Social Networking 442<br />
Webzugriffsrichtlinien 444, 450<br />
Wechselmediengeräte<br />
Einschränken 204<br />
<strong>Sicherheit</strong> 377<br />
Wechselmedien-Manager 325, 331<br />
WEvtUtil.exe 235, 242<br />
WFP (<strong>Windows</strong>-Filterplattform) 116, 411<br />
Whitelisting 476<br />
Wide Area Network (WAN) 406, 408, 410f.<br />
Wide-Area Information <strong>Server</strong> (WAIS) 116<br />
Wiederherstellung, <strong>Server</strong> 446<br />
Wiederherstellung-Registerkarte, <strong>Die</strong>nste-Konsole 159<br />
Wiederherstellungsplan Siehe auch Datensicherung, Richtlinien<br />
Wiederherstellungsverfahren, <strong>Server</strong> 446<br />
Wilson, Tim 430<br />
WIM (<strong>Windows</strong>-Abbilddatei) 357<br />
<strong>Windows</strong><br />
Angriffe mit vorberechneten Hashwerten 43<br />
Authentifizierung 492<br />
Automatische Updates 360<br />
Bitnummerierung 58<br />
LMCompatibilityLevel 32<br />
NLTM++ 35<br />
NTLM v2 32<br />
Privilegien, Eingeschränkte 93<br />
<strong>Server</strong> 2003 5, 32, 230, 258, 328, 366, 474<br />
<strong>Sicherheit</strong>sprinzipale 4<br />
SMB 411<br />
UAC-Kompatibilitätskonfiguration 107<br />
Versionen auswählen 431<br />
<strong>Windows</strong> 2000 4, 35<br />
<strong>Windows</strong> XP 5, 10, 366, 461<br />
Zugriffssteuerung 57<br />
<strong>Windows</strong> Automated Installation Toolkit 357<br />
<strong>Windows</strong> Essential Business <strong>Server</strong> 346, 433, 437, 443, 447<br />
<strong>Windows</strong> Management Instrumentation (WMI) 161, 179,<br />
410, 457<br />
Abfragesprache (WQL) 191<br />
BitLocker 421<br />
GPO-Filterung 191<br />
<strong>Windows</strong> Management Instrumentation-Befehlszeile<br />
(WMIC) 179<br />
<strong>Windows</strong> Media Player 331<br />
<strong>Windows</strong> NT 4f.<br />
LM-Hash 22<br />
NT-Hash 24<br />
Service Pack 4 32<br />
SIDs 15<br />
WSUS 366<br />
<strong>Windows</strong> PowerShell 54, 327, 358<br />
<strong>Windows</strong> <strong>Server</strong> 2003 299<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 5<br />
32- und 64-Bit-Version 432<br />
Abgestimmte Kennwortrichtlinien 50<br />
Active Directory Lightweight Directory Services<br />
(AD LDS) 268
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> (Fortsetzung)<br />
Active Directory-Domänendienste (AD DS) 270<br />
Active Directory-Verbunddienste (AD FS) 270<br />
Anwendungsinformationsdienst (AIS) 97<br />
Benutzerkontensteuerung (UAC) 91, 111, Siehe auch<br />
Benutzerkontensteuerung (UAC)<br />
BitLocker-Laufwerkverschlüsselung 418f.<br />
Datacenter Edition 281, 283, 285, 321, 331<br />
<strong>Die</strong>nstberechtigungen 11<br />
Drahtlosnetzwerkrichtlinie 209<br />
Enterprise Edition 281, 283, 285, 321, 331<br />
Ereignisprotokoll, Verbesserungen 220, 230<br />
Gruppenrichtlinien 185, 197, Siehe auch Gruppenrichtlinien<br />
Infrastruktur für öffentliche Schlüssel (PKI) 274<br />
Integritätsebenen 76<br />
IPsec, Verbesserungen 135<br />
Kennwortverifizierer 25<br />
Leere Kennwörter 42<br />
Leistung 328<br />
LMCompatibilityLevel 32<br />
LM-Hash 22<br />
NAP 139<br />
NTLM v2 32<br />
Privilegien, Liste 86, 166<br />
Security Guide 230<br />
<strong>Server</strong>datensicherung 411<br />
<strong>Server</strong>features, Liste 324<br />
<strong>Server</strong>rollen, Liste 321<br />
SIDs 14<br />
Standard Edition 321<br />
User Interface Privilege Isolation (UIPI) 102<br />
Versionen, in kleinen Unternehmen 431<br />
Web Edition 433<br />
WSUS 366<br />
Zugriffssteuerung, Änderungen 84<br />
Zweigstellen 409<br />
<strong>Windows</strong> <strong>Server</strong> Code Name Cougar 346, 439, 443, 447,<br />
466<br />
<strong>Windows</strong> <strong>Server</strong> Update Services (WSUS) 355, 366<br />
Anforderungen 369<br />
Clientkonfiguration 373<br />
Installation 370<br />
Neue Features 366<br />
Unterstützte Produkte 367<br />
Updates testen 355<br />
Voraussetzungen 367<br />
Webserverrolle installieren 368<br />
<strong>Windows</strong> <strong>Server</strong>-Sicherungsfeatures 327<br />
<strong>Windows</strong> <strong>Server</strong>-Virtualisierung 410<br />
<strong>Windows</strong> SharePoint Services 438<br />
<strong>Windows</strong> Small Business <strong>Server</strong> 346, 456<br />
<strong>Windows</strong> Sysinternals Process Explorer 154<br />
<strong>Windows</strong> Systems State Analyzer 452<br />
<strong>Windows</strong> Update 359<br />
<strong>Windows</strong> Vista 5<br />
Anwendungsinformationsdienst (AIS) 97<br />
Benutzerkontensteuerung (UAC) 91, 111, Siehe auch<br />
Benutzerkontensteuerung (UAC)<br />
BitLocker-Laufwerkverschlüsselung 418<br />
<strong>Die</strong>nstberechtigungen 11<br />
Stichwortverzeichnis 521<br />
<strong>Windows</strong> Vista (Fortsetzung)<br />
Drahtlosnetzwerkrichtlinie 209<br />
Ereignisprotokoll, Verbesserungen 220<br />
Firewalleinstellungen 461<br />
Gruppenrichtlinien 185, 197, Siehe auch Gruppenrichtlinien<br />
Integritätsebenen 76<br />
Kennwortverifizierer 25<br />
LMCompatibilityLevel 32<br />
LM-Hash 22<br />
NAP 139<br />
NT Siehe <strong>Windows</strong> NT<br />
NTLM v2 32<br />
<strong>Server</strong> <strong>2008</strong> Siehe <strong>Windows</strong> <strong>Server</strong> <strong>2008</strong><br />
SIDs 14<br />
Überwachungssubsystem Siehe Überwachung<br />
User Interface Privilege Isolation (UIPI) 102<br />
Vista Siehe <strong>Windows</strong> Vista<br />
WSUS 366<br />
Zugriffssteuerung Siehe auch Zugriffssteuerung<br />
<strong>Windows</strong> Web <strong>Server</strong> <strong>2008</strong> 433<br />
<strong>Windows</strong>-Abbilddatei (WIM) 357<br />
<strong>Windows</strong>-Bereitstellungsdienste (WDS) 323, 402<br />
<strong>Windows</strong>-Codeintegrität 424<br />
<strong>Windows</strong>-<strong>Die</strong>nsthärtung 118<br />
<strong>Windows</strong>-Explorer 331, 410<br />
<strong>Windows</strong>-Filterplattform (WFP) 116, 411<br />
<strong>Windows</strong>-Firewall mit erweiterter <strong>Sicherheit</strong> 118<br />
Akronyme, Liste 147<br />
Einstellungen 461<br />
Ereignis-IDs 234<br />
Gruppenrichtlinien 206<br />
IPsec-Richtlinie 135f.<br />
Kommunikationseinschränkungen 402<br />
Netzwerkisolierung 183<br />
Richtlinienänderung, Ereignisse 235<br />
Service Pack 2 119<br />
Verbesserungen 118<br />
Verwalten 122<br />
<strong>Windows</strong>-Lastausgleichdienste 288<br />
<strong>Windows</strong>-Netzwerk 41<br />
<strong>Windows</strong>-Prozessaktivierungsdienst 320, 327<br />
<strong>Windows</strong>-Systemintegritätsagent (WSHA) 142<br />
<strong>Windows</strong>-Systemressourcen-Manager (WSRM) 320, 327<br />
WinLogon 29<br />
Gruppenrichtlinien 197<br />
RRAS 132<br />
Smartcardauthentifizierung 38<br />
WINS (<strong>Windows</strong> Internet Name Service) 320, 331<br />
<strong>Server</strong> 327<br />
WINS-<strong>Server</strong> 327<br />
WLAN-<strong>Die</strong>nst 327<br />
WMI (<strong>Windows</strong> Management Instrumentation) Siehe<br />
<strong>Windows</strong> Management Instrumentation (WMI)<br />
WMIC (<strong>Windows</strong> Management Instrumentation-Befehlszeile)<br />
179<br />
Wood, Charles Cresson 452<br />
World Wide Web 116<br />
WRITE_DAC-Recht 64<br />
WRITE_OWNER-Recht 64<br />
WS-Federation Passive Requestor Profile (WS-F PRP) 271
522 Stichwortverzeichnis<br />
WSHA (<strong>Windows</strong>-Systemintegritätsagent) 142<br />
WS-Management 410<br />
WSRM (<strong>Windows</strong>-Systemressourcen-Manager) 320, 327<br />
WSUS (<strong>Windows</strong> <strong>Server</strong> Update Services) Siehe <strong>Windows</strong><br />
<strong>Server</strong> Update Services (WSUS)<br />
Wuauclt.exe /detectnow 374<br />
Wusa.exe 356<br />
X<br />
X.509-Zertifikat 38<br />
x64-Architektur 59<br />
x86-Architektur 59<br />
XCOPY 472<br />
XML-Format 356<br />
Clientzertifikatzuordnung 490<br />
Ereignisanalyse 236, 240<br />
Ereignisprotokoll 220<br />
IIS 7.0 482, 473, 478, 500<br />
WSUS-Installation 368<br />
XPATH 239<br />
Z<br />
Zeichenfolge, Privilegien 86<br />
Zeichensätze, sichere Kennwörter 46<br />
Zentraler Speicher 197<br />
Zentralisierung 408<br />
Zertifikatdienste 273, 289, 321<br />
Bedrohungen und Eindämmung 275<br />
Schützen 286<br />
Starten/Beenden, Versuche 280<br />
Verfahrensempfehlungen 288<br />
Zertifikate 20<br />
Active Directory-Rechteverwaltungsdienste (AD RMS)<br />
310<br />
Digitale, IPsec 134<br />
Fremdhersteller 450<br />
Nicht autorisierte 283<br />
SSL 493<br />
Systemintegrität 136<br />
Überprüfen, RRAS 132<br />
Website 276<br />
X.509 38<br />
Zuordnung 487<br />
Zertifikatsicherheit 273<br />
Zertifikatsperrliste (CRL) 276f.<br />
Mehrere <strong>Server</strong> 277<br />
Überprüfen 288<br />
Zertifikatsperrprüfung verhindern 276<br />
Zertifikatsvorlagen<br />
Manipulationsversuche 279<br />
Version 1 281<br />
Version 2 281<br />
Version 3 274, 281<br />
Zertifikatverwaltung 284, 286<br />
Verfahrensempfehlungen 288<br />
Zertifizierungsserver 296<br />
Zertifizierungsstelle 134, 273<br />
Manipulationsversuche 279<br />
Mehrere <strong>Server</strong> 277<br />
Nicht vertrauenswürdige hinzufügen 281<br />
Offline 287, 289<br />
Online 289<br />
Zertifikatsperrung 276<br />
Zertifizierungsstellenadministrator 284<br />
Zugriffsabhängigkeiten 386<br />
Zugriffsmasken 63<br />
Zugriffssteuerung 57, 89<br />
Benutzerrechte und Privilegien 85<br />
Berechtigungen verwalten Siehe Berechtigungen verwalten<br />
Geschützte Objekte 58<br />
Identitätsbasierte 89<br />
Integritätsebenen 76<br />
Leere und Null-DACLs 77<br />
Listen Siehe Zugriffssteuerungslisten (ACLs)<br />
RBAC/AZMAN 89<br />
Rollenbasierte 89<br />
Security Descriptor Definition Language (SDDL) 78<br />
<strong>Sicherheit</strong>sbeschreibungen 58<br />
<strong>Sicherheit</strong>stoken 71<br />
Strukturbeziehungen 69<br />
Vererbung 69<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 84<br />
Zugriffsmasken 63<br />
Zugriffsprüfungen 74<br />
Zugriffssteuerungseinträge (ACEs) 61<br />
Ändern 81<br />
SDDL 80<br />
Vererbung 69<br />
Zugriffssteuerungslisten (ACLs) 12, 60<br />
Discretionary Siehe Discretionary Access Control List<br />
(DACLs)<br />
Editor 67, 81<br />
Einträge (ACE) 61<br />
Ereignis-IDs 235<br />
MACLs 60f.<br />
Speichern und Wiederherstellen 82<br />
System Siehe Systemzugriffssteuerungslisten (SACLs)<br />
Typen 59f.<br />
Überwachung 220<br />
Vererbung 69<br />
Zurücksetzen 82<br />
Zustimmungs-Eingabeaufforderungen 95<br />
Sicherer Desktop 102<br />
Zweigstellensicherheit 405<br />
BitLocker-Laufwerkverschlüsselung 418<br />
Entwickeln 407<br />
RODC 412<br />
Schritte 426<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong> 409<br />
Zwischengespeicherte Anmeldeinformationen 25, 254, 412,<br />
482
<strong>Die</strong> Autoren<br />
<strong>Die</strong>ses Buch wurde nach einem etwas anderen Verfahren geschrieben als frühere <strong>technische</strong><br />
<strong>Referenz</strong>en. Statt einen Hauptautor zu bestimmen, der den Großteil des Textes schreibt,<br />
wurden die einzelnen Kapitel von unterschiedlichen Experten verfasst, die sich in ihrem<br />
jeweiligen Gebiet perfekt auskennen. <strong>Server</strong> sind komplizierte Gebilde, <strong>Windows</strong> <strong>Server</strong> ist<br />
da keine Ausnahme. Indem wir auf Topexperten in den verschiedenen Gebieten zurückgriffen,<br />
waren wir in der Lage, eine <strong>technische</strong> <strong>Referenz</strong> zum Thema <strong>Sicherheit</strong> zusammenzustallen,<br />
die profunde Fachkenntnisse vermittelt. Daher hat dieses Buch die eindrucksvolle<br />
Zahl von 12 Autoren.<br />
Jesper M. Johansson<br />
Jesper M. Johansson ist der Hauptautor. Er entwarf den Aufbau und<br />
stellte das Autorenteam zusammen. Während die Koautoren das Lob<br />
für die hervorragenden Texte beanspruchen können, die sie geschrieben<br />
haben, bleibt an Jesper M. Johansson die Kritik hängen, falls wichtige<br />
Themen nicht behandelt wurden.<br />
Jesper M. Johansson ist eine anerkannte Autorität auf dem Gebiet der<br />
Datensicherheit im Allgemeinen und der <strong>Windows</strong>-<strong>Sicherheit</strong> im Speziellen.<br />
Momentan ist er als leitender Softwaresicherheitsarchitekt<br />
beschäftigt, wobei er Softwareinfrastrukturen entwirft. Vorher arbeitete<br />
Jesper für Microsoft an <strong>Sicherheit</strong>sproblemen, seine Aufgaben dabei<br />
reichten vom Versuch, sich in Netzwerke einzuhacken, bis zum Entwurf von <strong>Sicherheit</strong>ssoftware.<br />
Jesper hat Vorträge zu Datensicherheit auf fünf Kontinenten gehalten, auf den<br />
meisten wichtigen <strong>Sicherheit</strong>skonferenzen gesprochen, viele Artikel zum Thema <strong>Sicherheit</strong><br />
geschrieben und ist Microsoft Security Most Valuable Professional (MVP). Er hat im Fach<br />
Management Information Systems promoviert und ist Certified Information Systems Security<br />
Professional (CISSP) sowie zertifizierter Information Systems Security Architecture<br />
Professional (ISSAP). Wenn Jesper nicht mit Datensicherheit beschäftigt ist, bringt er anderen<br />
Gerätetauchen bei.<br />
Jimmy Andersson<br />
Jimmy Andersson ist Consultant und leitender Berater bei Q Advice<br />
AB in Schweden. Sein Spezialgebiet sind Verzeichnisdienste. Außerdem<br />
hält er Seminare und Vorträge. Er hat einen eigenen Kurs zu<br />
Active Directory mit dem Titel »AD Troubleshooting and Advanced<br />
Theory« entwickelt. <strong>Die</strong> letzten neun Jahre bekam er jedes Jahr den<br />
Titel MVP von Microsoft verliehen. Er wird oft als Projektleiter für<br />
Verzeichnisdienste in Großunternehmen angeheuert.<br />
523
524 <strong>Die</strong> Autoren<br />
Susan Bradley<br />
Susan benutzt Computer, seit ihr Unternehmen erstmals einen IBM<br />
8088 anschaffte. Als die Person im Büro, die sich »mit Technik auskennt«,<br />
hat sie die Entwicklung von Einzelcomputern über Disketten<br />
und Novell begleitet, bis sie schließlich bei Microsoft-Netzwerken<br />
landete. Neben der Arbeit bei Wartung und Planung der Technik in<br />
ihrem Unternehmen hat sie ihre Rollen in verschiedenen Industrievereinigungen<br />
genutzt, um bessere und sicherere Software für Kleinunternehmen<br />
zu fördern. Wenn sie nicht mit ihrem Blog sbsdiva.com beschäftigt<br />
ist, schreibt sie zum Thema Softwarepatches auf <strong>Windows</strong>-<br />
Secrets.com. Außerdem drängt sie über ihre Website threatcode.com<br />
Hersteller, sicherer zu programmieren. Sie mag <strong>Windows</strong> Vista, und während sie ihr Kapitel<br />
und zusätzliche Materialien für das Buch verfasste, bekam sie nicht eine einzige UAC-Eingabeaufforderung<br />
angezeigt. Susan ist <strong>Windows</strong> Small Business <strong>Server</strong> MVP.<br />
Darren Canavor<br />
Darren Canavor arbeitet als Softwarearchitekt bei Microsoft. Er wurde<br />
1999 dort angestellt und hat wichtige Beiträge zu <strong>Sicherheit</strong>sarchitektur<br />
und Tests beim <strong>Windows</strong>-Kernbetriebssystem geleistet, darunter<br />
zur PKI in <strong>Windows</strong> 2000, den Zertifikatdiensten in <strong>Windows</strong> <strong>Server</strong><br />
2003 und zuletzt der Benutzerkontensteuerung in <strong>Windows</strong> Vista und<br />
<strong>Windows</strong> <strong>Server</strong> <strong>2008</strong>. Darren ist Koautor etlicher Whitepapers und<br />
Microsoft Press-Bücher über Microsoft-<strong>Sicherheit</strong> und -PKI, zum Beispiel<br />
<strong>Windows</strong> Vista Security Guide and Planning und »Implementing<br />
Cross-Certification and Qualified Subordination Using <strong>Windows</strong><br />
<strong>Server</strong> 2003«.<br />
Kurt Dillard<br />
Kurt lebt in Buenos Aires, der faszinierenden Hauptstadt von Argentinien.<br />
Er schreibt Bücher, Artikel und andere Texte, in denen er Möglichkeiten<br />
präsentiert, die Probleme beim Schutz von digitalen Daten<br />
und der Computer, auf denen sie gespeichert sind, zu lösen. Er hat<br />
Beiträge zu vielen der von Microsoft veröffentlichten Lösungen geliefert,<br />
zum Beispiel »<strong>Windows</strong> <strong>Server</strong> 2003 Security Guide«, »Security<br />
Risk Management Guide« und »Threats and Countermeasures: Security<br />
Settings in <strong>Windows</strong> <strong>Server</strong> 2003 and <strong>Windows</strong> XP«. Kurt hat<br />
Vorträge auf zahlreichen Konferenzen gehalten, darunter RSA, TechEd<br />
und Microsoft Federal Security Summits. Seine aktuellen Zertifizierungen<br />
sind unter anderem CISSP, ISSAP, CISM und MCSE + Security.
Eric Fitzgerald<br />
Eric ist CISSP und MCSE. Er arbeitet in der Produktabteilung Forefront<br />
Security bei Microsoft, wo er sich auf die Analyse von Daten aus<br />
<strong>Sicherheit</strong>ssensoren spezialisiert hat. Er hat sechs Jahre im <strong>Windows</strong><br />
Core OS Security-Team an Überwachungs- und Autorisierungstechnologien<br />
für <strong>Windows</strong> gearbeitet und war mehrere Jahre im Support<br />
für Microsoft-Unternehmenskunden in den Bereichen <strong>Sicherheit</strong>, Netzwerke<br />
und Verzeichnisdienste tätig. Außerhalb des Bereichs Datensicherheit<br />
beschäftigt sich Eric gern mit Segelregatten.<br />
Roger Grimes<br />
Roger A. Grimes ist CPA, CISSP, CISA und MCSE: Security. Er ist<br />
seit 22 Jahren als Spezialist für Hostsicherheit, PKI, Identitätsverwaltung<br />
und Schutz vor Hackern und Malware tätig. Roger arbeitet als<br />
leitender <strong>Sicherheit</strong>sconsultant für das ACE-Team von Microsoft. Er<br />
schreibt eine Kolumne zum Thema <strong>Sicherheit</strong> für das Magazin Info-<br />
World, ist Autor oder Koautor von 8 Büchern über Computersicherheit<br />
und hat über 200 Artikel für Fachzeitschriften verfasst. Roger betreibt<br />
8 Honeypots, die verdächtige Hackeraktivitäten aufdecken. Er ist auf<br />
der ganzen Welt unterwegs, um Vorträge auf Konferenzen zu halten<br />
und Kunden zu helfen, die bestmögliche <strong>Sicherheit</strong> zu erreichen.<br />
Byron Hynes<br />
Byron Hynes ist Enterprise Technology Strategist bei Microsoft. Seit er<br />
2005 bei Microsoft anfing, hat er sich auf <strong>Sicherheit</strong>stechnologien wie<br />
BitLocker-Laufwerksverschlüsselung, Benutzerkontensteuerung und<br />
viele andere konzentriert. Byron arbeitet direkt mit Kunden und hat<br />
Beiträge zu Hilfetexten, Websites, Magazinartikeln, Büchern und Vorträgen<br />
verfasst. So oft ihm sein Chef erlaubt, verlässt er sein heimeliges<br />
Büro, um Konferenzen, Tagungen oder Kunden zu besuchen.<br />
Byron wurde in Kanada geboren und verbrachte den größten Teil seines<br />
Lebens im arktischen Winter des hohen Nordens. Er kann immer<br />
noch nicht ganz glauben, dass er in den Vorstädten von Redmond,<br />
Washington, gelandet ist. Byron ist verheiratet und hat zwei kleine,<br />
sehr lebhafte Söhne.<br />
<strong>Die</strong> Autoren 525
526 <strong>Die</strong> Autoren<br />
Alun Jones<br />
Alun Jones ist Besitzer von Texas Imperial Software, einer Firma, die<br />
sichere Netzwerksoftware entwickelt und Consultingdienste für die<br />
<strong>Sicherheit</strong>splanung anbietet. Das wichtigste Produkt von Texas Imperial<br />
Software ist WFTPD Pro, ein sicherer FTP-<strong>Server</strong> für <strong>Windows</strong>,<br />
der vollständig von Alun geschrieben wurde.<br />
Alun verlagerte seine Aktivitäten in den Bereich <strong>Sicherheit</strong>, als sich<br />
beim Support für WFTPD zeigte, dass nur wenige Unternehmen in der<br />
Lage sind, ihre <strong>Sicherheit</strong>sanforderungen im Internet ohne Hilfe zu<br />
verwirklichen. Hauptberuflich arbeitet er momentan als <strong>Sicherheit</strong>sarchitekt<br />
für ein Onlinereisebüro. Alun hat am Corpus Christi College,<br />
Cambridge, und an der Bath University studiert. Momentan lebt er mit Frau Debbie und<br />
Sohn Colin bei Seattle, Washington. Alun möchte seiner Frau und seinem Sohn dafür<br />
danken, dass sie seine Abwesenheit so lange hingenommen haben, während er an diesem<br />
Buch gearbeitet hat. Alun ist MCP und Microsoft Security MVP.<br />
Brian Komar<br />
Brian Komar ist der Präsident von IdentIT Inc., einem Consultingunternehmen,<br />
das sich auf die Planung und Implementierung von Public-<br />
Key-Infrastrukturen sowie Identitätsintegrationslösungen spezialisiert.<br />
Brian arbeitet im Rahmen mehrerer Projekte mit Microsoft zusammen:<br />
Er schreibt Kursmaterialien und Whitepapers zu PKI sowie ILM 2007<br />
und arbeitet als leitender Consultant für die PKI- und ILM 2007-Unternehmensbereitstellung.<br />
Brian hält häufig Vorträge auf IT-Konferenzen<br />
wie Microsoft TechEd, Microsoft IT Forum und <strong>Windows</strong> IT Pro<br />
Magazine Connections. Brian ist Microsoft Security MVP.<br />
Brian Lich<br />
Brian Lich ist Fachautor für <strong>Sicherheit</strong> bei der <strong>Windows</strong> <strong>Server</strong> User<br />
Assistance-Gruppe, wo er zum Thema Active Directory-Rechteverwaltungsdienste<br />
schreibt. Bevor er bei Microsoft anfing, arbeitete er<br />
11 Jahre lang als Systemadministrator und <strong>Sicherheit</strong>sanalytiker in der<br />
IT-Branche. Brian hat sein Diplom in Elektrotechnik an der Purdue<br />
University erworben.
Darren Mar-Elia<br />
Darren Mar-Elia ist Gründer und CTO von SDM Software. Er hat über<br />
20 Jahre Erfahrung in Informationstechnologie und Softwareentwicklung.<br />
Er war Leiter der Produktentwicklung bei DesktopStandard (aufgekauft<br />
von Microsoft) und davor CTO für <strong>Windows</strong>-Verwaltungslösungen<br />
bei Quest Software. Er war außerdem Leiter für verteilte<br />
Systeme bei Charles Schwab & Co., wo er für den Einsatz von <strong>Windows</strong><br />
bei diesem Unternehmen verantwortlich war. Darren hat 12 Bücher<br />
zum Thema <strong>Windows</strong>-Verwaltung als Autor oder Koautor verfasst<br />
und ist Microsoft MVP für Gruppenrichtlinien. Er hat die beliebte<br />
Website gpoguy.com gegründet, wo Informationen und Tools zu Gruppenrichtlinien<br />
angeboten werden.<br />
<strong>Die</strong> Autoren 527
Change language