IPSEC-Interoperabilität

Willkommen im Zoo

IPSEC ist ein Standard, bei dem der blauäugige Administrator glauben könnte, dass jede standardkonforme Implementierung mit jeder anderen einfach so funktioniert. Dieser Artikel bringt IPSEC-Implementierungen zusammen und testet, wo dabei die Fallstricke der Interoperabilität liegen.
Beinahe enzyklopädisch behandelt unser Schwerpunkt-Artikel über IPSEC verschlüsselte Verbindungen zwischen Linux, Windows, BSD, Solaris, Cisco- sowie ... (mehr)

Die ersten RFCs zu IPSEC sind bei der Entwicklung von IPv6 entstanden und stammen aus dem Jahr 1995. Den aktuellen Stand beschreiben die RFCs beginnend mit 4301. Das IPSEC-Protokoll umfasst jedoch nur die Verschlüsselung und Authentisierung der IP-Pakete selbst. Um die Schlüssel nicht für jede Session neu manuell setzen zu müssen, gibt es zusätzlich das Internet Key Exchange Protocol (IKE), dessen erster RFC aus dem Jahr 1998 stammt und dessen aktuelle Version IKEv2 der RFC 5996 und die folgenden beschreiben.

IKE wurde im Lauf der Zeit um einige Funktionen erweitert, die etwa verschiedene Authentisierungsmethoden wie Challenge Response ermöglichen. Implementierungen des Protokolls finden sich in diversen Firewall-Produkten, Netzwerkkomponenten und Betriebssystemen. Am Interoperabilitäts-Test dieses Artikels beteiligten sich die folgenden Kandidaten:

  • Kame/Racoon auf Mac OS X und Linux
  • Solaris 10
  • Windows Server 2008
  • Checkpoint R70
  • Juniper SRX
  • Fortinet Fortigate
  • Cisco-Router mit IOS 12

Am Ende des Tests standen erfolgreiche VPN-Verbindungen zwischen allen Beteiligten. Der Artikel beschreibt im Folgenden, wie Sie die einzelnen Komponenten konfigurieren und was Sie bei den jeweiligen Paarungen beachten müssen.

Eine IPSEC-Verbindung kann im Tunnel-Modus (mehrere LANs werden mit Gateways verbunden, die den Verkehr zwischen den LANs verschlüsseln) oder im Transport-Modus aufgebaut werden, um genau den Verkehr zwischen zwei einzelnen Hosts zu verschlüsseln. Im Test wurde der Tunnel-Modus verwendet, wobei die genannten Gateways jeweils ein LAN mit allen anderen verschlüsselt verbinden sollten.

Die Pakete selbst können verschlüsselt und/oder authentisiert sein. Dazu werden sie zur Verschlüsselung mit ESP (Encapsulating Security Payload) eingepackt und für die Authentisierung mit Authentication Header (AH) versehen. Bei authentisierten und verschlüsselten Paketen bildet IPSEC zunächst den Authentisierungs-Header und stellt ihn vor das Paket, bevor es dann das ganze Paket verschlüsselt und als ESP einpackt.

Zur Authentisierung dient ein Hash über einen Schlüssel und das Paket. Damit kann die Gegenseite, die den Schlüssel kennt, berechnen, ob das Paket unverändert ist und vom authentisierten Sender stammt. Zur Verschlüsselung dient ein symmetrischer Algorithmus wie AES oder Blowfish. Die Wahl der Schlüssel für Authentisierung und Verschlüsselung sowie der Hash- und Verschlüsselungsalgorithmen kann entweder über eine manuelle Konfiguration erfolgen (Manual IPSEC) oder über das IKE-Protokoll.

Im Fall von IKE verhandeln die beiden Seiten die Algorithmen in zwei Phasen. In Phase 1 authentisieren sich die beiden Seiten gegenseitig mit einem festen Schlüssel oder X.509-Zertifikaten (mittlerweile gibt es dafür auch Erweiterungen mit anderen Wegen). Für diese Phase werden auch ein Hash und ein Verschlüsselungsalgorithmus aus einer konfigurierten Auswahl gewählt. Optional können hier noch die Gültigkeitsdauer dieser Verbindung (Security Association, SA) sowie PFS (Perfect Forwarding Secrecy) gesetzt werden. PFS sorgt dafür, dass sich die Session-Schlüssel, mit denen die Nutzdaten geschickt werden, nicht zurückrechnen lassen, wenn sie von den Schlüsseln der IKE SA abgeleitet werden und einer der IKE-Schlüssel kompromittiert wurde.

Sobald die IKE SA ausgehandelt ist, kommen in Phase 2 die Schlüssel der IPSEC-Verbindung an die Reihe. Auch hier wird die (deutlich kürzere) Lebensdauer der Schlüssel in Zeiteinheiten oder übertragenen Bytes sowie optional PFS ausgehandelt. War das erfolgreich, wird in der Regel in den Kernel eingetragen, dass die IPSEC-Verbindung mit diesen Parametern arbeiten soll, und das Gateway steckt Pakete für die Gegenseite in ein ESP-, AH- oder ESP+AH-Paket, das die andere Seite dann auspackt und weiterleitet.

Je nach Implementierung muss der Administrator jetzt noch das IP-Routing anpassen, damit die Pakete aus dem LAN auch im Tunnel landen. Ob dies erforderlich ist, beziehungsweise wie diese Routing-Einträge aussehen, sorgte in den Tests für einige Verwirrung. Bei den Firewalls ist es schließlich auch noch notwendig, im Regelwerk den Verkehr zu erlauben. Wer das vergisst, wird sich wundern, wieso trotz erfolgreicher Verhandlungen keine Pakete durch das VPN wandern.

Das Testsetup

Jedes IPSEC-Gateway bekam beim Test sein eigenes LAN und alle wurden direkt über ein Netzwerk miteinander verbunden.

Als Authentisierungsmethode kam ein festes Passwort zum Einsatz, die Konfiguration zwischen dem Cisco-Router und Solaris lief anfänglich jedoch mit einem Zertifikat, bis klar war, wie man aus dem Passwort »test123« den Hex-String erzeugt, den Solaris als PSK erwartet.

Der Verschlüsselungsalgorithmus für die erste Phase der Verhandlung wurde auf 3DES, der Hash-Algorithmus zur Authentisierung auf SHA1 gestellt. Die Einstellung für PFS wurde auf Gruppe 2 (1024 Bit) gestellt. Diese Parameter wurden nicht aus Sicherheitsgründen, sondern eher aus Kompatibilitätsgründen gewählt, da ältere Implementierungen zum Beispiel 256-Bit-AES nicht unbedingt für Phase 1 beherrschten und am Anfang des Tests noch nicht klar war, welche Implementierung welche Algorithmen beziehungsweise PFS-Gruppen beherrscht. Phase 2 sollte mit AES256, SHA1 und PFS2 arbeiten, was sich auch bis auf zwei Ausnahmen umsetzen ließ. Der zur Verfügung stehende Cisco-Router ist zwar mit Hardwareunterstützung für 3DES augestattet, beherrscht aber dennoch kein AES, sodass 3DES verwendet werden musste. Windows 2008 unterstützt in der einfachen grafischen Konfiguration gar kein PFS für die 2. Phase, doch hierzu später mehr.

Kame/Racoon

Da Kame/Racoon im Debug-Modus recht ausführlich protokolliert, mit welchen Parametern die Verhandlung angefangen hat, eignet es sich gut zur Fehlersuche und wurde von uns deshalb als Referenzimplementierung gewählt. Alle Teilnehmer wurden zuerst mit Racoon zum Laufen gebracht, in der Hoffnung, dass es bei gleicher Konfiguration (und angepassten IP-Adressen) dann auch mit den anderen Teilnehmern funktioniert. Die Konfiguration erfolgt in drei Dateien:

  • Die Datei »racoon.conf« enthält die Verschlüsselungs- und Hash-Algorithmen für Phase 1 und Phase 2 sowie PFS und Lebenszeiteinstellungen für die Schlüssel. Diese Datei ordnet die Parameter der Phase 1 einer Gegenstelle zu (Gegenstelle kann dabei eine IP-Adresse oder auch ein Distinguished Name aus einem Zertifikat sein). Für die Phase 2 werden Netzblöcke (optional auch Ports) angegeben, die für die darunter stehenden Phase-2-Algorithmen und -Parameter gelten.
  • Da im Beispiel feste Passwörter (Preshared Keys, kurz PSK) zum Einsatz kommen, müssen diese auch hinterlegt sein. Dies geschieht in der Datei »psk.txt« , in der den IP-Adressen der Gegenstellen die Passwörter zugeordnet sind. Passwörter können im Klartext oder als Hexstring angegeben werden.
  • Schließlich muss noch die IPSEC-Policy hinterlegt werden. Diese kann der Administrator auch einfach auf der Kommandozeile mit dem Kommando »setkey« eingeben, aber es ist praktischer, die Policy in einem Setkey-Skript zu hinterlegen. In der Policy bestimmen Regeln, welche Pakete in den IPSEC-Tunnel, der von Racoon ausgehandelt wurde, wandern sollen, beziehungsweise von wo Pakete aus dem Tunnel kommend erwartet werden. Die Regel enthält Quell- und Ziel-IP-Adressbereiche, Protokoll und Portnummern sowie die Richtung (eingehend oder ausgehend) und eine Angabe, ob ESP, AH oder beides zum Einsatz kommen soll. Racoon kann auch angewiesen werden, die Policy automatisch nach der Aushandlung zu generieren.

Listing 1 und 2 zeigen die Konfiguration zwischen dem Racoon-Netz aus Abbildung 1 und dem Netz hinter der Juniper-Firewall.

Listing 2

setkey -Skript

 

Listing 1

racoon.conf

 

Abbildung 1: Ein privates Netz stellt den Testaufbau für alle IPSEC-Beteiligten dar.

Racoon erlaubt es, an jeder Stelle mehrere Algorithmen anzugeben, die durch Kommas getrennt werden. Im Beispiel fehlen Angaben zur Lebenszeit der Schüssel. Vor dem Start von Racoon sollte die Policy eingespielt sein, da sonst die Zuordnung der Schlüssel zu den Verbindungen im Kernel nicht möglich ist. Dies erledigen üblicherweise die Init-Skripte.

Um Fehler bei einem Verbindungsversuch zu finden, startet der Administrator am besten Racoon im Vordergrund mit der Option »-F« . Damit erscheint auf der Kommandozeile eine Ausgabe, die anzeigt, ob die Verbindungen in Phase 1 und 2 verhandelt werden. Geht etwas schief, hilft das Log aber nicht weiter. Erst durch den Schalter »-d« wird Racoon gesprächiger. Das Gros der Ausgabe ist zwar informativ, hilft aber meist nicht dabei, den Fehler zu finden. Entscheidend ist es, die Zeilen zu finden, die den Vergleich zwischen der lokalen Konfiguration und den Parametern der Gegenseite ermöglicht. Ein Beispiel zeigt Listing 3 .

Listing 3

Debugging

 

Wie im Beispiel zu sehen ist, stimmt alles überein und es kann weitergehen. Die Verschlüsselungsalgorithmen sind in diesem Fall (AES) als Zahl dargestellt. Der Suchstring »DB:Peer« führt in dem umfangreichen Log am schnellsten zum Ziel.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023