Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien Anhang A: Überblick über IPSec-Richtlinienkonzepte

Dieser Anhang gibt einen detaillierten Überblick über die Begriffe, Prozesse und Konzepte von IPSec. Dabei sollen die nötigen Grundlagen für IPSec geschaffen werden, wie im Leitfaden Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien beschrieben.

Der Inhalt dieses Anhangs wurde erstmals in dem von Microsoft und Foundstone Strategic Security verfassten Whitepaper "Using Microsoft Windows IPsec to Help Secure an Internal Corporate Network Server" veröffentlicht (verfügbar in englischer Sprache unter: www.microsoft.com/ipsec).

Das Whitepaper liefert zusätzliche Informationen über das erste Modell der Verwendung von IPSec zur Sicherung des Netzwerkzugriffs auf interne Microsoft® Windows®-Server, die vertrauliche Daten verarbeiten oder speichern. Obwohl diese zusätzlichen Informationen für das Verständnis des Leitfadens Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien nicht erforderlich sind, stellen sie eine nützliche Hintergrundinformation dar.

Auf dieser Seite	In diesem Beitrag
Einführung IPSec-Richtlinienfilter IKE-Aushandlungsprozess Sicherheitsmethoden IPSec-Kapselungsmodi und Protokollformate IKE-Authentifizierung IKE-Authentifizierungsmethode und Reihenfolge der Sicherheitsmethoden Optionen für die Aushandlung der Sicherheit	Ü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.)

Einführung

Beim Erstellen einer IPSec-Richtlinie konfigurieren Sie IPSec-Regeln (die das IPSec-Verhalten festlegen) und -Einstellungen (die ungeachtet der konfigurierten Regeln zutreffen). Damit eine IPSec-Richtlinie umgesetzt werden kann, müssen Sie diese nach dem Konfigurieren einem Computer zuweisen. Obwohl sich mehrere IPSec-Richtlinien auf einem Computer befinden können, kann immer nur jeweils eine IPSec-Richtlinie einem Computer zugewiesen werden.

Eine IPSec-Regel legt neben weiteren Einstellungen fest, welcher Verkehrstyp von IPSec untersucht wird, ob Verkehr zugelassen, blockiert oder Sicherheit ausgehandelt oder wie ein IPSec-Peer authentifiziert wird. Beim Konfigurieren einer IPSec-Regel wird eine Filterliste konfiguriert, die mindestens einen Filter, eine Filteraktion, Authentifizierungsmethoden, einen Verbindungstyp und einen IPSec-Kapselungsmodus umfasst (Transportmodus oder Tunnelmodus). Eine IPSec-Regel wird gewöhnlich für einen bestimmten Zweck konfiguriert (zum Beispiel, "Blockieren von eingehendem Datenverkehr vom Internet zum TCP-Port 135").

Wie bei einem Firewallregelsatz wird mithilfe von Filtern festgelegt, welcher Verkehr geprüft werden soll, mit Quell- und Ziel-IP-Adresse, Protokollen und Portnummern (sofern zutreffend). Eine Filteraktion definiert die Sicherheitsanforderungen für den Netzwerkverkehr. Sie kann konfiguriert werden, um Sicherheit zuzulassen, zu sperren oder auszuhandeln (IPSec aushandeln). Wenn eine Filteraktion zum Aushandeln von Sicherheit konfiguriert wird, müssen zudem Sicherheitsmethoden zum Schlüsselaustausch konfiguriert werden (sowie deren Reihenfolge), um zu entscheiden, ob anfänglich eingehender, ungeschützter Datenverkehr erlaubt, ungeschützte Kommunikation mit Computern, die IPSec nicht unterstützen, zugelassen und PFS (Perfect Forward Secrecy) verwendet werden sollen.

Durch Einstellungen und Sicherheitsmethoden zum Schlüsselaustausch werden IPSec-Protokollformate (Authentifizierungs-Header (AH) oder Encapsulated Security Payload (ESP)), Verschlüsselungs- und Hashingalgorithmen, die Schlüssellebensdauer und andere Einstellungen, die für die Konfiguration des Internet Key Association (IKE)-Hauptmodus und IPSec-Sicherheitszuordnungen (SA) erforderlich sind, festgelegt. Unter SA versteht man die Übereinstimmung von Sicherheitseinstellungen mit schlüsselfertigem Material. Die in der ersten IKE-Aushandlungsphase erstellte SA wird als IKE-Hauptmodus-SA (auch ISAKMP-Hauptmodus-SA) bezeichnet. Durch die IKE-Hauptmodus-SA wird die IKE-Aushandlung geschützt. Die in der zweiten IKE-Aushandlungsphase erstellten SAs werden als IPSec-SAs bezeichnet (oder IKE-Schnellmodus-SAs, da jede Aushandlung des IKE-Schnellmodus die IPSec-SA für jede Richtung aushandelt). IPSec-SAs schützen den Anwendungsverkehr.

In diesem Abschnitt finden Sie Informationen zu den folgenden wichtigen IPSec-Richtlinienkonzepten:

• IKE-Aushandlungsprozess
• IPSec-Richtlinienfilter
• Sicherheitsmethoden
• IPSec-Protokollformate
• IKE-Authentifizierung
• IKE-Authentifizierungsmethode und Reihenfolge der Sicherheitsmethoden
• Optionen für die Aushandlung der Sicherheit

Weitere Informationen zu IPSec-Richtlinienkonzepten finden Sie im Hilfe- und Supportcenter für Microsoft Windows Server™ 2003.

Zum Seitenanfang

IPSec-Richtlinienfilter

Filter sind der wichtigste Bestandteil der IPSec-Richtlinien. Wenn die geeigneten Filter nicht in den Client- oder Server-Richtlinien angegeben oder die IP-Adressen vor der Aktualisierung der Richtlinienfilter geändert werden, kann möglicherweise kein ausreichender Schutz gewährleistet werden. IPSec-Filter werden in die IP-Ebene des TCP/IP-Netzwerkprotokollstapels auf dem Computer eingefügt, damit alle eingehenden bzw. ausgehenden IP-Pakete untersucht (gefiltert) werden können. Abgesehen von einer kleinen Verzögerung, die für die Aushandlung einer Sicherheitsbeziehung zwischen zwei Computern erforderlich ist, bleibt IPSec für Endbenutzeranwendungen und Dienste des Betriebssystems transparent. Filter sind durch die Sicherheitsregel in einer IPSec-Richtlinie einer entsprechenden Filteraktion zugeordnet. Windows IPSec unterstützt sowohl den IPSec-Tunnelmodus als auch den IPSec-Transportmodus als Option in dieser Regel. Die Konfiguration von IPSec-Tunnelmodusregeln unterscheidet sich sehr stark von der Konfiguration von IPSec-Transportmodusregeln.

Die Filterregeln der IPSec-Richtlinie entsprechen den Firewallregeln. Mit der grafischen Benutzeroberfläche der IP-Sicherheitsrichtlinienverwaltung des MMC-Snap-In (MMC – Microsoft Management Console) kann IPSec konfiguriert werden, um spezielle Verkehrstypen anhand von Quell- und Zieladresskombinationen und speziellen Protokollen und Ports zuzulassen oder zu sperren.

Informationen zu IPSec-Filtern

Filterlisten sind Listen von bekannten Subnetzen und Infrastruktur-IP-Adressen. Es sollte hervorgehoben werden, dass alle in den Regeln enthaltenen Filter den eingehenden und ausgehenden Zugriff steuern. In diesem Abschnitt werden die wichtigsten Informationen zur Auswirkung der IPSec-Filter auf die Paketverarbeitung geliefert.

Das MMC-Snap-In für den IPSec-Monitor von Windows Server 2003 gibt eine sehr genaue Beschreibung der Anordnung von IPSec-Filtern. Wenn der IPSec-Dienst eine Reihe von IPSec-Richtlinienregeln verarbeitet, werden die Filter in zwei Typen kopiert, um die zwei Phasen der IKE-Aushandlung zu steuern:

1. IKE-Hauptmodusfilter. Diese Filter verwenden lediglich die Quell- und Ziel-Adresse der in der IPSec-Richtlinie definierten Filter, um den IKE-Hauptmodus zu steuern. Die IKE-Hauptmodus-spezifischen Filter verfügen über eine Aushandlungsrichtlinie des IKE-Hauptmodus, die Folgendes definiert:
   • Sicherheitsmethoden des IKE-Hauptmodus, definiert nach Einstellungen zum Schlüsselaustausch für die IPSec-Richtlinie, wie die Diffie Hellman-Hauptschlüsselstärke und die Verschlüsselungs- und Integritätsalgorithmen zum Schutz der IKE-Aushandlung.
   • Lebensdauer des IKE-Hauptmodus und begrenzte Anzahl von Sitzungsschlüsseln, generiert von demselben Hauptschlüssel.
   • Authentifizierungsmethoden.
2. IKE-Schnellmodusfilter. Diese Filter enthalten die vollständigen Filterinformationen zu Adressen, Protokollen und Ports. Diese Filterdefinition wird mithilfe des IKE-Schnellmodus ausgehandelt, um festzulegen, welcher Verkehr innerhalb eines IPSec-Sicherheitszuordnungspaares gesichert wird. Jeder Filter hat eine entsprechende Gewichtung und eine Reihe von Sicherheitsmethoden, die Folgendes definieren:
   • Optionen für AH- oder ESP-Kapselung im Transport- oder Tunnelmodus.
   • Eine Liste der Verschlüsselungs- und Integritätsalgorithmen.
   • Lebensdauer der IPSec-Sicherheitszuordnung in KB und Sekunden.
   • PFS-Sicherheitseinstellungen.

Die IKE-Schnellmodusfilter sind die Filterlisten, die dem IPSec-Treiber zur Verstärkung gegeben werden. Der IPSec-Treiber überprüft mit diesen Filtern den eingehenden und ausgehenden IP-Verkehr nach Gewichtung. Im folgenden Abschnitt über den IKE-Verhandlungsprozess wird beschrieben, wie IPSec-Sicherheitszuordnungen mithilfe dieser Richtliniensteuerungen von IKE ausgehandelt und verwaltet werden.

Die in der IPSec-Richtlinie definierten Filter werden als "generische" Filter bezeichnet, da sie bei angewendeter Richtlinie vom IPSec-Dienst möglicherweise interpretiert werden müssen. Der IPSec-Dienst wertet alle generischen Filter nach spezifischen Filtern aus, wenn die IPSec-Richtlinie (oder Änderung) auf dem Computer angewendet wird. Spezifische Filter verfügen über einen eingebauten Algorithmus zur Berechnung der Gewichtung bzw. Reihenfolge. Dies hängt auch davon ab, wie spezifisch die Filtereinstellungen bei Auswahl des Datenverkehrs sind. Dabei gilt: Je höher der Gewichtungswert, desto spezifischer der Filter. Alle spezifischen Filter werden entsprechend ihrer Gewichtung sortiert. Die Gewichtung des Filters richtet sich zunächst nach der IP-Adresse, nach den Protokollen und schließlich nach den Ports, die innerhalb dieses Filters definiert werden können. Durch diesen Ansatz wird gewährleistet, dass die Reihenfolge der Regeln innerhalb einer Richtlinie und die Reihenfolge der Filter in allen unterschiedlichen Filterlisten keine Auswirkungen auf das vom IPSec-Filtertreiber während der Paketverarbeitung erzwungene Filterverhalten hat. Die Pakete werden zunächst mit den spezifischsten Filtern abgeglichen, um die Zeit, die im Vergleich zur gesamten Reihe von Filtern für die Verarbeitung der einzelnen Pakete erforderlich ist, so gering wie möglich zu halten. Die Filteraktion, die dem spezifischsten, mit einem Paket übereinstimmenden Filter entspricht, ist die einzige Aktion, die für dieses Paket durchgeführt wird. Der generischste Filter, der definiert werden kann, stimmt mit jeder IP-Adresse, allen Protokollen und Ports überein. Betrachten Sie beispielsweise die folgenden vier Filterdefinitionen:

• Beliebig <-> Beliebig, beliebiges Protokoll
• Beliebig <-> 192.168.1.0/24, beliebiges Protokoll
• Beliebig <-> 192.168.1.10/24, beliebiges Protokoll
• Beliebig <-> 192.168.1.10/24, TCP-Quellport Beliebig, Zielport 25

Der Filter "Beliebig bis Beliebig" ist der allgemeinste Filter, der definiert werden kann. Er wird nur von Windows Server 2003 und Windows XP Service Pack 2 (SP2) unterstützt. Normalerweise wird dieser Filter mit einer Blockierungsaktion verwendet, um ein Standardverhalten "Alle verweigern" zu erzielen. Wenn dieser Filter zum Blockieren des gesamten Verkehrs verwendet wird, können die restlichen spezifischeren Filter als Ausnahmen für den ersten Filter betrachtet werden. Unter Windows 2000 ist der allgemeinste unterstützte Filter "Beliebig <-> Subnetz, beliebiges Protokoll" oder "Beliebig <-> Eigene IP-Adresse", wenn Subnetze nicht verwendet werden.

Alle vier Filter entsprechen dem eingehenden Verkehr von einer beliebigen IP-Adresse bis 192.168.1.10 über TCP-Port 25 und die entsprechenden ausgehenden Antworten von Port 25. Der vierte Filter ist der spezifischste, da er Ziel-IP-Adresse, Protokoll und Portnummer bestimmt. Wenn alle vier durch den IPSec-Treiber verstärkt werden, entspricht ein für TCP-Port 25 bestimmtes eingehendes Paket nur dem vierten und spezifischsten Filter. Wenn ein Remotesystem den TCP-Datenverkehr an einen anderen Port als 25 bis 192.168.1.10 sendet, wird der dritte Filter angepasst. Wenn Datenverkehr an eine IP-Adresse im 192.168.1.0 Subnetz gesendet wird, ausschließlich 192.168.1.10, ist der zweite Filter der spezifischste für diesen Datenverkehr.

Potenzielle Filterentwurfaspekte

Beim Definieren von Filtern sollten bestimmte Kombinationen aus Quell- und Zieladressoptionen nicht verwendet werden. Wie oben bereits erwähnt, sollten Filter, die "Beliebige IP-Adresse zu Beliebige IP-Adresse" angeben, nicht für Hosts mit Windows 2000 verwendet werden.

Allgemein gilt, je mehr Filter in einer Richtlinie, desto größer die Auswirkungen auf die Paketverarbeitung. Diese Leistungsverringerung wird als reduzierter Durchsatz, erhöhte Auslastung nicht ausgelagerter Pool-Kernelspeicher und erhöhte CPU-Auslastung angegeben. Es ist sehr schwierig, die Auswirkungen auf die Leistung genau einzuschätzen, da diese vom Gesamtvolumen des Datenverkehrs, der Menge des verarbeiteten IPSec-gesicherten Datenverkehrs und der CPU-Auslastung auf dem Computer abhängen. Daher sollten Leistungstests der IPsec-Richtlinie in den Planungsaufwand miteinbezogen werden. Die Auswirkungen einiger hundert Filter sind bis auf Computer mit sehr hohem Durchsatz sehr gering.

Windows 2000 verfügt hinsichtlich des Umgangs mit vielen Filtern über keine Optimierung. Der IPSec-Treiber muss die gesamte Filterliste sequentiell durchsuchen, um eine Übereinstimmung zu finden.

Bei Windows XP und Windows Server 2003 wurden viele Optimierungen zur Beschleunigung der Filterverarbeitung vorgenommen, um eine Vielzahl von Filtern in der IPSec-Richtlinie verwenden zu können. Filter der Form "Von <IP-Adresse> Zu <IP-Adresse>" wurden unabhängig von Protokollen oder Ports unter Verwendung des GPC-Treibers (Generic Packet Classifier) für einen sehr schnellen Lookup optimiert. GPC kann mit nahezu allen Filtern ohne Durchsatz-Leistungseinbußen umgehen. Daher werden große Ausnahmelisten mit "Eigene IP-Adresse" zu "<bestimmte Ausnahme-IP-Adresse>" leicht unterstützt, vorausgesetzt, es gibt ausreichend nicht ausgelagerten Kernelspeicher für die gesamte Filterliste. Filter, die weder für die Quelle noch für das Ziel eine bestimmte IP-Adresse haben, können nicht durch GPC optimiert werden. Das heißt, dass nach den Filtern "Beliebige IP <-> Bestimmte IP (oder Subnetz)" sequentiell gesucht werden muss. Die Implementierung wurde jedoch über Windows 2000 verbessert.

Das Verwenden von "Eigene IP-Adresse" ist zwar in vielen Fällen angemessen, kann jedoch auch bei Hosts mit vielen IP-Adressen, wie beispielsweise bei einem Webserver, der viele virtuelle Websites ausführt, zu Problemen führen. Dies kann auch zu einer Verzögerung in der Verfügbarkeit des IPSec-Treiberfilterpakets führen, wenn es eine große Anzahl an Filtern gibt, die "Eigene IP-Adresse" verwenden. Der IPSec-Dienst verarbeitet diese während des Dienststarts und bei Adressänderungen. Durch die Verzögerung können Sicherheitslücken oder Verzögerungen bei der Herstellung einer sicheren Verbindung mit IPSec entstehen. Leistungstests sollten daher angemessene Auswirkungen eines bestimmten Richtlinienentwurfs bestätigen.

Die Definition "Eigene IP-Adresse" kann am besten verwendet werden, wenn Datenverkehr für einen bestimmten Port oder ein bestimmtes Protokoll zugelassen oder verweigert wird. Bei der IPSec-Richtlinienerstellung für die Woodgrove Bank wird mit dem Filter "Eigene IP-Adresse" ein spezifischerer Filter erstellt, der erlaubt, dass Internet Control Message Protocol (ICMP)-Datenverkehr zwischen allen Computern im Klartext gesendet und empfangen werden kann.

Wenn einem mobilen Client in der Organisation die Regel "Eigene IP-Adresse <-> Beliebige IP-Adresse" zugewiesen wird und er anschließend auf ein externes Netzwerk gestellt wird, kann er in dieser Umgebung möglicherweise nicht kommunizieren. Wenn dem Client das Zurückgreifen auf unsichere Verbindung erlaubt wird, treten bei Verbindungen mit allen Zielorten Verzögerungen von mindestens drei Sekunden auf. Wenn der Zielort eine IKE-Antwort gibt, schlägt die IKE-Aushandlung fehl, da die IKE mit der Domänenvertrauensstellung (Kerberos) nicht authentifizieren kann. Werden RFC 1918-Private Adressen als interne Netzwerk-Subnetze verwendet, werden mobile Clients beim Verbinden mit Hotels, Heimnetzwerken und anderen internen Netzwerken blockiert. Wenn es bei mobilen Clients Konnektivitätsprobleme gibt, werden lokale Administratorrechte erforderlich, um den IPSec-Dienst bei Verbindungen mit anderen Netzwerken abzubrechen. Daher muss möglicherweise ein Domänenanmeldeskript verwendet werden, um zu überprüfen, ob der IPSec-Dienst bei Verbindungen mit dem internen Netzwerk ausgeführt wird.

Windows 2000 wurde ursprünglich nicht dafür konzipiert, um Pakete mithilfe von Multicast- und Broadcastadressen zu filtern, da dieser Datenverkehr nicht durch die IKE-Aushandlung geschützt werden konnte. Daher zählten Multicast- und Broadcast-Pakettypen zu den ursprünglichen Standardausnahmen, die IPSec-Filter umgingen. Eine ausführliche Erklärung der Sicherheitsaspekte von Standardausnahmen und den von Service Pack 3 durchgeführten Änderungen zum standardmäßigen Entfernen einiger Standardausnahmen finden Sie im Microsoft Knowledge Base (KB)-Artikel 811832 "IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios" unter https://support.microsoft.com/kb/811832 (in englischer Sprache). Die TCP/IP-Integration mit IPSec in Windows XP und Windows Server 2003 wurde verbessert, um alle IP-Pakettypen zu filtern. Da IKE für Multicast und Broadcast jedoch keine Sicherheit aushandeln kann, wird nur begrenzter Support für das Filtern zur Verfügung gestellt. Weitere Details zum Entfernen von Standardausnahmen und dem Umfang von Filtersupport für Multicast- und Broadcast-Datenverkehr finden Sie im KB-Artikel 810207 "IPSec default exemptions are removed in Windows Server 2003" (in englischer Sprache) unter https://support.microsoft.com/kb/810207. Unter Windows XP SP2 werden dieselben Filterfunktionen "Beliebig <-> Beliebig" wie unter Windows Server 2003 verwendet.

Zum Seitenanfang

IKE-Aushandlungsprozess

Das IKE-Protokoll soll dazu beitragen, zwischen allen Computern eine Vertrauensstellung zu ermöglichen, Sicherheitsoptionen auszuhandeln und ein gemeinsames, geheimes kryptografisches Schlüsselmaterial dynamisch zu erstellen. Um eine erfolgreiche und sichere Kommunikation zu gewährleisten, führt IKE einen zweiphasigen Vorgang durch: Aushandlung der Phase 1 (Hauptmodus) und Aushandlung der Phase 2 (Schnellmodus). Vertraulichkeit und Authentifizierung können durch Verschlüsselungs- und Authentifizierungsalgorithmen, auf die sich beide Computer während Sicherheitsaushandlungen einigen, in jeder Phase sichergestellt werden.

Hauptmodusaushandlung

Während der Hauptmodusaushandlung stellen die beiden Computer einen sicheren authentifizierten Kanal her. Zuerst werden die folgenden IPSec-Richtlinienparameter ausgehandelt: Verschlüsselungsalgorithmus (DES oder 3DES), Integritätsalgorithmus (MD5 oder SHA1), Diffie-Hellman-Gruppe für grundlegendes Schlüsselmaterial (Gruppe 1, Gruppe 2 oder Gruppe 2048 unter Windows Server 2003) und Authentifizierungsmethode (Protokoll Kerberos Version 5, öffentliches Schlüsselzertifikat oder vorinstallierter Schlüssel). Nach dem Aushandeln von IPSec-Richtlinienparametern ist der Diffie-Hellman-Austausch von öffentlichen Schlüsseln abgeschlossen. Mit dem Diffie-Hellman-Algorithmus werden gemeinsame, symmetrische und geheime Schlüssel zwischen Computern erstellt. Wenn der Diffie-Hellman-Austausch abgeschlossen ist, erstellt der IKE-Dienst auf jedem Computer den Hauptschlüssel, der zum Authentifizierungsschutz verwendet wird. Der Hauptschlüssel wird mit Aushandlungsalgorithmen und Methoden zur Authentifizierung von Identitäten verwendet. Der Initiator der Kommunikation macht dem Responder daraufhin ein Angebot für eine potenzielle SA. Der Responder sendet entweder eine Antwort, in der er das Angebot annimmt, oder eine Antwort mit Alternativen. Die Hauptmodus-SA ist das Ergebnis einer erfolgreichen IKE-Hauptmodusaushandlung.

Aushandlung des Schnellmodus

Während der Aushandlung des Schnellmodus wird ein Paar IPSec-SAs zum Schutz des Anwendungsverkehrs eingerichtet. Dazu gehören Pakete, die über TCP, UDP (User Datagram Protocol) und andere Protokolle gesendet werden. Zuerst werden die folgenden Richtlinienparameter ausgehandelt: IPSec-Protokollformate (AH oder ESP), Hashalgorithmus für Integrität und Authentifizierung (MD5 oder SHA1) und Algorithmus für Verschlüsselung (DES oder 3DES), falls eine Verschlüsselung erforderlich ist. Zu diesem Zeitpunkt wird eine gemeinsame Vereinbarung hinsichtlich des IP-Pakettyps im erstellten IPSec-SA-Paar getroffen. Nach Aushandlung der IPSec-Richtlinienparameter wird das Sitzungsschlüsselmaterial (kryptografische Schlüssel und Schlüssellebensdauer, in Sekunden und Kilobit, für jeden Algorithmus) aktualisiert oder ausgetauscht.

Jede IPSec-SA wird von einem Sicherheitsparameterindex (SPI) identifiziert, der in den IPSec-Header jedes gesendeten Pakets eingefügt wird. Ein SPI identifiziert die eingehende IPSec-SA, der andere SPI die ausgehende IPSec-SA.

IKE-Hauptmodus-SAs und IPSec-SAs

Wenn IPSec zur Sicherung des Datenverkehrs verwendet wird, werden eine IKE-Hauptmodus-SA und zwei IPSec-SAs eingerichtet. In diesem Beispielszenario werden für IPSec-gesicherte Verbindungen, die zwischen CORPCLI und CORPSRV auftreten, folgende SAs eingerichtet:

CORPCLI [IP1] <-------- IKE-Hauptmodus-SA [IP1, IP2] -----> [IP2] CORPSRV

CORPCLI [IP1] ---------- IPSec-SA [SPI=x] ------------------> [IP2] CORPSRV

CORPCLI [IP1] <-------- IPSec-SA [SPI=y] --------------- [IP2] CORPSRV

Dabei gilt:

• IP1 ist die IP-Adresse von CORPCLI.
• IP2 ist die IP-Adresse von CORPSRV.
• x ist der SPI, der die eingehende IPSec-SA für CORPSRV von CORPCLI identifiziert.
• y ist der SPI, der die ausgehende IPSec-SA für CORPSRV zu CORPCLI identifiziert.

Diese Zusammenfassung verdeutlicht, dass die IKE-Hauptmodus-SA zwischen CORPCLI und CORPSRV bidirektional ist. Jeder Computer kann durch den Schutz der IKE-Hauptmodus-SA eine Aushandlung des Schnellmodus initiieren. IPSec-SAs hängen nicht vom Status der Protokolle auf höherer Ebene ab. Beispielsweise können TCP-Verbindungen bei fortbestehender IPSec-SAs hergestellt und abgebrochen werden, und IPSec-SAs können ablaufen, bevor eine TCP-Verbindung beendet wird. Die IKE versucht, mithilfe der Schnellmodusaushandlung erneut zu verhandeln, um zwei neue IPSec-SA-Paare vor Ablauf der Lebensdauer des bestehenden IPSec-SA-Paares einzurichten. Damit soll verhindert werden, dass eine Verbindung abgebrochen wird. Dieser Prozess wird zwar allgemein als Schlüsselrotation der IPSec-SA bezeichnet, es werden dabei jedoch zwei neue IPSec-SAs eingerichtet. Die Lebensdauer der IKE-Hauptmodus-SA wird nur nach Zeit und Anzahl der versuchten IPSec-SAs gemessen (nicht nach Bytes der Daten, die ins IKE-Protokoll übertragen werden). Die IKE-Hauptmodus-SA läuft unabhängig vom IPSec-SA-Paar ab. Wird ein neues IPSec-SA-Paar benötigt, wird automatisch eine erneute IKE-Hauptmodus-SA ausgehandelt (bei Ablauf einer Hauptmodus-SA). Durch das Internet Engineering Task Force (IETF)-Design muss IKE den Schlüsselaustausch der Hauptmodus-SA ausführen und den IKE-Schnellmodus in jeder Richtung aushandeln. Aus diesem Grund sollte die Authentifizierungsmethode, die in der IPSec-Richtlinie auf beiden Computern für die IKE-Hauptmodus-SA konfiguriert ist, die Authentifizierung in der Richtung ermöglichen, aus der die IKE-Hauptmodusaushandlung initialisiert wird. Ebenso sollten die IPSec-Richtlinieneinstellungen in der Filteraktion für Schnellmodus eine erfolgreiche bidirektionale Schnellmodusaushandlung ermöglichen.

Zum Seitenanfang

Sicherheitsmethoden

Sicherheitsmethoden werden während der IKE-Hauptmodusaushandlung zur Definition von Verschlüsselungs- und Hashingalgorithmen verwendet und die Diffie-Hellman-Gruppe zur Erstellung der Hauptmodus-SA und Sicherung des IKE-Aushandlungskanals. Sicherheitsmethoden werden auch während der Schnellmodusaushandlung verwendet, um den Kapselungsmodus (Transport oder Tunnel), das IPSec-Protokollformat (AH oder ESP), Verschlüsselungs- und Hashingalgorithmen und die Schlüssellebensdauer zu definieren, die zur Erstellung der eingehenden und ausgehenden Schnellmodus-SAs verwendet werden.

Zum Seitenanfang

IPSec-Kapselungsmodi und Protokollformate

IPSec schützt Daten in einem IP-Paket durch kryptografischen Schutz der IP-Nutzlast. Der Schutz hängt von dem Modus ab, in dem IPSec und das Protokollformat verwendet werden. IPSec kann im Transport- oder Tunnelmodus verwendet werden.

IPSec-Kapselungsmodi

Der IPSec-Tunnelmodus wird am häufigsten verwendet, um standortübergreifenden Datenverkehr (auch als Gateway-zu-Gateway- or Router-zu-Router-Datenverkehr bezeichnet) zwischen Netzwerken zu schützen, wie z. B. standortübergreifende Netzwerkverbindungen über das Internet. Bei Verwenden des IPSec-Tunnelmodus kapselt die sendende Gateway das gesamte ursprüngliche IP-Paket durch Erstellen eines IP-Pakets ein, das wiederum von einem der IPSec-Protokollformate (AH oder ESP) geschützt wird. Informationen zu IPSec im Tunnelmodus finden Sie im Kapitel “Deploying IPSec” des Dokuments Deploying Network Services im Windows Server 2003 Deployment Kit unter https://go.microsoft.com/fwlink/?LinkId=8195 (in englischer Sprache).

Der IPSec-Transportmodus wird zum Schutz der Host-to-Host-Kommunikation verwendet und ist der Standardmodus für Windows IPSec. Wird der IPSec-Transportmodus verwendet, verschlüsselt IPSec nur die IP-Nutzlast und nicht den IP-Header. Windows IPSec wird im Transportmodus hauptsächlich zum Schutz der End-to-End-Kommunikation verwendet (wie z. B. die Kommunikation zwischen Client und Server).

IPSec-Protokollformate

IPSec unterstützt zwei Protokollformate: AH oder ESP. Der IPSec-Transportmodus kapselt die ursprüngliche IP-Nutzlast mit einem IPSec-Header ein (AH oder ESP).

AH

AH stellt die Authentifizierung des Datenursprungs, Datenintegrität und Anti-Replay-Schutz für das gesamte Paket zur Verfügung (sowohl der IP-Header als auch die Datennutzlast in diesem Paket), ausgenommen der Felder im IP-Header, die während der Übertragung geändert werden können. AH stellt keine Datenvertraulichkeit zur Verfügung, d. h., es werden keine Daten verschlüsselt. Die Daten sind lesbar, jedoch gegen Spoofing und unbefugte Änderung geschützt. Wie aus der folgenden Abbildung hervorgeht, werden Integrität und Authentifizierung gewährleistet, indem der AH-Header zwischen IP-Header und TCP-Daten positioniert wird.

Abbildung A.1 Authentifizierungsheader in einem Paket

Bild in voller Größe anzeigen

Aktivieren Sie zur Verwendung von AH im Dialogfeld Einstellungen für Sicherheitsmethoden anpassen in den Eigenschaften für die entsprechende Regel das Kontrollkästchen Daten- und Adressintegrität ohne Verschlüsselung (AH), und legen Sie den Integritätsalgorithmus fest.

ESP

ESP stellt die Authentifizierung des Datenursprungs, Datenintegrität, Anti-Replay-Schutz und die Option der Vertraulichkeit für die IP-Nutzlast zur Verfügung. Im Transportmodus schützt ESP nicht das gesamte Paket mit einer kryptografischen Prüfsumme. Der IP-Header wird nicht geschützt. Wie aus der folgenden Abbildung hervorgeht, wird der ESP-Header vor die TCP-Daten und ein ESP-Trailer und ESP-Authentifizierungstrailer hinter die TCP-Daten gestellt.

Abbildung A.2 ESP-Daten in einem Paket

Bild in voller Größe anzeigen

Aktivieren Sie zur Verwendung von ESP im Dialogfeld Einstellungen für Sicherheitsmethoden anpassen in den Eigenschaften für die entsprechende Regel das Kontrollkästchen Datenintegrität und -verschlüsselung (ESP), und legen Sie die Integritäts- und Verschlüsselungsalgorithmen fest.

Zum Seitenanfang

IKE-Authentifizierung

IKE verwendet die gegenseitige Authentifizierung zwischen Computern, um eine vertrauenswürdige Verbindung herzustellen und erfordert eine der folgenden Authentifizierungsmethoden: Protokoll Kerberos Version 5, PKI-Zertifikat (Public Key Infrastructure, Infrastruktur öffentlicher Schlüssel) der Computer X.509 -Version 3 oder einen vorinstallierten Schlüssel. Die beiden Kommunikationsendpunkte müssen über mindestens eine gemeinsame Authentifizierungsmethode verfügen oder die Kommunikation schlägt fehl.

IKE-Authentifizierungsprozess

Während der IKE-Aushandlung schlägt der IKE-Initiator dem IKE-Responder eine Liste mit Authentifizierungsmethoden vor. Der Responder verwendet die Quell-IP-Adresse des Initiators, um zu ermitteln, welcher Filter die IKE-Aushandlung steuert. Die Liste der Authentifizierungsmethode, die dem Filter in der IPSec-Richtlinie des Responder entspricht, wird zur Auswahl einer Authentifizierungsmethode aus der Initiatorliste verwendet. Der Responder informiert daraufhin den Initiator über die vereinbarte Authentifizierungsmethode. Schlägt die ausgewählte Authentifizierungsmethode fehl, stellt IKE keine Methode für eine andere Authentifizierungsmethode zur Verfügung. Wenn die Authentifizierung erfolgreich und die Hauptmodusaushandlung abgeschlossen ist, läuft die Hauptmodus-SA innerhalb von acht Stunden ab. Wenn nach acht Stunden immer noch Daten übertragen werden, wird die Hauptmodus-SA automatisch neu ausgehandelt.

IKE-Authentifizierungsmethoden

Sie sollten die Authentifizierungsmethode wählen, die für Ihre IPSec-Richtlinie geeignet ist. Eine IPSec-Richtlinienregel verbindet jede IP-Adresse in einem Filter mit einer Authentifizierungsliste, damit IKE festlegen kann, welche Liste der Authentifizierungsmethoden mit der IP-Adresse verwendet werden soll.

Authentifizierungsprotokoll Kerberos Version 5

Das Protokoll Kerberos Version 5 ist die Standardauthentifizierung in Windows 2000 und Windows Server 2003 Active Directory-Domänen. Alle Computer in der Domäne oder in einer vertrauenswürdigen Domäne können diese Authentifizierungsmethode verwenden.

Bei der Kerberos-Authentifizierung sendet jeder IPSec-Peer während der Hauptmodusaushandlung seine Computeridentität in einem unverschlüsselten Format an einen anderen Peer. Die Computeridentität bleibt solange unverschlüsselt, bis die gesamte Identitätsnutzlast während der Authentifizierungsphase der Hauptmodusaushandlung verschlüsselt ist. Ein Angreifer kann ein IKE-Paket senden, wodurch der reagierende IPSec-Peer seine Computeridentität und Domänenmitgliedschaft offenlegt. Aus diesem Grund wird eine Zertifikatauthentifizierung empfohlen, um mit dem Internet verbundene Computer zu sichern.

Der Kerberos-Protokollverkehr ist unter Windows 2000 über das Service Pack 3 und unter Windows XP standardmäßig von IPSec-Filterungen ausgenommen. Um die Ausnahme für Kerberos-Protokollverkehr zu entfernen, müssen Sie die Registrierung ändern und einen geeigneten IPSec-Filter hinzufügen, um diesen Verkehr zu sichern. Weitere Informationen zu den Standardausnahmen unter Windows 2000 und Windows Server 2003 finden Sie unter den speziellen IPSec-Aspekten &#15 0;Creating, modifying, and assigning IPSec policies auf der Microsoft-Website unter
www.microsoft.com/resources/documentation/WindowsServ/
2003/standard/proddocs/en-us/sag_IPSECbpSpecial.asp (in englischer Sprache).

Authentifizierung für öffentliche Schlüsselzertifikate

Auf dem Windows 2000 Server können Zertifikatsdienste verwendet werden, um Computerzertifikate für IPSec während der Gültigkeitsdauer des Zertifikats automatisch zu verwalten. Zertifikatsdienste sind mit Active Directory und Gruppenrichtlinien integriert und vereinfachen die Bereitstellung von Zertifikaten durch die automatische Registrierung und Aktualisierung von Zertifikaten und durch die Bereitstellung von IPSec-kompatiblen Standardzertifikatvorlagen. Um Zertifikate für die IKE-Authentifizierung zu verwenden, sollte nicht das gewünschte Zertifikat, sondern eine geordnete Liste mit zulässigen Stamm-CAs definiert werden. Beide Computer sollten in ihrer IPSec-Richtlinienkonfiguration über eine gemeinsame Stamm-CA und Clients über ein zugeordnetes Computerzertifikat verfügen.

Während der Zertifikatauswahl führt IKE eine Reihe von Überprüfungen durch, um sicherzustellen, dass bestimmte Anforderungen für das Computerzertifikat getroffen werden. Das Computerzertifikat sollte beispielsweise über einen öffentlichen Schlüssel von mindestens 512 Bits verfügen und einen digitalen Signaturschlüssel verwenden.

Vorinstallierte Schlüssel

Wenn Sie die Kerberos-Authentifizierung nicht verwenden und keinen Zugriff auf eine CA haben, können Sie einen vorinstallierten Schlüssel verwenden. Ein eigenständiger Computer im Netzwerk muss beispielsweise einen vorinstallierten Schlüssel verwenden, da in einigen Szenarien weder die Kerberos-Authentifizierung (über das Domänenkonto des Computers) noch Zertifikate einer CA eine erfolgreiche IKE-Authentifizierung ermöglichen.

Die vorinstallierte Schlüsselauthentifizierung dient der Interoperabilität und Kompatibilität mit RFC-Standards. Verwenden Sie für eine vorinstallierte Schlüsselauthentifizierung einen beliebigen Schlüsselwert von mindestens 25 Zeichen und einen anderen vorinstallierten Schlüssel für jedes IP-Adressenpaar. Diese Methoden führen zu unterschiedlichen Sicherheitsregeln für jedes Ziel und stellen sicher, dass ein gefährdeter vorinstallierter Schlüssel nur die Computer gefährdet, die diesen Schlüssel gemeinsam verwenden.

IPSec-CRL-Überprüfung

Wenn Sie die zertifikatgestützte Authentifizierung verwenden, können Sie auch die CRL-Überprüfung aktivieren (Certificate Revocation List, Zertifikatssperrliste). Standardmäßig werden IPSec-CRLs unter Windows 2000 nicht automatisch während der IKE-Zertifikatauthentifizierung überprüft.

IPSec-CRL-Überprüfung aktivieren

Vorsicht: Eine nicht ordnungsgemäße Bearbeitung der Registrierung kann Ihrem System erhebliche Schäden hinzufügen. Vor der Änderung der Registrierung sollten Sie unbedingt alle wichtigen Daten auf dem Computer sichern.

1. Fügen Sie unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\
   Services\PolicyAgent\ einen neuen Oakley-Schlüssel mit dem DWORD-Eintrag "Sichere CRL-Überprüfung" hinzu.

2. Ordnen Sie diesem Eintrag unter folgenden Voraussetzungen einen beliebigen Wert zwischen 0 und 2 zu:

   • Der Wert 0 deaktiviert die CRL-Überprüfung (Standard bei Windows 2000).
   • Der Wert 1 bewirkt die CRL-Überprüfung und das Fehlschlagen der Zertifikatsüberprüfung nur bei gesperrtem Zertifikat (Standard bei Windows XP und Windows Server 2003). Andere während der CRL-Überprüfung auftretende Fehler (z. B. die nicht verfügbare Sperrungs-URL) bewirken kein Fehlschlagen der Zertifikatsüberprüfung.
   • Der Wert 2 ermöglicht eine strenge CRL-Überprüfung, d. h., die CRL-Überprüfung ist erforderlich, und die Zertifikatsüberprüfung schlägt fehl, wenn während des CRL-Verfahrens ein Fehler auftritt. Stellen Sie diesen Registrierungswert auf verstärkte Sicherheit ein.

3. Führen Sie einen der folgenden Vorgänge durch:

   • Starten Sie den Computer neu.

   Beenden und starten Sie den IPSec-Dienst durch Eingabe der Befehle net stop policyagent und net start policyagent in der Eingabeaufforderung neu.

   Hinweis

   
   Die IPSec-CRL-Überprüfung garantiert bei einer Sperrung des Zertifikats kein sofortiges Fehlschlagen der Zertifikatsüberprüfung. Es kommt zu einer Verzögerung zwischen der Zeit, in der das gesperrte Zertifikat auf eine aktualisierte und veröffentlichte CRL gesetzt wird und der Zeit, in welcher der Computer, der die IPSec-Überprüfung durchführt, diese CRL abruft. Der Computer ruft erst bei Ablauf der aktuellen CRL oder bei der nächsten Veröffentlichung einer CRL eine neue CRL ab. CRLs werden im Cache und unter Einstellungen<EM>Benutzername\Lokale Einstellungen\Temporary Internet Files von CryptoAPI gespeichert. Da CRLs bei CRL-Cache-Problemen zwischen Computerneustarts weiterhin bestehen, kann das Problem durch einen Neustart des Computers nicht behoben werden.
   

Zum Seitenanfang

IKE-Authentifizierungsmethode und Reihenfolge der Sicherheitsmethoden

Eine IPSec-Regel kann konfiguriert werden, um nur eine Authentifizierungs- oder Sicherheitsmethode festzulegen. Alternativ können Sie eine bevorzugte Liste der Authentifizierungs- und Sicherheitsmethoden festlegen. Durch die Reihenfolge der Authentifizierungs- und Sicherheitsmethoden wird die am meisten bzw. die am wenigsten bevorzugte Methode festgelegt. Wie aus der folgenden Abbildung hervorgeht, können Sie beispielsweise sowohl das Protokoll Kerberos Version 5 als auch die Authentifizierung für öffentliche Schlüsselzertifikate als Authentifizierungsmethoden festlegen, dem Kerberos-Protokoll jedoch eine höhere Priorität einräumen.

Abbildung A.3 Reihenfolge der Authentifizierungsmethoden

Wenn ein Client versucht, eine Verbindung mit CORPSRV herzustellen, jedoch lediglich öffentliche Schlüsselzertifikate zur Authentifizierung akzeptiert, verwendet CORPSRV diese Authentifizierungsmethode und fährt mit dem Herstellen der Verbindung fort. IKE muss die Authentifizierungsmethode erfolgreich verwenden, oder die Kommunikation wird blockiert. Wenn die Aushandlung fehlschlägt, versucht IKE nicht, eine andere Authentifizierungsmethode zu verwenden. Dasselbe Prinzip trifft auf Sicherheitsmethoden zu, bei denen beispielsweise ESP gegenüber AH bevorzugt wird.

Zum Seitenanfang

Optionen für die Aushandlung der Sicherheit

Auf der Registerkarte Sicherheitsmethoden kann in den Eigenschaften für eine Filteraktion konfiguriert werden, ob eine IPSec-Richtlinie Zurückgreifen auf unsichere Verbindung, Eingehendes Passthrough und einen Sitzungsschlüssel mit PFS erlaubt. Sie können im Dialogfeld Einstellungen für den Schlüsselaustausch in den allgemeinen Eigenschaften für eine Regel den Hauptschlüssel-PSF konfigurieren.

Auf unsichere Kommunikation zurückgreifen

Wenn Zurückgreifen auf unsichere Verbindung erlaubt ist, wird der Datenverkehr wenn möglich durch IPSec gesichert (wenn der Computer am anderen Ende der Verbindung IPSec mit einer ergänzenden Filteraktion und einem Filter in der Richtlinie unterstützt). Der Datenverkehr kann jedoch ungeschützt gesendet werden, wenn der Peer über keine IPSec-Richtlinie verfügt, mit der er auf die Anforderung für die Sicherheitsaushandlung reagieren könnte. Wenn der Peer nicht innerhalb von drei Sekunden auf die Anforderung für die Sicherheitsaushandlung reagiert, wird eine SA für Klartextverkehr erstellt (eine schwache SA). Schwache SAs ermöglichen eine normale TCP/IP-Kommunikation ohne IPSec-Kapselung. Obwohl dieser Datenverkehr möglicherweise nicht durch IPSec geschützt wird, kann dies durch eine andere Anwendung erfolgen (z. B. kann Datenverkehr durch LDAP-Verschlüsselung (Lightweight Directory Access Protocol) oder RPC-Authentifizierungsmechanismen (Remote Procedure Call) geschützt werden). Wenn der Peer innerhalb von drei Sekunden reagiert und die Sicherheitsaushandlung fehlschlägt, wird die Kommunikation, die dem entsprechenden Filter entspricht, blockiert.

"Zurückgreifen auf unsichere Verbindung" ist eine Einstellung, die die Interoperabilität mit den folgenden Computern ermöglicht:

• Computer mit Betriebssystemen vor Windows 2000
• Computer mit Windows 2000 oder älteren Systemen, die über keine IPSec-Richtlinienkonfiguration verfügen
• Computer mit Nicht-Microsoft-Betriebssystemen, die IPSec nicht unterstützen

Aktivieren oder deaktivieren Sie auf der Registerkarte Sicherheitsmethoden in den Eigenschaften für eine Filteraktion das Kontrollkästchen Unsichere Kommunikation mit Computern zulassen, die IPSec nicht unterstützen, um das Zurückgreifen auf unsichere Verbindung zu ermöglichen.

Diese Option kann für die Client-Richtlinie aktiviert oder deaktiviert werden. Wenn Sie diese Option aktivieren, und der Server nicht auf die Anforderung des Client zur Sicherheitsaushandlung reagiert, können Sie dem Client das Zurückgreifen auf unsichere Verbindung erlauben. Wenn Sie das Kontrollkästchen deaktivieren, und der Server nicht auf die Anforderung des Client zur Sicherheitsaushandlung reagiert, wird die Kommunikation blockiert. In einigen Fällen ist es hilfreich, das Zurückgreifen auf unsichere Verbindung zu erlauben. IKE ermöglicht das Zurückgreifen auf unsichere Verbindung jedoch nur, wenn keine Antwort erfolgt. Aus Sicherheitsgründen erlaubt Windows IPSec keine ungesicherte Kommunikation, wenn die IKE-Aushandlung fehlschlägt oder ein Fehler während der IKE-Aushandlung auftritt (nach der Antwort), wie die fehlgeschlagene Authentifizierung oder Vereinbarung zu Sicherheitsparametern.

Bei Erstbereitstellungen empfiehlt es sich, dieses Kontrollkästchen zu aktivieren, damit dem Client das Zurückgreifen auf unsichere Verbindung ermöglicht und die erstmalige Konnektivität hergestellt wird, wenn IPSec auf dem Server deaktiviert ist.

Eingehendes Passthrough

Ist die Option "Eingehendes Passthrough" aktiviert, wird der normale eingehende TCP/IP-Datenverkehr (Datenverkehr, der nicht durch IPSec gesichert wird, z. B. TCP SYN-Paket) akzeptiert, wenn er dem eingehenden, der Filteraktion zugeordneten Filter entspricht. Das Protokollantwortpaket der oberen Schicht (z. B. TCP SYN ACK-Paket) entspricht dem entsprechenden ausgehenden Filter und löst eine Sicherheitsaushandlung aus. Daraufhin werden zwei IPSec-SAs ausgehandelt, und der Verkehr wird in beide Richtungen IPSec-gesichert. Die Option "Eingehendes Passthrough" erlaubt einem Server, die Standardantwortregel zur Initiierung der Sicherheitsaushandlung bei Clients zu verwenden. Wenn Sie die Standardantwortregel in der Client-IPSec-Richtlinie aktivieren, müssen Clients keinen Filter beibehalten, der die IP-Adresse des Servers beinhaltet. Wenn Sie die Standardantwortregel in der Client-IPSec-Richtlinie nicht aktivieren, muss die Option "Eingehendes Passthrough" in der Server-IPSec-Richtlinie ebenfalls nicht aktiviert werden. Achten Sie außerdem darauf, dass Sie diese Option nie auf Computer aktivieren, die mit dem Internet verbunden sind.

Aktivieren oder deaktivieren Sie auf der Registerkarte Sicherheitsmethoden in den Eigenschaften für eine Filteraktion das Kontrollkästchen Unsichere Kommunikation mit Computern zulassen, die IPSec nicht unterstützen, um die Option "Eingehendes Passthrough" zu aktivieren oder deaktivieren.

Sitzungsschlüssel- und Hauptschlüssel-PFS

PFS ist ein Mechanismus, der festlegt, ob aus dem bestehenden Schlüsselmaterial für einen Hauptschlüssel ein neuer Sitzungsschlüssel abgeleitet werden kann. PFS stellt sicher, dass die Beschädigung eines einzigen Schlüssels nur den Zugriff auf Daten erlaubt, die von PFS geschützt werden, und nicht notwendigerweise auf die gesamte Kommunikation. Zu diesem Zweck stellt PFS sicher, dass ein Schlüssel, der zum Schutz von Übertragungen verwendet wird, nicht zum Generieren von weiteren Schlüssel eingesetzt werden kann. Sitzungsschlüssel mit Perfect Forward Secrecy (PFS) kann ohne Reauthentifizierung verwendet werden und nimmt weniger Ressourcen in Anspruch als Hauptschlüssel für Perfect Forward Secrecy (PFS). Wenn die Option "Sitzungsschlüssel mit PFS" aktiviert ist, wird ein neuer Diffie-Hellman-Schlüsselaustausch durchgeführt, um neue Schlüsselinformationen zum Hauptschlüssel zu generieren.

Wenn Sie die Option "Sitzungsschlüssel mit PFS" in einer Server-Richtlinie aktivieren, muss diese auch in der Client-Richtlinie aktiviert werden. Sie können die Option "Sitzungsschlüssel mit PFS" aktivieren, indem Sie im Dialogfeld Einstellungen für den Schlüsselaustausch in den allgemeinen Eigenschaften für eine Regel das Kontrollkästchen Sitzungsschlüssel mit Perfect Forward Secrecy (PFS) verwenden aktivieren. Die Option "Hauptschlüssel für Perfect Forward Secrecy (PFS)" erfordert eine Reauthentifizierung und nimmt einige Ressourcen in Anspruch. Außerdem benötigt sie für jede Schnellmodusaushandlung eine neue Hauptmodusaushandlung. Sie können die Option "Hauptschlüssel für Perfect Forward Secrecy (PFS)" konfigurieren, indem Sie das Kontrollkästchen Hauptschlüssel für Perfect Forward Secrecy (PFS) aktivieren. Wenn Sie die Option "Hauptschlüssel für Perfect Forward Secrecy (PFS)" in einer Server-Richtlinie aktivieren, muss diese in der Client-Richtlinie nicht aktiviert werden. Da beim Aktivieren dieser Option ein beträchtliches Overhead entsteht, empfiehlt es sich, die Option "Sitzungsschlüssel mit Perfect Forward Secrecy (PFS)" oder "Hauptschlüssel für Perfect Forward Secrecy (PFS)" nur in potenziell gefährlichen Umgebungen zu aktivieren, wenn IPSec-Datenverkehr erfahrenen Angreifern ausgesetzt ist, die den sicheren kryptografischen Schutz durch IPSec gefährden.

Zum Seitenanfang

| Home | Technische Artikel | Community