Sichere Netz­werk­ver­bin­dun­gen mit IPsec

IP-Pakete, die Grund­ele­men­te der Internet-Da­ten­kom­mu­ni­ka­ti­on, bestehen aus zwei Teilen: den Nutzdaten wie Sprache, Text oder Bildern und den Kopfdaten, zu denen u. a. die Adressen des Senders und des Emp­fän­gers zählen. Das große Problem dieser Da­ten­pa­ke­te, die auf ihrem Weg zum Adres­sa­ten ver­schie­de­ne Router passieren, ist die Tatsache, dass das In­ter­net­pro­to­koll von sich aus keinerlei Ver­schlüs­se­lungs- und Au­then­ti­fi­zie­rungs­me­cha­nis­men besitzt. Somit werden die Daten un­ver­schlüs­selt von Router zu Router über­tra­gen und können jederzeit gelesen oder ma­ni­pu­liert werden, wodurch die drei Säulen der In­for­ma­ti­ons­si­cher­heit – Ver­trau­lich­keit, Au­then­ti­zi­tät und In­te­gri­tät – nicht ga­ran­tiert sind. Aus diesem Grund wurde die Pro­to­koll­suite Internet Protocol Security, kurz IPsec, ent­wi­ckelt, die das In­ter­net­pro­to­koll um zahl­rei­che Si­cher­heits­funk­tio­nen erweitert. Mit­ein­an­der kom­bi­niert sorgen sie für eine zu­ver­läs­si­ge Si­cher­heit bei der Über­tra­gung von Da­ten­pa­ke­ten über öf­fent­li­che Netzwerke, weshalb IPsec ein wichtiger Baustein vieler VPN-Ver­bin­dun­gen (Virtual Private Network) ist.

Was ist IPsec?

IPsec ist eine Pro­to­koll­fa­mi­lie, deren Ar­chi­tek­tur von der Internet En­gi­nee­ring Task Force (IETF) als Standard vor­ge­schla­gen wurde. Die IETF ist eine Or­ga­ni­sa­ti­on, die sich mit der tech­ni­schen Wei­ter­ent­wick­lung des Internets be­schäf­tigt. IPsec un­ter­stützt sowohl IPv4 als auch IPv6; bei IPv6 war eine IPsec-Un­ter­stüt­zung his­to­risch ver­pflich­tend vor­ge­se­hen, was dem Protokoll dort einen besonders hohen Stan­dar­di­sie­rungs­sta­tus gab. IPsec kann im We­sent­li­chen in die drei folgenden Funk­ti­ons­grup­pen un­ter­teilt werden:

• Über­tra­gungs­pro­to­kol­le: Au­then­ti­ca­ti­on Header (AH), En­cap­su­la­ting Security Payload (ESP)

• Schlüs­sel­ma­nage­ment: Internet Key Exchange (IKEv2, aktueller Standard; IKEv1 und das zugrunde liegende ISAKMP-Framework sind veraltet und sollten nicht mehr ein­ge­setzt werden)

• Da­ten­ban­ken: Security As­so­cia­ti­on Database (SAD), Security Policy Database (SPD)

Mithilfe der beiden Über­tra­gungs­pro­to­kol­le AH und ESP ga­ran­tiert IPsec die Au­then­ti­zi­tät und In­te­gri­tät der ver­schick­ten Daten, stellt also sicher, dass ihr Inhalt vom an­ge­ge­be­nen Sender stammt und un­ver­än­dert beim Empfänger ankommt. AH bietet zu diesem Zweck durch Er­wei­te­rung des Paket-Headers ei­ner­seits eine Au­then­ti­fi­zie­rung der Da­ten­quel­le, um deren Echtheit zu be­stä­ti­gen, und an­de­rer­seits einen Schutz gegen die Ver­än­de­rung der Pakete auf dem Trans­port­weg. Außerdem fügt das AH-Protokoll dem Header eine Se­quenz­num­mer hinzu, die dem Empfänger er­mög­licht, Replay-Pakete zu erkennen und ab­zu­wei­sen – sofern Anti-Replay aktiviert ist. In der Praxis wird AH heute kaum noch ein­ge­setzt, da es mit Netz­werk­adress­über­set­zung (NAT) in­kom­pa­ti­bel ist – ein Umstand, der es in den meisten modernen Netz­wer­ken un­brauch­bar macht. Das ESP-Protokoll gewährt neben der Iden­ti­täts- und In­te­gri­täts­prü­fung auch eine Ver­schlüs­se­lung der ver­sen­de­ten Daten. Al­ler­dings un­ter­schei­det sich die ESP-Au­then­ti­fi­zie­rung insofern von der des AH-Pro­to­kolls, dass sie den äußeren IP-Header nicht be­rück­sich­tigt und somit nicht voll­stän­dig ist. Mithilfe einer zu­sätz­li­chen Ver­kap­se­lung können die ESP-Inhalte dadurch jedoch in Netz­wer­ken mit Adress­über­set­zung (NAT) richtig zu­ge­stellt werden. In der Praxis hat ESP mit in­te­grier­ter Au­then­ti­fi­zie­rung AH weit­ge­hend abgelöst. Für die Ver­wal­tung der ESP-Ver­schlüs­se­lung ist haupt­säch­lich das IKE-Protokoll ver­ant­wort­lich. Es handelt die Si­cher­heits­ver­ein­ba­run­gen (Security As­so­cia­ti­ons) zwischen Sender und Empfänger aus, nutzt das Diffie-Hellman-Verfahren für den sicheren Schlüs­sel­aus­tausch und setzt dadurch die De­fi­ni­tio­nen des ISAKMP-Frame­works technisch um. Die not­wen­di­gen In­for­ma­tio­nen für den Pa­ket­ver­sand auf Basis von IPsec sind in den zwei lokalen Da­ten­ban­ken SPD und SAD hin­ter­legt. Die Einträge in der Security Policy Database bestimmen bei­spiels­wei­se, welche Über­tra­gungs­pro­to­kol­le – AH, ESP oder beide – für die sichere Ver­bin­dung verwendet werden sollen. Die SAD verwaltet die spe­zi­fi­schen Security-As­so­cia­ti­on-Einträge, die vom IKE-Protokoll angelegt werden, und gibt damit dem Sender Ver­schlüs­se­lungs­ver­fah­ren inklusive Schlüssel und dem Empfänger das ent­spre­chen­de Ent­schlüs­se­lungs­ver­fah­ren vor.

Die zwei Modi von IPsec: Tunnel- vs. Trans­port­mo­dus

Für sichere Ver­bin­dun­gen mit IPsec exis­tie­ren zwei un­ter­schied­li­che Über­tra­gungs­mo­di: Der Trans­port­mo­dus, in dem zwei Endpunkte direkt mit­ein­an­der verbunden werden, und der Tun­nel­mo­dus, der eine Ver­bin­dung zwischen zwei IP-Netzen erstellt.

Close

Trans­port­mo­dus

Bei der Nutzung von IPsec im Trans­port­mo­dus geschieht Folgendes: Zwischen dem IP-Header des Da­ten­pa­kets, der un­ver­än­dert bleibt, und den Nutzdaten wird der Header des je­wei­li­gen Über­tra­gungs­pro­to­kolls eingefügt. Der Schutz beginnt auf dem Aus­gangs­com­pu­ter und bleibt während der gesamten Über­tra­gung bis zum Ziel­com­pu­ter bestehen. Erst nach dem Empfang des Pakets werden die ur­sprüng­li­chen Nutzdaten aus­ge­packt und dem Empfänger zur Verfügung gestellt. Somit sind kryp­to­gra­fi­scher und kom­mu­ni­ka­ti­ver Endpunkt identisch. Der Trans­port­mo­dus hat den Vorteil einer sehr geringen Ver­ar­bei­tungs­zeit. Bei ESP bleiben Quell- und Ziel­adres­sen im IP-Header sichtbar, während die Nutzdaten geschützt sind; AH kann zu­sätz­lich bestimmte un­ver­än­der­li­che Felder des IP-Headers au­then­ti­fi­zie­ren, ver­schlüs­selt aber nichts. Üb­li­cher­wei­se wird dieser Modus für Host-zu-Host- oder Host-zu-Router-Ver­bin­dun­gen verwendet, z. B. zur Netz­werk­ver­wal­tung.

Tun­nel­mo­dus

Im Tun­nel­mo­dus erhalten die Da­ten­pa­ke­te einen komplett neuen IP-Header. Bei Einsatz von ESP werden Quell- und Ziel­adres­se des inneren Headers sowie die Nutzdaten ver­schlüs­selt und sind damit für Dritte nicht einsehbar; bei AH entfällt die Ver­schlüs­se­lung, der innere Header wird aber au­then­ti­fi­ziert. Zu­sätz­lich wird auch der Header des je­wei­li­gen Über­tra­gungs­pro­to­kolls im­ple­men­tiert – wie auch beim Trans­port­mo­dus. Man spricht aus diesem Grund auch davon, dass das ur­sprüng­li­che Paket gekapselt bzw. verpackt wird. Der neue, äußere IP-Header definiert die kryp­to­gra­fi­schen Endpunkte, die nicht mit den ei­gent­li­chen, im inneren IP-Header fest­ge­hal­te­nen Kom­mu­ni­ka­ti­ons­punk­ten identisch sind. Erst wenn das Paket an den kryp­to­gra­fi­schen End­punk­ten, den so­ge­nann­ten Si­cher­heits­gate­ways, entpackt worden ist, wird es an den ei­gent­li­chen Empfänger wei­ter­ge­lei­tet. Stan­dard­mä­ßig findet die Da­ten­über­tra­gung im Tun­nel­mo­dus von Gateway zu Gateway statt; ebenso möglich sind al­ler­dings auch Host-zu-Gateway- sowie Host-zu-Host-Ver­bin­dun­gen.

IKEv1 vs. IKEv2: Der Ge­ne­ra­ti­ons­wech­sel im Schlüs­sel­ma­nage­ment

Das Schlüs­sel­ma­nage­ment-Protokoll IKE (Internet Key Exchange) liegt heute in zwei Versionen vor, die sich in Si­cher­heit, Effizienz und Funk­ti­ons­um­fang deutlich un­ter­schei­den.

IKEv1 war das ur­sprüng­li­che, mit IPsec ein­ge­führ­te Verfahren. Es benötigte zwei getrennte Phasen zum Ver­bin­dungs­auf­bau, galt als komplex in der Kon­fi­gu­ra­ti­on und wies im Laufe der Zeit mehrere Si­cher­heits­lü­cken auf. Seit RFC 9395 (2023) wird IKEv1 von der IETF offiziell als „Historic“ ein­ge­stuft und sollte nicht mehr ein­ge­setzt werden.

IKEv2 (stan­dar­di­siert in RFC 7296, 2014) ist der aktuelle Standard. Die wich­tigs­ten Ver­bes­se­run­gen gegenüber IKEv1:

• Schnel­le­rer Ver­bin­dungs­auf­bau: IKEv2 benötigt nur vier statt neun Nach­rich­ten für die initiale Aus­hand­lung.
• In­te­grier­te NAT-Traversal-Un­ter­stüt­zung: Kein separater Work­around mehr notwendig.
• MOBIKE (RFC 4555): Er­mög­licht es, eine be­stehen­de IPsec-Ver­bin­dung bei einem Netz­wech­sel (z. B. WLAN zu Mobilfunk) auf­recht­zu­er­hal­ten – ent­schei­dend für mobile Endgeräte.
• EAP-Un­ter­stüt­zung: Fle­xi­ble­re Au­then­ti­fi­zie­rungs­op­tio­nen, etwa mit Be­nut­zer­na­me/Passwort über Radius-Server.
• Geringere An­griffs­flä­che: Weniger Aus­hand­lungs­op­tio­nen bedeuten weniger Raum für Fehl­kon­fi­gu­ra­tio­nen.

Alle modernen Be­triebs­sys­te­me – Windows, macOS, iOS und Android – un­ter­stüt­zen IKEv2 nativ. Wer heute eine neue IPsec-Umgebung aufbaut, sollte aus­schließ­lich IKEv2 verwenden.

IPsec: Stärken und Schwächen

Bei der Rea­li­sie­rung von VPNs, die das größte Ein­satz­ge­biet der Pro­to­koll­fa­mi­lie ausmachen, hat IPsec einen ent­schei­den­den Vorteil gegenüber Al­ter­na­ti­ven wie SSL/TLS: Als Standard auf Netz­wer­kebe­ne kann IPsec ap­pli­ka­ti­ons­un­ab­hän­gig ein­ge­setzt werden. Ist die Ver­bin­dung aufgebaut, können die ver­schie­dens­ten Formen des Da­ten­ver­kehrs, ob E-Mail, Da­tei­über­tra­gung oder IP-Telefonie, ab­ge­wi­ckelt werden, ohne dass pro­gramm­spe­zi­fi­sche Tools in­stal­liert werden müssen.

Ein prak­ti­scher Vorteil für den Client-Einsatz: Moderne Be­triebs­sys­te­me (Windows, macOS, iOS, Android) un­ter­stüt­zen IKEv2/IPsec nativ – eine separate VPN-Client-Software ist in vielen Szenarien nicht mehr er­for­der­lich. Gegenüber dem jüngeren WireGuard-Protokoll ist IPsec al­ler­dings deutlich komplexer in der Kon­fi­gu­ra­ti­on und weist einen höheren Overhead auf. WireGuard punktet vor allem mit schlankem Code und sehr einfacher Ein­rich­tung, hat jedoch bislang einen deutlich kleineren En­ter­pri­se-Funk­ti­ons­um­fang und ist in Legacy-In­fra­struk­tur weniger ver­brei­tet.

Auf der Ri­si­ko­sei­te gilt: Die Ap­pli­ka­ti­ons­un­ab­hän­gig­keit kann sich bei un­be­fug­ten Zugriffen schnell zum Problem ent­wi­ckeln, wenn diese nicht von einer zentralen Firewall blockiert werden, da nicht nur eine, sondern alle An­wen­dun­gen gefährdet wären. Un­be­strit­ten sind die Vorteile von IPsec in Sachen Ausfall- si­cher­heit und Per­for­mance: Auf einem ge­clus­ter­ten System kann pro­blem­los ein anderes Gateway ein­sprin­gen, wenn Probleme auf­tau­chen, während Tausende Nutzer gleich­zei­tig mit Da­ten­pa­ke­ten versorgt werden. Zudem un­ter­stüt­zen viele moderne Netz­werk­kar­ten (NICs) IPsec-Hardware-Off­loa­ding, was den CPU-Overhead bei hohen Durch­satz­ra­ten deutlich reduziert. IPsec gilt dank seiner breiten In­ter­ope­ra­bi­li­tät und der tiefen Ver­an­ke­rung in be­stehen­den Netz­werk­in­fra­struk­tu­ren als bewährte Wahl für den Schutz sensibler Daten – vor­aus­ge­setzt, es wird mit aktuellen Al­go­rith­men und IKEv2 betrieben. Die IETF weist aus­drück­lich darauf hin, dass IPsec nicht für jeden Ein­satz­zweck die ideale Si­cher­heits­tech­no­lo­gie ist; die Wahl sollte immer von den konkreten An­for­de­run­gen abhängen.