Das ESAE-Modell im Einsatz – Teil 4: Windows IPSec im Detail erklärt

Im vierten Teil unserer ESAE-Blogserie konzentrieren wir  uns auf einen Bereich, der bislang im Web nicht ausreichend behandelt wird: Windows IPSec.

Ein Gastbeitrag der Teal Technology Consulting

Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie alle Teile nacheinander lesen.

Das bietet dieser Teil der ESAE-Serie:

Was ist IPSec?

Die Internet Protocol Security, kurz IPsec, ist laut Wikipedia „eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie das Internet ermöglichen soll. IPsec arbeitet direkt auf der Vermittlungsschicht (Internet Layer) des DoD Models und ist eine Weiterentwicklung der IP-Protokolle”.

Weiter heißt es: “Das Ziel ist es, eine verschlüsselungsbasierte Sicherheit auf Netzwerk-Ebene bereitzustellen. IPsec bietet durch die verbindungslose Integrität sowie die Zugangskontrolle und Authentifikation der Daten diese Möglichkeit an. Zudem wird durch IPsec die Vertraulichkeit sowie Authentizität der Paket-Reihenfolge durch Verschlüsselung gewährleistet.“

Warum IPSec im aktuellen Kunden-Kontext?

Wie im ersten Teil unserer ESAE-Serie beschrieben, wurde die Global-Authentication-Service-Umgebung bei einem Co-Location-Dienstleister aufgebaut. Zusätzlich hat man die WAN-Anbindung zwischen dem Kundenstandort und dem Co-Locator angemietet. Last but not least werden sämtliche Netzwerkkomponenten innerhalb der Umgebung ebenfalls von einem Dienstleister betrieben. Dies bedeutet, es gibt jede Menge Netzwerkgeräte außerhalb der Kontrolle des Kunden.

Prinzipiell gibt es zwei Möglichkeiten, die Vertraulichkeit der Kommunikation sicherzustellen:

    1. Verschlüsselung auf Applikationsebene
    2. Verschlüsselung auf Netzwerkebene

Beides sind valide Ansätze. In unserem Fall haben wir uns für Option 2 mit Windows IPSec entschieden, um nicht die komplette Kommunikation aller Komponenten im Detail analysieren und Wege zur Verschlüsselung suchen zu müssen. Die Wahrscheinlichkeit, dass wir nicht alle relevanten Protokolle (mit einfachen Mitteln) verschlüsseln können, war uns bei Option 1 zu groß.

Schematische Darstellung des Netzwerks

Hier nochmal die schematische Darstellung des Netzwerkes:

ESAE Kundenprojekt Architektur (Bild: TEAL)

Die ADFS-Kommunikation erfolgt per SSL und ist somit schon verschlüsselt. Zum Zeitpunkt des Aufbaus von GAS gab es noch keinen globalen Services. Diese müssen später betrachtet werden.

Es bleiben also folgende Kommunikationstrecken übrig, die verschlüsselt werden sollen:

    • Domain Controller zu Domain Controller
    • Server zu Domain Controller
    • Server zu Server
    • PAW zu Domain Controller
    • PAW zu Server

Prinzipiell entspricht das dem Domain Isolation Modell.

Wie funktioniert Windows IPSec?

Microsoft hat IPSec als Teil der Windows Firewall with Advanced Security implementiert. Die IPSec-Konfiguration wird somit in Firewall-Regeln definiert. Diese Regeln können entweder manuell pro Server oder per GPO angelegt und verwaltet werden.

Pro Regel sind fünf Bereiche konfigurierbar:

Nr. 1: Endpunkte

Hier wird definiert, für welche IPs diese Regel gelten soll.

Nr. 2: Authentifizierung

Hier wird definiert, ob eine Authentifizierung für ein- und/oder ausgehenden Netzwerkverkehr versucht oder zwingend verlangt wird.

Nr. 3: Authentifizierungsmethode

Wird eine Authentifizierung versucht oder erzwungen, wird hier eingestellt, auf welche Art das geschehen soll. Auf die Advanced-Einstellungen bzw. die IPSec-Default-Einstellungen gehen wir später näher ein.

Nr. 4: Protokolle und Ports

Hier können, wie es der Name schon besagt, die Protokolle und Ports, für die die Regel gilt, eingeschränkt werden.

Nr. 5: Profile

Auf der letzten Seite vor der Namensgebung kann definiert werden, bei welchen Firewall-Profilen die Regel angewendet werden soll.

Keine PKI? Kein Problem, Authentifizierung geht ja auch per Kerberos! Oder?

Auf den ersten Blick erscheint alles ganz einfach. Wieso schreiben wir dann diesen Blog-Beitrag? Hierzu gibt es eine kurze Anekdote.

Zuerst kommen die IPSec Defaults ins Spiel. Will man nicht für jede Regel neu definieren, welche Authentifizierung verwendet werden soll, kann man das unter anderem in den IPSec Defaults konfigurieren, indem man sich durch dieses schlanke Menü klickt (Rechtsklick auf Windows Defender Firewall with Advanced Security -> Properties):

Auf die Einstellungen zu Main und Quick Mode kommen wir später zurück.

Wo bleibt die Anekdote? Hier ist sie: Da wir aus Zeitgründen im Projekt auf den Aufbau einer PKI verzichtet haben, fielen Zertifikate (erst einmal) weg. Pre-shared Key ist sicherlich keine sichere Option. Alles kein Problem – wir haben ja noch Kerberos. Wir befinden uns ja in einem Windows-Netzwerk und alle unsere Server sind Domain-joined.

Wir hatten also IPSec für die oben genannten Netzwerkstrecken in unserem Lab konfiguriert und alles lief super. VMs runterfahren – Feierabend. Am nächsten Morgen kam die böse Überraschung: nichts geht mehr. Nach vielen Stunden Troubleshooting und fluchen fiel es uns wie Schuppen von den Augen (na gut, ein Microsoft Support Engineer war nicht ganz unbeteiligt):

Um eine Kerberos-authentifizierte IPSec-Verbindung herzustellen, wird ein valides Kerberos Token gebraucht. Dieses gibt es vom Domain Controller. Sobald alle Regeln für die oben genannten Netzwerkstrecken konfiguriert sind, antwortet dieser aber nur, wenn für die Verbindung IPSec verwendet wird … ein Teufelskreis.

Also doch Zertifikate! Hier erspare ich die restliche Story, also unser Leiden.

IPSec Zertifikate müssen eigentlich als „Key usage“ die OID 1.3.6.1.5.5.8.2.2 (IP Security IKE Intermediate) enthalten. Leider hat keiner der Provider unseres Kunden solche Zertifikate ausgestellt. Will man trotzdem Zertifikate verwenden, müssen ALLE Zertifikate von exakt der gleichen CA ausgestellt werden.

Und dann: Alle Zertifikate vorhanden, alle von der gleichen Root, alle Regeln konfiguriert – alles gut?

Natürlich nicht. Die Kommunikation zwischen allen Parteien lief. Und im Monitoring-Tab der Firewall-Konsole konnten wir sehen, dass der Main Mode und der Quick Mode zwar ausgehandelt waren, aber dass der Traffic nicht verschlüsselt war.

Wir haben nicht schlecht gestaunt. Nach einigem Suchen sind wir auf die entscheidende Einstellung im Menü für die Advanced Quick Mode Konfiguration gestoßen. Es muss der Haken „Require encryption for all connection security rules that use these settings“ gesetzt werden! Nur wenn dieser Haken gesetzt ist, wird auch verschlüsselt.

Ein letzter Hinweis vom Support-Techniker war noch, dass die Namensauflösung besser von IPSec ausgenommen werden sollte.

Zusammenfassung

Welche Regeln und Einstellungen wurden implementiert?

Generelle Einstellungen

    • Key Exchange (Main Mode):
    • Integrity algorithms: SHA-384
    • Encryption algorithms: AES-CBC 256
    • Key exchange protocols: Elliptic Curve Diffie-Hellman P-384

Data Protection (Quick Mode)

    • Require encryption for all connection security rules that use these settings: checked
    • Encryption algorithms: AES-GCM 256-bit
    • Integrity algorithms: AES-GCM 256-bit

Firewall-Regeln

    • All Server /PAW Require IPSec:
      • Endpoint 1: <PAW VPN subnet> and <Server subnet>
      • Endpoint 2: <PAW VPN subnet> and <Server subnet>
    • Authentication Mode: Require inbound and outbound authentication
    • Authentication methods: Custom (Certificate)
    • Endpoint 1 port: Any
    • Endpoint 2 port: Any
    • Protocol: Any

Server/PAW to DC DNS exception

    • Endpoint 1: <PAW VPN subnet> and <Server subnet>
    • Endpoint 2: <all domain controller IPs>
    • Authentication Mode: Do not authenticate
    • Authentication methods: No authentication
    • Endpoint 1 port: 53
    • Endpoint 2 port: Any
    • Protocol: UDP

Emergency PAW Exception

    • Endpoint 1: <all domain controller IPs + Well defined PAW IP>
    • Endpoint 2: <all domain controller IPs + Well defined PAW IP>
    • Authentication Mode: Do not authenticate
    • Authentication methods: No authentication
    • Endpoint 1 port: Any
    • Endpoint 2 port: Any
    • Protocol: Any

Viele mögen sich jetzt fragen, warum es die letzte Regel gibt. Nun, solange alles gut läuft, ist die Regel unnötig. Geht allerdings etwas schief, ist sie im konkreten Kontext unabdingbar. Wir rufen uns ins Gedächtnis, dass die Umgebung bei einem Co-Locater aufgebaut wurde. Dieser befindet sich mehrere hunderte Kilometer vom nächsten Kunden-Etandort entfernt. Man kann sich leicht vorstellen, dass es im Fehlerfall zu längeren Ausfällen kommen würde, müsste erst einer der wenigen vertrauenswürdigen Tier-0-Admins diese Strecke fahren, um mit lokalem Zugriff an dem Problem zu arbeiten. Also haben wir einen zweistufigen Fallback eingebaut.

Im Fehlerfall kann der Netzwerkprovider mittels VPN-Konfiguration einer PAW eine bestimmte IP zuweisen, die sich außerhalb des normalen PAW-VPN-Subnetzes befindet. Diese IP ist mittels der dritten Regel von oben vom IPSec-Zwang ausgenommen. So wird ermöglicht, dass im Fehlerfall remote administriert werden kann, aber keine einzelne Person böswillig oder zufällig unverschlüsselt mit der GAS-Umgebung kommuniziert.

Inbetriebnahme von IPSec und Installation neuer Systeme

Die oben genannten Regeln stellen die finale Konfiguration dar. Um diese zu erreichen, ist allerdings ein stufenweises Vorgehen notwendig. Implementiert man nämlich die Regeln so, wie sie dort stehen, „zieht“ die GPO (normalerweise) bei den Domain Controllern zuerst, da das Group Policy Refresh Interval für Domain Controller standardmäßig fünf Minuten (ohne Offset) ist.

Für alle anderen AD-Mitglieder steht das Intervall allerdings standardmäßig auf 90 Minuten, mit einem zufälligen Versatz von 0 bis 30 Minuten.

Wie sind wir vorgegangen?

Da die Umgebung komplett neu aufgebaut wurde und die Anzahl der Server überschaubar war, haben wir zunächst jede IP einzeln in die GPO aufgenommen. Und wir haben das GPO-Update lokal gestartet und – wenn der Client die neue Konfiguration hatte -, das Update auf den Domain-Controllern durchgeführt. Sobald wir das für alle Systeme durchgeführt hatten und alle mittels IPSec kommunizierten, haben wir die Regeln für das komplette Subnetz erstellt, das Refresh Intervall abgewartet und die Regeln mit den einzelnen IPs gelöscht.

Was ist mit Clients, die neu installiert werden und neu der Domäne hinzugefügt werden müssen? Das geht recht einfach: Man muss lokal eine IPSec-Regel für die Kommunikation mit dem Domain Controller mit dem passenden Zertifikat erstellen, dann kann der Client den Domain Join durchführen und bekommt dann per GPO die oben genannten Regeln.

Troubleshooting

Die obigen Ausführungen zeigen, dass Windows IPSec keine triviale Sache ist. Schon gar nicht, wenn man keinen lokalen Zugriff auf die Systeme hat. Nachfolgend einige Tipps, die beim Trouble-Shooting helfen können.

IPSec lokal deaktivieren

Um IPSec für einen Server lokal zu deaktivieren, muss man mittels folgendem Registry Key den Firewall Service deaktivieren:

REG add “HKLM\SYSTEM\CurrentControlSet\services\MpsSvc” /v Start /t REG_DWORD /d 4 /f

Anschließend wird ein Neustart durchgeführt.

Da der Firewall-Service gestoppt ist, lassen sich allerdings auch keine Änderungen an den Firewall- und somit IPSec-Einstellungen machen. Sollen diese angepasst werden, muss sowohl das Zielsystem als auch ein Domain Controller für unverschlüsselte Kommunikation konfiguriert werden, damit der Zielserver per Group Policy die neuen Einstellungen erhalten kann.

Logging einschalten

Will man besser verstehen, was gerade im Kontext IPSec passiert, muss man die entsprechenden Event-Viewer-Logs aktivieren:

auditpol /set /subcategory:”IPsec Driver” /success:enable /failure:enable

auditpol /set /subcategory:”IPsec Main Mode” /success:enable /failure:enable

auditpol /set /subcategory:”IPsec Quick Mode” /success:enable /failure:enable

auditpol /set /subcategory:”IPsec Extended Mode” /success:enable /failure:enable

auditpol /set /subcategory:”Filtering Platform Packet Drop” /success:enable /failure:enable

auditpol /set /subcategory:”Filtering Platform Connection” /success:enable /failure:enable

Es gibt noch mehr Kategorien. Aber das waren die, die wir verwendet haben.

Sobald das Problem gelöst ist, kann man die Logs entsprechend wieder deaktivieren:

auditpol /set /subcategory:”IPsec Driver” /success:disable /failure:disable

auditpol /set /subcategory:”IPsec Main Mode” /success:disable /failure:disable

auditpol /set /subcategory:”IPsec Quick Mode” /success:disable /failure:disable

auditpol /set /subcategory:”IPsec Extended Mode” /success:disable /failure:disable

auditpol /set /subcategory:”Filtering Platform Packet Drop” /success:disable /failure:disable

auditpol /set /subcategory:”Filtering Platform Connection” /success: disable /failure:disable

Firewall Regeln in PowerShell

Hilfreich war oftmals, die Firewall-Regeln auf der Kommandozeile ausgeben zu lassen:

show-netipsecrule –policystore activestore

get-netipsecrule –policystore activestore

Netzwerk Trace auf einem Core Server

Benötigt man einen Netzwerk-Trace auf einem Server-Core-System, kann man diesen mittels

netsh trace start capture=yes tracefile=.\mytrace.etl maxsize=300

starten und mit

Net trace stop

stoppen. Das Trace-File kann man dann mittels Netmon öffnen.


Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie auch die folgenden Teile lesen:


Über den Autor

Die TEAL Technology Consulting GmbH ist spezialisiert auf Infrastruktur-Security-Projekte im On-Premises- und Cloud-Umfeld. Zudem gehört TEAL zu den führenden Anbietern für die Adaption des Microsoft ESAE-Modells zur sicheren Infrastruktur-Administration. Als Partnerfirma ergänzt TEAL sinnvoll das Portfolio der FB Pro GmbH.

Bilder: Pixabay, TEAL, Microsoft

Schreibe einen Kommentar