© photocase.com

Admins gelten normalerweise nicht als stockkonservativ. Dennoch scheuen sie sich oft, Linux-basierte VPN-Gateways auf Kernel 2.6 zu aktualisieren. Grund: Der Netkey-IPsec-Implementierung [1] des Kernels 2.6 fehlt die virtuelle Schnittstelle »ipsec0«. Freeswan [3] hatte dieses Interface für Linux 2.4 eingeführt und damit einfache Filterung und Adressenumsetzung (NAT) des IPsec-Verkehrs erlaubt. Abbildung 1 zeigt den einleuchtend einfachen Datenfluss.

Abbildung 1: Der Linux-Kernel 2.4 verfügt über virtuelle »ipsecX«-Netzwerkkarten. Über dieses Interface läuft der Verkehr im Klartext und bleibt vom IPsec-verpackten Teil getrennt.

Folglich war es leicht, für jeden Verkehrstyp die passenden Firewallregeln [2] zu definieren. Das Beispiel nutzt eine interne Netzwerkkarte »eth0« und eine externe »eth1«. Zusätzlich implementiert Freeswan ein virtuelles Netzwerkdevice »ipsec0«. Die Pakete, die der Kernel zwischen »eth0« und »ipsec0« weiterleitet, sind beim Transport über das Internet durch den IPsec-Tunnel geschützt. Pakete, die Linux zwischen den Netzwerkkarten »eth0« und »eth1« transportiert, gehen auch im Klartext durch das Internet. Möchte der Administrator Telnet nur über das VPN erlauben, genügen die Regeln in Listing 1.

01 iptables -P FORWARD DROP
02 iptables -A FORWARD -m state ESTABLISHED,RELATED -j ACCEPT
03 iptables -A FORWARD -p tcp --dport 23 -m state --state NEW -i eth0 -o ipsec0 -j ACCEPT

Virtuelles Interface

Die erste Zeile setzt die Default-Policy in der Forward-Kette auf »DROP«. Die Firewall verwirft fortan alle Pakete, die nicht explizit erlaubt sind. Zeile 2 akzeptiert alle Pakete, die Netfilter als Teil einer aufgebauten Verbindung erkennt. Die dritte Zeile erlaubt Pakete mit Zielport 23 (Telnet), wenn sie eine neue Verbindung aufbauen, das VPN-Gateway über die interne Netzwerkkarte erreichen und sich ans virtuelle Interface »ipsec0« richten. IPsec verschlüsselt in Wirklichkeit alle Pakete, die über »ipsec0« den Rechner scheinbar verlassen, und sendet sie über »eth1« ans ferne VPN-Gateway.

Das Problem: Die virtuellen Schnittstellen stehen für Kernel 2.6 nur noch mit einem Patch zur Verfügung. Das KLIPS-Patch [4] enthält den von Freeswan portierten IPsec-Stack einschließlich der virtuellen Netzwerkkarten und verwendet nicht mehr den nativen IPsec-Stack des Kernels 2.6. Eine Aufnahme dieser Funktionalität in den Standardkernel war und ist daher eher unwahrscheinlich. Das Filtern von IPsec-Verkehr auf Kernel 2.6 stellt damit den Firewall-Administrator vor neue Aufgaben.

Markierung

Bei der IPsec-Implementierung des Kernels 2.6 durchlaufen alle Pakete die Forward-Kette [7], sowohl die aus einem Tunnel stammenden als auch jene, die im Klartext übers Internet eintreffen. Es gibt zunächst keine Möglichkeit, zwischen diesen beiden Paketsorten zu unterscheiden. Die Entschlüsselung und Authentizitätsprüfung erfolgten bereits. Damit ist es nicht unmittelbar möglich, Telnet-Pakete nur zu erlauben, wenn sie durch das VPN eintreffen.

Erste Lösungen für dieses Problem nutzten Markierungen der Pakete mit IPtables. Eine Regel markiert die verschlüsselten IPsec-ESP-Pakete in der Input-Kette, eine weitere Regel in der Forward-Kette wertet die Markierung nach dem Entschlüsseln aus (Listing 2a). Die Marke überlebt die IPsec-Aktionen.

01 iptables -t mangle -A INPUT -p esp -j MARK --set-mark 50
02 iptables -A FORWARD -m mark --mark 50 -j ACCEPT

Das Gleiche passiert beim Senden (Listing 2b): Die zu verschlüsselnden Pakete in der Forward-Kette markieren und in der Mangle-Postrouting-Kette prüfen, ob IPsec alle markierten Pakete wirklich verschlüsselt hat. Diese Variante funktioniert zwar, doch ist die Anwendung besonders bei mehreren Tunnels sehr umständlich. Einfacher klappt es mit dem neuen Policy-Match.

01 iptables -t mangle -A FORWARD -p tcp --dport 23 -j MARK --set-mark 50
02 iptables -t mangle -A POSTROUTING -p ! esp -m mark --mark 50 -j DROP

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.