IPSec

Wofür braucht ein Exchange oder Lync Admin eigentlich IPSec ?. Wer sein System gut konfiguriert hat, bei dem sind alle Zugriffe per SSL verschlüsselt, sei es nun OWA/HTTPS, MAPI/HTTPS (Outlook Anywhere), SIP/TLS (Lync) oder SRTP (Audio/Video). Auch Sharepoint-Zugriffe kann man per SSL absichern und SMB schützt sich zumindest schon per Signaturen gegen eingefügte Pakete. Dennoch gibt es Bereiche, bei denen IPSec zum Tragen kommen kann, von denen ich einige hier benennen will.

Hinweis: IPSec ist eine "Sicherheitskomponente", mit der Endpunkte sich gegenseitig identifizieren und dann Daten verschlüsselt übertragen können. IPSec ist nicht primär dazu gedacht, über einen erlaubten IPSec Tunnel durch Firewalls und Netzwerkzonen hinweg Datenverkehr zu Verstecken, der ansonsten nicht erlaubt wäre. Eine Firewall kann dies aber nicht überprüfen und es obliegt der Konfiguration der Endpunkte, die IPSec-Verbindung nicht zu missbrauchen. Prüfen sie daher genau, welche Endpunkte durch eine Firewall für IPSec zugelassen werden.

Einsatzbereich von IPSec

IPSec ist eine Sicherheitstechnologie, weil damit die beiden Endpunkte einer Verbindung sich gegenseitig authentifizieren können und die Daten verschlüsselt übertragen werden. Bei IPv4 ist IPSec leider nicht nativ Teil des Protokolls, so dass die eigentlichen Daten in einem anderen Paket übertragen werden. Sie erkennen dass daran, dass IP Typ50, Typ51 und UDP 500 genutzt werden. Und das ist auch gut so, da damit ein Mitlauscher gar nicht mehr erkennen kann, welche Dienste "da drin" durch geleitet werden. Zudem gibt es noch einen "Tunnel-Mode", bei dem z.B.: zwei Gateways als Router zwei Netzwerke über einen Tunnel verbinden. Sie könnten also das VPN über das Internet einfach per IPSec sichern und faktisch macht das ja auch ein VPN über IPSec.

Die Konfiguration kann statisch lokal auf jedem Endgerät, oder z.B. per Gruppenrichtlinie erfolgen. In einem Domain Netzwerk ist natürlich die Gruppenrichtlinie das bevorzugte Mittel. Die Gegenstellen können sich als Domänenmitglieder per Kerberos identifizieren. Natürlich können auch Computerzertifikate, NTLM-Anmeldedaten und notfalls auch "Preshared Keys" verwendet werden. Gerade die Zertifikate kommen gerne in Verbindung mit NAP zum Einsatz, weil der NAP Server z.B. einem Client erst nach der Bestätigung des "Compliant"-Status ein Zertifikat gibt und der Client erst dann auch die anderen Server erreichen kann.

Dadurch, dass aber nur "bekannte" Clients z.B. überhaupt einen IPSec Tunnel aufbauen können, ist IPSec auch ein Weg um z.B. den Zugriff auf Webseiten wie Outlook Web App, SharePoint oder andere Webseiten auf Clients zu begrenzen, die einen IPSec-Tunnel aufbauen können:

Using IPsec to Secure Access to Exchange
http://go.microsoft.com/fwlink/?LinkId=207227 
https://www.microsoft.com/en-us/download/details.aspx?id=23708

Einschränkungen von IPSec

Technisch werden die Daten über die IPSec-Ports geleitet. Was der Sicherheit dient, kann aber anderweitig auch handfeste Nachteile haben, die man auch wissen sollte, weil die eigentlichen Applikationsports nicht mehr sichtbar sind

  • Volumenmessen mit RMON u.a.
    Wenn die Pakete nicht mehr mit den normalen Application-Ports übertragen werden, können verschiedene Messpunkte natürlich auch keine Aufzeichnungen mehr anfertigen, anhand der Sie die Belastung ihrer WAN/LAN-Strecken auswerten können. Es ist alles nur noch eine "große IPSec Gruppe"
  • Portbasiertes QoS
    Sicher kann ein Client auch QoS-Tags setzen aber die meisten Netzwerkadministratoren vertrauen den Clients nur bedingt und übersteuern solche Taggings anhand von Ports oder IP-Adressen. Zumindest die "Erkennung" von Traffic anhand von Ports ist mit IPSec nicht mehr möglich.
  • Firewall-Blindheit
    Wenn zwei Endpunkte per IPSEC miteinander kommunizieren können, dann "sieht" eine eventuell zwischengeschaltete Firewall nichts mehr von dem originalen Traffic. So schön so ein "Tunnel" als Verbindung von Standorten durch Firewalls hindurch sein kann, so kritisch ist dies bezüglich der Sicherheit zu sehen. Denn faktisch ist zwischen den Endpunkten ein "voll transparentes Netzwerk vorhanden. Da darf man schon mal fragen, warum es denn noch eine Firewall zwischen diese Systemen gibt.
  • RTAudio/Video
    Die Verzögerung durch IPSec ist gering aber dennoch sollten Sie im Auge behalten, dass ohne entsprechende Ausnahme auch Lync Audio/Video-Verbindungen per IPSec noch mal verschlüsselt werden. das "muss" nicht sein und zudem sollten Sie beachten, dass z.B. ein Gateway zur TK-Anlage vielleicht kein IPSec spricht. Denkbar wäre hier ein Ausschluss der Gateway-IP oder ein IPSec-Tunnel zu einem Server neben dem Gateway oder besser direkt der Verzicht auf IPSec für RTP/SRTP
  • NAT Limits
    ESP als Transportmittel unterstützt auch NAT während AH aktuell kein NAT unterstützt. Gehen sie mal davon aus, das IPSec nicht korrekt funktioniert, wenn NAT zwischen zwei Endpunkten eingesetzt wird.

Auch wenn die Einschränkungen sie zögern lassen, so sollten Sie doch immer Vorteile und Einschränkungen gegeneinander abwägen. Wer z.B. Systeme untereinander nur erreichbar machen will, wenn sich die Systeme gegenseitig authentifiziert haben, hat mit IPSec eine sehr gute und einfache Möglichkeit gefunden. Da ist Sicherheit und Zuverlässigkeit ein wichtiger Aspekt, so dass QoS vielleicht nicht so wichtig sind. Wer allerdings IPSec primär mit dem Ziel einsetzen will, einfach eine Firewall zu "durchtunneln", sollte sich nicht wundern, wenn ihm ein Firewall-Admin die Tür zuschlägt. Denn IPSec baut auf die Sicherheit und das Vertrauen in die Endpunkte, da auf dem Weg nichts mehr zu "sehen" ist. In Firmen werden aber speziell VPNs natürlich durch Gateways und nicht durch die Endpunkte aufgebaut.

Konfiguration

IPSec kann auf Windows Clients über verschiedene Wege konfiguriert werden:

  • Gruppenrichtlinien zur Windows Firewall
    Am einfachsten ist es über eine Gruppenrichtlinie die Einstellungen der Windows Firewall vorzugeben. Eine GPO können Sie zudem auf bestimmte Ous und Computer einschränken und so auch relativ gefahrlos ein paar Testgeräte zuerst beglücken. Allerdings erlaubt diese Einstellung keine Steuerung auf die Ebene des Protokolls und einzelne Ports, sondern nur auf IP-Adressen. Wenn also eh alles per IPSec getunnelt werden soll, dann ist das der richtige Weg
  • Gruppenrichtlinie auf AD Policies
    Eine umfangreichere Einstellung ist über die "IP Security Policies on Active Directory" möglich. Allerdings müssen Sie hier in drei Stufen arbeiten. Sie müssen zuerst IP Filterlisten und IP-Actions pflegen, die sie dann im dritten Schritt in "IP Security Polices" zusammenfassen können.

    Damit ist dann aber auch eine Steuerung auf IP-Port und IP-Protokoll-Ebene möglich.
  • Lokaler Computer
    Zuletzt können Sie über das lokale Snapin für die Windows Firewall von Hand eigene IPSec Regeln anlegen. Das erscheint auf den ersten Blick unsinnig, wenn Sie die elegante Konfiguration per Gruppenrichtlinie können. Aber die GPOs sind nur für Domänenmitglieder nutzbar und leider nicht für Einzelsysteme. Oft stehen aber gena solche Einzelsysteme in einer DMZ oder sie wollen so ein System erst in die Domäne aufnehmen.

    Bedenken Sie dabei aber, dass Kerberos als Authentifizierung dann auch nicht möglich ist und sie den Client per Zertifikat oder Preshared-Key konfigurieren müssen. Die entsprechenden Gegenstellen, also zumindest der DC der für den Domain-Join genutzt wird, müssen dies dann auch unterstützen.

Ich habe sehr durchwachsene Ergebnisse, wenn Endpunkte auf beiden Seiten doppelt eingetragen waren. Eigentlich hatte ich versucht nachzustellen, dass drei Server im gleichen Subnetz miteinander IPSec sprechen. Warum auch immer war dies nicht problemfrei möglich. Das ist natürlich kein Problem. ,wenn die beiden Endpunktgruppen nicht untereinander IPSec nutzen sollen.

Gehen wir davon aus, das Sie per Gruppenrichtlinie die Einstellungen für bestimmte Clients vorgenommen haben, dann kann es etwas dauern, denn die Änderungen an den Gruppenrichtlinien müssen erst einmal über die DCs und SYSVOL-Verzeichnisse repliziert werden und dann vom Client angewendet werden. Während ersteres in der Regel zügig von stattet geht, können Sie die Aktualisierung auf dem Client mit einem "GPuPDATE /Force" beschleunigen. Die Änderungen sollten im Eventlog sichtbar sein

Log Name:      Microsoft-Windows-Windows Firewall With Advanced Security/Firewall
Source:        Microsoft-Windows-Windows Firewall With Advanced Security
Event ID:      2008
Level:         Information user:          LOCAL SERVICE
Description:
Windows Firewall Group Policy settings have changed. The new settings have been applied

Status

Die "Funktion" von IPSec ist ebenfalls über die MMC zu "Windows Firewall with Advanced Security" zu kontrollieren. Hier gibt es unter Monitoring die Anzeige der "Security Associations", unter der sowohl der "MainMode" als auch der Quick Mode zu sehen ist.

Ein Doppelklick zeigt an, was es zu dieser Verbindung noch zu wissen gibt. Hier ist gut zu sehen, dass die Gegenseite per Kerberos als Computer unter Nutzung von SHA-1 und AES-CBC 128 authentifiziert wurde.

In diesem Beispiel wurde "Kerberos" zur Authentifizierung verwendet, so dass kein separater "Key exchange" erforderlich war und dieser auf NONE steht. Ein Punkt weiter im Baum zeigt der Quickmode die Verbindungen.

Auch hier gibt ein Doppelklick auf die Zeile weitere Informationen preis

IPSec und Ping und Firewall

Mittlerweile sollte es sie nicht mehr verwundern, wenn ein Windows System nicht per Default auf ICMP (Ping) reagiert. Erst wenn z.B. die Dateiserverrolle installiert wird, oder eben in der Firewall ICMP freigeschaltet wird, wird ein Windows System auf einen Ping reagieren. In Verbindung mit IPSec können Sie aber doch erkennen, ob die Systeme miteinander kontakt aufnehmen konnten. Denn auch wenn die Windows Firewall den ICMP-Ping blockiert, so erlaubt sie eine IPSec Verbindung. Wenn Sie also im Fenster für den "MainMode" eine Verbindung gefunden haben, dann ist der andere Partner online.

Die Firewall kann ja z.B. erst nach erfolgreicher Authentifizierung des Partners das getunnelte Paket bekommen und entscheiden, ob es durch die Firewall dann weiter gereicht wird. Bei Windows Vista/2008 oder höher muss aber auch ein durch IPSec getunneltes Paket trotzdem noch durch die Windows Firewall. Das war bei Windows 2003 noch nichts so.

IPSec mit Netmon

NETMON kann IPSec nicht decodieren !

Auch wenn man mit Netzwerkschnüfflern die Daten selbst kaum lesbar bekommt, so ist Netmon doch eine effektive Methode den IPSec Handshake und die Verwendung von IPSec zu überprüfen. Zuerst müssen Sie folgendes wissen.

  • IKE nutzt 500/UDP als Source und Zielport
    Mit einem Filter in der Art "UDP.Port == 500" können Sie schon beim Mitschnitt oder beim späteren Auswerten die IKE-Aushandlung sichtbar machen.

Wer dann aber nur ein AuthIP sieht, muss in den Optionen den Parser aktivieren.

Dann werden auch die IKE/AuthIP-Pakete decodiert. Hier sieht man gut, dass zuerst der "MainMode" ausgehandelt wird und dann der QuickMode um dann einen TCP-Handshake zu sehen.

Schauen Sie aber genau hin, denn auf den ersten Blick könnte man vermute, dass hier nichts verschlüsselt ist. Da aber Netmon auf einem der Endpunkte gestartet wurde, wird die Verbindung auf Port 135/TCP decodiert angezeigt auch wenn unten im "Payload" der ESP-Verschlüsselung enthalten ist. Mit WireShark in der Default Installation siehst das zwar farbiger aus, aber hier ist bei ESP Schluss:

Interessanterweise konnte der Mitschnitt von WireShark als CAP-Datei von NETMON 3.4 gelesen und sogar interpretiert werden. Die Nutzung von kerberos ist natürlich auch eine Besonderheit von Windows-Umgebungen.

Weitere Links