Kapitel 7 � Sichern der Server anhand ihrer Rollen

Document Sample
Kapitel 7 � Sichern der Server anhand ihrer Rollen Powered By Docstoc
					Kapitel 7 – Sichern der Server anhand ihrer Rollen
(Engl. Originaltitel: Chapter 7 - Hardening Specific Server Roles)

Das vorhergehende Kapitel hat Ihnen ein grundlegendes Verständnis zur Entwicklung und
Umsetzung einer Basisrichtlinie durch die Verwendung von Gruppenrichtlinien für Microsoft®
Windows® 2000 Server im Szenario Contoso Ltd. vermittelt. Sobald eine grundlegende
Sicherheit für diese Server etabliert ist, sollten Sie sich, in Abhängigkeit zur Rolle den der Server
in Ihrer Organisation spielt, über die Absicherung jedes einzelnen Servers Gedanken machen.
In diesem Kapitel werden die empfohlenen Sicherheitseinstellungen gezeigt, durch die Sie eine
sichere Umgebung für die vier Hauptrollen von Servern, die es in den meisten Organisationen die
Windows 2000 Server einsetzen gibt, erreichen.
      Microsoft® Active Directory®-Domänencontroller
      Infrastruktur-Server, für Dynamic Host Configuration Protocol (DHCP) und Windows
       Internet Naming Services (WINS)
      Datei- und Druckserver
      Internet Information Services (IIS)
Jeder Server in Ihrer Umgebung stellt eine Gruppe von Anwendungsdiensten zur Verfügung,
durch die entsprechende Sicherheitseinstellungen notwendig werden, um maximale
Verfügbarkeit und Zuverlässigkeit für diese Dienste sicherzustellen. Diese
Sicherheitseinstellungen, die Sie zuweisen, schützen die Daten auf die über diesen Server
zugegriffen werden kann. Wie in der Mitgliedsserver Basisrichtlinie (MSBR) in Kapitel 6
„Sichern der Standardserver“ detailliert diskutiert, werden Gruppenrichtlinien genutzt, um für die
Windows 2000 Server in Ihrer Umgebung so viele Sicherheitseinstellungen wie möglich
durchzusetzen. Die Gruppenrichtlinieneinstellungen sind für jede Serverrolle in individuellen
Sicherheitsvorlagen gespeichert. Diese werden in die entsprechenden Gruppenrichtlinienobjekte
(GPO) importiert. Ein GPO stellt eine Sammlung von Gruppenrichtlinieneinstellungen dar, die in
einer Windows 2000 basierten Umgebung zur Definition von Sicherheitseinstellungen genutzt
werden.
Die in diesem Szenario zur Absicherung des IIS-Servers verwandten
Gruppenrichtlinieneinstellungen sind zum Beispiel in der Sicherheitsvorlage MSS IIS Rolle.inf
gespeichert. Diese Vorlage wird in das GPO der IIS Gruppenrichtlinie, das der
Organisationseinheit (OU) Web in der untergeordneten Domäne Contoso zugewiesen ist,
importiert.
Die Anordnung der Objekte im Microsoft® Active Directory® Verzeichnisdienst von Contoso ist
in der Abbildung unten dargestellt.
Abbildung 7.1: Die Sicherheitsvorlagen für jede Serverrolle wird in das entsprechende
Gruppenrichtlinienobjekt, das der OU für diese Rolle zugewiesen ist, importiert.
In diesem Kapitel sind die Einstellungen beschrieben, die in den Sicherheitsvorlagen für die
einzelnen Serverrollen in Abbildung 7.1 enthalten sind. Einige Verfahren zur Erhöhung der
Sicherheit können allerdings nicht über eine Gruppenrichtlinie automatisiert werden. Die jeweils
empfohlenen Verfahren für diese Fälle werden später in diesem Kapitel beschrieben. Die MSS
Baseline.inf Sicherheitsvorlage, die in Kapitel 6 „Sichern der Standardserver“ näher besprochen
wurde, wird als Grundlage für die Vorlage MSS DCBaseline Role.inf genutzt. Die Unterschiede
zwischen der MSS Baseline.inf Sicherheitsvorlage und der MSS DCBaseline Role.inf
Sicherheitsvorlage werden im Abschnitt „Domänencontroller Basisrichtlinie“ in diesem Kapitel
beschrieben.

Active Directory Domänencontroller-Rolle
Eine der wichtigsten Rollen, die Sie in einer Windows 2000 Active Directory
Unternehmensumgebung schützen müssen, ist die des Domänencontrollers. Der Verlust, oder die
Kompromittierung des Domänencontrollers würde sich verheerend auf die von Clients, Servern
und Anwendungen verwendeten Dienste wie Domänenauthentifizierung, Gruppenrichtlinien und
das zentrale LDAP-Verzeichnis (lightweight directory access protocol) auswirken.
Aufgrund Ihrer Wichtigkeit, sollten Domänencontroller in physikalisch abgesicherten Anlagen
untergebracht werden, zu denen nur qualifizierte administrative Mitarbeiter Zugang haben. Wenn
Domänencontroller an unsicheren Orten, zum Beispiel Außenstellen, untergebracht werden
müssen, können bestimmte Sicherheitseinstellungen vorgenommen werden, um den potentiellen
Schaden durch physikalische Bedrohungen zu beschränken.
Die empfohlenen Einstellungen für Domänencontroller die sich an unsicheren Standorten
befinden werden, soweit anwendbar, in diesem Kapitel beschrieben.
Domänencontroller Basisrichtlinie
Im Gegensatz zu anderen Richtlinien für Serverrollen, die in diesem Kapitel beschrieben werden,
ist die Gruppenrichtlinie für die Domänencontroller eine Basisrichtlinie. Hierdurch gehört Sie zur
selben Klasse wie die Mitgliedsserver Basisrichtlinie (MSBR) die in Kapitel 6 definiert wurde.
Das bedeutet, dass die Domänencontroller Gruppenrichtlinie keine anderen Sicherheitsrichtlinien
benötigt, außer denen, die sie über den Domain-Container von der Default Domain Policy geerbt
hat und der Default Domain Controllers Policy der OU Domain Controllers.
Da die Domänencontroller Basisrichtlinie auf der MSBR basiert, sollten Sie Kapitel 6 gelesen
haben. Viele der dortigen Einstellungen finden sich ebenfalls in der Domänencontroller
Basisrichtlinie. Der größte Teil der Domänencontroller Basisrichtlinie entspricht exakt der
MSBR. Alle Einstellungen, die von der MSBR abweichen, werden in diesem Abschnitt
beschrieben.

Anmerkung: Der Schutz des Verzeichnisdienstes (die Daten aus Active Directory, inklusive der
Objekte, Klassen und Attribute) wird in Kapitel 5, „Sichern der Domäneninfrastruktur“
behandelt.


Einstellungen für Überwachungsrichtlinien
Die Einstellungen für Überwachungsrichtlinien in der Domänencontroller Basisrichtlinie sind
dieselben, die schon in der MSBR definiert wurden. Die Basisrichtlinie stellt sicher, dass auf
Domänencontrollern alle relevanten Informationen der Sicherheitsüberwachung protokolliert
werden. Dies schließt auch den Zugriff auf den Verzeichnisdienst mit ein.

Einstellungen der Ereignisprotokollierung
Die Einstellungen für die Ereignisprotokollierung in der Domänencontroller Basisrichtlinie sind
dieselben, die schon in der MSBR definiert wurden.

Zuweisen von Benutzerrechten
Die Default Domain Controllers Policy definiert eine Anzahl von Benutzerrechten für die
Domänencontroller. Zusätzlich zu den vorgegebenen Einstellungen gibt es zwei Benutzerrechte,
bei denen Sie die Sicherheit auf den Domänencontroller erhöhen sollten:
      Lokal anmelden
      Herunterfahren des Systems


Die folgende Tabelle zeigt die vorgeschlagenen Einstellungen für diese Rechte.
Tabelle 7.1: Einstellungen der Benutzerrechte in der Domänencontroller Basisrichtlinie
Einstellung                     Zugewiesene Gruppen             Empfehlung

Lokal anmelden                  Administrators                  Entfernen Sie
                                                                Kontenoperatoren und
                                Sicherungsoperatoren
                                                                Druckoperatoren, da sie nur
                                Serveroperatoren                zur Kontenverwaltung benötigt
                                                                werden. Druckfreigaben sollten
                                                                auf Domänencontrollern nicht
                                                                erlaubt sein.

Herunterfahren des Systems      Administrators                  Entfernen Sie
                                                                Kontenoperatoren und
                                Serveroperatoren
                                                                Druckoperatoren, da es diesen
                                                                nicht erlaubt sein soll die
                                                                Domänencontroller
                                                                herunterzufahren.

Lokal anmelden

Sicherheitslücken

Jedes Konto mit dem Recht lokal anmelden, kann für eine Anmeldung direkt am
Domänencontroller genutzt werden. Zur Nutzung der Terminaldienste über das Netzwerk
benötigt das Konto ebenfalls das Recht lokal anmelden. Wenn ein Benutzer versucht sich über
den Terminaldienst auf dem Server anzumelden, muss sein Konto außerdem Gastzugriff oder
Benutzerzugriff auf das Remote Desktop Protocol (RDP) des Terminaldienstes haben.
Die beste Vorgehensweise ist es, unautorisierten Benutzern das lokale Anmelden zu nicht zu
gestatten. Bei Domänencontrollern trifft dieses Vorgehen typischerweise die Gruppen
Kontenoperatoren und Druckoperatoren.

Maßnahmen

Entfernen Sie die folgenden zwei vorgegebenen Gruppen: Kontenoperatoren und
Druckoperatoren. Keine dieser beiden Gruppen sollte in Ihrer Umgebung die Fähigkeit
benötigen sich an den Domänencontrollern anzumelden. Setzen Sie dies über die
Domänencontroller Basisrichtlinie um.
Alternativ können Sie diese Gruppen zur Richtlinie lokale Anmeldung verweigern der
Domänencontroller Basisrichtlinie hinzufügen. Diese Einstellung ist so in der Vorlage
Domänencontroller Basisrichtlinie konfiguriert.

Mögliche Auswirkungen

Durch die Entfernung dieser vorgegebenen Gruppen kann es sein, dass die Möglichkeiten, die an
bestimmte Benutzerrollen delegiert wurden, eingeschränkt werden. Stellen Sie sicher, dass diese
delegierten Möglichkeiten nicht beeinflusst werden.
Contoso Szenario

Auf den Domänencontrollern von Contoso haben nur Administratoren, Sicherungsoperatoren
und Serveroperatoren das Recht lokal anmelden. Sicherungsoperatoren brauchen dieses Recht
um mit Sicherungssoftware zu arbeiten, die dieses Konto benötigt. Server Operatoren brauchen
das Recht um Domänencontroller herunterzufahren, da das Herunterfahren erst nach der
Anmeldung möglich ist. Die beiden anderen Gruppen wurden über die Vorlage
Domänencontroller Basisrichtlinie entfernt.

Herunterfahren des Systems

Sicherheitslücken

Die Möglichkeit Domänencontroller herunterzufahren sollte auf eine sehr kleine Zahl von
vertrauenswürdigen Administratoren beschränkt werden. Auch, wenn das Herunterfahren eines
Systems das Recht zur lokalen Anmeldung voraussetzt, sollten Sie doch sehr vorsichtig sein mit
Benutzerkonten und Gruppen denen Sie erlauben Domänencontroller herunterzufahren. Weitere
Informationen entnehmen Sie bitte dem Abschnitt „Herunterfahren des Systems ohne Anmeldung
zulassen“ in Kapitel 6.
Nach dem Herunterfahren von Domänencontrollern werden Funktionen wie in der Domäne
anmelden, Gruppenrichtlinien abfragen und LDAP-Anfragen stellen natürlich nicht länger
verfügbar sein. Die Auswirkung des Herunterfahrens von Domänencontrollern, die
Betriebsmasterfunktionen ausfüllen, kann Schlüsselfunktionen der Domäne, wie z. B. das
Verarbeiten von Anmeldungen mit neuen Passwörtern (PDC-Emulator), betreffen.

Maßnahmen

Entfernen Sie die drei folgenden voreingestellten Gruppen aus jeder Domain Controller
Gruppenrichtlinie, die das Recht vergibt das System herunterzufahren: Kontenoperatoren,
Sicherungsoperatoren und Druckoperatoren. Diese Gruppen sollten die Möglichkeit zum
Herunterfahren von Domänencontrollern nicht benötigen.
Wenn sie alternativ das Recht zum Herunterfahren von Domänencontrollern an andere Gruppen
delegieren möchten, dann können Sie dies natürlich machen. Bedenken Sie aber immer, dass Sie
im Normalfall Ihre zentrale Authentifizierungsdatenbank sicher nicht herunterfahren möchten, da
Benutzer dann nicht mehr in der Domäne authentifiziert werden können.

Möglichte Auswirkungen

Durch die Entfernung dieser vorgegebenen Gruppen kann es sein, dass die Möglichkeiten, die an
bestimmte Benutzerrollen delegiert wurden, eingeschränkt werden. Stellen Sie sicher, dass diese
delegierten Möglichkeiten nicht beeinflusst werden.

Contoso Szenario

Nur Administratoren und Serveroperatoren auf Domänencontrollern haben das Recht das System
herunterzufahren. Sicherungsoperatoren benötigen dieses Recht nicht um mit
Sicherungsprogrammen zu arbeiten. Serveroperatoren brauchen dieses Recht, da sie
Domänencontroller häufig ohne administrative Rechte herunterfahren müssen. Die
entsprechenden Gruppen wurden über die Domänencontroller Basisrichtlinie entfernt.

Sicherheitsoptionen
Die folgende Tabelle umreißt die Einstellungen der Sicherheitsoptionen, die sich von denen in
der MSBR unterscheiden, oder solche, die im Zusammenhang mit Domänencontrollern spezielle
Überlegungen erfordern. Keine dieser Einstellungen erfordert irgendeine Änderung der
vorgegebenen Client-Einstellungen für eine Verbindung mit Domänencontrollern
Tabelle 7.2: Einstellungen der Sicherheitsoptionen in der Domänencontroller Basisrichtlinie

Sicherheitsoption               Empfehlung                      Kommentar

Anzahl                          0 Anmeldungen                   Es gibt keinen Grund die
zwischenzuspeichernder                                          Zwischenspeicherung von
vorheriger Anmeldungen (für                                     Anmeldeinformationen zu
den Fall, dass der                                              unterstützten. Dies sind die
Domänencontroller nicht                                         Domänencontroller.
verfügbar ist)

Clientkommunikation digital     deaktiviert                     Wie in der Mitgliedsserver
signieren (immer)                                               Basisrichtlinie in Kapitel 6.
                                                                Das Aktivieren dieser
                                                                Einstellung führt zu spürbaren
                                                                Leistungseinbußen auf den
                                                                Servern.

LAN Manager-                    Nur NT-LMv2-Antworten           Wie in der Mitgliedsserver
Authentifizierungsebene         senden                          Basisrichtlinie in Kapitel 6. Für
                                                                die Unterstützung von
                                                                Windows 98 SE Clients
                                                                notwendig.

Serverkommunikation digital     deaktiviert                     Wie in der Mitgliedsserver
signieren (immer)                                               Basisrichtlinie in Kapitel 6.
                                                                Das Aktivieren dieser
                                                                Einstellung führt zu spürbaren
                                                                Leistungseinbußen auf den
                                                                Servern.

Serveroperatoren das           deaktiviert                      Serveroperatoren benötigen
Einrichten von geplanten Tasks                                  dieses Recht auf
erlauben (Nur für                                               Domänencontrollern nicht
Domänencontroller)
                                                                Wie in der Mitgliedsserver
Sicherer Kanal: Daten des       deaktiviert
                                                                Basisrichtlinie in Kapitel 6.
sicheren Kanals digital
verschlüsseln oder signieren                                     Notwendig für die
(immer)                                                          Unterstützung von Windows
                                                                 98 SE und aller
                                                                 Domänencontroller mit
                                                                 Microsoft® Windows NT®
                                                                 Version 4.0 Service Pack 5
                                                                 (SP5) in lokalen und
                                                                 vertrauten Domänen.
Weitere Einschränkungen für     Aufzählung von SAM-Konten        Wie in der Mitgliedsserver
anonyme Verbindungen            und Freigaben nicht zulassen     Basisrichtlinie in Kapitel 6.
                                                                 Diese Einstellung ist für
                                                                 Domänencontroller besonders
                                                                 wichtig.


Einige der in Tabelle 7.2 gezeigten Sicherheitsoptionen erfordern eine genauere Erklärung. Im
Rest dieses Abschnittes werden die Erwägungen die hinter diesen, für die Domänencontroller im
Contoso Szenario implementieren, Einstellungen stehen genauer beschrieben.

Weitere Einschränkungen für anonyme Verbindungen

Domänencontroller sind im Bezug auf die Notwendigkeit einiger Clients zum anonymen Zugriff
besonders empfindlich. Die Domänencontroller müssen anonyme Verbindungen zulassen, um
folgende Funktionen zu unterstützen:
      Vertrauensstellungen zwischen Gesamtstrukturen
      Vertrauensstellungen mit Windows NT 4.0 Domänen
      Windows 98 SE und Windows NT 4.0 Client mit SSL-Verbindungen für die
       Domänenanmeldung

Serveroperatoren das Einrichten von geplanten Tasks erlauben (Nur für
Domänencontroller)

Sicherheitslücken

Berechtigte Benutzer, die zur Gruppe Serveroperatoren gehören, können Tasks in der
Domänencontroller-Gruppe planen. Da der Taskplaner in den Voreinstellungen mit
Systemrechten ausgeführt wird, kann ein Angreifer mit einer Mitgliedschaft in der Gruppe
Serveroperatoren dieses Recht ausnutzen. Ein Angreifer könnte z. B. einen Task planen, der sein
Benutzerkonto zur Gruppe Domänenadministratoren hinzufügt.

Gegenmaßnahme

Setzen Sie die Einstellungen für Serveroperatoren das Einrichten von geplanten Tasks
erlauben (Nur für Domänencontroller) auf deaktiviert.
Mögliche Auswirkungen

Nur Benutzer mit den Rechten der Domänenadministratoren können auf Domänencontrollern
Tasks über den Taskplanerdienst planen.

Contoso Szenario

Im Contoso Szenario benötigen nur die Administratoren das Recht Tasks auf
Domänencontrollern zu planen. Serveropertoren das Einrichten von geplanten Tasks
erlauben (Nur für Domänencontroller) wurde über die Gruppenrichtlinie auf deaktiviert
gesetzt.

Digital signierte Client- und Serverkommunikation

Die Einstellungen Clientkommunikation digital signieren (wenn möglich) sollte auf allen
Clientcomputer aktiviert werden, bevor Sie die Einstellungen Clientkommunikation digital
signieren (immer) auf Ihren Domänencontrollern aktivieren. Aktiveren Sie die Einstellungen in
dieser Reihenfolge, um den Clients jederzeit eine erfolgreiche Kommunikation mit den
Domänencontrollern zu ermöglichen.

LAN Manager-Authentifizierungsebene

Gerade bei Windows 2000 Domänencontroller ist es besonders wichtig, dass alle Clients in der
Lage sind sich an einem Domänencontroller zu authentifizieren. Und zwar für den Beitritt, als
auch für das spätere Arbeiten in der Domäne. Es ist ebenfalls wichtig, dass Domänencontroller
andere Domänencontroller aus anderen Domänen (aus anderen Gesamtstrukturen oder NT 4.0
Domänen) authentifizieren können. Zum Beispiel um Berechtigungen außerhalb der
Gesamtstruktur zu prüfen. Beides erfordert eine Form der LAN-Manager Authentifizierung (ein
Authentifizierungsprotokoll, das nicht mit Kerberos5 arbeitet).
Alle Windows-Clients (auch Windows 2000 und Microsoft® Windows® XP ) sind in der
Voreinstellung so konfiguriert, dass sie LM- (LAN-Manager) und NT-LM-
Authentifizierungsantworten versenden. Sie versenden nicht automatisch NT-LMv2-
Authentifizierungsantworten. Deswegen ist das Erzwingen von NT-LMv2-Authentifizierung auf
einem Windows 2000 Domänencontrollern nicht möglich, so lange nicht alle Clients (und alle
Domänencontroller außerhalb der Gesamtstruktur zu denen eine Vertrauensstellung besteht) zur
Verwendung von NT-LMv2 konfiguriert wurden.

Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der
Domänencontroller nicht verfügbar ist)

Sicherheitslücken

Während es auf Windows-Clients, die einer Domäne angehören, sinnvoll ist Anmeldungen
zwischenzuspeichern, ist es auf Domänencontrollern grundsätzlich unnötig. Es ist nicht möglich,
dass der Domänencontroller seine eigenen Anmeldeinformationen nicht überprüfen kann.

Maßnahmen
Setzen Sie die Einstellungen Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für
den Fall, dass der Domänencontroller nicht verfügbar ist) für Domänencontroller auf 0.
Mögliche Auswirkungen

Wenn Sie das Zwischenspeichern von Anmeldungen deaktivieren, ist es nicht mehr möglich,
Konten die aus anderen Domänen stammen aus vorhergehenden Anmeldungen zu
authentifizieren, wenn die Domänencontroller der anderen Domänen nicht zur Verfügung stehen.
Beispiel: Eine Anmeldung an Domänencontrollern in der Contoso-Unterdomäne als
Organisationsadmin ist nicht mehr möglich wenn alle Domänencontroller aus der Contoso-
Stammdomäne nicht mehr zur Verfügung stehen. Dies ist aber kein dauerhafter Zustand. Er ist
behoben, sobald der Zugriff auf die Domänencontroller wiederhergestellt ist.

Contoso Szenario

Die Einstellungen Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall,
dass der Domänencontroller nicht verfügbar ist) wurde über eine Gruppenrichtlinie in der
Domänencontroller Basisrichtlinie auf 0 gesetzt.

Sicherer Kanal: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer)

Wenn unterstützt, ist die digitale Verschlüsselung und Signierung eines sicheren Kanals eine
Betrachtung wert. Die digitale Verschlüsselung und Signierung eines sicheren Kanals wird
allerdings nur ab Windows NT 4.0 SP6a oder später, und nicht von Windows 9x-Clients
unterstützt. Deshalb kann diese Einstellung auf Domänencontrollern nicht aktiviert werden,
solange es Windows 9x-Clients als Domänenmitglieder gibt.
Diese Einstellung wird die Signierung oder Verschlüsselung nur erzwingen, wenn eine der
zugehörigen anderen „wenn möglich“-Einstellungen auf den Domänencontrollern angewandt
wird. Wenn keine dieser Einstellungen angewandt wurde, hat die Einstellungen keine Wirkung
auf die Domänencontroller.
Potentielle Auswirkungen dieser Einstellungen umfassen z. B. den Verlust der Fähigkeit
untergeordnete Vertrauensstellungen zu erstellen oder zu löschen, dass Verhindern von
Anmeldungen von Clients und das Verhindern einer Authentifizierung von Benutzern aus
untergeordneten Domänen.
Die Einstellung sollte auf Ihren Domänencontrollern nur aktiviert werden, wenn die folgenden
Bedingungen zutreffen:
      alle Windows 9x-Clients wurden aus der Domäne entfernt
      alle Windows NT 4.0 Clients, Server und Domänencontroller (aus vertrauten oder
       vertrauenden Domänen) wurden auf SP6a aktualisiert
      die Option Sicherer Kanal: Daten des sicheren Kanals digital verschlüsseln (wenn
       möglich) oder Sicherer Kanal: Daten des sicheren Kanals digital signieren (wenn
       möglich) wurde auf allen Windows-Clients aktiviert; eine von beiden Einstellungen muss
       auf den Domänencontrollern aktiviert sein.
Systemdienste
Dies ist eine Zusammenfassung aller vorgeschriebenen Systemdienste, die auf allen Windows
2000 Domänencontrollern aktiviert sein müssen. Die Systemdienste sind in der Vorlage MSS
DCBaseline Role.inf konfiguriert, welche dann in die Default Domain Controller Policy
Gruppenrichtlinie importiert wird.


Tabelle 7.3: Zwingend notwendige Dienste auf Domänencontrollern in der Basisrichtlinie
Dienstname                      Starttyp                        Kommentar

Verteiltes Dateisystem (DFS)    automatisch                     Benötigt für die SYSVOL-
                                                                Freigabe von Active Directory

Dateireplikation                automatisch                     Benötigt für die
                                                                Dateireplikation zwischen
                                                                Domänencontrollern

Standortübergreifender          automatisch                     Benötigt für die Active
Meldungsdienst                                                  Directory-Replikation

Kerberos                        automatisch                     Für die Netzwerkanmeldung
Schlüsselverteilungscenter                                      von Benutzer über das
                                                                Kerberos V5-Protokoll

Remoteprozeduraufruf            automatisch                     Benötigt der
                                                                Domänencontroller um den
(RPC)
                                                                RPC-Namensdienst zur
                                                                Verfügung zu stellen


Es gibt weitere Dienste, die gewöhnlich auf Windows 2000 Domänencontrollern aktiviert sind,
die aber nicht in jeder Organisation grundsätzlich notwendig sind. Die empfohlenen
Einstellungen für diese Dienste entsprechen denen des Contoso Szenarios. Sie sind jedoch ein
häufiger Diskussionspunkt, und es mag sein, dass sie für Ihre Umgebung so nicht anwendbar
sind.


Tabelle 7.4: Betrachtung zusätzlicher Dienste auf Domänencontrollern
Dienstname                      Starttyp                        Kommentar

DNS-Server                      automatisch                     In der Umgebung von Contoso
                                                                wird ein Active Directory
                                                                integrierter DNS genutzt.

IIS Admin-Dienst                deaktiviert                     Die SMTP-basierte Replikation
                                                                ist in der Contoso Umgebung
                                                                  nicht aktiviert. Deshalb wird
                                                                  der IIS Admin-Dienst nicht
                                                                  benötigt.

NT-LM-Sicherheitsdienst          automatisch                      Bietet Sicherheit für RPC.

SMTP-Dienst                      deaktiviert                      Die SMTP-basierte Active
                                                                  Directory Replikation ist in der
                                                                  Contoso Umgebung nicht
                                                                  aktiviert.



Anmerkung: Mit dem Tool DCDiag.exe aus den Windows 2000 Support Tools können Sie
prüfen welche Dienste auf Domänencontrollern in Ihrer Umgebung ausgeführt werden.
DCDiag.exe wird Fehlermeldungen anzeigen, da einige Dienste (unter anderem auch IISADMIN,
SMTPSVC und TrkSvr) in der Domänencontroller Basisrichtlinie deaktiviert sind. Daher sind
diese Fehlermeldungen kein Anzeichen für Probleme mit ihrer Konfiguration.


DNS-Server

Sicherheitslücken

Der DNS-Server Dienst wird zur Unterstützung des Active-Directory-integrierten DNS-Dienstes
benötigt. Der DNS-Server wird zur Unterstützung des "dynamic-DNS-update"-Protokolls unter
Windows 2000 Server verwendet.
Jeder Dienst und jede Anwendung ist ein potentieller Angriffspunkt. Dienste und Komponenten
die nicht ausgeführt werden, können nicht angegriffen werden. Es ist daher die für das Erstellen
eines sicheren Systems beste Verfahrensweise, ungenutzte Komponenten zu deaktivieren um so
die Angriffsfläche zu verringern.

Maßnahmen

Keine. Dieser Dienst wird benötigt.
Wenn Active-Dirctory-integriertes DNS nicht notwendig ist, kann dieser Dienst alternativ auf
Domänencontrollern deaktiviert und auf dem Infrastruktur-Betriebsmaster aktiviert werden. Der
Infrastrukturserver kann dann den DNS-Server Dienst als primärer oder sekundärer DNS-Server
ausführen.

Mögliche Auswirkungen

Das Deaktivieren des Active-Directory-integrierten DNS-Dienstes wird zum Fehlschlag aller
Domänenfunktionen, inklusive Replikation, Anmeldung und Gruppenrichtlinien, führen.
Außerdem werden alle Active-Directory-integrierten Anwendungen, wie z. B. Microsoft®
Exchange 2000, nicht mehr funktionieren.
Contoso Szenario

In der Contoso Umgebung wird Active-Dirctory-integriertes DNS benötigt. Deshalb ist der
Starttyp dieses Dienstes als automatisch konfiguriert.

Standortübergreifender Meldungsdienst

Sicherheitslücken

Dieser Dienst wird vom Knowledge Consistency Checker (KCC) benötigt. Außerdem wird der
Dienst genutzt, um SMTP-basierte Active Directory-Replikation zwischen Standorten zu
unterstützen.
Jeder Dienst und jede Anwendung ist ein potentieller Angriffspunkt. Dienste und Komponenten
die nicht ausgeführt werden, können nicht angegriffen werden. Es ist daher die für das Erstellen
eines sicheren Systems beste Verfahrensweise, ungenutzte Komponenten zu deaktivieren, um so
die Angriffsfläche zu verringern.

Maßnahmen

Die Option für den Standortübergreifenden Meldungsdienst sollte in der Domänencontroller
Basisrichtlinie auf automatisch gestellt werden.
Wenn Sie, alternativ, eine manuelle Replikaktionstopologie aufbauen möchten, und deshalb den
KCC nicht benötigen, können Sie diesen Dienst deaktivieren.

Mögliche Auswirkungen

Keine.

Contoso Szenario

Solange die Contoso Umgebung vom KCC und der von ihm erstellen Replikaktionstopologie
abhängig ist, wird der Standortübergreifende Meldungsdienst benötigt. Deshalb wurde der Dienst
in der Domänencontroller Basisrichtlinie aktiviert.

IIS Admin-Dienst

Sicherheitslücken

Wenn der SMTP-Dienst aktiviert ist, dann muss der IIS Admin-Dienst ebenfalls aktiviert werden,
da der SMTP-Dienst von diesem abhängt.
Wie bereits vorher ausgeführt, ist jeder Dienst und jede Anwendung ist ein potentieller
Angriffspunkt. Es ist daher die für das Erstellen eines sicheren Systems beste Verfahrensweise,
ungenutzte Komponenten zu deaktivieren, um so die Angriffsfläche zu verringern.
Maßnahmen

Setzen Sie die Option für den IIS Admin-Dienst in der Domänencontroller Basisrichtlinie auf
deaktiviert.
Wenn eine SMTP-basierte Replikation notwendig ist, sollte der Dienst in der Domänencontroller
Basisrichtlinie alternativ auf den Starttyp automatisch gesetzt werden.

Mögliche Auswirkungen

Da der Dienst für das erfolgreiche Ausführen des SMTP-Dienstes notwendig ist, führt das
Deaktivieren des IIS Admin-Dienstes auch zur Deaktivierung der SMTP-basierten Replikation
von Active Directory-Informationen. Wenn SMTP-basierte Replikation durch langsame
Verbindungen, oder Verbindungen mit hoher Latenz notwendig ist, dann wird die Deaktivierung
die Active Directory-Replikation verhindern. Aus diesem Grund sollten Sie diesen Dienst auf
automatisch stellen.

Contoso Szenario

Da die Contoso Umgebung über Hochgeschwindigkeitsverbindungen zwischen den Active
Directory-Standorten verfügt, ist eine SMTP-basierte Replikation nicht notwendig. Daher wurde
dieser Dienst deaktiviert.

NT-LM Sicherheitsdienst

Sicherheitslücken

Der NT-LM-Sicherheitsdienst bietet eine Schnittelle (NTLM Security Support Provider Interface
– SSPI) für RPC-Anwendungen. Diese können über das SSPI Anforderungen für gesicherte RPC-
Nachrichten senden. Dieser Dienst ist essentiell für den Betrieb von Windows 2000 Servern.

Maßnahmen

Keine. Dieser Dienst ist in den Voreinstellungen aktiviert und kann für die Kompatibilität von
Anwendungen nötig sein.
Unter Umständen kann dieser Dienst deaktiviert werden. Er ist jedoch von grundlegender
Bedeutung für die Unterstützung einiger älterer Anwendungen unter Windows 2000. Wenn Sie
diesen Dienst deaktivieren möchten, empfehlen wir dringend erst alle Anwendungen, die auf
Ihren Domänencontrollern ausgeführt werden oder die auf die Domänencontroller zugreifen, zu
testen. Stellen Sie sicher, dass diese Anwendungen auch ohne das NT-LM SSPI noch
funktionstüchtig sind.
Die Entfernung der LM- und NT-LM-Authentifizierung (um die sichereren Protokolle NT-LMv2
und Kerberos zu nutzen) aus Ihrer Umgebung erfordert einiges an Prüfung, Planung und Tests.
Sie sollten als erstes die folgenden Artikel der Microsoft Knowledge Base lesen:
      Q147706, "How to Disable LM Authentication on Windows NT."
      Q239869, "How to Enable NT-LM 2 Authentication for Windows 95/98/2000 and NT."
Mögliche Auswirkungen

Das Aktivieren dieses Dienstes ermöglicht die Authentifizierung über die relativ schwachen
Protokolle LM und NT-LM an den Domänencontrollern Ihrer Organisation. Dies kann durch die
Nutzung des NT-LMv2 Protokolls auf Clients und Domänencontrollern verhindert werden.

Contoso Szenario

Der NT-LM-Sicherheitsdienst wird für viele Szenarien in der Contoso Umgebung benötigt. Aus
diesem Grund wurde er in der Domänencontroller Basisrichtlinie aktiviert.

SMTP-Dienst

Sicherheitslücken

Im Gegensatz zum RPC-Protokoll, erlaubt es der SMTP-Dienst, der auf einem
Domänencontroller ausgeführt wird, anderen Domänencontrollern eine Active Directory-
Replikation zwischen Standorten über SMTP durchzuführen. Dieses Protokoll ist von Nutzen,
wenn die Replikation zwischen Standorten in denen Domänencontroller stehen über langsame
oder hoch ausgelastete Netzwerkverbindungen erfolgt. Es ist notwendig, wenn in einer
Organisation RPC über die Grenzen des eigenen Netzwerkes hinweg, z. B. durch eine Firewall,
nicht gestattet. Die Replikation zwischen Standorten kann über RPC oder SMTP ausgeführt
werden. Wenn Sie in Ihrer Umgebung SMTP für die Replikation zwischen Standorten nutzen,
dann müssen Sie den SMTP-Dienst aktiveren.
SMTP hat zwei Sicherheitslücken:
      Als zusätzlicher Dienst der auf Anforderungen und Daten reagiert, die von außen
       kommen, kann SMTP möglicherweise durch Buffer-Overflows unterwandert werden.
      Der SMTP-Server kann eingehende SMTP-Anfragen über die Nutzung von
       Domänenbenutzerkonten authentifizieren. Da der SMTP-Server aber keine
       Kontosperrung verwendet (wie z. B. in Active Directory durch Passwortrichtlinien), kann
       ein Angreifer ohne Sperrung oder Verzögerung so viele Passwörter testen wie er möchte.

Maßnahmen

Wenn eine SMTP-basierte Active Directory-Replikation in Ihrer Umgebung nicht benötigt wird,
sollte der SMTP-Dienst in der Domain Controller Gruppenrichtlinie deaktiviert werden.
Wenn Sie den SMTP-Dienst nicht deaktivieren möchten, können Sie alternativ den SMTP-Dienst
selbst über Zugriffsfilter absichern. In den Eigenschaften des SMTP-Servers, Registerkarte
Zugriff, Schalter Verbindungen, oder über Internet Protocol Security (IPSec) Filter die
Verbindungen auf TCP-Port 25 für alle IP-Adressen, außer den von Ihnen definierten, verbieten.
IPSec ist ein Sicherheitsstandard für die Netzwerk- oder Paketvermittlungsschicht in der
Netzwerkkommunikation. Es wird genutzt, um zwischen einzelnen IP-Hosts virtuelle private
Netzwerke (VPNs) einzurichten, und so die übertragenen Daten zu authentifizieren oder zu
verschlüsseln. Sie sollten außerdem erwägen, den SMTP-Dienst nur auf Replikationspartnern zu
aktivieren, die zwischen Domänen replizieren, die eine SMTP-basierte Active Directory-
Replikation erfordern.
Anmerkung: Wenn Sie eine SMTP-Replikation aktivieren möchten, dann müssen Sie digitale
Zertifikate für alle Domänencontroller, die an der SMTP-basierten Replikation teilnehmen,
erstellen. Weitere Einzelheiten entnehmen Sie bitte dem Anhang E „Konfigurieren von digitalen
Zertifikaten für sicheres LDAP und SMTP-Replikation auf Domänencontrollern.“


Mögliche Auswirkungen

Die möglichen Auswirkungen einer Deaktivierung von SMTP auf Domänencontrollern sind
minimal. Es sei denn, Sie haben eine SMTP-basierte Active Directory-Replikation auf den
betreffenden Domänencontrollern konfiguriert. In diesem Fall wird die Replikation fehlschlagen.

Contoso Szenario

Die gesamte Active Directory-Replikation wurde in der Contoso-Umgebung für die Verwendung
des IP (auch RPC genannt) Protokolls konfiguriert. Daher wurde der SMTP-Dienst deaktiviert.

Zugriffskontrolllisten der Registrierung
Es gibt, außer den in der MSBR vorgeschlagenen, keine weiteren empfohlenen Änderungen für
die Zugriffskontrollliste der Registrierung.

Dateisystem Zugriffskontrolllisten
Sicherheitslücken

Die ACL-Berechtigungen aller neu erstellen Partitionen sind in der Voreinstellung, im Gegensatz
zum %SystemDrive% - gewöhnlich die C-Partition, auf Jeder: Vollzugriff gesetzt. Das bedeutet,
dass alle Dateien und Ordner, die zu diesen Partitionen hinzugefügt werden, generell die
Berechtigung Jeder: Vollzugriff erben. Aufgrund dieser Zugriffsberechtigungen eröffnet jede
Freigabe jedem den Zugriff auf die freigegebenen Dateien. Diese Dateien sind dann Missbrauch
und Verfälschung ausgesetzt. Und zwar über Bedrohungen, die im STRIDE-Model (Spoofing
identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and
Elevation of privilege) definiert sind. Genauere Beschreibungen dieser Bedrohungen entnehmen
Sie bitte dem Abschnitt „Bedrohungen Einordnen“ im Kapitel 2 „Bestandsaufnahme“.
Die einzigen Änderungen zu den Berechtigungen des Dateisystems in der Domänencontroller
Basisrichtlinie beziehen sich auf %SystemDrive%.
Sie sollten die Dateiberechtigungen für alle Partitionen, die Sie zusätzlich zu %SystemDrive%
erstellen (z. B. die Partitionen D, E und F), aktualisieren. Dies ist ganz besonders für die
Partitionen wichtig, welche die Active Directory-Datenbank, die DNS-Protokolldateien und
andere sensible Daten enthalten.
Maßnahmen

Vergeben Sie für alle Nicht-Systempartitionen Vollzugriff für Administratoren, ERSTELLER-
BESITZER und System. Vergeben sie an andere Benutzer oder Gruppen keinen Zugriff. Das
Vergeben dieser Berechtigung an ERSTELLER-BESITZER ermöglicht es dem Betriebssystem
den Besitzt an den individuellen Administrator zuzuweisen und nicht einfach der Gruppe
Administratoren.
Alternativ möchten Sie vielleicht abweichende Berechtigungen für den Stamm jeder Partition
vergeben. Trotzdem sollten Sie sicherstellen, dass die Berechtigungen für die Ordner der DNS-
Protokolldateien und für die Active Directory-Datenbank und –Protokolldateien Vollzugriff nur
Administratoren und System gestatten.

Mögliche Auswirkungen

Wenn die bestehenden Berechtigungen auf Nicht-Systempartition geändert werden, ist es
möglich, dass Anwendungen die bereits auf diesen Partitionen installiert waren, nicht mehr
korrekt arbeiten. Einige Windows-Anwendungen sind so konfiguriert, dass sie ihre eigenen
expliziten Berechtigungen für die Ordner in denen sie installiert sind setzen. Aus diesem Grund
sollten diese Anwendungen immer erst in einer Testumgebung mit den hier vorgeschlagenen
Berechtigungsänderungen geprüft werden.

Contoso Szenario

In der Domänencontroller Basisrichtlinie ist die Berechtigung für %SystemDrive% so
konfiguriert, dass nur Administratoren, ERSTELLER-BESITZER und System Vollzugriff
haben. Außerdem werden diese Berechtigungen an untergeordnete Ordner und Dateien vererbt.
Für alle anderen Partitionen wurden diese Berechtigungen manuell konfiguriert.
Um die per Hand Berechtigungen des Stammordners auf einer Nicht-Systempartition (z. B.
der E Partition) zu ändern
   1. Öffnen Sie die Eingabeaufforderung
   2. Geben Sie folgenden Befehl ein: *calcs e:\ /t /g administratoren:F system:F
      „ersteller/besitzer“:F
   3. Wenn sie dazu aufgefordert werden geben Sie Y zum Fortfahren ein

Zusätzliche Sicherheitseinstellungen - Verzeichnisdienst
Deaktivieren der Einstellungen NoLmHash auf Domänencontroller

Sicherheitslücken

Die NoLmHash-Einstellungen entschärft die Schwachstelle der Speicherung von LM-Hashes in
der Kontendatenbank, und verhindert die Nutzung der LM-Challenge/Response-
Authentifizierung. Obwohl diese Einstellungen in der MSBR aktiviert sind, ist es im Contoso
Szenario nicht möglich sie auf den Domänencontrollern zu aktivieren. Das liegt daran, dass
Contoso Windows 98 Clients unterstützten muss und diese nicht in der Lage sind mit NT-LM
oder NT-LMv2 Authentifizierung zu arbeiten. So lange die Windows 98 Clients bei Contoso sich
nur über das LM Protokoll authentifizieren können, muss auch auf den Domänencontrollern die
Möglichkeit einer LM Authentifizierung erhalten werden. Unglücklicherweise erfordert dies eine
auf den Domänencontrollern gespeicherte Version des LM-Hashes, was wiederum die Nutzung
der NoLmHash-Einstellungen auf Domänencontrollern ausschließt.

Maßnahmen

Stellen Sie sicher, dass der NoLmHash Registrierungsschlüssel auf Domänencontroller nicht
vorhanden ist.

Mögliche Auswirkungen

Wenn Sie die LM-Hash Erstellung nicht deaktivieren, bewirkt dies, dass weiterhin LM-Hash-
Werte die das Passwort eines Benutzers darstellen in Active Directory gespeichert werden.
Dennoch ist das Risiko, dass ein Angreifer Zugriff zu diesen schwächeren Hashes erlangt,
generell auf Domänencontrollern geringer als auf anderen Servern und auf Clients, da der
physikalische Zugriff auf Domänencontroller im allgemeinen schwerer zu erlangen ist.
Beachten Sie hierzu bitte auch den Abschnitt „Verwendung von Syskey“ weiter unten in diesem
Kapitel.
Wenn das Erstellen von LM-Hashes nicht deaktiviert wird, ermöglicht dies außerdem die LM-
Challenge/Response-Authentifizierung. Dies ist die schwächste der unter Windows möglichen
Challenge/Response-Authentifizierungsmethoden. Sie wird für die Unterstützung von Windows
98 SE-Clients benötigt. Sobald alle Windows 9x-Clients aus der Domäne entfernt wurden ist sie
unnötig.

Contoso Szenario

Die manuelle Deaktivierung der Erstellung von LM-Hashes wurde auf den Domänencontrollern
nicht konfiguriert. Der Schlüssel NoLmHash wurde nicht zum Registrierungsschlüssel
HKLM\SYSTEM\CurrentControlSet\Lsa auf den Domänencontrollern hinzugefügt.

Verlagerung von Daten - Active Directory Datenbank und Protokolldateien

Sicherheitslücken

Die Datenbank und die Protokolldateien (ntds.dit, edb.log und temp.edb) sind während der
Ausführung des Active Directory-Dienstes immer exklusiv geöffnet; das heißt, diese Dateien
können nicht direkt gelesen oder geschrieben werden. Es könnte jedoch passieren, dass diese
Dateien kompromittiert werden, wenn ein Angreifer irgendwie über den lsass.exe-Prozess der
diese Dateien sperrt, Zugriff erlangt. Die beste Vorgehensweise ist es, die Active Directory-
Datenbank und die Protokolldateien auf eine Nicht-Systempartition zu verschieben, um die
Leistung des Domänencontrollers zu steigern. Bevorzugt sollte diese Partition ein Stripeset oder
ein gespiegeltes Stripeset sein. Es ist außerdem im Bezug auf Sicherheit die beste
Vorgehensweise, sensible Dateien wie diese von der Systempartition zu entfernen, um „Directory
Traversal„ Angriffe auf diese Dateien zu verhindern.
Maßnahmen

Achten Sie darauf, dass Sie während der Installation der Active Directory Domänencontroller den
Ordner für die Datenbank und die Protokolldateien auf einer nicht Systempartition platzieren
(normalerweise eine andere als die Partition C). Die beste Wahl ist eine Partition mit hoher
Leistung wie z. B. ein Stripeset oder ein gespiegeltes Stripeset.
Alternativ können sie bei bereits existierenden Domänencontrollern – wenn Sie diese Dateien
nicht bereits von der Systempartition entfernt haben – die Active Directory-Datenbank und die
Protokolldateien nachträglich verschieben. Machen Sie dies über die Startoption
Verzeichnisdienstwiederherstellung.

Mögliche Auswirkungen

So lange die Partition auf der die Datenbank und die Protokolldateien liegen ausreichend
Speicherplatz und Leistung bietet, gibt es keine Auswirkungen oder sie sind minimal. Das
Verschieben der Datenbank und der Protokolldateien auf bestehenden Domänencontrollern kann
erhebliche Auswirkungen haben, da das System während dieses Vorganges heruntergefahren
werden muss. Außerdem gibt es immer das kleine Risiko eines Hardwareausfalls während des
Verschiebevorganges. Erstellen Sie immer eine Sicherung des Systemstatus bevor Sie einen
solchen Vorgang durchführen. Lesen Sie den Knowledge-Base-Artikel Q257420, "HOW TO:
Move the Ntds.dit File or Log Files" für ausführliche Informationen zu den im Folgenden
beschriebenen Verfahren.

Contoso Szenario

In der Umgebung von Contoso wurden die Datenbanken und Protokolldateien während des
Installationsprozesses auf eine Nicht-Systempartition installiert.
Um den Speicherort der Active Directory-Datenbank und der Protokolldateien während
der Installation eines Domänencontrollers zu ändern
   1. Starten Sie Dcpromo.exe und wählen Sie ihre gewünschte Konfiguration auf der Seite
      Speicherort der Datenbank und Protokolldateien aus
   2. Geben Sie den Speicherort für die Datenbank (z. B. d:\NTDS) und den Speicherort für die
      Protokolldatei an (z. B. e:\NTDSLogs)
   3. Machen Sie mit den verbleibenden Schritten von DCPROMO weiter.


Um die Datenbank und die Protokolldateien eines vorhandenen Domänencontrollers zu
verschieben
   1. Starten Sie den Domänencontroller neu
   2. Drücken Sie während des Startvorganges F8, wählen Sie
      Verzeichnisdienstwiederherstellung und melden Sie sich als Administrator an wenn Sie
      dazu aufgefordert werden.
   3. Starten sie das Tool ntdsutil.exe und geben sie files in der ntdsutil-Eingabeaufforderung
      ein.
   4. In der Eingabeaufforderung File Maintenance verwenden Sie eins oder beide der
      folgenden Verfahren:
      a) Um die Datenbank zu verschieben geben Sie move db to %s ein (wobei %s das
      Laufwerk und den Ordner bezeichnet in den Sie die Datenbank verschieben möchten.
      b) Um die Protokolldateien zu verschieben geben Sie move logs to %s ein (wobei %s das
      Laufwerk und den Ordner bezeichnet in den Sie die Datenbank verschieben möchten.
   5. Um die neue Position der Datenbank oder der Protokolldateien anzuzeigen geben Sie info
      ein, und um die Integrität der Datenbank zu prüfen geben Sie integrity ein
   6. Geben Sie zweimal quit ein um zur Eingabeaufforderung zurückzukehren.
   7. Starten Sie das System im normalen Modus neu.

Anmerkung: Auf einem erfolgreich erstellten Domänencontroller sind die folgenden
Berechtigungen für die Ntds-Ordnerstruktur zugewiesen: Administratoren und SYSTEM:
Vollzugriff. Eine weiterführende Absicherung dieser Daten wird nicht empfohlen.


Absicherung des Gruppe Prä-Windows 2000 kompatibler Zugriff

Sicherheitslücken

Auf die meisten Active Directory-Objekte ist in der Voreinstellung für die Gruppe Prä-Windows
2000 kompatibler Zugriff die Berechtigung Lesen vergeben. Alle Benutzer- und Gruppenobjekte
haben dieses Recht und in der Domänenpartition ist das Recht Inhalte auflisten für diese Gruppe
vergeben. Wenn die Gruppe Jeder in einer Active Directory-Domäne zu einem Mitglied der
Gruppe Prä-Windows 2000 kompatibler Zugriff gemacht wird, hat jeder anonyme Benutzer
das LDAP-Leserecht. Dies schließt dann auch die Gruppenmitgliedschaften von
Benutzerobjekten mit ein. Dieser anonyme Benutzer könnte außerdem den Inhalt der Domäne
auflisten.

Maßnahmen

Entfernen Sie in Ihrer Domäne den Alias Jeder aus der Gruppe Prä-Windows 2000
kompatibler Zugriff.
Alternativ können Sie bei der Einrichtung von neuen Domänen die Berechtigungen auf
Kompatibel nur für Windows 2000 Server setzen. Sie können dies auf der Seite
Berechtigungen während des DCPROMO-Vorgangs des ersten Domänencontrollers erreichen.
Theoretisch können Sie auch die vererbten Berechtigungen der Gruppe Prä-Windows 2000
kompatibler Zugriff aus dem Domänencontainer entfernen. Die gesamten Berechtigungen so zu
entfernen führt jedoch zu einem größeren Risiko, da diese Alternative nicht umfassend von
Microsoft getestet wurde, und sie Ihre Flexibilität diese Berechtigungen zukünftig einzusetzen
deutlich einschränkt.
Außerdem weisen wir darauf hin, dass das Entfernen von Berechtigungen auf Active Directory-
Objekte die Sicherheit in Ihrer Umgebung nicht mehr verbessern wird, als dass Entfernen aller
Mitglieder aus der Gruppe Prä-Windows 2000 kompatibler Zugriff.
Mögliche Auswirkungen

Alle Anwendungen, die einen anonymen Zugriff auf Active Directory benötigen, werden nicht
mehr wie erwartet funktionieren. Folgende Dienste und Anwendungen schlagen unter anderem
fehl, wenn Jeder aus der Gruppe Prä-Windows 2000 kompatibler Zugriff entfernt wird:
       Remote Access Service (RAS), wenn er auf einem Windows NT 4.0 Backup
        Domänencontroller (BDC) ausgeführt wird.
       Routing und Remote Access Service (RRAS), wenn er auf einem Windows NT 4.0
        Domänencontroller ausgeführt wird
       Microsoft® SQL Server 2000 bei der Batchverarbeitung von Gruppenmitgliedschaften.

Anmerkung: SQL-Server 2000 die auf Mitgliedsservern ausgeführt werden, können den Zugriff
den sie benötigen alternativ erhalten, indem Sie die Computerkonten der Mitgliedsserver anstelle
von Jeder in die Gruppe Prä-Windows 2000 kompatibler Zugriff aufnehmen.

       Das Auflisten von Benutzern und Gruppen aus vertrauten Domänen – in diesem Fall muss
        der Gruppen- oder Benutzername manuell eingegeben werden.

Contoso Szenario

Im Contoso Szenario wurde der symbolische Name Jeder über das folgende Verfahren aus der
Gruppe Prä-Windows 2000 kompatibler Zugriff entfernt.
►Um den   symbolischen Namen Jeder aus der Gruppe Prä-Windows 2000 kompatibler
Zugriff zu entfernen
       1. Öffnen Sie eine Eingabeaufforderung auf einem Domänencontroller in der Domäne in
          der Sie diese Gruppe entfernen möchten.
       2. Geben Sie den folgenden Befehl ein: net localgroup „Prä-Windows kompatibler
          Zugriff“ Jeder /DELETE
       3.   Geben Sie net localgroup „Prä-Windows 2000 kompatibler Zugriff ein, um zu
            überprüfen, dass die Gruppe tatsächlich leer ist. Sie sollten das folgende Ergebnis
            angezeigt bekommen:
                 C:\>net localgroup "pre-windows 2000 compatible access"
                 Alias name     pre-windows 2000 kompatibler Zugriff
                 Comment        A backward compatibility group which allows read
                 access
                 on all users and groups in the domain
                 Members
                 ------------------------------------------------------------------
                 -------------
                 The command completed successfully.
       4. Starten Sie alle Domänencontroller in der Domäne neu, um diese Einstellungen
          durchzusetzen
Das Recht Arbeitsstationen zu Domäne hinzuzufügen entfernen

Sicherheitslücken

In den Voreinstellungen haben alle authentifizierten Benutzer das Recht bis zu 10
Computerkonten in die Domäne aufzunehmen. Die neuen Computerkonten werden im Container
Computer erstellt.
Im Gegensatz zum Windows NT 4.0 Domänenmodell, ist in einer Windows 2000 Domäne jedes
Computerkonto ein vollwertiger Sicherheitsprinzipal, der den Computer in die Lage versetzt sich
zu authentifizieren und auf Ressourcen der Domäne zuzugreifen. Einige Organisationen möchten
die Anzahl der Computer in ihrer Domäne einschränken, so dass diese Einheitlich erstellt und
verwaltet werden können.
Wenn die Benutzer die Möglichkeit haben, Arbeitsstationen zur Domäne hinzuzufügen, werden
diese Bemühungen untergraben. Den Benutzern stehen außerdem Verfahren zu Verfügung mit
denen Sie Aktionen vornehmen können, die einfacher zu verfolgen wären, wenn sie nur das
Recht hätten unautorisierte Domänencomputer einzurichten.
Und schließlich de-registriert ein System, das korrekt heruntergefahren wird, seinen Service
Principal Name (SPN) aus Active Directory. Während der Zeit, die ein System heruntergefahren
ist – z. B. nach einem Denial of Service (DoS) Angriff – könnte ein Angreifer seinen eigenen
Computer unter diesem SPN registrieren, und so den gesamten Verkehr der an den echten Server
gehen soll abfangen.

Maßnahmen

Entfernen Sie in der Default Domain Controllers Policy die Gruppe Authentifizierte Benutzer
aus dem Recht Hinzufügen von Arbeitsstationen zur Domäne.
Wenn Sie, alternativ, einer eingeschränkten Gruppe von Benutzern das Erstellen von
Computerkonten gestatten wollen, können Sie dies natürlich ebenfalls über das Recht
Hinzufügen von Arbeitsstationen zur Domäne machen. Sie können z. B. eine neue Gruppe
„Computerkonten Ersteller“ erstellen und dieser Gruppe alle Benutzer, die das Recht
Hinzufügen von Arbeitsstationen zur Domäne haben sollen, hinzufügen. Danach geben Sie der
Gruppe das Recht in der Default Domain Controllers Policy. Sie können zur Definition dieser
Benutzergruppe auch die Berechtigungen Computerkonten erstellen und Computerkonten
löschen an jeder OU (oder der Domäne) vergeben. Benutzer können beliebige Computerkonten
in allen Containern (z. B. die OU einer Niederlassung) erstellen, in denen Sie dieses Recht
besitzen.
Eine Sicherheitsgruppe mit dem Namen „Serververwaltung“ könnte z. B. die Rechte
Computerkonten erstellen und Computerkonten löschen für die Mitgliedsserver-OU haben.
Jedes Mitglied der Gruppe Serververwaltung hätte dann die Möglichkeit eine beliebige Menge
von Computerkonten in der OU Mitgliedsserver zu erstellen. Weitere Informationen zur
Erstellung von Computerkonten in OUs entnehmen Sie bitte dem Knowledge-Base-Artikel
Q251335, "Domain Users Cannot Join Workstation or Server to a Domain."
Als letztes können Sie, wenn Sie weiterhin den authentifizierten Benutzer das Erstellen von
Computerkonten über das Hinzufügen einer Arbeitsstation zur Domäne gestatten wollen, die
Voreinstellung von 10 Konten heruntersetzen. Ändern Sie hierzu den Wert des Attributes ms-DS-
MachineAccountQuote von 10 auf einen Dezimalwert größer 0. Wenn Sie diesen Wert auf 0
setzen, deaktivieren Sie dieses Recht. Weitere Informationen entnehmen Sie bitte dem
Knowledge-Base-Artikel Q243327, "Default Limit to Number of Workstations a User Can Join
to the Domain."

Mögliche Auswirkungen

Benutzer, die vorher die Möglichkeit hatten ihre eigenen Arbeitsstationen der Domäne beitreten
zu lassen, können dies nun nicht mehr. Dies könnte sich möglicherweise auf ihre Arbeit
auswirken, speziell, wenn sie regelmäßig Computerkonten erstellen.
Dieser Schritt kann den administrativen Aufwand in der Umgebung erhöhen, da Computerkonten
bereits im Voraus für neue Computer bereitgestellt werden müssen. Er kann außerdem dazu
führen, dass der Koordinationsaufwand mit der zentralen IT-Abteilung beim Bereitstellen neuer
Computer größer wird, da diese Computerkonten nun auf Anforderung erstellen muss. Außerdem
eröffnet das Erstellen von Computerkonten im Voraus ein neues Sicherheitsloch. Sind die neuen
Computerkonten länger ungenutzt, vergrößert sich die Gefahr, dass jemand ein Computerkonto
„stiehlt“ indem er einen nicht autorisierten Computer unter Verwendung des ungenutzten
Computerkontos zur Domäne hinzufügt. Da Windows ein vorhersagbares Passwort für diese
Computerkonto verwendet ist dies möglich. Dieses vorgegebene Passwort für jedes ungenutzte
Computerkonto, das in Active Directory registriert ist, bleibt bestehen bis ein Computer dieses
Konto zum Beitritt zur Domäne nutzt.
Auch wenn der „Kontodieb“ auffliegt, z. B. wenn der berechtigte Benutzer seinen Computer
nicht in die Domäne aufnehmen kann, ist der Angreifer doch in der Zwischenzeit in der Lage den
Domänencomputer zu nutzen.

Contoso Szenario

Im Szenario von Contoso werden Computer nur von IT-Mitarbeitern zum Netzwerk hinzugefügt.
Diese haben die Erstellen/Löschen-Berechtigung für alle relevanten OUs. Es ist keinem Benutzer
erlaubt Arbeitsstationen in die Domäne aufzunehmen. Deshalb wurde dieses Recht für alle
Benutzer entfernt. Die Gruppe authentifizierte Benutzer wurde über das folgende Verfahren in
der Vorlage MSS DCBaseline Role.inf aus dem Recht Arbeitsstationen zur Domäne hinzufügen
entfernt.
Um die Gruppen zu ändern, die das Recht „Hinzufügen von Arbeitsstationen zur Domäne“
haben:
     1. Öffnen Sie das Snap-In Active Directory Benutzer und Computer – verwenden Sie
        ein Benutzerkonto mit der Berechtigung das GPO Default Domain Controllers Policy
        zu bearbeiten
     2. Klicken Sie mit der rechten Maustaste auf die OU Domänencontroller und wählen Sie
        Eigenschaften
     3. Wählen Sie auf der Registerkarte Gruppenrichtlinie das Default Domain Controllers
        Policy GPO aus und klicken Sie auf den Schalter Bearbeiten
     4. Klicken Sie doppelt auf Windows-Einstellungen, Sicherheitseinstellungen, lokale
        Einstellungen und dann auf Zuweisen von Benutzerrechten
     5. Klicken Sie doppelt auf die Einstellungen Hinzufügen von Arbeitensstationen zur
        Domäne
     6. Um ein Mitglied zu entfernen klicken Sie auf den Eintrag (z. B. authentifizierte
        Benutzer und dann auf den Schalter entfernen
Um ein Mitglied hinzuzufügen klicken Sie auf den Schalter hinzufügen, wählen den Benutzer
oder die Gruppe aus und klicken dann auf OK

Schutz gegen Denial of Service-Angriffe gegen Kerberos/TCP

Sicherheitslücken

Es gibt ein paar Bedingungen, unter denen Windows 2000 Domänencontroller zeitweise
aufhören, anfragen des Kerberos-Protokolls über TCP entgegenzunehmen. Hierbei handelt es
sich um ein bekanntes Problem. Dieses wurde nach SP3 durch einen Hotfix beseitigt. Ein Hotfix
ist ein aus einer oder mehreren Dateien zusammengesetztes Packet, das genutzt werden kann um
Fehler in Produkten zu beseitigen. Hotfixes beziehen sich auf die Situation spezieller Kunden und
sollten außerhalb der Organisation dieses Kunden nicht ohne das offizielle Einverständnis vom
Microsoft weitergegeben werden. Diese Angriffsmöglichkeit ist im Knowledge-Base-Artikel
Q320903, „Clients Cannot Log On by Using Kerberos over TCP." detaillierter beschrieben.
Auch bei hoch ausgelasteten Domänencontrollern ist dieser Fall durch berechtigte Nutzung sehr
unwahrscheinlich. Trotzdem ist es möglich, dass ein Angreifer diese Möglichkeit eines DoS-
Angriffs ausnutzt, und dass so der Domänencontroller zeitweise nicht mehr auf Kerberos-
Anfragen über TCP antwortet.
In der Voreinstellung verwendet das Kerberos Authentifizierungsprotokoll zum Senden und zum
Empfang das User Datagram Protokoll (UDP) auf Port 88. Wenn die Kerberos-Pakete größer als
2.000 Bytes (das ist die Voreinstellung) werden, wechselt Windows 2000 zu TCP auf Port 88. In
einigen Organisationen sind Clients mit Windows 2000 und Windows XP so konfiguriert, dass
sie für das Kerberos-Protokoll immer TCP verwenden. Der Knowledge-Base-Artikel Q244474,
"Forcing Kerberos to Use TCP Rather Than UDP in Windows 2000" erklärt die häufigsten
Situationen, die eine solche Änderung rechtfertigen.

Maßnahmen

Wenn Sie in Ihrer Umgebung eine solche Bedrohung für möglich halten, oder wenn bei Ihnen die
Bedingungen, die im Knowledge-Base-Artikel Q320903 näher beschrieben sind, zutreffen, dann
laden Sie Sich den Hotfix von Microsoft herunter der in diesem Knowledge-Base-Artikel
beschrieben ist. Wenden Sie den Hotfix auf alle Domänencontroller an.
Alternativ können Sie die Hilfeanforderungen Ihres Helpdesks beobachten. Ein ungewöhnlich
langsamer Anmeldevorgang kann ein Indikator für dieses Problem sein. Eine langsame
Anmeldung kann allerdings auch durch viele andere Probleme verursacht werden. Festzustellen
was eine Anmeldung verlangsamt, ist bekanntlich äußerst schwierig.
Sie können außerdem die Nutzung des in Knowledge-Base-Artikel Q244474 beschriebenen
Workarounds begrenzen, um so die Menge an Kerberos-Verkehr über TCP zu vermindern.
Artikel Q244474 beschreibt ein Problem im Zusammenhang mit fehlgeschlagenen Anmeldungen,
welches häufig durch verloren Paketfragmente verursacht wird. Probleme, die sich hierauf
beziehen, sind ohne den Wechsel zu TCP sehr viel schwieriger zu lösen. Wenn Sie Sich
tatsächlich entschlossen haben zu wechseln ist es unwahrscheinlich, dass Sie in der Lage sind
zurück zu UDP zu wechseln.
Weiterhin möchten viele Organisationen die Zuverlässigkeit der Authentifizierung über das
Kerberos-Protokoll erhöhen, da es eine Schlüsselrolle im Zusammenhang mit den
Unternehmensanwendungen spielt. Ein Wechsel zu TCP erhöht diese Zuverlässigkeit. Aus diesen
Gründen ist eine Beschränkung der Nutzung von TCP, um das Risiko eines DoS-Angriffs zu
minimieren, nicht empfehlenswert.

Mögliche Auswirkungen

Die möglichen Auswirkungen sind die gleichen wie bei jedem Hotfix. Wie immer sollten Sie
ausführliche Tests durchführen, bevor Sie den Hotfix in Ihrer Produktivumgebung anwenden.

Contoso Szenario

Im Contoso Szenario ist die Geschwindigkeit des Anmeldevorganges hochgradig wichtig, und es
besteht die Möglichkeit von internen Netzwerkangriffen. Aus diesen Gründen wurde der Hotfix
aus dem Knowledge-Base-Artikel Q320903 als vorbeugende Maßnahme angewandt.
► Um den Hotfix für Q320903 zu bekommen und anzuwenden
     1. Fordern Sie den im Knowledge-Base-Artikel Q320903 beschriebenen Hotfix beim
        Microsoft Product Support oder dem Premier Help Desk an.
     2. Testen Sie den Hotfix und wenden Sie ihn, entsprechend der Verfahrensweisen Ihrer
        Organisation im Bezug auf Test und Verteilung von Hotfixes, an.

Zusätzliche Sicherheitseinstellungen - Active Directory integrierter
DNS-Server
Microsoft schlägt die Verwendung eines Active Directory integrierten DNS vor, unter anderem,
weil Active Directory integrierte Zonen den Prozess der Absicherung der DNS-Infrastruktur
erleichtern.

DNS-Server schützen

Sicherheitslücken

Ein möglicher Grund für einen Angriff auf einen DNS-Server ist, dem Angreifer die Kontrolle
über die Informationen zu geben, mit denen der DNS-Server auf die Anfragen von Clients
antwortet. Auf diese Art können Clients ohne ihr Wissen zu nicht autorisierten Computern
umgeleitet werden. Beispiele für diese Art von Angriff sind z. B. IP-Spoofing und Cache-
Poisoning.
Beim IP-Spoofing wird für eine Übertragung die IP-Adresse eines autorisierten Benutzers
verwendet, um so Zugriff auf einen Computer oder ein Netzwerk zu erlangen. Cache-Poisoning
passiert, wenn ständig alle Namen, die auf eine Anfrage zurückgegeben werden,
zwischengespeichert werden. So sollen spätere Anfragen beschleunigt werden.
Sobald Clients unbeabsichtigt mit unautorisierten Computern kommunizieren, könnten diese
Computer versuchen Informationen, die auf den Clientrechnern gespeichert sind, abzufragen.
Nicht alle Angriffe beziehen sich auf die Umleitung von DNS-Servern. Einige DoS-Angriffe
könnten Einträge von legitimen DNS-Servern abändern, so dass den anfragenden Clients falsche
Adressen zurückgeliefert werden. Indem man die Server dazu bringt auf Clientanfragen falsche
Adressen zu liefern ist es möglich zu verhindern, dass Clients und Server die benötigten
Ressourcen (z. B. Domänencontroller, Webserver oder Netzwerkfreigaben) finden. Dies wird in
dem Abschnitt „Absichern des DNS-Datencontainers“ weiter unten in diesem Kapitel näher
besprochen.

Maßnahmen

Da die Konfiguration des gesamten DNS-Clients auf IP-Adressen basiert, konfigurieren Sie auf
allen Routern das Verwerfen von „Spoofed IP-packets“. So stellen Sie sicher, dass die IP-
Adressen der DNS-Server nicht von anderen Computern verändert wurden.
Alternativ können Sie den Schaden solcher Angriffe für Ihre DNS-Server beschränken, indem Sie
die Verbindung der DNS-Server überwachen.

Mögliche Auswirkungen

Keine.

Contoso Szenario

Da alle DNS-Server (Domänencontroller) von Contoso in Nordamerika äußerst wichtig sind,
wurden alle Router in der Umgebung von Contoso so konfiguriert, dass „IP-Address spoofing“
verhindert wird.
Es sind nicht alle Clients in der Lage IPSec zu nutzen. Deshalb wurde die IPSec Verschlüsselung
oder Signierung auf den DNS-Server nicht aktiviert – weitere Informationen entnehmen Sie bitte
dem Abschnitt „Blockieren von Ports mit IPSec-Filtern“ weiter unten in diesem Kapitel.
Die Leistung der Domänencontroller und DNS-Server wurde mit dem Microsoft Operations
Manager (MOM) überwacht.

Sichere dynamische Aktualisierung konfigurieren

Sicherheitslücken

Der DNS-Server von Windows 2000 und die Clients unterstützen DDNS-Aktualisierungen. Diese
erlaubt es den Clients auf DNS-Server die dies unterstützen direkt DNS-Einträge in die
Datenbank hinzuzufügen. Nicht autorisierte DDNS-Aktualisierungen können auf einem Windows
2000 DNS-Server passieren wenn:
        der Angreifer mit einem Client arbeitet, der das DDNS-Protokoll unterstützt.
        der DNS-Server so konfiguriert ist, dass er ungesicherte Aktualisierungen akzeptiert.
Im günstigsten Fall kann ein Angreifer der DNS-Datenbank gefälschte Einträge hinzufügen; im
ungünstigsten Fall kann der Angreifer korrekte Einträge in der DNS-Datenbank überschreiben
oder löschen. Mögliche Auswirkungen dieser Art eines Angriffs sind unter anderem:
      Weiterleitung von Clients zu nicht autorisierten Domänencontrollern.
       Ein kompromittierter DNS-Server kann so verändert werden, dass auf Clientanfragen die
       Adresse eines nicht autorisierten Servers zurückgibt. In Verbindung mit anderen nicht
       DNS-bezogenen Angriffen kann der Client dann dazu gebracht werden,
       sicherheitsrelevante Informationen an den gefälschten Server zu senden.
      Antwort auf DNS-Abfragen mit ungültigen Adressen
       Clients und Server sind nicht mehr in der Lage sich gegenseitig zu finden. Wenn die
       Clients nicht mehr in der Lagen sind die Server zu finden, können sie auch nicht mehr auf
       das Verzeichnis zugreifen. Wenn die Domänencontroller nicht mehr in der Lage sind
       andere Domänencontroller zu finden, findet keine Replikation mehr statt.
      Der Server antwortet nicht mehr auf Anfragen (DoS), es kann z. B. folgendes passieren:
           o der Server hat keinen ausreichenden Plattenplatz mehr, da eine große Zone erstellt
             wurde die nur Fülleinträge enthält.
           o im Zonen-Contrainer des Verzeichnisses könnte eine große Menge an Einträgen,
             z. B. mehr als 50.000, erstellt werden. Das verlangsamt die Replikation.

Maßnahmen

Um die Registrierung falscher Einträge schon im voraus zu verhindern, sollten Sie die sichere
dynamische Aktualisierung nutzen. Die Nutzung der sicheren dynamischen Aktualisierung
(DDNS) garantiert, dass Registrierungsanfragen nicht verarbeitet werden, wenn sie von gültigen
Clients der Gesamtstruktur kommen. Dies macht es für einen Angreifer viel schwieriger diese Art
Angriff durchzuführen. Ein Angreifer muss erst Zugriff auf eine Arbeitsstation erlangen, die
Mitglied der Gesamtstruktur ist.
Sie können, alternativ, auch die DDNS-Aktualisierung deaktivieren. Dies verhindert die Angriffe,
die oben beschrieben wurden. Die Kosten für die Pflege aktueller DNS-Einträge werden damit
natürlich deutlich steigen, da alle Aktualisierungen per Hand durchgeführt werden müssen. Die
Anzahl von DNS-Einträgen, die in einer Windows 2000 Umgebung gepflegt werden müssen, ist
wahrscheinlich deutlich höher als Administratoren einer Umgebung vor Windows 2000
vermuten.
Weitere Informationen entnehmen Sie bitte den folgenden Knowledge-Base-Artikeln:
   o Q246804, "How to Enable/Disable Windows 2000 Dynamic DNS Registrations."
   o Q198767, "How to Prevent Domain Controllers from Dynamically Registering DNS
     Names."

Mögliche Auswirkungen

Sobald eine Zone gesichert wurde, könnten einige nicht-Windows 2000 Systeme nicht in der
Lage sein, Einträge über DDNS in eine Active-Directory-integrierten Zone hinzuzufügen. Diese
Situation kann für Clients, die das DHCP (Dynamic Host Configuration Protocol) nutzen
umgangen werden, indem der Windows 2000 DHCP-Server so konfiguriert wird, dass er DNS-
Einträge im Namen der Clients registriert. Die Verwendung von DHCP-Servern zur
Registrierung von DDNS-Einträgen wird natürlich bei nicht DHCP-Clients keine Hilfe sein. Für
Systeme, die DDNS-Aktualisierung nicht unterstützten und ihre IP-Adresse nicht von einem
Windows 2000 DHCP erhalten, müssen Sie die Einträge manuell registrieren.

Contoso Szenario

Die Active Directory integrierten DNS-Server im Contoso Szenario wurden manuell so
konfiguriert, dass sie ausschließlich sichere DDNS-Aktualisierungen akzeptieren.
So Aktivieren Sie sichere DDNS-Aktualisierung für jede Zone (Forward Lookup Zone und
Reverse Lookup Zone):
     1. Öffnen Sie das DNS-Server Snap-In und dann den entsprechenden Ordner (Forward
        Lookup Zone oder Reverse Lookup Zone).
     2. Klicken Sie mit der rechten Maustaste auf die entsprechende Zone (z. B.
        northamerica.corp.contoso.com) und wählen Sie Eigenschaften
     3. Auf der Registerkarte Allgemein wählen Sie im Feld dynamische Aktualisierung den
        Eintrag sichere Aktualisierung aus

Anmerkung: In diesem Verfahren vor davon ausgegangen, dass unter der Registerkarte
Allgemein der Typ Active Directory integriert konfiguriert ist.


Absichern des DNS-Datencontainers

Sicherheitslücken

Für den Zonen-Container können ACL-Berechtigungen gesetzt werden, um den Zugriff von
Benutzern zu beschränken, die möglicherweise über Verwaltungswerkzeuge wie das DNS-Snap-
In oder ADSI-Edit versuchen könnten Änderungen vorzunehmen.
Administratoren, Domänenadministratoren, Organisationsadministratoren und DNS-
Administratoren haben als Voreinstellungen der Rechte Vollzugriff auf alle DNS-Komponenten.
Alle Anderen haben Lesezugriff. Wenn die vorgegebene ACL geändert wird, könnte es zu nicht
bösartigen Bedrohungen, durch Benutzer die unbeabsichtigt das Recht erhalten, Änderungen am
DNS-Container durchzuführen, kommen. Dies könnten Änderungen an den Eigenschaften des
DNS-Servers oder den Daten die in der integrierten Zone gespeichert sind, sein. Nicht bösartige
Bedrohungen entstehen typischerweise durch unerfahren Benutzer und deren Unkenntnis im
Bezug auf Sicherheitsbedrohungen und –schwachstellen.

Maßnahmen

Beschränken Sie die ACL auf den Container Microsoft DNS in jeder Domäne, die einen
Active Directory integrierten DNS nutzt auf die Voreinstellungen.
Alternativ können Sie die Mitgliedschaften in den Gruppen einschränken, die als
Voreinstellungen in der Lage sind die Einstellungen und Daten zu ändern (das sind die Gruppen
Administratoren, Domänenadministratoren, Organisationsadministratoren und DNS-
Administratoren).

Mögliche Auswirkungen

Falsche Berechtigungen auf den Container Microsoft DNS oder irgendeiner Active Directory
integrierten DNS-Zone, können ernsthafte Konsequenzen für Ihre Organisation haben. Zu
großzügige Berechtigungen könnten es unautorisierten Benutzern erlauben, Ihren DNS-Servern
oder den Zonendaten schaden zuzufügen. Umgekehrt könnten zu restriktive Berechtigungen
theoretisch zu einer DoS-Situation führen. Z. B. wenn versucht wird die DNS-Daten aus dem
Verzeichnis zu lesen, oder wenn neue dynamische Aktualisierungen hinzugefügt werden.

Anmerkung: Stellen Sie unter allen Umständen sicher, dass SYSTEM Vollzugriff hat.


Contoso Szenario

Es wurde überprüft, dass die Vorgegebenen Einstellungen für den Microsoft DNS und alle
untergeordneten Zonen konfiguriert sind.
► Um die Berechtigungen für den Active Directory integrierten DNS anzuzeigen oder zu ändern
     1.    Offenen Sie DNS-Server MMC, klicken Sie mit der rechten Maustaste auf den DNS-
           Server und wählen Sie Eigenschaften
     2.    Wechseln Sie zur Registerkarte Sicherheitseinstellungen und klicken Sie dann auf den
           Schalter Erweitert

Schutz gegen „DNS Cache Poisoning“ konfigurieren

Sicherheitslücken

Es ist möglich, nicht autorisierte Einträge direkt in den Cache eines DNS-Servers hinzuzufügen.
Clients könnten so zu nicht autorisierten Zielen fehlgeleitet werden. Hierbei handelt es sich um
ein Beispiel für die Beschädigung des Cache.

Maßnahmen

Aktivieren Sie die Einstellungen Zwischenspeicher vor Beschädigungen sichern auf allen
DNS-Servern. Wenn diese Funktion aktiviert ist, kann der Server feststellen ob Einträge
beschädigt oder unsicher sind, um sie dann zu verwerfen. Weitere Informationen erhalten Sie im
Knowledge-Base-Artikel Q316786, "Description of the DNS Server Secure Cache Against
Pollution Setting."

Mögliche Auswirkungen

Minimal.

Contoso Szenario
Im Contoso Szenario wurden die Active Directory integrierten DNS-Server gegen
Beschädigungen des Cache abgesichert.
► Um die Absicherungen gegen die Beschädigung des Cache zu aktivieren
     1. Öffnen Sie die DNS-Server MMC, klicken Sie mit der rechten Maustaste auf den
        DNS-Server und wählen Sie Eigenschaften
     2. Wechseln Sie zur Registerkarte Erweitert und stellen Sie sicher, dass die Einstellung
        Zwischenspeicher vor Beschädigungen sichern aktiviert ist


Die Verzeichnisse für DNS-Daten und Protokolle sichern

Sicherheitslücken

Windows 2000 DNS-Server, die als Active Directory integrierter DNS konfiguriert sind,
speichern ihre Zonendaten im Active Directory. DNS-Server die als primärer oder sekundärer
DNS-Server konfiguriert sind, speichern ihre Zonendaten jedoch in der Voreinstellung in einer
Textdatei im Ordner %SystemRoot%\system32\dns.
Außerdem werden Fehlerprotokolle, wenn Sie denn konfiguriert wurden, ebenfalls im Ordner
%SystemRoot%\system32\dns in einer Textdatei gespeichert.
Die vorgegebenen Berechtigungen für diese beiden Dateien geben Benutzern Lesezugriff und
Hauptbenutzern Änderungszugriff.
Diese Daten des DNS-Servers könnten kompromittiert werden, wenn der Server Angriffen über
einen Pufferüberlauf oder Angriffen über das Verzeichnis ausgesetzt ist. Durch diese könnte
Zugriff auf die Daten innerhalb der Systempartition erlangt werden. Ein Pufferüberlauf ist ein
Sicherheitsleck, das der Angreifer nutzt um Zugriff auf ein System zu erlangen.

Maßnahmen

Reduzieren Sie die Berechtigungen auf den Ordner %SystemRoot%\system32\dns, so dass
nur Administratoren und SYSTEM Berechtigungen auf diese Dateien haben.
Alternativ können Sie die Daten- und Protokolldateien in eine separate Partition oder ein anderes
Verzeichnis, das potentiellen Angreifern nicht bekannt ist, verschieben. Das Verschieben der
Dateien wird natürlich nicht notwendigerweise zu sichereren Berechtigungen auf diese Dateien
führen. Das heißt, sie sind noch immer potentielle Sicherheitslecks für Angriffe für alle die sie
finden können (z. B. indem die Speicherorte in der Registrierung abgefragt werden).

Mögliche Auswirkungen

Da nur die Administratoren und das System Zugriff auf diese Dateien benötigt, sind die
möglichen Auswirkungen minimal. Idealerweise delegieren Sie die Administration des DNS-
Server an eine neue Gruppe, die in der Gruppe Administratoren auf dem DNS-Server nicht
Mitglied ist. In diesem Fall müssen Sie sicherstellen, dass die neue Gruppe auch über die
Berechtigungen auf diese Dateien verfügt, da Sie diese zur Erfüllung Ihrer Aufgaben benötigen.
Contoso Szenario

Im Contoso Szenario sind sämtlichen DNS-Daten im Active Directory gespeichert. Deshalb
waren Änderungen der Berechtigungen nicht notwendig.
► Um die Berechtigungen auf die Voreingestellten Ordnern für die DNS-Dateien zu
beschränken
     1. Öffnen Sie eine Eingabeaufforderung
     2. Geben Sie folgenden Befehl ein: cacls.exe %systemroot%\system32\dns /t / g
        administrators:F system:F
     3. Wenn Sie dazu aufgefordert werden, geben Sie zum Fortfahren Y ein

Anmerkung: Wenn Sie die DNS-Dateien in einen anderen ungesicherten Ordner verschoben
haben, denken Sie daran den Ordner, der in dem oben angegebenen calcs.exe-Befehle verwendet
wird, zu ändern.


DNS-Daten- und DNS-Protokollverzeichnis verschieben

Sicherheitslücken

Windows 2000 DNS-Server, die als Active Directory integrierter DNS konfiguriert sind,
speichern ihre Zonendaten im Active Directory. DNS-Server, die als primärer oder sekundärer
DNS-Server konfiguriert sind, speichern ihre Zonendaten jedoch in der Voreinstellung in einer
Textdatei im Ordner %SystemRoot%\system32\dns.
Außerdem werden Fehlerprotokolle, wenn Sie denn konfiguriert wurden, ebenfalls im Ordner
%SystemRoot%\system32\dns in einer Textdatei gespeichert.
Die Vorgegebenen Berechtigungen für diese beiden Dateien geben Benutzer Lesezugriff und
Hauptbenutzern Änderungszugriff.
Diese Daten des DNS-Servers könnten kompromittiert werden, wenn der Server Angriffen über
einen Pufferüberlauf oder Angriffen über das Verzeichnis ausgesetzt ist. Durch diese könnte
Zugriff auf die Daten innerhalb der Systempartition erlangt werden. Ein Pufferüberlauf ist ein
Sicherheitsleck, das Angreifer nutzt um Zugriff auf ein System zu erlangen.

Maßnahmen

Verschieben Sie die DNS Zonendateien und die Protokolldateien auf eine nicht
Systempartition. Alternativ können Sie die Berechtigungen auf den vorgegebenen Ordner
(%SystemRoot%\system32\dns) für die DNS-Dateien reduzieren. Dies wird das Angriffspotential
gegen diese Dateien jedoch nicht verringern. Angriffe könnten z. B. über kompromittierte
Dienste, die unter dem Systemkonto oder einem Konto mit Administratorrechten ausgeführt
werden, erfolgen.

Mögliche Auswirkungen
Wenn Sie Ihr Datensicherungsteam nicht über den neuen Speicherort dieser Dateien informieren,
könnten Sie bei der nächsten Datensicherung übersehen werden. Vermeiden Sie einen
potentiellen Datenverlust, indem Sie sicherstellen, dass diese Dateien auch an ihrem neuen
Speicherort gesichert werden.

Contoso Szenario

Im Contoso Szenario sind sämtliche DNS-Daten im Active Directory gespeichert. Es gibt keine
Textdateien und deshalb waren Änderungen nicht notwendig.
Im Contoso Szenario ist die Protokollierung von Fehlern für DNS-Server nicht aktiviert.
Trotzdem wurde vorsorglich der Speicherort für das Fehlerprotokoll geändert, so dass diese, bei
einer späteren Verwendung der Protokollfunktionalität, auf einer separaten Platte gesichert
werden.
► Um die DNS-Zonendateien zu verschieben
     1. Starten Sie Regedit.exe und öffnen Sie den Schlüssel
        HKLM\System\CurrentControlSet\Services\DNS\Parameters.
     2. Wählen Sie im Menü Bearbeiten die Option Neu, Zeichenkette und vergeben Sie den
        Namen "DatabaseDirectory."
     3. Klicken Sie doppelt auf den neuen Eintrag DatabaseDirectory und geben Sie in das
        Feld Wert den vollen Pfad zu dem Ordern ein, in dem Sie die Zonendaten speichern
        möchten.

Anmerkung: Wenn Sie diese Registrierungsänderung vornehmen, wird der DNS-Server die
original Datenbank nicht verschieben und sie auch nicht weiter pflegen

     4. Halten Sie den DNS Server an.
     5. Wenn Sie schon eine DNS-Datenbank im Ordner Systemroot\System32\Dns haben,
        müssen Sie diese manuell in den neuen Ordner verschieben. Verschieben Sie alle
        Dateien und Ordner im Ordner %systemroot%\system32\dns in den neuen Ordner.
     6. Starten Sie den DNS-Server wieder.


► Um die DNS-Protokolldateien zu verschieben
     1. Starten Sie Regedit.exe und öffnen Sie den Schlüssel
        HKLM\System\CurrentControlSet\Services\DNS\Parameters.
     2. Wählen Sie im Menü Bearbeiten die Option Neu, Zeichenkette und vergeben Sie den
        Namen "LogFilePath."
     3. Klicken Sie doppelt auf den neuen Eintrag LogFilePath und geben Sie im Feld Wert
        den vollen Pfad zu dem Ordern ein, in dem Sie die Protokolldateien speichern möchten.
     4. Starten Sie den DNS-Server neu
Zonenübertragung auf autorisierte Systeme Einschränken

Sicherheitslücken

Zusätzlich zu den Active Directory integrierten DNS-Servern, gibt es DNS-Server die, als
primäre oder sekundäre DNS-Server konfiguriert sind. Sekundäre DNS-Server übertragen
typischerweise zur Synchronisierung der Inhalte die gesamte Zonendatei von einem primären
DNS-Server.
Wenn die Zonenübertragung auf einem DNS-Server nicht eingeschränkt wurde, überträgt der
DNS-Server die gesamten Zonendaten an jeden der sie anfordert. Dies kann über Werkzeuge wie
z. B. nslookup.exe sehr einfach durchgeführt werden. Der gesamte DNS-Datensatz der Domäne
wird so bloßgelegt. Inklusive solcher Informationen wie: welcher Host fungiert als
Domänencontroller, Webserver oder SQL Server 2000.

Maßnahmen

Konfigurieren Sie die DNS-Server so, dass sie eine Zonenübertragung nur an bekannte Computer
erlauben (nämlich nur die sekundären DNS-Server).
Alternativ können Sie auch die Zonenübertragung ganz verbieten. Dies könnte allerdings in
großen, verteilten Netzwerken schwer umzusetzen sein. Z. B. wenn Sie eine Hierarchie von
DNS-Servern haben und sekundäre DNS-Server näher an großen Gruppen von Computern
einsetzen möchten.

Mögliche Auswirkungen

Die Konfiguration kann bei Diensten, die eventuell die gesamte DNS-Zone auf einmal abfragen
müssen, zu Einschränkungen führen. Es könnte außerdem die Anfragen von DNS-Clients
verlangsamen, da diese möglicherweise alternative DNS-Server abfragen müssen.
Möglicherweise könnten, abhängig von Ihrer DNS-Infrastruktur, einige DNS-Abfragen
fehlschlagen.

Contoso Szenario

Im Contoso Szenario ist auf den Domänencontrollern der untergeordneten Domäne eine
sekundäre DNS-Zone für die Zone _msdcs.corp.contoso.com der Stammdomäne konfiguriert.
Die Domänencontroller der Stammdomäne wurden so konfiguriert, dass sie eine
Zonenübertragung für diese Zone nur zu den Domänencontrollern der untergeordneten Domäne,
zulassen. Hierzu nutzen sie die IP-Adressen der autorisierten DNS-Server. Alle anderen Active-
Directory-integrierten Zonen arbeiten mit der vorgegebenen Konfiguration. Diese erlaubt keine
Zonenübertragung.
► Um die Zonenübertragung auf bekannte Server einzuschränken
   1. Öffnen Sie das DNS-Administrationswerkzeug, klicken Sie mit der rechten
      Maustaste auf die Zone für die Sie die Zonenübertragung konfiguriert möchten und
      wählen Sie Eigenschaften
   2. Stellen Sie sicher, dass Zonenübertragung erlauben aktiviert ist, wählen Sie entweder
      Nur die folgenden Server oder„Nur die Server unter der Registerkarte Nameserver“.
           a) Wenn Sie Nur die folgenden Server auswählen, geben Sie die IP-Adressen dieser
              autorisierten DNS-Server ein. (Diese Einstellungen wurden für Contoso gewählt –
              die IP-Adressen der Domänencontroller der untergeordneten Domäne wurden
              hinzugefügt).
           b) Wenn Sie „Nur die Server unter der Registerkarte Nameserver“ ausgewählt haben,
              wechseln Sie zur Registerkarte Nameserver und geben Sie die Nameserver (DNS-
              Server) an, die eine sekundäre Zonenübertragung von diesem DNS-Server
              anfordern dürfen und für diese Zone autorisiert sind.

Blockieren von Ports über IPSec-Filter
Sicherheitslücken

Die Reduzierung der offenen Ports, auf denen Verbindungsversuche entgegengenommen werden,
auf den Server in Ihrer Organisation, wird die Angriffsfläche jeder einzelnen Maschine in großem
Umfang reduzieren. Die Angriffsfläche ist der Bereich der Client-/Servermaschinen in Ihrer
Umgebung, der für Angriffe verwundbar ist.
Offene Ports können einem Angreifer als Startpunkt für Angriffe auf andere Server Ihrer
Organisation dienen – ein Wurm und trojanisches Pferd kann z. B. eine Anwendung installieren,
die auf einem unautorisierten Port auf einem Server auf eingehende Befehle wartet.

Maßnahmen

Konfigurieren Sie IPSec Blockierungsfilter, die nur den Netzwerkverkehr erlauben, der unten
spezifiziert ist. Dies wird die Zahl von unerwarteten und nicht autorisierten Anwendungen, die
Anfragen entgegen nehmen oder angegriffen werden könnten, reduzieren.
Wie in der Tabelle 7.5 zu sehen, benötigen Domänencontroller für viele Funktionen das RPC-
Protokoll. Daher müssen mehrere verschiedene Einträge so, wie in der Liste unten umgesetzt
werden. Jeder Dienst teilt sich in Client- und Serverfunktionalität. Diese bezieht sich nicht
notwendigerweise auf Clients und Server. Sie zeigt stattdessen die entsprechenden IPSec-Filter,
die erstellt werden müssen, um den beschriebenen Dienst entweder anzubieten oder zu nutzen.
Die DNS-Clientrichtlinie sollte z. B. auf jeder Maschine angewandt werden, die eine
Funktionalität zur Namensauflösung benötigt. Die DNS-Serverregel würde nur auf Maschinen
die den DNS-Serverdienst ausführen angewandt. Andere Dienste, wie z. B. das SNMP-Protokoll
(Simple Network Management Protocol) können etwas verwirrend sein, da Ports für SNMP-
Server zwar erlaubt, Ports für SNMP-Client aber verboten sind. Tatsächlich, auf Grund der Natur
des SNMP-Protokolls – bei dem eine Remotestation einzelne Maschinen nach Informationen
abfragt, arbeitet SNMP auf Domänencontrollern als Serverdienst um diese Informationen für die
Remotestation anzubieten.
Domänencontroller IPSec Netzwerkverkehrsplan

Table 7.5: Domänencontroller IPSec Netzwerkverkehrsplan

Dienst     Protokoll Quellport Zielport Quelladresse   Zieladresse   Aktion

DNS        TCP       ALLE      53       Host IP        ALLE          ZULASSE
Client                                                               N

           UDP       ALLE      53       Host IP        ALLE          ZULASSE
                                                                     N

SNMP       TCP       ALLE      161      JEDE           Host IP       ZULASSE
Server                                                               N

           UDP       ALLE      161      ALLE           Host IP       ZULASSE
                                                                     N

CIFS/SM    TCP       ALLE      445      Host IP        ALLE          ZULASSE
B Client                                                             N

           UDP       ALLE      445      Host IP        ALLE          ZULASSE
                                                                     N

CIFS/SM    TCP       ALLE      445      ALLE           Host IP       ZULASSE
B Server                                                             N
                                                                     ZULASSE
           UDP       ALLE      445      ALLE           Host IP
                                                                     N
RPC        TCP       ALLE      135      Host IP        ALLE          ZULASSE
Client                                                               N

           UDP       ALLE      135      Host IP        ALLE          ZULASSE
                                                                     N

RPC        TCP       ALLE      135      ALLE           Host IP       ZULASSE
Server                                                               N

           UDP       ALLE      135      ALLE           Host IP       ZULASSE
                                                                     N

FRS/AD TCP           ALLE      57951    Host IP        ALLE          ZULASSE
Replikatio                                                           N
nsports
ausgehend

           TCP       ALLE      57952    Host IP        ALLE          ZULASSE
                                                                     N
FRS/AD TCP      ALLE   57951   ALLE      Host IP   ZULASSE
Replikatio                                         N
nsports
eingehend

          TCP   ALLE   57952   ALLE      Host IP   ZULASSE
                                                   N

NetBIOS   TCP   ALLE   137     Host IP   ALLE      ZULASSE
Client                                             N

          UDP   ALLE   137     Host IP   ALLE      ZULASSE
                                                   N

          TCP   ALLE   139     Host IP   ALLE      ZULASSE
                                                   N

          UDP   ALLE   138     Host IP   ALLE      ZULASSE
                                                   N

NetBIOS   TCP   ALLE   137     ALLE      Host IP   ZULASSE
Server                                             N

          UDP   ALLE   137     ALLE      Host IP   ZULASSE
                                                   N

          TCP   ALLE   139     ALLE      Host IP   ZULASSE
                                                   N

          UDP   ALLE   138     ALLE      Host IP   ZULASSE
                                                   N

NTP       TCP   ALLE   123     Host IP   ALLE      ZULASSE
Client                                             N

          UDP   ALLE   123     Host IP   ALLE      ZULASSE
                                                   N

Überwach ANY    ALLE   ALLE    Host IP   MOM       ZULASSE
ender                                    Server    N
Client

LDAP      TCP   ALLE   389     Host IP   ALLE      ZULASSE
Client                                             N

          UDP   ALLE   389     Host IP   ALLE      ZULASSE
                                                   N
           TCP   ALLE   636    Host IP   ALLE      ZULASSE
                                                   N

           UDP   ALLE   636    Host IP   ALLE      ZULASSE
                                                   N

Kerberos   TCP   ALLE   88     Host IP   ALLE      ZULASSE
Client                                             N

           UDP   ALLE   88     Host IP   ALLE      ZULASSE
                                                   N

Terminal   TCP   ALLE   3389   ALLE      Host IP   ZULASSE
Services                                           N

Global     TCP   ALLE   3268   Host IP   ALLE      ZULASSE
Catalog                                            N
Client

           TCP   ALLE   3269   Host IP   ALLE      ZULASSE
                                                   N

Global     TCP   ALLE   3268   ALLE      Host IP   ZULASSE
Catalog                                            N
Server

           TCP   ALLE   3269   ALLE      Host IP   ZULASSE
                                                   N

DNS        TCP   ALLE   53     ALLE      Host IP   ZULASSE
Server                                             N

           UDP   ALLE   53     ALLE      Host IP   ZULASSE
                                                   N

Kerberos   TCP   ALLE   88     ALLE      Host IP   ZULASSE
Server                                             N

           UDP   ALLE   88     ALLE      Host IP   ZULASSE
                                                   N

LDAP       TCP   ALLE   389    ALLE      Host IP   ZULASSE
Server                                             N

           UDP   ALLE   389    ALLE      Host IP   ZULASSE
                                                   N

           TCP   ALLE   636    ALLE      Host IP   ZULASSE
                                                                           N

            UDP        ALLE        636       ALLE            Host IP       ZULASSE
                                                                           N

NTP         TCP        ALLE        123       ALLE            Host IP       ZULASSE
Server                                                                     N

            UDP        ALLE        123       ALLE            Host IP       ZULASSE
                                                                           N

ICMP        ICMP       ALLE        ALLE      Host IP         ALLE          ZULASSE
                                                                           N

sämtlicher ALLE        ALLE        ALLE      ALLE            Host IP       BLOCKIE
eingehend                                                                  REN
er Verkehr


Anmerkung: Die Host IP unter Zieladresse in Tabelle 7.5 sollte auf die IP Ihres Servers gesetzt
sein. Außerdem ist es wichtig darauf hinzuweisen, dass der Kerberos-Filter nur notwendig ist,
wenn Sie die NoDefailtExempt-Einstellung implementiert haben. Weiter hierzu im Knowledge-
Base-Artikel Q254728, „IPSec Does Not Secure Kerberos Traffic Between Domain Controllers."

Alle Regeln, die oben aufgeführt sind, sollten bei Ihrer Implementierung gespiegelt werden. Dies
stellt sicher, dass es dem gesamten auf einem Domänencontroller eingehenden Verkehr auch
gestattet ist, zu ursprünglichen Server zurückzukommen.
Wie Sie oben gesehen haben, gibt es eine Anzahl Ports und Dienste, die auf dem
Domänencontroller geöffnet wurden. Die Konfiguration einer noch strengeren Sicherheit auf dem
Domänencontroller würde es Ihnen gestatten weitere Ports zu blockieren. Tatsächlich wurden
diese Ports geöffnet, da einige älterer Clients NetBIOS nutzen und ebenso um den
Administratoren der Maschinen eine zusätzliche Funktionalitäten zur Verfügung zu stellen.
Die in dem Knowledge-Base-Artikel Q319533, „How to Restrict FRS Replication to a Specific
Static Port" vorgeschlagenen Einstellungen wurden implementiert, um sicherzustellen, dass die
FRS-Replikation nur über einen einzelnen Port arbeitet. Contoso wählte hierfür den Port 57951
aus. Sie sollten in Ihrer Umgebung einen zufällig ausgewählten Port über 50.000 verwenden.
Auf den Domänencontrollern wurden die im Knowledge-Base-Artikel Q319533, „How to
Restrict FRS Replication to a Specific Static Port" vorgeschlagenen Einstellungen ebenfalls
umgesetzt. Dies stellt sicher, dass auch die NTDS-Replikation nur über einen speziellen Port
stattfindet. Contoso wählte hierzu den Port 57952. Sie sollten in Ihrer Umgebung auch hier einen
zufällig ausgewählten Port über 50.000 verwenden.
Nachdem alle Schritte aus diesem Knowledge-Base-Artikel implementiert worden sind, müssen
die Server neu gestartet werden. Erst dann wirken sich die Änderungen aus.
Bitte beachten Sie, dass Contoso einen MOM-Server in ihre Umgebung implementiert hat.
Aufgrund der Umfangreichen Interaktion zwischen MOM-Server und dem OnePoint-Client – die
Clientanwendung die Informationen an die MOM-Konsole sendet – ist jeglicher
Netzwerkverkehr zwischen dem Server und dem MOM-Server gestattet.


Scriptbefehle

Die Implementierung der folgenden Befehle sollte auf dem Domänencontroller ausgeführt
werden. Diese Befehle blockieren den Netzwerkverkehr so wie oben spezifiziert. Dieser Satz von
Befehlen steht Ihnen auch als Batchdatei die dieser Anleitung beiliegt, zur Verfügung.

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
       -f 192.168.100.11+*:53:TCP -f 192.168.100.11+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
       -f *+192.168.100.11:161:TCP -f *+192.168.100.11:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Client"
       -f 192.168.100.11+*:445:TCP -f 192.168.100.11+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Server"
       -f *+192.168.100.11:445:TCP -f *+192.168.100.11:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
       -f 192.168.100.11+*:135:TCP -f 192.168.100.11+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
       -f *+192.168.100.11:135:TCP -f *+192.168.100.11:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports IN"
       -f *+192.168.100.11:57951:TCP -f *+192.168.100.11:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports OUT"
       -f 192.168.100.11+*:57951:TCP -f 192.168.100.11:+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
       -f 192.168.100.11+*:137:TCP -f 192.168.100.11+*:137:UDP
       -f 192.168.100.11+*:139:TCP -f 192.168.100.11+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
       -f *+192.168.100.11:137:TCP -f *+192.168.100.11:137:UDP
       -f *+192.168.100.11:139:TCP -f *+192.168.100.11:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
       -f 192.168.100.11+*:123:TCP -f 192.168.100.11+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Überwachender"
       -f 192.168.100.31+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
       -f 192.168.100.11+*:389:TCP -f 192.168.100.11+*:389:UDP
       -f 192.168.100.11+*:636:TCP -f 192.168.100.11+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
       -f 192.168.100.11+*:88:TCP -f 192.168.100.11+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
       -f *+192.168.100.11:3389:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
       -f 192.168.100.11+*:3268:TCP -f 192.168.100.11+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP"
       -f 192.168.100.11+*:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Server"
       -f *+192.168.100.11:3268:TCP -f *+192.168.100.11:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DNS Server"
       -f *+192.168.100.11:53:TCP -f *+192.168.100.11:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Server"
       -f *+192.168.100.11:88:TCP -f *+192.168.100.11:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Server"
       -f *+192.168.100.11:389:TCP -f *+192.168.100.11:389:UDP
       -f *+192.168.100.11:636:TCP -f *+192.168.100.11:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Server"
       -f *+192.168.100.11:123:TCP -f *+192.168.100.11:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
       -f *+192.168.100.11 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x



Mögliche Auswirkungen

Da diese Einstellungen keinen Verkehr über zufällige hohe Ports zulassen, ist RPC-Verkehr nicht
erlaubt. Das kann die Verwaltung des Servers erschweren. Durch die Nutzung des Common
Internet File System (CIFS) und der grundlegenden NetBIOS Ports werden allerdings trotzdem
eine Menge Möglichkeiten bereitgestellt. Das CIFS-Protokoll definiert einen Standard für den
Dateizugriff über das Netzwerk. Mit CIFS haben Benutzer unterschiedlicher Plattformen und
Computer, die Möglichkeit Dateien ohne die Installation neuer Software zur Verfügung zu
stellen.
Administratoren sollen in der Lage sein, sich zur Remoteadministration mithilfe eines
Terminaldienst-Clients zu verbinden. Während Sie mit dem Domänencontroller verbunden sind,
sollten Sie in der Lage sein, Netzlaufwerke zu verbinden. Die oben angegebenen Richtlinien
können natürlich gestrafft werden, um diese Funktionen zu verhindern. Dann könnte die
Administration des Servers allerdings umständlich werden.
Die Implementierung dieser relativ kleinen Anzahl von IPSec-Richtlinien sollte keine spürbare
Auswirkung auf die Leistung des Servers haben. Trotzdem sollen vor der Implementierung dieser
Filter in Ihrer Umgebung umfangreiche Tests durchgeführt werden, um die nötige Funktionalität
und Leistung sicher zu stellen.

Contoso Szenario

Im Contoso Szenario wurden die IPSec-Filter, die oben dargestellt sind, auf den
Domänencontrollern implementiert. Die IP-Adressen wurden in den Scripten und
Kommandozeilenbefehlen jeweils durch die für jeden Domänencontroller passenden Adressen
ersetzt.

Diskussion zur Active Directory Sicherheit
Verwendung von Syskey

Syskey ist auf allen Windows 2000 Server in Modus 1 aktiviert. Es wird für Domänencontroller
die physikalischen Angriffsmöglichkeiten ausgesetzt sind, häufig vorgeschlagen, Syskey im
Modus 3 (Speicherung des Syskey-Passwortes auf einer Diskette) oder Modus 2
(Konsolenpasswort) zu aktivieren. Um eine Zusätzliche Sicherung des Modus 2 Syskey
Passwortes zu erhalten, können Sie für Ihren Domänencontroller eine Reparaturdiskette erstellen
und diese an einem sichereren Ort verwahren.
Syskey Modus 2 oder Modus 3 wird z. B. häufig für Domänencontroller in Niederlassungen
empfohlen, da die Domänencontroller dort oft nicht über eine ausreichende physikalische
Absicherung verfügen. Vom Standpunkt der Sicherheit aus erscheint dies erst einmal sinnvoll, da
Domänencontroller von einem Angreifer mit physikalischem Zugriff auf die Maschine einfach
neu gestartet werden könnte. Im Modus 1 würde dies dem Angreifer gestatten, die Inhalte der
Verzeichnisse zu lesen und zu verändern.
Wenn Sie sicherstellen möchten, dass Domänencontroller durch einen Neustart wieder verfügbar
werden, sind die operativen Anforderungen jedoch bei den Syskey-Modi 2 oder 3 schwierig zu
unterstützen
Erstens können die logistischen Anforderungen für die Verwaltung eines Syskey-Passwortes oder
der Disketten, vor allem in Niederlassungen, ziemlich Komplex sein.
Es könnte z. B. notwendig werden, dass ein leitender Mitarbeiter oder einer der örtlichen
Administratoren um 3 Uhr nachts in das Büro kommt, um ein Passwort einzugeben oder eine
Diskette zu verwenden, damit andere Benutzer das System nutzen können. Dies ist sehr teuer und
wird es schwierig machen, die Vereinbarung eines hohen Servicelevels (SLA) einzuhalten. Wenn
Sie alternativ Ihrer zentralen IT-Abteilung die Möglichkeit geben möchten, das Syskey Passwort
remote zu verwenden, benötigen Sie zusätzliche Hardware – einige Hardwarehersteller bieten
zusätzliche Hardwarelösungen an, um einen Remotezugriff auf die Konsole des Server zu
erlangen. Eine Solche Hardwarelösung würde benötigt.
Zweitens verbleibt Ihr Domänencontroller bei einem Verlust des Syskey Passwortes oder der
Diskette in einem Zustand, in dem er nicht wieder gestartet werden kann. Wenn das Passwort
oder die Diskette verloren ist, gibt es keine Methode den Domänencontroller wiederherzustellen.
Wenn dies passiert, muss der Domänencontroller neu aufgesetzt werden.
Infrastrukturserver Rolle
Bei der Rolle des Infrastrukturservers handelt es sich im Contoso Szenario entweder um einen
DHCP oder einen WINS-Server (Windows Internet Name Service).
Ein Unterschied der Definition eines Infrastrukturservers in dieser Anleitung und der
Infrastrukturserver-Rolle im Dokument „Microsoft Systems Architecture Enterprise Data Center
(MSA EDC) guide“ definiert ist, dass die Rolle hier nicht den DNS-Server einschließt.
Das liegt daran, dass im Contoso Szenario die gesamte DNS-Server Funktionalität als Active
Directory integrierter DNS-Server konfiguriert ist und so auf Domänencontroller zur Verfügung
gestellt wird.
Es mag trotzdem Unternehmen geben, die ihren DNS nicht in Active Directory integrieren
möchten, oder die einen primären oder sekundären DNS-Server auf einem anderen Server als
dem Domänencontroller nutzen möchten. Wenn einer dieser Fälle auf Ihre Umgebung zutrifft,
dann beachten Sie die Anleitung aus dem vorhergehenden Abschnitt „Zusätzliche
Sicherheitseinstellungen - Active Directory integrierter DNS-Server“ in diesem Kapitel.
Verwenden sie die Alternativen und Hinweise, die dort für die Implementierung eines nicht
integrierten DNS in angegeben sind.

Erweiterte Richtlinie für Infrastrukturserver
Die Infrastruktur Zusatzrichtlinie umfasst Einstellungen für Systemdienste, die auf einem
Infrastrukturserver notwendig sind.

Systemdienste

Die folgende Tabelle zeigt eine Zusammenfassung der vorgeschriebenen Systemdienste auf
einem Windows 2000 Infrastrukturserver und ob diese aktiviert oder deaktiviert sein müssen.
Diese Dienste sind in der Richtlinienvorlage MSS Infrastructure Role.inf konfiguriert, welche
dann in das Infrastruktur-Zusatzrichtlinien-GPO importiert wird.


Tabelle 7.6: Infrastruktur Zusatzrichtlinie - Diensteinstellungen
Dienst              Starttyp      Kommentar

DHCP-Server         automatisch   DHCP-Dienst für Clients

NT-LM-              automatisch   Bietet RPC-Sicherheit
Sicherheitsdienst

WINS                automatisch   WINS-Dienst für Clients




Anmerkung: Der DNS-Server ist im Contoso Szenario für die Rolle des Infrastrukturservers
deaktiviert, da dieser auf Domänencontrollern ausgeführt wird.
Einige Organisationen, die keinen Active Directory integrierten DNS nutzen, möchten
möglicherweise ihre primären oder sekundären DNS-Server auf einem Infrastrukturserver
ausführen. In diesem Fall muss die Vorlage für die Infrastruktur Zusatzrichtlinie so erweitert
werden, dass der Starttyp des Dienstes DNS-Server auf automatisch gesetzt ist.
Wenn dies in Ihrer Organisation notwendig wird, lesen Sie die Vorschläge zur Absicherungen eines Windows 2000
DNS-Server im Abschnitt „Zusätzliche Sicherheitseinstellungen - Active Directory integrierter DNS-
Server“ in diesem Kapitel.



Zusätzliche Sicherheitseinstellungen – WINS
Port über IPSec-Filter blockieren

Sicherheitslücken

Wie schon erwähnt, wird die Reduzierung der offenen Ports auf denen Verbindungsversuche
entgegengenommen werden, die Angriffsfläche jeder einzelnen Maschine in großem Umfang
reduzieren. Offene Ports können einem Angreifer als Startpunkt für Angriffe auf andere Server
Ihrer Organisation dienen – ein Wurm und trojanisches Pferd kann z. B. eine Anwendung
installieren, die an einem unautorisierten Port eines Servers auf eingehende Befehle wartet.

Maßnahmen

Konfigurieren Sie IPSec Blockierungsfilter, die nur den Netzwerkverkehr erlauben, der unten
spezifiziert ist. Dies wird die Zahl von unerwarteten und nicht autorisierten Anwendungen, die
Anfragen entgegen nehmen oder angegriffen werden könnten, reduzieren.


WINS Server IPSec Netzwerkverkehrsplan

Tabelle 7.7: WINS Server IPSec Network Traffic Map
Dienst             Protokoll     Quellport     Zielport     Quelladresse Zieladresse Aktion

DNS Client         TCP           ALLE          53           Host IP          ALLE           ZULASSEN

                   UDP           ALLE          53           Host IP          ALLE           ZULASSEN

SNMP Server        TCP           ALLE          161          ALLE             Host IP        ZULASSEN

                   UDP           ALLE          161          ALLE             Host IP        ZULASSEN

CIFS Client        TCP           ALLE          445          Host IP          ALLE           ZULASSEN

                   UDP           ALLE          445          Host IP          ALLE           ZULASSEN

CIFS Server        TCP           ALLE          445          ALLE             Host IP        ZULASSEN
              UDP    ALLE   445     ALLE      Host IP   ZULASSEN

RPC Client    TCP    ALLE   135     Host IP   ALLE      ZULASSEN

              UDP    ALLE   135     Host IP   ALLE      ZULASSEN

RPC Server    TCP    ALLE   135     ALLE      Host IP   ZULASSEN

              UDP    ALLE   135     ALLE      Host IP   ZULASSEN

zus. RPC Ports TCP   ALLE   57952   Host IP   ALLE      ZULASSEN
ausgehend

NetBIOS       TCP    ALLE   137     Host IP   ALLE      ZULASSEN
Client

              UDP    ALLE   137     Host IP   ALLE      ZULASSEN

              TCP    ALLE   139     Host IP   ALLE      ZULASSEN

              UDP    ALLE   138     Host IP   ALLE      ZULASSEN

NetBIOS       TCP    ALLE   137     ALLE      Host IP   ZULASSEN
Server

              UDP    ALLE   137     ALLE      Host IP   ZULASSEN

              TCP    ALLE   139     ALLE      Host IP   ZULASSEN

              UDP    ALLE   138     ALLE      Host IP   ZULASSEN

NTP Client    TCP    ALLE   123     Host IP   ALLE      ZULASSEN

              UDP    ALLE   123     Host IP   ALLE      ZULASSEN

Überwachender ALLE   ALLE   ALLE    Host IP   MOM       ZULASSEN
Client                                        Server

LDAP Client   TCP    ALLE   389     Host IP   ALLE      ZULASSEN

              UDP    ALLE   389     Host IP   ALLE      ZULASSEN

              TCP    ALLE   636     Host IP   ALLE      ZULASSEN

              UDP    ALLE   636     Host IP   ALLE      ZULASSEN

Kerberos      TCP    ALLE   88      Host IP   ALLE      ZULASSEN
Client
                 UDP         ALLE        88          Host IP       ALLE          ZULASSEN

Terminal         TCP         ALLE        3389        ALLE          Host IP       ZULASSEN
Services

Global Catalog TCP           ALLE        3268        Host IP       ALLE          ZULASSEN
Client

                 TCP         ALLE        3269        Host IP       ALLE          ZULASSEN

WINS             TCP         ALLE        1512        ALLE          Host IP       ZULASSEN
Resolution
Server

                 UDP         ALLE        1512        ALLE          Host IP       ZULASSEN

WINS             TCP         ALLE        42          Host IP       ALLE          ZULASSEN
Replication
Client

                 UDP         ALLE        42          Host IP       ALLE          ZULASSEN

WINS             TCP         ALLE        42          ALLE          Host IP       ZULASSEN
Replication
Server

                 UDP         ALLE        42          ALLE          Host IP       ZULASSEN

ICMP             ICMP        ALLE        ALLE        Host IP       ALLE          ZULASSEN

der gesamte      ALLE        ALLE        ALLE        ALLE          Host IP       BLOCKIEREN
eingehende
Verkehr


Anmerkung: Die Host IP unter Zieladresse in Tabelle 7.5 sollte auf die IP Ihres Servers gesetzt
sein.

Alle Regeln die oben aufgeführt sind, sollten bei Ihrer Implementierung gespiegelt werden. Dies
stellt sicher, dass es dem gesamten auf einem WINS-Server eingehende Verkehr auch gestattet
ist, zu ursprünglichen Server zurückzukommen.
Wie Sie oben gesehen haben, gibt es eine Anzahl Ports und Dienste, die auf dem WINS-Server
geöffnet wurden. Die Konfiguration einer noch strengeren Sicherheit auf dem WINS-Server
würde es ihnen gestatten weitere Ports zu blockieren. Tatsächlich wurden diese Ports geöffnet,
um den Administratoren der Maschinen zusätzliche Funktionalitäten zur Verfügung zu stellen.
Über eben diese zusätzlichen Funktionalitäten wird die gesamte WINS-Verwaltung und die
Verwaltung des Server über die Nutzung von Terminaldiensten durchgeführt.
Bitte beachten Sie, dass Contoso einen MOM-Server in der eigenen Umgebung implementiert
hat. Aufgrund der Umfangreichen Interaktion zwischen MOM-Server und dem OnePoint-Client –
die Clientanwendung die Informationen an die MOM-Konsole sendet – ist jeglicher
Netzwerkverkehr zwischen dem Server und dem MOM-Server gestattet.

Scriptbefehle

Die Implementierung der folgenden Befehle sollte auf dem WINS-Server ausgeführt werden.
Diese Befehle blockieren den Netzwerkverkehr so wie oben spezifiziert. Dieser Satz von
Befehlen steht Ihnen auch als Batchdatei, die dieser Anleitung beiliegt, zur Verfügung.


ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
      -f 192.168.100.22+*:53:TCP -f 192.168.100.22+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
      -f *+192.168.100.22:161:TCP -f *+192.168.100.22:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Client"
      -f 192.168.100.22+*:445:TCP -f 192.168.100.22+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
      -f *+192.168.100.22:445:TCP -f *+192.168.100.22:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
      -f 192.168.100.22+*:135:TCP -f 192.168.100.22+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
      -f *+192.168.100.22:135:TCP -f *+192.168.100.22:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"
      -f 192.168.100.22+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
      -f 192.168.100.22+*:137:TCP -f 192.168.100.22+*:137:UDP -f
      192.168.100.22+*:139:TCP -f 192.168.100.22+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
      -f *+192.168.100.22:137:TCP -f *+192.168.100.22:137:UDP
      -f *+192.168.100.22:139:TCP -f *+192.168.100.22:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
      -f 192.168.100.22+*:123:TCP -f 192.168.100.22+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Überwachender"
      -f 192.168.100.22+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
      -f 192.168.100.22+*:389:TCP -f 192.168.100.22+*:389:UDP
      -f 192.168.100.22+*:636:TCP -f 192.168.100.22+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
       -f 192.168.100.22+*:88:TCP -f 192.168.100.22+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
       -f *+192.168.100.22:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
       -f 192.168.100.22+*:3268:TCP -f 192.168.100.22+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP"
       -f 192.168.100.22+*:*:ICMP -f *+192.168.100.22:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Resolution Server"
       -f *+192.168.100.22:1512:TCP -f *+192.168.100.22:1512:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Client"
       -f 192.168.100.22+*:42:TCP -f 192.168.100.22+*:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Server"
       -f *+192.168.100.22:42:TCP -f *+192.168.100.22:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
       -f *+192.168.100.22 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x



Mögliche Auswirkungen

Da diese Einstellungen keinen Verkehr über zufällige hohe Ports zulassen, ist RPC-Verkehr nicht
erlaubt. Das kann die Verwaltung des Servers erschweren. Durch die Nutzung des Common
Internet File System (CIFS) und der grundlegenden NetBIOS Ports werden allerdings trotzdem
eine Menge Möglichkeiten bereitgestellt. Das CIFS-Protokoll definiert einen Standard für den
Dateizugriff über das Netzwerk. Mit CIFS haben Benutzer unterschiedlicher Plattformen und
Computer die Möglichkeit, Dateien ohne die Installation neuer Software zur Verfügung zu
stellen.
Administratoren sollen in der Lage sein, sich zur Remoteadministration mit Hilfe eines
Terminaldienst-Clients zu verbinden. Während Sie mit dem WINS-Server verbunden sind,
sollten Sie in der Lage sein, Netzlaufwerke zu verbinden. Die oben angegebenen Richtlinien
können natürlich gestrafft werden, um diese Funktionen zu verhindern. Dann könnte die
Administration des Servers allerdings umständlich werden.
Die Implementierung dieser relativ kleinen Anzahl von IPSec-Richtlinien sollte keine spürbare
Auswirkung auf die Leistung des Servers haben. Trotzdem sollen vor der Implementierung dieser
Filter in Ihrer Umgebung umfangreiche Tests durchgeführt werden, um die nötige Funktionalität
und Leistung sicher zu stellen. Zusätzliche Regeln könnten notwendig sein, um andere
Anwendungen aus Ihrer Umgebung zu unterstützten.
Contoso Szenario
Im Contoso Szenario wurden die IPSec-Filter, die oben dargestellt sind, auf den WINS-Servern
implementiert.
Zusätzliche Sicherheitseinstellungen - DHCP
Protokollierung konfigurieren

Sicherheitslücken

DHCP-Clients sind in Protokollen oft schwer auszuspüren, da als einzige Information der
Computername und nicht die IP-Adresse gespeichert wird. Mit den DCHP-
Überwachungsprotokollen haben Sie ein weiteres Werkzeug zur Verfügung, um die Quelle von
internen Angriffen oder versehendlichen Aktivitäten aufzuspüren.
Die Informationen aus diesen Protokollen sind allerdings nicht unbedingt absolut aussagekräftig,
da sowohl Computernamen als auch MAC-Adressen (media access control) gefälscht oder
verändert werden können. Auf jeden Fall überwiegen die Vorteile gegenüber den Nachteilen.
Wenn Sie diese Informationen sammeln, ist die IP-Adresse nicht die einzige Information die sie
haben. Sie können zusätzlich nachverfolgen, wie diese IP-Adresse in der letzten Zeit genutzt
wurde.
Da das Überwachungsprotokoll für den DHCP in der Voreinstellung nicht aktiviert ist, werden
diese Informationen nicht gesammelt.

Maßnahmen

Setzen Sie die Einstellung DHCP-Protokollierung auf Aktiviert.

Mögliche Auswirkungen

Diese Informationen könnten von allen, die Zugriff auf diese Protokolldateien haben, verändert
oder missbraucht werden. Die Berechtigungen auf diese Dateien sollten also eingeschränkt
werden.
Die DHCP-Überwachungsprotokolle können theoretisch die Partition, in der sie konfiguriert sind
komplett voll schreiben. Die vorgegebenen Einstellungen für die DHCP-Protokollierung zur
Überprüfung des Plattenplatzes reichen jedoch aus um dies zu verhindern. Überprüfen Sie diese
Einstellungen, um sicherzustellen, dass für andere Anwendungen noch ausreichend Plattenplatz
zur Verfügung steht. Weitere Informationen über die Einstellungen DhcpLogMinSpaceOnDisk
finden sie im Windows 2000 Server Resource Kit unter:
HTTP://www.microsoft.com/windows2000/techinfo/reskit/en-us/regentry/46692.asp.

Contoso Szenario

Im Contoso Szenario wurden diese Informationen als harmlos und potentiell nützlich für die
weiterführende Überwachung er Benutzeraktivitäten betrachtet.
►Um das Überwachungsprotokoll für den DHCP zu aktivieren
   1. Öffnen Sie das Snap-In für die DHCP-Verwaltung.
   2. Klicken Sie mit der rechten Maustaste auf den Server, klicken Sie auf Eigenschaften und
      wählen Sie dann die Registerkarte Allgemein aus.
   3. Aktivieren Sie das Kontrollkästen.
   4. Starten Sie den DHCP-Server neu.

Schutz gegen Denial of Service (DoS) Angriffe auf einem DHCP

Sicherheitslücken

Da DHCP-Server eine zentrale Ressource darstellen, könnten DoS-Angriffe auf DHCP-Server
weitreichende Konsequenzen haben. Wenn ein DHCP-Server angegriffen wird und nicht mehr in
der Lage ist auf DHCP-Anforderungen zu antworten, sind Clients keine DHCP-Leases mehr
erhalten. Diese Clients werden ihre existierende IP-Lease und die Fähigkeit auf
Netzwerkressourcen zuzugreifen verlieren.
Es dürfte nicht sehr schwer sein, ein Script für einen solchen Angriff zu erstellen, das alle auf
einem DHCP-Server verfügbaren IP-Adressen anfordert. Der Pool von verfügbaren IP-Adressen
für nachfolgende legitime Anfragen von DHCP-Clients würde komplett aufgebraucht werden.
Außerdem haben böswillige Benutzer die Möglichkeit, die IP-Adresse des Netzwerkadapters des
Rechners den sie administrieren so zu konfigurieren, dass der DHCP-Server IP-Adresskonflikte
für alle Adressen in seinem Bereich erkennt. Er wird dann alle DHCP-Leaseanforderungen
verweigern.
Zusätzlich kann, genau wie bei allen anderen Netzwerkdiensten, ein DoS-Angriff (z. B. eine
CPU-Auslastung oder des Auffüllen des Anfragepuffers des DHCP-Listeners) dazu führen, dass
der DHCP-Server nicht mehr auf legitimen Verkehr antworten kann. Dies kann dazu führen, dass
Clients nicht in der Lage sind, Leaseanfragen oder Lease-Erneuerungen durchzuführen.
Vorschläge zur Verminderung des Risikos von netzwerkbasierten DoS-Angriffen entnehmen Sie
bitten dem Abschnitt „Sicherheitserwägungen im Zusammenhang mit Netzwerkangriffen“ im
Kapitel 6, "Sichern der Standardserver".
Außer, wenn ein Clients gestartet wird und keine gültige Lease besitzt, ist das Verhalten der
DHCP-Clients glücklicherweise so, dass periodische Ausfülle oft toleriert werden können. Wenn
der DHCP-Server auf eine Lease-Erneuerung nicht antwortet, versucht der Client es später noch
einmal. Er versucht dies so lange, bis er eine Lease-Erneuerung oder eine neue Lease erhalten
hat.
Grundsätzlich sind DoS-Angriffe gegen DHCP-Server nur für interne Angreifer möglich. Bei
diesen ist es allerdings eher unwahrscheinlich, dass sie einen Infrastrukturserver statt eines
Systems mit sensitiven Daten angreifen werden.

Maßnahmen

Konfigurieren Sie DHCP-Server als Paare, und teilen Sie die verfügbaren IP-Adressen unter der
Berücksichtigung der 80/20-Regel zwischen den Server auf. Weitere Informationen zur 80/20-
Regel und zum DHCP-Protokoll erhalten Sie unter:
HTTP://www.microsoft.com/windows2000/techinfo/reskit/en-us/cnet/cncb_dhc_ogjw.asp.
Alternativ können Sie die Leasedauer für DHCP-Bereiche erhöhen, so dass mehr Clients in der
Lage sind, einen Ausfall über einen längeren Zeitraum zu tolerieren. Dies bietet jedoch keinen
Schutz davor, dass ein Client während eines Serverausfalles unmittelbar ein DHCP-Lease
benötigt. Die kann z. B. geschehen, wenn ein neuer Computer im LAN das erste Mal gestartet
wird.
Sie können die Leistung und Verfügbarkeit des Windows 2000 Servers und des DHCP-Dienstes
außerdem überwachen.
Sie können DHCP-Clustering konfigurieren. Dies wird Ihnen helfen DoS-Angriffe, die gegen
einen der individuellen Hosts selbst und nicht gegen den Cluster gerichtet sind, abzuschwächen.
Letztlich können Sie auch mehrere separate DHCP-Server, die jeweils alle IP-Adressen eines
separaten Subnetzes Ihrer Umgebung verwalten, implementieren. Hierdurch wird jeder DHCP-
Server zwar vollständig von allen Problemen isoliert, die ein Server in einem anderen Subnetz
haben könnte, es wird jedoch keine Ausfallsicherheit erreicht. Diese ist jedoch in den meisten
Unternehmensumgebungen notwendig.

Mögliche Auswirkungen

Die potentielle Auswirkung ist ein erweiterter Aufwand für die Verwaltung von zusätzlichen
Servern. Wenn Sie außerdem bei der Konfiguration der 80/20-Verteilung von IP-Adressen über
mehrere Server nicht sorgfältig vorgehen, könnte es passieren, dass falsch konfigurierte Server
die gleiche IP-Adresse an mehr als einen Client vergeben. Die erhöhte Leasedauer könnte zu
Situationen führen, in denen der gesamte DHCP-Adressraum vollständig ausgenutzt ist, was
schlicht und ergreifen eine andere Art von DoS-Angriff darstellt.

Contoso Szenario

Im Contoso Szenario hat jeder Standort zwei DHCP-Servers, die so konfiguriert sind, dass die IP-
Adressen nach der 80/20-Regel verteilt sind. Die vorgegebene Leasedauer von acht Tagen wurde
als ausreichend betrachtet, um auch längere Ausfallzeigen des DHCP-Dienstes zu überstehen.
► Um die Leasedauer zu ändern
   1. Öffnen Sie das Snap-In für die DHCP-Verwaltung
   2. Klicken Sie mit der rechten Maustaste auf den Bereich, den Sie bearbeiten möchten,
      klicken Sie auf Eigenschaften und wählen Sie dann die Registerkarte Allgemein aus
   3. Tragen Sie im Feld Gültigkeitsdauer der Lease für DHCP-Clients den Zeitraum ein,
      den Sie implementieren möchten
      Sie können hier auch eine unbeschränkte Leasedauer konfigurieren. Diese Einstellung ist
      allerdings nur unter ganz bestimmten Umständen und nicht generell für die DHCP-
      Verteilung in einem Unternehmen, sinnvoll.

Ports über IPSec-Filter blockieren

Sicherheitslücken

Wie schon erwähnt, wird die Reduzierung der offenen Ports, auf denen Verbindungsversuche
entgegengenommen werden, auf den Server in Ihrer Organisation, die Angriffsfläche jeder
einzelnen Maschine in großem Umfang reduzieren. Offene Ports können einem Angreifer als
Startpunkt für Angriffe auf andere Server Ihrer Organisation dienen – ein Wurm und trojanisches
Pferd kann z. B. eine Anwendung installieren, die auf einem unautorisierten Port auf eines
Servers auf eingehende Befehle wartet.

Maßnahmen

Konfigurieren Sie IPSec Blockierungsfilter, die nur den Netzwerkverkehr erlauben, der unten
spezifiziert ist. Dies wird die Zahl von unerwarteten und nicht autorisierten Anwendungen die
Anfragen entgegen nehmen oder angegriffen werden könnten, reduzieren.


DHCP Server IPSec Netzwerkverkehrsplan

Tabelle 7.8: DHCP Server IPSec Network Traffic Map
Dienst           Protokoll   Quellport    Zielport   Quelladresse Zieladresse Aktion

DNS Client       TCP         ALLE         53          Host IP       ALLE         ZULASSEN

                 UDP         ALLE         53          Host IP       ALLE         ZULASSEN

SNMP Server      TCP         ALLE         161         ALLE          Host IP      ZULASSEN

                 UDP         ALLE         161         ALLE          Host IP      ZULASSEN

CIFS Client      TCP         ALLE         445         Host IP       ALLE         ZULASSEN

                 UDP         ALLE         445         Host IP       ALLE         ZULASSEN

CIFS Server      TCP         ALLE         445         ALLE          Host IP      ZULASSEN

                 UDP         ALLE         445         ALLE          Host IP      ZULASSEN

RPC Client       TCP         ALLE         135         Host IP       ALLE         ZULASSEN

                 UDP         ALLE         135         Host IP       ALLE         ZULASSEN

RPC Server       TCP         ALLE         135         ALLE          Host IP      ZULASSEN

                 UDP         ALLE         135         ALLE          Host IP      ZULASSEN

Zus. RPC Ports TCP           ALLE         57952       Host IP       ALLE         ZULASSEN
ausgehend

NetBIOS          TCP         ALLE         137         Host IP       ALLE         ZULASSEN
Client

                 UDP         ALLE         137         Host IP       ALLE         ZULASSEN
              TCP    ALLE   139    Host IP   ALLE      ZULASSEN

              UDP    ALLE   138    Host IP   ALLE      ZULASSEN

NetBIOS       TCP    ALLE   137    ALLE      Host IP   ZULASSEN
Server

              UDP    ALLE   137    ALLE      Host IP   ZULASSEN

              TCP    ALLE   139    ALLE      Host IP   ZULASSEN

              UDP    ALLE   138    ALLE      Host IP   ZULASSEN

NTP Client    TCP    ALLE   123    Host IP   ALLE      ZULASSEN

              UDP    ALLE   123    Host IP   ALLE      ZULASSEN

Überwachender ANY    ALLE   ALLE   Host IP   MOM       ZULASSEN
Client                                       Server

LDAP Client   TCP    ALLE   389    Host IP   ALLE      ZULASSEN

              UDP    ALLE   389    Host IP   ALLE      ZULASSEN

              TCP    ALLE   636    Host IP   ALLE      ZULASSEN

              UDP    ALLE   636    Host IP   ALLE      ZULASSEN

Kerberos      TCP    ALLE   88     Host IP   ALLE      ZULASSEN
Client

              UDP    ALLE   88     Host IP   ALLE      ZULASSEN

Terminal      TCP    ALLE   3389   ALLE      Host IP   ZULASSEN
Services

Global Catalog TCP   ALLE   3268   Host IP   ALLE      ZULASSEN
Client

              TCP    ALLE   3269   Host IP   ALLE      ZULASSEN

DHCP Server   UDP    68     67     ALLE      Host IP   ZULASSEN

ICMP          ICMP   ALLE   ALLE   Host IP   ALLE      ZULASSEN

der gesamte   ALLE   ALLE   ALLE   ALLE      Host IP   BLOCKIEREN
eingehende
Verkehr
Anmerkung: Die Host IP unter Zieladresse in Tabelle 7.5 sollte auf die IP Ihres Servers gesetzt
sein.

Alle Regeln, die oben aufgeführt sind, sollten bei Ihrer Implementierung gespiegelt werden. Dies
stellt sicher, dass es dem gesamten, auf einem DHCP-Server eingehenden Verkehr auch gestattet
ist, zu ursprünglichen Server zurückzukommen.
Wie Sie oben gesehen haben, gibt es eine Anzahl Ports und Dienste, die auf dem DHCP-Server
geöffnet wurden. Die Konfiguration einer noch strengeren Sicherheit auf dem DHCP-Server
würde es ihnen gestatten weitere Ports zu blockieren. Tatsächlich wurden diese Ports geöffnet
um, den Administratoren der Maschinen zusätzliche Funktionalitäten zur Verfügung zu stellen.
Über eben diese zusätzlichen Funktionalitäten wird die gesamte DHCP-Verwaltung und die
Verwaltung des Server über die Nutzung von Terminaldiensten durchgeführt.
Bitte beachten Sie, dass Contoso einen MOM-Server in der eigenen Umgebung implementiert
hat. Aufgrund der umfangreichen Interaktion zwischen MOM-Server und dem OnePoint-Client –
die Clientanwendung, die Informationen an die MOM-Konsole sendet – ist jeglicher
Netzwerkverkehr zwischen dem Server und dem MOM-Server gestattet.

Scriptbefehle

Die Implementierung der folgenden Befehle sollte auf dem DHCP-Server ausgeführt werden.
Diese Befehle blockieren den Netzwerkverkehr so wie oben spezifiziert. Dieser Satz von
Befehlen steht Ihnen auch als Batchdatei die dieser Anleitung beiliegt, zur Verfügung.

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
-f 192.168.100.21+*:53:TCP -f 192.168.100.21+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
-f *+192.168.100.21:161:TCP -f *+192.168.100.21:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Client"
-f 192.168.100.21+*:445:TCP -f 192.168.100.21+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS/SMB Server"
-f *+192.168.100.21:445:TCP -f *+192.168.100.21:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
-f 192.168.100.21+*:135:TCP -f 192.168.100.21+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
-f *+192.168.100.21:135:TCP -f *+192.168.100.21:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"
-f 192.168.100.21+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
-f 192.168.100.21+*:137:TCP -f 192.168.100.21+*:137:UDP
-f 192.168.100.21+*:139:TCP -f 192.168.100.21+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
-f *+192.168.100.21:137:TCP -f *+192.168.100.21:137:UDP
-f *+192.168.100.21:139:TCP -f *+192.168.100.21:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
-f 192.168.100.21+*:123:TCP -f 192.168.100.21+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Überwachender"
-f 192.168.100.31+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
-f 192.168.100.21+*:389:TCP -f 192.168.100.21+*:389:UDP
-f 192.168.100.21+*:636:TCP -f 192.168.100.21+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
-f 192.168.100.21+*:88:TCP -f 192.168.100.21+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
-f *+192.168.100.21:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
-f 192.168.100.21+*:3268:TCP -f 192.168.100.21+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP IN OUT"
-f 192.168.100.21+*:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DHCP Server"
-f *:68:UDP+192.168.100.21:67:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
-f *+192.168.100.21 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

Mögliche Auswirkungen

Da diese Einstellungen keinen Verkehr über zufällige hohe Ports zulassen, ist RPC-Verkehr nicht
erlaubt. Das kann die Verwaltung des Servers erschweren. Durch die Nutzung des Common
Internet File System (CIFS) und der grundlegenden NetBIOS Ports werden allerdings trotzdem
eine Menge Möglichkeiten bereitgestellt. Das CIFS-Protokoll definiert einen Standard für den
Dateizugriff über das Netzwerk. Mit CIFS haben Benutzer unterschiedlicher Plattformen und
Computer die Möglichkeit, Dateien ohne die Installation neuer Software zur Verfügung zu
stellen.
Administratoren sollen in der Lage sein, sich zur Remoteadministration mit Hilfe eines
Terminaldienst-Clients zu verbinden. Während Sie mit dem DHCP-Server verbunden sind,
sollten Sie in der Lage sein, Netzlaufwerke zu verbinden. Die oben angegebenen Richtlinien
können natürlich gestrafft werden, um diese Funktionen zu verhindern. Dann könnte die
Administration des Servers allerdings umständlich werden.
Die Implementierung dieser relativ kleinen Anzahl von IPSec-Richtlinien sollte keine spürbare
Auswirkung auf die Leistung des Servers haben. Trotzdem sollen vor der Implementierung dieser
Filter in Ihrer Umgebung umfangreiche Tests durchgeführt werden, um die nötige Funktionalität
und Leistung sicher zu stellen. Zusätzliche Regeln könnten notwendig sein, um andere
Anwendungen aus Ihrer Umgebung zu unterstützten.
Contoso Szenario

Im Contoso Szenario wurden die IPSec-Filter, die oben dargestellt sind auf den DHCP-Servern
implementiert.

Datei- und Druckserverrolle
Die Datei- und Druckserver können schwer abzusichern sein, da die meisten essentiellen Dienste
auf diesen Server die Windows NetBIOS-Protokolle benötigen. Diese Protokolle die z. B. von
SMB und CFIS genutzt werden, können einem nicht autorisierten Benutzer eine Menge an
Informationen bringen. Oftmals wird für hochsichere Windows Umgebungen die Deaktivierung
dieser Protokolle vorgeschlagen.

Datei und Drucker Zusatzrichtlinie
Die Datei und Drucker Zusatzrichtlinie konfiguriert die folgenden zwei Einstellungen:
      Sie aktiviert den Dienst „Druckwarteschlange“, welcher zum Drucken genutzt wird.
      Sie deaktiviert die Sicherheitsoption Microsoft-Netzwerk (Server): Kommunikation
       digital signieren (immer). Wenn diese Einstellungen nicht deaktiviert sind, sind Clients
       zwar in der Lage zu drucken, nicht jedoch die Druckerwarteschlange anzuzeigen. Es wird
       die Fehlermeldung „Keine Verbindung möglich. Zugriff verweigert“ zurückgegeben,
       wenn sie versuchen die Druckerwarteschlange anzuzeigen.

Anmerkung: Wenn die Clients das Anzeigen der Druckerwarteschlange unterstützten sollen,
sollte auf den Clientcomputer die Einstellung Microsoft-Netzwerk (Client): Kommunikation
digital signieren (immer) deaktiviert werden


Systemdienste

Jeder Dienst und jede Anwendung stellt einen potentiellen Angriffspunkt dar. Daher sollen alle
nicht benötigten Dienste und ausführbaren Dateien deaktiviert oder entfernt werden. In der
MSBR sind diese optionalen Dienste, genau wie alle anderen unnötigen Dienste, deaktiviert. Die
Rolle des Datei- und Druckservers hängt allerdings von einem dieser deaktivierten Dienste ab:
dem Dienst „Druckerwarteschlange“. Darum wurde in der Datei und Druck Zusatzrichtlinie für
diesen Dienst der Starttyp auf automatisch gesetzt.

Anmerkung: Der Dienst „Druckerwarteschlange“ wird auch auf jedem Clientsystem genutzt,
dass Druckaufträge auf Druckservern initiiert oder sendet. Da die MSBR den Dienst
„Druckerwarteschlange“ deaktiviert, werden sie, mit Ausnahme der Datei- und Druckserver, von
keinem Server aus einen Druckauftrag geben können. Wenn Sie von anderen Servern aus
drucken möchten, müssen Sie in der entsprechenden Gruppenrichtlinie den Dienst
„Druckerwarteschlange“ aktivierten.
Es gibt weitere Dienste, die auf Windows 2000 Datei- und Druckservern häufig deaktiviert
werden. Diese Dienste sind nicht essentiell und daher wurden sie im Contoso Szenario
deaktiviert. Sie sind allerdings ein ständiges Diskussionsthema und daher mag es sein, dass die
Empfehlungen aus dieser Anleitung in Ihrer Umgebung nicht anwendbar sind. Passen Sie die
Empfehlungen der Datei und Drucker Zusatzrichtlinie den Bedürfnissen Ihrer Organisation an.

Verteiltes Dateisystem (DFS)

Das verteilte Dateisystem (DFS) ist ein Dienst, der unterschiedliche Dateifreigaben in einen
einzelnen logischen Namensraum integriert. DFS verwaltet logische Partitionen, die über das
LAN oder WAN verteilt sind und wird für die SYSVOL-Freigabe von Active Directory benötigt.
Der Namensraum ist eine logische Darstellung, der für Benutzer verfügbaren Speicherressourcen
im Netzwerk. Wenn der DFS-Dienst deaktiviert ist, können Benutzer nicht über diesen logischen
Namensraum auf die Netzwerkdaten zugreifen. Um dann auf Daten zugreifen zu können, müssen
Benutzer jeweils erst die Namen der Server und Freigaben kennen. Aus diesem Grund ist der
DFS-Dienst in der Datei und Drucker Zusatzrichtlinie deaktiviert. Wenn Ihre Organisation DFS
auf Dateiservern nutzt, um den Zugriff auf verteilte Ressourcen zu vereinfachen, müssen Sie die
File-and-Print-Server-Gruppenrichtlinie ändern. Alternativ können Sie auch ein neues GPO
erstellen, in dem Sie diesen Dienst aktivieren. Dieses GPO wenden Sie dann auf alle Dateiserver,
die DFS benötigen, an.

Dateireplikationsdienst

Der NT Dateireplikationsdienst (NTFRS) sorgt für die Synchronisation von Dateiverzeichnissen
über mehrere Server hinweg. NTFRS ist der automatische Dateireplikationsdienst in Windows
2000. Der Dienst pflegt auf mehreren Servern gleichzeitig die Kopien von Dateien und repliziert
außerdem das Windows 2000 Systemverzeichnis SYSVOL auf alle Domänencontroller. NTFRS
kann, in Verbindung mit dem ausfallsicheren DFS, so konfiguriert werden, dass es Dateien über
verschiedene Ziele hinweg repliziert. Wenn dieser Dienst deaktiviert ist, wird keine
Dateireplikation stattfinden. Außerdem werden die Serverdaten nicht synchronisiert.
NTFRS wird im Contoso Szenario auf Datei- und Druckservern nicht unterstützt. Daher ist der
NTFRS-Dienst in der Datei und deaktiviert. Wenn Ihre Organisation NTFRS auf Dateiservern
nutzt, um Daten über mehrere Server hinweg zu replizieren, dann ändern Sie die
Gruppenrichtlinie. Alternativ können Sie auch ein neues GPO erstellen, in dem Sie diesen Dienst
aktivieren. Dieses GPO wenden Sie dann auf alle Dateiserver, die DFS benötigen, an.

Zusätzliche Sicherheitseinstellungen
Die vorgegebenen Berechtigungen für Dateifreigaben zurücksetzen

Sicherheitslücken

Als Voreinstellungen sind die Mitglieder der Gruppen lokale Administratoren, Hauptbenutzer
und Serveroperatoren in der Lage, neue Datei- und Druckerfreigaben zu erstellen. Neue
Dateifreigaben haben die vorgegebene Berechtigung Vollzugriff für die symbolische Gruppe
Jeder. Hier handelt es sich um eine potentielle Sicherheitslücke. Vergessliche Mitarbeiter des IT-
Teams könnten unbeabsichtigt eine neue Dateifreigabe erstellen, bei der jedem der Zugriff auf
diese Freigabe gestattet ist. So erhält jeder vollen Zugriff auf alle Objekte in der Freigabe.

Anmerkung: Die systemeigene Gruppe Hauptbenutzer gibt es auf Domänencontrollern nicht. Es
gibt jedoch Gruppe Serveroperatoren. Sie besitzt gleichwertige Privilegien.


Maßnahmen

Schulen Sie alle Administratoren, die in der Lage sind neue Dateifreigaben anzulegen, in der
manuellen Konfiguration der Freigabeberechtigungen. Vergeben Sie Berechtigungen nur an
Benutzer, die einen Zugriff auf die Freigabe benötigen. Stellen Sie dann sicher, dass diese
Berechtigungen so restriktiv wie möglich sind.

Mögliche Auswirkungen

Benutzer, die Freigaben erstellen und verwalten, müssen die Berechtigungen dieser Freigaben
manuell konfigurieren.

Contoso Szenario

Alle Dateifreigaben auf Datei- und Druckservern wurden so konfiguriert, dass authentifizierte
Benutzer die Berechtigung Ändern haben. Die freigegebenen Dateien und Ordner wurden
hierdurch ebenso gut wie durch NTFS-Berechtigungen geschützt.
► Um die Freigabeberechtigungen für neue Freigaben manuell zu ändern
   1. Öffnen Sie das MMC Snap-In Computerverwaltung, öffnen Sie Freigegebene Ordner,
      Freigaben
   2. Klicken Sie mit der rechten Maustaste auf Freigaben, wählen Sie neue Dateifreigabe und
      klicken Sie auf den Schalter Durchsuchen um einen Ordner für die Freigabe auszuwählen
      (z. B. e:\Benutzer). Geben Sie einen Namen in das Feld Freigabename ein.
   3. Auf der Seite Freigabe erstellen wählen Sie Freigabe- und Ordnerberechtigungen
      anpassen und klicken auf den Schalter anpassen.
   4. Klicken Sie auf den Schalter Entfernen um den Eintrag jeder zu entfernen. Klicken Sie
      auf Hinzufügen, geben Sie authentifizierte Benutzer ein und klicken Sie auf den Schalter
      OK.
   5. Aktivieren Sie das Kontrollkästchen Ändern in der Spalte Zulassen und klicken Sie auf
      OK. Klicken Sie auf Beenden und wählen Sie Nein wenn Sie dazu aufgefordert werden.

Die Berechtigungen der existierenden Dateifreigaben überprüfen

Sicherheitslücken

Wie bereits oben beschrieben, ist der Vergabewert für jede neue Freigabe Vollzugriff für die
symbolische Gruppe Jeder. Das bedeutet, dass es bereits existierende Freigaben geben könnte,
auf die diese Gruppe Jeder Vollzugriff hat.
Maßnahmen

Überprüfen Sie alle Freigaben in Ihrer Organisation, um zu prüfen, dass alle die jeweils
entsprechenden Berechtigungen haben. Die können sie manuell erledigen, indem sie jeden
Dateiserver einzeln überprüfen, oder sie nutzen Befehle wie net view. Eine weitere Möglichkeit,
die Berechtigungen aller Freigaben zu dokumentieren, sind Werkzeuge von Drittanbietern.

Mögliche Auswirkungen

Das Durchsetzen der korrekten Freigabeberechtigungen kann dazu führen, dass einige legitime
Benutzer ihren Zugriff auf diese Ressourcen verlieren werden. Diese Situationen müssen bei
ihrem Auftreten bereinigt werden.
Dieses Problem könnte ganz besonders Benutzer betreffen, deren Zugriff über Berechtigungen
über die Security-IDs (SIDs) in der SIDHistory zustande kommen. Eine SID ist ein Wert, der
jeden Benutzer, jede Gruppe, jedes Computerkonto und jede Sitzung in einem Netzwerk
eindeutig identifiziert.
Wenn Benutzerkonten aus einer älteren NT 4.0 Domäne, oder eine Windows 2000 Domäne die
nicht Teil der aktuellen Gesamtstruktur ist, migriert werden, wird diese Migration oft mit Hilfe
von Werkzeugen durchgeführt, die versuchen, die Benutzerberechtigungen über das SIDHistory-
Attribut des neuen Benutzerkontos, beizubehalten. Das SIDHistory-Attribut speichert die SIDs
des migrierten Kontos, um weiterhin den Zugriff auf existierende abgesicherte Ressourcen zu
gewähren.
Die gebräuchlichste Verwendung der SIDHistory ist den Zugriff auf Datei- Druckfreigaben
sicherzustellen, ohne alle ACLs zu aktualisieren.
Die Berechtigungen für die existierenden Datei- und Druckfreigaben könnten noch nicht auf die
aktuellen Benutzer und Gruppen aktualisiert worden sein. Daher könnte es sein, dass die
Benutzer, ohne ihr Wissen, von den Berechtigungen, die sie durch ihre SIDHistory erhalten,
abhängig sind.
Für Administratoren die nichts über die migrierten Konten und die SIDHistory wissen, kann die
ACL von existierenden Datei- oder Druckfreigaben so aussehen, als enthielte sie unnötige
Einträge oder Einträge, die nicht in existierende Gruppen oder Benutzerkonten der Domäne
aufgelöst werden können. Trotzdem werden die Benutzer, die von der SIDHistory abhängig sind
um Zugriff auf diese Ressourcen zu erhalten, ihren Zugriff verlieren wenn diese Einträge
gelöscht werden. Im schlimmsten Fall könnten diese Benutzer den gesamten Zugriff auf diese
Datei- und Druckfreigaben verlieren.
Wenn in Ihrer Umgebung vor einer Migration von Benutzerkonten aus alten Windows-Domänen
Datei- und Druckserver vorhanden waren, sollten Sie die Berechtigungen für die Datei- und
Druckfreigaben sorgfältig dokumentieren, bevor Sie irgendeine Änderung in den ACLs
vornehmen.
Sein Sie darauf vorbereitet, neue ACLs erstellen zu müssen, die denselben Zugriff wieder
gewähren oder die Datei- und Druckserver von einem Backup-Medium wiederherzustellen, um
die gelöschten ACL-Einträge wiederherzustellen.
Contoso Szenario

Da in der Contoso Umgebung keine bereits existierenden Dateiserver vorhanden waren, gab es
keine Notwendigkeit, die existierenden Freigabeberechtigungen zu aktualisieren. Alle neuen
Freigabeberechtigungen wurden manuell so konfiguriert, dass die Benutzer die minimal
notwendigen Berechtigungen erhielten.

Ports über IPSec-Filter blockieren

Sicherheitslücken

Wie schon erwähnt, wird die Reduzierung der offenen Ports, auf denen Verbindungsversuche
entgegengenommen werden, auf den Server in Ihrer Organisation, die Angriffsfläche jeder
einzelnen Maschine in großem Umfang reduzieren. Offene Ports können einem Angreifer als
Startpunkt für Angriffe auf andere Server Ihrer Organisation dienen – ein Wurm und trojanisches
Pferd kann z. B. eine Anwendung installieren, die auf einem unautorisierten Port eines Servers
auf eingehende Befehle wartet.

Maßnahmen

Konfigurieren Sie IPSec Blockierungsfilter, die nur den Netzwerkverkehr erlauben, der unten
spezifiziert ist. Dies wird die Zahl von unerwarteten und nicht autorisierten Anwendungen, die
Anfragen entgegen nehmen oder angegriffen werden könnten, reduzieren.
Da sie RPC benötigen, unterscheiden sich Datei- und Druckserver sehr stark von den anderen
Serverrollen.

Datei- und Druckserver IPSec Netzwerkverkehrsplan

Tabelle 7.9: Datei- und   Druckserver IPSec Netzwerkverkehrsplan

Dienst      Protokoll Quellport      Zielport   Quelladresse Zieladresse Aktion

DNS         TCP           ALLE       53         Host IP       ALLE         ZULASSEN
Client

            UDP           ALLE       53         Host IP       ALLE         ZULASSEN

SNMP        TCP           ALLE       161        ALLE          Host IP      ZULASSEN
Server

            UDP           ALLE       161        ALLE          Host IP      ZULASSEN

CIFS        TCP           ALLE       445        Host IP       ALLE         ZULASSEN
Client

            UDP           ALLE       445        Host IP       ALLE         ZULASSEN
CIFS      TCP   ALLE   445     ALLE      Host IP   ZULASSEN
Server

          UDP   ALLE   445     ALLE      Host IP   ZULASSEN

RPC       TCP   ALLE   135     Host IP   ALLE      ZULASSEN
Client

          UDP   ALLE   135     Host IP   ALLE      ZULASSEN

RPC       TCP   ALLE   135     ALLE      Host IP   ZULASSEN
Server

          UDP   ALLE   135     ALLE      Host IP   ZULASSEN

Zus. RPC TCP    ALLE   57952   Host IP   ALLE      ZULASSEN
Ports
ausgehen
d

NetBIOS   TCP   ALLE   137     Host IP   ALLE      ZULASSEN
Client

          UDP   ALLE   137     Host IP   ALLE      ZULASSEN

          TCP   ALLE   139     Host IP   ALLE      ZULASSEN

          UDP   ALLE   138     Host IP   ALLE      ZULASSEN

NetBIOS   TCP   ALLE   137     ALLE      Host IP   ZULASSEN
Server

          UDP   ALLE   137     ALLE      Host IP   ZULASSEN

          TCP   ALLE   139     ALLE      Host IP   ZULASSEN

          UDP   ALLE   138     ALLE      Host IP   ZULASSEN

NTP       TCP   ALLE   123     Host IP   ALLE      ZULASSEN
Client

          UDP   ALLE   123     Host IP   ALLE      ZULASSEN

Überwach ALLE   ALLE   ALLE    Host IP   MOM       ZULASSEN
ender                                    Server
Client

LDAP      TCP   ALLE   389     Host IP   ALLE      ZULASSEN
Client

           UDP         ALLE         389        Host IP        ALLE         ZULASSEN

           TCP         ALLE         636        Host IP        ALLE         ZULASSEN

           UDP         ALLE         636        Host IP        ALLE         ZULASSEN

Kerberos   TCP         ALLE         88         Host IP        ALLE         ZULASSEN
Client

           UDP         ALLE         88         Host IP        ALLE         ZULASSEN

Terminal   TCP         ALLE         3389       ALLE           Host IP      ZULASSEN
Services

Global     TCP         ALLE         3268       Host IP        ALLE         ZULASSEN
Catalog
Client

           TCP         ALLE         3269       Host IP        ALLE         ZULASSEN

RPC Ports TCP          ALLE         RPC        ALLE           Host IP      ZULASSEN
                                    Bereich

ICMP       ICMP        ALLE         ALLE       Host IP        ALLE         ZULASSEN

der       ALLE         ALLE         ALLE       ALLE           Host IP      BLOCKIER
gesamte                                                                    EN
eingehend
e Verkehr



Anmerkung: Die Host IP unter Zieladresse in Tabelle 7.5 sollte auf die IP Ihres Servers gesetzt
sein.

Da die Datei- und Druckserver zahlreiche RPC-Verbindungen benötigen, um den Clients Zugriff
auf Datei- und Druck-Ressourcen zur Verfügung zu stellen, sollte ein Portbereich speziell für die
Nutzung über RPC vorgesehen sein. Wenn RPC in Ihrer Umgebung auf eine bestimmte Zahl an
Ports beschränkt werden soll, sollten Sie hierfür Ports über 50.000 auswählen. Sie können diese
Einstellung über die folgenden Registrierungsschlüssel erreichen:
Der Schlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet sollte, wenn er
nicht schon existiert, erstellt werden
Der Schlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\Ports sollte als
REG_MULTI_SZ erstellt werden. Der Wert gibt die Anzahl Ports an, die sie öffnen möchten.
Der Schlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\
PortsInternetAvailable sollte als REG_SZ mit dem Wert Y erstellt werden.
Der Schlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\UseInternetPorts
sollte als REG_SZ mit dem Wert Y erstellt werden.
Nachdem Sie die oben genannten Änderungen an der Registrierung vorgenommen haben, sollten
Sie den Server neu starten. Die Änderungen können die Leistung beeinträchtigen. Daher sollten
sie vor der Implementierung in die Produktivumgebung getestet werden. Die exakte Anzahl
Ports, die geöffnet werden, hängt von der Nutzung und er Funktionalität des Servers ab.
Alle Regeln, die oben aufgeführt sind, sollten bei Ihrer Implementierung gespiegelt werden. Dies
stellt sicher, dass es dem gesamten auf einem Datei- und Druckserver eingehenden Verkehr auch
gestattet ist, zu ursprünglichen Server zurückzukommen.
Wie Sie oben gesehen haben, gibt es eine Anzahl Ports und Dienste, die auf dem Datei- und
Druckserver geöffnet wurden. Die Konfiguration einer noch strengeren Sicherheit auf den Datei-
und Druckservern würde es ihnen gestatten weitere Ports zu blockieren. Tatsächlich wurden diese
Ports geöffnet um den Administratoren der Maschinen eine zusätzliche Funktionalitäten zur
Verfügung zu stellen. Über eben diese zusätzlichen Funktionalitäten wird die gesamte
Verwaltung des Servers über die Nutzung von Terminaldiensten durchgeführt.
Bitte beachten Sie, dass Contoso einen MOM-Server in der eigenen Umgebung implementiert
hat. Aufgrund der Umfangreichen Interaktion zwischen MOM-Server und dem OnePoint-Client –
die Clientanwendung die Informationen an die MOM-Konsole sendet – ist jeglicher
Netzwerkverkehr zwischen dem Server und dem MOM-Server gestattet.

Scriptbefehle

Eine Einschränkung von IPSecPol ist, dass es immer nur einen Port hinzufügen kann. Da für RPC
aber eine große Zahl an Ports geöffnet werden muss, ist der einfachste Weg dies umzusetzen ein
Script. Dieses Script generiert automatisch, basierend auf den Ports die geöffnet werden sollen,
eine Batchdatei mit allen benötigten Befehlen.
Das Beispielscript unten generiert eine Datei mit dem Namen c:\ipsec.bat. In dieser befindet sich
für jeden Port, welcher der IPSec-Richtlinie hinzugefügt werden soll, ein separater Befehl. Die
Variable PORT_START definiert den ersten Port des RPC-Bereiches und PORT_END den
letzen. POLICY_NAME ist der Name der IPSec-Richtlinie zu der die Portfilter hinzugefügt
werden. Der Wert IP_ADDR sollte die IP-Adresse des Servers, auf dem die Richtlinie
implementiert wird, enthalten.

PORT_START = 57901
PORT_END = 57950
POLICY_NAME = "Packet Filter"
RULE_NAME = "RPC Ports"
IP_ADDR = "192.168.100.31"
BATCH_FILE = "c:\ipsec.bat"
Dim fso
Dim tf
Const ForWriting = 2
Set fso = CreateObject("Scripting.FileSystemObject")
Set tf = fso.OpenTextFile(BATCH_FILE, ForWriting, True)
tf.Write "ipsecpol -w REG -p " & chr(34) & POLICY_NAME & chr(34) & " -r " &
chr(34) & RULE_NAME & chr(34)
For i = PORT_START TO PORT_END
tf.Write " -f *+" & IP_ADDR & ":" & i & ":TCP"
Next
tf.WriteLine " -n PASS"
tf.Close


Mit wenig manuellem Aufwand ist es möglich mit diesem Script eine Batchdatei zu erstellen, die
IPSec-Richtlinien erstellt.

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
       -f 192.168.100.31+*:53:TCP -f 192.168.100.31+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
       -f *+192.168.100.31:161:TCP -f *+192.168.100.31:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Client"
       -f 192.168.100.31+*:445:TCP -f 192.168.100.31+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
       -f *+192.168.100.31:445:TCP -f *+192.168.100.31:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
       -f 192.168.100.31+*:135:TCP -f 192.168.100.31+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
       -f *+192.168.100.31:135:TCP -f *+192.168.100.31:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Ports"
       -f *+192.168.100.31:57901:TCP -f *+192.168.100.31:57902:TCP
       -f *+192.168.100.31:57903:TCP -f *+192.168.100.31:57904:TCP
       -f *+192.168.100.31:57905:TCP -f *+192.168.100.31:57906:TCP
       -f *+192.168.100.31:57907:TCP -f *+192.168.100.31:57908:TCP
       -f *+192.168.100.31:57909:TCP -f *+192.168.100.31:57910:TCP
       -f *+192.168.100.31:57911:TCP -f *+192.168.100.31:57912:TCP
       -f *+192.168.100.31:57913:TCP -f *+192.168.100.31:57914:TCP
       -f *+192.168.100.31:57915:TCP -f *+192.168.100.31:57916:TCP
       -f *+192.168.100.31:57917:TCP -f *+192.168.100.31:57918:TCP
       -f *+192.168.100.31:57919:TCP -f *+192.168.100.31:57920:TCP
       -f *+192.168.100.31:57921:TCP -f *+192.168.100.31:57922:TCP
     -f *+192.168.100.31:57923:TCP -f *+192.168.100.31:57924:TCP
     -f *+192.168.100.31:57925:TCP -f *+192.168.100.31:57926:TCP
     -f *+192.168.100.31:57927:TCP -f *+192.168.100.31:57928:TCP
     -f *+192.168.100.31:57929:TCP -f *+192.168.100.31:57930:TCP
     -f *+192.168.100.31:57931:TCP -f *+192.168.100.31:57932:TCP
     -f *+192.168.100.31:57933:TCP -f *+192.168.100.31:57934:TCP
     -f *+192.168.100.31:57935:TCP -f *+192.168.100.31:57936:TCP
     -f *+192.168.100.31:57937:TCP -f *+192.168.100.31:57938:TCP
     -f *+192.168.100.31:57939:TCP -f *+192.168.100.31:57940:TCP
     -f *+192.168.100.31:57941:TCP -f *+192.168.100.31:57942:TCP
     -f *+192.168.100.31:57943:TCP -f *+192.168.100.31:57944:TCP
     -f *+192.168.100.31:57945:TCP -f *+192.168.100.31:57946:TCP
     -f *+192.168.100.31:57947:TCP -f *+192.168.100.31:57948:TCP
     -f *+192.168.100.31:57949:TCP -f *+192.168.100.31:57950:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Additional RPC Ports"
     -f 192.168.100.31+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
     -f 192.168.100.31+*:137:TCP -f 192.168.100.31+*:137:UDP
     -f 192.168.100.31+*:139:TCP -f 192.168.100.31+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
     -f *+192.168.100.31:137:TCP -f *+192.168.100.31:137:UDP
     -f *+192.168.100.31:139:TCP -f *+192.168.100.31:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
     -f 192.168.100.31+*:123:TCP -f 192.168.100.31+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Überwachender"
     -f 192.168.100.31+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
     -f 192.168.100.31+*:389:TCP -f 192.168.100.31+*:389:UDP
     -f 192.168.100.31+*:636:TCP -f 192.168.100.31+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
     -f 192.168.100.31+*:88:TCP -f 192.168.100.31+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
     -f *+192.168.100.31:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
     -f 192.168.100.31+*:3268:TCP -f 192.168.100.31+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP"
     -f 192.168.100.31+*:*:ICMP -f *+192.168.100.31:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
       -f *+192.168.100.31 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

Mögliche Auswirkungen

Da diese Einstellungen weiterhin RPC-Verkehr erlauben, wird die Leistung des Servers nicht
eingeschränkt. Der Hauptvorteil dieser Einstellung ist, dass der RPC-Verkehr auf einen
bestimmten Bereich eingeschränkt wird. Trotzdem kann es zu Leistungsproblemen kommen,
basierend auf der Anzahl von Benutzern, die eine Verbindung mit dem Computer aufbauen und
auf der Zahl der RPC-Verbindungen, die etabliert werden müssen. Bevor Sie diese Filter in Ihrer
Umgebung implementieren, sollten Sie umfangreiche Tests durchführen. Die oben angegebenen
Richtlinien können verschärft werden. Die Administration des Servers könnte dann jedoch
schwierig werden. Wie bereits besprochen, sollte die Implementierung dieser relativ kleinen
Anzahl von IPSec-Richtlinien keine spürbare Auswirkung auf die Leistung des Servers haben.
Trotzdem sollen vor der Implementierung dieser Filter in Ihrer Umgebung umfangreiche Tests
durchgeführt werden, um die nötige Funktionalität und Leistung sicher zu stellen. Zusätzliche
Regeln könnten notwendig sein, um andere Anwendungen aus Ihrer Umgebung zu unterstützten.

Contoso Szenario

Contoso hat die oben angegebenen IPSec Filter für seine Datei- und Druckserver implementiert.

Die Rolle IIS-Server
Die jüngsten Untersuchungen haben gezeigt, dass einer von neun IIS-Servern auf irgendeine Art
angegriffen werden kann. Der Dienst Internet Information Services (IIS) 5.0 wird als Vorgabe auf
allen Windows 2000 Servern installiert. IIS 5.0 stellt schon „out of the box“ eine große Anzahl
von Anwendungsfeatures zur Verfügung, und ist ein Beispiel für eine Anwendung, bei der die
gute Benutzbarkeit auf Kosten der ausreichenden Sicherheit geht. Diese Sicherheitslücke wurde
vom Nimda-Wurm ausgenutzt. Es ist wahrscheinlich, dass bei einer Erhöhung der Sicherheit, ein
Teil der einfachen Nutzung des IIS verloren gehen wird. Der IIS 5.0 ist extrem flexibel. Das
heißt, er enthält schon in der Standardinstallation eine große Anzahl an Features. Wie bei jedem
anderen Server, vergrößert auch hier jeder Dienst und jedes Feature die Angriffsfläche.
Trotzdem kann der IIS bedeutend mehr abgesichert werden und weiterhin einen Großteil seiner
grundlegenden Funktionalität zur Verfügung stellen. Der einmalige Zeitaufwand zur
Absicherungen von IIS-Servern ist mit Werkzeugen wie IISLockDown und URLScan deutlich
gesenkt worden.
Das Werkzeug IISLockDown von Microsoft deaktiviert die Features, die sie für die Microsoft-
Produkte die vom IIS abhängen, nicht benötigen. So wird die Angriffsfläche für Angreifer
verringert. URLScan ist ein ISAPI-Filter (Internet Server Application Programming Interface),
der eingehende HTTP-Pakete (Hypertext Transfer Protocol) analysiert und diese auf Grundlage
von Regeln, die Sie festgelegt haben, ablehnt.
Diese Werkzeuge können in Kombination mit einem gut geplanten Server und der Nutzung von
IPSec-Filtern für die Netzwerkkarte, die mit den Clients kommuniziert, zur Erstellung einer
extrem sicheren Lösung führen.
Server patchen
Als erster Schritt zur Absicherung von IIS-Servern in Ihrer Umgebung, ist es zwingend
notwendig, dass Sie alle Servicepacks und Sicherheitsupdates installieren. Diese Verfahren
werden im Kapitel 8, „Patchverwaltung“ näher beschrieben.
Durch die umgehende Aktualisierung des Servers, unbedingt vor der Implementierung in das
Netzwerk, reduzieren Sie das Risiko einer Infektion des Server durch einen Wurm oder einen
anderen Angreifer, wie Code Red oder Nimda. Daher sollte der Server auf dem aktuellsten Stand
und so abgesichert wie möglich sein, bevor er in das Netzwerk implementiert wird.

IIS-Absicherung
Nachdem Sie die notwendigen Patches installiert haben, ist der zweite Schritt in der Absicherung
des IIS-Servers, die Konfiguration der vorgeschlagenen automatischen Werkzeuge. Z. B.
IISLockdown und URLScan.

Übersicht

IIS-Server können einen großen Funktionsumfang zur Verfügung stellen. Um IIS-Server
abzusichern, sollte die Funktionalität dieser Server auf das, was benötigt wird, eingeschränkt
werden. Der einfachste Weg dies zu erreichen, ist das IISLockDown-Werkzeug.
Das IISLockdown-Werkzeug ist ein Hilfsprogramm, das Sie nach dem Anwendungsgebiet des
IIS-Servers fragt. (z. B. dynamischer Webserver oder Exchange Server). Dann entfernt es
sämtliche Funktionalität, die auf diesem speziellen Werbserver nicht benötigt wird. Sie sollten
dann die Änderungen gründlich testen, bevor Sie diese in der Produktionsumgebung umsetzen.

Anmerkung: Das IISLockdown-Werkzeug ist als Teil des Security Toolkit und auf der
Microsoft Security Webseite erhältlich. Weitere Informationen können Sie im Abschnitt
"Zusätzliche Informationen" am Ende dieses Kapitels erhalten.

Das Werkzeug IISLockdown kann viele unterschiedliche Schritte ausführen um Ihnen bei der
Absicherung von Webservern zu helfen. Diese umfassen:
      Deaktivieren von Diensten und Komponenten.
      Installation von URLScan.
      Entfernen von ungenutzten ISAPI-DLL-script-mappings.
      Entfernung von ungenutzten Verzeichnissen
      Datei- und Ordner-ACLs ändern
IISLockdown kann zur Sicherung von vielen verschiedenen Arten von IIS-Webserver-Rollen
genutzt werden. Sie sollten die Rolle wählen, die am besten zu der Art von Anwendung passt, die
Sie auf dem jeweiligen Webserver hosten.
Installation von IISLockdown

In der Umgebung von Contoso wurde der IIS meist als dynamischer Webserver zur
Unterstützung von Active Server Pages (ASP) genutzt. Zur Absicherung der Server wurde in der
Umgebung von Contoso die Version 2.1 von IISLockdown genutzt. Das war zum Zeitpunkt
dieser Veröffentlichung die aktuellste Version dieses Werkzeuges. Mit älteren Versionen ergeben
sich eventuell Probleme und zukünftige Versionen könnten Features unterstützen, die in dieser
Anleitung noch nicht verfügbar sind.


► Um einen dynamischen Wegserver mit IISLockdown manuell abzusichern
   1. Starten Sie iislockd.exe.
   2. Klicken Sie auf Next.
   3. Wählen Sie I agree aus und klicken Sie auf Next.
   4. Wählen Sie Dynamic Web server (ASP enabled) aus und klicken Sie auf Next.
   5. Stellen Sie sicher, dass Install URLScan filter on the server ausgewählt ist und klicken
      Sie auf Next.
   6. Klicken Sie auf Next.
   7. Wenn das Fenster Digital Signature Not Found erscheint, klicken Sie auf Yes.
   8. Klicken Sie auf Next.
   9. Klicken Sie auf Finish.

Anmerkung: IISLockdown kann auch in einem unbeaufsichtigten Modus ausgeführt werden, um
die Verteilung der von Ihnen gewählten Einstellungen zu ermöglichen. Weiter Informationen
hierzu entnehmen Sie bitte der Hilfedatei RunLockdUnattended.doc die im selbstextrahierenden
Archiv iislockd.exe enthalten ist.

Folgen Sie, um den IIS-Server als dynamischer Webserver zu konfigurieren, den oben
beschriebenen Schritten. Der Konfigurationsprozess sollte folgende Änderungen durchgeführt
haben:
      der Dienst FTP ist deaktiviert
      der SMTP-Dienst ist deaktiviert
      der NNTP-Dienst ist deaktiviert
      die Scriptzuordnung Index Server Web Interface (.idq, .htw, .ida) ist deaktiviert
      die Scriptzuordnung Server side includes (.shtml, .shtm, .stm) ist deaktiviert
      die Scriptzuordnung Internet Data Connector (.idc) ist deaktiviert
      die Scriptzuordnung .HTR scripting (.htr) ist deaktiviert
      die Scriptzuordnung Internet printing (.printer) ist deaktiviert
      das virtuelle Druckerverzeichnis wurde entfernt
          das virtuelle Verzeichnis IIS Samples wurde entfernt
          das virtuelle Verzeichnis Scripts wurde entfernt
          das virtuelle Verzeichnis MSADC wurde entfernt
          das virtuelle Verzeichnis IISAdmin wurde entfernt
          die IISAdmin Webseite wurde entfernt
          das virtuelle Verzeichnis IISHelp wurde entfernt
          die Dateiberechtigungen wurde so konfiguriert, dass anonyme IIS-Benutzer keine
           Systemprogramme ausführen können
          die Dateiberechtigungen wurde so konfiguriert, dass anonyme IIS-Benutzer keinen
           Schreibzugriff auf das Basisverzeichnis haben
          Web Distributed Autoring and Versioning (WebDAV) ist deaktiviert
       -     der URLScan-Filter ist auf dem Server installiert

Anmerkung: Wenn eine abweichende IISLockdown Sicherheitsvorlage benötigt wird, oder
wenn es notwendig ist, die ausgewählten Einstellungen anzupassen, kann es ein, dass einige
Dienste, die in der MSBR deaktiviert wurden, wieder aktiviert werden müssen. Dies könnten z.
B. SMTP, NNTP oder FTP sein. Es reicht nicht, einfach das IISLockdown auszuführen und einen
dieser Dienste auszuwählen, da dieser so nicht dauerhaft reaktiviert wird. Das liegt daran, dass
die IIS-Gruppenrichtlinien ihn bei der nächsten Aktualisierung wieder deaktivieren werden. Die
Dienste müssen in der IIS-Gruppenrichtlinie die sie der Web-OU zugewiesen haben, manuell
aktiviert werden.


Dienste

Sicherheitslücken

Dienste und Anwendungen, die ausgeführt werden, sind ein potentieller Angriffspunkt – alle
Dienste und Komponenten, die nicht ausgeführt werden, können auch nicht angegriffen werden.
Daher ist das beste Verfahren, um ein sichereres System zu bekommen, dass deaktivieren von
nicht verwendeten Features. So reduzieren Sie die Angriffsoberfläche der IIS-Server in Ihrer
Umgebung.

Maßnahmen

Nutzen sie IISLockdown, um die vorinstallieren Dienste SMTP und FTP zu deaktivieren. Wenn
NNTP mit dem IIS installiert wurde, sollte es ebenfalls deaktiviert werden.
Alternativ kann IISLockdown auch zur Deinstallation dieser Dienste verwendet werden.
Mögliche Auswirkungen

Die Einstellung UninstallServices in der Datei iislockd.ini sollte genau überdacht werden. Diese
Einstellung ist in allen vorkonfigurierten Vorlagen, die mit der Version 2.1 von IISLockdown
ausgeliefert werden, auf FALSE gesetzt. Wenn Sie diese Einstellung in der Datei iislockd.ini auf
TRUE setzen, werden diese Dienste bei der Ausführung von IISLockdown deinstalliert. Sie
können einen dieser Dienste dann nur manuell über Software in der Systemsteuerung wieder
installieren, oder den Server neu aufsetzen.

Contoso Szenario

Die Dienste NNTP, FTP und SMTP wurden mit IISLockdown auf den IIS-Servern der
Organisation deaktiviert, aber nicht deinstalliert.
► Um die Dienste NNTP, FTP und SMTP auf einem IIS Server unter Verwendung einer
angepassten IISLockd.ini-Datei zu deinstallieren
   1. Öffnen Sie die Datei IISLockd.exe mit einem Packprogramm wie z. B. WinZip und
      entpacken Sie alle Dateien auf Ihre Festplatte.
   2. Offnen sie die Datei iislockd.ini in Notepad
   3. Suchen Sie den Abschnitt, der sich auf die Rolle bezieht, die Sie konfigurieren möchten
      (z. B. [dynamicweb] für die Rolle dynamischer Webserver) und ändern Sie in diesem
      Abschnitt die Einstellungen UninstallServices auf den Wert TRUE. Im Abschnitt [Info]
      geben Sie unter der Einstellung UnattendedServerType den Namen der Vorlage die Sie
      nutzen möchten an.
   4. Ändern Sie die Einstellung von Unattended auf den Wert TRUE.
   5. speichern Sie die Datei iislockd.ini
   6. Führen Sie iislockd.exe von der Kommandozeile oder über ein Script aus.

Scriptzuordnungen deaktivieren

Sicherheitslücken

Die IIS-bezogenen Scriptzuordnungen sind ein hervorragendes Beispiel dafür, dass eine
erweiterte Funktionalität eine geringere Sicherheit zur folge haben kann. Obwohl die
Scriptzuordnungen sehr mächtig sind und einen großen Mehrwert zu einer Webseite hinzufügen
können, sind fast alle Zuordnungen irgendwann einmal seit der Einführung von Windows 2000
durch Angriffe ausgenutzt worden.
      Die Zuordnungen .ida und .idq sind ISAPI-Erweiterungen, die eine erweiterte
       Funktionalität für den Indexserver bieten. Zusammen mit anderen Sicherheitslecks, kann
       ein ungeprüfter Puffer in der Datei idq.dll zu einem Angriff führen, durch den der
       Angreifer die komplette Kontrolle über den Server erlangen kann. Die berühmteste
       Nutzung dieses Sicherheitslochs war der Code Red-Wurm. Weiter Informationen
       entnehmen Sie bitte dem Microsoft Security Bulletin MS01-033.
      Der .htw ISAPI-Filter bietet zusätzliche Funktionalität für den Microsoft Index Server.
       Ein Sicherheitsloch in der zugehörigen Datei webhits.dll kann dazu führen, dass ein
       Benutzer unbeabsichtigt einen feindlichen Link öffnet. Dieses kann dann dazu genutzt
       werden, aktive Inhalte, wie z. B. Javascript, auszuführen. Weiter Informationen
       entnehmen Sie bitte dem Microsoft Security Bulletin MS01-025.
      Die .shtml-Zuordnung ist ein intelligenter HTML-Interpreter, der Teil der Microsoft®
       FrontPage® Servererweiterungen ist. Er wird für die Unterstützung von Server side
       includes genutzt. Eine Sicherheitslücke in der Datei ssiinc.dll könnte verwendet werden,
       um spezifische Inhalte des Angreifers, die auf dem Webserver liegen, zum Browser
       zurückzugeben. Weitere Informationen finden Sie in Microsoft Security Bulletin MS00-
       060.
      Die .idc-Zuordnung enthält eine Sicherheitslücke, die zur Ausnutzung eines
       Sicherheitsloches beim Webseitenübergreifenden Scripting benutzt werden kann. So kann
       die gesamte URL in eine Fehlerseite zurückgegeben werden, was dem Angreifer erlaubt,
       beliebigen Scriptcode auf dem Server auszuführen. Dieser Fehler wurde mit Windows
       2000 SP3 behoben.
      Die .htr-ISAPI-Erweiterung war eine Scriptingtechnologie der ersten Generation für ASP-
       Entwickler. Sie wurde jedoch kaum verwendet. Ein Sicherheitsloch in der Datei ism.dll
       kann dazu ausgenutzt werden, den Sourcecode von ASP-Dateien anzuzeigen. Weitere
       Informationen finden Sie in Microsoft Security Bulletin MS00-031 und MS01-014.
      Die .printer-ISAPI-Erweiterung wurde für die Nutzung von Protokollen für das Drucken
       über das Internet entwickelt. Über ein Sicherheitsloch in der Datei msw3prt.dll kann der
       Angreifer eine Remotekonsole auf dem Ziel IIS-System erlangen. Weitere Informationen
       finden Sie in Microsoft Security Bulletin MS01-023.

Maßnahmen

Alle unnötigen Zuordnungen und ISAPI Filters sollten vom System entfernt werden.
Ungenutzte Scriptzuordnungen sollen auf die Datei 404.dll umgeleitet werden. Die Datei 404.dll
ist ein ISAPI-Filter, der mit einer einfachen 404 Fehlerseite auf Anfragen die über diese
ungenutzten Scriptzuordnungen erfolgen, antwortet.

Anmerkung: Eine ungenutzte Erweiterung auf die 404.dll umzuleiten ist besser, als sie einfach
zu löschen. Bei einer gelöschten Zuordnung wird, wenn die Datei versehendlich auf dem Server
belassen wurde, diese als Klartext angezeigt. Außerdem könnte Sie versehendlich erneut
zugeordnet werden.
Die entsprechenden Dateien und Ordner einer jeden Scriptzuordnung sollen ebenfalls auf dem
entsprechenden System gelöscht werden. Dies wird nicht von IISLockDown erledigt. Der
Vorgang ist unten in dem Abschnitt " Entfernen von virtuellen Verzeichnissen und
Beispielanwendungen“ beschrieben


Mögliche Auswirkungen
Jegliche Funktionalität, die von diesen Scriptzuordnungen zur Verfügung gestellt wurde, wird
verloren gehen. Wenn Webbasierte Anwendungen diese Scriptfunktionalität benötigen, könnten
diese Anwendungen so versehendlich deaktiviert werden.

Contoso Szenario

Im Contoso Szenario wurde IISLockdown zur Entfernung aller unbenötigten ISAPI-Filter auf
allen IIS-Servern der Organisation genutzt. Es blieben nur die .ASP-Dateien und die statischen
Inhalte auf dem Server aktiv. Jede Scripterweiterung wurde automatisch auf die Datei 404.dll
umgeleitet.
Die Umleitung der Scriptzuordnung zur 404.dll kann, wenn IISLockDown nicht genutzt wird,
auch manuell erledigt werden.
►Um die Erweiterungen manuell zur 404.dll zuzuordnen
   1. Öffnen Sie das Internet Services Manager MMC Snap-In.
   2. Klicken Sie mit der rechten Maustaste im linken Fenster auf Ihren Server. Klicken Sie
      dann auf Eigenschaften
   3. Stellen Sie sicher, dass im Feld Haupteigenschaften der Eintrag WWW-Dienst ausgewählt
      ist und klicken Sie dann auf den Schalter Bearbeiten
   4. Wechseln Sie zur Registerkarte Basisverzeichnis, klicken Sie auf Konfiguration
   5. Wählen Sie eine der Erweiterungen aus der Liste und klicken Sie auf Bearbeiten
   6. Klicken Sie auf Durchsuchen und wechseln Sie zu c:\winnt\system32\inetsrv\404.dll.
   7. Klicken Sie auf Öffnen und OK
   8. Wiederholen Sie die Schritte 5, 6 und 7 für die verbleibenden Dateierweiterungen.

Drucken über das Internet

Windows 2000 Server bietet die Möglichkeit über das Internet zu drucken. Diesem Server
Drucker hinzuzufügen bedeutet, dass diese über eine Webseite zur Verfügung stehen. Die
Administration dieser Drucker findet ebenfalls über eine Webseite statt.

Sicherheitslücken

Das Feature für Drucken über das Internet erweitert die Angriffsfläche eines IIS-Servers.
Zusätzlich kann diese Funktionalität über eine GPO erneut gestartet werden, obwohl sie im
Internet-Dienstemanager deaktiviert wurde.
Es ist wichtig, sicherzustellen, dass das Drucken über das Internet über ein GPO deaktiviert
wurde, das für diesen Server gültig ist. Dies sollte vor der Implementierung des Servers gesichert
werden. Die vorgegebene Gruppenrichtlinie deaktiviert diese Funktion nicht, sie aktiviert sie aber
auch nicht.

Maßnahmen
Deaktivieren Sie das Drucken über das Internet über eine Gruppenrichtlinie, indem Sie das
Verfahren für das Contoso Szenario nutzen.
Alternativ kann das Feature auch über den Internet-Dienstemanager deaktiviert werden. Wenn es
einen Konflikt zwischen diesen Einstellungen und denen in einem GPO gibt, haben die
Einstellungen im GPO Vorrang.
Wenn Sie Drucken über das Internet mit dem Internet-Dienstemanager entfernen, überprüfen Sie,
dass es nicht über eine Gruppenrichtlinie wieder aktiviert wird. In den Verfahren zum Contoso
Szenario wird beschrieben, wie Sie dies erledigen.

Mögliche Auswirkungen

Alle Clients, die Drucker auf diesem IIS-Server über das Internet Printing Protocol (IPP) nutzen,
können nicht mehr drucken.

Contoso Szenario

Das Drucken über das Internet wurde mit Hilfe von IISLockdown deaktiviert. Es werden keine
Drucker von den IIS-Servern freigegeben.
► Um das Drucken über das Internet über eine Gruppenrichtlinie zu deaktivieren
   1. Öffnen Sie Active Directory-Benutzer und -Computer mit einer Benutzerberechtigung,
      die es Ihnen gestattet das GPO zu bearbeiten, das Sie nutzen möchten um IPP zu
      deaktiviert.
   2. Klicken Sie mit der rechten Maustaste auf die OU in der das GPO gespeichert ist und
      wählen Sie Eigenschaften
   3. Wechseln Sie zur Registerkarte Gruppenrichtlinie, klicken Sie auf das GPO das sie
      bearbeiten möchten, klicken Sie auf Bearbeiten
   4. Klicken Sie doppelt auf Computerkonfiguration, Administrative Vorlagen, Drucker
   5. Klicken Sie doppelt auf die Einstellung Webbasiertes Drucken, wählen Sie deaktiviert
      und klicken Sie auf OK

Entfernen von virtuellen Verzeichnissen und Beispielanwendungen

Sicherheitslücken

Im IIS 5.0 sind eine Anzahl Beispielanwendungen enthalten. Diese werden zwar nicht als
Vorgabe installiert, sind aber in der Komplettinstallation des IIS enthalten. Außerdem sind im IIS
5.0 mehrere virtuelle Verzeichnisse enthalten, die Beispielanwendungen zur Verfügung stellen.
Die Beispielanwendungen, die in der Vorgabeinstallation des IIS 5.0 enthalten sind, wurden nicht
für den Einsatz auf einem hochsicheren Produktivserver entwickelt. Es ist möglich, dass ein
Angreifer eine Schwachstelle in diesen Anwendungen entdeckt und diese ausnutzt, um die
Webseite anzugreifen. Durch die Entfernung dieser Anwendungen kann die Angriffsfläche des
Webservers verkleinert werden.
Außerdem sind die virtuellen Verzeichnisse selbst nicht für hohe Sicherheit konfiguriert. Das
vorgegebene Script-Verzeichnis gibt z. B. jedem die Möglichkeit in diesem und potentiellen
anderen Verzeichnisse Programme auszuführen.

Maßnahmen

Die virtuellen Verzeichnisse sollten entweder manuell oder mit dem IISLockdown Werkzeug
vom IIS entfernt werden. Die Ihnen untergeordneten Dateien und Ordner sollen ebenfalls per
Hand gelöscht werden.
► Um die Beispielanwendungen zu entfernen
   1. Verwenden Sie das IIS MMC Snap-In um das entsprechende virtuelle Verzeichnisse zu
      löschen
   2. Verwenden Sie den Windows Explorer um die untergeordneten Ordner zu löschen

► Um die Anwendung für die Remoteadministration des IIS zu entfernen
   1. Verwenden Sie das IIS MMC Snap-In um die Administrative Webseite zu beenden
   2. Verwenden Sie das Snap-In um das virtuelle Verzeichnis zu löschen
   3. Verwenden Sie den Windows Explorer um die untergeordneten Ordner zu löschen

Mögliche Auswirkungen

Es sollte keine Auswirkungen geben, es sei denn, Sie verwenden aus irgendeinem
unwahrscheinlichen Grund eine dieser Anwendungen in der Produktivumgebung.

Contoso Szenario

Die virtuellen Verzeichnisse wurden im Contoso Szenario mit IISLockdown entfernt.
Die Beispielanwendungen und andere unnötige Dateien wurden per Hand entfernt. Dieses
umfasste die folgenden Verzeichnisse:
      C:\inetpub\scripts
      C:\inetpub\iissamples
      C:\Program Files\Common files\system\msadc
      C:\winnt\help\iishelp
      C:\Winnt\system32\inetsrv\iisadmin

Dateiberechtigungen von IIS-Benutzern

Sicherheitslücken

Nachdem ein Hacker sich unautorisierten Zugang zum System verschafft hat, könnte es möglich
sein, dass er Systemwerkzeuge verwendet, um auf dem Remoteserver verschiedene Aktionen
auszuführen, oder um Daten anzuzeigen. Mit denselben Systemwerkzeugen könnte ein Hacker
zusätzliche Anwendungen auf dem Server starten.
Maßnahmen

Ergreifen Sie folgende Maßnahmen:
     -   Fügen Sie einen Eintrag in die ACL aller ausführbaren Dateien in C:\WINNT und
         alle Unterordner hinzu. Dieser Eintrag sollte das Recht Ausführen für alle
         Benutzerkonten für den anonymen Zugriff auf diesem Computer verbieten (inklusive
         des Kontos IUSR_Computername). Außerdem sollte das Recht für alle Konten, die zur
         Ausführung von Webanwendungen verwendet werden, verboten sein (inklusive
         IWAM_Computername).
     -   Fügen Sie einen Eintrag in die ACL aller Dateien und Ordner für virtuelle
         Verzeichnisse hinzu. Dieser Eintrag sollte das Recht Schreiben für alle Benutzerkonten
         für den anonymen Zugriff auf diesem Computer verbieten (inklusive des Kontos
         IUSR_Computername). Außerdem sollte das Recht für alle Konten, die zur Ausführung
         von Webanwendungen verwendet werden, verboten sein (inklusive
         IWAM_Computername).
Beide Vorgänge können automatisch über IISLockdown erledigt werden.

Mögliche Auswirkungen

Webanwendungen von Microsoft sind von den oben genannten Maßnahmen nicht betroffen. Es
könnte jedoch sein, dass andere Anwendungen von den Berechtigungen, die oben beschrieben
wurden, abhängen. Sie sollten deshalb erst getestet werden, bevor sie diese Änderungen in Ihre
Produktivumgebung übernehmen.

Contoso Szenario

Die notwendigen Einstellungen wurden im Contoso Szenario mit IISLockdown für die Dateien
und Ordner umgesetzt.

WebDAV deaktivieren

Sicherheitslücken

Eine Sicherheitslücke von WebDAV besteht in der Möglichkeit, dass ein Script unter dem
aktuellen Sicherheitskontext des WebDAV-Prozesses ausgeführt werden könnte. Das bedeutet,
dass ein Angreifer sich innerhalb Ihres Intranets bewegen, und potentiell Zugriff auf gesperrte
Informationen, die nur für das WebDAV-Dienstkonto verfügbar waren, bekommen kann. Weitere
Informationen erhalten Sie in Microsoft Security Bulletin MS01-022.

Maßnahmen

Deaktivieren Sie WebDAV. Erstellen Sie einen Eintrag in die ACL der DLL, die für die
WebDAV-Funktionalität zuständig ist (HTTPext.dll), um zu vermeiden, dass die DLL in den IIS-
Prozess geladen wird. Mit IISLockdown kann diese Aufgabe automatisch erledigt werden.
Verschiedene Anwendungen, wie z. B. Exchange 2000 und Microsoft® SharePoint Portal Server,
benötigen WebDAV. In diesen Fällen ist es das Beste, dass letzte Servicepack zu installieren, um
sicherzustellen, dass WebDAV vollständig abgesichert ist.

Mögliche Auswirkungen

Alle Anwendungen, die von WebDAV abhängig sind, werden nicht mehr funktionieren. Bevor
Sie diese Änderungen in Ihrer Produktivumgebung durchführen, sollten Sie alle Anwendungen
von denen Sie vermuten, dass diese von WebDAV abhängig sind, in einen Laborumgebung
testen.

Contoso Szenario

Da es keine Anwendungen gab, die WebDAV benötigten, wurde WebDAV über IISLockdown
Tool entfernt.

URLScan
URLScan ist ein ISAPI-Filter. Er wird entweder mit IISLockdown installiert, oder Sie können ihn
separat installieren, indem Sie die entsprechenden Dateien aus dem IISLockdown Packet
extrahieren. URLScan gestattet es den Administratoren von Webseiten die Art von HTTP-
Anfragen, die der Server verarbeitet, zu beschränken. Durch die Blockierung von speziellen
HTTP-Anfragen schützt URLScan den Server davor, dass ihn schädliche Anfragen erreichen und
so Schaden anrichten können.

Überblick

URLScan blockiert viele verschiedene Arten von ungewöhnlichen oder potentiell schädlichen
HTTP-Anfragen. Im Besonderen solche, die Zeichen enthalten, die in der Vergangenheit zur
Ausnutzung von Sicherheitslücken geführt haben (z. B. „..“ – diese Zeichenfolge wird für
„directory traversal attacks“ genutzt. Diese Anfragen werden dann im Verzeichnis
%systemroot%\system32\inetsrv\urlscan protokolliert.
Da auch URL von legitimen Webanwendungen diese Zeichen im Pfad haben können, weist
URLScan die Anfrage und sendet eine „404 Not Found“ Fehlermeldung an den Client zurück.
Wenn Sie die Verwendung dieser Zeichen gestatten möchten, weil z. B. eine Ihrer
Webanwendungen sie erfordert, dann setzen Sie den Parameter AllowDotInPath in der Datei
urlscan.ini auf 1 (Sie finden die Datei unter %systemroot%\system32\inetsrv\urlscan\). Es sollte
Ihnen hierbei allerdings klar sein, dass die Erweiterung der erlaubten Zeichen die Sicherheit Ihres
Systems reduziert.

URLScan konfigurieren

Der größte Teil der Konfiguration von URLScan wird über die Änderung der Datei URLScan.ini
erledigt. Sie finden diese Datei unter %systemroot%\system32\inetsrv\urlscan. Diese Datei
enthält verschiedene Abschnitte und Parameter, die im Folgenden aufgeführt sind.
Options

Der Options-Abschnitt der Datei urlscan.ini enthält 10 Einstellungen die von URLScan genutzt
werden. Einige dieser Einstellungen verweisen auf konfigurierte Untereinstellungen der
urlscan.ini-Datei. Diese sind:
      UseAllowVerbs
      UseAllowExtensions
      NormalizeUrlBeforeScan
      VerifyNormalization
      AllowHighBitCharacters
      AllowDotInPath
      RemoveServerHeader
      AlternateServerName
      EnableLogging
      PerProcessLogging
      PerDayLogging
      LogLongUrls
      LoggingDirectory
      AllowLateScanning
      RejectResponseUrl
      UseFastPathReject.

Die meisten dieser Einstellungen sind entweder mit 1 (Wahr) oder 0 (Falsch) konfiguriert. Es gibt
ein paar, die eine weiterführende Konfiguration benötigen. Diese sind unten beschrieben. Weitere
Informationen entnehmen Sie bitte dem Knowledge-Base-Artikel Q326444, „How TO:
Configure the URLScan Tool."

Erlaube Befehle und verbotene Befehle

Begriffe sind eine kritische Komponente von HTTP-Anfragen. GET und HEAD sind die Befehle,
die ein Webbrowser für einfaches Browsen am häufigsten nutzt. Ein Webbrowser benutzt den
Befehl GET z. B. um Informationen von einer bestimmten URL anzufordern.
Browser können andere Befehle wie z. B. PUT, POST und REPLY verwenden, um den Inhalte
von Webseiten zu verändern. FrontPage Servererweiterungen nutzen z. B. die POST und
OPTIONS Befehle um Webinhalte zur Verfügung zu stellen.
Die Einstellung UseAllowVerbs im Abschnitt Options legt fest, ob der Abschnitt AllowVerb der
.ini-Datei verarbeitet wird. Wenn der Wert von UseAllowVerbs 1 ist, überprüft URLScan nur
dem AllowVerbs-Abschnitt und ignoriert den DenyVerbs-Abschnitt der ini-Datei.
Wenn der Wert für UseAllowVerbs auf 0 gesetzt ist, schaut URLScan nur in den Abschnitt
DenyVerbs und ignoriert den Abschnitt AllowVerbs. IIS ist sicherer, wenn alle HTTP-Befehle
verboten sind und nur spezielle Ausnahmen aufgeführt werden. Dies ist auch die Voreinstellung
von URLScan (UseAllowVerbs = 1).
Dieses Feature ist nützlich, wenn Sie die Aktivitäten der Benutzer auf Ihrer Webseite
einschränken möchten.

Allow Extensions und Deny Extensions

Die Abschnitte AllowExtensions und DenyExtensions der URLScan.ini arbeiten genau wie
AllowVerbs und DenyVerbs. Diese Abschnitte legen die spezifischen Dateierweiterungen fest,
auf die eingehende Anfragen Zugriff haben.
Diese Einstellungen erlauben es dem Administrator den Zugriff auf die gebräuchlichen Web-
Dateitypen zu gestatten und gleichzeitig dem Benutzer die Möglichkeit zu nehmen, ausführbare
Dateien oder Scripte zu starten.
Die sicherste Einstellung ist, UseAllowExtensions auf 1 zu setzen und die erlaubten
Erweiterungen im Abschnitt AllowExtensions aufzuführen. Diese Konfiguration wird dann alle
anderen Erweiterungen blockieren. Die Voreinstellung ist UseAllowExtensions = 0. Dies
verbietet den Zugriff auf spezielle Erweiterungen

Deny Headers

Der DenyHeaders Teil der Datei gibt Ihnen die Möglichkeit festzulegen, welche Header von
Clientanfragen zugelassen sind und welche nicht. Dieser Abschnitt könnte z. B. dazu genutzt
werden, den Header „Translate“ zu verbieten. Durch diesen entsteht eine spezielle
Sicherheitslücke, die auf einer ungepatchten Version des IIS 5.0 ausgenutzt werden könnte.

URLScan Implementierung

Sicherheitslücken

URLScan schließt so viele Sicherheitslücken, dass diese Liste zu groß ist, um hier diskutiert zu
werden. Eine der gebräuchlichsten Sicherheitslücken ist „Directory Traversal“. Im Contoso
Szenario wurde diese Lücke als das größte Risiko für die Umgebung identifiziert.
Einen „Directory-Traversal“-Angriff kann ein Angreifer nicht nur dazu nutzen, das Dateisystem
auf dem IIS-Server anzuzeigen. Er kann auch potentiell Daten in diesen Dateien betrachten und
die Möglichkeit erhalten von außen Befehle auf der Maschine auszuführen.

Maßnahmen

Die primäre Gegenmaßnahme für dieses Sicherheitsloch ist ein Verschieben der Verzeichnisse,
welche die Basisverzeichnisse der virtuellen Server enthalten, auf eine andere Partition als die
Systempartition. Es gibt im Moment keinen bekannten Weg für Hacker das Dateisystem über
Partitionsgrenzen hinweg zu durchlaufen und so Befehle auszuführen. Durch das Verschieben der
Datendateien von Webanwendungen auf Partitionen, in denen keine ausführbaren Systemdateien
existieren, werden Angreifer daran gehindert diese Aktionen durchzuführen.
Alternativ können mithilfe von URLScan die Zeichen, die in URL-Aufrufen erlaubt sind,
eingeschränkt werden. URLScan kann die URL vor der Ausführung prüfen. Das verhindert die
meisten „Directory-Traversal“-Angriffe.

Mögliche Auswirkungen

Es gibt keine bekannten Auswirkungen für Microsoft-Anwendungen durch die Installation der
Datendateien auf nicht Systempartitionen. Trotzdem könnte es mit anderen Anwendungen zu
Problemen kommen. Die meisten Anwendungen müssen zusätzlich konfiguriert werden, wenn
Sie nach der Installation an einen anderen Speicherort verschoben werden.
Alle Anwendungen sollten ausführlich in einer Testumgebung getestet werden, bevor Sie sie in
Ihre Produktivumgebung übernehmen.

Contoso Szenario

Im Contoso Szenario wurden die Inetpub-Verzeichnisse und alle virtuellen Verzeichnisse
außerhalb der Systempartition installiert.
Außerdem hat Contoso URLScan implementiert, um die URLs und die ausführbaren Dateien, die
auf dem System ausgeführt werden können, einzuschränken.

Zusätzliche IIS Gruppenrichtlinie
Die Basisrichtlinie, die in Kapitel 6, „Sichern der Standardserver“ besprochen wurde, stellt
sicher, dass die Server eine signifikant höhere Sicherheitsstufe haben, als direkt nach der
Installation. Trotzdem sind, wie bei anderen Servern auch, weitere Sicherheitseinstellungen
notwendig, um weitere Serverfunktionalität und eine Steigerung der Sicherheit zu erreichen.

Systemdienste
Die Rolle IIS-Server fügt der Windows 2000 Server Basisrichtlinie Webserver-Funktionalität
hinzu. Egal, welche anderen Dienste auch immer auf dem IIS-Server ausgeführt werden, die
folgenden zwei Dienste müssen zur Unterstützung der Webserver-Funktionalität aktiviert sein.
Der IIS Admin-Dienst ist nicht nur für die Administration der IIS-Webseiten notwendig, sondern
er ist auch der Kontaktpunkt für den gesamten Webbezogenen Verkehr auf einem IIS-Server.
Daher wird eine Deaktivierung dieses Dienstes auch alle Webseiten, FTP, SMTP und NNTP in
Ihrer Umgebung deaktivieren. Diese Dienste wurden in der IIS Zusatzrichtlinie aktiviert.


Tabelle 7.10: IIS Zusatzrichtlinie - Diensteinstellungen
Dienst                           Starttyp                         Kommentar

IISAdmin                         Automatisch                      Administration des Webservers

W3SVC                            Automatisch                      bietet Webserver-
                                                                  Funktionalität
Manuelle Sicherheitskonfiguration
Zusätzlich zur IIS Zusatzrichtlinie gibt es einige vorgeschlagene Schritte, die manuell
implementiert werden müssen. Diese umfassen:
      Verschieben der Verzeichnisse mit Webinhalten
      Verschieben der Sicherheitsprotokolldateien
      Absichern der Metabase-Berechtigungen
      Deaktivieren von „content location“ in HTTP-Antworten
      Deaktivieren von detaillierten ASP Fehlermeldungen
      Entfernen der FrontPage 2000 Servererweiterungen
      Konfigurieren von IPSec-Filtern

Verschieben von Verzeichnissen mit Webinhalten

Sicherheitslücken

Der IIS ist in seiner vorgegebenen Installation historisch für Angriffe über „Directory-Traversal“-
Angriffe verwundbar. Ein „Directory-Traversal“-Angriff passiert, wenn ein Angreifer aus dem
Stammordner der Webseite „entflieht“ und außerhalb der Webordner Dateien Abfragen oder
Hochladen kann. Wenn IIS-Anwendungen für diese Art des Angriffes verwundbar sind, bedeutet
das bei der vorgegebenen IIS-Installation, dass der Angreifer Zugriff auf die Ordner und Dateien
der Systempartition bekommt. Das schließt unter anderem viele nützliche Systembefehle und
Ordner mit Schreibberechtigung ein. Es gibt keine bekannte Methode über einen HTTP-Befehl,
Dateien über Partitionsgrenzen hinweg aufzurufen.

Maßnahmen

Um diese Angriffe erfolgreich zu verhindern, verschieben sie das \Inetpub-Verzeichnis und alle
virtuellen Verzeichnisse auf andere Partition als die Systempartition.
Dieser Schritt stellt sicher, dass ein Angreifer gerade grundlegende Befehle, wie z. B. cmd.exe,
nicht ausführen kann, wenn er eine unvorhergesehene Sicherheitslücke findet. Außerdem kann er
so nicht in Ordner der Systempartition (z. B. den Ordner \inetpub\Scripts) schreiben.

Mögliche Auswirkungen

Minimal. Der Administrator des Webservers muss nur sicherstellen, dass die Konfiguration der
virtuellen Webseiten festgehalten wird, um sie am neuen Standort erneut zu registrieren.
Contoso Szenario

Die Webseite von Contoso Research wurde hier als Beispiel verwendet. Das virtuelle
Basisverzeichnis der Webseite war C:\Inetpub\wwwroot\research auf dem Webserver. Um die
Dateien auf eine andere Partition aus die Systempartition (wie z. B. E:) zu verschieben, wurden
folgende Schritte durchgeführt:
►Um die gesamten Inhalte der Webseite zu verschieben:
   1. Öffnen Sie das IIS MMC Snap-In.
   2. Klicken Sie mit der rechten Maustaste auf die Webseite. Wählen Sie Stop. (dies hebt die
      Sperrung aller Dateien auf)
   3. Öffnen Sie eine Eingabeaufforderung
   4. Geben Sie den folgenden Befehl ein: xcopy c:\inetpub\wwwroot\research
      d:\wwwroot\research /s /i /o
   5. Gehen Sie zurück zum IIS MMC Snap-In
   6. Klicken Sie mit Rechts auf die Webseite und wählen Sie Eigenschaften
   7. Wechseln Sie zur Registerkarte Basisverzeichnis, klicken Sie dann auf den Schalter
      Durchsuchen und wählen Sie das Verzeichnis aus, in das Sie soeben die Dateien kopiert
      haben (z. B. d:\wwwroot\research).
   8. Klicken Sie mit der rechten Maustaste auf die Webseite und wählen Sie Start

Verschieben und Absichern der Protokolldateien

Sicherheitslücken

Das Verschieben und Sichern der IIS-Protokolldateien kann es dem Angreifer viel schwerer
machen seinen Angriff zu verdecken, indem er die Protokolldateien oder einzelne Einträge
löscht.

Maßnahmen

Verschieben Sie das Verzeichnis für die Protokolldateien in eine andere Partition als die
Systempartition und die Partition, auf der die Daten der Webseite liegen. Setzen Sie dann stärkere
NTFS-Berechtigungen, um die Protokolldateien besser abzusichern. Zum Schluss stellen Sie
sicher, dass die vorgeschlagenen Protokolldateien konfiguriert sind.
Zusätzliche Optionen für die Protokolldateien:
      Bevor sie eine Offlineanalyse der IIS Protokolldateien durchführen, können Sie ein Script
       gesicherte automatische Entfernung der Protokolldateien von jedem Server nutzen.
       Protokolldateien sollen nach spätestens 24 Stunden entfernt und auf einem zentralen
       Server abgelegt werden.
      Es könnte ein automatisches Script erstellt werden um die Protokolldateien zu einer
       anderen Maschine mithilfe von FTP, SMTP, HTTP oder SMB zu übertragen. Dies muss
         allerdings vorsichtig geschehen, um das Öffnen von zusätzlichen Angriffsmöglichkeiten
         zu vermeiden.
        Die IIS-Protokolldateien können, wenn Sie ein CD-RW-Laufwerk haben das mehrfaches
         Schreiben auf einer CD-R unterstützt, auf einer CD-R gespeichert werden. Damit können
         Sie dann die IIS-Protokolldateien auf einem Medium sichern, auf dem sie nicht wieder
         gelöscht werden können. So können Angreifer ihre Spuren nicht verwischen.
        Die IIS-Protokolldateien können auch in einer zentralen UNC (Universal Naming
         Convention) Freigabe (z. B. \\server\share\iislogs anstatt %Windir%\system32\logfiles)
         gespeichert werden. Hierdurch haben Sie die Möglichkeit die Protokolldateien täglich aus
         einem zentralen Verzeichnis zu sichern.
        Außerdem können die Einträge in einer ODBC-Konformen Datenbank gespeichert
         werden. Damit können Sie die IIS-Protokolle an einer zentralen Stelle speichern und
         detailliertere Berechtigungen nutzen (z. B. lesen/schreiben aber nicht löschen). Die
         Protokolleinträge werden dann in einem Format gespeichert, das ideal für eine Analyse
         ist.

Mögliche Auswirkungen

Keine.

Contoso Szenario

Die Protokolldateien der Webserver von Contoso wurden auf eine nicht Systempartition
verschoben. Sicherheit und erweiterte Protokollierung wurden konfiguriert.


► Um die IIS-Protokolldateien auf eine nicht Systempartition zu verschieben
   1. Öffnen Sie das IIS MMC Snap-In.
   2. Klicken Sie mit der rechten Maustaste auf die Webseite und wählen Sie Eigenschaften
   3. Klicken Sie unten im Fenster auf Eigenschaften
   4. Auf der Registerkarte Allgemeine Eigenschaften klicken Sie auf den Schalter
      Durchsuchen. Wählen Sie Laufwerk und Ordner in dem Sie die IIS-Protokolldateien
      speichern möchten
      Anmerkung: Sie müssen bereits vorher einen Ordner erstellt haben.
   5. Klicken Sie zwei mal auf OK

Anmerkung: Wenn Sie unter dem Original Speicherort (%Windir%\System32\logfiles) schon
IIS-Protokolldateien haben, müssen Sie diese manuell an den neuen Speicherort verschieben. Der
IIS erledigt dies nicht automatisch

► Um die vorgeschlagenen Berechtigungen für den Speicherort der IIS-Protokolldateien zu
konfigurieren
   1. Öffnen Sie eine Eingabeaufforderung
   2. Geben Sie folgenden Befehl ein cacls e:\iislogs /t /g administrators:F system:F
      everyone:R
   3. Wenn Sie dazu aufgefordert werden, geben Sie Y ein

► Um die Überwachung im erweiterten W3C Protokollformat zu konfigurieren
   1. Öffnen Sie das IIS MMC Snap-In.
   2. Klicken Sie im linken Fenster mit der rechten Maustaste auf Ihren Server und wählen Sie
      Eigenschaften
   3. Stellen Sie sicher, dass WWWService im Feld Haupteigenschaften steht und klicken Sie
      auf Bearbeiten
   4. Wählen Sie Protokollierung aktivieren und prüfen Sie, ob im Feld Aktives
      Protokollformat W3C-Erweitert eingetragen ist
   5. Klicken Sie auf Eigenschaften
   6. Wählen Sie das Feld „Wenn Dateigröße erreicht“ aus und geben Sie als
      Dateigröße 500 MB an
   7. Ändern Sie das Protokolldateiverzeichnis. Verwenden Sie, wie vorgeschlagen, eine nicht
      Systempartition auf der nicht Ihre Webseite liegt
   8. Wählen Sie die Registerkarte Erweiterte Eigenschaften
   9. Wählen Sie zusätzlich den Eintrag Win32 Statuseintrag
   10. Klicken Sie drei mal auf OK

Anmerkung: Reines Überwachen verhindert keine Angriffe auf das System. Es ist jedoch ein
hervorragendes Werkzeug um Eindringlinge und laufende Angriffe zu identifizieren und um die
Spuren von Angriffen zu untersuchen


Metabase Berechtigungen absichern

Sicherheitslücken

Sicherheit und andere IIS-Konfigurationseinstellungen werden im der IIS-Metabasedatei
verwaltet. Die vorgegebenen Berechtigungen erlauben es jedem Angreifer die Metabasedatei
direkt zu bearbeiten. Die NTFS-Berechtigungen der IIS-Metabasedatei (und die der
Sicherungsdatei) sollten sicherer konfiguriert werden, um sicherzustellen, dass Angreifer die IIS-
Konfiguration auf keinen Fall ändern können. Z. B. kann ein Angreifer versuchen die
Authentifizierung für ein spezielles virtuelles Verzeichnis über eine Änderung der Metabasedatei
zu entfernen.

Maßnahmen

Sichern Sie die Metabasedatei so, dass nur Administratoren und SYSTEM Vollzugriff haben
Mögliche Auswirkungen

Auswirkungen können nur auftreten, wenn die Berechtigungen für die Metabasedatei zu restriktiv
gesetzt wurden. Diese könnten so den Zugriff der Gruppen Administratoren oder SYSTEM
verhindern.

Contoso Szenario

Die Metabasedateien wurden über die Verwendung der IIS Zusatzrichtlinie abgesichert
► Um die NTFS Berechtigungen der Metabasedateien manuell zu konfigurieren
   1. Öffnen Sie eine Eingabeaufforderung
   2. Geben Sie den folgenden Befehl ein: cacls
      %systemroot%\system32\inetsrv\metabase.bin /g administrators:F system:F.
   3. Geben Sie Y ein wenn Sie dazu aufgefordert werden
   4. Geben Sie den folgenden Befehl ein: cacls
      %systemroot%\system32\inetsrv\metaback /g administrators:F system:F.
   5. Geben Sie Y ein wenn Sie dazu aufgefordert werden
Diese Einstellungen sind in der Richtlinienvorlage MSS IIS Role.inf dieser Anleitung enthalten.

Content Location in HTTP-Antworten deaktivieren

Sicherheitslücken

Beim Versand einer statischen HMTL-Seite wird ein content-location-Header von IIS zur
Antwort hinzugefügt. In der Voreinstellung verweist dieser Header auf die IP-Adresse, und nicht
auf den FQDN der aktuellen Webseite. Hierdurch entsteht ein Sicherheitsloch, durch das Ihre
interne IP-Adresse unbeabsichtigt offen gelegt wird.

Maßnahmen

Verbergen Sie den content-location-Header, der als Vorgabe im HTTP Response Headers
zurückgegeben wird. Sie können die über die Änderungen des Wertes UseHostName in der IIS-
Metabase erreichen. Der IIS wird dann den FQDN anstatt der IP-Adresse zurückgeben.

Mögliche Auswirkungen

Keine.

Contoso Szenario

Die Einstellung UseHostName wurde im Contoso Szenario unter Verwendung des Skriptes
adsutil.vbs auf den Wert True geändert. Der Syntax, um diesen Schritt durchzuführen, lautet:
cscript Adsutil.vbs set w3svc/UseHostName True
Das ADSUtil.vbs Script liegt im Verzeichnis IIS Adminscripts auf dem IIS-Server (in der
Voreinstellung ist das C:\Inetpub\Adminscripts).

Anmerkung: Weitere Informationen zur manuellen Durchführung dieses Schrittes finden Sie im
Knowledge-Base-Artikel Q218180, "Internet Information Server Returns IP Address in HTTP
Header (Content-Location)."


Detaillierte ASP Fehlermeldungen deaktivieren

Sicherheitslücken

Wenn interne Anwendungsfehler auftreten, sendet IIS in der Voreinstellung an den Client
detaillierte ASP-Fehlermeldungen. Während dies für die Fehlersuche sehr nützlich ist, kann es
Angreifern Informationen über die interne Arbeitsweise der Anwendung preisgeben. Hierdurch
kann ein Hacker einfacher herausfinden, wie eine Anwendung angreifbar ist.

Maßnahmen

Deaktivieren Sie auf den IIS-Server in Ihrer Produktionsumgebung detaillierte ASP-
Fehlermeldungen.

Mögliche Auswirkungen

Die Fehlersuche in Webanwendungen kann schwieriger werden, da die Fehlermeldungen in den
IIS-Protokolldateien nicht annährend so ausführlich sind, wie bei detaillierten ASP-
Fehlermeldungen. Wenn sie reproduzierbare ASP-Fehler erhalten, gibt es zwei Alternativen um
das Problem zu lösen: Erstellen Sie eine gespiegelte Entwicklungsumgebung (konfigurieren sie
hier detaillierte ASP-Fehlermeldungen), oder aktivieren sie für einen beschränkten Zeitraum die
Einstellung in Ihrer Produktionsumgebung.

Contoso Szenario

In der Produktionsumgebung von Research und HR wurde auf den IIS-Servern die Einstellung
detaillierte ASP-Fehlermeldungen mit dem unten beschriebenen Script adsutil.vbs deaktiviert.
► Um die detaillierten ASP-Fehlermeldungen zu deaktivieren
   1. Öffnen Sie das IIS MMC Snap-In.
   2. Klicken Sie im linken Fenster mit der rechten Maustaste auf Ihren Server und wählen Sie
      Eigenschaften
   3. Stellen Sie sicher, dass WWWService im Feld Haupteigenschaften steht und klicken Sie
      auf Bearbeiten
   4. Wechseln Sie zur Registerkarte Basisverzeichnis
   5. Klicken Sie auf Konfiguration
   6. Wählen Sie eine der Erweiterungen aus der Liste aus und klicken Sie auf Bearbeiten
   7. Klicken Sie auf Durchsuchen und wechseln Sie zu c:\winnt\system32\inetsrv\404.dll
   8. Klicken Sie auf Öffnen und OK
   9. Wiederholen Sie die Schritte 6, 7 und 8 für alle verbleibenden Erweiterungen

Alternativ kann dieser Vorgang über das Script Adsutil.vbs durchgeführt werden. Der Syntax
hierzu lautet: cscript Adsutil.vbs set w3svc/AspScriptErrorSentToBrowser False

FrontPage 2000 Servererweiterungen entfernen

Sicherheitslücken

Die FrontPage 2000 Servererweiterungen stellen praktische Verfahren zur Zusammenarbeit von
Office-Benutzer-Teams und zur externen Verwaltung von Webseiten-Inhalten zur Verfügung.
Diese Verwaltungsmöglichkeiten sind für Webseiten mit nur einem Administrator nicht
unbedingt notwendig und können von erfahrenen Angreifern als Angriffspunkt auf die Webseite
genutzt werden.

Maßnahmen

Deaktivieren Sie die FrontPage 2000 Servererweiterungen auf allen IIS-Servers in Ihrer
Produktionsumgebung.

Mögliche Auswirkungen

Wenn Sie die Verwaltung verschiedener virtueller Webseiten an Benutzer ohne Administrative
Rechte delegieren wollen, dann benötigen Sie möglicherweise die FrontPage 2000
Servererweiterungen. In diesem Fall stellen Sie sicher, dass Sie wirklich alle aktuellen Hotfixes
für die FrontPage2000 Servererweiterungen auf Ihren IIS-Webservern installiert haben.

Contoso Szenario

In der Umgebung von Contoso werden die IIS-Webseiten alle von einer kleinen Gruppe von IT-
Mitarbeitern administriert. Diese Gruppe ist in der Lage, das Internetdienste MMC-Snap-In über
den Terminaldienst als auch über das Netzwerk zu nutzen. Daher wurden die FrontPage2000
Servererweiterungen manuell für alle IIS-Produktionsserver deaktiviert.


► Um die FrontPage 2000 Servererweiterungen manuell zu entfernen
   1. Öffnen Sie Software in der Systemsteuerung, wählen Sie Windows-Komponenten
      hinzufügen/entfernen.
   2. Wählen Sie Internet Information Services (IIS) aus und klicken Sie auf den Schalter
      Details
   3. Deaktivieren Sie das Kontrollkästchen FrontPage 2000 Servererweiterungen, klicken
      Sie auf OK und auf Weiter
   4. Wenn das Fenster Terminaldiensteinstallation erscheint, klicken Sie auf Weiter – oder,
      wenn das Fenster Dateien benötigt erscheint, wechseln Sie zu dem Speicherort, von dem
      Sie Windows 2000 ursprünglich installiert haben. Klicken Sie auf OK
   5. Wenn Sie dazu aufgefordert werden, klicken Sie auf Fertig
   6. Wenn notwendig, löschen Sie die FrontPage Server Verzeichnisse:
           -   C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40
           -   C:\Inetpub\wwwroot\_private
           -   C:\Inetpub\wwwroot\_vti_cnf
           -   C:\Inetpub\wwwroot\_vti_log
           -   C:\Inetpub\wwwroot\_vti_pvt
           -   C:\Inetpub\wwwroot\_vti_script

Zusätzliche Virtuelle Server löschen

Sicherheitslücken

Mit der vorgegebenen Installation des IIS wird auch eine FTP-Seite, eine Default- Webseite und
eine Administrations-Webseite erstellt. Diese Seiten enthalten häufig Beispielcode und sind
außerdem ein potentieller Startpunkt für Angriffe, die eine ungesicherte Instanz dieser Dienste
erfordern. Wenn sie für Ihre Produktionsumgebung nicht notwendig sind, ist das Löschen oder
Deaktivieren dieser Seiten die beste Vorgehensweise.

Maßnahmen

Entfernen sie die Default FTP-Seite und die Administrations-Webseite. Halten Sie die Default-
Webseite an.

Mögliche Auswirkungen

Sie könnten in den vorgegebenen Webseiten verschiedene Anwendungen installiert haben. Bevor
Sie diese Webseiten löschen, sollten Sie sicherstellen, dass Sie diese Anwendungen auf eine neue
Webseite auf Ihrem IIS-Server migriert haben. Wenn Sie die gesamten Webseiten, aus welchen
Gründen auch immer, nicht löschen können, sollten Sie doch zumindest den Beispielcode
löschen. Verwenden Sie hierzu das Werkzeug IISLockdown.

Contoso Szenario

Die vorgegebenen Webseiten waren im Contoso Szenario nicht notwendig. Alle produktiven
Webseiten wurden jeweils über eine neue virtuelle Webseite implementiert. Daher wurden die
vorgegeben Seiten gelöscht oder beendet.


► Um die Standard FTP-Seite manuell zu entfernen
   1. Öffnen Sie das IIS MMC Snap-In.
   2. Klicken Sie mit der rechten Maustaste auf Standard-FTP-Seite, wählen Sie löschen und
      klicken Sie auf Ja.

► Um die Administrations-Webseite manuell zu entfernen
   1. Öffnen Sie das IIS MMC Snap-In.
   2. Klicken Sie mit der rechten Maustaste auf Verwaltungswebsite, wählen Sie löschen und
      klicken Sie auf Ja.

► Um die Standardwebseite manuell anzuhalten
   1. Öffnen Sie das IIS MMC Snap-In.
   2. Klicken Sie mit der rechten Maustaste auf Standardwebsite, wählen Sie löschen und
      klicken Sie auf Ja.

Überlegungen zu zusätzlichen IIS-Servereinstellungen
Deaktivierung des IUSR Kontos

Um den Zugriff von anonymen Internetbenutzern zu ermöglichen, wird währen der
Standardinstallation des IIS ein Konto mit dem Namen IUSR_COMPTERNAME erstellt.
COMPUTERNAME ist der NetBIOS-Name des Rechners auf dem der IIS installiert wird. Wenn
Sie keinen anonymen Zugriff auf Ihre Webseite gestatten, dann sollten Sie das Anonymous-
Benutzerkonto löschen.
Anonymer Zugriff kann auch über jedes andere Konto gestattet werden, nicht nur über dieses –
dieses Konto wird eben nur bei der Installation des IIS zusätzlich erstellt. Das Deaktivieren oder
Löschen dieses Kontos führt nicht dazu, dass kein anonymer Zugriff mehr für die Webbenutzer
möglich ist.
Dieses Konto wird von der Mehrheit aller öffentlichen Webseiten, die den Benutzern anonymen
Zugriff gestatten, oder die Authentifizierung selber vornehmen (z. B. über die
Formularauthentifizierung), für Zugriff auf die Webseite genutzt.

Anmerkung: Wenn Ihre Webseite mehrere Anwendungen hostet, können Sie auch mehrere
Anonymous-Konten nutzen (z. B. eins pro Anwendung), um sicherzustellen, dass die Aktionen
für jede Anwendung getrennt überwacht werden können.


Überwachung der regulären Gruppenmitgliedschaften durchführen

Überwachen Sie, besonders bei privilegierten Gruppen wie den Administratoren, die
Gruppenmitgliedschaften. Die Zahl der Mitglieder der Gruppe Administratoren sollte so gering
wie möglich gehalten werden. Neue Mitarbeiter sollten erst eine komplette Einweisung erhalten,
bevor Sie zur Gruppe Administratoren hinzugefügt werden.

Weiter Empfehlungen um Benutzer und Gruppen zu sichern
      erstellen Sie für spezielle administrative Aufgaben spezielle Gruppen
      achten Sie auf nicht autorisierte Mitglieder in privilegierten Gruppen (z. B.
       Serveroperatoren)
      überwachen Sie die Gruppenmitgliedschaften periodisch
      wenden Sie strenge Vorraussetzungen und Richtlinien an, bevor Sie jemanden in die
       Gruppe Administratoren aufnehmen


Die Einstellung „übergeordnete Pfade“ deaktivieren

Diese IIS-Metabaseeinstellung verhindert die Nutzung von „..“ (zwei Punkte) Funktionen wie z.
B. MapPath in Anwendungen und Scripten. Sie verhindert potentielle „Directory-Traversal“-
Angriffe
► Um die Einstellung „übergeordnete Pfade“ manuell zu deaktivieren
   1. Klicken Sie mit der rechten Maustaste auf die Webseite die Sie absichern möchten und
      klicken Sie auf Eigenschaften
   2. Wechseln Sie zu Registerkarte Basisverzeichnis
   3. Klicken Sie auf Konfiguration
   4. Wechseln Sie zu Registerkarte Anwendungsoptionen
   5. Deaktivieren Sie die Einstellung „übergeordnete Pfade aktivieren“

Anmerkung: Wenn Sie die Application Center 2002-Administrationsseite nutzen, lesen Sie
bitte den Knowledge-Base-Artikel Q288309, "PRB: Disabling Parent Paths Breaks User
Interface."


Ports über IPSec-Filter blockieren

Sicherheitslücken

Wie schon erwähnt, wird die Reduzierung der offenen Ports, auf den Servern in Ihrer
Organisation, die Angriffsfläche jeder einzelnen Maschine in großem Umfang reduzieren. Offene
Ports können einem Angreifer als Startpunkt für Angriffe auf andere Server Ihrer Organisation
dienen – ein Wurm und trojanisches Pferd kann z. B. eine Anwendung installieren, die auf einem
unautorisierten Port auf einem Server auf eingehende Befehle wartet.

Maßnahmen

Konfigurieren Sie IPSec Blockierungsfilter, die nur den Netzwerkverkehr erlauben, der unten
spezifiziert ist. Dies wird die Zahl von unerwarteten und nicht autorisierten Anwendungen die
Anfragen entgegen nehmen oder angegriffen werden könnten, reduzieren.

Zusätzlicher IIS-Server IPSec Netzwerkverkehrsplan
Tabelle 7.11: Zusätzlicher IIS-Server IPSec   Netzwerkverkehrsplan

Dienst       Protokoll Quellport   Zielport     Quelladresse Zieladresse Aktion

DNS Client TCP             ALLE          53             Host IP      ALLE         ZULASSE
                                                                                  N

               UDP         ALLE          53             Host IP      ALLE         ZULASSE
                                                                                  N

SNMP           TCP         ALLE          161            ALLE         Host IP      ZULASSE
Server                                                                            N

               UDP         ALLE          161            ALLE         Host IP      ZULASSE
                                                                                  N

CIFS Client TCP            ALLE          445            Host IP      ALLE         ZULASSE
                                                                                  N

               UDP         ALLE          445            Host IP      ALLE         ZULASSE
                                                                                  N

CIFS Server TCP            ALLE          445            ALLE         Host IP      ZULASSE
                                                                                  N

               UDP         ALLE          445            ALLE         Host IP      ZULASSE
                                                                                  N

RPC Client     TCP         ALLE          135            Host IP      ALLE         ZULASSE
                                                                                  N

               UDP         ALLE          135            Host IP      ALLE         ZULASSE
                                                                                  N

RPC Server TCP             ALLE          135            ALLE         Host IP      ZULASSE
                                                                                  N

               UDP         ALLE          135            ALLE         Host IP      ZULASSE
                                                                                  N

zus. RPC       TCP         ALLE          57952          Host IP      ALLE         ZULASSE
Ports                                                                             N
ausgehend

NetBIOS        TCP         ALLE          137            Host IP      ALLE         ZULASSE
Client                                                                            N

               UDP         ALLE          137            Host IP      ALLE         ZULASSE
                                                     N

             TCP   ALLE   139    Host IP   ALLE      ZULASSE
                                                     N

             UDP   ALLE   138    Host IP   ALLE      ZULASSE
                                                     N

NetBIOS      TCP   ALLE   137    ALLE      Host IP   ZULASSE
Server                                               N

             UDP   ALLE   137    ALLE      Host IP   ZULASSE
                                                     N

             TCP   ALLE   139    ALLE      Host IP   ZULASSE
                                                     N

             UDP   ALLE   138    ALLE      Host IP   ZULASSE
                                                     N

NTP Client   TCP   ALLE   123    Host IP   ALLE      ZULASSE
                                                     N

             UDP   ALLE   123    Host IP   ALLE      ZULASSE
                                                     N

Überwachen ALLE    ALLE   ALLE   Host IP   MOM       ZULASSE
der Client                                 Server    N

LDAP         TCP   ALLE   389    Host IP   ALLE      ZULASSE
Client                                               N

             UDP   ALLE   389    Host IP   ALLE      ZULASSE
                                                     N

             TCP   ALLE   636    Host IP   ALLE      ZULASSE
                                                     N

             UDP   ALLE   636    Host IP   ALLE      ZULASSE
                                                     N

Kerberos     TCP   ALLE   88     Host IP   ALLE      ZULASSE
Client                                               N

             UDP   ALLE   88     Host IP   ALLE      ZULASSE
                                                     N

Terminal     TCP   ALLE   3389   ALLE      Host IP   ZULASSE
Services                                                                            N

Global          TCP         ALLE          3268          Host IP       ALLE          ZULASSE
Catalog                                                                             N
Client

                TCP         ALLE          3269          Host IP       ALLE          ZULASSE
                                                                                    N

HTTP            TCP         ALLE          80            ALLE          Host IP       ZULASSE
Server                                                                              N

HTTPS           TCP         ALLE          443           ALLE          Host IP       ZULASSE
Server                                                                              N

ICMP            ICMP        ALLE          ALLE          Host IP       ALLE          ZULASSE
                                                                                    N

der gesamte ALLE            ALLE          ALLE          ALLE          Host IP       BLOCKIER
eingehende                                                                          EN
Verkehr



Anmerkung: Die Host IP unter Zieladresse in Tabelle 7.5 sollte auf die IP Ihres Servers gesetzt
sein.

Alle Regeln die oben aufgeführt sind, sollten bei Ihrer Implementierung gespiegelt werden. Dies
stellt sicher, dass es dem gesamten auf einem IIS-Server eingehenden Verkehr auch gestattet ist,
zu ursprünglichen Server zurückzukommen.
Wie Sie oben gesehen haben, gibt es eine Anzahl Ports und Dienste, die auf dem IIS-Server
geöffnet wurden. Die Konfiguration einer noch strengeren Sicherheit auf dem IIS-Server würde
es ihnen gestatten, weitere Ports zu blockieren. Tatsächlich wurden diese Ports geöffnet um den
Administratoren der Maschinen eine zusätzliche Funktionalitäten zur Verfügung zu stellen. Über
eben diese zusätzlichen Funktionalitäten wird die gesamte IIS-Verwaltung und die Verwaltung
des Server über die Nutzung von Terminaldiensten durchgeführt.


Bitte beachten Sie, dass Contoso einen MOM-Server in der eigenen Umgebung implementiert
hat. Aufgrund der Umfangreichen Interaktion zwischen MOM-Server und dem OnePoint-Client –
die Clientanwendung die Informationen an die MOM-Konsole sendet – ist jeglicher
Netzwerkverkehr zwischen dem Server und dem MOM-Server gestattet.

Scriptbefehle
Die Implementierung der folgenden Befehle sollte auf dem IIS-Server ausgeführt werden. Diese
Befehle blockieren den Netzwerkverkehr so wie oben spezifiziert. Dieser Satz von Befehlen steht
Ihnen auch als Batchdatei die dieser Anleitung beiliegt, zur Verfügung.

ipsecpol -w REG -p "Packet Filter" -r "DNS Client"
-f 192.168.100.41+*:53:TCP -f 192.168.100.41+*:53:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "SNMP Server"
-f *+192.168.100.41:161:TCP -f *+192.168.100.41:161:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Client"
-f 192.168.100.41+*:445:TCP -f 192.168.100.41+*:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server"
-f *+192.168.100.41:445:TCP -f *+192.168.100.41:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Client"
-f 192.168.100.41+*:135:TCP -f 192.168.100.41+*:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "RPC Server"
-f *+192.168.100.41:135:TCP -f *+192.168.100.41:135:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Addl RPC Ports Out"
-f 192.168.100.41+*:57952:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Client"
-f 192.168.100.41+*:137:TCP -f 192.168.100.41+*:137:UDP
-f 192.168.100.41+*:139:TCP -f 192.168.100.41+*:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server"
-f *+192.168.100.41:137:TCP -f *+192.168.100.41:137:UDP
-f *+192.168.100.41:139:TCP -f *+192.168.100.41:138:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NTP Client"
-f 192.168.100.41+*:123:TCP -f 192.168.100.41+*:123:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Überwachender"
-f 192.168.100.41+192.168.100.73 -n PASS
ipsecpol -w REG -p "Packet Filter" -r "LDAP Client"
-f 192.168.100.41+*:389:TCP -f 192.168.100.41+*:389:UDP
-f 192.168.100.41+*:636:TCP -f 192.168.100.41+*:636:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Kerberos Client"
-f 192.168.100.41+*:88:TCP -f 192.168.100.41+*:88:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server"
-f *+192.168.100.41:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "GC Client"
-f 192.168.100.41+*:3268:TCP -f 192.168.100.41+*:3269:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f *+192.168.100.41:*:ICMP -n
PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTP Server"
-f *+192.168.100.41:80:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTPS Server"
-f *+192.168.100.41:443:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic"
-f *+192.168.100.41 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x



Mögliche Auswirkungen

Da diese Einstellungen keinen Verkehr über zufällige hohe Ports zulassen, ist RPC-Verkehr nicht
erlaubt. Das kann die Verwaltung des Servers erschweren. Durch die Nutzung des Common
Internet File System (CIFS) und der grundlegenden NetBIOS Ports werden allerdings trotzdem
eine Menge Möglichkeiten bereitgestellt. Das CIFS-Protokoll definiert einen Standard für den
Dateizugriff über das Netzwerk. Mit CIFS haben Benutzer unterschiedlicher Plattformen und
Computer die Möglichkeit Dateien ohne die Installation neuer Software zur Verfügung zu stellen.
Administratoren sollen in der Lage sein, sich zur Remoteadministration mithilfe eines
Terminaldienst-Clients zu verbinden. Während Sie mit dem IIS-Server verbunden sind, sollten
Sie in der Lage sein, Netzlaufwerke zu verbinden. Die oben angegebenen Richtlinien können
natürlich gestrafft werden, um diese Funktionen zu verhindern. Dann könnte die Administration
des Servers allerdings umständlich werden.
Diese Richtlinien erlauben weiterhin jeglichen notwendigen Authentifizierungsverkehr für alle
Webseiten die eine basic- oder NT-LM-Authentifizierung erfordern.
Die Implementation dieser relativ kleinen Anzahl von IPSec-Richtlinien sollte keine spürbare
Auswirkung auf die Leistung des Servers haben. Trotzdem sollen vor der Implementation dieser
Filter in Ihrer Umgebung umfangreiche Tests durchgeführt werden, um die nötige Funktionalität
und Leistung sicher zu stellen. Zusätzliche Regeln könnten notwendig sein, um andere
Anwendungen aus Ihrer Umgebung zu unterstützten.

Contoso Szenario

Im Contoso Szenario wurden die IPSec-Filter, die oben dargestellt sind, auf den IIS-Servern
implementiert.

„Best Practices“ für den IIS

Die folgenden Empfehlungen stellen die grundsätzlich besten Vorgehensweisen zur
Implementierung und Absicherung von IIS-Servern dar:
      installieren Sie den IIS nicht auf Domänencontrollern
      verbinden Sie den IIS-Server nicht, bevor er nicht alle Patches installiert sind und eine
       höchstmögliche Absicherung implementiert ist (Ausnahme: Änderung von
       Gruppenrichtlinien – diese müssen von einem Domänencontroller im Netzwerk kommen)
   nutzen Sie eine dedizierte Maschine als Webserver
   schützen Sie den Webserver-Rechner in einem physikalisch abgesicherten Serverraum
   gestatten Sie, außer den Administratoren, niemandem sich an der Maschine lokal
    anzumelden
   gestatten Sie den Administratoren nicht, sich über das Netzwerk an der Maschine
    anzumelden. Führen Sie Arbeitsanweisungen für die lokale Administration ein.
Zusammenfassung
Dieses Kapitel erklärt die Verfahren zur Serverabsicherung, angewandt auf die einzelnen
Serverrollen im Contoso Szenario. Die meisten dieser Verfahren wurden über die Erstellung einer
Vielzahl von Sicherheitsvorlagen durchgeführt. Diese wurden dann in ein
Gruppenrichtlinienobjekt importiert, das zu der, der Serverrolle entsprechenden, OU zugewiesen
ist. Einige Absicherungsprozesse konnten nicht über Gruppenrichtlinien durchgesetzt werden. In
diesen Fällen wurden Ihnen Informationen zur Verfügung gestellt, die zeigen wie diese Prozesse
per Hand durchgeführt werden.
Da sie nur Ihre Windows 2000 Server abgesichert haben, können Sie die nächsten Schritte in
Angriff nehmen: Wie stellen Sie sicher, dass in Ihrer Organisation auch weiterhin
Sicherheitsupdates angewandt werden. Wie überwachen Sie die Sicherheit Ihrer Systeme und wie
reagieren Sie bei Sicherheitsproblemen, die eventuell zukünftig auf den Server auftreten könnten.



Weiter Informationen
Informationen zur Microsoft Systemarchitektur finden Sie in „Enterprise Data Center
prescriptive architecture guides“ unter:
http://www.microsoft.com/technet/itsolutions/edc/default.asp.
Weiter Informationen über anonymen Zugriff auf Active Directory finden Sie im Knowledge-
Base-Artikel Q257988, "Description of Dcpromo Permissions Choices."
Informationen über Windows NT 4.0 RAS, RRAS und Active Directory finden Sie im
Knowledge-Base-Artikel Q254311, "Enable Windows NT 4.0-Based RAS Servers in a Windows
2000-Based Domain."
Informationen über den Windows 2000 DNS finden sie im Whitepaper "Windows 2000 DNS"
unter:
http://www.microsoft.com/windows2000/techinfo/howitworks/communications/nameadrmgmt/w
2kdns.asp.
Informationen über den Windows 2000 DNS finden sie ausserdem in Kapitel 6 der Onlineversion
von "TCP/IP Core Networking Guide" unter:
http://www.microsoft.com/windows2000/techinfo/reskit/samplechapters/cncf/cncf_imp_vsin.asp.
Weiter Informationen über die 80/20 Regel finden Sie unter:
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/cnet/cncb_dhc_ogjw.asp.
Informationen über IISLockdown, Version 2.1 und Informationen über URLScan erhalten sie
unter: http://www.microsoft.com/technet/security/tools/tools/locktool.asp.
Informationen über den IIS 5.0 erhalten Sie im Whitepaper "From Blueprint to Fortress: A Guide
to Securing IIS 5.0" unter:
http://www.microsoft.com/technet/prodtechnol/iis/deploy/depovg/securiis.asp.
Informationen zu Verwaltung der Sicherheit bei IIS-Webdiensten finden sie unter "Manage
Security of Your Windows IIS Web Services" unter:
http://www.microsoft.com/technet/security/bestprac/mcswebbp.asp.
Ein Checkliste zur Sicherheit des IIS-Dienstes erhalten Sie unter "Secure Internet Information
Services 5 Checklist" unter: http://www.microsoft.com/technet/security/tools/chklist/iis5chk.asp.
Informationen über die IIS 5.0 Baseline Security Checkliste, die ein Teil der Secure IIS 5
Checkliste ist, finden Sie unter:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/chklist/iis5cl.a
sp.
Informationen über die passeneden Dateisystemberechtigungen für die IIS-Inhalte und
Protokolldateien finden Sie im Knowledge-Base-Artikel Q310361, "HOW TO: Set Secure NTFS
Permissions on IIS 5.0 Log Files and Virtual."
Informationen zur erweiterten programmatischen Administration des IIS 5.1 finden Sie unter:
http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/abgu26y6.asp.
Informationen über den Schutz gegen SYN-Angriffe finden Sie im Knowledge-Base-Artikel
Q315669, "HOW TO: Harden the TCP/IP Stack Against Denial of Service Attacks in Windows
2000“
Weiter Informationen zur Absicherung und Verwaltung des IIS finden Sie unter:
http://www.iisanswers.com.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:12
posted:6/26/2012
language:German
pages:97