Bedrohungen und Gegenmaßnahmen

  • Artikel

Kapitel 11: Zusätzliche Gegenmaßnahmen

In diesem Kapitel wird die Implementierung von zusätzlichen Gegenmaßnahmen, wie z. B. der Kontosicherung, beschrieben. Das Kapitel enthält außerdem allgemeine Hintergrundinformationen, Verweise auf weiterführende Informationen sowie Konfigurationsanleitungen zur Verwendung von IP-Sicherheitsfiltern (IPSec-Filterung) als effektive Maßnahme gegen Netzwerkangriffe.

Auf dieser Seite

Absicherungsverfahren für Mitgliedsserver
Konfigurieren der Windows-Firewall
Weitere Informationen

Absicherungsverfahren für Mitgliedsserver

Obwohl die meisten der in diesem Handbuch erläuterten Gegenmaßnahmen über Gruppenrichtlinien angewendet werden können, gibt es zusätzliche Einstellungen, bei denen dies nur schwer oder gar nicht möglich ist. Die folgenden Abschnitte enthalten Anleitungen zur Implementierung dieser zusätzlichen Einstellungen für Domänenmitgliedsserver.

Sichern von Konten

Microsoft® Windows Server™ 2003 mit Service Pack 1 (SP1) verfügt über eine Reihe von vordefinierten Benutzerkonten, die nicht gelöscht, aber umbenannt werden können. Die zwei bekanntesten vordefinierten Konten in Windows Server 2003 sind die Konten „Gast“ und „Administrator“.

Sicherheitsanfälligkeit

Das Konto „Gast“ ist auf Mitgliedsservern und Domänencontrollern standardmäßig deaktiviert. Diese Konfiguration sollte nicht geändert werden. Viele verschiedene schädliche Codes verwenden das vordefinierte Administratorkonto bei einem ersten Versuch, einen Server anzugreifen. Daher sollten Sie das vordefinierte Administratorkonto umbenennen und seine Beschreibung ändern, damit Sie Angriffen auf Remoteserver vorbeugen, bei denen versucht wird, dieses bekannte Konto zu verwenden.

Die Auswirkung dieser Konfigurationsänderung hat sich in den letzten Jahren nach dem Auftreten von Angriffstools verringert, die durch Angabe der Sicherheits-ID (SID) des vordefinierten Administratorkontos dessen wahren Namen in Erfahrung bringen und dadurch Zugriff auf den Server erhalten. Eine Sicherheits-ID ist ein Wert, der jeden Benutzer, jede Gruppe, jedes Computerkonto und jede Anmeldesitzung bei einem Netzwerk eindeutig identifiziert. Die Sicherheits-ID dieses vordefinierten Kontos kann nicht geändert werden.

Gegenmaßnahme

Benennen Sie das Konto „Administrator“ auf jedem Server um, und verwenden Sie als Kennwort einen langen und komplexen Wert.

Hinweis: Das vordefinierte Administratorkonto kann durch eine Gruppenrichtlinie umbenannt werden. Diese Einstellung wird nicht über die im Windows Server 2003-Sicherheitshandbuch enthaltenen Baseline-Richtlinien implementiert, da jede Organisation einen eindeutigen Namen für dieses Konto auswählen sollte. Konfigurieren Sie zum Umbenennen des Kontos die Einstellung Administratorkonto umbenennen in der Gruppenrichtlinie unter:
Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\
Sicherheit\Optionen
Idealerweise sollten auf den einzelnen Servern verschiedene Kennwörter eingerichtet werden. Der damit verbundene Verwaltungsaufwand ist allerdings beträchtlich. Wenn jedoch in einer Organisation auf allen Servern dieselben Kontonamen und Kennwörter verwendet werden, kann ein Angreifer, dem das Kennwort eines Mitgliedsservers bekannt ist, sofort auf alle anderen Server zugreifen. Notieren Sie die vorgenommenen Änderungen, und bewahren Sie diese Informationen an einem sicheren Ort auf.

Mögliche Auswirkung

Die für die Verwaltung der Systeme verantwortlichen Benutzer müssen sorgfältig notieren, welcher Kontoname den einzelnen Computern zugewiesen ist. Benutzer, die sich über das lokale Administratorkonto bei einem bestimmten Server anmelden müssen, benötigen diese Sicherheitsunterlagen, um den Benutzernamen und das Kennwort für den Server zu erfahren.

NTFS

Die NTFS-Einstellungspartitionen unterstützen Zugriffssteuerungslisten (ACLs, Access Control Lists) und optional die Verschlüsselung auf Datei- und Ordnerebene über das verschlüsselnde Dateisystem (EFS, Encrypting File System). Diese Unterstützung ist nicht verfügbar für die Dateizuordnungstabelle (File Allocation Table, FAT), FAT32 oder FAT32x-Dateisysteme. FAT32 ist eine aktualisierte Version des FAT-Dateisystems, die nun erheblich kleinere Clusterstandardgrößen zulässt und Festplatten mit bis zu 2 TB unterstützt. FAT32 ist in Microsoft Windows® 95 OSR2, Windows 98, Windows ME, Windows Server 2003 und Windows XP enthalten.

Sicherheitsanfälligkeit

Dateien, die nicht durch Zugriffssteuerungslisten geschützt werden können, können von nicht autorisierten Benutzern leicht angezeigt, geändert oder gelöscht werden. Dabei spielt es keine Rolle, ob die Benutzer lokal oder über ein Netzwerk auf diese Dateien zugreifen. Andere Dateien können durch Zugriffssteuerungslisten geschützt werden. Durch Verschlüsselung kann jedoch ein höheres Maß an Sicherheit erzielt werden, insbesondere dann, wenn es sich um Dateien handelt, die nur von einem einzelnen Benutzer verwendet werden.

Gegenmaßnahme

Formatieren Sie alle Partitionen auf jedem Server mit NTFS. Verwenden Sie das Konvertierungsdienstprogramm, um FAT-Partitionen in NTFS zu konvertieren. Denken Sie daran, dass durch das Konvertierungsdienstprogramm die Zugriffssteuerungslisten für das konvertierte Laufwerk auf „Jeder: Vollzugriff“ gesetzt werden.

Für Windows Server 2003- und Windows XP-basierte Computer wenden Sie lokal die folgenden Sicherheitsvorlagen an, um die Zugriffssteuerungslisten für das Standarddateisystem zu konfigurieren:

  • Für Arbeitsstationen: %windir%\inf\defltwk.inf

  • Für Server: %windir%\inf\defltsv.inf

  • Für Domänencontroller: %windir%\inf\defltdc.inf

Anleitungen zur lokalen Anwendung von Sicherheitsvorlagen finden Sie in Kapitel 12, „Die Bastion-Hostrolle“, im Windows Server 2003-Sicherheitshandbuch.

Hinweis: Die Standardsicherheitseinstellungen für Domänencontroller werden während der Heraufstufung eines Servers zum Domänencontroller angewendet.

Mögliche Auswirkung

Es gibt keine negativen Auswirkungen.

Wichtig: Ordnungsgemäß konfigurierte NTFS-Berechtigungen schützen die Daten Ihrer Organisation vor Offenlegung und nicht autorisierten Änderungen. Allerdings muss auch die physische Sicherheit bedacht werden. Wenn ein Angreifer physischen Zugriff auf einen Computer hat, kann er mit einer startfähigen CD-ROM oder einer Diskette ein anderes Betriebssystem verwenden. Wenn ein Angreifer eine Festplatte aus einem Computer Ihrer Organisation entfernt, kann die Festplatte in einem anderen, nicht verwalteten Computer verwendet werden. Sobald ein Angreifer physischen Zugriff auf ein Speichermedium hat, können die enthaltenen Daten kaum noch geschützt werden.

Dies ist ein grundsätzliches Problem der Computersicherheit, das auch bei den Dateisystemen anderer Betriebssysteme vorhanden ist. Sobald der Angreifer physischen Zugriff auf die Festplatte hat, können NTFS-Berechtigungen und die meisten anderen Sicherheitsmaßnahmen leicht umgangen werden. Es gibt eine Reihe von nahe liegenden physischen Sicherheitsmaßnahmen, die in einer Organisation implementiert werden können, z. B. Gebäudezugangsbeschränkungen, Magnetsperren an Serverraumtüren, Sperren an Serverracks sowie Sperren an Dockingstationen zur sicheren Aufbewahrung von Laptops. Darüber hinaus empfiehlt Microsoft die folgenden zusätzlichen Technologien, mit denen die Auswirkungen derartiger Angriffe verringert werden können:

  • Verwenden Sie SYSKEY mit einem Offlinekennwort, um zu verhindern, dass nicht autorisierte Personen das Windows-Betriebssystem starten können.

  • Verwenden Sie EFS zum Verschlüsseln von Benutzerdaten. Weisen Sie die Benutzer an, ihre Domänenkonten zu verwenden und entweder keinen Wiederherstellungs-Agenten zu konfigurieren oder den Wiederherstellungs-Agenten nicht für das lokale Administratorkonto, sondern für Domänenadministratorkonten zu konfigurieren.

  • Verwenden Sie BIOS-Kennwörter, um zu verhindern, dass nicht autorisierte Benutzer Computer in Ihrer Organisation starten können.

  • Legen Sie im BIOS fest, dass Computer nicht von Diskette oder CD-ROM gestartet werden können. Durch diese Konfiguration wird verhindert, dass nicht autorisierte Benutzer den Computer mit einem eigenen Betriebssystem starten können.

Trennen von Daten und Anwendungen

Es wird schon seit langem empfohlen, Daten, Anwendungen und Betriebssystemdateien auf separaten Speichermedien zu speichern, um die Computerleistung zu erhöhen. Wenn Sie diese Dateitypen auf Servern separat speichern, können Sie die Anwendungen, Daten und Betriebssysteme auch vor Directory-Traversal-Angriffen schützen.

Sicherheitsanfälligkeit

Es können zwei Arten von Sicherheitsanfälligkeiten entstehen, wenn Anwendungen, Daten und Protokolldateien auf demselben Speichermedium wie das Betriebssystem gespeichert werden. Eine Sicherheitsanfälligkeit besteht darin, dass Benutzer eine Anwendungsprotokolldatei versehentlich oder absichtlich mit Daten füllen oder Dateien auf den Server hochladen und das Speichermedium auf diese Weise mit Daten füllen.

Die zweite Sicherheitsanfälligkeit stellen die so genannten Directory-Traversal-Angriffe dar, bei denen ein Angreifer aufgrund von Schwachstellen in einem Netzwerkdienst durch die Verzeichnisstruktur navigieren und bis in das Stammverzeichnis des Systemlaufwerks gelangen kann. Von dort aus ist es einem Angreifer möglich, die Ordner mit den Betriebssystemdateien zu durchsuchen und Programme über den Remotezugriff auszuführen.

Es gibt mittlerweile mehrere tausend Variationen dieser Directory-Traversal-Angriffe, die Anwendungen und Betriebssysteme bedrohen. IIS war in den letzen Jahren mehreren solcher Angriffe ausgesetzt. Beispiele hierfür sind die Würmer NIMDA und CODE RED, die einen Pufferüberlauf ausgenutzt haben, um die Verzeichnisstrukturen von Websites zu durchlaufen. Anschließend wurde über den Remotezugriff das Programm „Cmd.exe“ ausgeführt, um auf eine Remoteshell zuzugreifen und weitere Befehle auszuführen.

Gegenmaßnahme

Verschieben Sie wann immer möglich Webdokumente, Anwendungen, Daten und Anwendungsprotokolldateien in eine vom Systemdatenträger getrennte Partition.

Mögliche Auswirkung

Für Organisationen, die ihre Server einheitlich erstellen und verwalten, sind die Auswirkungen gering. Für Organisationen, die diese Informationen nicht verwalten, sind die Auswirkungen etwas größer, da die Administratoren erst herausfinden müssen, wie die einzelnen Computer eingerichtet sind.

Konfigurieren des SNMP-Communitynamens

SNMP (Simple Network Management Protocol) ist ein Netzwerkmanagement-Standardprotokoll, das in TCP/IP-Netzwerken häufig verwendet wird. Mit SNMP können Netzwerkknotenserver (z. B. Server, Arbeitsstationen, Router, Bridges und Hubs) über einen zentralen Host verwaltet werden. SNMP führt Verwaltungsdienste über eine aus Verwaltungssystemen und Agenten bestehende, verteilte Architektur aus. Computer, die Netzwerkverwaltungssoftware ausführen, werden als SNMP-Managementsysteme oder SNMP-Manager bezeichnet. Verwaltete Netzwerkknoten werden als SNMP-Agenten bezeichnet.

Der SNMP-Dienst bietet eine sehr einfache Form der Sicherheit durch Communitynamen und Authentifizierungstraps. Sie können die SNMP-Kommunikation für Agenten einschränken und nur die Kommunikation mit bestimmten SNMP-Verwaltungssystemen zulassen. Darüber hinaus können Communitynamen zur Authentifizierung von SNMP-Nachrichten verwendet werden. Obwohl ein Host in mehreren Communitys gleichzeitig Mitglied sein kann, werden vom Agenten nur SNMP-Nachrichten akzeptiert, die von einem Verwaltungssystem stammen, das in der Liste der akzeptierten Communitys enthalten ist. Es gibt keinen Zusammenhang zwischen den Communitynamen, Domänennamen und Arbeitsgruppennamen. Communitynamen stellen in gewisser Weise ein Kennwort dar, das von SNMP-Verwaltungskonsolen und verwalteten Computern gemeinsam verwendet wird. Es ist Ihre Aufgabe als Systemadministrator, bei der Installation des SNMP-Dienstes den Namen so zu wählen, dass er nicht einfach zu erraten ist.

Sicherheitsanfälligkeit

Das SNMP-Protokoll ist in seinem Aufbau kaum auf Sicherheit ausgelegt. Die größte Sicherheitsanfälligkeit im SNMP-Protokoll besteht darin, dass nahezu alle Hersteller von Komponenten einen Standardnamen für die Community einrichten und diese standardmäßigen Communitynamen allgemein bekannt sind. Bei Microsoft wird z. B. der Standardname „Public“ verwendet.

Eine zweite Sicherheitsanfälligkeit ist schwieriger zu bekämpfen. Bei der SNMP-Kommunikation werden Communitynamen immer als Klartext gesendet. Wenn ein SNMP-Verwaltungsgerät eine Verbindung mit einem SNMP-Client hergestellt hat, ist bei der Übertragung von SNMP-Nachrichten der Communityname zu sehen, da er nicht verschlüsselt oder gehasht wird. Sie können diese zweite Sicherheitsanfälligkeit beseitigen, indem Sie den Datenverkehr zwischen den Servern vollständig verschlüsseln. Diese Gegenmaßnahme würde allerdings den Rahmen dieser Anleitung sprengen.

Gegenmaßnahme

Legen Sie für den SNMP-Communitynamen für Lesezugriff auf allen Computern einen zufällig erzeugten alphanumerischen Wert fest.

So konfigurieren Sie den SNMP-Communitynamen

  1. Doppelklicken Sie in der Konsole „Dienste“ auf SNMP-Dienst.

  2. Klicken Sie im Dialogfeld Eigenschaften des SNMP-Dienstes auf die Registerkarte Sicherheit.

  3. Wählen Sie in der Liste Akzeptierte Communitynamen die Option Öffentlich.

  4. Klicken Sie auf die Schaltfläche Bearbeiten, und geben Sie anschließend im Dialogfeld SNMP-Dienst Communityname den neuen Communitynamen ein.

  5. Klicken Sie auf OK, um die Dialogfelder zu schließen.

Lassen Sie den Schreibzugriff über SNMP deaktiviert.

Hinweis: Der Communityname wird in der Registrierung als DWORD-Eintrag mit dem Wert 4 gespeichert. Somit ist es möglich, diese Änderung zu automatisieren, indem Sie entweder ein Skript erstellen oder der Sicherheitsvorlage eine Zeile hinzufügen und die Vorlage in eine domänenbasierten Gruppenrichtlinie importieren. Der Wert wird unter HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities gespeichert.

Mögliche Auswirkung

Der Communitystring muss auch in allen Verwaltungstools, die das SNMP-Protokoll verwenden, entsprechend konfiguriert werden.

Deaktivieren von NetBIOS und SMB auf öffentlich zugänglichen Schnittstellen

Dieser Abschnitt enthält spezielle Empfehlungen für Server, die sich in Netzwerken befinden, die nicht vollständig kontrolliert werden können. Dazu zählen z. B. öffentlich zugängliche Webserver und E-Mail-Gateways. Derartige Server werden auch als Bastion-Hosts bezeichnet. Wenn Sie über solche Server verfügen, sollten Sie die Anwendung der in dieser Gegenmaßnahme empfohlenen Verfahren in Erwägung ziehen. Sie sollten jedoch jede Änderung gründlich testen und sich bewusst machen, welche Hausforderung die Verwaltung von Computern darstellt, auf denen NetBIOS deaktiviert wurde.

Sicherheitsanfälligkeit

Zur Sicherung eines Bastion-Hosts können Sie seine Angriffsfläche erheblich verringern, indem Sie SMB (Server Message Block) und „NetBIOS über TCP/IP“ deaktivieren. Die Verwaltung der unter dieser Konfiguration betriebenen Server ist schwierig. Außerdem können diese Server nicht auf freigegebene Ordner im Netzwerk zugreifen. Diese Maßnahmen bieten jedoch wirksamen Schutz vor Angriffen über SMB- und NetBIOS-Protokolle. Deaktivieren Sie daher die SMB und „NetBIOS über TCP/IP“ für Netzwerkverbindungen auf Servern, auf die über das Internet zugegriffen werden kann.

Gegenmaßnahme

Die SMB-Kommunikation wird nicht verhindert, wenn Sie NetBIOS deaktivieren. SMB verwendet bei fehlenden NetBIOS-Standardports den TCP-Port 445, der als SMB-Direkthost (SMB Direct Host) oder als CIFS-Port (Common Internet File System Port) bezeichnet wird. Daher müssen explizite Schritte durchgeführt werden, um sowohl NetBIOS als auch SMB einzeln zu deaktivieren.

NetBIOS verwendet die folgenden Ports:

  • UDP/137 (NetBIOS-Namensdienst)

  • UDP/138 (NetBIOS-Datagrammdienst)

  • TCP/139 (NetBIOS-Sitzungsdienst)

SMB verwendet die folgenden Ports:

  • TCP/139

  • TCP/445

Führen Sie auf Servern, auf die über das Internet zugegriffen werden kann, die folgenden Schritte durch, um die Datei- und Druckerfreigabe für Microsoft-Netzwerke und den Client für Microsoft-Netzwerke zu entfernen.

So deaktivieren Sie SMB

  1. Doppelklicken Sie in der Systemsteuerung auf Netzwerkverbindungen.

  2. Klicken Sie mit der rechten Maustaste auf eine Internetverbindung, und klicken Sie dann auf Eigenschaften.

  3. Wählen Sie im Dialogfeld Eigenschaften die Option Client für Microsoft-Netzwerke, und klicken Sie dann auf Deinstallieren.

  4. Befolgen Sie die Schritten zum Deinstallieren.

  5. Wählen Sie Datei- und Druckerfreigabe für Microsoft Netzwerke, und klicken Sie dann auf Deinstallieren.

  6. Befolgen Sie die Schritten zum Deinstallieren.

So deaktivieren Sie NetBIOS über TCP/IP

  1. Doppelklicken Sie in der Systemsteuerung auf System, klicken Sie auf die Registerkarte Hardware und anschließend auf die Schaltfläche Geräte-Manager.

  2. Klicken Sie im Menü Ansicht auf Ausgeblendete Geräte anzeigen.

  3. Erweitern Sie Nicht-PnP-Treiber.

  4. Klicken Sie mit der rechten Maustaste auf NetBIOS über Tcpip und anschließend auf Deaktivieren.

Dadurch wird der SMB-Direkthost-Listener auf TCP/445 und UDP 445 deaktiviert.

Hinweis: Durch diese Vorgehensweise wird der Treiber Nbt.sys deaktiviert. Obwohl der NetBIOS-Sitzungsdienst deaktiviert wird, der den TCP-Port 139 zum Abhören verwendet, wird SMB dadurch nicht vollständig deaktiviert. Führen Sie zur vollständigen Deaktivierung die Schritte im Abschnitt „So deaktivieren Sie SMB“ durch (weiter oben in diesem Kapitel).

Mögliche Auswirkung

Kein Computer kann über SMB eine Verbindung mit dem Server herstellen. Die Server können nicht auf Ordner zugreifen, die im Netzwerk gemeinsam verwendet werden. Verwaltungstools, für die eine NetBIOS- oder SMB-Verbindung erforderlich ist, können keine Verbindung mit den Servern herstellen.

Konfigurieren des Ports für Terminaldienste

Terminaldienste sind ein nützliches Werkzeug für Netzwerkadministratoren, um auf Remoteserver zugreifen und Endbenutzercomputer verwalten zu können. Der Remotedesktopclient wird standardmäßig auf allen Windows Server 2003- und Windows XP-Computern installiert und steht als optionale Komponente auf den Installationsmedien für Windows 2000 Server zur Verfügung. Es kann auch ein Microsoft ActiveX®-Client heruntergeladen werden, der in Internet Explorer oder Microsoft Management Console (MMC) ausgeführt wird. Der Remotedesktopclient und der ActiveX-Client werden auch als Terminal Services Advanced Clients (TSAC) bezeichnet.

Sicherheitsanfälligkeit

Die Terminaldienste von Microsoft verwenden in der Standardeinstellung zum Abhören den TCP-Port 3389. Alle Remotedesktopclients versuchen, eine Verbindung mit diesem Port herzustellen. Obwohl die Sitzung (einschließlich der Benutzerauthentifizierung) vollständig verschlüsselt ist, wird durch die Terminaldiensteclients keine Serverauthentifizierung durchgeführt. Wenn es einem Angreifer gelingt, durch Spoofing einen legitimen Terminaldiensteserver vorzutäuschen, besteht die Gefahr, dass Benutzer eine Verbindung mit dem Server des Angreifers (statt mit dem echten Server) herstellen. Der Angreifer kann hierzu die DNS-Einträge ändern, um Benutzer auf den eigenen Server umzuleiten. Dasselbe Ergebnis kann auch auf andere Weise erzielt werden.

Gegenmaßnahme

Ändern Sie den TCP-Port, der von den Terminaldiensten verwendet wird, oder implementieren Sie eine IPSec-Richtlinie, um eine gesicherte Verbindung über Authentification Header (AH) oder Encapsulation Security Payload (ESP) im IPSec-Transportmodus (nicht IPSec-Tunnelmodus) zu erzwingen. In einigen Szenarien kann der Terminalserver hinter einem VPN-Gateway isoliert werden, damit entweder das Point-to-Point-Tunnel-Protokoll (PPTP) oder L2TP/IPSec-gesicherte VPN-Tunnel für den Zugriff auf den Terminalserver erforderlich sind.

Weitere Informationen zur Ändern des Ports, der von Terminaldiensten und dem Remotedesktopclient verwendet wird, finden Sie im Microsoft Knowledge Base-Artikel „Ändern des Abhörports des Terminal Servers“ unter https://support.microsoft.com/?scid=187623. In diesem Artikel wird erläutert, wie der Abhörport für den regulären Desktopclient geändert wird. Wenn die Einstellungen für den TSAC-Webclient geändert werden sollen, müssen Sie die folgende Skriptzeile in die Webseite einfügen:

MsRdpClient.RDPport = xxx

(„xxx“ steht hierbei für den bevorzugten TCP-Port.) Weitere Informationen zur Verwendung und Anpassung von Remotedesktop-Webverbindungen, die Terminaldienstesitzungen in Microsoft Internet Explorer ausführen, finden Sie im Abschnitt „Sicherheit von RDP-Clients“ (in englischer Sprache) unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/termserv/termserv/
providing_for_rdp_client_security.asp.

Mögliche Auswirkung

Die Implementierung von IPSec mit AH hat nur geringe Auswirkungen auf die Computerleistung. Es entsteht jedoch ein zusätzlicher Aufwand, da die IPSec-Konfiguration für Clients und Server verwaltet werden muss. Darüber hinaus entsteht ein zusätzlicher Aufwand bei der Verwaltung einer gegenseitigen Vertrauensstellung zwischen Client- und Servercomputern, die von der IKE-Sicherheitsaushandlung (Internet Key Exchange) verwendet wird, bevor die Sicherheitszuordnungen eingerichtet werden. Die IPSec-Richtlinie sollte so eingerichtet werden, dass der gesamte Datenverkehr zum Server geschützt wird, oder dass IPSec nur für Verbindungen zum TCP-Port 3389 erforderlich ist. Wenn IPSec auf dem Server erforderlich ist, wird der Zugriff für Clientcomputer verweigert, die keine kompatible IPSec-Konfiguration aufweisen und nicht das erforderliche Vertrauen genießen. Weitere Informationen zur Verwendung von IPSec-Richtlinien zur Aushandlung der Sicherheit für TCP/IP-Datenverkehr finden Sie im Abschnitt „Konfigurieren von IPSec-Richtlinien“ weiter unten in diesem Kapitel.

Wenn Sie die Standardports für Terminaldiensteserver und -clients ändern, können legitime Benutzer, deren Clientsoftware nicht für die Verwendung des neuen Ports konfiguriert ist, keine Verbindung mit den Computern herstellen, deren Portzuweisungen geändert wurden. Darüber hinaus wird in der aktuellen Version von TSAC der Wechsel des TCP-Ports nicht unterstützt.

Deaktivieren von Dr. Watson: Automatische Ausführung des Dr. Watson-Systemdebuggers deaktivieren

Systemdebugger erleichtern die Problembehandlung bei Computern und Anwendungen. Diese Programme sammeln Daten, die sie dem Systemadministrator oder Anwendungsentwickler zur Verfügung stellen, während der Computer in Betrieb ist. Beim in Windows Server 2003 und Windows XP enthaltenen Tool „Dr. Watson“ handelt es sich um einen automatisierten Systemdebugger, der Informationen zum Systemstatus und zu den bei Auftreten eines Programmfehlers ausgeführten Anwendungen erfasst.

Sicherheitsanfälligkeit

In einigen Organisationen ist die Installation von Debuggern auf wichtigen Computern in der Produktionsumgebung möglicherweise nicht angebracht. Derzeit sind keine mit Dr. Watson in Zusammenhang stehenden Schwachstellen bekannt, die von Benutzern ohne Administratorrechte ausgenutzt werden können. Dies bedeutet, dass ein Angreifer zur lokalen Gruppe Administratoren gehören muss, um Dr. Watson als Angriffstool gegen andere Benutzer oder Prozesse verwenden zu können. Ein Angreifer, der bereits Administratorrechte besitzt, hat vollständige Kontrolle über den Computer und kann den Computer im Falle der Deaktivierung von Dr. Watson auf andere Weise beinträchtigen.

Gegenmaßnahme

Eine Anleitung zum Deaktivieren des Dr. Watson-Systemdebuggers finden Sie im Microsoft Knowledge Base-Artikel „Deaktivieren von Dr. Watson für Windows“ unter https://support.microsoft.com/?kbid=188296.

Mögliche Auswirkung

Bei einem Programmabsturz erfolgt keine Ausführung des Systemdebuggers und keine automatische Berichterstellung. Für die Problemursachendiagnose stehen Systemadministratoren und Entwicklern weniger Informationen zur Verfügung, und die Fehlerberichterstattungsfunktion ist deaktiviert.

SSDP/UPnP deaktivieren: SSDP/UPnP deaktivieren

Bei Deaktivierung des Hostdienstes für universelles Plug & Play (UPnP™) können andere Anwendungen (z. B. Windows Messenger) weiterhin den SSDP-Suchdienst (Simple Service Discovery Protocol) verwenden, um Netzwerkgateways oder andere Netzwerkgeräte zu identifizieren.

Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel „Verkehr wird nach Abschalten des SSDP-Erkennungsdienstes und des Universal Plug & Play-Gerätehosts gesendet“ (in englischer Sprache) unter https://support.microsoft.com/kb/317843/en-us.

Sicherheitsanfälligkeit

Die in Windows XP und Windows Server 2003 enthaltenen UPnP-Funktionen können für private Benutzer und kleine Unternehmen äußerst nützlich sein, da die Installation und Konfiguration von UPnP-Geräten mit diesen Funktionen automatisiert werden kann, wenn diese Geräte mit dem lokalen Netzwerk verbunden sind. In einigen Organisationen muss möglicherweise sichergestellt werden, dass kein UPnP- oder SSDP-Datenverkehr im Netzwerk stattfindet. Derzeit sind zwar keine mit diesen Funktionen in Zusammenhang stehenden Sicherheitsanfälligkeiten bekannt, vor ein paar Jahren wurde jedoch ein schwerwiegendes Problem in Windows XP festgestellt, für dessen Behebung ein Hotfix angewendet werden musste.

Gegenmaßnahme

Um sicherzustellen, dass keine Anwendung die in Windows XP enthaltenen SSDP- und UPnP-Funktionen verwendet, können Sie den REG_DWORD-Registrierungswert „UPnPMode“ dem folgenden Registrierungsschlüssel hinzufügen:

HKEY_LOCAL_MACHINE\Software\Microsoft\DirectPlayNATHelp\DPNHUPnP\

Legen Sie dann für UPnPMode den Wert 2 fest.

Mögliche Auswirkung

UPnP- und SSDP-Funktionen werden vollständig deaktiviert. Wenn UPnP-Geräte mit dem Netzwerk verbunden sind, müssen sie manuell konfiguriert und verwaltet werden.

Konfigurieren von IPSec-Richtlinien

IPSec (verfügbar für die Betriebssysteme Windows 2000, Windows XP und Microsoft Windows Server 2003) ist ein Tool, mit dem Netzwerkadministratoren den TCP/IP-Datenverkehr zulassen bzw. blockieren oder die Sicherheit für den TCP/IP-Datenverkehr aushandeln können. IPSec ist anwendungsunabhängig und für Anwendungen transparent. Entwurfsziel für Windows 2000 war es, eine Möglichkeit zu bieten, den Netzwerkdatenverkehr mit dem AH- oder dem ESP-Format des IPSec-Protokolls zu sichern. In IPSec-Richtlinien werden statische TCP/IP-Filter verwendet, die auch als Selektoren bezeichnet werden und für die Aushandlung der Sicherheit über IKE notwendig sind.

Ausführliche Informationen zu den neuesten IPSec-Funktionen finden Sie in Kapitel 6, „Bereitstellen von IPSec“, des Windows Server 2003 Deployment Kit: Bereitstellen von Netzwerkdiensten (in englischer Sprache). Im Abschnitt „Determining Your IPSec Needs“ werden die Einsatzmöglichkeiten von IPSec beschrieben. Das Deployment Kit kann unter www.microsoft.com/downloads/details.aspx?
FamilyID=d91065ee-e618-4810-a036-de633f79872e&DisplayLang=en heruntergeladen werden.

Bei den meisten Anwendungen bietet die Windows-Firewallkomponente angemessenen Schutz auf Hostebene gegen schädlichen eingehenden Datenverkehr. Mit dem Sicherheitskonfigurations-Assistenten (SCW, Security Configuration Wizard) unter Windows Server 2003 mit SP1 wird das Einrichten und Verwalten der Windows-Firewalleinstellungen für umfangreiche Bereitstellungen erheblich vereinfacht. IPSec sollte nach Möglichkeit zur Sicherung des Host-to-Host-Datenverkehrs und des Host-Client-Datenverkehrs verwendet werden. Die Windows-Firewall sollte in den meisten Organisationen auf breiter Ebene als zusätzlicher Schutz bereitgestellt werden.

Sicherheitsanfälligkeit

Obwohl viele Netzwerk-Sicherheitsstrategien ihr Hauptaugenmerk auf die Verhinderung von Angriffen von außerhalb legen, müssen vertrauliche Informationen zusätzlich gegen interne Angriffe geschützt werden, bei denen Daten auf dem Netzwerk interpretiert oder Design- und Implementierungsschwächen in Protokollen auf höherer Ebene ausgenutzt werden, um Zugriff auf einen Computer zu erlangen. Angreifer können z. B. so genannte NetBT-Nullsitzungen verwenden, um Informationen zu erhalten, mit denen Administratorkennwörter manipuliert werden können (wenn keine anderen Sicherheitseinstellungen verwendet werden oder versehentlich deaktiviert wurden).

Die Angreifer müssen nur eine Sicherheitsanfälligkeit in einem einzigen Anwendungsport ausfindig machen, um Zugriff erlangen und u. U. die vollständige Kontrolle über den Computer übernehmen zu können. Wie bereits ausgeführt, werden viele Datentypen bei der Übertragung im Netzwerk nicht geschützt. Das bedeutet, dass Mitarbeiter, Mitglieder der Supportabteilung oder Besucher die Daten kopieren können, um sie später zu analysieren. Firewalls zwischen dem internen Netzwerk und dem externen Internet bieten keinen Schutz vor diesen internen Bedrohungen. Interne Firewalls bieten häufig keine authentifizierten Zugriffssteuerungen, um die Clients und Server zu schützen. Sie können auch keine End-to-End-Sicherheit für den Netzwerkverkehr zwischen den Computern gewährleisten.

Gegenmaßnahme

IPSec-Filter erkennen TCP/IP-Datenverkehr anhand der Quell- und Ziel-IP-Adresse, des IP-Protokolltyps und des TCP/UDP-Ports. IPSec-Filter können die Verbreitung von schädlichem Code durch Blockieren von Wurm- und Virusdatenverkehr eindämmen und kontrollieren. Außerdem kann IPSec es Angreifern erschweren, Remoteshells oder andere Angriffstools zu verwenden, um über eine manipulierte Anwendung Zugriff auf den Computer zu erhalten. Weitere Informationen zur Anwendung von IPSec-Richtlinien unter Windows 2000 zum Sperren von Ports finden Sie im Microsoft Knowledge Base-Artikel „Blockieren bestimmter Netzwerkprotokolle und Ports mithilfe von IPSec“ unter https://support.microsoft.com/?scid=813878. Darüber hinaus enthält das Whitepaper „Verwenden von IPSec zum Sperren eines Servers“ (in englischer Sprache) unter www.microsoft.com/technet/itsolutions/network/security/ipsecld.mspx eine ausführliche Anleitung zur Konfiguration von IPSec-Filtern unter Windows Server 2003 ähnlich der vorliegenden Anleitung. Für Windows 2000 sollten Sie jedoch die im Knowledge Base-Artikel empfohlenen NoDefaultExempt-Registrierungseinstellungen hinzufügen.

Windows Server 2003 stellt mit dem MMC-Snap-In für die IPSec-Richtlinienverwaltung eine grafische Benutzeroberfläche zur Verfügung, mit der die IPSec-Richtlinien verwaltet werden können. Dieses Tool ist dem Tool unter Windows 2000 und Windows XP sehr ähnlich. Unter Windows Server 2003 stehen das MMC-Snap-In „IPSec-Monitor“ und das Befehlszeilendienstprogramm „NETSH IPSec“ zur Verfügung, um die auf dem Computer angewendeten IPSec-Richtlinienfilter anzuzeigen. Filter zum Zulassen bzw. Blockieren werden in der IKE-Schnellmoduskonfiguration angezeigt. Die generischen IKE-Schnellmodusfilter sind die in der zugewiesenen IPSec-Richtlinie definierten Filter. IKE-Schnellmodus-spezifische Filter ergeben sich aus der Anwendung der Richtlinie auf die jeweilige IP-Konfiguration des Computers. Mit der Funktion „Übereinstimmende Filter suchen“ für IKE-Schnellmodus-spezifische Filter kann nur nach Filtern gesucht werden, die Sicherheit aushandeln. Die Funktion kann nicht verwendet werden, um nach Filtern zum Zulassen bzw. Blockieren zu suchen.

Im übrigen Teil dieses Abschnitts werden die folgenden Begriffe erläutert:

  • Filterliste. Enthält Ports, Protokolle, und Datenverkehrsrichtungen. Eine Filterliste löst eine Aktion aus, wenn der Datenverkehr einem in der Liste angegebenen Kriterium entspricht. Eine Liste kann mehrere Filter enthalten.

  • Filteraktion. Die Aktion, die ausgeführt wird, wenn der Datenverkehr die Kriterien in einer Filterliste erfüllt. Mögliche Aktionen sind z. B. das Blockieren bzw. Zulassen von bestimmtem Datenverkehr.

  • Regel. Eine Regel ist die Wechselbeziehung zwischen einer Filterliste und einer Filteraktion.

  • IPSec-Richtlinie. Eine Regelsammlung. Es kann immer nur eine Richtlinie aktiv sein.

Eine einfache Möglichkeit zum Aufzeichnen dieser Informationen ist eine so genannte Netzwerkdatenverkehrstabelle. Eine Netzwerkdatenverkehrstabelle enthält Informationen zu Serverrolle, Richtung des Netzwerkdatenverkehrs, Datenverkehrsziel, IP-Adresse der Schnittstelle, IP-Protokoll, TCP-Port und UDP-Port (User Datagram Protocol). Ein Beispiel für eine Netzwerkdatenverkehrstabelle ist in der folgenden Tabelle abgebildet.

Anhand einer Netzwerkdatenverkehrstabelle können Sie den ein- und ausgehenden Datenverkehr von bestimmten Servern leicht erkennen. Vor der Erstellung von IPSec-Richtlinien müssen Sie sich unbedingt bewusst machen, welche Art von Datenverkehr für das ordnungsgemäße Funktionieren des Servers erforderlich ist. Andernfalls besteht die Gefahr, dass zu starke Filter erstellt werden und bestimmte Anwendungen nicht mehr ausgeführt werden können.

So erstellen Sie eine Datenverkehrstabelle

  1. Bestimmen Sie die wichtigen Netzwerkdienste, die für die Serverrolle erforderlich sind.

  2. Identifizieren Sie die Protokolle und Ports, die für die einzelnen Dienste erforderlich sind. Sie können den Netzwerkmonitor verwenden, um den Netzwerkdatenverkehr zu erfassen und die Zieladressen, Protokolle und Ports zu bestimmen. Darüber hinaus können Sie Tools zur Anzeige von offenen Ports und aktiven Verbindungen verwenden, z. B. den Befehl „Netstat.exe“.

  3. Dokumentieren Sie die IPSec-Filterregeln, die notwendig sind, um nur den identifizierten Datenverkehr zuzulassen.

Beginnen Sie mit den IPSec-Filtern mit den meisten Einschränkungen. Öffnen Sie je nach Bedarf zusätzliche Ports, um mit diesen Einstellungen ein Höchstmaß an Sicherheit zu erreichen. Dieser Prozess wird wesentlich vereinfacht, wenn Sie eine Unterscheidung zwischen Server- und Clientdiensten vornehmen. Die Serverdienste müssen für alle Dienste definiert werden, die der Computer für andere Hosts zur Verfügung stellt.

Tabelle 11.1: Beispiel für eine Netzwerkdatenverkehrstabelle

Dienst

Protokoll

Quellport

Zielport

Quelladresse

Zieladresse

Aktion

Spiegelung

HTTP-Server

TCP

BELIEBIG

80

BELIEBIG

MEINE

ZULASSEN

JA

HTTPS-Server

TCP

BELIEBIG

443

BELIEBIG

MEINE

ZULASSEN

JA

DNS-Client

TCP

BELIEBIG

53

MEINE

DNS

ZULASSEN

JA

Alles blockieren

BELIEBIG

BELIEBIG

BELIEBIG

BELIEBIG

BELIEBIG

BLOCKIEREN

JA

Im diesem Beispiel für eine Datenverkehrstabelle stellt der Webserver HTTP- und HTTPS-Dienste für Computer mit einer beliebigen IP-Quelladresse zur Verfügung, damit der entsprechende Datenverkehr zugelassen wird. Das Ziel „MEINE“ wird vom IPSec-Dienst als Aufforderung zum Erstellen eines Filters für alle IP-Adressen auf dem Computer interpretiert. Alle Filter werden gespiegelt und ermöglichen somit den Datenverkehr zurück zu dem Computer, von dem die Daten gesendet wurden. Dies bedeutet, dass die HTTP-Serverregel jeglichen Datenverkehr an Port 80 des IIS-Servers zulässt, unabhängig davon, welcher Host und welcher Quellport für die Verbindung verwendet wird. Die Spiegelung dieser Regel gestattet jeglichen TCP-Datenverkehr von Port 80 des IIS-Servers an beliebige Ports und Hosts.

Als Clientdienste stehen alle vom Computer ausgeführten Dienste zur Verfügung, in denen die Richtlinien einen anderen Host verwenden. Der Server im Beispiel für die Datenverkehrstabelle benötigt möglicherweise DNS-Clientdienste, um Suchvorgänge für den Namen einer der Webanwendungen durchzuführen. In diesem Beispiel wurde der Filter erstellt, um Datenverkehr zuzulassen, der an DNS-Server und/oder von DNS-Servern gesendet wird. Windows Server 2003 enthält Richtlinienverbesserungen gegenüber Windows 2000 Server für diesen Konfigurationstyp, um Datenverkehr an DNS-Server und andere Infrastrukturserver zuzulassen. Unter Windows 2000 muss die IPSec-Richtlinie alle IP-Adressen der DNS-Server in der Richtlinie enthalten. Unter Windows Server 2003 können in der Richtlinie logische DNS-Namen verwendet werden. Diese können je nach lokaler IP-Konfiguration des Servers in einen Filter für die IP-Adressen eines DNS-Servers erweitert werden.

Hinweis: IPSec-Richtlinien, in denen diese Windows Server 2003-Funktionen verwendet werden, sollten nicht Windows 2000- oder Windows XP-Computern zugeordnet werden.

Der gespiegelte Blockierungsfilter von einer beliebigen an die eigene IP-Adresse blockiert jeglichen weiteren Unicast-IP-Datenverkehr von und zu allen IP-Adressen auf dem Computer. Dieser Filter ist allgemeiner gehalten als die protokoll- und portspezifischen Filter, die für DNS, HTTP und HTTPS definiert wurden. Die Standardausnahmen für Windows Server 2003 wurden entfernt. Deshalb stimmt dieser Filter mit ausgehenden Multicast- und Broadcastpaketen überein und blockiert sie. Da als Quell-IP die eigene IP-Adresse verwendet wird, stimmt die Zieladresse mit jeder beliebigen IP-Adresse überein. Beachten Sie allerdings, dass eingehender Multicast- und Broadcastdatenverkehr von diesem Filter nicht erfasst wird. Während als Quelladresse eine beliebige IP-Adresse verwendet werden kann, handelt es sich bei der Zieladresse eines Multicast- oder Broadcastpakets nicht um eine auf dem Computer angegebene IP-Adresse, sondern um eine Multicast- oder Broadcast-IP-Adresse. Daher wird eingehender Multicast- oder Broadcastverkehr unter Windows Server 2003 von dieser Regel nicht blockiert. Diese Filterdefinition wird auch von Windows 2000 und Windows XP unterstützt. Allerdings wird nur Unicast-IP-Datenverkehr erfasst. Diese Plattformen wurden nicht mit dem Ziel entworfen, Broadcast- und Multicastpakete auf mögliche Übereinstimmung mit IPSec-Filtern zu vergleichen. Ein- und ausgehende Multicast- und Broadcastpakete werden daher zugelassen, obwohl dieser Filter auf Windows 2000- und Windows XP-Computer angewendet wird.

Die letzte Regel „Alles blockieren“ stellt eine weitere Filterverbesserung unter Windows Server 2003 dar. Diese Regel wird unter Windows 2000 oder Windows XP nicht unterstützt. Die Regel blockiert sowohl eingehende als auch ausgehende Multicast-, Broadcast- und Unicastpakete, die von keinem der anderen Filter erfasst werden. Bei Verwendung dieser Regel wird die vorherige Regel „Beliebige IP-Adressen an meinen Computer“ nicht benötigt.

Wichtig: Bedenken Sie beim Einsatz einer solchen Richtlinie, dass die Computer nicht mit DHCP-Servern, Domänencontrollern, WINS-Servern, Zertifikatsrückruflisten (CRLs) oder Computern, die Server überwachen, kommunizieren können. Außerdem können Administratoren mit dieser Richtlinie keine Remoteverwaltung über RPC-basierte MMC-Snap-Ins oder eine Remotedesktopclient-Verbindung durchführen. Wenn der IIS-Server im Beispiel über zwei Netzwerkschnittstellenkarten verfügt (eine für Internetverkehr und eine für Intranetverkehr), wird sämtlicher Datenverkehr über beide Schnittstellen auf dieselbe Weise gefiltert. Die Richtlinie muss daher an die speziellen Anforderungen in der jeweiligen Produktionsumgebung angepasst werden. Netzwerkdatenverkehr für die Schnittstelle der internen Subnet-IP-Adresse muss anders gefiltert werden als für die Schnittstelle zum Internet. Darüber hinaus sollten wann immer möglich Filterregeln verwendet werden, die von bestimmten Verwaltungsstationen eine IPSec-verschlüsselte Remoteverwaltung erfordern. Dadurch wird verhindert, dass beeinträchtigte Server über die interne Schnittstelle auf andere Server zugreifen oder administrative Netzwerkanmeldedaten für Offlineangriffe missbrauchen können.

Wenn ein Clientdienst erforderlich ist, der nicht auf Verbindungen mit einem bestimmten Zielserver oder eine begrenzte Anzahl von Zielservern eingeschränkt werden kann, wird die Sicherheit durch IPSec-Filter erheblich verringert. Im folgenden Beispiel für eine Netzwerkdatenverkehrstabelle wird eine Regel hinzugefügt, die es dem Administrator ermöglicht, einen Webbrowser zu verwenden, um Hilfe-, Informations- und Downloadseiten im Internet aufzurufen. Die Regel benötigt einen gespiegelten, statischen Filter, der den ausgehenden Datenverkehr für den TCP-Zielport 80 zulässt.

Tabelle 11.2: Beispiel für eine Netzwerkdatenverkehrstabelle mit ausgehendem Webbrowsing

Dienst

Protokoll

Quellport

Zielport

Quelladresse

Zieladresse

Aktion

Spiegelung

Eingehend ICMP-Daten für TCP-PMTU

ICMP

BELIEBIG

BELIEBIG

BELIEBIG

MEINE

ZULASSEN

NEIN

Eingehend IIS-Server HTTP:80

TCP

BELIEBIG

80

BELIEBIG

MEINE

ZULASSEN

JA

Eingehend IIS-Server FTP:21

TCP

BELIEBIG

21

BELIEBIG

MEINE

ZULASSEN

JA

Eingehend Terminalserver

TCP

BELIEBIG

3389

BELIEBIG

MEINE

ZULASSEN

JA

Ausgehend zum Domänencontroller, sämtlicher Datenverkehr

BELIEBIG

BELIEBIG

BELIEBIG

MEINE

Domänenname

ZULASSEN

JA

Ausgehend DNS UDP/TCP

UDP

BELIEBIG

53

MEINE

DNS

ZULASSEN

JA

Ausgehend DNS UDP/TCP

TCP

BELIEBIG

53

MEINE

DNS

ZULASSEN

JA

Ausgehend WINS

UDP

137

137

MEINE

WINS

ZULASSEN

JA

Ausgehend DHCP

UDP

68

67

MEINE

DHCP

ZULASSEN

JA

Ausgehend HTTP:80

TCP

BELIEBIG

80

MEINE

BELIEBIG

ZULASSEN

JA

Alles blockieren

BELIEBIG

BELIEBIG

BELIEBIG

BELIEBIG

BELIEBIG

BLOCKIEREN

JA

Auf den ersten Blick macht dieses Beispiel für eine Datenverkehrstabelle den Eindruck einer gut durchdachten Konfiguration. Genauer betrachtet bietet die gesamte Richtlinie jedoch keinen Schutz davor, dass ein Angreifer von einer beliebigen IP-Adresse aus eine eingehende Verbindung über den TCP-Quellport 80 herstellt. Der Angreifer kann auf jeden offenen TCP-Port über den eingehenden Zulassungsfilter zugreifen. Die Antwort wird wiederum über den ausgehenden Zulassungsfilter am TCP-Zielport 80 empfangen.

Zur Abwehr von eingehenden Angriffen stehen die folgenden Lösungen zur Verfügung:

  • Verwenden Sie zusätzliche IPSec-Filterregeln, um zu verhindern, dass ein Angreifer über Port 80 internen Zugriff auf offene Ports erhält.

  • Verwenden Sie einen Firewall oder einen Router, um eingehende Verbindungen von Quellport 80 zu blockieren, sofern nicht vorher eine ausgehende Verbindung über diesen Port erfolgt ist.

  • Konfigurieren Sie zusätzlich zu dieser IPSec-Richtlinie die Windows-Firewall auf dem externen Netzwerkadapter des Servers, um eine statusbehaftete Filterung für sämtlichen ausgehenden Datenverkehr zu erreichen, der von den IPSec-Filter zugelassen wird. Da die Windows-Firewall eine Ebene oberhalb von IPSec angesiedelt ist, muss sie ebenfalls so konfiguriert werden, dass eingehender Datenverkehr über die TCP-Ports 80 und 433 zugelassen wird (obwohl es sich hierbei um die Standardkonfiguration handelt).

Im folgenden Beispiel für eine Datenverkehrstabelle werden zusätzliche IPSec-Filter verwendet, um Angriffe zu blockieren, bei denen versucht wird, über Port 80 auf offene Ports zuzugreifen. Zunächst wird der Befehl „Netstat –ano“ verwendet, um zu bestimmen, welche TCP-Ports auf dem Server geöffnet sein müssen, damit der Angreifer eine Verbindung herstellen kann. Die Ausgabe für diesen Befehl sieht in etwa folgendermaßen aus:

C:\Documents and Settings\testuser.domain.000>netstat -ano
Active Connections

Proto  Local Address       Foreign Address     State         PID
TCP    0.0.0.0:135         0.0.0.0:0           LISTENING     740
TCP    0.0.0.0:445         0.0.0.0:0           LISTENING     4
TCP    0.0.0.0:1025        0.0.0.0:0           LISTENING     884
TCP    0.0.0.0:1046        0.0.0.0:0           LISTENING     508
TCP    192.168.0.5:139     0.0.0.0:0           LISTENING     4
UDP    0.0.0.0:445         *:*                               4
UDP    0.0.0.0:500         *:*                               508
UDP    0.0.0.0:1026        *:*                               816
UDP    0.0.0.0:1029        *:*                               508
UDP    0.0.0.0:1051        *:*                               452
UDP    0.0.0.0:4500        *:*                               508
UDP    127.0.0.1:123       *:*                               884
UDP    192.168.0.5:123     *:*                               884
UDP    192.168.0.5:137     *:*                               4
UDP    192.168.0.5:138     *:*                               4

Anschließend wird die Regel definiert, um bestimmte Angriffe zu blockieren, die den TCP-Quellport 25 verwenden, um eine Verbindung mit einem offenen TCP-Port herzustellen. Dies wird in der folgenden Tabelle dargestellt:

Tabelle 11.3: Überarbeitetes Beispiel für eine Netzwerkdatenverkehrstabelle mit ausgehendem Webbrowsing

Dienst

Protokoll

Quellport

Zielport

Quelladresse

Zieladresse

Aktion

Spiegelung

Eingehend ICMP-Daten für TCP-PMTU

ICMP

BELIEBIG

BELIEBIG

BELIEBIG

MEINE

ZULASSEN

NEIN

Eingehend IIS-Server HTTP:80

TCP

BELIEBIG

80

BELIEBIG

MEINE

ZULASSEN

JA

Eingehend IIS-Server FTP:21

TCP

BELIEBIG

21

BELIEBIG

MEINE

ZULASSEN

JA

Eingehend Terminalserver

TCP

BELIEBIG

3389

BELIEBIG

MEINE

ZULASSEN

JA

Ausgehend zum Domänencontroller, sämtlicher Datenverkehr

BELIEBIG

BELIEBIG

BELIEBIG

MEINE

Domänenname

ZULASSEN

JA

Ausgehend DNS UDP/TCP

UDP

BELIEBIG

53

MEINE

DNS

ZULASSEN

JA

Ausgehend DNS UDP/TCP

TCP

BELIEBIG

53

MEINE

DNS

ZULASSEN

JA

Ausgehend WINS

UDP

137

137

MEINE

WINS

ZULASSEN

JA

Ausgehend DHCP

UDP

68

67

MEINE

DHCP

ZULASSEN

JA

Ausgehend HTTP:80

TCP

BELIEBIG

80

MEINE

BELIEBIG

ZULASSEN

JA

Verhindern der Angriffe von Quellport 80

TCP

80

135

BELIEBIG

MEINE

BLOCKIEREN

NEIN

Verhindern der Angriffe von Quellport 80

TCP

80

139

BELIEBIG

MEINE

BLOCKIEREN

NEIN

Verhindern der Angriffe von Quellport 80

TCP

80

445

BELIEBIG

MEINE

BLOCKIEREN

NEIN

Verhindern der Angriffe von Quellport 80

TCP

80

1025

BELIEBIG

MEINE

BLOCKIEREN

NEIN

Verhindern der Angriffe von Quellport 80

TCP

80

1046

BELIEBIG

MEINE

BLOCKIEREN

NEIN

Alles blockieren

BELIEBIG

BELIEBIG

BELIEBIG

BELIEBIG

BELIEBIG

BLOCKIEREN

JA

Dieses Beispiel verdeutlicht, wie das Blockieren von Angriffen von außen erreicht werden kann. Durch Erstellen von Einwegfiltern wird sämtlicher Datenverkehr blockiert, der über Quellport 80 versucht, eine Verbindung mit einem aktiven Port des Computers herzustellen. Hierbei wird auch verhindert, dass Quellport 80 durch Spoofing dazu gebracht werden kann, eine Verbindung mit den Ports herzustellen, die für RPC, NetBT und SMB (CIFS) erforderlich sind.

Sie können IPSec-Richtlinien auf verschiedene Weise anwenden:

  • Wenden Sie sie auf einem einzelnen Computer an.

  • Hängen Sie sie über eine Gruppenrichtlinie an eine Organisationseinheit oder Domäne an.

  • Schreiben Sie ein Skript für den Befehl „netsh ipsec“, und wenden Sie das Skript anschließend auf ausgewählte Computer an.

Diese IPSec-Richtlinien können über Gruppenrichtlinien auf mehrere Computer verteilt werden. Wenn IPSec-Richtlinien jedoch an bestimmte Computer angepasst werden müssen, ist es u. U. besser, lokale Richtlinien zu verwenden. Wahlweise können Sie auch eine Mischung aus einer lokalen oder domänenbasierten Richtlinie und einer permanenten Richtlinie auf Grundlage von NETSH-IPSec-Skripts verwenden. Diese Variante lässt sich vergleichsweise einfach verwalten. NETSH muss insbesondere zum Einrichten einer permanenten Richtlinie verwendet werden, die Sicherheit beim Starten des Computers gewährleistet. Ausführliche Informationen finden Sie im Abschnitt „Assigning Domain-based, OU-Level, and Local IPSec Policies“ in Kapitel 6, „Bereitstellen von IPSec“, des Windows Server 2003 Deployment Kit: Bereitstellen von Netzwerkdiensten (in englischer Sprache).

Aushandeln von IPSec-Schutz für Netzwerkdatenverkehr

Die Integration des IKE-Protokolls in die IPSec-Filter ermöglicht die richtlinienbasierte automatische Aushandlung des IPSec-Kryptografieschutzes für den Unicast-IP-Datenverkehr, der den IPSec-Filterregeln entspricht. IPSec-geschützte Pakete können entweder das AH-Format oder das ESP-Format mit verschiedenen Sicherheitsoptionen verwenden, die von der Konfiguration der Richtlinie abhängen. Wenn Sie IPSec-Richtlinien zur Aushandlung des IPSec-geschützten Transports für Protokolle und Anwendungen auf höherer Ebene verwenden, ergeben sich folgende Vorteile:

  • Tiefenverteidigung gegen Netzwerkangriffe. IPSec ist ein ausgereiftes Sicherheitsprotokoll auf dem neuesten Stand der Technik, das von der IETF (Internet Engineering Task Force) entwickelt wurde. Mit IPSec kann zur Erhöhung der anwendungsbasierten Sicherheit auf einer Ebene, die sich unterhalb sämtlicher Unicast-IP-Kommunikation befindet, eine zusätzliche leistungsfähige Verteidigungsschicht hinzugefügt werden. Auf diese Weise wird IPSec vor Sicherheitsanfälligkeiten in Protokollen auf höherer Ebene geschützt, und die Kommunikationssicherheit wird verbessert. Das SMB-Protokoll für den Dateiaustausch findet z. B. ausgiebige Verwendung bei Active Directory®-Verzeichnisdienstreplikationen, Dateiübertragungen, Druckvorgängen und Downloadvorgängen für Gruppenrichtlinien. SMB gewährt allerdings keinen Datenschutz. Alle Daten, die innerhalb von SMB versendet werden, sind für passive Netzwerkbeobachter sichtbar. SMB unterstützt digitale Signaturen, allerdings stehen diese nicht immer zur Verfügung, da sich jede Einstellung immer auf den vollständigen SMB-Kommunikationspfad auswirkt. IPSec kann zum Sichern eines bestimmten Netzwerkpfads oder einer Reihe von Pfaden verwendet werden. Bisher wurden in Windows 2000 und Windows XP bezüglich SMB zwei Sicherheitsanfälligkeiten festgestellt. Obwohl Microsoft bereits entsprechende Sicherheitsupdates für diese Sicherheitsanfälligkeiten zur Verfügung stellt, können Sie die Sicherheit zusätzlich verbessern, indem Sie IPSec als erste Verteidigungsschicht gegen Angriffe auf SMB und andere Protokolle verwenden. Weitere Informationen zu den bekannten SMB-Sicherheitsanfälligkeiten und den entsprechenden Sicherheitsupdates für Windows 2000 und Windows XP finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:

  • IPSec bietet hostbasierte Authentifizierung und Verschlüsselung für den gesamten Datenverkehr zwischen zwei oder mehreren Computern. Dadurch wird gewährleistet, dass der administrative Besitzer der Daten während der Netzwerkübertragung vollständige Kontrolle über die Daten hat. Die Daten im Netzwerkdatenverkehr können Informationsressourcen enthalten, die u. U. urheberrechtlich geschützt und für die Besitzer von zentraler Bedeutung sind. Ein Datendiebstahl während der Übertragung kann zu katastrophalen Folgen für das Unternehmen und seine Aufgaben führen. Die IPSec-Verschlüsselung zur sicheren Kommunikation bleibt auch gewährleistet, wenn geschäftliche oder rechtliche Vertrauensbeziehungen zur Verwaltung der Vertrauensstellung und Integrität des Netzwerkpfads nicht perfekt umgesetzt werden.

  • Einfacher und sicherer Datenverkehr durch die Firewall. Die vielen zur Kommunikation zwischen Domänencontrollern, zwischen Servern oder zwischen Clients und Servern verwendeten Protokolle werden von Firewalls nur als IPSec-Datenverkehr im ESP-Format (Protokoll 50) und als Datenverkehr im AH-Format (Protokoll 51) interpretiert. Firewalls können so konfiguriert werden, dass nur der Datenverkehr dieser Protokolle (und IKE-Datenverkehr) zulässig ist. Diese Protokolle wiederum sind selbst gegen Angriffe geschützt.

  • IPSec verwendet den 3DES-Verschlüsselungsalgorithmus und den SHA1-Integritätsalgorithmus und verfügt über die Common Criteria- sowie die FIPS-140-1-Zertifizierung. Viele Regierungs-, Militär-, Finanz- und Gesundheitsorganisationen verlangen, dass zur Sicherung des Datenverkehrs Algorithmen mit Common Criteria- oder FIPS-140-1-Zertifizierung verwendet werden. Der RC4 Stream-Verschlüsselungsalgorithmus wird standardmäßig verwendet, um den Datenverkehr der meisten Windows-Protokolle zu verschlüsseln, z. B. RPC, Kerberos-Authentifizierungsprotokoll und LDAP (Lightweight Directory Access Protocol). Der RC4-Algorithmus verfügt weder über Common Criteria- noch über FIPS-140-1-Zertifizierung.

  • Als softwarebasierte Windows-Lösung ist IPSec bei der Sicherung der Host-to-Host-Kommunikation eine kostengünstige Alternative zu einer hardwarebasierten Lösung. Hardwarebasierte Sicherheitslösungen, z. B. ein virtuelles privates Netzwerk (VPN) oder eine exklusiv gemietete Leitung, verursachen höhere Kosten als die Windows-Lösung mit IPSec.

  • Bei IPSec wird die CPU weniger beansprucht als bei protokollspezifischen Sicherheitsmaßnahmen (z. B. SMB-Signatur). Durch Netzwerkadapter, die die IPSec-Verarbeitung verschieben, werden die zur Sicherung von IPSec-Paketen erforderlichen Kryptografieprozesse beschleunigt, wodurch wiederum die Leistungskosten für die Verschlüsselung minimiert werden. IPSec-verschlüsselte TCP/IP-Kommunikation kann daher denselben Durchsatz erreichen wie die unverschlüsselte TCP/IP-Kommunikation. Allerdings können Kosten durch die erforderliche Anschaffung der Adapter entstehen. Wenn die Verwendung solcher Adapter nicht möglich ist, wird die CPU-Auslastung auf einem Domänencontroller aufgrund der IPSec-Verschlüsselung erhöht. Je nach verfügbarer Prozessorleistung und dem Umfang des Netzwerkdatenverkehrs muss u. U. aufgrund der erhöhten CPU-Auslastung zusätzliche CPU-Kapazität eingesetzt werden. Zur Analyse der Auswirkungen auf die Domänencontroller in bestimmten Szenarien sollten Sie einige Leistungstests durchführen. Weitere Informationen zu den Vorteilen von IPSec-Hardwareadaptern für das Verschieben der Serverbelastung finden Sie im Artikel „Intel PRO/100S Netzwerkadapter, IPSec Offload – Leistung und Vergleich“ (in englischer Sprache) unter www.veritest.com/clients/reports/intel/intelps.pdf.

Mögliche Auswirkung

IPSec ist ein Tool, mit dem Sie einen Server gegen Netzwerkangriffe absichern können. Sie stellen jedoch keine vollständige Lösung dar, und es gibt noch weitere Werkzeuge. Die IPSec-Filterung wurde nicht als Ersatz für voll funktionsfähige Perimeterfirewalls oder Routerfilter entwickelt. IPSec wird für einfache Paketfilterszenarien empfohlen, um Clients und Server dort abzusichern, wo statische Filterregeln effektiv verwendet werden können. Darüber hinaus wurden IPSec-Filter so entwickelt, dass sie über verzeichnisbasierte Richtlinien auf viele Computer angewendet werden können. Das MMC-Snap-In für die IPSec-Richtlinienverwaltung bietet daher während des Konfigurationsvorgangs keine ausführlichen Informationen zur Anwendung einer Richtlinie auf einen bestimmten Computer. Für IPSec-Filter gelten die folgenden Einschränkungen:

  • IPSec-Filter können nicht für einzelne Anwendungen definiert werden. Sie können nur für Protokolle und Ports definiert werden, die von der Anwendung verwendet werden.

  • IPSec-Filter sind statisch. Sie bieten keine statusbehaftete Filterung von ausgehendem Datenverkehr. Zum Zulassen von ausgehendem Netzwerkdatenverkehr sind in der Regel statische ein- und ausgehende Zulassungsfilter erforderlich. IPSec kann daher keinen Schutz vor Angreifern bieten, die den statischen Zulassungsfilter von außen verwenden, um auf einen beliebigen offenen Port zuzugreifen. Ausgehende Zulassungsfilter sollten daher nur speziell für die erforderliche IP-Adresse oder den erforderlichen Bereich verwendet werden.

  • IPSec-Filter unterscheiden nicht zwischen den verschiedenen ICMP-Meldungstypen.

  • IPSec-Filter führen keine Eindringungserkennung durch, d. h., der Inhalt von IP-Paketen wird nicht untersucht.

  • IPSec-Filter können überlappen, jedoch nicht manuell sortiert werden. Der IPSec-Dienst führt eine interne Berechnung durch, um die Filter zu gewichten, und erstellt die Filterreihenfolge automatisch. Oberste Priorität genießt der Adressteil eines Filters, es folgen das Protokoll und schließlich Quell- und Zielport.

  • IPSec-Filter sind nicht schnittstellenspezifisch. Sie können jedoch IP-adressenspezifisch konfiguriert werden. Allerdings wird der gesamte Datenverkehr auf einer Schnittstelle mit der Filterliste abgeglichen.

  • IPSec-Filter können nicht explizit als eingehende oder ausgehende Filter konfiguriert werden. Die jeweilige Richtung (ein- oder ausgehend) wird in Abhängigkeit von der im Filter angegebenen Adresse automatisch bestimmt. In einigen Fällen werden sowohl eingehende als auch ausgehende Filter automatisch erzeugt.

  • Doppelte Filter werden von den IPSec-Richtlinien nicht unterstützt.

  • Obwohl Windows Server 2003 eine erheblich verbesserte IPSec-Filterleistung bietet, kann durch die hostbasierte Filterung die CPU-Leistung bei starkem Netzwerkdatenverkehr beeinträchtigt werden. Durch die Optimierung von Front-End-Routern oder -Firewalls kann die Filterung des Datenverkehrs beschleunigt werden.

Wenn ein IPSec-Filter (oder ein anderes Netzwerkgerät) den Netzwerkdatenverkehr blockiert, kann dies zu ungewöhnlichem Anwendungsverhalten und entsprechenden Ereignismeldungen führen. IPSec-Filter erzeugen für ein- oder ausgehende Datenpakete, die verworfen wurden, keine leicht lesbaren Protokolleinträge. Im Netzwerkmonitor (Netmon) zur Erfassung des Netzwerkdatenverkehrs können die ausgehenden Pakete, die blockiert wurden, nicht angezeigt werden. Eingehende Pakete, die blockiert wurden, können im Netzwerkmonitor angezeigt werden, allerdings wird nicht angegeben, dass diese Pakete verworfen wurden. Eine effektive Diagnose ist daher nur möglich, wenn als Vergleichswert das normale Verhalten (ohne IPSec-Richtlinie) von Anwendungen, Ereignissen und Netzwerkdatenströmen bekannt ist.

Darüber hinaus kann für das Konfigurieren der IPSec-Filter für den Anwendungsdatenverkehr eine ausführlichen Analyse der Netzwerkdatenströme erforderlich sein, um verstehen zu können, wie das Netzwerk von der jeweiligen Anwendung verwendet wird. Beispielsweise verwendet das SMB-Protokoll den TCP-Port 139 zur Dateiübertragung sowie für Datei- und Druckfreigaben. Wenn dieser Port durch IPSec blockiert wird, kann SMB den TCP-Port 445 verwenden. Ein weiteres Beispiel ist eine Situation, bei der für eine Anwendung mehrere Netzwerkdatenströme mit verschiedenen Zieladressen erforderlich sind. SMB und andere Protokolle verwenden normalerweise auch eine Form der Benutzerauthentifizierung. Dies kann dazu führen, dass die Authentifizierung von Kerberosdaten mit dem Domänencontroller durchgeführt wird. Das Kerberos-Protokoll verwendet zum Suchen einer Liste mit den IP-Adressen der Domänencontroller eine DNS-Abfrage auf UDP 53 oder TCP 53. Anschließend wird zur Ermittlung von Domänencontroller-IP-Adressen eine LDAP-Abfrage auf UDP 389 und über UDP- und TCP-Port 88 ausgeführt. Wenn ein Druckauftrag fehlschlägt, kann dies z. B. daran liegen, dass ein an den Domänencontroller gesendetes Paket blockiert wurde. Einige Protokolle (z. B. RPC) verwenden mehrere TCP-Ports, die beim Starten des Computers oder beim Ausführen einer Anwendung dynamisch ermittelt werden. Daher können RPC-Anwendungen nicht mit statischen Portfiltern gesteuert werden, es sei denn, die RPC-Anwendung kann so konfiguriert werden, dass die Verwendung eines statischen Ports erzwungen wird.

Unter Windows 2000 und Windows XP wurden Standardausnahmen für die in der Richtlinienkonfiguration angegebenen Filter entworfen. Diese gelten speziell für die folgenden IP-Netzwerkdatenverkehrstypen: Datenverkehr, der nicht durch IKE gesichert werden kann (Broadcast- und Multicast-IP-Pakete), Datenverkehr, der ausgenommen werden muss, damit QoS (Quality of Service) für IPSec-Datenverkehr (RSVP-Protokoll) verfügbar ist, sowie Datenverkehr, der für das Funktionieren des IPSec-Systems erforderlich ist (IKE selbst und das Kerberos-Protokoll als IKE-Authentifizierungsmethode). Obwohl für das Entfernen dieser Ausnahmen ein Registrierungsschlüssel bereitgestellt wurde, wurden sie häufig nicht deaktiviert, wenn IPSec-Filter zum Zulassen und Blockieren in Firewallszenarien verwendet wurden. Daher stellt Windows Server 2003 nur für IKE-Datenverkehr eine Ausnahme zur Verfügung. Microsoft empfiehlt das Entfernen der Standardausnahmen für alle IPSec-Szenarien unter Windows 2000 und Windows XP. Weitere Informationen zu Standardausnahmen finden Sie im Microsoft Knowledge Base-Artikel „IPSec-Standardausnahmen können in einigen Szenarios zum Überwinden des IPSec-Schutzes verwendet werden“ unter https://support.microsoft.com/?kbid=811832 und im Microsoft Knowledge Base-Artikel „IPSec-Standardausnahmen wurden in Windows Server 2003 entfernt“ unter https://support.microsoft.com/?kbid=810207 (jeweils in englischer Sprache).

Wenn ein Windows 2000-Computer mit dem Internet verbunden ist, ermöglicht der gespiegelte ausgehende Zulassungsfilter (z. B. für Port 80, siehe weiter oben in diesem Kapitel) einem Angreifer den Zugriff auf einen beliebigen offenen TCP-Port auf dem Server über den Internetquellport. Somit kann ein Fehler in der IPSec-Konfiguration zum Verlust der erwarteten Sicherheit führen. Testen Sie daher immer Ihre Konfiguration, um sicherzustellen, dass der erwartete Schutz vor Angriffen auch tatsächlich vorhanden ist.

Wenn es einem Angreifer gelingt, über eine Sicherheitsanfälligkeit auf ein lokales System- oder Administratorkonto zuzugreifen, kann der Angreifer auch die IPSec-Richtlinie deaktivieren oder ändern.

Unter Windows 2000 bietet IPSec während des Hochfahrens des Computers keine vollständige Filterung. Es gibt dabei ein kleines Zeitfenster, in dem der TCP/IP-Protokollstapel reagiert. Während dieser Zeit besteht die Gefahr, dass bei einem automatisierten Angriff auf Anwendungsports zugegriffen wird, die erst später durch die IPSec-Richtlinie blockiert werden. In den meisten Fällen ist jedoch der Verbindungsaufbau über die Anwendungen vor Aktivierung der IPSec-Filterung nicht möglich. Um bei Verwendung von IPSec-Filtern maximale Sicherheit zu erreichen, trennen Sie den Computer während eines Neustarts vom Netzwerk.

Unter Windows Server 2003 steht eine Startrichtlinie zur Verfügung, die vom IPSec-Treiber verwendet wird, sobald der TCP/IP-Ladevorgang beim Starten des Computers erfolgt. Beim Starten des IPSec-Dienstes wird sie sofort als permanente Richtlinie angewendet. Wenn anschließend die Zuordnung einer lokalen oder domänenweiten Richtlinie erfolgt, wendet der Dienst diese Richtlinienzuordnung zusätzlich zur permanenten Richtlinie an. Ein NETSH-IPSec-Skript, das eine sichere und permanente Standardrichtlinie konfiguriert (z. B. zum Blockieren des gesamten Datenverkehrs mit Ausnahme der Verwaltungsdaten), kann daher vollständigen Schutz gewährleisten, während von der Startrichtlinie zur lokal oder domänenweit zugeordneten IPSec-Richtlinie übergegangen wird. Weitere Informationen finden Sie in der Windows Server 2003-Onlinehilfe und im Deployment Kit.

Weder Windows 2000 noch Windows Server 2003 sind darauf ausgerichtet, Dienstabhängigkeiten für den Start des IPSec-Richtlinienagenten zu konfigurieren. Die Konfiguration einer Dienstabhängigkeit garantiert nicht, dass die Filter aktiviert sind, bevor der Dienst gestartet wird.

Unter Windows Server 2003 und Windows XP mit SP2 steht der Windows-Firewalldienst zur Verfügung. Dadurch wird die statusbehaftete Filterung aller ausgehenden Pakete ermöglicht. Außerdem werden grundlegende Steuerungsmöglichkeiten für eingehende Pakete bereitgestellt, die auf Ports und ICMP-Meldungstypen zugreifen. Die Windows-Firewall kann ein lesbares Protokoll für blockierte eingehende und ausgehende Pakete erstellen. Als Administrator sollten Sie die Windows-Firewallfunktionen testen, um herauszufinden, ob die Windows-Firewall für Ihre Anforderungen zum Filtern von Datenverkehr besser geeignet ist. Die statusbehaftete Filterung durch die Windows-Firewall kann in Kombination mit IPSec-Filtern verwendet werden. Dies ist z. B. in Szenarien nützlich, in denen IPSec so konfiguriert ist, dass ausgehende Filter gespiegelt werden, um Datenverkehr zuzulassen. Verwenden Sie als erste Sicherheitsmaßnahme gegen Angriffe möglichst Front-End-Router oder Firewallsysteme.

Hostbasierte Eindringungserkennungssysteme und andere Antivirussysteme sind ebenfalls empfehlenswert, damit Infektionen und Angriffen innerhalb des zugelassenen Netzwerkdatenverkehrs und innerhalb von Anwendungen entgegengewirkt werden kann. Eine hostbasierte Firewall oder eine Perimeterfirewall von Drittanbietern stellt möglicherweise die beste Lösung für komplexe Filteranforderungen dar.

Aushandeln von IPSec-Schutz für Netzwerkdatenverkehr

Mit End-to-End-Sicherheitsmaßnahmen durch IPSec kann die Sicherheit deutlich erhöht werden. Für die IPSec-gesicherte Netzwerkkommunikation sind jedoch zusätzliche Schulungen und höhere Verwaltungsausgaben erforderlich. Dazu kommen möglicherweise weitere Hardwarekosten für IPSec-taugliche Geräte, Netzwerkadapter oder zusätzliche CPU-Kapazität. Bevor Sie sich für ein bestimmtes IPSec-Szenario entscheiden, sollten Sie deshalb sorgfältig analysieren und dokumentieren, welchen möglichen Sicherheitsrisiken mit IPSec begegnet werden soll, welches Ihre Sicherheitsanforderungen sind, welche Kosten bei der IPSec-Bereitstellung entstehen und welche Geschäftsvorteile zu erwarten sind.

Das Implementieren von IPSec mit AH führt zu zusätzlichem Aufwand beim Verwalten einer Client/Server-IPSec-Konfiguration und einer gegenseitigen Vertrauensstellung zwischen Client- und Servercomputern. Wenn sich zwei Computer immer in derselben Domäne oder in Domänen mit gegenseitiger Vertrauensstellung befinden, kann eine Grupperichtlinie die erforderlichen IPSec-Richtlinieneinstellungen zur Verfügung stellen. Die Kerberos-Authentifizierung kann in diesem Fall eine Vertrauensstellung für IPSec-Sicherheitszuordnungen einrichten. Wenn ein Computer die Kerberos-Authentifizierung nicht verwenden kann, müssen entweder Computerzertifikate oder vorinstallierte Authentifizierungsschlüssel verwendet werden. In diesem Handbuch wird die Verwendung von vorinstallierten Authentifizierungsschlüsseln jedoch nicht empfohlen, da der Schlüsselwert ungeschützt in der IPSec-Richtlinienkonfiguration gespeichert wird.

Obwohl die lokale IPSec-Richtlinie nur von Administratoren gelesen werden kann, die die Richtlinie definiert haben, muss die in Active Directory gespeicherte Richtlinie für alle Domänencomputer zugänglich sein. Aus diesem Grund ist es schwer, den Wert des vorinstallierten Schlüssels geheim zu halten. Microsoft empfiehlt die Verwendung von digitalen Zertifikaten, wenn das Kerberos-Protokoll nicht für die IKE-Authentifizierung verwendet werden kann. Die IPSec-Richtlinie sollte so eingerichtet werden, dass entweder der gesamte Datenverkehr geschützt wird oder dass IPSec nur für bestimmte TCP- und UDP-Ports ausgehandelt wird. Auf den Clients muss die IPSec-Richtlinie normalerweise mit der statischen IP-Adresse des Servers konfiguriert werden. Wenn IPSec auf dem Server erforderlich ist, kann kein Zugriff mit Clientcomputern erfolgen, die nicht über eine kompatible IPSec-Richtlinienkonfiguration und eine gegenseitige Vertrauensstellung verfügen.

Weitere Informationen zur Implementierung von Windows IPSec finden Sie auf der Windows 2000 IPSec-Website (in englischer Sprache) unter www.microsoft.com/windows2000/technologies/communications/ipsec/default.asp.

Konfigurieren der Windows-Firewall

Eine Internetfirewall kann verhindern, dass externe Benutzer über das Internet auf Ihren Computer zugreifen können. Windows XP mit SP2 und Windows Server 2003 mit SP1 enthalten die Windows-Firewall. Hierbei handelt es sich um eine integrierte Firewall, die vielen Organisationen zusätzlichen Schutz gegen netzwerkbasierte Angriffe bietet (z. B. gegen Würmer und Denial-of-Service-Angriffe).

  1. Klicken Sie auf Start und anschließend auf Systemsteuerung.

  2. Klicken Sie auf Windows-Firewall.    

  3. Klicken Sie auf das Optionsfeld Aktiv (empfohlen).

  4. Klicken Sie bei Bedarf auf die Registerkate Ausnahmen, um Ausnahmen für die Protokolle zu konfigurieren, die von der Firewall zugelassen werden sollen.

  5. Klicken Sie auf OK, um die Windows-Firewall zu aktivieren.

Die Windows-Firewall verfügt nicht über so vielfältige Funktionen wie viele Produkte von Drittanbietern, da sie lediglich als eine grundlegender Schutz gegen Eindringungsversuche gedacht ist. Die Windows-Firewall verhindert, dass Unbefugte Informationen zu Ihrem Computer sammeln können, und blockiert unerwünschte Verbindungsversuche. Sie führt jedoch keine umfassende Filterung des ausgehenden Datenverkehrs durch.

Die Windows-Firewall bietet verschiedene wichtige Verbesserungen im Vergleich zur Internetverbindungsfirewall (ICF), die in früheren Windows-Versionen enthalten war. Insbesondere kann die Windows-Firewall über Gruppenrichtlinien zentral verwaltet werden. Weitere Informationen zu den verfügbaren Verwaltungstools und Einstellungen finden Sie im Whitepaper „Bereitstellen von Windows-Firewall-Einstellungen für Microsoft Windows XP mit Service Pack 2“ (in englischer Sprache) unter www.microsoft.com/downloads/details.aspx?
FamilyID=4454e0e1-61fa-447a-bdcd-499f73a637d1&DisplayLang=en.

Weitere Informationen

Die folgenden Links bieten weitere Informationen zu zusätzlichen Absicherungsmaßnahmen unter Windows Server 2003 und Windows XP:

In diesem Beitrag

Download

Handbuch „Bedrohungen und Gegenmaßnahmen“ herunterladen (engl.)

Benachrichtigung über Neuerungen

Melden Sie sich an, um sich über Updates und neue Versionen zu informieren

Feedback

Senden Sie uns Ihre Kommentare oder Vorschläge

 Dd443758.pageLeft(de-de,TechNet.10).gif12 von 14Dd443758.pageRight(de-de,TechNet.10).gif