9 minutes reading time (1821 words)

ESAE Serie Teil 5 - Windows IPSec

cyber-security-600_360

Herzlich willkommen zum fünften Teil unserer ESAE Serie. In diesem Teil möchten wir uns gerne auf einen im Internet nicht so umfassend behandelten Bereich konzentrieren – Windows IPSec.

Was ist IPSec?

„IPsec (Kurzform für Internet Protocol Security) ist 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. Das Ziel ist es, eine verschlüsselungsbasierte Sicherheit auf Netzwerkebene 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 Paketreihenfolge durch Verschlüsselung gewährleistet."

(Quelle Wikipedia)


Warum IPSec im aktuellen Kundenkontext?

Wie in Teil 2 der ESAE Serie beschrieben, wurde die Global Authentication Service Umgebung bei einem Co-Location Dienstleister aufgebaut. Zusätzlich wurde die WAN Anbindung zwischen dem Kundenstandort und dem Co-Locator ebenfalls 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

Zur besseren Übersicht hier nochmal die schematische Darstellung des Netzwerkes:

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 also später betrachtet werden.

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

   1. Domain Controller zu Domain Controller
   2.Server zu Domain Controller
   3.Server zu Server
   4.PAW zu Domain Controller
   5.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 können 5 Bereiche konfiguriert werden:

1.Endpunkte

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

2. Authentifizierung

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

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.

4. Protokolle und Ports

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

5. Profile

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

Auf den ersten Blick erscheint dies ganz einfach, wieso dann also einen eigenen Blogpost zu dem Thema? Dazu eine kleine Anekdote im nächsten Abschnitt.


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

An dieser Stelle 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.

Ok, wo bleibt die Anekdote? Also gut: Da wir aus Zeitgründen im Projekt auf den Aufbau einer PKI verzichtet haben, fielenZertifikate (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 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 euch die Story (=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.

Alle Zertifikate da, 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 hundert Kilometer vom nächsten Kundenstandort weg. 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 mehrere hundert Kilometer 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.

Bevor wir mit dem Thema Troubleshooting schließen, noch ein Absatz zum Thema:


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 5 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 – 30 Minuten.

Wie sind wir also 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, 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.

Soweit - so gut! Aber 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 Troubleshooting helfen können.

1. 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. Müssen 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.


2. 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


3. Firewall Regeln in Powershell

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

show-netipsecrule –policystore activestore

get-netipsecrule –policystore activestore


4. 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 Tracefile kann man dann mittels Netmon öffnen.

Damit endet der Artikel über IPSec. Ich hoffe, er kann einigen von euch helfen, die sich an das Thema herantrauen. Gerne könnt ihr bei Fragen auch Kontakt zu uns aufnehmen. Wir helfen gerne 😊.

ESAE Series Part 5 - Windows IPSec
Openshift - Automated Installation in Azure

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Guest
Monday, 09 December 2019