Seit Entwicklerkernel 2.5.45 ist IPsec fester Bestandteil von Linux. Dabei löste eine neue Implementierung das bisherige Freeswan ab. Das neues Design verzichtet aber auf virtuelle Interfaces und bereitet dadurch dem Zusammenspiel mit Netfilter-Firewalls große Probleme.

Schutzmarke

Der Kernel verwaltet Netzwerkpakete in der Datenstruktur »sk_buff«, die neben einem Zeiger auf die Paketdaten viele weitere Variablen für paketspezifische Informationen enthält. Eine dieser Variablen heißt »nfmark«, sie speichert die Netfilter-Markierungen als Unsigned-Long-Variable:

struct sk_buff {
        ...
# ifdef CONFIG_NETFILTER
        unsigned long   nfmark;
        ...
};

Beim Ver- und Entschlüsseln ändert das IPsec-Modul nur das Paket, nicht aber die Struktur, durch die es im Kernel repräsentiert wird. Damit bleibt der Wert von »nfmark« erhalten, IPtables kann ihn setzen und später wieder prüfen. Anders als bei den Targets »ACCEPT« oder »DROP« bricht eine Verzweigung »-j« zum Target »MARK« die Bearbeitung der folgenden Firewallregeln nicht ab. Das Setzen einer Netfilter-Markierung ist nur in den Chains der Mangle-Tabelle möglich: »iptables -t mangle -A Kette .... -j MARK --set-mark Wert«. Zum Beispiel:

iptables -t mangle -A PREROUTING -p esp -j MARK --set-mark 0x00000001

Überprüfen lässt sich die Markierung in beliebigen Netfilter-Tabellen und allen Chains, die das zu prüfende Paket durchläuft. Eine Regel kann den Wert der Markierung prüfen: »-m mark --mark Wert«. Ein Beispiel:

iptables -A INPUT -p icmp -m mark --mark 1 -j DROP

Statt eines einfachen Werts ist es sogar möglich, zusätzlich eine Maske zu übergeben: »--mark 1/1«. In diesem Fall verknüpft (AND) Netfilter die Maske Bit für Bit mit der Markierung, bevor es das Ergebnis mit dem Sollwert vergleicht und über das weitere Schicksal des Pakets entscheidet (Abbildung 3).

Abbildung 3: Bevor Netfilter die Markierung mit dem Wert vergleicht, maskiert das Modul die Marke Bit für Bit per AND-Verknüpfung.

Eleganter mit Policy-Modul

Neben dem recht primitiven Markierungsverfahren führt auch das neue Policy-Modul zum Ziel. Dazu ist allerdings der Netfilter-Code im Kernel auf den neuesten Stand zu bringen (siehe Kasten "Kurzanleitung Patch-o-matic-NG"). Ähnlich der Paketmarkierung greift das Policy-Modul auf eine Variable in der Struktur »sk_buff« zurück, diesmal ist es jedoch eine Struktur »struct sec_path« und keine einfache Zahl.

tar xvjf patch-o-matig-ng-Datum.tar.bz2
tar xvjf iptables-Version.tar.bz2
ln -s iptables-Version iptables

cd /usr/src/patch-o-matic-ng-Datum
export KERNEL_DIR="/usr/src/linux"
export IPTABLES_DIR="/usr/src/iptables"
./runme Suite

make BINDIR=Dir LIBDIR=Dir MANDIR=Dir
make BINDIR=Dir LIBDIR=Dir MANDIR=Dir install

Der IPsec-Stack des Kernels setzt den Inhalt dieser Variablen selbst. Damit müssen die IPtables-Regeln sich nicht mehr um das Setzen und Prüfen der Markierungen kümmern. Die Regeln für das Ping-Beispiel aus Listing 2 lassen sich wie folgt neu schreiben:

iptables -A INPUT -i eth1 -m policy --dir in --pol ipsec --mode tunnel --proto esp -p icmp --icmp-type 8 -j ACCEPT
iptables -A OUTPUT -o eth1 -m policy --dir out --pol ipsec --mode tunnel --proto esp -p icmp --icmp-type 0 -j ACCEPT

Befindet sich zwischen zwei IPsec-Endpunkten ein NAT-Router, kommt es wegen der Architektur der IPsec-Protokolle zu einem Problem. Im Gegensatz zu TCP oder UDP arbeitet ESP ohne Portnummern. Der NAT-Router ist aber auf Ports angewiesen, um die Pakete eindeutig ihrer Verbindung zuzuordnen. Wenn mehrere Clients gleichzeitig über das NAT-Gateway mit dem gleichen Server kommunizieren, sind Portnummern das einzige Kriterium, um die Antworten zu unterscheiden.

Eine Technik namens NAT-Traversal schafft Abhilfe und sorgt dafür, dass mehr als ein Client eine IPsec-Verbindung durch ein NAT-Gateway aufbauen kann. Der IPsec-Stack verpackt das ESP-Paket in UDP (ESP-in-UDP-Encapsulation genannt). Das UDP-Protokoll arbeitet mit Ports und löst so das Zuordnungsproblem. Der Austausch der UDP-Pakete zwischen den beiden IPsec-Endpunkten erfolgt über Port 4500, den die Firewall auch freigeben muss (siehe Listing 1, Zeilen 44 und 45).

Der Nachteil für die Firewall: Bei NAT-Traversal sehen die Netfilter-Hooks im Kernel nur noch UDP-Pakete statt der ESP-Pakete (Abbildung 2). Für IPtables bleibt der besondere Inhalt des UDP-Pakets verborgen, das ESP-Paket passiert nach dem Entfernen des UDP-Headers keine Netfilter-Chains mehr. Erst nach dem Entschlüsseln durchläuft das Klartextpaket die gleichen Filter, die auch im Tunnelmodus ohne NAT-Traversal zur Anwendung kommen. Im Transportmodus ist der Einsatz von NAT-Traversal allerdings sowieso unsicher.

Im Transportmodus stellt der IPsec-Stack von Kernel 2.6 den Firewall-Designer vor beinahe unlösbare Probleme. Nachdem eintreffende ESP-Pakete die »PREROUTING«- und »INPUT«-Chain hinter sich gelassen haben, werden sie entpackt und direkt an die höheren Protokollschichten weitergereicht. IPtables erhält keinen Zugriff auf die Klartext-Pakete, wie Abbildung 4 zeigt. In dieser Situation bleiben NF-Mark und Policy-Patch wirkungslos. Hier helfen nur noch experimentelle Patches von Netfilter-Core-Mitglied Patric McHardy.

Abbildung 4: Im Transportmodus von Kernel 2.6 sind eintreffende Pakete nur verschlüsselt zu sehen (A). Nach dem Entschlüsseln leitet der Kernel das Paket direkt an höhere Protokollschichten weiter, es durchläuft keine weiteren Netfilter-Hooks mehr.

Seit Entwicklerkernel 2.5.45 ist IPsec fester Bestandteil von Linux. Dabei löste eine neue Implementierung das bisherige Freeswan ab. Das neues Design verzichtet aber auf virtuelle Interfaces und bereitet dadurch dem Zusammenspiel mit Netfilter-Firewalls große Probleme.