IPSec Hochverfügbarkeit mit Linux 2.6 und Openswan-2

Transkript

1 Ulrich Weber IPSec Hochverfügbarkeit mit Linux 2.6 und Openswan-2 Abstract Im Rahmen einer Diplomarbeit bei der Firma Astaro AG, Karlsruhe, hat der Referent das IPSec-Paket Openswan für Hochverfügbarkeit auf Kernel 2.6 erweitert. Hierbei werden in einem High-Availability-System die IKE- und IPSec-SAs zwischen Master und Slave synchronisiert. Neben der Synchronisation der eigentlichen SAs sind bei IPSec weitere Protokolleigenschaften wichtig. IPSec besitzt Sequenznummern, um sich vor Replay Attacken zu schützen. Diese müssen in bestimmten Abständen ebenfalls auf dem HA- System synchronisiert werden, damit im Übernahmefall immer gültige Sequenznummern erzeugt und erwartet werden. Auch für Dead Peer Detection (DPD) ist eine zusätzliche Abstimmung nötig. Die Kommunikation zwischen Openswan und Kernel 2.6 (native IPSec) erfolgt über Netlink. Diese Netlink/XFRM Schnittstelle wurde erweitert, um ESP- und AH- Sequenznummern auslesen und ändern zu können.

2 Inhaltsverzeichnis Abstract Einleitung Grundlagen Hochverfügbarkeitsumgebung IPSec Openswan Kernel 2.6 IPSec Implementierung Kernel Schnittstellen Analyse Szenario ESP und AH-Sequenznummern Problematik Hauptprobleme Implementierung Erweiterungen von Openswan Erweiterungen des Kernels Synchronisation der IKE und IPSec-SAs Synchronisation der Sequenznummern Voraussetzungen Fazit und Ausblick Literatur RFCs

3 1 Einleitung IPSec (IP Security) gilt als De-Facto-Standard für VPNs, den gesicherten Zusammenschluss von lokalen Netzwerken über das Internet. Zwar existieren Alternativen wie PPTP oder OpenVPN, IPSec stellt jedoch die sicherste Variante dar. Beim Entwurf von IPSec wurde Ausfallsicherheit durch Erkennung, ob eine Gegenstelle noch erreichbar ist, nicht berücksichtigt. Daher konnte es im ursprünglichen Standard im ungünstigsten Fall die komplette Schlüsselgültigkeit dauern, bis nach einem Systemausfall die IPSec Verbindung neu aufgebaut wird. Um diese Problematik zu umgehen, wurde später unter RFC 3706 die sogenannte Dead Peer Detection (DPD) definiert. Hochverfügbarkeit, im englischen High Availibility gennant und im folgenden als HA abgekürzt, ermöglicht die transparente und reibungslose Übernahme der Dienste eines ausgefallenen Geräts durch redundante Systeme im Fehlerfall. Um HA für IPSec zu realisieren, ist Dead Peer Detection nicht ausreichend, da sämtliche Verbindungen im Fehlerfall neu aufgebaut werden müssen. Für eine vollständige IPSec HA Umgebung ist daher eine vollständige Synchronisation der IKE- und IPSec-SAs nötig. Zusätzlich müssen die Sequenznummern der IPSec-Tunnel und des DPD synchronisiert werden. Bisher existierten nur kommerzielle und nicht frei verfügbare IPSec HA Implementierungen, unter anderem von Cisco Systems TM und Juniper Networks TM. Ziel der Diplomarbeit war die IPSec HA Integration mit den Open Source Komponenten Openswan und Linux Kernel 2.6. Die Ausfallzeit sollte hierbei möglichst unter einer Sekunde betragen bei Beibehaltung bestehender IPSec Verbindungen. 2 Grundlagen 2.1 Hochverfügbarkeitsumgebung Das Ziel einer Hochverfügbarkeitsumgebung ist es, Ausfallzeiten von Diensten und Systemen so gering wie möglich zu halten. In der Regel wird hierbei eine Ausfallzeit von wenigen Sekunden akzeptiert, idealerweise jedoch unter einer Sekunde. Die höheren Netzwerkschichten von IP, wie z. B. TCP, sind in der Lage, mit diesem kurzfristigen Ausfall ohne Datenverlust zurechtzukommen, da mit Unterbrechungen in dieser Größenordnung bereits auf normalen Internet-Verbindungen zu rechnen ist. Um Hochverfügbarkeit zu erreichen wird Redundanz benötigt, die im Allgemeinen aus einem oder mehreren weiteren Systemen besteht. Das aktive System, welches den Datenverkehr verarbeitet, wird hierbei Master genannt, während das passive System, das sich im Standby Zustand befindet, Slave genannt wird. Da der Slave im normalen Betrieb keine Aufgaben übernimmt, wird ein solches System in der HA-Terminologie auch als Active/Passive bezeichnet. In den meisten Fällen werden in bestimmten Abständen sogenannte Heartbeats (Lebenszeichen) vom Master an das Slave System verschickt, um ein funktionsfähiges System zu beweisen. Bleiben diese über einen vorher definierten Zeitraum aus, übernimmt der Slave alle Aufgaben des Masters. Sollten mehrere Slave Systeme existieren, handeln diese bei einem Ausfall untereinander aus, wer die aktive Rolle übernimmt. 3

4 Die wichtigsten Open Source HA-Lösungen für Linux sind das High-Availability Linux Project 1, das Linux FailSafe Project 2 von SGI und der Cluster Manager 3 von RedHat. Eine Erweiterung von Hochverfügbarkeitsumgebungen sind so genannte HA-Cluster, auch Active/Active Systeme genannt. Hierbei befinden sich alle Systeme im aktiven Zustand und teilen die Aufgaben untereinander auf. Da die Umsetzung einer solchen Lösung jedoch deutlich die Komplexität erhöht, beschränkten wir uns auf ein Active/Passive -System. 2.2 IPSec IPSec ist ein VPN Standard der von der IETF ursprünglich für IPv6 definiert wurde, später jedoch auch für IPv4 poriert wurde. Die Verschlüsselung kann entweder mit statischen Schlüsseln erfolgen oder durch ein automatisches Schlüsselaustauschverfahren wie IKE (Internet Key Exchange) - das in den RFCs 2407, 2408 und 2409 definiert ist und einen ständig wechselnden Schlüssel ermöglicht. Verbindungen zwischen zwei IPSec-Systemen können entweder im Transport-Mode oder im Tunnel-Mode erfolgen. Transport-Mode definiert eine direkte Verbindung zwischen zwei Systemen, sichert also lediglich die Kommunikation zwischen zwei Systemen ab. Der Tunnel-Mode dagegen definiert eine Verbindung zwischen zwei Gateways, die ihre lokalen Netzwerke über diese Verbindung miteinander verbinden. Die beteiligten Rechner auf beiden Subnetzen sind sich über die Verschlüsselung nicht bewusst und müssen hierzu auch nicht beitragen. Aus ihrer Sicht erfolgt die Absicherung also transparent. Der direkte Datenverkehr zwischen den beiden Gateways ist hiervon nicht beeinflusst. ESP und AH Zur Umsetzung sowohl von Tunnel-Mode als auch von Transport-Mode werden bei IPSec zwei verschiedene Protokolle verwendet: Authentication Header (AH) und Encapsulating Security Payload (ESP). AH stellt die Authentizität und Integrität einer IPSec-Verbindung sicher, bietet jedoch keine Möglichkeit zur Verschlüsselung der Daten. AH garantiert somit die Echtheit des Paketes und verhindert jegliche Art der Manipulation der Daten. Bei ESP dagegen werden die Daten mit einem symmetrischen Schlüsselverfahren, meist 3DES oder AES, verschlüsselt. Somit stellt ESP die Vertraulichkeit des Pakets sicher und schützt den Dateninhalt vor dem Lesen durch Dritte. Ursprünglich wurden für eine IPSec-Verbindung sowohl ESP als auch AH verwendet - dies garantierte Vertraulichkeit, Authentizität und Integrität. Jedes IPSec-Paket enthielt also sowohl einen ESP- als auch einen AH-Header. Zur Vereinfachung wurde ESP jedoch später in RFC 2406 um die Authentizitäts- und Integritätsfunktionen erweitert. Diese Authentizitäts- und Integritätsfunktionen von ESP beziehen sich aber nur auf den ESP-Header und die IP-Nutzdaten und nicht wie bei AH auch auf den IP-Header. Für den Tunnel-Mode ist dies jedoch ausreichend, da der Original IP-Header hier im ESP Anhang

5 (Payload) liegt und verschlüsselt ist. In der Praxis wird daher fast nur noch ausschließlich ESP im Tunnel-Mode eingesetzt. Security Associations Alle Parameter einer IPSec-Verbindung, wie IP-Adressen und Verschlüsselungsdaten, werden bei IPSec in so genannten Security Associations (SA) abgespeichert. Diese existieren als IKE-SA und IPSec-SA. Eine IKE-SA sichert die Kommunikation zum Schlüsselaustausch. Eine IPSec-SA dagegen sichert den tatsächlichen Datenverkehr zwischen zwei Systemen. Im Gegensatz zu IKE-SAs sind IPSec-SAs unidirektional. Dies bedeutet, dass für eine Verbindung zwei IPSec-SAs existieren, eine für jede Richtung. Ein IKE-Verbindungsaufbau besteht aus zwei Phasen. In Phase 1 wird zuerst eine IKE-SA aufgebaut. Im allgemeinem wird hierbei das Main Mode Verfahren eingesetzt. Es sind aber auch noch andere Arten wie Aggressive Mode und Base Mode möglich, falls diese unterstützt werden. Die Authentifizierung kann über ein Passwort (PSK - Pre Shared Key), RSA Schlüssel oder X.509 Zertifikat erfolgen. Nachdem diese IKE-SA besteht, wird über den Quick Mode von Phase 2 eine IPSec-SA aufgebaut, die die eigentliche Vertraulichkeit, Authentizität und Integrität der IP-Pakete gewährleistet. Die genaue Beschreibung der Authentifizierungsarten und der Schlüsselaustauschverfahren von Phase 1 und Phase 2 sind für ein IPSec HA-System nicht relevant und würden den Rahmen dieser Abhandlung sprengen. Wer sich hierfür interresiert, sei auf das sehr gute Buch Demystifying the IPSec Puzzle 4 verwiesen. Die Gesamtmenge aller im System vorhandenen IPSec-SAs nennt man die Security Association Database (SAD). Analog hierzu gibt es die Security Policy Database (SPD). Diese legt die Richtlinien für den IP-Datenverkehr fest. Diese Richtlinien definieren, wann und wie IPSec anzuwenden ist. Insofern sind IPSec-SAs die Folge der Richtlinien, die in der Security Policy Database festgelegt sind. Für die Verwaltung der IKE-SAs ist der IKE Daemon selbst zuständig. Hierfür gibt es keine Vorgaben. Die SAD und SPD befindet sich dagegen in der Regel im Kernel. Eine Minimalanforderung der Implementierung ist hierfür in RFC 2401 definiert. Zur Verwaltung dieser beiden Datenbanken wurde die PF_Key Schnittstelle in RFC 2367 definiert. Unter Linux existiert zudem alternativ die Netlink Schnittstelle. Sequenznummern Ein Replay-Angriff besteht aus einem absichtlichen, wiederholten Einspielen eines mitgeschnittenen Netzwerkverkehrs. Je nach eingesetztem Protokoll und Dienst kann dies zu unerwünschtem Verhalten und Schäden führen, selbst wenn der Angreifer den Inhalt der verschlüsselten Pakete nicht entziffern kann. Zum Beispiel könnte eine mitgeschnittene finanzielle Transaktion unter Umständen auf diese Weise mehrfach ausgeführt werden. Da die Pakete vom Zielsystem entschlüsselt werden, kann außerdem eine Denial of Service (DoS) Angriff durchgeführt werden, da jedes zu entschlüsselnde Paket Rechenzeit kostet. 4 Sheila Frankel. Demystifying the IPsec Puzzle. Artech House,

6 Sowohl AH als auch ESP haben daher zum Schutz vor Replay-Angriffen Sequenznummern, welche bei jedem Paket inkrementiert werden. Pakete mit unerwarteter Sequenznummer werden verworfen, noch bevor die eigentliche Entschlüsselung geschieht. Die Überprüfung der Sequenznummern und damit der Replay-Schutz kann wahlweise auch deaktiviert werden. Jedoch ist es laut RFC Spezifikation nicht möglich, dies auch auf der Gegenseite zu erzwingen. Jedes IPSec-System entscheidet für sich, ob die Sequenznummern der Pakete überprüft werden. Da bei IP-Paketen nicht immer die gleiche Route durch das Internet gewährleistet ist und Pakete daher in einer anderen Reihenfolge ankommen können, ist ein so genanntes Replay- Window nötig. Das Replay-Window (Aus Sicherheitsgründen maximal 64 bei KLIPS und 32 bei Native IPSec) legt fest, um wie viel ein Paket eine niedrigere Sequenznummer haben darf als das höchst bekannte. Damit bereits empfangene Pakete, die sich im gültigen Replay-Window Bereich befinden, nicht für einen Replay-Angriff missbraucht werden können, existiert eine Replay-Bitmap. Diese Replay-Bitmap erkennt, ob Pakete innerhalb des Replay-Windows schon empfangen wurden. In der Linux Implementierung besteht diese Replay-Bitmap aus 32 Bit. Beispiel: Bei einer gegebenen Reihenfolge von Sequenznummern (104, 99, 108, 79) würde ein darauf folgendes Paket mit einer Sequenznummer von 73 verworfen werden, da das gültige Fenster 76 bis 108 ist. Wird ein Paket mit der Sequenznummer 108 ein zweites Mal empfangen, so wird es auch direkt verworfen. Sequenznummern Fenster Dead Peer Detection Um ausgefallene IPSec-Partner zu erkennen, wurde im RFC 3706 der Dead Peer Detection (DPD) Standard veröffentlicht. Dieser beinhaltet im Falle der Inaktivität des IPSec-Tunnels Keepalive-Nachrichten (R-U-THERE, R-U-THERE-ACK). Bleiben die ACK Pakete über einen vorher definierten Zeitraum aus, so kann davon ausgegangen werden, dass die Gegenstelle nicht erreichbar ist. In diesem Fall werden die dazugehörigen IKE und IPSec-SAs gelöscht. Zum Schutz vor Lifeness-Angriffen - Angriffen die einem IPSec-System eine aktive Gegenstelle vortäuschen, obwohl diese ausgefallen ist - wurden bei DPD auch Sequenznummern integriert. Diese werden auf beiden Seiten mit einem Zufallswert initialisiert, der später bei jeden DPD Paket inkrementiert wird. Die Gegenstelle muss das empfangene R-U-THERE Paket mit einem R-U-THERE-ACK Paket bestätigen, das dieselbe Sequenznummer besitzt. Dieser Datenverkehr ist zum Schutz vor Manipulation mit dem IKE- SA Schlüssel verschlüsselt. Die Gegenstelle merkt sich die empfangene Sequenznummer und erwartet beim nächsten Paket R-U-THERE einen höheren Wert. 6

7 Beide Sequenznummern auf beiden Systemen sind voneinander unabhängig. Welche Sequenznummer für R-U-THERE und R-U-THERE-ACK benutzt werden, hängt davon ab, wer zuerst das R-U-THERE Paket verschickt. Antwortet ein System auf ein R-U-THERE Paket, so ist es Responder. In diesem Fall setzt es seinen eigenen Timer für ein R-U- THERE Paket zurück auf seinen Defaultwert, da eine Aktivität des anderen Systems soeben bewiesen wurde. 2.3 Openswan Openswan ist eine freie, unter der GNU General Public License entwickelte IPSec und IKE Implementierung für Linux. Sie entstand aus dem Open Source Projekt FreeS/WAN, das mit Version 1.0 (veröffentlicht im April 1999) den ersten und lange Zeit einzigen Internet Key Exchange (IKE) Daemon (Pluto) für Linux besaß. Dazu gehörte auch die erste Linux Kernel IPSec Implementierung namens KLIPS (Kernel IPSec). Neben Openswan existieren nun auch folgende andere IKE Daemons für Linux 2.6: Racoon 5 (aus dem KAME Projekt), isakmpd 6 (der IKE Daemon von OpenBSD) und eine weitere FreeS/WAN-Variante namens Strongswan 7, die einen stärkeren Fokus auf die Authentifizierung mit Zertifikaten legt. Die für eine HA-Erweiterung wichtigen Dateien von Openswan sind: programs/pluto/connections.c Verwaltung der Verbindungsendpunkte programs/pluto/demux.c Verarbeitung der IKE-Nachrichten programs/pluto/ipsec_doi.c Schlüsselaustausch Routinen programs/pluto/kernel.c Generelle Kernel Kommunikation programs/pluto/kernel_netlink.c Netlinkspezifische Kernel Kommunikation programs/pluto/plutomain.c Hauptprogramm mit Startparameterkonfiguration programs/pluto/rcv_whack.c Verarbeitung der Whack Nachrichten programs/pluto/server.c Socket und Interface Initialisierung programs/pluto/state.c Verwaltung der IKE und IPSec-SAs programs/pluto/whack.c Schnittstelle zwischen Benutzer und Pluto Openswan Dateifunktionen

8 2.4 Kernel 2.6 IPSec Implementierung Seit der Kernelreihe 2.6 besitzt Linux neben KLIPS eine weitere IPSec Implementierung, die aus dem KAME Projekt hervorgeht. Die eigentliche IPSec Implementierung findet im XFRM- Framework statt. XFRM steht für Transform Framework und ist eine generelles Verschlüsselungsgerüst für IP-Pakete. Beim Schreiben dieser Ausarbeitung existierte jedoch nur die IPSec Implementierung im XFRM-Framework. Es gibt jedoch Pläne, dieses Framework auch für OpenVPN 8 zu nutzen. Für eine Linux IPSec HA-Erweiterung sind folgende Dateien des Kernels wichtig: include/linux/xfrm.h Definition der Strukturen der Netlink/XFRM Schnittstelle include/net/xfrm.h Definition der Strukturen der IPSec Implementierung net/ipv4/ah4.c IPv4 AH-Paketbehandlung net/ipv4/esp4.c IPv4 ESP-Paketbehandlung net/ipv6/ah6.c IPv6 AH-Paketbehandlung net/ipv6/esp6.c IPv6 ESP-Paketbehandlung net/key/af_key.c Implementierung der PF_Key Management API Version 2 net/xfrm/xfrm_export.c Definition der exportierten Funktionen net/xfrm/xfrm_state.c Behandlung der IPSec-SAs (States) net/xfrm/xfrm_user.c Verarbeitung der Netlink/XFRM Kommunikation Linux IPSec Dateifunktionen Da das XFRM-Framework ein generisches Framework ist, definiert es für jeden XFRM-State eine ausgehende und eine eingehende Sequenznummer. Diese xfrm_replay_state-struktur ist wie folgt definiert: struct xfrm_replay_state { u32 oseq; u32 seq; u32 bitmap; }; Da IPSec-SAs jedoch unidirektional sind, wird bei den IPSec XFRM-States entweder die oseq Variable (bei ausgehende IPSec-SAs) oder die seq Variable (bei eingehende SAs) verwendet. Hierauf muss bei einer späteren Sequenznummernsynchronisation geachtet werden. An dieser Stelle sei noch erwähnt, dass die bitmap Variable für ausgehende IPSec-SAs keine Verwendung hat. 2.5 Kernel Schnittstellen Zur Kommunikation zwischen Kernel und Anwendungsebene besitzt Linux mehrere Schnittstellen. Dazu gehören die vom Betriebsystem unabhängige PF_Key Management API Version 2 (definiert im RFC 2367), die zur Schlüsselverwaltung von IPSec verwendet werden kann, sowie Netlink, eine Linux spezifische generelle Kernel Schnittstelle, die hauptsächlich für Firewall Konfiguration, Routing Konfiguration und IPSec Schlüsselverwaltung verwendet wird, als auch Sysctl, einer allgemeinen Parameterkonfiguration zur Laufzeit für den Linux Kernel

9 Openswan verwendet bei der native IPSec Implementierung die Netlink Schnittstelle zur Schlüsselverwaltung. Netlink besitzt unter anderem Multicast Gruppen, um mehrere Prozesse, die einer Netlink Multicast Gruppe angeschlossen sind, gleichzeitig zu informieren. Bei IPSec sind dies: XFRMGRP_ACQUIRE XFRMGRP_EXPIRE Aufforderung des Aufbaus einer IPSec-SA Mitteilung über das nahe Ende einer IPSec-SA 3 Analyse Bei Openswan werden alle Konfigurationen und Passwörter in folgenden Dateien und Verzeichnissen gespeichert: /etc/ipsec.conf Zentrale Konfigurationsdatei /etc/ipsec.d Verzeichnis mit Zertifikaten und weiteren Dateien /etc/ipsec.secrets Zentrale Passwortdatei Es wird davon ausgegangen, dass diese Dateien auf beiden Systemen identisch sind. Die Synchronisation bei Änderungen kann von anderen Programmen, wie rsync 9 oder unision 10, erledigt werden. Alternativ können diese Dateien auch auf einem redundant angebundenen Netzwerk Dateisystem wie NFS gespeichert sein. Somit besteht eine Openswan HA-Erweiterung aus der Synchronisation der statischen Datenstrukturen, die beim Aufbau einer SA im Hauptspeicher erzeugt werden, und der dynamischen Daten, die sich während der Verwendung einer SA im Hauptspeicher ändern. Zu diesen statischen Daten gehören unter anderem die SPI Nummer bei IPSec SAs oder Initiator-Cookie und Responder-Cookie bei IKE-SAs, sowie der Schlüssel zur Generierung der Hash-Prüfsumme (SKEYID_A) und derjenige zur Verschlüsselung (SKEYID_E). Sowohl die IKE als auch die IPSec-SAs werden bei Openswan in der state Struktur gespeichert. Diese Struktur besteht sowohl aus normalen Dateitypen als auch aus Pointer auf andere Strukturen, Pointer auf statische Funktionen und Chunks. Die IPSec-SAs befinden sich daher sowohl im Kernel wie auch im Speicherbereich des IKE Daemons. Daher können die IPSec-SAs wie die IKE-SAs direkt aus Openswan heraus synchronisiert werden. Die dynamischen Daten bestehen aus den ESP und AH-Sequenznummern, die sich im Kernel-Speicherbereich befinden, und den DPD-Sequenznummern, die sich im Speicherbereich des IKE Daemons befinden

10 3.1 Szenario Basisumgebung ist ein Linux HA-System mit Kernel und Openswan Dieses besteht aus einem Master und einem Slave System. Der Slave ist hierbei im passiven Zustand, empfängt und verarbeitet also keine Pakete. Ein vereinfachter Systemaufbau setzt sich wie folgt zusammen: IPSec HA-System Hieraus ergeben sich folgende mögliche Szenarien, die von einer Openswan HA- Erweiterung abgedeckt werden müssen (M = Master, S = Slave): Bei IPSec Verbindungsaufbau müssen SAs von M auf S synchronisiert werden Bei IPSec Verbindungsabbau müssen SAs auch auf S gelöscht werden Geänderte Sequenznummern von M müssen auf S synchronisiert werden Im Falle eines Neustarts von S muss dieser alle SAs inklusiver aktueller Sequenznummern erhalten (Bulk Update) 3.3 ESP und AH-Sequenznummern Problematik Aus Performancegründen, die besonders bei sehr hohen IPSec Datenübertragungen und den dadurch resultierenden sehr raschen Anstieg der Sequenznummern auftreten, sollten die ESP und AH-Sequenznummern nicht bei jeder Änderung aktualisiert werden. Hierfür kann die Eigenschaft von IPSec genutzt werden, dass eingehende Pakete mit höheren Sequenznummern immer akzeptiert werden. Hatte z. B. das zuletzt bekannte Paket eine Sequenznummer von 500, so wird generell jedes Paket mit einer Sequenznummer größer als 500 akzeptiert. Das Replayschutz-Window wird automatisch aktualisiert. Hieraus ergibt sich, dass die eingehenden Sequenznummern weniger häufig synchronisiert werden können als ausgehende Sequenznummern. Die eingehende Synchronisation könnte sogar generell deaktiviert werden, da ein Slave System nach einer HA-Übernahme in diesem Fall alle IPSec Pakete akzeptieren würde und die Sequenznummer des ersten Pakets als aktuellen Wert übernimmt. 10

11 Aus sicherheitstechnischen Aspekten ist dies jedoch nicht sinnvoll. Replay-Attacken werden nämlich genau mit den eingehenden Paketen durchgeführt. Um vollständig gegen solche Angriffe geschützt zu sein, müsste also eigentlich jede Änderung synchronisiert werden. Da dies aber aus Performancegründen nicht sinnvoll ist, muss hier abgewogen werden. Bei einem eingehenden Updateintervall von n könnten im ungünstigsten Fall n-1 Pakete in einem Replay-Angriff nach der HA-Übernahme in das System eingeschleust werden. Hierbei muss jedoch erwähnt werden, dass ein Angreifer in der Lage sein muss, das HA- System gezielt zu einer Übernahme zu bringen. Sollte er dazu in der Lage sein, muss überlegt werden, was für einen Nutzen ein Angreifer durch einen Replay-Angriff erzielen würde. Sollte er durch einen Softwarefehler das Hauptsystem zum Absturz bringen können, so könnte er dies auch beim Slave System erreichen und würde dadurch einen viel größeren Schaden erreichen. Da IPSec durch das Replay-Bitmap vor mehrfacher Entschlüsselung gleicher Pakete geschützt ist, würde bei einem Replay-Angriff jedes Paket nur einmal entschlüsselt werden. Dadurch wäre kein DoS Angriff möglich, falls ha_seqdiff_in der Performance des Systems angemessen gewählt wurde. Ein Angreifer könnte somit nur den Datenverkehr nach einer HA-Übernahme stören. Da jedoch TCP durch seine eigenen Sequenznummern geschützt ist, würde dies nur den UDP-Datenverkehr betreffen. 3.4 Hauptprobleme Die Implementierung lässt sich in zwei Bereiche aufteilen: Erweiterung von Openswan um einen HA-Modus und der Erweiterung des Linux Kernels. Hauptproblem der Openswan Erweiterung war die Übertragung der IKE und IPSec-SA Daten, die bei Openswan in der state-struktur gespeichert sind. Hierfür mussten Funktionen und Makros geschrieben werden, welche die Pointerinhalte auslesen und korrekt synchronisieren. Das Hauptproblem der Kernel-Erweiterung war die Synchronisation der Sequenznummern. Ein weiteres Problem ergab sich aus der Tatsache, dass Openswans Pluto nicht multithreaded ist. Daher kann Pluto entweder eine SA aufbauen oder Daten synchronisieren, jedoch nicht beides gleichzeitig. Dies ist vor allem bei Bulk Updates, Anforderung aller SA Einträge, problematisch, da sich im System unter Umständen eine große Anzahl aktiver SA Einträge befinden kann. Bei einem solchen Fall wäre das System mit der Synchronisation eine längere Zeit beschäftigt und neue SA Anfragen müssten warten. Da jedoch der Implementierungsaufwand, Pluto multithreaded zu machen, in keiner Relation zu dem Nutzen steht, verzichteten wir auf dieses Feature. 11

12 4 Implementierung 4.1 Erweiterungen von Openswan Die meisten Änderungen waren am IKE Daemon Pluto nötig. Pluto hat seine Quelldateien im Verzeichnis programs/pluto des Openswan Paketes. Um Änderungen an den anderen Quelldateien möglichst gering zu halten, wurde eine neue Datei namens sa_sync.c und dazugehöriger Header-Datei sa_sync.h geschrieben. Konfiguration Es wurden folgende neue Konfigurationsparameter für ipsec.conf definiert: ha_interface ha_seqdiff_in ha_seqdiff_out Netzwerkinterface für HA-Kommunikation Größe des Updateintervalls für eingehende Pakete Größe des Updateintervalls für ausgehende Pakete Sollte kein ha_interface definiert sein, startet Openswan im normalen Modus ohne die HA- Erweiterungen. In diesem Fall ist ha_interface als NULL Pointer definiert. Andere Programmteile können dadurch erkennen, ob sich Openswan im HA-Modus befindet. Falls ha_seqdiff_in oder ha_seqdiff_out nicht definiert sind, wird hier der Default Wert verwendet. Diese sind 256 bei in und 1024 bei out. Whack Schnittstelle IPSec besitzt zur Konfiguration während der Laufzeit eine Unix Socket Schnittstelle mit dem Namen Whack. Diese ist mit dem Kommando ipsec whack ansprechbar. Für diese Schnittstelle wurden folgende neue Kommandos definiert: ipsec whack --ha_mode=master ipsec whack --ha_mode=slave ipsec whack --debug-ha Umschaltung in den Master Modus Umschaltung in den Slave Modus Ausgabe von HA-Meldungen im Syslog Zusätzlich wurde der ipsec whack --status Befehl erweitert. Dieser listet die aktuelle Konfigurationsparameter und aktive IKE und IPSec-SAs auf und wurde erweitert, über ein aktives Openswan HA-System zu informieren. Dazu gehört der aktuelle Status (Master oder Slave Modus) und das konfigurierte Openswan HA-Interface. Synchronisations-Kommunikation Zur Kommunikation zwischen Master und Slave wurde Multicast UDP als Protokoll gewählt. Dies ermöglicht in späteren Versionen auch mehrer Slave Systeme zu unterstützen. Als Multicastgruppe wurde und als UDP Port 501 gewählt. 4.2 Erweiterungen des Kernels 12

13 Da der Linux Kernel keine Möglichkeit bot, Sequenznummern in irgendeiner Weise zu ändern oder auszulesen und über Sequenznummeränderungen zu informieren, mussten diese Funktionen neu implementiert werden. Hierfür wurde zuerst ein neues RT Attribute mit dem Namen XFRMA_REPLAY definiert, welches die Sequenznummer und das Replay-Bitmap enthält. Mit Hilfe dieses Attributes können nun Sequenznummern in den Kernel eingetragen und ausgelesen werden. Damit Openswan bei Änderungen an den Sequenznummern informiert wird, wurde eine neue Netlink Multicastgruppe mit dem Namen XFRMGRP_REPLAY definiert. Über die beiden neuen sysctl Variablen sysctl_xfrm_seqdiff_in (für eingehende IPSec-SAs) und sysctl_xfrm_seqdiff_out (für ausgehende IPSec-SAs) kann konfiguriert werden, wie oft über die Änderungen informiert werden soll. 4.3 Synchronisation der IKE und IPSec-SAs Openswan speichert sowohl IKE als auch IPSec SAs in der Struktur state. Daher können beide SA's bei der Synchronisation identisch behandelt werden. Hierfür war die spezielle Behandlung von Pointern aus der state Struktur nötig, damit die Inhalte über das Netzwerk übertragen werden können. Beim Start von Openswan und einem konfigurierten ha_interface ist Pluto immer zuerst im Slave Modus. Sobald alles initiiert ist, sendet er dann eine SYNC_BULK Nachricht. Falls ein aktiver Master diese Nachricht empfängt, durchwandert dieser die Liste aller SAs und überträgt diese inklusive der aktuellen Sequenznummern an den Slave. 4.4 Synchronisation der Sequenznummern ESP und AH Bei jedem ESP oder AH-Datenpaket wird überprüft ob die aktuelle Sequenznummer minus der zuletzt synchronisierten Sequenznummer größer oder gleich dem entsprechenden sysctl_xfrm_seqdiff Wert ist. Ist dies der Fall, wird über die Netlink Multicast Gruppe Openswan von der Änderung informiert. Openswan empfängt dann diese Netlink Nachricht und leitet sie an das Slave System weiter. Das Slave System überprüft anhand der Ziel IP-Adresse der IPSec-SA, ob es sich um eine ausgehende oder um eine eingehende SA handelt. Im Falle einer ausgehenden IPSec-SA wird die entsprechende Sequenznummer um den sysctl_xfrm_seqdiff_out Wert erhöht. Dies garantiert, dass nach einer HA-Übernahme das neue Master System IPSec Pakete mit Sequenznummern versendet, die noch nicht verwendet wurden. 13

14 Dead Peer Detection Um den Synchronisationsaufwand möglichst gering zu halten, wird nur bei einer Aktualisierung der ausgehenden DPD-Sequenznummern synchronisiert. Eingehende Sequenznummern brauchen nicht synchronisiert werden, da höhere Werte vom lokalen System immer akzeptiert werden. In Synchronisationsfall wird jedoch die Synchronisationsnachricht genutzt, um zusätzlich auch die eingehenden DPD- Sequenznummern zu synchronisieren. Dies ist möglich, da IKE-SAs im Gegensatz zu IPSec-SAs bidirektional sind und somit beide Variablen in derselben Struktur gespeichert sind. 5 Voraussetzungen Für ein funktionsfähiges Openswan HA-System müssen folgende Voraussetzungen erfüllt sein: Beide HA-Systeme müssen die identischen Openswan Konfigurationsdateien besitzen Master und Slave System müssen die gleiche IP-Adresse für das LAN Interface besitzen Alle Netzwerk Interfaces müssen aktiv sein Der Slave muss bis auf das Heartbeat Interface alle Netzwerkpakete ignorieren 6 Fazit und Ausblick Die Umsetzung der HA-Lösung für Openswan und Linux Kernel 2.6 wurde erfolgreich abgeschlossen und befindet sich bis zur Veröffentlichung in einer ausgiebigen Testphase. Die Ausfallzeit im Übernahmefall bleibt hierbei im Idealfall unter einer Sekunde. Als Erweiterung und zukünftige Weiterentwicklung steht die Umsetzung eines Active/Active Prinzips an, bzw. die Realisierung eines IPSec Hochverfügbarkeits-Clusters, bei dem alle angeschlossenen Systeme den IPSec Datenverkehr gleichmäßig verarbeiten und zur Gesamtleistung beitragen. Zudem ist geplant, die Kernel IPSec HA Erweiterungen auch für Openswans eigene Kernel-Implementierung KLIPS umzusetzen. 14

15 Literatur Sheila Frankel. Demystifying the IPSec Puzzle. Artech House, Ralf Spenneberg. VPN mit Linux. Addison-Wesley, Günter Schäfer. Netzsicherheit. Dpunkt.verlag, Neil Horman. Understanding And Programming With Netlink Sockets, Version John W. Lockhart. Proceedings of the Linux Symposium 2003 and Yoshifuji-OLS2003.pdf Linux Kernel: Linux Firewall: Openswan Projekt: Offizielle IPSec Arbeitsgruppe: RFCs 2401 Security Architecture for the Internet Protocol 2402 IP Authentication Header 2406 IP Encapsulating Security Payload 2407 The Internet IP Security Domain of Interpretation for ISAKMP 2408 Internet Security Association and Key Management Protocol 2409 The Internet Key Exchange 2412 The OAKLEY Key Determination Protocol 3706 A Traffic-Based Method of Detecting Dead IKE Peers