Der Server ist mit hilfe eines Heartbeat-Tunnels über sixxs.net an das Internet angebunden. Mir wurde das Netzwerk 2a01:198:200:7a6::/64 für die Punkt-zu-Punkt Verbindung zum Tunnelbroker zugewiesen. Der Aufbau des Tunnels erfolgt über das “Automatic IPv6 Connectivity Client Utility”, kurz AICCU.

Viele reden über IPSec ohne genau zu Wissen wie es eigentlich funktioniert. Im Grunde genommen ist es eine symetrische Verschlüsselung, die asymetrische Schlüssel zum austausch des eigentlichen, symetrischen Schlüssels für die Daten verwendet. Dieser Austauschvorgang wird IKE genannt und arbeitet mit dem ISAKMP Protokoll. Anschließend wird mit diesem Schlüssel die eigentliche Datenverschlüsselung oder Signierung durchgeführt. Das ganze funktioniert so:

• Einmalige Ausstellung eines Zertifikates durch die PKI

1. Erstellen eines geheimen Schlüssels in einer sicheren Umgebung. Bei einer sauber implementierten PKI sollte der geheime Schlüssen den Speicher des Gerätes, auf dem er erstellt wurde, nie verlassen. Beispiele hierfür sind zb. eine SmartCard oder ein TPM.
2. Anschließend wird aus dem geheimen Schlüssel ein öffentlicher Schlüssel errechnet. Aus diesem kann der geheime Schlüssel nicht mehr zurückgerechnet werden (Stand der Technik 2008, Schlüssellänge mind. 2048Bit)
3. Damit dem Inhaber des geheimen Schlüssels vertraut werden kann, wird der öffentliche Schlüssel zusammen mit Daten zum Inhaber an eine Zertifizierungsstelle gesendet. Diese signiert den Schlüssel mit ihrem geheimen Schlüssel. Eine Prüfung der Signatur ist mit dem öffentlichen Schlüssel der Zertifizierungsstelle jederzeit möglich. Dieser ist übrigens im CA-Zertifikat enthalten.
4. Ein von der CA signierter Schlüssel wird meistens in Form eines Zertifikats ausgestellt und an den Antragsteller zurückgesandt. Dieser verfügt nun über seinen privaten Schlüssen und eine Signatur (Zertifikat), die bestätigt das die person die ist, für die sie sich ausgibt.

• Der eigentliche Schlüsseltausch (Verbindungsinitialisierung)

1. Während des Schlüsseltausches verschlüsselt der Client alle Informationen mit dem öffentlichen Schlüssel des IPSec-Servers. Zusätzlich Authentifiziert er sich mit seinem öffentlichem Schlüssel und signiert die Daten mit seinem privatem Schlüssel. Da den privaten Schlüssel nur der Antragsteller des Zertifikates besitzt, ist die Idendität somit bestätigt.
2. Der IPSec-Server entschlüsselt die Daten mit seinem privatem Schlüssel. Zusätzlich prüft er bei der CA, ob das Zertifikat, mit welchem die Daten signiert wurden, gültig ist. Dies geschiet durch abfrage der Zertifikatssperrliste. Ist die Signatur der CA gültig und das Zertifikat weder abgelaufen noch gesperrt, ist der Client erfolgreich authentifiziert.
3. Über diese initiale Verbindung generieren beide Partnr bestimmte zufallszahlen und errechnen nach einem bestimmtem Schema einen gemeinsamen Schlüssel (SA). Für dieses Verfahren wird meistens nach dem Diffie-Hellman (DH) prinzip durchgeführt. Zusätzlich einigen sich beide Partner, welcher Algorithmus und welche Prüfsummenmethode (MD5, SHA1), für die Datenpakete der eigentlichen Übertragung verwendet werden sollen.

• IPSec Modus Authentication Header Modus (AH)

In diesem Modus werden die Datenpakete nur signiert und nicht verschlüsselt. Dies schützt die Daten gegen veränderung während der Übertragung oder Relay Angriffe (Sniffen und erneutes Aussenden der Pakete). Zur Signierung wird der vorher ausgehandelte Schlüssel der private Schlüssel des Clients direkt verwendet. Die so signierten Daten werden über das IP-Prokokoll Nummer 51 versendet.

• IPSec Encapsulating Security Payload Modus (ESP)

In desem Modus werden die Daten verschlüsselt. Dazu gibt es 2 Verfahren:

1. Im Tunnel-Modus werden die Daten inklusive IP-Header verschlüsselt und mit einem neuem IP-Header versehen. Dieser Modus eignet sich für Site-to-Site (Verbindung zweier Standorte) Verbindungen.
2. Im Transport-Modus werden die Daten des verwendeten Transportprotolls (TCP, UDP) verschlüsselt.

Die eigentliche Verschlüsselung erfolgt mit dem vorher über IKE ausgehandeltem Privatem Schlüssel und Protokoll. Die daten werden bei ESP über das IP-Protokoll nummer 50 übertragen.

Ich hoffe mit diesem Beitrag IPSec einfach erklärt zu haben. Auf tiefere Details, wie die verschiedenen Authentifizierungsmethoden, DH-Gruppen oder Algorithmen werde ich hier nicht eingehen. Fragen, Anregungen und Kritik bin ich jederzeit offen. Dafür gibt es ja die Komentarfunktion .

Weitere Informationen:

http://www.google.de/search?q=ipsec+funktionsweise

http://de.wikipedia.org/wiki/IPsec

Problembeschreibung:
Das Problem wurde wie folgt nachgestellt:
Windows Server 2003R2 wurde auf einem DL360G4P neu installiert, anschließend das aktuelle ProLiant SupportPack im ExpressModus installiert. Nach dem anschließendem Neustart wurde Teaming für die beiden OnBoard NICs im 802.3ad Modus aktiviert, eine statische IP konfiguration erstellt und das System mit dem Netzwerk verbunden. Anschließend wurde die Netzwerkkonfiguration sowie die LACP aushandlung erfolgreich geprüft und Windows aktiviert. Nun wurden die aktuellen Hotfixes über WindowsUpdate eingespielt. Nach dem Neustart tritt das Problem auf. In den Reiter “Status” des “HP Network team” Interfaces ist keine IP-Konfiguration vorhanden (IP: 0.0.0.0) und das System versucht über DHCP eine Konfiguration zu erhalten. Wenn man allerdings Eingenschaften von TCP/IP aufruft um eine statische Konfiguration zu hinterlegen, ist diese noch vorhanden. Der Befehl ipconfig /all zeigt das selbe Ergebnis. Löst man das NetzworkTeam auf und konfiguriert eines der Interfaces statisch, wird die Konfiguration übernommen.

Ursache:
Nach der Installation des Hotfixes KB941644 werden komponenten der TCP/IP Protokolltreiber ausgetausch. Diese neuere Version funktioniert warscheinlich nicht richtig mit dem HP NicTeaming Treiber und verursacht das Problem.

Auswirkungen:
Der Server ist nicht mehr über seine statische IP erreichbar. Es scheint als ob das Interface auf DHCP konfiguriert wurde und keine IP erhält. Selbst wenn ein DHCP-Server im Netzsegment vorhanden ist, bekommt das Interface keine IP. Auch die LACP Aushandlung am Switch schlägt nach einspielen des Patches fehl.

Umgebung:
Windows Server 2003R2 ServicePack 2 inkl. aller Hotfixes bis 01.01.2008 sowie aller zusätzlichen Updates (IE7, XML Services usw.). Die aktuelle Version des ProLiant SupportPacks ist installiert. Eine neuere Version des Netzwerktreibers ist nicht verfügbar.

Lösung:
Nach der Deinstallation des HotFixes KB941644 ist das Problem vorerst behoben wurden. Allerdings ist die Sicherheitsanfälligkeit die mit diesem Hotfix behoben wurde wieder vorhanden. Der Workarround des Bulletins funktioniert und schließt die Lücke ohne die Konfiguration des Interfaces zu beschädigen.

Bulletin: Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution (941644)