15 Mrz ESAE Serie Teil 5 – Windows IPSec
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:
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:
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
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 😊.
Bildquelle: freepik.com
LATEST POSTS
-
ChatGPT 1/3: Revolution in der KI-Technologie? – Wir stellen Cybersecurity-Fragen an eine Chat-KI
Die Künstliche Intelligenz (KI) ist ein faszinierendes und immer wieder viel diskutiertes Thema in der heutigen Technologie- und Informationsgesellschaft. Egal ob in der Wissenschaft, der Industrie oder im Alltag, die Möglichkeiten...
16 Januar, 2023 -
ChatGPT 2/3: Die Krux mit der KI
Nein, im zweiten Teil werden wir nicht noch ein Interview mit ChatGPT führen und über dessen Fähigkeiten staunen. Diesmal betrachten wir die Entwicklung und Möglichkeiten von KI im Allgemeinen und wagen einen Ausblick in die Zukunft, die in der IT-Welt...
16 März, 2023 -
ChatGPT 3/3: KI for IT Security
Die Geschwindigkeit der Weiterentwicklung und Ausbreitung von KI-Technologie ist inzwischen enorm gestiegen. Allein in den wenigen Wochen seit dem letzten Blog zu diesem Thema...
15 Juni, 2023