Open Source im professionellen Einsatz

Newsletter abonnieren
Seite durchsuchen

HEFTARCHIV | NEWS | E-BIBLIOTHEK | VIDEO | BLOGS | WHITEPAPER | EVENTS | ACADEMY | ABO | SHOP

user friendly

  Home  »  Heft & Abo  »  Heftarchiv  »  2006  »  08  »  Doppelnase  

RSS-Feed der aktuellen News von Linux-Magazin Online Folgen Sie Linux-Magazin Online auf Twitter
Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark

© photocase.com

Neue Netfilter-Features erlauben reibungslose Zusammenarbeit mit IPsec

Doppelnase

von Ralf Spenneberg
Erschienen im Linux-Magazin 2006/08

IPsec-Verkehr war beim Linux-Kernel 2.6 bisher weitaus schwieriger zu filtern als noch unter 2.4. Seit Ende März 2006 klappt mit den aktuellen Versionen von Kernel und IPtables das Zusammenspiel endlich wieder reibungslos: Das Policy-Match und ein Patch von McHardy machen's möglich.

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.

Listing 1: Virtuelles
Interface

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.

Listing 2a: Markierung beim
Empfangen

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.

Listing 2b: Markierung beim
Senden

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.


Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark
Whitepaper
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)

Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.

Download PDF (Registrierung erforderlich)
Usage Landscape Enterprise Open Source Data Integration

Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.

Download PDF (Registrierung erforderlich)
Kommentare (0)