Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien Kapitel 5: Erstellen von IPSec-Richtlinien für Isolierungsgruppen

Ziel dieses Kapitels ist es, Anweisungen für die Implementierung des Entwurfs zur Server- und Domänenisolierung bereitzustellen. In den vorhergehenden Kapiteln wurden der Entwurfsprozess sowie die Grundprinzipien erläutert, die den Anleitungen in diesem Kapitel zugrunde liegen. Wir empfehlen Ihnen daher dringend, zunächst die bisherigen Kapitel durchzulesen, sofern noch nicht geschehen, und erst dann mit diesem Kapitel fortzufahren.

Dieses Kapitel enthält eine vollständige Anleitung zur Implementierung der Sicherheitsanforderungen für die Domänenisolierung und der in Kapitel 4, "Entwerfen und Planen von Isolierungsgruppen", entworfenen Serverisolierungsgruppen. Diese Anforderungen werden durch eine Kombination der folgenden Elemente implementiert:

• Anforderungen für den eingehenden und den ausgehenden Zugriff für die Isolierungsdomäne und die Isolierungsgruppen:
  • IPSec-Richtlinien, die speziell für die Isolierungsgruppe entwickelt wurden, die eine IPSec-IKE-Aushandlung für eingehende und ausgehende Verbindungen erfordern
  • Netzwerkzugriffsgruppen (NAGs) genannte domänenbasierte Sicherheitsgruppen zum Zulassen oder Ablehnen des Netzwerkzugriffs bei Verwendung von IPSec zur Absicherung des Datenverkehrs
• Anforderungen für den Schutz des Netzwerkverkehrs für die Isolierungsdomäne und die Isolierungsgruppen:
  • IPSec-Richtlinienfilter zur ordnungsgemäßen Erkennung des abzusichernden Verkehrs
  • IPSec-Filteraktionen, die aushandeln, welches Maß an Authentifizierung und Verschlüsselung für den Verkehr erforderlich ist, der von den Filtern identifiziert wird
  • IPSec-Filteraktionseinstellungen, die steuern, ob bei der Initiierung von ausgehenden Verbindungen durch Hosts ungesicherte Kommunikation (Klartext) zugelassen ist

In dieser Anleitung wird die Vorbereitung der Lösung mithilfe der Gruppenrichtlinie und der IPSec-Richtlinien im Active Directory®-Verzeichnisdienst unter Verwendung von Microsoft® Windows Server 2003 und die Konfiguration der Domänenmitglieder unter Verwendung von Windows Server 2003 und Microsoft Windows® XP erläutert. Darüber hinaus werden in diesem Kapitel Entwurfsalternativen und Rolloutoptionen vorgestellt. Am Ende des Kapitels finden Sie Checklisten, mit deren Hilfe überprüft werden kann, ob der Entwurf allen Geschäfts- und Sicherheitsanforderungen gerecht wird.

Auf dieser Seite	In diesem Beitrag
Voraussetzungen für das Kapitel Erstellen von IPSec-Richtlinien in Active Directory Autorisieren von bei einer Isolierungsgruppe eingehendem Verkehr Weitere Überlegungen zum Thema IPSec Zusammenfassung	Überblick - Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien Kapitel 1: Einführung in die Server- und Domänenisolierung Kapitel 2: Grundlagen der Server- und Domänenisolierung Kapitel 3: Ermitteln des aktuellen Status der IT-Infrastruktur Kapitel 4: Entwerfen und Planen von Isolierungsgruppen Kapitel 5: Erstellen von IPSec-Richtlinien für Isolierungsgruppen Kapitel 6: Verwalten einer Server- und Domänenisolierungsumgebung Kapitel 7: Problembehandlung für IPSec Anhang A: Überblick über IPSec-Richtlinienkonzepte Anhang B: Zusammenfassung zu IPSec-Richtlinien Anhang C: Leitfaden zum Aufbau einer Testumgebung Anahng D: IT-Bedrohungskategorien Danksagungen
	Vollständige Lösung downloaden Server-und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien (engl.)

Voraussetzungen für das Kapitel

Dieser Abschnitt enthält Informationen, anhand derer Sie bestimmen können, inwieweit Ihre Organisation für die Implementierung der IPSec-Lösung bereit ist. (Bereitschaft ist hier eher im logistischen als im geschäftlichen Sinn zu verstehen. Die geschäftliche Motivation für die Implementierung dieser Lösung wird in Kapitel 1, "Einführung in die Server- und Domänenisolierung", dieses Leitfadens erörtert.)

Vorausgesetzte Kenntnisse

Dieses Kapitel setzt Kenntnisse der allgemeinen Konzepte und Begriffe im Zusammenhang mit IPSec sowie speziell der Microsoft-Implementierung von IPSec voraus. Vertrautheit mit Microsoft Windows Server 2003 (oder höher) ist in den folgenden Bereichen ebenfalls erforderlich:

• Active Directory®-Konzepte, einschließlich Active Directory-Struktur und -Tools; Verwalten von Benutzern, Gruppen und anderen Active Directory-Objekten; Verwenden der Gruppenrichtlinien.
• Windows-Systemsicherheitskonzepte, wie Benutzer, Gruppen, Überwachung und Zugriffssteuerungslisten (ACLs); Verwenden von Sicherheitsvorlagen; Anwenden von Sicherheitsvorlagen durch Gruppenrichtlinien oder Befehlszeilenprogramme.
• Kenntnisse der wichtigsten Netzwerk- und IPSec-Prinzipien

Bevor Sie mit diesem Kapitel fortfahren, sollten Sie auch die Planungsanleitungen in den vorhergehenden Kapiteln dieses Leitfadens durchgelesen und sich so einen Überblick über die Architektur und das Design (Entwurf) der Lösung verschafft haben. Darüber hinaus sollten Sie die Geschäftsanforderungen der Lösung definiert und als Teil der Matrix der Lösungsanforderungen dokumentiert haben.

Unternehmensvoraussetzungen

Sie sollten sich daher mit anderen Personen in Ihrer Organisation besprechen, die in die Implementierung dieser Lösung mit einbezogen werden müssen, wie z. B. Personen, die die folgenden Rollen bekleiden:

• Geschäftssponsoren

• Für Sicherheit und Überwachung zuständige Mitarbeiter

• Für Verwaltung, Betrieb und technische Aspekte von Active Directory zuständige Mitarbeiter

• Für Verwaltung, Betrieb und technische Aspekte von DNS (Domain Name System), Webservern und Netzwerk zuständige Mitarbeiter

  Hinweis

  
  Die Anzahl dieser Rollen muss nicht unbedingt mit der Anzahl der verschiedenen Personen übereinstimmen. Abhängig von der Struktur der jeweiligen IT-Organisation können Rollen von mehreren Personen besetzt werden bzw. mehrere Rollen können von ein und derselben Person übernommen werden.
  

Grundvoraussetzungen der IT-Infrastruktur

In diesem Kapitel wird auch davon ausgegangen, dass die folgende IT-Infrastruktur vorhanden ist:

• Microsoft Windows Server 2003-Active Directory-Domäne im gemischten oder einheitlichen Modus. Bei dieser Lösung werden universelle Gruppen für die Gruppenrichtlinienobjekt-Anwendung verwendet. Auch wenn in der Organisation nicht der gemischte oder der einheitliche Modus ausgeführt wird, ist es dennoch möglich, das GPO durch standardmäßige Konfigurationen globaler und lokaler Gruppen anzuwenden. Da diese Option jedoch schwieriger zu verwalten ist, wird sie in dieser Lösung nicht verwendet.

  Hinweis

  
  Windows Server 2003 umfasst eine Reihe von Verbesserungen, die sich auf IPSec-Richtlinien auswirken. In der vorliegenden Lösung sind keine speziellen Konfigurationen enthalten, die einem einwandfreien Betrieb mit Windows 2000 im Wege stehen würden. Die Lösung wurde jedoch nur mit Windows Server 2003 Active Directory getestet.
  Weitere Informationen zu den Verbesserungen an IPSec in Windows Server 2003 finden Sie auf der Seite New features for IPsec der Microsoft-Website unter www.microsoft.com/resources/documentation/
  WindowsServ/2003/standard/proddocs/en-us/ipsec_whatsnew.asp (in englischer Sprache).

• Lizenzen, Installationsmedien und Produktschlüssel für Windows 2000 Server, Windows Server 2003 Standard Edition und Windows Server 2003 Enterprise Edition.

Dieses Kapitel setzt außerdem die vollständige Kenntnis der vorhandenen IT-Infrastruktur voraus. Auf diese Weise wird gewährleistet, dass für die Hosts in der Umgebung jeweils die entsprechenden Richtlinien bereitgestellt werden. In Kapitel 3, "Ermitteln des aktuellen Status der IT-Infrastruktur", wird beschrieben, welche Informationen Sie zur Infrastruktur benötigen und woher Sie diese Informationen bekommen. Führen Sie die in diesem Kapitel beschriebenen Schritte erst aus, wenn Ihnen mindestens die folgenden Informationen vorliegen:

• Definition der Isolierungsgruppen für den Entwurf. Für jede der erforderlichen Isolierungsgruppen sollten die Sicherheitsanforderungen und die Ressourcen ("Assets") benannt und dokumentiert werden, für die diese Anforderungen gelten (d. h., die Isolierungsgruppenmitgliedschaft).
• Allgemeine Beschreibung der Verwendung von IPSec-Richtlinien zur Implementierung der Isolierungsgruppen, einschließlich einer Liste der verschiedenen IPSec-Richtlinien, die benötigt werden, sowie Angaben dazu, wie sie zugewiesen werden sollen.
• Allgemeine Übersicht über die Auswirkungen der Anwendung von IPSec zur Durchsetzung der Isolierungsgruppen. Diese Übersicht kann eventuelle durch eine Liste mit Problemen und Informationen zu deren Lösung ergänzt werden.
• Allgemeine Beschreibung, wie die IPSec-Richtlinien im Laufe der Zeit geändert werden, und eine Liste der Verfahren, die eine Änderung von IPSec-Richtlinien erfordern. Diese Liste würde Verfahren wie z. B. das Reagieren auf Sicherheitsvorfälle, das Hinzufügen von Netzwerkkomponenten und das Hinzufügen von Clients oder Servern zu einer Isolierungsgruppe enthalten.
• Übersicht über die Netzwerktopologie und das IP-Adressierungsschema der Organisation.

Zum Seitenanfang

Erstellen von IPSec-Richtlinien in Active Directory

Bei der Erstellung der zur Unterstützung der erforderlichen Isolierungsgruppen benötigten Richtlinien fallen die folgenden Hauptaufgaben an:

• Erstellen der Filterlisten
• Erstellen der Filteraktionen
• Erstellen der IPSec-Richtlinien zum Implementieren der Isolierungsgruppen

Bevor Sie mit dem Erstellen dieser Komponenten beginnen, sollten Sie die Verkehrsmodelldiagramme und -tabellen aus Kapitel 4, "Entwerfen und Planen von Isolierungsgruppen", und die Host- und Netzwerkzuordnungstabellen vorliegen haben. Mithilfe der Informationen in diesen Tabellen kann sichergestellt werden, dass die Richtlinien die erforderliche Funktionalität bereitstellen und den richtigen Isolierungsgruppen zugewiesen werden.

Die folgende Abbildung zeigt die Netzwerkkonfiguration, die zum Simulieren des Woodgrove Bank-Szenarios verwendet wurde.

Abbildung 5.1: Netzwerkkonfiguration der Woodgrove Bank

Bild in voller Größe anzeigen

Die Konfiguration der Woodgrove Bank-Testumgebung demonstriert die folgenden Schlüsselfunktionen der Lösung:

• Domänenisolierung mithilfe von Netzwerkzugriffsgruppen, um bestimmte vertrauenswürdiger Hosts in der Domäne, die ein höheres Risiko darstellen, bei der Verwendung von IPSec zu blockieren
• Serverisolierung mithilfe von Netzwerkzugriffsgruppen um einzuschränken, welche vertrauenswürdigen Hostclients zum Herstellen einer Verbindung mit IPSec autorisiert sind

Darüber hinaus demonstriert die Testumgebung die folgenden erforderlichen Funktionen von Windows IPSec und die Testkompatibilität mit anderen Sicherheitstechnologien, die in der Praxis zum Einsatz kommen würden:

• Kompatibilität mit Computern unter Windows 2000 SP 4 (mit NAT-T-Aktualisierung), Windows XP SP2 und Windows Server 2003 als Domänenmitglieder.
• Kompatibilität dieser Plattformen, wenn sie mithilfe der in den Microsoft Windows-Sicherheitsleitfäden empfohlenen Maßnahmen abgesichert sind. Die Verkehrspläne zum Zulassen oder Blockieren von Verkehr mithilfe von IPSec-Filtern wurden nicht in diese Lösung integriert, da für die Isolierung andere Schutzanforderungen gelten. Darüber hinaus führt die Nichtberücksichtigung dieser Verkehrspläne zu einer geringeren Komplexität der IPSec-Richtlinien für die Serverisolierung. Außerdem ist die Windows Firewall besser zum Filtern von Datenverkehr geeignet (unabhängig davon, dass IPSec eine Absicherung auf dem gesamten Weg des Pakets vom Sender zum Empfänger bietet).
• Fähigkeit von IPSec, Web- (HTTP), SQL Server-, Distributed File System (DFS)-, Datei- und Druckerfreigabe-, Microsoft Operations Manager (MOM)- und Microsoft Systems Management Server (SMS)-Server und -Datenverkehr abzusichern.
• Kompatibilität von IPSec-ESP-NAT-T mithilfe von UDP-ESP-Verkapselung für die folgenden beiden Zustände:
  • Von Domänenmitgliedern hinter NAT ausgehender Zugriff mithilfe der IKE-Kerberos-Authentifizierung
  • Bei einem Domänenmitglied hinter NAT eingehender Zugriff mithilfe der IKE-Kerberos-Authentifizierung

Mithilfe des in Abbildung 5.1 dargestellten Szenarios wurde getestet, ob in allen Isolierungsgruppen für die Lösung die korrekte Funktionalität erzielt wurde. Insgesamt wurden vier IPSec-Richtlinien erstellt und den in der Abbildung mit fetter Umrandung dargestellten Isolierungsgruppen (also der Isolierungsdomäne, der Isolierungsgruppe "Verschlüsselung", der Isolierungsgruppe "Kein Klartext" und der Isolierungsgruppe "Domänengrenze") zugewiesen. In den folgenden Abschnitten wird erläutert, wie diese Richtlinien erstellt wurden.

Überblick über die Komponenten einer IPSec-Richtlinie

Eine IPSec-Richtlinie besteht aus einer Reihe von Komponenten, mit deren Hilfe die IPSec-Sicherheitsanforderungen der Organisation durchgesetzt werden. Die folgende Abbildung zeigt die einzelnen Komponenten, aus denen sich eine IPSec-Richtlinie zusammensetzt, und deren Beziehungen untereinander.

Abbildung 5.2: Komponenten einer IPSec-Richtlinie

Bild in voller Größe anzeigen

Die IPSec-Richtlinie fungiert als Behälter für die Regeln, mit denen festgelegt wird, welcher Netzwerkkommunikationsverkehr zugelassen wird und wie die Zulassung erfolgt. Jede Regel besteht aus einer Filterliste und einer zugehörigen Aktion. Die Filterliste enthält mehrere Filter. Wenn die übertragenen Daten die Kriterien eines bestimmten Filters erfüllen, wird die zugehörige Filteraktion ausgelöst. Darüber hinaus legen die Regeln fest, welche Authentifizierungsmethoden zwischen den Hosts verwendet werden.

Die Grafik zeigt die Richtlinienkomponenten hierarchisch von oben nach unten geordnet. Die Richtlinien lassen sich aber am effektivsten erstellen, wenn mit den Filtern und Filterlisten begonnen wird, da diese Komponenten die Grundbausteine darstellen und bestimmen, welcher Datenverkehr gesichert wird.

IPSec-Filterlisten

IPSec-Filterlisten sind Zusammenstellungen von Filtern mit entsprechenden Kriterien, die auf den Netzwerkverkehr angewendet werden. Jeder Filter in der Filterliste definiert Folgendes:

• Quell- und Zielnetzwerke bzw. -adressen
• Protokoll(e)
• Quell- und Ziel-TCP- bzw. -UDP-Ports

Filterlisten und Filteraktionen gelten für mehrere IPSec-Richtlinien gleichzeitig. Dieser Ansatz ermöglicht es, eine Filterliste für einen bestimmten Ausnahmetyp zu unterhalten und in der bestimmten IPSec-Richtlinie für die jeweilige Isolierungsgruppe zu verwenden. Die Filter selbst, aus denen die Filterlisten bestehen, können jedoch nicht von den verschiedenen Filterlisten gemeinsam genutzt werden. Wenn zwei Filterlisten identische Filter enthalten, müssen die Filter für jede Filterliste separat (also zweimal) erstellt werden.

Der IPSec-Administrator sollte in jedem Fall Filterdubletten in einer IPSec-Richtlinie vermeiden, da die Filter unterschiedliche Aktionen auslösen könnten. Der IPSec-Dienst kann die Reihenfolge doppelt vorkommender Filter ändern, was sich auf die Paketverarbeitung auswirkt und zu inkonsistenten Ergebnissen führen kann. Filterdubletten können bei Bedarf verwendet werden, wenn die Filter genau dieselbe Aktion auslösen, wie z. B. Zulassen oder Blockieren, und wenn dadurch nicht die Arbeitsgeschwindigkeit beeinträchtigt wird.

Anhand der vorab zusammengetragenen Netzwerkinformationen werden die verschiedenen Verkehrsmuster identifiziert, die der Administrator absichern möchte. Darüber hinaus bilden diese Informationen die Grundlage für die Identifizierung von Datenverkehr, der u. U. von den IPSec-Einschränkungen auszunehmen ist.

Die folgende Tabelle enthält einige einfache Filterlisten, wie sie in einer typischen Organisation vorhanden sein könnten. Je nach den Geschäftsanforderungen der Organisation und der dort vorhandenen Netzwerkstruktur sind möglicherweise zusätzliche Filterlisten erforderlich.

Tabelle 5.1: Von der Lösung bereitgestellte Filterlisten

Filterliste	Beschreibung
Liste der sicheren Subnetze	Enthält alle Subnetze in der Organisation, die mit IPSec abgesichert werden.
DNS-Ausnahmeliste	Enthält die IP-Adressen der DNS-Server, für die eine Kommunikation ohne IPSec zugelassen werden soll.
Domänencontroller-Ausnahmeliste	Enthält die IP-Adressen der Domänencontroller, für die eine Kommunikation ohne IPSec zugelassen werden soll.
WINS-Ausnahmeliste	Enthält die IP-Adressen der WINS-Server, für die die Kommunikation ohne IPSec zugelassen werden soll.
DHCP, Aushandlungsverkehr	Enthält den Filter, der den DHCP-Aushandlungsverkehr (Dynamic Host Configuration Protocol) über UDP 68 zulässt.
ICMP, gesamter Verkehr	Enthält den Filter, der die Verwendung von ICMP (Internet Control Message Protocol) zu Fehlerbeseitigungszwecken in der Organisation zulässt.

Die Liste der sicheren Subnetze enthält alle Subnetze, die im internen Netzwerk der Organisation vorhanden sind. Diese Filterliste ist mit einer Filteraktion verbunden, die die für eine bestimmte Isolierungsgruppe erforderlichen Aktionen implementiert. Bei dieser Aktion handelt es sich um die allgemeinste Sicherheitsaktion für den gesamten Netzwerkverkehr für dieses Subnetz (z. B. IPSec aushandeln), weil die anderen Filter, wie beispielsweise der Filter für ICMP, spezifischer sind, um eine andere Aktion zu erfordern (wie z. B. Zulassen). Wichtig ist, daran zu denken, dass bei diesem Ansatz keine nicht vertrauenswürdigen oder Nicht-IPSec-Hosts in diesen Subnetzen vorhanden sein dürfen.

Die Filter müssen die Sicherheitsanforderungen sowohl für den eingehenden als auch für den ausgehenden Verkehr implementieren. Beim Definieren der Filter sollten diese als gespiegelt konfiguriert werden. Durch das Spiegeln wird sichergestellt, dass der Verkehr auch dann gefiltert wird, wenn genau die umgekehrten Quell- und Zieladressen verwendet werden. Beim Beschreiben von Filtern wird mithilfe des Symbols "<->" angegeben, dass der Filter gespiegelt ist. Gespiegelte Filter müssen immer dann verwendet werden, wenn die Filteraktion Sicherheitsmethoden für die IPSec-Verkapselung aushandelt.

Quell- und Zieladressen

Jeder Filter besitzt für die Quell- und für die Zieladresse jeweils eine eigene Einstellung. In Windows XP und Windows Server 2003 gibt es mehr Optionen für Adressen als in Windows 2000. Wenn eines der Mitglieder in der Domäne unter Windows 2000 läuft, sollten daher ausschließlich Windows 2000-Einstellungen verwendet werden. Windows 2000 bietet die folgenden Einstellungen:

• Eigene IP-Adresse. Diese Option wurde so konzipiert, dass eine gemeinsame IPSec-Richtlinie in Active Directory auf viele oder alle Computer anwendbar ist, und dies unabhängig davon, ob die Computer eine statische IP-Adresse oder eine DHCP-zugewiesene Adresse besitzen. Damit eine zentralisierte Richtlinienzuweisung über die Domäne möglich ist, unterstützt IPSec keine Filterkonfiguration für physische Netzwerkschnittstellen, sondern nur für den Schnittstellentyp (wie LAN oder WAN), also z. B. für DFÜ- oder VPN-Schnittstellen. Die Verwendung von Eigene IP-Adresse führt dazu, dass die generischen IPSec-Richtlinienfilter in einen spezifischen Filter kopiert werden, der alle vom Computer zu dem Zeitpunkt verwendeten IP-Adressen enthält, zu dem der IPSec-Dienst die Umsetzung der Richtlinie vorbereitet. Darüber hinaus erkennt der IPSec-Dienst bei der Verwendung dieser Option Adressänderungen bzw. neue Netzwerkschnittstellen, so dass die richtige Anzahl an Filtern beibehalten werden kann. Wenn ein Computer eine Netzwerkkarte mit zwei für diese Karte konfigurierten IP-Adressen besitzt, werden unter Verwendung dieser beiden IP-Adressen zwei verschiedene IPSec-spezifische Filter erstellt.

• Beliebige IP-Adresse. Diese Option führt dazu, dass die IPSec-Filter alle IP-Adressen als Filterkriterium verwenden.

• Spezieller DNS-Name. Diese Option veranlasst, dass IPSec die IP-Adresse des angegebenen DNS-Namens auswertet und dann die Filter unter Verwendung dieser IP-Adresse(n) erstellt. Das Ergebnis ist dasselbe, als hätte der Administrator die IP-Adresse(n) in den bzw. die Filter eingegeben. Während der Erstellung des anfänglichen Filters wird der DNS-Name aufgelöst, und die entsprechenden IP-Adressen werden in den Filter platziert. Wenn der DNS-Server einen falschen Ressourceneintrag für den im Filter angegebenen DNS-Namen besitzt, wird dem Filter die falsche IP-Adresse hinzugefügt.

  Hinweis

  
  Nachdem die Filter zum ersten Mal in der Richtlinie erstellt wurden, erfolgt keinerlei Auswertung des DNS-Namens mehr.

  Die Option der Angabe eines DNS-Namens empfiehlt sich, wenn Sie zahlreiche Filter erstellen müssen, da der DNS-Name viele zugehörige IP-Adressen besitzt, z. B. für jeden Domänencontroller in der Domäne. Das automatische Erstellen von Filtern, die für einen bestimmten DNS-Namen auf dem aktuellen Stand der Liste der IP-Adressen gehalten werden, ist nicht möglich.

• Spezifische IP-Adresse. Bei dieser Option wird der Verkehr mit der IP-Adresse abgeglichen, die dem Filter bereitgestellt wird.

• Spezielles IP-Subnetz. Diese Option ermöglicht es dem Administrator, ein spezifisches Subnetz zu konfigurieren. Jede IP-Adresse innerhalb des angegebenen Subnetzes wird mit den Filterkriterien abgeglichen. Diese Option sollte nur mit Vorsicht verwendet werden, vor allem dann, wenn eine Ausnahme für ein Subnetz erstellt wird, weil diese Ausnahme auch für böswillige Benutzer gilt, die über betrügerische Maßnahmen an eine IP-Adresse aus diesem Subnetz gelangen.

  Hinweis

  
  In Windows XP und Windows Server 2003 stehen zusätzliche Adressoptionen sowie eine Reihe weiterer Optionen zur Verfügung. Wenn ein und dieselbe IPSec-Richtlinie auf mehrere Plattformen angewendet wird, muss der Administrator sicherstellen, dass im Richtlinienentwurf ausschließlich Windows 2000-Optionen verwendet werden.
  

Protokolle

Neben der Konfiguration von Quell- und Zieladressen kann jeder Filter auch so konfiguriert werden, dass er Verkehr mit einem bestimmten Protokoll oder Port abgleicht. Standardmäßig wird Verkehr auf allen Protokollen und Ports gefiltert. Wenn als Teil der Filterkriterien ein bestimmtes Protokoll, das Ports unterstützt, ausgewählt ist, hat der Administrator die Möglichkeit, auch Quell- und Zielports zu konfigurieren.

Quell- und Zielports

Filter können zwar für eine Prüfung der TCP- bzw. UDP-Ports konfiguriert werden, aber im Rahmen dieser Lösung wird von der Erstellung portspezifischer Filter abgeraten. Die Portfilterung erhöht den administrativen Aufwand und die Komplexität der Konfiguration der IPSec-Filter beträchtlich und kann eine komplexe Koordination zwischen Client- und Serverrichtlinien für IKE erforderlich machen, damit die Sicherheit erfolgreich ausgehandelt wird. Da diese Lösung davon ausgeht, dass die Kommunikation zwischen vertrauenswürdigen Computern auch tatsächlich vertrauenswürdig ist, lassen die Filter zu, dass der gesamte Verkehr (außer ICMP) durch IPSec abgesichert wird. Falls die Portfilterung auf dem vertrauenswürdigen Host erforderlich ist, finden Sie in der Datei Business_Requirements.xls die Sicherheitsanforderungen, die durch die Verwendung einer Kombination aus IPSec und einer oberhalb der IPSec-Ebene befindlichen hostbasierten Firewall (wie z. B. der Windows Firewall) erfüllt werden.

Um eine Reihe der in Anhang A erwähnten Probleme im Zusammenhang mit dem Verhalten der Filter bei Verwendung der Option "Eigene IP-Adresse" zu umgehen, verwendet diese Lösung für das Woodgrove Bank-Szenario Filter vom Typ "Beliebige <-> Subnetz". Es wird eine Filterliste erstellt, die aus mehreren Filtern vom Typ "Beliebige IP-Adresse <-> Spezielles IP-Subnetz" besteht und in der alle Subnetze der Organisation ausdrücklich aufgelistet sind. Auf diese Weise kann der Administrator die jeweiligen Subnetze definieren, die abgesichert werden sollen. Jeglicher Verkehr außerhalb der angegebenen Subnetze wird von keinem der IPSec-Filter herausgefiltert und kann als Klartext an den Zielhost weitergesendet werden.

Weitere Empfehlungen zur Gestaltung von Filtern finden Sie im Abschnitt "Best Practices" des "IT Showcase"-Whitepapers Improving Security with Domain Isolation: Microsoft IT implements IP Security (IPsec) in Microsoft TechNet unter www.microsoft.com/technet/itsolutions/msit/
security/ipsecdomisolwp.mspx (in englischer Sprache).

Überlegungen zur Ausnahmeliste

Ein Teil des Verkehrs kann aus Support-, technischen oder geschäftlichen Gründen nicht durch IPSec geschützt werden. Darüber hinaus ist es möglich, dass Computer, auf denen das Windows-Betriebssystem nicht ausgeführt wird, IPSec gar nicht unterstützen bzw. IPSec darauf nicht so ohne weiteres bereitgestellt werden kann. Computer, auf denen eine ältere Windows-Version läuft (Microsoft Windows NT® 4.0, Windows 95, Windows 98 usw.), können kein gruppenrichtlinienbasiertes IPSec verarbeiten. Und unverwaltete Computer, auf denen Windows 2000 oder später ausgeführt wird, können nur an der IPSec-Aushandlung teilnehmen, wenn die Richtlinien manuell auf die einzelnen Computer angewendet und eine andere Form der Authentifizierung als das Protokoll Kerberos 5 verwendet werden (z. B. vorinstallierter Schlüssel oder Zertifikat).

Darüber hinaus muss der jeweilige Computer unter Windows 2000 oder höher an das Netzwerk angeschlossen und in der Lage sein, eine IPSec-Richtlinie von der Domäne abzurufen, damit IPSec verwendet werden kann. Derzeit müssen die unterstützenden Infrastrukturdienste von der IPSec-Absicherung ausgenommen werden, um eine Netzwerkverbindung herstellen, nach einem Domänencontroller suchen und die Richtlinie abrufen zu können. Zu diesen Diensten gehören die Namensdienste, wie z. B. DNS und WINS, sowie die Domänencontroller selbst.

Über diese Infrastrukturdienste hinaus können in der Organisation aber noch weitere Dienste vorhanden sein, die kein IPSec unterstützen. So bieten z. B. Thin-Clients oder andere Bootstrap-Clients, die ein Image von den ADS (Advanced Deployment Services) oder RIS (Remote Installation Services) downloaden müssen, keine IPSec-Unterstützung. Wenn in Ihrem Netzwerk Server vorhanden sind, die diese Dienste bereitstellen, sollten Sie prüfen, ob Sie sie auf eine Ausnahmeliste setzen oder in die Isolierungsgruppe "Domänengrenze" aufnehmen sollten, damit sie Netzwerkkommunikation von Hosts akzeptieren können, die nicht in der Lage sind, IPSec zu verwenden.

Wenn ein Client nicht in der Lage ist, an der IPSec-Infrastruktur teilzunehmen, er aber auf einen Server zugreifen muss, der IPSec verwendet, müssen Sie eine Methode implementieren, die den Aufbau eines Kommunikationspfades zulässt. Die Lösung in diesem Leitfaden verwendet Ausnahmefilterlisten, um diese Verkehrsanforderungen durch Genehmigungen zu steuern. Ausnahmelisten werden in die IPSec-Infrastruktur integriert, um sicherzustellen, dass die gesamte erforderliche Hostkommunikation erfolgen kann, auch wenn keine IPSec-Aushandlungen stattfinden können.

Ausnahmelisten werden verwendet, um Verkehr selektiv von der Teilnahme an der IPSec-Infrastruktur auszuschließen. Dazu wird Verkehr zugelassen, der den Filterkriterien der Ausnahmelisten entspricht. Diese Listen müssen sorgfältig erstellt werden, da sie die von IPSec implementierten Sicherheitsmechanismen umgehen. Wird z. B. ein Server, der typischerweise durch die Verwendung von Verschlüsselung abgesichert wird (um proprietäre Informationen zu schützen), auf eine Ausnahmeliste gesetzt, können Gastcomputer ohne Verwendung von IPSec direkt mit dem Server kommunizieren.

Die Ausnahmelisten werden als Filterlisten implementiert, um die Listengröße zu minimieren und damit die Konfiguration der Benutzeroberfläche zu vereinfachen. So sollten Sie z. B. eine Filterliste haben, die die Filter für alle Domänencontroller oder für die Domänencontroller in den einzelnen Domänen enthält. Das Einrichten mehrerer Filterlisten hat außerdem den Vorteil, dass die Zulassungsregel problemlos für jede Filterliste in der IPSec-Richtlinie aktiviert bzw. deaktiviert werden kann.

Beim Entwerfen einer Regel zum Implementieren der Ausnahme in den IPSec-Richtlinien ist es das Ziel, so wenig wie möglich Verkehr zuzulassen, der nicht von IPSec geschützt wird. Hinsichtlich der Komplexität und der Größe der IPSec-Richtlinie zum einen und der Sicherheit, die durch die meisten spezifischen Filter erzielt wird, zum anderen sind jedoch Kompromisse nötig. Beachten Sie, dass alle Domänencontroller-IP-Adressen in allen vertrauenswürdigen Gesamtstrukturen auf die Ausnahmeliste gesetzt werden müssen, damit die Clients in einer Domäne oder Gesamtstruktur in der Lage sind, Kerberos-Tickets für Server in einer anderen vertrauenswürdigen Domäne oder Gesamtstruktur zu erwerben. Der Windows-Kerberos-Client benötigt sowohl auf den eigenen Domänencontrollern als auch auf den Domänencontrollern in anderen Domänen Verkehr vom Typ ICMP, LDAP-UDP 389 sowie Kerberos UDP 88 und TCP 88. Domänenmitglieder benötigen darüber hinaus noch zusätzliche Arten von Verkehr mit den Domänencontrollern der eigenen Domäne, wie z. B. SMB TCP 445, RPC und LDAP-TCP 389. Wenn die Sicherheitsanforderungen nicht extrem sind, wird die Ausnahme aus Gründen der Einfachheit und zur Verringerung der Anzahl der Filter für den "gesamten Verkehr" mit den Domänencontroller-IP-Adressen implementiert.

Es besteht die Versuchung, Ausnahmen für bestimmten Anwendungsverkehr statt nach der Zieladresse nach dem Port festzulegen, um so keine Adressliste unterhalten zu müssen. Ein Beispiel dafür wäre ausgehender Telnet-Verkehr, der für den Zugriff auf UNIX-Systeme den TCP-Port 23 verwendet. Für den ausgehenden Verkehr wäre z. B. folgende Ausnahme denkbar:

Eigene IP-Adresse an Beliebige IP-Adresse, TCP, Quellport Beliebig, Zielport 23, gespiegelt

Der entsprechende Filter für eingehenden Verkehr würde dann wie folgt aussehen:

Beliebige IP-Adresse an Eigene IP-Adresse, TCP, Quellport 23, Zielport Beliebig

Dieser Filter für eingehenden Verkehr würde Antworten von Telnet-Verbindungsanforderungen zulassen, er würde es aber auch einem Angreifer gestatten, die IPSec-Authentifizierungsanforderungen zu umgehen und auf alle geöffneten Ports auf dem Host zuzugreifen. Organisationen müssen daher das Sicherheitsrisiko eines potenziellen Angriffs sorgfältig analysieren, bevor sie diesen Filterentwurf verwenden. Das Risiko wird auf jeden Fall minimiert, wenn die Ziel-IP-Adresse angegeben wird. Dieselbe Situation kann sich auch ergeben, wenn die Standardausnahme für das Kerberos-Authentifizierungsprotokoll nicht deaktiviert ist. Eine ausführliche Erörterung des Entwurfs von Standardausnahmen und deren Auswirkungen auf die Sicherheit finden Sie in den Microsoft Knowledge Base-Artikeln 811832 unter https://support.microsoft.com/?kbid=811832 und 810207 unter https://support.microsoft.com/?kbid=810207. Sie sollten die IPSec-Richtlinien mit der Maßgabe entwerfen, dass keine Standardausnahmen aktiviert sind.

Wenn Systemadressen auf eine Ausnahmeliste gesetzt werden, werden diese Systeme wirksam von der Teilnahme als IPSec-Hosts für alle IPSec-Richtlinien ausgenommen, die die Ausnahmeliste implementieren. Da die meisten Clients in der Organisation (einschließlich der Gastclients) in der Regel Zugriff auf Infrastrukturdienste wie DHCP, DNS oder WINS benötigen, werden die Server, die diese Dienste bereitstellen, normalerweise auf diese Weise implementiert.

Woodgrove Bank-Filterlisten

Nach der in Kapitel 4 erfolgten Analyse der Verkehrsanforderungen haben die Woodgrove Bank-Administratoren folgende Filterlisten aufgestellt:

Tabelle 5.2: Beispielfilterlisten für die Woodgrove Bank

Filterliste	Definierte Filter	Protokoll bzw. Port
Sichere Subnetze	Beliebig <-> 192.168.1.0/24 Beliebig <-> 172.10.1.0/24	Alle
DNS-Ausnahmeliste	Beliebig <-> 192.168.1.21 Beliebig <-> 192.168.1.22	Alle
Domänencontroller-Ausnahmeliste	Beliebig <-> 192.168.1.21 Beliebig <-> 192.168.1.22	Alle
Ausnahmeliste LOB-Anwendungsserver	Beliebig <-> 192.168.1.10	Alle
WINS-Ausnahmeliste	Beliebig <-> 192.168.1.22	Alle
DHCP, Aushandlungsverkehr	Eigene IP-Adresse <-> Beliebig	UDP Quelle 68, Ziel 67
ICMP, gesamter Verkehr	Eigene IP-Adresse <-> Beliebig	Nur ICMP

Bei der Erstellung dieser Filterlisten sind die Entwickler der Woodgrove Bank den Empfehlungen in diesem Kapitel gefolgt. Die erste Liste ("Sichere Subnetze") besteht aus den folgenden beiden Filtern:

• Beliebig <-> 192.168.1.0/24
• Beliebig <-> 172.10.1.0/24

Diese Subnetzfilter werden gespiegelt, um sowohl den eingehenden als auch den ausgehenden Verkehr zu filtern, und sie wurden so konfiguriert, dass sie bei jedem Protokoll ausgelöst werden. In Verbindung mit der entsprechenden Filteraktion implementiert diese Filterliste die Isolierungsgruppen.

Die Entwickler der Woodgrove Bank haben sich dann dafür entschieden, eine Ausnahmeliste für den ICMP-Netzwerkverkehr zu implementieren. Diese Filterliste besteht aus einem einzigen gespiegelten Filter ("Eigene IP-Adresse <-> Beliebig"), der nur für ICMP-Netzwerkverkehr konfiguriert ist. Diese Herangehensweise erlaubt es Administratoren, zur Fehlerbeseitigung in der Umgebung Ping zu verwenden, und zwar unabhängig davon, ob eine IPSec-Sicherheitszuordnung (Security Association, SA) ausgehandelt wurde. Außerdem war dieser Ansatz auch nötig, da diese Lösung nur mit Pfad-MTU-Ermittlung (Maximum Transmission Unit oder maximale Übertragungseinheit) ordnungsgemäß funktioniert. Für den DHCP-Verkehr erstellten die Woodgrove Bank-Entwickler einen neuen Filter für den UDP-Port 68, um für DHCP-Clients den Empfang von Verkehr vom DHCP-Server zuzulassen.

Zusätzlich besaß die Woodgrove Bank noch einige LOB-Anwendungen (Line of Business), die auf Servern ausgeführt wurden, die nicht an der IPSec-Infrastruktur teilnehmen können. Um diese Dienste weiter verwenden zu können, wurde eine neue Ausnahmefilterliste mit dem Namen "Ausnahmeliste LOB-Anwendungsserver" erstellt und ein Filter "Beliebig <-> 192.168.1.10" für das System hinzugefügt, das die LOB-Anwendung hostet.

Zuletzt hat das Woodgrove Bank-Entwurfsteam seine Infrastrukturdienste identifiziert und die entsprechenden Ausnahmefilterlisten erstellt, um allen Clients unabhängig von den IPSec-Einstellungen für die Isolierungsgruppen die direkte Kommunikation mit den Servern zu erlauben, die diese Dienste bereitstellen. Für die folgenden Dienste wurden spezifische Ausnahmelisten erstellt:

• DNS. Diese Liste erklärt die DNS-Server zu Ausnahmen, so dass alle Clients im Netzwerk Domänennamensuchen durchführen können.
• Domänencontroller. Mit dieser Liste können sich die der Domäne zugehörigen Systeme bei einem Domänencontroller authentifizieren.
• WINS. Mit dieser Liste können Hostgeräte NetBIOS-Namen auf einem WINS-Server nachschlagen.

Diese Filterlisten enthalten gespiegelte Filter, die "Beliebig <-> Spezifische IP-Adresse" definieren. Sie sind so konfiguriert, dass sie bei jedem Protokoll ausgelöst werden. Die Anzahl der Computer in den Ausnahmefilterlisten sollte auf ein Minimum beschränkt werden, da für diese Computer sämtlicher Verkehr ausgenommen ist und alle in der Ausnahmeliste befindlichen Computer uneingeschränkten TCP/IP-Zugriff auf alle vertrauenswürdigen Hosts in der Isolierungsdomäne besitzen. Folglich kann diese Herangehensweise eine größere Angriffsfläche bieten, als andernfalls vorhanden wäre. Genaue Informationen zu den Anforderungen für das Verringern des Risikos bei eingehendem Verkehr von IP-Adressen, die auf der Ausnahmeliste stehen, finden Sie in der Tabelle Business_Requirements.xls (im Ordner "Tools and Templates").

Die Woodgrove Bank hat sich dafür entscheiden, zwei separate Listen, eine für DNS-Server und eine für Domänencontroller, zu unterhalten, obwohl die IP-Adressen identisch sind. Dieser Ansatz wurde gewählt, weil beide Filterlisten dieselbe Aktion Zulassen haben sollen. Außerdem verwendet das Woodgrove-Produktionsnetzwerk in einigen Bereichen DNS-Server, die nicht gleichzeitig Domänencontroller sind.

Für den Filter für DHCP werden keine spezifischen Ziel-IP-Adressen festgelegt, sondern bei ihm wird der gesamte ausgehende DHCP-Clientverkehr abgeglichen. Der Spiegel dieses Filters lässt Antworten von DHCP-Servern zu. Wie bereits erläutert, könnte er daher auch eingehende Angriffe von beliebigen IP-Adressen zulassen, die den Quellport 67 verwenden. Ein solcher eingehender Angriff wäre aber auf den Zielport 68 des Clients beschränkt, den der DHCP-Client gar nicht verwendet. Die Woodgrove Bank hat sich für diesen Entwurf entschieden, um nicht Filter für jeden DHCP-Server erstellen zu müssen und weil das Risiko von eingehenden Angriffen über den DHCP-Clientport oder das Risiko durch nicht autorisierte DHCP-Server als nicht allzu hoch beurteilt wurde.

Dieser Abschnitt enthält keine vollständige Beschreibung der einzelnen Filter. Dennoch empfiehlt es sich, dass Filterbeschreibungsfeld zum sorgfältigen Definieren der einzelnen Filter zu verwenden, da die IPSec-Überwachungs- und -Befehlszeilenprogramme die Beschreibung der einzelnen Filter und nicht die Informationen in der Filterliste anzeigen.

IPSec-Filteraktionen

Die Filteraktionen legen fest, was mit IP-Paketen geschieht, nachdem festgestellt wurde, dass sie die Kriterien einer der Filter in der Filterliste erfüllen. Filteraktionen bilden die Grundlage für die Implementierung der verschiedenen Isolierungsgruppen. Mit dem Windows-Betriebssystem werden drei Standardfilteraktionen bereitgestellt. Es empfiehlt sich jedoch, diese Standardaktionen zu entfernen und neue Filteraktionen zu erstellen. Auf diese Weise können Sie sicherstellen, dass nur die Aktionen verwendet werden, die Sie im Rahmen Ihres Entwurfs erstellen. Jede Filteraktion setzt sich aus einem Namen, einer Beschreibung und einer Sicherheitsmethode zusammen.

Name

Geben Sie der Filteraktion einen aussagekräftigen Namen, aus dem hervorgeht, worin die Filteraktion besteht.

Beschreibung

Geben Sie im Beschreibungsfeld eine detaillierte Beschreibung für das Verhalten der Filteraktion ein.

Sicherheitsmethoden

Die Sicherheitsmethoden, die im Rahmen der Filteraktion implementiert werden, richten sich nach den Anforderungen für die Verarbeitung von Paketen, die den zugehörigen Filtern in der Filterliste entsprechen. Die folgenden drei Optionen sind verfügbar:

• Blockieren. IP-Pakete, die den Kriterien des zugehörigen Filters entsprechen, werden blockiert. Das bedeutet, dass das betreffende Paket verworfen oder ignoriert wird.
• Zulassen. IP-Paketen, die den Kriterien des zugehörigen Filters entsprechen, wird gestattet, die IPSec-Ebene ohne weitere Verarbeitung durch IPSec zu passieren.
• Aushandeln. Wenn die Filterkriterien von ausgehenden Paketen erfüllt werden, versucht IPSec, eine der in der Filteraktion vorhandenen Sicherheitsmethoden auszuhandeln, wobei nach der relativen Reihenfolge vorgegangen wird. Je höher die Sicherheitsmethode in der Liste steht, desto höher ist ihre Präferenz. Jede Sicherheitsmethode kann festlegen, ob Integrität verwendet und die Verschlüsselung aktiviert werden soll und welche Verschlüsselungsalgorithmen verwendet werden sollen, um die Funktionalität zur Verfügung zu stellen. Wie mit eingehenden Paketen verfahren wird, die die Kriterien eines Filters mit einer Aushandlungsaktion erfüllen, hängt von der Einstellung Unsichere Kommunikation annehmen, aber immer mit IPSec antworten ab.

Die folgende Tabelle enthält eine Übersicht über die möglichen Verschlüsselungsoptionen für die einzelnen Sicherheitsmethoden:

Tabelle 5.3: Sicherheitsmethoden und Verschlüsselungsoptionen

Sicherheitsmethode	Verschlüsselungsoption	Beschreibung
AH (Authentication Header)	MD5 SHA-1	Ermöglicht die Prüfung der Integrität und Authentizität des IP-Aufkommens (Daten) und des IP-Headers (Adresse) ohne Verschlüsselung. AH bietet keine Unterstützung für Verkehr, der NAT-Geräte durchläuft.
ESP Integrität	<Keine> MD5 SHA-1	Ermöglicht die Prüfung der Integrität und Authentizität des IP-Aufkommens (Daten). Kann mit und ohne Verschlüsselung verwendet werden. Die Verwendung von ESP ohne Authentifizierung wird nicht empfohlen.
ESP Verschlüsselung	<Keine> 3DES DES	Mit DES oder 3DES; ermöglicht Verschlüsselung des IP-Aufkommens (Daten). Kann mit einem Null-Verschlüsselungsalgorithmus verwendet werden, falls keine Verschlüsselung notwendig ist.

Die IPSec-Implementierungen in Windows 2000 SP4, Windows XP SP2 und Windows Server 2003 unterstützen jetzt zusätzlich zu NAT-T für L2TP/IPSec-VPN-Clienttunnel auch NAT-T-Verfahren für IPSec-Transportmodus-ESP. Bei Windows 2000 SP4 muss die NAT-T-Aktualisierung installiert sein. Die Windows 2000- und Windows XP-Unterstützung für IPSec-Transportmodus-NAT-T beschränkt sich auf Windows 2000- und Windows XP-Versionen vor SP2, da die TCP-PMTU-Erkennung für IPSec-geschützten TCP-Verkehr nicht unterstützt wird. Windows Server 2003 bietet diese Unterstützung. NAT-T-Verfahren verwenden nach dem IP-Header einen UDP-Header, um ESP einzukapseln. IKE erkennt automatisch, wenn NAT im Pfad vorhanden ist, und verwendet UDP-ESP immer dann, wenn ESP in der Liste der Sicherheitsmethoden zugelassen ist. Darüber hinaus ist zu erwähnen, dass die aktuellen Windows-IPSec-Implementierungen nicht den AES-Verschlüsselungsstandard (Advanced Encryption Standard) der US-Regierung unterstützen. Dies wird sich in zukünftigen Windows-Versionen ändern.

Für AH und ESP sind die folgenden Kryptografieoptionen verfügbar:

• MD5. Dieser Hashalgorithmus verwendet einen kryptografischen 128-Bit-Schlüssel, um ein Digest des Paketinhalts zu generieren. MD5 gehört nicht zu den für die Verwendung durch US-Behörden genehmigten Sicherheitsalgorithmen.
• SHA-1. Dieser Hashalgorithmus verwendet einen leistungsfähigeren kryptografischen 160-Bit-Schlüssel, um ein Digest des Paketinhalts zu generieren. Die größere Schlüssellänge von SHA-1 bietet ein höheres Maß an Sicherheit, bringt aber auch einen höheren Verarbeitungsaufwand mit sich. SHA-1 gehört zu den für die Verwendung durch US-Behörden genehmigten Sicherheitsalgorithmen.

ESP kann so konfiguriert werden, dass kein Verschlüsselungsalgorithmus verwendet wird. In diesem Fall wird nur die Datenintegrität und -echtheit geprüft. Diese Konfiguration wird allgemein als "ESP Null" bezeichnet. Sie bietet die Möglichkeit, die Hosts zu authentifizieren, bevor eine Kommunikationsverbindung hergestellt und eine Integritätsprüfung des Datenteils des IP-Pakets durchgeführt wird, das innerhalb des ESP-Pakets transportiert wird.

ESP kann auch den Datenteil des IP-Pakets verschlüsseln. Dafür stehen die folgenden beiden Kryptografieoptionen zur Verfügung:

• DES. Diese Option verwendet einen einfachen 56-Bit-Schlüssel und verarbeitet jeden Block einmal. DES wird lediglich aus Gründen der Einhaltung der RFC-Vorgaben bereitgestellt. Diese Art der Verschlüsselung ist inzwischen nicht mehr ausreichend sicher und sollte daher nicht verwendet werden.
• 3DES. Diese Option verarbeitet jeden Block dreimal und verwendet dazu drei eindeutige 56-Bit-Schlüssel. Obwohl auch DES unterstützt wird, wird dringend empfohlen, aufgrund der höheren Sicherheit 3DES zu verwenden. Es ist jedoch zu beachten, dass 3DES etwas langsamer arbeitet und einen größeren Verarbeitungsaufwand als DES mit sich bringt.

Für den Fall, dass sehr hohe Sicherheitsanforderungen erfüllt werden müssen, können Sie die AH- und ESP-Protokolle miteinander kombinieren. Wenn z. B. zusätzlich zur Datenverschlüsselung die Prüfung der IP-Header-Integrität erforderlich ist, können Sie die Sicherheitsmethode so konfigurieren, dass AH mit SHA-1-Integrität und ESP-3DES-Verschlüsselung verwendet wird. Wenn nur eine Datenintegritätsprüfung erforderlich ist, können Sie ESP Null mit SHA-1 verwenden.

Sie können zwar die Sicherheitsoptionen beliebig miteinander kombinieren, dabei sollte aber berücksichtigt werden, dass AH sowohl die Daten- als auch die Adressheaderintegrität gewährleistet. Die Verwendung von AH und ESP zur Gewährleistung der Integrität bringt daher für die Paketdaten keinen zusätzlichen Integritätsschutz, sondern erhöht nur die Arbeitslast, die bei der Verarbeitung des Pakets entsteht. Darüber hinaus werden durch eine Kombination von ESP mit AH auch nicht die Probleme gelöst, die durch die fehlende NAT-Unterstützung bei AH entstehen. Daher sollte AH zusätzlich zu ESP nur in solchen Umgebungen eingesetzt werden, die allerhöchsten Sicherheitsanforderungen gerecht werden müssen.

Beim Entwerfen der Sicherheitsmethoden der Filteraktionen ist eine sorgfältige Planung erforderlich. Damit zwei Computer erfolgreich miteinander verhandeln können, müssen sie mindestens eine gemeinsame Sicherheitsmethode in ihren jeweiligen Filteraktionen besitzen. Jede Filteraktion kann mehrere Aushandlungsmethoden enthalten, damit auch verschiedene Arten der Aushandlung zulässig sind. Ein System könnte typischerweise z. B. nur ESP Null aushandeln, die Filteraktion könnte aber auch eine Aushandlungsmethode für ESP-3DES enthalten. Bei dieser Herangehensweise kann das System bei Bedarf eine Verbindung mit 3DES-Verschlüsselung aushandeln.

Neben den Sicherheitsmethoden können Sie, sofern erforderlich, auch die Sitzungsschlüsseleinstellungen für jede Sicherheitsmethode festlegen. In der Standardeinstellung läuft die Gültigkeitsdauer der IPSec-SAs ab, wenn 100 MB Daten weitergegeben wurden oder wenn eine Stunde vergangen ist. Diese Einstellungen steuern, wann ein neues Paar von IPSec-SAs durch den IKE-Schnellmodus neu ausgehandelt wird. Der IKE-Schnellmodusprozess wird als "erneute Schlüsselerstellung" bezeichnet, wobei aber nicht nur einfach die Schlüssel für ein vorhandenes IPSec-SA-Paar erneuert werden. Falls die Gültigkeitsdauer abgelaufen ist, muss IPSec Pakete verwerfen. Daher versucht IPSec bereits weit bevor die Kriterien für den Ablauf der Gültigkeitsdauer (Bytes oder Sekunden) erfüllt sind eine Neuaushandlung. Wenn die Gültigkeitsdauer zu kurz festgelegt ist, können Pakete verloren gehen. Gleichzeitig kann sich die CPU-Auslastung der Server erhöhen, die IPSec-SAs mit vielen Clients unterhalten. Mit der Erneuerung der IPSec-SAs wird sichergestellt, dass Angreifer auch dann nicht die gesamte Kommunikation entschlüsseln können, wenn sie es schaffen, einen der Sitzungsschlüssel zu knacken. Je höher die Gültigkeitsdauer ist, desto mehr Informationen zum Sitzungsschlüssel sind für den Angreifer verfügbar. Daher sollten Sie die Gültigkeitsdauern nur verlängern, wenn dies aus operativen Gründen erforderlich ist. Außerdem können Sie spezifische Sicherheitsanforderungen verfassen, mit denen ein angemessenes Maß an Absicherung gegen ausgeklügelte kryptografische Angriffe definiert wird.

Optionen für die Aushandlung der Sicherheit

In IPSec-Richtlinien können Sie die folgenden Optionen für die Aushandlung der Sicherheit festlegen:

• Eingehendes Passthrough
• Auf unsichere Kommunikation zurückgreifen
• Sitzungsschlüssel mit Perfect Forward Secrecy (PFS) verwenden

Eingehendes Passthrough

Die Option "Eingehendes Passthrough" ist für die Verwendung in einer internen Serverrichtlinie gedacht, damit Clientrichtlinien die nicht-behindernde Regel "Standardantwort" verwenden können. Bei Aktivierung dieser Option werden Anforderungen zum Aufbau von Klartextverbindungen akzeptiert, sofern die Anforderung die Kriterien eines Filters für eingehenden Verkehr erfüllt. Die serverseitige Antwort auf die Verbindungsanforderung erfüllt die Filterkriterien, so dass eine IKE-Hauptmodus-Aushandlungsanforderung an den Client ausgelöst wird.

Auf Computern, die mit dem Internet verbunden sind, sollten Sie diese Option nicht aktivieren, weil dann eingehende Angriffe die IPSec-Ebene passieren können. Die Option zwingt außerdem den Server, eine IPSec-SA-Aushandlung mit dem Quell-IP aller eingehenden Pakete zu versuchen. Durch Spoofing der Quell-IP-Adressen können Angreifer einen Denial-of-Service auf dem Server verursachen, so dass IKE Aushandlungen mit Hunderten oder Tausenden von ungültigen IP-Adressen versucht.

Zum Aktivieren der Option "Eingehendes Passthrough" wählen Sie im Dialogfeld Filteraktionen verwalten die Option Unsichere Kommunikation annehmen, aber immer mit IPSec antworten.

Auf unsichere Kommunikation zurückgreifen

Die Option "Auf unsichere Kommunikation zurückgreifen" steuert die Fähigkeit des (Quell-)Computers, das Senden von Verkehr ohne IPSec-Absicherung zuzulassen, wenn die anfängliche IKE-Hauptmodusaushandlung keine Antwort von einem Zielcomputer erhält. Hosts, die IPSec nicht unterstützen, sind nicht in der Lage, (mithilfe von IKE) auf die IKE-Aushandlungsanforderungen zu reagieren. Das Ausbleiben einer IKE-Hauptmodusantwort bedeutet aber nicht unbedingt, dass der Computer nicht IPSec-fähig ist; es könnte sich auch um einen IPSec-fähigen Computer handeln, der keine aktive IPSec-Richtlinie besitzt oder dessen aktive IPSec-Richtlinie nur die Aktionen "Zulassen" und "Blockieren" enthält. Es könnte auch sein, dass die aktive IPSec-Richtlinie nicht für Aushandlungen mit der IP-Adresse des Quellcomputers ausgelegt ist. In der IPSec-Terminologie wird Netzwerkverkehr, der kein IPSec verwendet, als Verkehr in Klartext bezeichnet. Wenn innerhalb von drei Sekunden keine Antwort vom Zielcomputer eintrifft, wird eine schwache Sicherheitszuordnung (schwache SA) erstellt, und die Kommunikation beginnt im Klartext. Bei Erstbereitstellungen empfiehlt es sich, diese Option zu aktivieren, damit die Clients mit Hosts kommunizieren können, auf denen IPSec nicht aktiviert ist. Die Aktivierung dieser Option hilft auch bei der vorübergehenden Wiederherstellung der Klartextkonnektivität, wenn der IPSec-Dienst für Problembehandlungszwecke gestoppt wird. Wenn der Zielcomputer aber eine IKE-Antwort bereitstellt und es bei der IKE-Aushandlung aus irgendeinem Grund zu einem Fehler kommt, verwirft IPSec auf dem Quellcomputer die ausgehenden Pakete und blockiert damit praktisch die Kommunikation.

Zum Aktivieren der Option "Auf unsichere Kommunikation zurückgreifen" wählen Sie im Dialogfeld Filteraktionen verwalten die Option Unsichere Kommunikation mit Computern zulassen, die IPSec nicht unterstützen.

Sitzungsschlüssel mit Perfect Forward Secrecy (PFS) verwenden

Mit der Option "Sitzungsschlüssel mit Perfect Forward Secrecy (PFS) verwenden" wird festgelegt, ob das Hauptschlüsselmaterial zur Generierung aller Sitzungsschlüssel oder nur zur Generierung des ersten Sitzungsschlüssels verwendet werden kann. Wenn diese Option aktiviert ist, kann der Hauptschlüssel nur einmal verwendet werden. Alle weiteren Neuaushandlungen von Sitzungsschlüsseln erfordern dann die Durchführung eines neuen Schlüsselaustauschs, bei dem ein neuer Hauptschlüssel erstellt wird. Erst dann kann der nächste Sitzungsschlüssel generiert werden. Durch diese Einschränkung wird sichergestellt, dass ein etwaiger Angreifer, der sich den Hauptschlüssel verschafft hat, keine weiteren Sitzungsschlüssel zum Entschlüsseln des Verkehrsstroms generieren kann. Das Aktivieren dieser Option wird jedoch aufgrund des zusätzlichen Aufwands für die Durchführung eines Schlüsselaustauschs für jede Erneuerung des Sitzungsschlüssels nicht empfohlen.

Weitere Informationen zu den Optionen "Eingehendes Passthrough" und "Auf unsichere Kommunikation zurückgreifen" sowie zu den Sitzungsschlüssel- und Hauptschlüssel-PFS-Optionen finden Sie im Abschnitt "Security Negotiation Options" in Using Microsoft Windows IPSec to Help Secure an Internal Corporate Network Server im Microsoft Download Center unter www.microsoft.com/downloads/details.aspx?
familyid=a774012a-ac25-4a1d-8851-b7a09e3f1dc9&displaylang=en (in englischer Sprache).

Woodgrove Bank-IPSec-Filteraktionen

Die folgende Tabelle enthält die Namen und Beschreibungen der Filteraktionen, die für die Implementierung der verschiedenen Isolierungsgruppen für das Woodgrove Bank-Szenario verwendet wurden:

Tabelle 5.4: IPSec-Filteraktionen mit Beschreibung

Filteraktion	Beschreibung
IPsec Block	Blockiert den Verkehr, der die Filterkriterien erfüllt.
IPsec Permit	Lässt den Verkehr zu, der die Filterkriterien erfüllt.
IPsec Request Mode (Accept Inbound, Allow Outbound)	Der Host akzeptiert eingehende Pakete, die IPSec-geschützt sind oder in Klartextform vorliegen. Bei ausgehendem Verkehr löst er eine IKE-Aushandlung aus und erlaubt bei Ausbleiben einer Antwort die Verwendung von Klartext ("Zurückgreifen auf unsichere Kommunikation" bzw. auch "Fallback" genannt). Diese Filteraktion wird zum Konfigurieren der Isolierungsgruppe "Domänengrenze" verwendet.
IPsec Secure Request Mode (Ignore Inbound, Allow Outbound)	Der Host lässt eingehenden TCP/IP-Zugriff nur dann zu, wenn die Pakete IPSec-gesichert sind. Eingehende Pakete, die nicht durch IPSec abgesichert sind, werden ignoriert. Bei ausgehendem Verkehr löst er eine IKE-Aushandlung aus und erlaubt bei Ausbleiben einer Antwort die Verwendung von Klartext. Diese Filteraktion dient zum Implementieren der Isolierungsdomäne, bei der ausgehende Verbindungen zu nicht vertrauenswürdigen Hosts zugelassen werden.
IPsec Full Require Mode (Ignore Inbound, Disallow Outbound)	Der Host fordert IPSec-Absicherung sowohl für eingehende als auch für ausgehende Pakete. Diese Filteraktion wird zum Implementieren der Isolierungsgruppe "Kein Klartext" verwendet, bei der die gesamte Kommunikation durch IPSec geschützt wird.
IPsec Require Encryption Mode (Ignore Inbound, Disallow Outbound)	Der Host lässt den eingehenden TCP/IP-Zugriff nur dann zu, wenn die Pakete durch IPSec-ESP-3DES-Verschlüsselung gesichert sind. Eingehende Pakete, die nicht durch IPSec abgesichert sind, ignoriert er. Bei ausgehendem Verkehr löst er eine IKE-Aushandlung aus, die IPSec-ESP-3DES-Verschlüsselung erfordert. Diese Filteraktion wird zum Implementieren der Isolierungsgruppe "Verschlüsselung" verwendet.

Die ersten beiden Filteraktionen sind nicht weiter kompliziert. Die Filteraktion "Blockieren" verwirft sämtlichen Verkehr, der den Kriterien einer der Filter in der Filterliste entspricht, die mit dieser Aktion verbunden ist. Die Filteraktion "Zulassen" lässt den Verkehr für alle verknüpften Filterlisten zu, die einen entsprechenden Filter enthalten. Die übrigen vier Filteraktionen in Tabelle 5.4 werden zum Implementieren der Isolierungsgruppen im Woodgrove Bank-Szenario verwendet.

Die Woodgrove Bank-Administratoren müssen vier Sicherheitsisolierungsgruppen implementieren. Zum Bereitstellen dieser Konfiguration müssen zusätzlich zu den Filteraktionen "Zulassen" und "Blockieren" mindestens drei weitere Filteraktionen mit benutzerdefinierten Sicherheitsaushandlungsmethoden definiert werden.

Die Woodgrove Bank stellt an die Isolierung der Computer untereinander innerhalb einer bestimmten Sicherheitsisolierungsgruppe keine weiteren Anforderungen. Die Bank hat daher bestimmt, dass die in der folgenden Tabelle aufgeführten vier ausgehandelten Filteraktionen für die Implementierung in ihrer Umgebung ausreichend sind:

Tabelle 5.5: Unterstützte Sicherheitsmethoden

Filteraktion	Unterstützte Sicherheitsmethoden
IPsec Request Mode (Accept Inbound, Allow Outbound)	ESP SHA-1, <Keine> ESP SHA-1, 3DES
IPsec Secure Request Mode (Ignore Inbound, Allow Outbound)	ESP SHA-1, <Keine> ESP SHA-1, 3DES
IPsec Full Require Mode (Ignore Inbound, Disallow Outbound)	ESP SHA-1, <Keine> ESP SHA-1, 3DES
IPsec Require Encryption Mode (Ignore Inbound, Disallow Outbound)	ESP SHA-1, 3DES

Woodgrove verwendet IPSec-ESP anstelle von AH, da Netzwerkgeräte im Einsatz sind, die NAT verwenden.

Außerdem war es erforderlich, für einige der Server im Unternehmen Verschlüsselung zu implementieren. Daher mussten sämtliche Richtlinien die Option zur Verwendung von Verschlüsselung beinhalten. Aus diesen Gründen hat sich die Woodgrove Bank entschlossen, ihre Sicherheit ausschließlich auf der Basis von IPSec-ESP zu implementieren.

Zur Wahrung der ESP-Integrität fiel die Entscheidung zugunsten von SHA-1 anstelle von MD5, da SHA-1 ein höheres Maß an Sicherheit bietet und außerdem den Vorgaben der US-Regierung für die Verarbeitung von Finanzinformationen entsprochen werden musste, zu denen auch die Verwendung genehmigter Algorithmen gehört.

Die Woodgrove Bank entschied sich gegen die Implementierung von PFS in den jeweiligen Filteraktionen, da keine spezifische Sicherheitsbedrohung vorhanden war, die die Verwendung von PFS erfordert hätte. Außerdem wollte man so eine Beeinträchtigung der Computerleistung vermeiden, zu der es durch die Neuaushandlung der Schlüssel gekommen wäre.

Filteraktion der Isolierungsdomäne

Zur Implementierung der Isolierungsdomäne wurde die Filteraktion "PSEC Secure Request Mode (Ignore Inbound, Allow Outbound)" erstellt.

Bei der Woodgrove Bank gibt es eine Reihe von Geschäftsanforderungen für die Kommunikation zwischen Hosts in der Isolierungsdomäne und anderen Isolierungsgruppen. Dementsprechend führen die Clients in der Isolierungsdomäne die folgenden Aktionen aus (eine Beschreibung der Aktionen finden Sie in den Tabellen 4.5 und 4.6 in Kapitel 4 dieses Leitfadens):

• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Kein Klartext"
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Kein Klartext"
• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Verschlüsselung"
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Verschlüsselung"
• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Domänengrenze"
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Domänengrenze"
• Initiieren von Kommunikationsanforderungen für nicht vertrauenswürdige Systeme

Clients in der Isolierungsdomäne können keine Kommunikationsanforderungen von nicht vertrauenswürdigen Systemen akzeptieren.

Wie bereits erwähnt, verwenden IPSec-Richtlinien Filter und Filteraktionen, um eingehende und ausgehende IP-Pakete abzufangen und deren Weiterleitung zu steuern. Obwohl IKE beide Computer authentifiziert, ist die Gruppenzugehörigkeit eines Computers mit einer bestimmten IP-Adresse zum Zeitpunkt, zu dem die erste Verbindungsanforderung nach außen gesendet wird, nicht bekannt. Daher können IPSec und IKE nicht ausdrücklich so konfiguriert werden, dass sie Kommunikation in einer bestimmten Weise mit einer konkreten Identitäts- oder Isolierungsgruppe initiieren. Darüber hinaus können Computer, die Mitglieder dieser Isolierungsgruppen sind, an einer beliebigen Stelle im internen Netzwerk befinden. Daher ist es nicht möglich, IP-Adressen zum genauen oder näherungsweise Definieren von Isolierungsgruppen zu verwenden.

Um diese Anforderungen in einer IPSec-Richtlinie zu implementieren, müssen Sie die Filteraktion so entwerfen, dass sie mit der Filterliste arbeitet, in der alle internen Subnetze angegeben sind. Die zuvor genannten Anforderungen lassen sich auf zwei Grundverhalten reduzieren:

• Ausgehend, für Pakete, die die entsprechenden Filterkriterien erfüllen (alle internen Subnetze) Auslösen von IKE-Aushandlungsanforderungen für den Versuch, den Verkehr per IPSec-ESP abzusichern, wobei ESP Null bevorzugt wird und ESP SHA-1 3DES zum Einsatz kommt. Wenn ein Zielhost nicht mit IKE antwortet, kann auf unsichere Kommunikation zurückgegriffen werden.
• Eingehend, für Pakete, die die entsprechenden Filterkriterien erfüllen (alle internen Subnetze) Ignorieren von Verkehr, der nicht bereits in gültigen IPSec-ESP-Paketen gesichert ist.

Um Kommunikation mit der Isolierungsgruppe "Verschlüsselung" zu ermöglichen, umfassen die Sicherheitsmethoden die für die Isolierungsgruppe "Verschlüsselung" definierten Sicherheitsmethoden (ESP SHA-1 3DES-Algorithmus). Weitere Informationen zu den Sicherheitsaushandlungsmethoden für die Isolierungsgruppe "Verschlüsselung" finden Sie im Abschnitt "Filteraktion der Isolierungsgruppe 'Verschlüsselung'" weiter unten in diesem Kapitel.

Für Verkehr innerhalb der Isolierungsdomäne und mit den Isolierungsgruppen "Domänengrenze" und "Kein Klartext" verwendet die Woodgrove Bank ESP Null mit SHA-1.

In der Filteraktion muss die Option Unsichere Kommunikation zulassen, aber immer mit IPSec antwortendeaktiviert werden, damit eingehender Klartext ignoriert wird. Auf diese Weise wird sichergestellt, dass Hosts in der Isolierungsdomäne keinen Verkehr von Computern akzeptieren, die nicht an der IPSec-Umgebung teilnehmen.

Die Filteraktion "IPSEC Secure Request Security (Ignore Inbound, Allow Outbound)" ist konfiguriert, um Mitgliedern der Isolierungsdomäne zu gestatten, Kommunikationsanforderungen für nicht vertrauenswürdige Systeme zu initiieren. Dieses Verhalten wird durch Aktivieren der Option Unsichere Kommunikation mit Computern zulassen, die IPSec nicht unterstützen in der Filteraktion implementiert. Wenn ein vertrauenswürdiger Host in der Isolierungsdomäne eine ausgehende Verbindung zu einem nicht vertrauenswürdigen Host (oder einem anderen System, das IPSec nicht unterstützt) initiiert, wird die schwache IPSec-SA erstellt. Diese bleibt noch fünf Minuten aktiv, nachdem der Verkehrsfluss zum Erliegen gekommen ist. Daher ist das nicht vertrauenswürdige System in dieser Zeit in der Lage, neue Klartextverbindungen zurück zum vertrauenswürdigen Host zu initiieren. Nachdem die schwache SA abgelaufen ist, akzeptiert der vertrauenswürdige Host keinen Klartextverkehr mehr von diesem System. Die IPSec-Filterung und die Unterstützung schwacher SAs ist, im Gegensatz zu vielen Firewalls, nicht dafür ausgelegt, verbindungsspezifische Absicherung, wie z. B. statusbehaftetes Filtern, bereitzustellen. Schwache SAs lassen sämtlichen Verkehr zu, der die Kriterien des zugehörigen Filters erfüllt. Weitere Informationen zu diesem Prozess finden Sie im Abschnitt "IKE-Hauptmodus-SAs und IPSec-SAs" in Anhang A, "Überblick über IPSec-Richtlinienkonzepte".

Filteraktion der Isolierungsgruppe "Domänengrenze"

Zur Implementierung der Isolierungsgruppe "Domänengrenze" haben die Woodgrove Bank-Administratoren die Filteraktion "IPSEC z. Request Mode (Accept Inbound, Allow Outbound)" erstellt.

Bei der Woodgrove Bank gibt es eine Reihe von Geschäftsanforderungen für die Kommunikation zwischen Hosts in der Isolierungsgruppe "Domänengrenze" und anderen Isolierungsgruppen. Dementsprechend können Clients in der Isolierungsgruppe "Domänengrenze" die folgenden Aktionen ausführen (eine Beschreibung der Aktionen finden Sie in den Tabellen 4.5 und 4.6 in Kapitel 4):

• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Kein Klartext"
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Kein Klartext"
• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsdomäne
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsdomäne
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Verschlüsselung"
• Initiieren von Kommunikationsanforderungen für nicht vertrauenswürdige Systeme
• Akzeptieren von Kommunikationsanforderungen von nicht vertrauenswürdigen Systemen

Um diese Anforderungen in einer IPSec-Richtlinie zu implementieren, müssen Sie die Filteraktion so entwerfen, dass sie mit der Filterliste arbeitet, in der alle internen Subnetze angegeben sind. Die genannten Anforderungen lassen sich auf zwei Grundverhalten reduzieren:

• Ausgehend, für Pakete, die die entsprechenden Filterkriterien erfüllen (alle internen Subnetze) Auslösen von IKE-Aushandlungsanforderungen für den Versuch, den Verkehr per IPSec-ESP abzusichern, wobei ESP Null bevorzugt wird und ESP SHA-1 3DES zum Einsatz kommt. Wenn ein Zielhost nicht mit IKE antwortet, kann auf unsichere Kommunikation zurückgegriffen werden.
• Eingehend Akzeptieren von Klartextpaketen, die die Kriterien der entsprechenden Filter erfüllen (alle internen Subnetze).

Um den Anforderungen für das Initiieren und Akzeptieren von Verkehr zu und von der Isolierungsdomäne und zu und von der Isolierungsgruppe "Kein Klartext" gerecht zu werden, wurde bei der Woodgrove Bank dafür gesorgt, dass die für die Isolierungsdomäne und die Isolierungsgruppe "Kein Klartext" verwendeten Sicherheitsaushandlungsmethoden in der Filteraktion enthalten sind. Als allgemeine Sicherheitsaushandlungsmethode wurde hierbei ESP mit SHA-1 zur Integritätsprüfung gewählt.

Hosts in der Isolierungsgruppe "Domänengrenze" dürfen mit nicht vertrauenswürdigen Systemen kommunizieren. Um dies zu ermöglichen, wurde für diese Filteraktion sowohl die Option Unsichere Kommunikation mit Computern zulassen, die IPSec nicht unterstützen als auch die Option Unsichere Kommunikation zulassen, aber immer mit IPSec antworten aktiviert. Durch das Aktivieren dieser beiden Optionen wurde dafür gesorgt, dass die Hosts unsicheren eingehenden Verkehr akzeptieren und in der Lage sind, bei ungesichertem ausgehenden Verkehr auf Klartextkommunikation zurückzugreifen.

Filteraktion der Isolierungsgruppe "Kein Klartext"

Zum Implementieren der Isolierungsgruppe "Kein Klartext" haben die Woodgrove Bank-Administratoren die Filteraktion "IPSEC Full Require Mode (Ignore Inbound, Disallow Outbound)" erstellt.

Bei der Woodgrove Bank gibt es eine Reihe von Geschäftsanforderungen für die Kommunikation zwischen Hosts in der Isolierungsgruppe "Kein Klartext" und anderen Isolierungsgruppen. Dementsprechend können Clients in der Isolierungsgruppe "Kein Klartext" die folgenden Aktionen ausführen:

• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsdomäne
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsdomäne
• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Verschlüsselung"
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Verschlüsselung"
• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Domänengrenze"
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Domänengrenze"

Clients in der Isolierungsgruppe "Kein Klartext" können keine Kommunikation mit nicht vertrauenswürdigen Systemen initiieren und auch keine Kommunikation von diesen akzeptieren.

Um diese Anforderungen in einer IPSec-Richtlinie zu implementieren, müssen Sie die Filteraktion so entwerfen, dass sie mit der Filterliste arbeitet, in der alle internen Subnetze angegeben sind. Die genannten Anforderungen lassen sich auf zwei Grundverhalten reduzieren:

• Ausgehend, für Pakete, die die entsprechenden Filterkriterien erfüllen (alle internen Subnetze) Auslösen von IKE-Aushandlungsanforderungen für den Versuch, den Verkehr per IPSec-ESP abzusichern, wobei ESP Null bevorzugt wird und ESP SHA-1 3DES zum Einsatz kommt. Wenn ein Zielhost nicht mit IKE antwortet, darf nicht auf unsichere Kommunikation (Klartext) zurückgegriffen werden.
• Eingehend, bei Klartextpaketen, die die Kriterien der entsprechenden Filter erfüllen (alle internen Subnetze) Ignorieren.

Um Kommunikation mit der Isolierungsgruppe "Verschlüsselung" zu ermöglichen, enthalten die Sicherheitsaushandlungsmethoden die Verschlüsselungsaushandlungsmethoden, die für die Isolierungsgruppe "Verschlüsselung" definiert sind. Weitere Informationen zu den Sicherheitsaushandlungsmethoden für die Isolierungsgruppe "Verschlüsselung" finden Sie im Abschnitt "Filteraktion der Isolierungsgruppe 'Verschlüsselung'" in diesem Kapitel.

Für den Verkehr zur Isolierungsgruppe "Domänengrenze" und zur Isolierungsgruppe "Kein Klartext" verwendet die Woodgrove Bank als Sicherheitsaushandlungsmethode für die Integrität ESP mit SHA-1.

Die Option Unsichere Kommunikation zulassen, aber immer mit IPSec antworten in der Filteraktion ist deaktiviert, um die Isolierungsgruppe "Kein Klartext" zu erstellen. Auf diese Weise wird sichergestellt, dass die Hosts in der Isolierungsgruppe "Kein Klartext" sämtlichen eingehenden und ausgehenden Verkehr mit IPSec sichern müssen. Verkehr von Computern, die nicht an der IPSec-Umgebung teilnehmen, wird von ihnen nicht akzeptiert.

Die Filteraktion "IPSEC Full Require Mode (Ignore Inbound, Disallow Outbound)" erlaubt es Computern nicht, diese Filteraktion zum Initiieren von Kommunikation mit Computern zu verwenden, die nicht an der IPSec-Infrastruktur teilnehmen. Die Option Unsichere Kommunikation mit Computern zulassen, die IPSec nicht unterstützen wurde für die Umsetzung dieser Anforderung deaktiviert.

Filteraktion der Isolierungsgruppe "Verschlüsselung"

Die Woodgrove Bank hat sich für ESP als grundlegendes Integritätsprotokoll und SHA-1 als Kryptografieoption entschieden. Darüber hinaus müssen Hosts in der Isolierungsgruppe "Verschlüsselung" mit den Hosts in der Isolierungsdomäne und der Isolierungsgruppe "Kein Klartext" kommunizieren können. Die Filteraktion wurde so konfiguriert, dass sie die Sicherheitsaushandlungsmethoden zum Verschlüsseln der Informationen enthält.

Bei der Woodgrove Bank gibt es eine Reihe von Geschäftsanforderungen für die Kommunikation zwischen Hosts in der Isolierungsgruppe "Verschlüsselung" und anderen Isolierungsgruppen. Dementsprechend können Clients in der Isolierungsgruppe "Verschlüsselung" die folgenden Aktionen ausführen (eine Beschreibung der Aktionen finden Sie in Tabelle 4.6 in Kapitel 4):

• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsdomäne
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsdomäne
• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Kein Klartext"
• Akzeptieren von Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Kein Klartext"
• Initiieren von Kommunikationsanforderungen für Hosts in der Isolierungsgruppe "Domänengrenze"

Computern in der Isolierungsgruppe "Verschlüsselung" ist es untersagt, Kommunikationsanforderungen von Hosts in der Isolierungsgruppe "Domänengrenze" zu akzeptieren.

Um diese Anforderungen in einer IPSec-Richtlinie zu implementieren, müssen Sie die Filteraktion so entwerfen, dass sie mit der Filterliste arbeitet, in der alle internen Subnetze angegeben sind. Die genannten Anforderungen lassen sich auf zwei Grundverhalten reduzieren:

• Ausgehend, für Pakete, die die entsprechenden Filterkriterien erfüllen (alle internen Subnetze) Auslösen von IKE-Aushandlungsanforderungen für den Versuch, den Verkehr nur per IPSec-ESP SHA-1 3DES abzusichern. Wenn ein Zielhost nicht mit IKE antwortet, darf nicht auf unsichere Kommunikation (Klartext) zurückgegriffen werden.
• Eingehend, bei Klartextpaketen, die die Kriterien der entsprechenden Filter erfüllen (alle internen Subnetze) Ignorieren. Nur IKE-Aushandlungsanforderungen von vertrauenswürdigen Hosts akzeptieren, die IPSec-ESP SHA-1 3DES zulassen.

Clients in der Isolierungsgruppe "Verschlüsselung" können keine Kommunikationsanforderungen von der Isolierungsgruppe "Domänengrenze" akzeptieren und auch keine Kommunikationsanforderungen für nicht vertrauenswürdige Systeme initiieren bzw. von diesen akzeptieren.

Um die Kommunikation mit der Isolierungsdomäne zu ermöglichen, sind die in der Filteraktion "IPSEC Require Encryption Mode (Ignore Inbound, Disallow Outbound)" verwendeten Sicherheitsaushandlungsmethoden für die Verschlüsselung auch in den Filteraktionen "IPSEC Secure Request (Ignore Inbound, Allow Outbound)" und "IPSEC Full Require Mode (Ignore Inbound, Disallow Outbound)" vorhanden. Die Woodgrove Bank verwendet die 3DES-Verschlüsselungsmethode, die bessere Sicherheit als DES bietet, obgleich dies mit zusätzlichem Verwaltungs- und Verarbeitungsaufwand einhergeht.

Aufgrund der Anforderung, keine Kommunikationsanforderungen für nicht vertrauenswürdige Systeme zu akzeptieren bzw. zu initiieren, wurde bei der Woodgrove Bank die Option Unsichere Kommunikation zulassen, aber immer mit IPSec antworten nicht aktiviert. Diese Konfiguration sorgt dafür, dass Hosts in der Isolierungsgruppe "Verschlüsselung" keinen Verkehr von Computern akzeptieren, die nicht an der IPSec-Umgebung teilnehmen. Auch die Option Unsichere Kommunikation mit Computern zulassen, die IPSec nicht unterstützen wurde deaktiviert, um die Computer daran zu hindern, Kommunikation mit Computern zu initiieren, die nicht an der IPSec-Umgebung teilnehmen.

Das Blockieren von IPSec-Kommunikationsanforderungen von Computern in der Isolierungsgruppe "Domänengrenze" erforderte einen zusätzlichen Konfigurationsaufwand. Das Gruppenrichtlinienobjekt (GPO), mit dem den Computern in der Isolierungsgruppe "Verschlüsselung" die IPSec-Richtlinie bereitgestellt wird, wurde mit dem Recht "Zugriff vom Netzwerk auf diesen Computer verweigern" konfiguriert. Dieses Recht wurde einer Gruppe zugewiesen, in der sich alle Computerkonten für die an der Isolierungsgruppe "Domänengrenze" teilnehmenden Systeme befinden. Sollte einer dieser Computer versuchen, Kommunikationsanforderungen für ein System in der Isolierungsgruppe "Verschlüsselung" zu initiieren, käme es bei der IKE-Authentifizierung zu einem Fehlschlagen der Autorisierung, und die Kommunikation würde blockiert.

IPSec-Richtlinien

Mit IPSec-Richtlinien werden Windows-basierte Computer für den Einsatz in einer IPSec-Umgebung konfiguriert. Eine IPSec-Richtlinie ist eine Sammlung von Regeln, die vom Verkehr eingehalten werden müssen. Bei Windows 2000 gibt es drei verschiedene Arten von IPSec-Richtlinien:

• lokale Richtlinien
• Active Directory-Domänenrichtlinien
• dynamische Richtlinien

Windows XP und Windows Server 2003 unterstützen darüber hinaus die folgenden Richtlinienarten:

• IPSec-Startrichtlinien. Werden in der lokalen Registrierung gespeichert und verwaltet. Werden nur in Windows XP SP2 oder später unterstützt. Werden angewendet, sobald der Computer eine IP-Adresse erhält; dies kann auch vor dem Start des IPSec-Dienstes geschehen. Werden ersetzt, wenn der Dienst die permanente Richtlinie anwendet.
• Permanente IPSec-Richtlinien. Werden in der Registrierung auf dem lokalen Computer gespeichert und verwaltet. Werden mit dem Befehlszeilenprogramm konfiguriert. Werden zuerst angewendet, wenn der IPSec-Dienst startet. Ersetzen die Startrichtlinien.
• Lokale IPSec-Richtlinien. Werden auf dem lokalen Computer gespeichert und verwaltet. Werden mit dem MMC-Snap-In für die IPSec-Richtlinienverwaltung oder einem Befehlszeilenprogramm konfiguriert. Werden zusätzlich zu permanenten Richtlinien angewendet, wenn keine Domänenrichtlinien zugewiesen sind.
• Active Directory-Domänenrichtlinien. Werden in Active Directory gespeichert. Werden vom MMC-Snap-In für die IPSec-Richtlinienverwaltung oder von einem Befehlszeilenprogramm verwaltet. Setzen alle lokalen Richtlinien außer Kraft, die zugewiesen wurden. Active Directory-IPSec-Richtlinien werden einem GPO mithilfe des MMC-Snap-Ins für den Gruppenrichtlinien-Editor oder der Gruppenrichtlinien-Verwaltungskonsole (Group Policy Management Console, GPMC) unter Windows-Einstellungen, Sicherheitseinstellungen, IP-Sicherheitsrichtlinien zugewiesen.
• Dynamische IPSec-Richtlinien. Werden nur im Arbeitsspeicher gespeichert. Werden mit dem Befehlszeilenprogramm konfiguriert. Dienen zum dynamischen Hinzufügen zu den vorhandenen Richtlinien. Dynamische Richtlinien werden verworfen, wenn der IPSec-Dienst stoppt.

Aus Gründen der Einfachheit konzentriert sich diese Anleitung auf die Verwendung der Active Directory-Domänenrichtlinien.

Beim Definieren von IPSec-Richtlinien sollte am besten versucht werden, eine übergreifende Richtlinie zu entwerfen, die die Grundlage für die IPSec-Infrastruktur für alle Computer bildet. Anschließend können Sie weitere Richtlinien erstellen, um auf Systemen, die eine zusätzliche Sicherheitskonfiguration benötigen, strengere Einstellungen durchzusetzen. Jede zusätzliche Richtlinie sollte so ausgelegt werden, dass die größtmögliche Anzahl von Computern abgedeckt wird, die der konkreten geschäftlichen oder technischen Anforderung gerecht werden müssen. Wenn die Anzahl der Richtlinien so gering wie möglich gehalten wird, vereinfachen sich auch die Fehlersuche und die Verwaltung der Richtlinien.

IPSec-Richtlinien enthalten einen Namen, eine Beschreibung, einen Satz von Regeln sowie Konfigurationseinstellungen für die Abfrageintervalle, Einstellungen für den Schlüsselaustausch und Schlüsselaustauschmethoden. Auf alle diese Bestandteile wird im folgenden Abschnitt näher eingegangen.

Name

Genau wie Filteraktionen sollten auch Richtlinien aussagekräftige Namen erhalten, um die Verwaltung der Lösung und die Fehlerbehandlung während der Implementierungs- und der Betriebsphase des Projekts zu erleichtern.

Beschreibung

Eine detaillierte Beschreibung der Richtlinie hilft Administratoren herauszufinden, wofür die Richtlinie steht, ohne dass sie dazu die Richtlinie tatsächlich öffnen und sich mit deren Regeln vertraut machen müssen.

Regeln

Eine IPSec-Regel besteht aus einer einzelnen Filterliste, einer zugehörigen Filteraktion, den Authentifizierungsmethoden, die zum Aufbauen der Vertrauensstellung zwischen den Computern verwendet werden, dem Verbindungstyp und der Angabe, ob es sich bei der Regel um eine Tunnelkonfiguration handelt.

Jede Regel definiert eine oder mehrere Authentifizierungsmethoden, anhand derer die Vertrauensstellung zwischen den Hosts aufgebaut wird. Zur Wahl stehen dabei die Version 5 des Kerberos-Protokolls, Zertifikate von einer bestimmten Zertifizierungsstelle und vorinstallierte Schlüssel.

Der Verbindungstyp definiert die Verbindungen, auf die die IPSec-Richtlinie angewendet wird. Sie können in der Konfiguration festlegen, dass die Richtlinie für alle Verbindungen, für LAN-Verbindungen oder für RAS-Verbindungen gelten soll.

Der Tunneltyp legt fest, ob die IPSec-Richtlinie einen IPSec-Tunnel definiert. Wenn der Tunneltyp deaktiviert ist, verwendet IPSec den Transportmodus.

Zur Unterstützung der zuvor in diesem Leitfaden herausgearbeiteten Sicherheitsisolierungsgruppen hat die Woodgrove Bank vier IPSec-Richtlinien implementiert. Alle vier Richtlinien wurden wie folgt konfiguriert: Es wird die Version 5 des Kerberos-Protokolls verwendet, die Richtlinien gelten für alle Verbindungen, und es wird kein IPSec-Tunnel definiert.

Die folgende Tabelle enthält eine Übersicht über die im Woodgrove Bank-Szenario verwendeten Richtlinien:

Tabelle 5.6: IPSec-Richtlinien der Woodgrove Bank

Name der Richtlinie	Beschreibung
IPSEC Isolation Domain IPsec Policy (1.0.041001.1600)	Diese Richtlinie definiert die Isolierungsdomäne. Hosts in dieser Isolierungsgruppe sind in der Lage, beim Initiieren von Kommunikationsanforderungen für Hosts, die IPSec nicht unterstützen, auf unsichere Kommunikation (Klartext) zurückzugreifen. Sie konfiguriert die Hosts so, dass diese IPSec-Kommunikation zur Voraussetzung machen. Wenn die Aushandlung zwischen IPSec-fähigen Clients fehlschlägt, kommt auch keine Kommunikation zustande.
IPSEC Boundary Isolation Group IPsec Policy (1.0.041001.1600)	Diese Richtlinie definiert die Isolierungsgruppe "Domänengrenze". Sie konfiguriert die Hosts so, dass diese IPSec-Kommunikation zur Voraussetzung machen, erlaubt ihnen aber, auf unsichere Kommunikation zurückzugreifen, wenn mit Hosts kommuniziert werden muss, die IPSec nicht unterstützen.
IPSEC No Fallback Isolation Group IPsec Policy (1.0.041001.1600)	Diese Richtlinie definiert die Isolierungsgruppe "Kein Klartext". Sie konfiguriert die Hosts so, dass diese IPSec-Kommunikation zur Voraussetzung machen. Wenn die Aushandlung fehlschlägt oder die Kommunikation mit einem Client versucht wird, der IPSec nicht verwendet, scheitert auch die Kommunikation.
IPSEC Encryption Isolation Group IPsec Policy (1.0.041001.1600)	Diese Richtlinie definiert die Isolierungsgruppe "Verschlüsselung". Sie konfiguriert die Hosts so, dass diese IPSec-Kommunikation und Verschlüsselung zur Voraussetzung machen. Wenn die Aushandlung fehlschlägt oder die Kommunikation mit einem Client versucht wird, der IPSec nicht verwendet, scheitert auch die Kommunikation.

Bei der Zahl hinter dem Namen der einzelnen Richtlinien handelt es sich um eine Versionsnummer. Eine Erläuterung dazu finden Sie im Abschnitt "Versionskontrolle für Richtlinien" weiter hinten.

Alle Woodgrove Bank-Richtlinien enthalten dieselben Ausnahmelisten, da es nicht erforderlich ist, eine bestimmte Gruppe von Computern für eine der Isolierungsgruppen als Ausnahme festzulegen. Die folgende Tabelle enthält die aktivierten Regeln, die für alle vier in der vorherigen Tabelle genannten Richtlinien identisch sind:

Tabelle 5.7: In den Woodgrove Bank-IPSec-Richtlinien definierte gemeinsame Regeln

Filterliste	Filteraktion	Authentifizierungsmethoden	Tunnelendpunkt	Verbindungstyp
DNS-Ausnahmeliste	IPSEC Zulassen	Keine	Keine	Alle
Domänencontroller-Ausnahmeliste	IPSEC Zulassen	Keine	Keine	Alle
WINS-Ausnahmeliste	IPSEC Zulassen	Keine	Keine	Alle
DHCP, Aushandlungsverkehr	IPSEC Zulassen	Keine	Keine	Alle
ICMP, gesamter Verkehr	IPSEC Zulassen	Keine	Keine	Alle

Zusätzlich zu den in dieser Tabelle aufgeführten Regeln ist die Standardantwortregel für Clients in allen Richtlinien deaktiviert.

Die vier von der Woodgrove Bank definierten Richtlinien unterscheiden sich lediglich dadurch, wie sie mit dem Verkehr umgehen, der nicht von einer der Ausnahmefilterlisten verarbeitet wird. Für alle Regeln wurde als Authentifizierungsmethode das Protokoll Kerberos 5 festgelegt, der Tunnelendpunkt wurde auf "Kein" gesetzt, und als Verbindungstyp wurde "Alle" gewählt.

Die folgende Tabelle enthält die Regeln der Woodgrove Bank für das Implementieren der vier Isolierungsgruppen:

Tabelle 5.8: Grundregeln der Woodgrove Bank für das Implementieren von Isolierungsgruppen

Name der Richtlinie	Filterliste	Filteraktion
IPSEC Isolation Domain IPsec Policy (1.0.041001.1600)	Woodgrove Bank Secure Subnets	IPsec Secure Request Mode (Ignore Inbound, Allow Outbound)
IPSEC Boundary Isolation Group IPsec Policy (1.0.041001.1600)	Woodgrove Bank Secure Subnets	IPsec Request Mode (Accept Inbound, Allow Outbound)
IPSEC No Fallback Isolation Group IPsec Policy (1.0.041001.1600)	Woodgrove Bank Secure Subnets	IPsec Full Require Mode (Ignore Inbound, Disallow Outbound)
IPSEC Encryption Isolation Group IPsec Policy (1.0.041001.1600)	Woodgrove Bank Secure Subnets	IPsec Require Encryption Mode (Ignore Inbound, Disallow Outbound)

Die Woodgrove Bank hat sich für Kerberos 5 als alleiniges Authentifizierungsprotokoll entschieden. Vorinstallierte Schlüssel wurden nicht verwendet, weil der Authentifizierungsschlüsselwert von den lokalen Administratoren in der Registrierung sowie von allen authentifizierten Benutzern und Computern in der Domäne gelesen werden kann. Zertifikate kamen nicht in Frage, weil im Unternehmen keine Infrastruktur öffentlicher Schlüssel (PKI) eingerichtet ist.

Durch die Verwendung von Kerberos 5 sind alle zur Domäne gehörenden Computer in der Lage, an der IPSec-Infrastruktur teilzunehmen, da sie sich authentifizieren und die Richtlinie abrufen können. Computer, die nicht zur Domäne gehören, können nicht ohne weiteres an der IPSec-Umgebung teilnehmen, da ihnen ein Authentifizierungsmechanismus und ein Richtlinienverteilungssystem fehlt. Wenn diese Computer die Kriterien für vertrauenswürdige Hosts erfüllen, können Sie eine lokale IPSec-Richtlinie konfigurieren, die sie mithilfe von Zertifikatauthentifizierung in die Lage versetzt, mit anderen vertrauenswürdigen Hosts zu kommunizieren. Derzeit behandelt die Woodgrove Bank Computer, die nicht zur Domäne gehören, als nicht vertrauenswürdige Computer.

Abfrageintervalle

Es müssen zwei Abfrageintervalle berücksichtigt werden: das Abfrageintervall für die Gruppenrichtlinie und das Abfrageintervall für den IPSec-Dienst. Das Abfrageintervall zur Feststellung von Änderungen bei Active Directory-basierten IPSec-Richtlinien beträgt standardmäßig 180 Minuten. Dabei wird nur geprüft, ob es Änderungen in der IPSec-Richtlinie gibt. Änderungen bei der Mitgliedschaft in der Domäne bzw. Organisationseinheit oder bei der Zuweisung bzw. Entfernung von IPSec-Richtlinien innerhalb eines GPO werden nicht erkannt. Die Erkennung dieser Änderungen erfolgt mithilfe des Abfrageintervalls für die Gruppenrichtlinie, das standardmäßig auf 90 Minuten eingestellt ist.

Die Woodgrove Bank hat beide Abfrageintervalle auf 60 Minuten festgelegt. Sollte eine Sicherheitsantwort benötigt werden, könnten die Richtlinien so aktualisiert und innerhalb einer Stunde bereitgestellt werden, um das Risiko zu abzuschwächen. Diese erhöhte Abfragefrequenz führte zu zusätzlichem Abfrageverkehr in Form von LDAP-Abfragen vom Client, um die Zeitstempel der IPSec-Richtlinien zu prüfen. Dies hat zwar keinen deutlich höheren Overhead im Woodgrove Bank-Szenario mit sich gebracht, bei Bereitstellungen für eine große Zahl von Clients könnte sich der Verwaltungs- und Verarbeitungsaufwand jedoch beträchtlich erhöhen.

Einstellungen für den Schlüsselaustausch

Mit den folgenden Einstellungen für den Schlüsselaustausch wird festgelegt, wie neue Schlüssel abgeleitet und wie oft sie erneuert werden. Der Begriff "Hauptschlüssel" steht für das gemeinsame geheime Diffie-Hellman-Schlüsselmaterial, das im IKE-Hauptmodus generiert wird. Der Begriff "Sitzungsschlüssel" bezieht sich auf Schlüssel, die im IKE-Schnellmodus für die Verwendung in den IPSec-Integritäts- und -Verschlüsselungsalgorithmen generiert werden. Sitzungsschlüssel werden vom Hauptschlüssel abgeleitet.

• PFS (Perfect Forward Secrecy). Es gibt zwei Arten von PFS in IKE: "Hauptschlüssel für Perfect Forward Secrecy (PFS)" (Hauptmodus-PFS) und "Sitzungsschlüssel mit Perfect Forward Secrecy (PFS)" (Schnellmodus-PFS). "Hauptschlüssel für Perfect Forward Secrecy (PFS)" wird nicht empfohlen, weil die Funktionalität von anderen unterstützten Schlüsselaustauscheinstellungen dupliziert wird. Hauptmodus-PFS erfordert, dass IKE jedes Mal einen neuen Hauptschlüssel neu authentifiziert und aushandelt, wenn zum Erneuern der Sitzungsschlüssel ein Schnellmodus ausgeführt wird. Diese Bedingung stellt sicher, dass beide Computer für jede Erneuerung eines kryptografischen Schlüssels von vorn und mit einer neuen IKE-Hauptmodus- und Schnellmodusaushandlung beginnen. Dieser zusätzliche Schutz führt jedoch zu zusätzlichem Verwaltungs- und Verarbeitungsaufwand. "Sitzungsschlüssel mit Perfect Forward Secrecy (PFS)" generiert während des Schnellmodus (ohne Hauptmodusauthentifizierung) einen neuen Hauptschlüssel und leitet dann aus diesem neuen Hauptschlüssel neue Sitzungsschlüssel ab. Diese Funktionalität sorgt dafür, dass ein großer Teil oder sogar alle Daten in der Kommunikation nicht nur durch einen Hauptschlüsselwert geschützt werden. Falls es einem Angreifer gelingen würde, in den Besitz des Hauptschlüssels zu gelangen, würde auf diese Weise nur ein kleinerer Teil der verschlüsselten Daten entschlüsselt werden können. "Sitzungsschlüssel mit Perfect Forward Secrecy (PFS)" steht als Option bei der Festlegung der Sicherheitsmethoden für eine Filteraktion zur Verfügung. Sie sollten diese Option aber nur dort verwenden, wo der IPSec-geschützte Verkehr nicht der Gefahr von ausgefeilten kryptografischen Angriffen auf den Diffie-Hellman-Hauptschlüssel ausgesetzt ist.
• Authentifizieren und einen neuen Schlüssel erzeugen nach <Anzahl> Minuten. Dieser Wert legt die Gültigkeitsdauer der IKE-Hauptmodus-SA fest. Standardmäßig ist dieser Wert auf 480 Minuten eingestellt. Über diesen Wert wird gesteuert, wie lange der Hauptschlüssel und die Vertrauensstellung gültig sind, bevor sie neu ausgehandelt werden müssen. Die erste TCP/IP-Verbindung von einem eindeutigen Client zum Host führt dazu, dass eine neue IKE-Hauptmodus-SA erstellt wird. Im Unterschied zu schwachen SAs werden Hauptmodus-SAs bei einer Inaktivität von mehr als 5 Minuten nicht vom Host entfernt. Jede Hauptmodus-SA nimmt etwa 5 KB Arbeitsspeicher in Anspruch. Durch Anpassen des Wertes kann der Administrator die CPU-Last und die Arbeitsspeichernutzung optimieren, die für IKE erforderlich sind. Wird die Gültigkeitsdauer herabgesetzt, verringert sich die Anzahl der aktiven Hauptmodus-SAs auf dem Server. Dadurch wird weniger Arbeitsspeicher beansprucht, und es wird IKE-Verarbeitungszeit gespart, weil weniger SAs unterhalten werden müssen. Bei Clients, die häufig kommunizieren, können Sie die CPU-Last auch erhöhen, die für das Neuaushandeln der Hauptmodus-SAs notwendig ist.
• Authentifizieren und einen neuen Schlüssel erzeugen nach <Anzahl> Sitzungen. Mit dieser Einstellung wird die maximale Anzahl der IKE-Schnellmodi gesteuert, die während der Gültigkeitsdauer einer Hauptmodus-SA zulässig sind, und damit die Anzahl der Sitzungsschlüssel beschränkt, die von ein und demselben Hauptschlüssel erzeugt werden können. Wenn der Grenzwert erreicht ist, wird eine neue IKE-Hauptmodus-SA ausgehandelt, die einen neuen Hauptschlüssel erzeugt. Die Standardeinstellung ist "0", d. h., es ist kein Grenzwert festgelegt. Daher wird der Hauptschlüssel nur erneuert, wenn die Gültigkeit der IKE-Hauptmodus-SA abläuft, sofern nicht Schnellmodus-PFS verwendet wird. Um dasselbe Verhalten wie bei der Einstellung "Hauptschlüssel für Perfect Forward Secrecy (PFS)" zu erzielen, muss diese Option auf "1" gesetzt werden.

Die Woodgrove Bank entschied sich, "Hauptschlüssel für Perfect Forward Secrecy (PFS)" nicht zu verwenden, weil keine spezifischen Sicherheitsanforderungen vorhanden waren, die dies erforderlich gemacht hätten. Dementsprechend wurde in den Filteraktionen auch kein IKE-Schnellmodus-PFS verwendet. Die Gültigkeitsdauer für die IKE-Hauptmodus-SA wurde von 480 Minuten in 180 Minuten geändert, damit die Hauptmodus-SAs auf allen ausgelasteten Servern mit Ausnahme der Server in der Isolierungsgruppe "Domänengrenze" schneller gelöscht werden. Für die Isolierungsgruppe "Domänengrenze" reduzierten die Woodgrove Bank-Administratoren die Gültigkeitsdauer der IKE-Hauptmodus-SA auf 20 Minuten, um die Angriffsfläche zu verringern, die die mit der Isolierungsgruppe "Verschlüsselung" ausgehandelten residenten Hauptmodus-SAs bieten. Obwohl Hosts in der Isolierungsgruppe "Domänengrenze" keine neuen IKE-Aushandlungen mit Hosts in der Isolierungsgruppe "Verschlüsselung" initiieren können, kann der umgekehrte Fall eintreten. Nach dem Einrichten der Hauptmodus-SA wäre ein Host in der Isolierungsgruppe "Domänengrenze" dann so lange in der Lage, mithilfe dieser SA Schnellmodus-SAs für den Schutz von eingehendem Verkehr an das entsprechende System in der Isolierungsgruppe "Verschlüsselung" auszuhandeln, bis die Hauptmodus-SA gelöscht wurde. Dieses Risiko lässt sich verringern, indem die Hauptmodus-SAs auf den Servern in der Isolierungsgruppe "Domänengrenze" zwangsweise häufiger gelöscht werden. Die Einstellung für die Anzahl der Sitzungen, für die der Hauptschlüssel zum Erzeugen eines Sitzungsschlüssels verwendet werden kann, wurde bei der Standardeinstellung 0 belassen.

Methoden für den Schlüsselaustausch

Mit den Schlüsselaustauschmethoden wird gesteuert, welche Sicherheitsmethoden während der Hauptmodus-IKE-Aushandlung verwendet werden. Dabei stehen Konfigurationsoptionen für die Prüfung der Integrität (SHA-1 und MD5), der Vertraulichkeit bzw. Verschlüsselung (3DES und DES) und der Länge der Basisprimzahlen zur Verfügung, die während des Schlüsselaustauschvorgangs verwendet werden.

Die kryptografische Stärke der Schlüssel, die für die Integritätsprüfung und die Verschlüsselung der IKE-Aushandlung selbst und für den IPSec-Datenschutz verwendet werden, hängt von der Stärke der Diffie-Hellman-Gruppe ab, auf der die Primzahlen basieren. Für die Diffie-Hellman-Gruppe stehen die folgenden drei Optionen zur Verfügung:

• Hoch (3): Verschlüsselung mit 2048 Bit. Diese Option entspricht der Spezifikation IETF RFC 3526 für die Diffie-Hellman-Gruppe 14. Diese Schlüsselstärke ist für 3DES erforderlich, um die maximale kryptografische Stärke zu erzielen. Weitere Informationen dazu finden Sie unter "IETF RFC 3526".
• Medium (2) Verschlüsselung mit 1024 Bit
• Niedrig (1) Verschlüsselung mit 768 Bit

Die Konfiguration "Hoch" kann nur auf Windows XP SP2- und Windows Server 2003-basierten Systemen verwendet werden. Die Konfiguration "Medium" bietet Interoperabilität mit Windows 2000 und Windows XP SP1. Die Konfiguration "Niedrig" wird zum Zweck der Rückwärtskompatibilität bereitstellt, sollte aber wegen ihrer relativen Schwäche nicht verwendet werden.

In der folgenden Tabelle werden die bei der Woodgrove Bank eingesetzten Sicherheitsmethoden für den Schlüsselaustausch in der Reihenfolge ihrer Präferenz durch das Unternehmen aufgeführt:

Tabelle 5.9: Standardsicherheitsmethoden für den Schlüsselaustausch

Verschlüsselung	Integrität	Diffie-Hellman-Gruppe
3DES	SHA-1	Hoch (3) 2048 Bit
3DES	SHA-1	Medium (2) 1024 Bit
3DES	MD5	Medium (2) 1024 Bit

Versionskontrolle für Richtlinien

IPSec-Richtlinien werden während der Anfangsplanung, beim Testen in einer Testumgebung, in Pilotbereitstellungen und auch später nach der Einführung häufig geändert. Wenn Sie Ihre IPSec-Richtlinien mithilfe von Skripts, Tabellen oder anderen Dokumenten erstellen, sollten Sie diese Dateien mit einem Versionskontrollsystem, wie z. B. Microsoft Visual SourceSafe®, verwalten.

Versionen der IPSec-Richtlinien innerhalb von Active Directory anhand der Attribute der jeweiligen Richtlinie zu identifizieren, ist schwierig. Bei der Problembehandlung muss aber feststellbar sein, welche Version der IPSec-Richtlinie auf dem Computer aktiv ist. Es empfiehlt sich daher, sowohl im Namen der Richtlinie als auch in den Richtlinienregeln in irgendeiner Form Versionsinformationen zu speichern.

Eine einfache Methode zur Versionskontrolle ist das Erstellen einer Versions-ID unter Angabe des Erstellungszeitpunkts:

<Major Change>.<Minor Change>.<Date:yymmdd>.<Time:24 Hour>

So würde z. B. die Versionsnummer "1.0.041001.1600" anzeigen, dass es sich bei der Richtlinie um die Version 1.0 handelt, die am 01.10.2004 um 16.00 Uhr erstellt wurde.

Diese Versions-ID sollten Sie dann an das Ende des Namens der zu erstellenden Richtlinie stellen. Die Richtlinie könnte dann z. B. den folgenden Namen erhalten: "IPSEC "IPSec-Richtlinie 'Domänengrenze' (1.0.041001.1600)". Sie können die Versions-ID auch an den Namen bzw. die Beschreibung der sich ebenfalls häufig ändernden Filterlisten anhängen.

Die Gruppenrichtlinienfunktion ruft den Namen der IPSec-Richtlinie ab und speichert ihn in der lokalen Registrierung unter HKEY_LOCAL_MACHINE \SOFTWARE\
Policies\Microsoft\Windows\IPsec\GPTIPSECPolicy als Zeichenfolgewert unter dem Schlüssel DSIPSECPolicyName.

Obwohl im Rahmen des Abfrageintervalls für den IPSec-Dienst eine Prüfung auf Änderungen in allen zugewiesenen Richtlinienobjekten erfolgt, wird der Name der zugewiesenen Richtlinie, die die Gruppenrichtlinienfunktion gespeichert hat, nicht aktualisiert. Die Gruppenrichtlinienfunktion aktualisiert den Namen in der lokalen Registrierung erst, wenn die GPO-Zuweisung sich ändert. Microsoft IT hat festgestellt, dass eine nicht verwendete Regel in einer IPSec-Richtlinie ein effektives Mittel zum Speichern von Richtlinienversionsinformationen sein kann. Sie können z. B. eine Filterliste mit einem Filter erstellen, der ungültige Adressen enthält und mit einer "Zulassen"-Filteraktion wie beispielsweise der folgenden verbunden ist:

Filterlistenname: IPSec-Richtlinie Ver 1.0.041001.1600

Filterlistenbeschreibung: IPSec-Richtlinie Ver 1.0.041001.1600

1.1.1.1 <-> 1.1.1.2, ICMP,Beschreibung = "IPSec-Richtlinie Versions-ID 1.0.041001.1600"

Nachdem Sie diese Filterliste in Active Directory erstellt haben, können Sie den definierten Namen (DN) des Versionsobjekts für die Filterliste mithilfe des MMC-Snap-Ins "Active Directory-Benutzer und -Computer" (im Erweiterten Modus) identifizieren. Sie finden das Filterlistenobjekt anhand seiner Beschreibung unter <Domänenname>\System\IP Security.

Wenn Sie den DN des Versionsobjekts kennen, können Sie ihn über ein Skript mit den in der Registrierung unter HKEY_LOCAL_MACHINE \SOFTWARE
\Policies\Microsoft\Windows\IPSec\Policy\Cache gespeicherten IPSec-Objekten vergleichen lassen und so bestimmen, ob er sich im Cache befindet. Wenn Sie den Versionsobjekt-DN im Cache finden, können Sie die in Active Directory gespeicherten Richtliniennamen für das Objekt mit dem auf dem lokalen Computer gespeicherten Objekt vergleichen. Wenn die Namen identisch sind, bedeutet das, dass die lokale und die Domänenrichtlinie synchronisiert sind. Im IPSec-Richtliniencache werden auch die Namen und Beschreibungen aller IPSec-Filterlisten gespeichert, so dass besser festzustellen ist, welche Versionen dieser Objekte derzeit zugewiesen sind. Der IPSec-Dienst behält die Textbeschreibung aller Filter (nicht der Filterlisten) im Arbeitsspeicher, so dass das MMC-Snap-In für die IPSec-Überwachung und die Befehlszeilenprogramme diese Informationen in ihren Berichten ausgeben können.

Mithilfe eines Skripts lässt sich die Richtlinienversionsüberprüfung für einen Client automatisieren. Dies kann z. B. mit dem Beispielskript Detect_IPsec_Policy.vbs erfolgen, dass Sie im Ordner "Tools and Templates" in dieser Lösung finden.

Da Richtlinien im Laufe der Zeit bearbeitet werden, sollten Sie die entsprechenden Filternamen auch entsprechend aktualisieren.

Anwenden von IPSec-Richtlinien auf einzelne Computer

Der letzte Schritt zur Aktivierung von IPSec besteht darin, den Hosts die Richtlinien bereitzustellen. Dazu gibt es zwei Methoden. Eine Methode besteht darin, die Richtlinien direkt den einzelnen Hostcomputern zuzuweisen, bei der anderen Methode werden GPOs und Active Directory verwendet. Die Anwendung von Richtlinien über Active Directory wird im Abschnitt "Anwenden von IPSec-Richtlinien mithilfe von GPOs" weiter unten beschrieben.

Die Anwendung der IPSec-Richtlinien auf Einzelcomputer kann entweder über das MMC-Snap-In für die IPSec-Sicherheitsrichtlinienverwaltung oder über die Befehlszeile unter Verwendung von Netsh (bei Windows Server 2003), Ipseccmd.exe (bei Windows XP) oder Ipsecpol.exe (bei Windows 2000) erfolgen.

Das MMC-Snap-In stellt eine grafische Benutzeroberfläche bereit, über die der Administrator die Richtlinie manuell zuweisen oder eine zuvor auf einem anderen Computer definierte IPSec-Richtlinie importieren kann. Administratoren können aber nicht nur die Richtlinie auf dem lokalen Computer bearbeiten, sondern sie können mit dem Snap-In auch Richtlinien auf Remotecomputern verwalten.

Ausführliche Informationen zu den Befehlszeilenprogrammen finden Sie in den folgenden Quellen:

• Windows Server 2003 Help and Support for Netsh
• Dokumentation zum Windows XP-Supporttool Ipseccmd.exe
• Windows 2000 Server Resource Kit for Ipsecpol.exe

Die neuesten Versionen des Resource Kit und der Supporttools stehen im Microsoft Download Center unter folgender Adresse bereit: www.microsoft.com/downloads/search.aspx?

Microsoft hat aktualisierte Versionen von IPseccmd und anderer Supporttools für Windows XP SP2 bereitgestellt. Informationen dazu finden Sie im Microsoft KB-Artikel 838079, "Supporttools in Windows XP Service Pack 2", unter https://support.microsoft.com/?kbid=838079.

Eine ausführliche Erläuterung der Verwendung dieser Tools würde den Rahmen dieser Anleitung sprengen. Die Beispiele in diesem Leitfaden beziehen sich auf die Verwendung von Netsh auf Servern unter Windows Server 2003.

Anwenden von IPSec-Richtlinien mithilfe von GPOs

Die Active Directory-Gruppenrichtlinien werden als Mechanismus zum Zuweisen und Verteilen von IPSec-Richtlinien auf zur Domäne gehörigen Computern verwendet. Vor dem Verteilen der Richtlinien mithilfe der Gruppenrichtlinien-Verteilungsmechanismen in Active Directory müssen Sie zunächst die GPOs konfigurieren, die zum Anwenden der IPSec-Richtlinien auf den Hostcomputern verwendet werden sollen.

Laden von IPSec-Richtlinien in Active Directory

Der erste Schritt beim Implementieren von IPSec-Richtlinien über Active Directory besteht darin, Filterlisten, Filteraktionen und IPSec-Richtlinien im Verzeichnisdienst zu erstellen. Diese Aufgabe können Sie mit dem MMC-Snap-In für die IPSec-Sicherheitsrichtlinienverwaltung oder mit einem Befehlszeilenprogramm, wie z. B. Netsh, ausführen. Unabhängig davon, für welches Tool Sie sich entscheiden, müssen Sie zum Implementieren der IPSec-Richtlinien die folgenden drei Teilaufgaben ausführen:

1. Erstellen der im Abschnitt "IPSec-Filterlisten" dieses Kapitels genannten Filterlisten und Filter
2. Erstellen der im Abschnitt "IPSec-Filteraktionen" dieses Kapitels genannten Filteraktionen
3. Erstellen der im Abschnitt "IPSec-Richtlinien" dieses Kapitels genannten IPSec-Richtlinien

Verwenden des MMC-Snap-Ins für die IPSec-Sicherheitsrichtlinienverwaltung

Das MMC-Snap-In für die IPSec-Sicherheitsrichtlinienverwaltung ist ein Tool mit grafischer Benutzeroberfläche zum Erstellen, Konfigurieren und Bearbeiten von IPSec-Richtlinien auf lokalen Computern, auf Remotecomputern und in Domänen. Das Konfigurieren der IPSec-Komponenten ist ein manueller Prozess, bei dem die erstellten Objekte mithilfe von Assistenten direkt bearbeitet werden.

Nachdem der Administrator die IPSec-Richtlinien lokal oder in Active Directory definiert hat, kann er diese IPSec-Richtlinien (einschließlich aller Filterlisten und Filteraktionen) in eine Datei exportieren, deren Dateiname die Dateinamenerweiterung ".ipsec" erhält. Diese Datei kann zu Sicherungszwecken auf andere Medien kopiert werden.

Wenn eine Sicherungskopie der IPSec-Richtlinien vorhanden ist, können Sie mit diesem Tool die gesicherten Richtlinien in Active Directory importieren. Auf diese Weise sind Wiederherstellungen möglich, und die IPSec-Richtliniendateien können so auch von einer Testgesamtstruktur in eine Produktionsgesamtstruktur verschoben werden, ohne dass die einzelnen Filterlisten, Filteraktionen und Richtlinien manuell neu erstellt werden müssen. Richtlinien, die auf der Basis einer Sicherheitskopie wiederhergestellt werden, sollten gründlich überprüft werden. Es empfiehlt sich, Tests durchzuführen, um abschätzen zu können, welche Folgen das Anwenden alter Einstellungen auf die aktuelle Umgebung hat. Eine alte Sicherungskopie kann Richtlinieneinstellungen, wie z. B. Filterlisten oder Filteraktionen, enthalten, die ungültig sind und die, wenn sie den aktuellen Domänenmitgliedern zugewiesen werden, zu einem Scheitern der Kommunikation führen können.

Weitere Informationen zum Verwenden des MMC-Snap-Ins für die IPSec-Sicherheitsrichtlinienverwaltung finden Sie im Thema "Definieren von IPSec-Richtlinien" im Windows Server 2003-TechCenter.

Verwenden des Befehlszeilenprogramms Netsh

Sie können Netsh als Alternative zum MMC-Snap-In für die IPSec-Sicherheitsrichtlinienverwaltung verwenden und damit die IPSec-Richtlinien innerhalb eines Windows Server 2003-basierten Active Directory konfigurieren. Dieses Befehlszeilenprogramm kann sowohl im interaktiven Modus als auch im Batchmodus ausgeführt werden. Im interaktiven Modus muss der Administrator einzelne Befehle an der Netsh-Eingabeaufforderung eingeben. Vor dem Erstellen der Filterlisten, Filteraktionen und IPSec-Richtlinien muss das Tool so konfiguriert werden, dass es auf den Active Directory-Verzeichnungsdienst weist.

Geben Sie dazu an der Netsh-Eingabeaufforderung den folgenden Befehl ein:

ipsec static set store location=domain

Der Administrator gibt daraufhin manuell über die Netsh-Befehlsshell die Filterlisten, Filter, Filteraktionen und IPSec-Richtlinien ein. Wie auch das MMC-Tool mit der grafischen Benutzeroberfläche unterstützt Netsh den Export und Import der IPSec-Richtliniendateien zu Sicherungs- und Wiederherstellungszwecken.

Bei der Ausführung von Netsh im Batchmodus muss eine Skriptdatei der Netsh-Befehle erstellt werden. Diese Skriptdatei muss neben dem Befehl, mit dem der Fokus auf die Domäne gesetzt wird, auch alle Konfigurationsbefehle für die Filterlisten, Filter, Filteraktionen und IPSec-Richtlinien enthalten.

Anschließend können die IPSec-Richtlinieninformationen in Active Directory durch Starten von Netsh und Ausführen der Skriptdatei erstellt werden. Für die Befehlszeile zum Starten von Netsh und Ausführen der Skriptdatei gilt die folgende Syntax:

netsh –f <scriptfile>

Weitere Informationen zur Verwendung von Netsh finden Sie im Thema "Netsh" im Abschnitt "Administration and Scripting Tools" im Help and Support Center für Windows Server 2003.

Erstellen von Gruppenrichtlinienobjekten für die Verteilung von IPSec-Richtlinien

Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) sind in Active Directory gespeicherte Objekte, in denen die Computern zuzuweisenden Einstellungen definiert sind. IPSec-Richtlinien werden nicht direkt in GPOs gespeichert, sondern die GPOs enthalten eine LDAP-DN-Verknüpfung zur IPSec-Richtlinie. Die IPSec-Richtlinien selbst werden unter "cn=IP Security, cn=System, dc=<Domäne>" in Active Directory gespeichert.

GPOs werden Standorten, Domänen und Organisationseinheiten innerhalb von Active Directory zugewiesen. Computer, die sich an diesen Standorten bzw. in diesen Containern befinden, erhalten die vom GPO definierten Richtlinie, sofern diese nicht anderweitig blockiert ist. Das für den IPSec-Entwurf zuständige Team sollte zusammen mit dem Active Directory-Team besprechen, inwieweit vorhandene GPOs zur Bereitstellung ihrer IPSec-Richtlinien genutzt werden können. Wenn dies nicht möglich ist oder wenn umfangreiche Änderungen an deren Verwaltungspraktiken nötig wären, können für jeden Satz der bereitzustellenden IPSec-Richtlinien neue GPOs definiert werden. Die in dieser Anleitung beschriebene Lösung verwendet für die Bereitstellung der IPSec-Richtlinien neue GPOs.

GPOs können zwar mit den Tools "Active Directory-Benutzer und -Computer" und "Active Directory-Standorte und -Dienste" erstellt werden, wir empfehlen aber, die neuen GPOs mithilfe der Gruppenrichtlinien-Verwaltungskonsole (Group Policy Management Console, GPMC) zu erstellen. Bei der Erstellung einer Richtlinie über die Active Directory-Tools wird das GPO automatisch mit dem Objekt verknüpft, das durchsucht wird. Wenn zum Erstellen der GPOs die Gruppenrichtlinien-Verwaltungskonsole verwendet wird, kann der Administrator sicherstellen, dass die GPOs zwar innerhalb von Active Directory erstellt, aber erst dann auf Computer angewendet werden, wenn jedes GPO ausdrücklich mit einer Site, Domäne oder Organisationseinheit verknüpft ist.

Die GPMC ist ein Add-On-Dienstprogramm für Computer, die unter Windows XP Service Pack 1 (oder höher) bzw. Windows Server 2003 laufen. Sie ermöglicht Administratoren die Verwaltung von Gruppenrichtlinien für mehrere Domänen und Standorte innerhalb einer oder mehrerer Gesamtstrukturen über eine einfache Benutzeroberfläche mit Drag-&-Drop-Unterstützung. Zu den Features der Gruppenrichtlinien-Verwaltungskonsole zählen Funktionen für das Sichern, Wiederherstellen, Importieren und Kopieren von GPOs sowie das Erstellen von entsprechenden Berichten. Da diese Operationen vollständig skriptfähig sind, können Administratoren die Verwaltung anpassen und automatisieren. Beachten Sie, dass diese Verfahren zur GPO-Verwaltung nur zum Verwalten der IPSec-Richtlinienobjekte selbst geeignet sind. Sie sollten eine Verwaltungsstrategie für die koordinierte Verwaltung der IPSec-Richtlinien und der GPOs entwickeln, die die IPSec-Richtlinienzuweisung übernehmen.

Weitere Informationen zur Verwendung der GPMC finden Sie im White Paper Administering Group Policy with the GPMC auf der Microsoft-Website unter www.microsoft.com/windowsserver2003/gpmc/
gpmcwp.mspx (in englischer Sprache).

Die Gruppenrichtlinien-Verwaltungskonsole mit Service Pack 1 steht als Download unter folgender Adresse zur Verfügung: www.microsoft.com/downloads/details.aspx?
FamilyId=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=de.

Bei Verwendung der GPMC erstellt der Administrator ein GPO für jede IPSec-Richtlinie, indem er die folgenden Schritte ausführt:

So erstellen Sie ein neues GPO

1. Erweitern Sie die Domänenstruktur, klicken Sie mit der rechten Maustaste auf den Container Gruppenrichtlinienobjekte, und wählen Sie den Befehl Neu.
2. Geben Sie einen Namen für das GPO ein, und klicken Sie auf OK.

Wie bei den IPSec-Filteraktionen und -Richtlinien sollten Sie bei der Benennung Ihrer GPOs auch die Versionsnummer in den Namen aufnehmen, da sich bei Active Directory-Objekten nicht so ohne weiteres Informationen zur jeweiligen Version ermitteln lassen. Wenn der Richtlinienname eine Versionsnummer enthält, können Administratoren schnell herausfinden, welche Richtlinie gerade wirksam ist. Microsoft empfiehlt, dieselbe Namenskonvention zu verwenden, die bereits weiter oben in diesem Kapitel für Filteraktionen und IPSec-Richtlinien beschrieben wurde. So würde z. B. bei einem GPO namens "IPSec-GPO Isolierungsdomäne Ver 1.0.040601.1600" die Versionsnummer "1.0.040601.1600" anzeigen, dass es sich beim GPO um die Version 1.0 handelt, die am 01.06.04 um 16.00 Uhr erstellt wurde.

Nach dem Erstellen des GPO muss der Administrator das GPO für die Verwendung der richtigen IPSec-Richtlinie konfigurieren.

So weisen Sie einem GPO eine IPSec-Richtlinie zu

1. Starten Sie den Gruppenrichtlinien-Editor, indem Sie mit der rechten Maustaste auf das GPO klicken und Bearbeiten wählen.
2. Die für die Zuweisung verfügbaren IPSec-Richtlinien befinden sich unter "Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\IP-Sicherheitsrichtlinien in Active Directory".
3. Zum Zuweisen einer IPSec-Richtlinie klicken Sie im rechten Fensterbereich mit der rechten Maustaste auf den Richtliniennamen, und wählen Sie dann Zuweisen.
   • Pro GPO kann jeweils nur eine IPSec-Richtlinie zugewiesen werden.
4. Zum Speichern der Änderungen am GPO schließen Sie den Gruppenrichtlinien-Editor.

Die IPSec-Richtlinie wird den Hostcomputern über die Computerkonfigurationseinstellungen im GPO zugewiesen. Wenn das GPO nur zum Zuweisen der IPSec-Richtlinien verwendet wird, empfiehlt es sich, im GPO die Benutzerkonfigurationseinstellungen zu deaktivieren. Auf diese Weise wird die Verarbeitungszeit für das GPO reduziert, weil keine Notwendigkeit mehr besteht, die Benutzerkonfigurationsoptionen auszuwerten.

So deaktivieren Sie die Benutzerkonfiguration im GPO

1. Öffnen Sie die GPMC.
2. Klicken Sie mit der rechten Maustaste auf den GPO-Namen in der GPMC.
3. Wählen Sie Status der Gruppenrichtlinie und anschließend Computerkonfigurationseinstellungen deaktiviert.

Wenn die Benutzerkonfigurationseinstellungen zu einem späteren Zeitpunkt im GPO konfiguriert werden, muss der Administrator die Verarbeitung der Benutzerkonfigurationseinstellungen neu aktivieren, damit sie angewendet werden.

Domänensicherheitsgruppen

Domänensicherheitsgruppen erfüllen zwei Zwecke. Zum einen können mit ihrer Hilfe Domänencomputerkonten identifiziert werden, die Mitglieder einer Isolierungsgruppe sind. Zum anderen sind auch die Domänencomputerkonten identifizierbar, die Mitglieder einer Netzwerkzugriffsgruppe sind.

Alle Mitglieder einer Isolierungsgruppe müssen dieselbe IPSec-Richtlinie erhalten. Daher können Sie für das Anwenden und Verwalten der IPSec-Richtlinien Domänensicherheitsgruppen erstellen, statt für die Steuerung der Richtlinienzuweisung OU-Container (Organisationseinheiten) zu verwenden. Universelle Gruppen sind das beste Mittel zum Steuern der Richtlinienzuweisung, weil sie auf die vollständige Gesamtstruktur anwendbar sind und weil sich durch sie die Anzahl der zu verwaltenden Gruppen verringert. Wenn jedoch keine universellen Gruppen verfügbar sind, können Sie auch globale Domänengruppen verwenden. Lokale Domänengruppen werden für Netzwerkzugriffsgruppen verwendet, die in einem späteren Abschnitt beschrieben werden.

Die folgende Tabelle enthält die Gruppen, die für das Woodgrove Bank-Szenario zum Verwalten der IPSec-Umgebung und zur Steuerung der Richtlinienanwendung erstellt wurden:

Tabelle 5.10: IPSec-Gruppennamen

Name der Gruppe	Beschreibung
No IPsec	Universelle Gruppe von Computerkonten, die nicht an der IPSec-Umgebung teilnehmen. Besteht typischerweise aus Konten für Infrastrukturcomputer.
CG_IsolationDomain_computers	Universelle Gruppe von Computerkonten, die Mitglieder der Isolierungsdomäne sind.
CG_BoundaryIG_computers	Universelle Gruppe von Computerkonten, die Mitglieder der Isolierungsgruppe "Domänengrenze" und damit berechtigt sind, mit nicht vertrauenswürdigen Systemen zu kommunizieren.
CG_NoFallbackIG_computers	Universelle Gruppe von Computerkonten, die Mitglieder der Isolierungsgruppe "Kein Klartext" und damit nicht berechtigt sind, ausgehende nicht authentifzierte Kommunikation durchzuführen.
CG_EncryptionIG_computers	Universelle Gruppe von Computerkonten, die Mitglieder der Isolierungsgruppe "Verschlüsselung" sind und damit nur verschlüsselte Kommunikation durchführen.

Zusätzlich zu den aufgeführten Gruppen könnten weitere Gruppen erstellt worden sein, um die Richtlinienanwendung während des Erstrollouts zu beschränken. Beim Bereitstellen von IPSec empfiehlt es sich nicht, die GPOs und IPSec-Richtlinien einfach zu erstellen und diese gleichzeitig allen Computern in der Domäne zuzuweisen. Mithilfe einer Domänensicherheitsgruppe lässt sich exakt steuern, welche Computer die GPOs lesen und damit die zugehörige IPSec-Richtlinie empfangen können. Die GPOs, die die IPSec-Richtlinie liefern, können alle der gesamten Domäne zugewiesen werden. Beim Rolloutprozess muss sorgfältig bedacht werden, ob die IPSec-Richtlinie ordnungsgemäß entworfen, zugewiesen und von allen Knoten abgerufen wurde, die erwartungsgemäß IPSec aushandeln werden. Der Entwurf der Gruppenrichtlinie "Domänengrenze" wird typischerweise zum Zulassen von eingehender und ausgehender Nicht-IPSec-Kommunikation mit Computern verwendet, die ihre IPSec-Richtlinie noch nicht erhalten haben.

Verteilen von IPSec-Richtlinien über Active Directory

Sie können steuern, welche GPOs auf die Computer in Active Directory angewendet werden. Dazu lassen sich die folgenden drei Möglichkeiten miteinander kombinieren:

• Verwenden von OUs mit verknüpften GPOs
• Platzieren von Computerkonten in Sicherheitsgruppen, auf die in Zugriffssteuerungslisten verwiesen wird, die für die GPOs gelten
• Verwenden von WMI-Filtern (Windows Management Instrumentation) in den GPOs

Das Steuern der GPO-Anwendung über OUs mit verknüpften GPOs ist die üblichste Form der Richtlinienanwendung in Active Directory. Diese Methode erstellt OUs in Active Directory und verknüpft GPOs mit Standorten, Domänen oder OUs. Die Computer erhalten die Richtlinie auf der Grundlage ihrer Position in Active Directory. Wenn ein Computer von einer OU in eine andere OU verschoben wird, wird die mit der zweiten OU verknüpften Richtlinie erst wirksam, wenn die Gruppenrichtlinie die Änderung während der Abfrage erkennt.

Bei der zweiten Methode werden die Sicherheitseinstellungen in den GPOs selbst verwendet. Der Zugriffssteuerungsliste des GPO wird in Active Directory eine Gruppe hinzugefügt. Dieser Gruppe werden dann die Rechte zum Lesen und Anwenden der Gruppenrichtlinienberechtigungen zugewiesen, die auf den Computern innerhalb der Gruppe wirksam werden sollen. Außerdem werden der Gruppe spezifisch Berechtigungen für Richtlinien verwehrt, die nicht auf die Computer in dieser Gruppe angewendet werden sollen. Die Richtlinie wird dann auf der Domänenebene verknüpft.

Bei der dritten Methode werden WMI-Filter in der Richtlinie verwendet, um so dynamisch den Umfang der Richtlinienanwendung zu steuern. Dazu wird ein WMI-SQL-Filter erstellt und mit der Richtlinie verknüpft. Wenn die Abfrage der Bedingung "wahr" ergibt, wird die Richtlinie angewendet, anderenfalls nicht. Computer unter Windows 2000 ignorieren die WMI-Filterung und wenden die Richtlinie an. WMI-Abfragen können zu einer Verlangsamung der GPO-Verarbeitung führen und sollten nur verwendet werden, wenn es unbedingt notwendig ist.

Die Woodgrove Bank hat entschieden, für die Steuerung der Richtlinienanwendung Sicherheitsgruppen zu verwenden, statt die Richtlinien direkt mit einer OU zu verknüpfen. Mit dieser Herangehensweise wurde das Ziel verfolgt, die IPSec-Richtlinien auf einfache Weise in die Umgebung einzuführen, ohne die Richtlinien an mehreren Standorten umsetzen oder Computer von einer OU zu einer anderen OU transportieren zu müssen, damit diese die korrekte Richtlinie erhalten. Sofern die Zugriffssteuerungslisten im GPO nicht extrem groß sind, kommt es bei dieser Methode im Vergleich zur ersten Methode zu keinem zusätzlichen Verarbeitungsaufwand, weil in beiden Fällen die Zugriffssteuerungslisten ausgewertet werden müssen. Die WMI-Filterung kam für Woodgrove nicht in Frage, weil in der Umgebung Windows 2000-Systeme vorhanden sind.

Die folgende Tabelle enthält die endgültige Konfiguration für die Zugriffssteuerungslisten der Gruppenrichtlinien. Beachten Sie, dass Zugriffssteuerungslisten in den IPSec-Richtlinienobjekten selbst nicht verwendet werden und dass eine solche Verwendung auch nicht empfohlen wird.

Tabelle 5.11: GPO-Berechtigungen für Woodgrove Bank-Richtlinien

Name des GPO	Name der Sicherheitsgruppe	Zugewiesene Rechte
IPSEC Isolation Domain Policy	No IPsec	"Gruppenrichtlinie übernehmen": Verweigern
IPSEC Isolation Domain Policy	CG_IsolationDomain_computers	"Lesen" und "Gruppenrichtlinie übernehmen": Zulassen
IPSEC Boundary Group Policy	No IPsec	"Gruppenrichtlinie übernehmen": Verweigern
IPSEC Boundary Group Policy	CG_BoundaryIG_computers	"Lesen" und "Gruppenrichtlinie übernehmen": Zulassen
IPSEC No Fallback Isolation Group Policy	No IPsec	"Gruppenrichtlinie übernehmen": Verweigern
IPSEC No Fallback Isolation Group Policy	CG_NoFallbackIG_computers	"Lesen" und "Gruppenrichtlinie übernehmen": Zulassen
IPSEC Encryption Isolation Group Policy	No IPsec	"Gruppenrichtlinie übernehmen": Verweigern
IPSEC Encryption Isolation Group Policy	CG_EncryptionIG_computers	"Lesen" und "Gruppenrichtlinie übernehmen": Zulassen

Isolierungsdomäne

Die Woodgrove Bank hatte beschlossen, die Richtlinie für die Isolierungsdomäne ("IPSEC Isolation Domain Policy") mit der Domänenebene der einzelnen Domänen in der Organisation zu verknüpfen. Die Richtlinie verwendet eine Zugriffssteuerungsliste, die verhindert, dass Clients, die nicht Mitglied der Gruppe "CG_IsolationDomain_computers" sind, die Richtlinie übernehmen. Das Recht "Gruppenrichtlinie übernehmen" für die Gruppe "Authentifizierte Benutzer" wurde aus der Richtlinien-Zugriffssteuerungsliste entfernt.

Die Richtlinie für die Isolierungsdomäne wird von allen Computern in der Organisation als IPSec-Standardrichtlinie verwendet. Der Gruppe "Domänencomputer" wird daher Lesezugriff auf die Richtlinie gewährt. Das Recht "Gruppenrichtlinie übernehmen" für die Gruppe "Authentifizierte Benutzer" wurde aus der Richtlinien-Zugriffssteuerungsliste entfernt. Während des Erstrollouts wurde die Gruppe "Domänencomputer" aus der Zugriffssteuerungsliste entfernt, und es wurde mithilfe einer anderen temporären Sicherheitsgruppe gesteuert, wer diese Richtlinie empfangen kann. Diese Herangehensweise ermöglichte eine gestaffelte Bereitstellung dieser Richtlinie.

Isolierungsgruppe "Domänengrenze"

Die Woodgrove Bank hatte beschlossen, die Richtlinie für die Isolierungsgruppe "Domänengrenze" (IPSEC Boundary Group Policy) mit der Domänenebene der einzelnen Domänen in der Organisation zu verknüpfen. Die Richtlinie verwendet eine Zugriffssteuerungsliste, die verhindert, dass Clients, die nicht Mitglied der Gruppe "CG_BoundaryIG_computers" sind, die Richtlinie übernehmen. Das Recht "Gruppenrichtlinie übernehmen" für die Gruppe "Authentifizierte Benutzer" wurde aus der Richtlinien-Zugriffssteuerungsliste entfernt.

Wenn aus geschäftlichen Gründen die Notwendigkeit besteht, dass ein System Kommunikationsanforderungen von nicht vertrauenswürdigen Systemen akzeptiert, kann das Computerkonto des betreffenden Systems in die Sicherheitsgruppe "Domänengrenze" (CG_BoundaryIG_computers) aufgenommen werden.

Isolierungsgruppe "Kein Klartext"

Die Woodgrove Bank hatte beschlossen, die Richtlinie für die Isolierungsgruppe "Kein Klartext" (IPSEC No Fallback Isolation Group Policy) mit der Domänenebene der einzelnen Domänen in der Organisation zu verknüpfen. Die Richtlinie verwendet eine Zugriffssteuerungsliste, die verhindert, dass Clients, die nicht Mitglied der Gruppe "CG_NoFallbackIG_computers" sind, die Richtlinie übernehmen. Das Recht "Gruppenrichtlinie übernehmen" für die Gruppe "Authentifizierte Benutzer" wurde aus der Richtlinien-Zugriffssteuerungsliste entfernt.

Wenn aus geschäftlichen Gründen die Notwendigkeit besteht, dass einem System die ausgehende Kommunikation mit nicht vertrauenswürdigen Systemen verweigert wird, kann das Computerkonto des betreffenden Systems in die Sicherheitsgruppe "Kein Klartext" (CG_NoFallbackIG_computers) aufgenommen werden.

Isolierungsgruppe "Verschlüsselung"

Die Woodgrove Bank hatte beschlossen, die Richtlinie für die Isolierungsgruppe "Verschlüsselung" (IPSEC Encryption Isolation Group Policy) mit der Domänenebene der einzelnen Domänen in der Organisation zu verknüpfen. Die Richtlinie verwendet eine Zugriffssteuerungsliste, die verhindert, dass Clients, die nicht Mitglied der Gruppe "CG_EncryptionIG_computers" sind, die Richtlinie übernehmen. Das Recht "Gruppenrichtlinie übernehmen" für die Gruppe "Authentifizierte Benutzer" wurde aus der Richtlinien-Zugriffssteuerungsliste entfernt.

Wenn aus geschäftlichen Gründen die Notwendigkeit besteht, dass ein System nur verschlüsselt kommuniziert, kann das Computerkonto des betreffenden Systems in die Sicherheitsgruppe "Verschlüsselung" (CG_EncryptionIG_computers) aufgenommen werden.

Zum Seitenanfang

Autorisieren von bei einer Isolierungsgruppe eingehendem Verkehr

Gemäß den Vorgaben der Woodgrove Bank durfte nur ein Teil der vertrauenswürdigen Hosts für den eingehenden Netzwerkzugriff auf die Server in der Isolierungsgruppe "Verschlüsselung" autorisiert werden. In Tabelle 4.8 in Kapitel 4 wurde definiert, dass diese Anforderungen für die folgenden Netzwerkzugriffsgruppen zu implementieren sind:

• ANAG_EncryptedResourceAccess_Users
• ANAG_EncryptedResourceAccess_Computers
• DNAG_EncryptedResourceAccess_Computers

Wenn ein Client IKE mit einem Verschlüsselungsserver initiiert, muss IKE ein Kerberos-Dienstticket erwerben, dass die ID der Domänensicherheitsgruppe enthält, die anzeigt, ob der Clientcomputer Mitglied der Zulassen-Netzwerkzugriffsgruppe (ANAG) und/oder möglicherweise der Verweigern-Zugriffsgruppe (DNAG) ist. Wenn alle Computer in der Isolierungsgruppe "Verschlüsselung" zur selben Domäne gehören, können diese NAGs als lokale Domänensicherheitsgruppen erstellt werden. Wenn die Computer in der Isolierungsgruppe "Verschlüsselung" zu unterschiedlichen vertrauenswürdigen Domänen gehören, kann entweder ein Satz globaler Domänengruppen für die NAGs verwendet werden, oder es können in jeder Domäne lokale Domänengruppen erstellt werden. Im Woodgrove Bank-Szenario ist lediglich eine Domäne vorhanden, demzufolge werden für diese NAGs lokale Domänengruppen verwendet.

Zum Definieren des Rechts Auf diesen Computer vom Netzwerk aus zugreifen, das die Autorisierung für den eingehenden Netzwerkzugriff implementiert, wurde das folgende zusätzliche GPO erstellt:

• EncryptionIG Inbound Network Authorization GPO

Der Gruppe "CG_EncryptionIG_Computers" wird das Lesen und Übernehmen dieses GPO gestattet. Der Gruppe "Authentifizierte Benutzer" wird das Leserecht aberkannt, was dazu führt, dass dieses GPO nur auf die Computer angewendet wird, die Mitglieder der Isolierungsgruppe "Verschlüsselung" sind.

Wie in Tabelle 4.8 in Kapitel 4 zu sehen ist, wird der Netzwerkzugriffsgruppe "ANAG_EncryptedResourceAccess_Computers" das autorisierte Clientdomänencomputer-Konto IPS-ST-XP-05 hinzugefügt. Außerdem werden die Konten der Verschlüsselungsserver selbst (IPS-SQL-DFS-01 und IPS-SQL-DFS-02) hinzugefügt. Dasselbe Ergebnis hätte sich aber auch einfacher erreichen lassen, indem die Gruppe "CG_EncryptionIG_computers" zum Verwalten einer umfangreicheren Liste eingesetzt worden wäre. Die Konten müssen dazu autorisiert sein, auf irgendeine Weise das Recht Auf diesen Computer vom Netzwerk aus zugreifen zu erhalten, sei es durch die ANAG-Mitgliedschaft, durch den direkten Einschluss ihrer Gruppe "CG_EncryptionIG_computers" oder durch das explizite Aufführen der Computerkonten im Recht. Anderenfalls sind die Konten nicht in der Lage, IPSec-geschützte Verbindungen untereinander herzustellen, was deren Anwendungen aber fordern. Um eine große Domänenumgebung zu simulieren, sind im Woodgrove Bank-Szenario die ANAG-Gruppen die einzigen Gruppen, die den eingehenden Zugriff autorisieren.

Da die Gruppe "Authentifizierte Benutzer" alle Domänencomputer umfasst, muss ihr das Recht Auf diesen Computer vom Netzwerk aus zugreifen entzogen werden. Autorisierte Domänenbenutzer müssen nun ausdrücklich autorisiert werden, was durch die Verwendung der vordefinierten Gruppe "Domänenbenutzer" erreicht werden kann. Die Woodgrove Bank wollte aber von der Möglichkeit profitieren, sowohl für Benutzer als auch für Computer Beschränkungen für den eingehenden Netzwerkzugriff zu definieren. Daher wurde eine lokale Domänensicherheitsgruppe mit dem Namen "ANAG_EncryptedResourceAccess_Users" erstellt und dieser Gruppe neben autorisierten Anwendungsbenutzerkonten (wie z. B. "User7") auch die lokale Administratorengruppe und die Domänenadministratorgruppen hinzugefügt. Diese Netzwerkzugriffsbeschränkungen auf Benutzerebene finden bei Authentifizierungsanforderungen auf höherer Protokollebene statt (wie z. B. RPC, SMB und SQL), nachdem die IPSec-ESP-3DES-Konnektivität erfolgreich hergestellt wurde.

Für die Netzwerkanmelderechte der Verschlüsselungsserver wurden die folgenden Domänensicherheitsgruppen erstellt, die im GPO im Recht Auf diesen Computer vom Netzwerk aus zugreifen unter "Computerkonfiguration", "Windows-Einstellungen", "Sicherheitseinstellungen", "Lokale Richtlinien", "Zuweisen von Benutzerrechten" residieren:

• ANAG_EncryptedResourceAccess_Computers
• ANAG_EncryptedResourceAccess_Users

Die folgende Gruppe wurde für dasselbe GPO mit dem Recht Zugriff vom Netzwerk auf diesen Computer verweigern konfiguriert:

• DNAG_EncryptedResourceAccess_Computers

Wenn sich "User7" nicht direkt auf den Verschlüsselungsservern anmelden kann, bedeutet das, dass "User7" zum Zugriff auf die Server IPS-SQL-DFS-01 bzw. IPS-SQL-DFS-02 den Clientcomputer IPS-ST-XP-05 verwenden muss. Der Computer IPS-ST-XP-05 muss ein gültiges Domänencomputerkonto und eine aktive IPSec-Richtlinie besitzen, die die IKE-Aushandlung mit den IP-Adressen der Verschlüsselungsserver initiiert.

Den übrigen Benutzern und Computern in der Domäne wird der Zugriff wirksam verweigert, da sie ausdrücklich vom Recht Auf diesen Computer vom Netzwerk aus zugreifen ausgenommen wurden. Nur den Computern der Isolierungsgruppe "Domänengrenze" wird durch die Verwendung der Verweigern-Netzwerkzugriffsgruppe (DNAG) als Tiefenverteidigungsmaßnahme gegen zukünftige Gruppenmitgliedschaftsänderungen, bei denen ein Computer der Gruppe "Domänengrenze" Mitglied in einer Zulassen-NAG (ANAG) werden könnte, der Zugriff ausdrücklich verwehrt. Ein expliziter Verweigerungsparameter setzt alle Formen der Zulassung außer Kraft.

Zum Seitenanfang

Weitere Überlegungen zum Thema IPSec

Für eine erfolgreiche IPSec-Implementierung müssen nicht nur die IPSec-Richtlinien definiert werden, sondern es sind auch noch weitere Überlegungen anzustellen. Die Datei Business_Requirements.xls im Ordner "Tools and Templates" enthält genaue Angaben zu Beschränkungen bei der Verwendung von IPSec.

Standardausnahmen

In Windows 2000 und Windows XP sind die folgenden Arten von Verkehr standardmäßig von der Filterung ausgenommen:

• Broadcastmeldung
• Multicast
• Kerberos-Authentifizierungsprotokoll
• IKE
• Resource Reservation Protocol (RSVP)

In der Familie der Windows Server 2003-Betriebssysteme ist Verkehr von den Broadcast-, Multicast-, RSVP- und Kerberos-Authentifizierungsprotokollen nicht standardmäßig von der Filterung ausgenommen (lediglich IKE-Verkehr ist hier standardmäßig eine Ausnahme). Broadcast- und Multicastpakete werden verworfen, wenn sie die Kriterien eines Filters mit einer Filteraktion zum Aushandeln von Sicherheit erfüllen. Standardmäßig bietet die Windows Server 2003-Familie eine beschränkte Unterstützung für das Filtern von Broadcast- und Multicastverkehr. Filter mit der Quelladresse "Beliebige IP-Adresse" werden mit Multicast- und Broadcastadressen abgeglichen. Filter mit der Quelladresse "Beliebige IP-Adresse" und der Zieladresse "Beliebige IP-Adresse" werden mit eingehenden und ausgehenden Multicastadressen abgeglichen. Mit solch einem Filter können Sie sämtlichen Verkehr blockieren. Unidirektionale Filter, mit denen spezifischer Multicast- oder Broadcastverkehr blockiert bzw. zugelassen werden kann, werden jedoch nicht unterstützt.

Aufgrund der Änderung im Standardausnahmeverhalten der IPSec-Implementierung in der Windows Server 2003-Familie sollten Sie das Verhalten der für Windows 2000 bzw. Windows XP entwickelten IPSec-Richtlinien überprüfen und festlegen, ob explizite Zulassungsfilter zum Zulassen spezifischer Verkehrstypen zu definieren sind. Zum Wiederherstellen des Windows 2000- und Windows XP-Standardverhaltens für IPSec-Richtlinien können Sie den Befehl Netsh verwenden bzw. die Registrierung bearbeiten.

So setzen Sie den IPSec-Treiber mit dem Befehl Netsh wieder auf sein Windows 2000- und Windows XP-Standardverhalten zurück

1. Geben Sie an einer Netsh-Eingabeaufforderung den folgenden Befehl ein, und drücken Sie dann die Eingabetaste:

   netsh ipsec dynamic set config ipsecexempt 0
   

2. Starten Sie den Computer neu.

So nehmen Sie den gesamten Broadcast-, Multicast- und IKE-Verkehr durch Bearbeiten der Registrierung von der IPSec-Filterung aus

1. Setzen Sie die Registrierungseinstellung HKEY_LOCAL_MACHINE\System\CurrentControlSet\
   Services\IPSEC\NoDefaultExempt DWORD auf den Wert 1. Der Schlüssel NoDefaultExempt ist standardmäßig nicht vorhanden und muss daher erstellt werden.
2. Starten Sie den Computer neu.

NAT-T

Aufgrund der Arbeitsweise von Netzwerkadressübersetzern (NAT) kann es für die Clients zu unerwarteten Ergebnissen kommen, wenn sie mit Servern unter Windows 2000 Server oder Windows Server 2003 hinter einem Netzwerkadressübersetzer kommunizieren, der IPSec-NAT-T verwendet. Standardmäßig unterstützt Windows XP SP2 keine IPSec-NAT-T-Sicherheitszuordnungen mit solchen Servern mehr.

Diese Änderung wurde vorgenommen, um ein bekanntes Sicherheitsrisiko bei Situationen zu vermeiden, in denen es zu der folgenden Reihenfolge von Ereignissen kommt:

1. Der Netzwerkadressübersetzer ist so konfiguriert, dass er IKE- und IPSec-NAT-T-Verkehr einem Server in einem NAT-konfigurierten Netzwerk (Server 1) zuordnet.
2. Der Client, der sich außerhalb des NAT-konfigurierten Netzwerks befindet (Client 1), verwendet zum Einrichten bidirektionaler Sicherheitszuordnungen mit Server 1 IPSec-NAT-T.
3. Der Client, der sich innerhalb des NAT-konfigurierten Netzwerks befindet (Client 2), verwendet zum Einrichten bidirektionaler Sicherheitszuordnungen mit Client 1 IPSec-NAT-T.
4. Es tritt ein Zustand ein, bei dem Client 1 aufgrund der statischen Zuordnungen des Netzwerkadressübersetzers, die IKE- und IPSec-NAT-T-Verkehr Server 1 zuordnen, die Sicherheitszuordnungen mit Client 2 neu einrichten muss. Dieser Zustand kann dazu führen, dass der Verkehr zur Aushandlung der IPSec-Sicherheitszuordnung, den Client 1 eigentlich an Client 2 senden wollte, irrtümlicherweise an Server 1 geleitet wird.

Diese Situation ist zwar unwahrscheinlich, das Standardverhalten von Windows XP SP2-basierten Computer verhindert aber grundsätzlich IPSec-NAT-T-basierte Sicherheitszuordnungen zu Servern, die sich hinter einem Netzwerkadressübersetzer befinden. Auf diese Weise soll sichergestellt werden, dass eine solche Situation nie eintritt.

Wenn IPSec-Kommunikation über NAT-Geräte erforderlich ist, empfiehlt es sich, für alle Server, zu denen eine direkte Verbindung aus dem Internet hergestellt werden kann, öffentliche IP-Adressen zu verwenden. Wenn diese Konfiguration nicht möglich ist, können Sie das Standardverhalten von Windows XP SP2 ändern und so IPSec-NAT-T-Sicherheitszuordnungen zu Servern zulassen, die sich hinter einem Netzwerkadressübersetzer befinden.

So erstellen und konfigurieren Sie den Registrierungswert "AssumeUDPEncapsulationContextOnSendRule"

1. Klicken Sie auf Start, dann auf Ausführen, geben Sie regedit ein, und klicken Sie anschließend auf OK.

2. Klicken Sie auf den folgenden Registrierungsunterschlüssel:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   Services\IPSec
   

3. Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie auf DWORD-Wert.

4. Geben Sie im Feld Neuer Wert #1 Folgendes ein, und drücken Sie anschließend die Eingabetaste: AssumeUDPEncapsulationContextOnSendRule

   Hinweis

   
   Bei der Eingabe des Namens für diesen Wert ist auf die Groß- und Kleinschreibung zu achten.

5. Klicken Sie mit der rechten Maustaste auf AssumeUDPEncapsulationContextOnSendRule, und klicken Sie dann auf Ändern.

6. Geben Sie im Feld Wert einen der folgenden Werte ein:

   • 0 (Standardwert). Mit dem Wert "0" (Null) wird Windows so konfiguriert, dass es keine Sicherheitszuordnungen mit Servern einrichten kann, die sich hinter Netzwerkadressübersetzern befinden.

   • 1. Mit dem Wert "1" wird Windows so konfiguriert, dass es Sicherheitszuordnungen mit Servern einrichten kann, die sich hinter Netzwerkadressübersetzern befinden.

   • 2. Mit dem Wert "2" wird Windows so konfiguriert, dass es Sicherheitszuordnungen einrichten kann, wenn sich sowohl der Server als auch der Windows XP SP2-basierte Clientcomputer hinter Netzwerkadressübersetzern befinden.

     Hinweis

     
     Die Konfiguration, die mit dem Wert "2" erzielt wird, entspricht der ursprünglichen Konfiguration von Windows XP bzw. Windows XP SP1.

7. Klicken Sie auf OK, und schließen Sie den Registrierungs-Editor.

8. Starten Sie den Computer neu.

Nachdem AssumeUDPEncapsulationContextOnSendRule mit dem Wert "1" oder "2" konfiguriert wurde, kann Windows XP SP2 eine Verbindung zu Servern herstellen, die sich hinter einem Netzwerkadressübersetzer befinden.

Windows Server 2003-basierte Server müssen außerdem aktualisiert werden, damit sie, wenn sie hinter einem NAT-Gerät platziert werden, ordnungsgemäß mit IPSec funktionieren. Wie Sie Windows Server 2003 Service Pack 1 erhalten können, erfahren Sie unter folgender Adresse:

https://go.microsoft.com/fwlink/?LinkId=41652

Damit eingehende NAT-Verbindungen ordnungsgemäß arbeiten, muss die PMTU-Ermittlung aktiviert werden und funktionieren. Einige Quellen, wie z. B. der Windows XP Hardening Guide und der Windows Server 2003 Hardening Guide, empfehlen die Deaktivierung der PMTU-Ermittlung (Discovery), und in einigen Fällen stellen sie Richtlinienvorlagen zum Deaktivieren dieser Funktionalität bereit.

So aktivieren Sie PMTU-Ermittlung

1. Klicken Sie auf Start, dann auf Ausführen, geben Sie regedit ein, und klicken Sie anschließend auf OK.

2. Klicken Sie auf den folgenden Registrierungsunterschlüssel:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
   Services\tcpip\parameters
   

3. Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie auf DWORD-Wert.

4. Geben Sie im Feld Neuer Wert #1EnablePMTUDiscovery, und drücken Sie dann die Eingabetaste.

5. Klicken Sie mit der rechten Maustaste auf EnablePMTUDiscovery, und klicken Sie dann auf Ändern.

6. Geben Sie im Feld Wert "1" ein.

7. Klicken Sie auf OK, und schließen Sie den Registrierungs-Editor.

8. Starten Sie den Computer neu.

Auf Hosts, auf denen Windows 2000 läuft und die an einem NAT-T-Szenario teilnehmen, muss zum ordnungsgemäßen Funktionieren das im Knowledge Base-Artikel 818043, L2TP/IPSec-NAT-T-Update für Windows XP und Windows 2000, beschriebene Hotfix installiert werden.

Weitere Informationen finden Sie in den folgenden Knowledge Base-Artikeln:

• 885407, In Windows XP Service Pack 2 wird das Standardverhalten von IPsec NAT Traversale (NAT-T) geändert, auf der Microsoft-"Hilfe und Support"-Website unter https://support.microsoft.com/kb/885407
• 818043, L2TP/IPSec-NAT-T-Update für Windows XP und Windows 2000, auf der Microsoft-"Hilfe und Support"-Website unter https://support.microsoft.com/kb/818043

IPSec und Windows-Firewall

Auf Computern, auf denen Windows XP SP2 ausgeführt wird, bietet die Windows-Firewall zusätzlichen Schutz vor Angriffen, indem sie eingehenden unerwünschten Verkehr blockiert. IPSec in Windows XP SP2 ist Windows-Firewall-fähig. Wenn eine aktive IPSec-Richtlinie vorhanden ist, weisen die IPSec-Komponenten von Windows XP SP2 die Windows-Firewall an, die UDP-Ports 500 und 4500 für den IKE-Verkehr zu öffnen.

Ein weiteres Feature der IPSec-Unterstützung besteht darin, dass Sie durch die Gruppenrichtlinie festlegen können, dass der gesamte IPSec-geschützte Verkehr die Windows-Firewall-Verarbeitung umgeht. Weitere Informationen dazu finden Sie in Anhang A des Dokuments Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2, das unter folgender Adresse zur Verfügung steht: https://download.microsoft.com/download/
6/8/a/68a81446-cd73-4a61-8665-8a67781ac4e8/wf_xpsp2.doc (in englischer Sprache).

IPSec und Internetverbindungsfirewall (ICF)

Auf Windows XP-basierten Computern, auf denen nicht SP2 ausgeführt wird, erfüllt die Internetverbindungsfirewall (Internet Connection Firewall, ICF) möglicherweise besser die Sicherheitsanforderungen für das Filtern von Verkehr. In Windows XP SP1 bietet die ICF Filterung und kann eingehenden Multicast- und Broadcastverkehr blockieren. Sie erkennt aber keinen Verkehr, der durch IPSec-AH oder -ESP im Transport- oder Tunnelmodus geschützt ist. Da IPSec auf der Netzwerkebene unterhalb von ICF und IKE oberhalb von ICF arbeitet, muss für den eingehenden Verkehr eine statische Zulassung für IKE (UDP-Port 500) eingerichtet werden. Wenn IPSec Verkehr blockiert, enthält das Protokoll der von der ICF verworfenen Pakete keine Pakete, die von IPSec verworfen wurden.

Zum Seitenanfang

Zusammenfassung

In diesem Kapitel wurde das Erstellen und Bereitstellen von IPSec-Richtlinien beschrieben, die auf dem in Kapitel 4 erstellten Isolierungsgruppenentwurf basieren. Die Informationen wurden dabei auf die folgenden sieben Hauptaufgaben verteilt:

• Identifizieren und Erstellen von Filterlisten
• Identifizieren und Erstellen von Filteraktionen
• Identifizieren und Erstellen von Regeln
• Identifizieren und Erstellen von IPSec-Richtlinien
• Definieren eines Verteilungsmechanismus für die IPSec-Richtlinien
• Definieren einer Rolloutbereitstellungsmethode für die IPSec-Richtlinien
• Definieren der Autorisierungen für die Steuerung des eingehenden Netzwerkzugriffs durch Konfigurieren von Gruppenrichtlinien-Netzwerkanmelderechten

Mit der Abarbeitung dieser Aufgaben sind die Entwurfs- und Planungsphasen für die Server- und Domänenisolierungslösung abgeschlossen. In der nächsten Phase des Projekts erfolgt die Bereitstellung einer Test- bzw. Pilotumgebung, in der der Entwurf geprüft werden kann. Microsoft hat diese Überprüfung in seinen Testumgebungen vorgenommen und das Woodgrove Bank-Szenario als Pilotumgebung verwendet. Wenn Sie diese Umgebung nachstellen oder die Bereitstellungsphasen genauer betrachten möchten, finden Sie in Anhang C dieses Leitfadens genaue Anleitungen für den Bereitstellungsprozess, den Microsoft in seinen Testumgebungen zur Validierung des Entwurfs für das Szenario verwendet hat.

Weitere Informationen

Dieser Abschnitt enthält Links zu weiterführenden Informationen zu den in diesem Kapitel erwähnten Technologien.

Allgemeine Hintergrundinformationen zu IPSec

• IPSec-Homepage von Microsoft:

  www.microsoft.com/ipsec (in englischer Sprache)

• Die Seite IPsec for Windows 2000 auf der Microsoft-Website enthält umfangreiche Windows 2000-spezifische IPSec-Informationen: www.microsoft.com/windows2000/technologies/
  communications/ipsec/default.asp (in englischer Sprache).

• Die Seite IPsec im Windows Server 2003-Abschnitt der Microsoft-Website enthält umfangreiche Windows Server 2003-spezifische IPSec-Informationen: www.microsoft.com/windowsserver2003/technologies/
  networking/ipsec/
  default.mspx (in englischer Sprache).

• Kapitel Deploying IPsec im Windows Server 2003 DeploymentKit unter www.microsoft.com/resources/documentation/
  WindowsServ/2003/all/deployguide/en-us/DNSBJ_IPS_OVERVIEW.asp (in englischer Sprache).

Zusätzliche Informationen

• Die Seite Windows Server 2003 Group Policy auf der Microsoft-Website bietet umfangreiche Informationen zur Verwaltung von Windows-Systemen mithilfe von Gruppenrichtlinien in Active Directory: www.microsoft.com/windowsserver2003/technologies/
  management/grouppolicy/
  default.mspx (in englischer Sprache).

• Der Cable Guy-Artikel vom Oktober 2004, Problems with Using Network Address Translators, enthält zusätzliche Informationen zu spezifischen Problemen im Zusammenhang mit NAT und IPSec. Dieser Artikel steht auf der Microsoft-Website unter folgender Adresse zur Verfügung:

  www.microsoft.com/technet/community/columns/
  cableguy/cg1004.mspx (in englischer Sprache).

Zum Seitenanfang

| Home | Technische Artikel | Community