Linux VPN: IPsec, OpenVPN und Wireguard

• Erstelle eine Shell-Verbindung zu beiden VMs (Web oder SSH)
• Prüfe die Netzwerkkonfiguration mit ip address show
• Prüfe die Routing-Konfiguration mit ip route show
• Teste die Netzerkverbindung zwischen beidem VMs mittels ping

• ISAKMP = Internet Security Association and Key Management Protocol
• IKE oder IKEv1 = Internet Key Exchange Version 1 (eine Implementation von ISAKMP)
• IKEv2 = Internet Key Exchange Version 2 (eine moderne Implementation von ISAKMP)
• AH = Authentication Header = ein Modus von IPsec, sichert Integrität und Authentisierung der Daten
• ESP = Encapsulating Security Payload = ein Modus von IPsec, sichert Integrität, Authentisierung und Vertraulichkeit der Daten
• Transport Mode = IPSec Modus, bei welchem der IP-Header gesichert, aber nicht geändert wird. Funktioniert nicht mit NAT
• Tunnel Mode = IPsec Modus, bei welchem das IP-Paket in ein neues IP-Paket eingepackt wird. Funktioniert mit NAT, benötigt mehr Bandbreite und kann Problemen mit MTU und Fragmentierung führen
• Security Association (SA) = Paket aus Verschlüsselungs-Algorithmen und -Parametern für eine Richtung einer IPsec Verbindung
• Security Policy Database (SPD) = Datenbank innerhalb der IPsec Implementierung, welche die Regeln für die Anwendung von IPsec auf IP-Pakete definiert (welche Verbindungen sollen durch IPsec abgesichert werden)
• Securty Association Database (SADB oder SAD) = Datenbank innerhalb der IPsec Implementierung mit Informationen zu den Verschlüsselungs-Algorithmen und -Parametern für jede Verbindung)

• Arbeit an IPsec startete in 1992, zusammen mit der Arbeit an IPv6
  • IPv6-Implementierungen sollen auch eine IPsec Implementierung beinhalten
  • IPsec für IPv4 wurde nachträglich entwickelt, als klar wurde das die IPv6 Umstellung längere Zeit benötigen wird
• Erste Implementationen für BSD-Unix wurden vom "Naval Research Labatory" (NRL) erstellt
• Dies war vor NAT (1994) und "privaten" IP-Adressen (RFC 1918, 1996)!
  • Dies war einer der Gründe warum die Einrichtung der frühen Versionen von IPsec unter IPv4 recht komplex und schwierig waren
  • Probleme mit IPsec und NAT hat zu einem schlechten Ruf von IPsec geführt
• IPsec mit IKEv1 wurde 1998 zum Internet Standard (RFC)
• Das Problem bei IPsec war der Schlüssenaustausch (IKEv1)
  • IKEv1 war nicht mit Beachtung von NAT in Netzwerken entwickelt worden und kommunizierte IP-Adressen
    • Diese IP-Adressen wurden auf dem Weg durch NAT geändert und passten nicht mehr zu den IKE-Daten = Pakete wurden verworfen
• Nach der Veröffentlichung von IPsec mit IKEv1 wurde in der IETF an einer Verbesserung von IPsec gearbeitet
  • Einfache Konfiguration
  • Bessere Fehlersuche
  • Kompatibel mit IPv4 NAT-Netzwerken
• IKEv2 für IPsec wurde 2005 als Internet-Standard veröffentlicht, IKEv1 wurde als veraltet markiert
• Mit RFC9395 (April 2023) wurde IKEv1 als deprecated markiert, soll nicht mehr implementiert und benutzt werden
  • In LibreSwan wurde IKEv1 in den neueren Versionen entfernt

• Ein IPsec Verbindungsaufbau geschied in Schritten. In IKEv1 wurden diese Schritte Phase 1 (IKEv2 = Parent SA) und Phase 2 (IKEv2 = Child SA) genannt. Unter IKEv2 gibt es diese Phasen so nicht mehr (in den Standard-Dokumenten, RFC), die Begriffe werden jedoch weiterhin von Netzwerkadministratoren auch für IKEv2 IPsec verwendet (auch wenn das nicht mehr korrekt ist).
  • Aushandeln der Kontrollverbindung (Phase 1 bei IKEv1): die IPsec Kommunikationspartner verständigen sich auf einen verschlüsselten Kanal (Algorithmen und Parameter). Ergebnisse ist die SA (Security Association) oder auch Parent-SA.
    • Über diese (verschlüsselte und authentisierte) Kontrollverbindung werden nun die Algorithmen und Parameter für die Datenverbindung ausgehandelt (Phase 2 bei IKEv1). Dies ist die Child-SA.
    • Die Daten werden der Verbindung werden mittels der Konfiguration der Child-SA verschlüsselt und abgesichert
    • Die Parameter der Child-SA können sich von den Parametern der Parent-SA unterscheiden(!)
    • Die Parameter von Parent-SA und Child-SA können sich für jede Kommunikationsrichtung unterscheiden(!)
• Die IKE-Kommunikation benutzt die Ports 500 (default, ohne NAT) und 4500 (wenn NAT zwischen den IPsec-Kommunikationspartnern entdeckt wurde)
  • Die IKE-Kommunikation benutzt UDP als Transport-Protokoll
  • RFC 9329 (TCP Encapsulation of Internet Key Exchange and IPsec Pakets) erlaubt das "tunneln" von IKE und IPsec-Paketen über TCP. Dies ist notwendig bei Firewall-Middelboxen welche jegliche UDP-Kommunikation bklockieren (z.B. in Hotels oder öffentlichen WLAN-Netzwerken)

• IPsec kennt zwei Arten der Absicherung von IP-Paketen: Authentication Header (AH) und Encapsulating Security Payload (ESP)
• Bei AH wird ein weiterer Header (IP-Protokoll 51) in das IP-Paket zwischen dem IP-Header und den Daten (Payload) bzw. dem Header des Transport-Protokols (UDP oder TCP) des IP-Paketes eingefügt
• Dieser Header enthält kryptografische Prüfsummen (Hashes) über Teile des IP-Headers und den Daten
• AH bietet Integrität und Autentifizierung, jedoch keine Vertraulichkeit (Verschlüsselung)
• AH kann sowohl im Transport- als auch im Tunnel-Modus von IPsec eingesetzt werden
• AH wird für Punkt-zu-Punkt Verbindungen zwischen zwei Rechnern mit öffentlichen IP-Adressen (meist IPv6) benutzt

• ESP ist eine Alternative zu AH und ist der heute meist genutzte Modus von IPsec
• Bei ESP werden die zu sichernde Daten (Payload) vollständig und unverändert in ein neues ESP-Transport-Protokoll mit einem ESP-Header eingeschlossen (IP-Protokoll 50 = ESP)
• ESP kann sowohl im Transport-Mode als auch im Tunnel-Mode eingesetzt werden
• ESP wir oft für VPNs zwischen zwei Netzwerken benutzt, bei denen jeglicher Verkehr zwischen den Netzwerken durch IPsec abgesichert sein soll
• In einigen Fällen kann ESP Vorteile beim Durchsatz von IP-Paketen bringen, wenn ESP durch Hardware-Funktionen unterstützt wird (IPsec offloading). Dies setzt Netzwerkhardware mit spezieller IPsec Offloading-Funktion vorraus

• Sowohl AH als auch ESP können wahlweise im Transport-Modus als auch im Tunnel-Modus eingesetzt werden
• Beim Transport-Modus werden in das bestehende IP-Paket AH- oder ESP-Header eingefügt. Der IP-Header bleibt original bestehen, bei AH wird der IP-Header geschützt, bei ESP werden nur die Daten geschützt
  • Der Transport-Modus wird häufig benutzt um die Kommunikation zwischen zwei einzelne Rechner abzusichern. Bauen diese zwei Rechner eine ungesicherte Tunnelverbindung zwischen zwei Netzwerken (z.B. GRE- oder IPIP-Tunnel), so kann diese bestehende Verbindung durch IPsec-Transport-Mode abgesichert werden

• Beim Tunnel-Modus wird das original IP-Paket in ein neues (IPsec-gesichertes) IP-Paket eingebettet. Die IPsec Sicherheit (AH oder ESP) sichert dabei das gesamte original IP-Paket.
  • Auf der Empfängerseite wird das Paket wieder ausgepackt und unverändert an den Netzwerk-Stack des Empfängers übergeben
  • Tunnel-Mode eignet sich gut um mehrere Netzwerke mittels IPsec-Gateway-Router miteinerander zu verbinden

• Einer der Designziele von IPsec war die vollständige Verschlüsselung von IP-Netzwerken im Internet
• Traditionelle IPsec Verbindungen werden manuell erstellt und konfiguriert
• Bei opportunistic encryption (OE-IPsec) wird die IPsec-Verbindung zwischen zwei Kommunikationspartnern automatisch ausgehandelt
• Beim ersten IP-Paket wird getestet, ob die Gegenstelle IPsec unterstützt
• Authentisierung geschied mittels (DNSSEC gesichertem) DNS (Prüfung von vorwärts – A- und AAAA-Records – und rückwärts (PTR-Records) DNS-Auflösung
• Im IPSECKEY-Record können pro Host IPsec-Parameter im DNS abgelegt werden (RFC 4025)
  • Der IPSECKEY-Record beinhaltet den Gateway-Typ (IPv4 oder IPv6), die Gateway-Adresse, den Schlüsselalgorithmus des öffentlichen Schlüssel des Hosts und den öffentlichen Schlüssel
  • IPSECKEY-Record sollten per DNSSEC abgesichert sein, Empfänger von IPSECKEY-Records sollten diese per DNSSEC prüfen

dnf install libreswan

• Datei /etc/ipsec.d/psk-tunnel.conf erstellen (emacs, vim, nano)

conn host-host
     keyexchange=ikev2
     authby=secret
     left=<ip-vm-1>
     right=<ip-vm-2>
     auto=add

• IPSec Konfiguration neu laden

ipsec restart

• Status des Dienstes prüfen

systemctl status ipsec

• Logdateien des IPsec Dienstes (LibreSwan) anschauen

journalctl -u ipsec

• Logdateien im "follow"-Modus beobachten

journalctl -fu ipsec

• Benannte IPsec Verbindung starten

ipsec up host-host

• IPsec Status anzeigen

ipsec status

• Linux-Kernel IPsec Policy Datenbank anzeigen

ip xfrm pol

• Linux-Kernel IPsec Verbindungen anzeigen /ACHTUNG: dieser Befehl zeigt die IPsec Schlüssel im Klartext. Mittels der Daten dieses Befehls kann eine IPsec Kommunikation entschlüsselt werden! (mehr dazu später)

ip xfrm state

• Firewall? Finde auf der Webseite https://libreswan.org die Information, wie bei Red Hat Systemen IPsec in der Firewall erlaubt wird

Datei /etc/ipsec.d/psk-tunnel.secrets:

<ip-vm1> <ip-vm2> : PSK "mein-geheimer-schluessel"

• RSA-Schlüssel erstellen, CKAID notieren

# ipsec newhostkey --nssdir /var/lib/ipsec/nss
Generated RSA key pair with CKAID 3bdd3ee727c90bac3218dcaf0cdf680a0a405664 was stored in the NSS database
The public key can be displayed using: ipsec showhostkey --left --ckaid 3bdd3ee727c90bac3218dcaf0cdf680a0a405664

• NSS-Schlüssel anzeigen

ipsec showhostkey --list

• RSA-Schlüssel ausgeben

# ipsec showhostkey --left --ckaid  3bdd3ee727c90bac3218dcaf0cdf680a0a405664
        # rsakey AwEAAc73d
        leftrsasigkey=0sAwEAAc73dvkhQKUgEKG1W2bg8BrSgTXDWG47ST71j58NOs7s1gRBydtRLCrdEkO8GeTTjCSPmq6nW+CWCPP10zxDbsj/rHfYbuGwkBLdjEvseO96W2C0w2TKe0KhAuJCVrioGUGZ3Fdvib3gjrlryAFjSMipLV5ykZDR9ZFi4EBMIH4N2bfuAIgnNe84iIfqFt5RnY486uTy78LU2qlSxBVHaMmlSRb50WJuCB39J7auKNdQepmmbJZusmffYtsAoQul2ysF3sxW7nX9I3Gmmz5+PSrLefPvj9q0yv3n9DLCZPserQK+Fnxo/R7MbMYSVIOgAFyZYd/9jCSy2+oSJkoseW5u+22KKnCYRkSbw5BD/WAqa4+KK3CNcfPSkfFAEtbD762fi+FW8BRMqHrhZln+gTIOr/IZYCOiR2w+8Qk26ZhTJAn5nT8lTBsES9vUbvKqj5CUIOGj4emx2j6RAZAZm74zYfIcK0puweNt5wMhxGbez3yJbJRxoU6nqko/aB5Cz5bnOfAE2pd9J5L5XhOH7PS/oNFFHILIt6FltxaAyHDFyEjlb63ZhxR7wgkFrDjfYCnMGss=

• RSA-Schlüssel Authentisierung (ipsec Konfiguration):

[...]
authby=rsasig

• Teste die IPsec Konfiguration im Tunnel-Mode mit ICMP. Notiere die Grßsse der ESP-Pakete
• Konfiguriere die aktuelle IPsec-Konfiguration für den Transport-Mode (Standard ist Tunnel-Mode)

[...]
type=transport

• Vergleiche die Grössen der Pakete bei einem ICMP-Echo Reqest/Reply ("ping") zwischen Tunnel- (Default) und Transport-Mode.

• Root-CA erzeugen

certutil -S -k rsa -n "MyLocalCA" -s "CN=Lokale CA" -v 12 -t "CT,C,C" -x -d sql:/var/lib/ipsec/nss

• Maschinen-Zertifikat erzeugen

certutil -S -k rsa -c "MyLocalCA" -n "vm1" -s "CN=vm1 Common Name" -v 12 -t "P,," -d sql:/var/lib/ipsec/nss

• Zertifikate in der NSS-Datenbank anzeigen

certutil -L  -d sql:/var/lib/ipsec/nss

• Einzelnes Zertifikat anzeigen

certutil -L -n vm1  -d sql:/var/lib/ipsec/nss | less

• Bei Fehlern kann ein Zertifikat aus der Datenbank gelöscht werden

certutil -D -n <nickname>  -d sql:/var/lib/ipsec/nss

• Das Root-Zertifikat einer CA aus der Datenbank exportieren

certutil -L -n "MyLocalCA" -d sql:/var/lib/ipsec/nss -a > mylocal.crt

• Das Root-Zertifikat (öffentlicher Schlüsse) aus einer Datei in die NSS-Datenbank importieren

certutil -A -i mylocalca.crt -n "MyLocalCA" -t "CT,," -d sql:/var/lib/ipsec/nss

• Ein Benutzer/Maschinen-Zertifikat exportieren (nur öffentlicher Schlüssel)

certutil -L -n "vm1" -d sql:/var/lib/ipsec/nss -a > vm1.crt

• Ein Benutzer/Maschinen-Zertifikat importieren (nur öffentlicher Schlüssel)

certutil -A -i vm1.crt -n "vm1" -t "P,," -d sql:/var/lib/ipsec/nss

• Ein Benutzer/Maschinen-Zertifikat exportieren (öffentlicher UND privater Schlüssel)

pk12util -o vm2.p12 -n vm2 -d sql:/var/lib/ipsec/nss

• P12 (binär) in PEM (Text) umwandeln

openssl pkcs12 -in vm2.p12 -out vm2.pem -clcerts -nodes -legacy

• PEM (Text) und P12 (binär) umwandeln

openssl pkcs12 -export -in vm2.pem -out vm2.p12

• Ein Benutzer/Maschinen-Zertifikat importieren (öffentlicher und privater Schlüssel)

ipsec import vm2.p12

• Nickname eines Zertifikats in der NSS-Datenbank umbenennen

certutil  -n "vm2 Common Name" --rename --new-n "vm2" -d sql:/var/lib/ipsec/nss

• Die Vertrauens-Attribute eines Zertifikats anpassen

certutil -M -n vm2 -t "P,," -d sql:/var/lib/ipsec/nss

• LibreSwan unterstützt IPsec mit Virtual Tunnel Interface (VTI)
• VTI erzeugt eine virtuelle Netzwerkschnittstelle im Linux-System
  • Alle Netzwerkpakete, welche über diese Schnittstelle geroutet werden, sind per IPsec abgesichert
  • Die Sicherheit des VPN-Tunnel hängt am Routing und der Firewall-Konfiguration – Pakete welche nicht über das VTI geroutet werden, werden nicht IPsec gesichert
  • IPsec mit VTI vereinfacht die Konfiguration und Fehlersuche im IPsec
    • Am VTI-Interface sind die unverschlüsselten Daten zu sehen
    • Am physischen Netzwerkinterface sind die verschlüsselten IPsec-Pakete zu sehen
• Beispiel einer Konfiguration mit Zertifikaten und VTI-Schnittstelle

conn vti-vti
     keyexchange=ikev2
     authby=rsa-sha2
     type=tunnel
     left=vm1
     leftsubnet=0.0.0.0/0
     leftid=%fromcert
     leftrsasigkey=%cert
     leftcert=vm1
     leftsendcert=always
     right=vm2
     rightsubnet=0.0.0.0/0
     rightid=%fromcert
     rightrsasigkey=%cert
     rightcert=vm2
     rightsendcert=always
     mark=5/0xffffffff
     vti-interface=vti01
     vti-routing=no
     auto=add