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.
Dass IPsec viele Firewall-Techniken untergräbt, ist den meisten Admins bekannt. Die Firewall kann nicht in die Innereien eines IPsec-verschlüsselten Pakets blicken und darum nicht nach Dienst und Port filtern.
Es bleiben in der Praxis dennoch Szenarien, die den kombinierten Einsatz von IPsec und Firewalls erfordern. Sinnvoll ist dieses Paar zum Beispiel in einem Endsystem, dessen Firewall sowohl Klartext-Pakete als auch IPsec-Verkehr empfängt. Nach dem Entschlüsseln und Auspacken soll die Firewall noch unterscheiden können, ob das Paket ursprünglich mit IPsec-Schutz versehen war. Überraschenderweise ist das unter Kernel 2.6 aber nur mit wesentlich größeren Anstrengungen möglich als noch unter Kernel 2.4.
Bei den IPsec-Implementierungen für Kernel 2.4 (Freeswan[3], Openswan[4] und Strongswan[5]) stellt die Kernelkomponente KLIPS virtuelle Interfaces zur Verfügung. Nachdem der IPsec-Stack die empfangenen Pakete ausgepackt und entschlüsselt hat (Decapsulation) und noch bevor er zu sendende Pakete verschlüsselt und verpackt (Encapsulation), durchlaufen die Pakete die Netfilter-Hooks des virtuellen Interface im Klartext.
Dank dieses Interface ist das Filtern vergleichsweise einfach. Die Regeln können zwischen IPsec- und Nicht-IPsec-Verkehr unterscheiden und die IPsec-Pakete im Klartext analysieren. Abbildung 1 zeigt, durch welche Netfilter-Hooks die Pakete in welchem Stadium laufen.
Abbildung 1: Die ESP- und Klartext-Pakete durchlaufen bei Freeswan (Kernel 2.4) mehrere Netfilter-Hooks. Das WAN-Interface »eth1« nimmt ein ESP-Paket aus dem Internet entgegen (A). Unabhängig vom Ziel leitet der IPsec-Stack das ausgepackte Klartext-Paket zunächst an »ipsec0« (B). Pakete für den lokalen Rechner bleiben in »ipsec0« (C), alle anderen gehen über einen weiteren Hook in »ipsec0« (D) an das LAN-Interface »eth0« (E). Beim Versenden ist der Ablauf umgekehrt (6 bis J).
Als Beispiel soll ein Rechner nur IPsec-geschützte Daten akzeptieren. Die Firewall-Policy darf auf dem physikalischen WAN-Interface »eth1« dazu ausschließlich ESP-Pakete sowie UDP-Pakete auf Port 500 (IKE-Daemon) und Port 4500 (NAT-Traversal) gestatten. Die Paketfilter sind in der »INPUT«- und »OUTPUT«-Chain des virtuellen Interface zu platzieren. Arbeitet der Rechner als Gateway und schützt ein privates LAN, dann kommen zusätzlich Regeln in der »FORWARD«-Chain zwischen virtuellem Interface »ipsec0« und LAN-Interface »eth0« zum Einsatz.
Der Weg der Pakete durch die einzelnen Netfilter-Hooks ist für Tunnel- und Transportmodus identisch. Im Transportmodus entfallen jedoch die Regeln für die »FORWARD«-Chain, da bei der direkten IPsec-Verbindung die Endpunkte selbst das Entschlüsseln der Pakete übernehmen. Listing 1 zeigt den Auszug eines typischen Firewallskripts, passend für IPsec unter Kernel 2.4.
Die Befehle in den Zeilen 15 bis 17 setzen die Default-Policys der Filter-Chains auf »DROP«. Danach definieren die Kommandos ab Zeile 34 die Regeln für ESP, IKE und NAT-Traversal auf dem WAN-Interface. Die Regeln in Zeile 57 und 58 erlauben einen Echo-Request über IPsec an das Gateway und das entsprechende Echo-Reply. Der geschützte Zugriff auf einen POP3-Server im LAN, etwa durch einen Roadwarrior, wird von den Regeln ab Zeile 74 gestattet.
Die Regeln aus Listing 1 zeigen auszugsweise, dass das Filtern ein-, aus- und weitergehender Pakete über das »ipsec0«-Interface recht übersichtlich erfolgt und sich nicht von Regeln für ein physikalisches Interface unterscheidet.
Die IPsec-Implementierung in Kernel 2.6[6] verzichtet leider auf virtuelle Interfaces. Darüber hinaus ist der Weg der Pakete durch die Netfilter-Hooks im Tunnelmodus anders als im Transportmodus. Kommt auch noch NAT-Traversal zum Einsatz, dann ist das Verkehrschaos perfekt. Es sind komplizierte Zusatzfeatures aus dem Netfilter-Framework nötig (Mark-Target oder IPsec-Policy), um wenigstens einige der Probleme in den Griff zu bekommen. Andere lassen sich selbst damit nicht lösen und erfordern experimentelle Kernelpatches, die Netfilter-Core-Mitglied Patrick McHardy entwickelt hat (IPsec-Hooks).
Im Tunnelmodus durchläuft ein ESP-verschlüsseltes Paket die »PREROUTING«- und »INPUT«-Chains des WAN-Interface »eth1«. Nach der Decapsulation passiert das Paket im Klartext erneut die »PREROUTING«-Chain des WAN-Interface »eth1« und, abhängig von der Zieladresse, ein zweites Mal die »INPUT«-Chain oder die »FORWARD«-Chain von »eth1« (siehe Abbildung 2). Das Problem ist: Ausgepackte Pakete sind nicht mehr von einem neu eingetroffenen Paket gleichen Typs zu unterscheiden. Ob das Paket ursprünglich als ESP-Paket eintraf, lässt sich beim Durchlaufen der Netfilter-Hooks im unverschlüsselten Zustand nicht mehr feststellen.
Abbildung 2: Im Tunnelmodus von Kernel 2.6 durchläuft ein IPsec-Paket die Eingangsfilter von »eth1« doppelt. Erst nimmt das WAN-Interface »eth1« ein ESP-Paket an (A). Unabhängig vom Ziel leitet der IPsec-Stack das ausgepackte Klartext-Paket erneut an »eth1« (B). Pakete für den lokalen Rechner bleiben in »eth1« (C), die anderen gehen über einen weiteren Hook in »eth1« (D) an das LAN-Interface »eth0« (E). Am Klartext-Paket ist nur noch durch spezielle Markierungen erkennbar, ob es über IPsec eingetroffen ist.
Als Ausweg muss der Kernel ESP-verschlüsselte Pakete markieren und die unverschlüsselte Fassung beim erneuten Netfilter-Durchlauf auf diese Markierung hin überprüfen. Das Markieren der Pakete erledigt das »MARK«-Target; ein IPtables-Match-Filter prüft, ob ein Paket markiert ist. Eine Markierung für ausgehende Daten ist nur dann nötig, wenn die Firewall-Policy bestimmte Pakettypen ausschließlich unverschlüsselt, nicht aber im Tunnel erlauben soll. Eine »DROP«-Regel für ESP-Pakete mit gesetzter Marke verwirft in diesem Sonderfall unerwünschte Pakete.
Egal ob ein Dienst nur im Tunnel oder auch unverschlüsselt erlaubt sein soll, die »FORWARD«- oder »OUTPUT«-Chain muss ihn zunächst akzeptieren. Das relevante Filtern findet in der »POSTROUTING«-Chain statt, die auf »DROP«- Policy gesetzt ist. Erlaubt sind in dieser Chain nur ESP- sowie jene Pakete, die den Rechner auch unverschlüsselt verlassen dürfen.
In Abbildung 2 sind die Stellen gekennzeichnet, an denen Netfilter-Regeln die Markierungen setzen oder prüfen müssen. Listing 2 setzt die Theorie in die Praxis um und erreicht die gleiche Funktion wie Listing 1. Auch hier handelt es sich nur um einen kleinen Auszug.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
