Policy-Match
Seit Version 1.3.5 enthält das »iptables«-Kommando das Policy-Match. Mit ihm erkennt die Firewall in der Forward-Kette, ob ein Paket durch eine IPsec-Policy geschützt ist (Abbildung 2). Eine Regel kann sogar definieren, durch welchen Tunnel die Pakete fließen müssen. Listing 3 akzeptiert nur Telnet-Pakete, die durch einen IPsec-Tunnel kommen, der per ESP verschlüsselt ist.
|
Abbildung 2: IPtables kann ab der Version 1.3.5 mit dem Policy-Match IPsec-Pakete erkennen.
|
01 iptables -A FORWARD -p tcp --dport 23 -m policy --dir out --pol ipsec --proto esp --mode tunnel -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
02 iptables -A FORWARD -m policy --dir in --pol ipsec --proto esp --mode tunnel -m state --state ESTABLISHED,RELATED -j ACCEPT
|
Die Option »--dir« unterscheidet, ob die Policy das Paket verschlüsselt (»out«) oder entschlüsselt hat (»in«). Die Option »--pol« trennt geschützte (»ipsec«) und nicht durch IPsec behandelte Pakete (»none«). Mit »--proto« wählt der Admin, ob ESP das Paket verschlüsseln und authentifizieren soll (»esp«), ob das AH-Protokoll lediglich die Integrität und Authentizität sichert (»ah«, siehe Kasten "IPsec-Funktionsweise") oder ob das Paket nur komprimiert ist (»ipcomp«). Mit »--mode« unterscheidet IPtables, ob das Paket im Tunnelmodus oder im Transportmodus durchs Netz läuft.
|
Die IPsec-Protokolle wurden ursprünglich für das neue Internetprotokoll IPv6 entwickelt. Sie sorgen für Authentizität, Integrität und Vertraulichkeit der übertragenen Informationen. Hierzu signieren und verschlüsseln sie die übertragenen Pakete. Es stehen zwei Protokolle zur Verfügung: AH und ESP. Während AH (Authentication Header) nur die Signatur beherrscht, kann ESP (Encapsulation Security Protocol) signieren und verschlüsseln. Daher verwenden VPNs meist ESP.
Beide Protokolle benötigen zum Signieren und Verschlüsseln symmetrische Keys und Angaben über den zu verwendenden Algorithmus. Diese kann der Administrator fest auswählen (Manual-keyed Connections). Besser sind jedoch Automatic-keyed Connections, bei denen die Rechner die Informationen per IKE-Protokoll aushandeln (Internet Key Exchange). Während ESP und AH als Transportprotokolle bei Linux im Kernel implementiert sind, spricht ein Userspace-Daemon das IKE-Protokoll. Das ist entweder Pluto (Openswan [4], Strongswan [5]) oder Racoon (Netkey-IPsec in Kernel 2.6 [1]). Die ausgehandelten Informationen landen anschließend in zwei Datenbanken:
- Security Policy Database (SPD)
- Security Association Database (SAD)
Während die Security Policies definieren, welche Pakete IPsec mit welchen Protokollen zu schützen hat, enthalten die Security Associations alle Angaben über die zu verwendenden Schlüssel und Algorithmen. Existiert keine Security Policy, schützt IPsec auch kein Paket. Für komplexe Anforderungen kann der Admin Security Policies auch verschachteln, um zum Beispiel ein Paket zunächst mit IPcomp zu komprimieren, anschließend mit ESP zu verschlüsseln und zusätzlich mit AH zu authentifizieren. Die SAD und die SPD lassen sich bei Openswan mit den Befehlen »setkey -D« beziehungsweise »setkey -DP« anzeigen.
|
Richtungweisend
Zwingend ist beim Policy-Match die Richtungsangabe mit »--dir«. Weitere Parameter spezifizieren die Tunnelendpunkte (»--tunnel-src« und »--tunnel-dst«), »--spi« gibt die SPI des Tunnels an. Letzteres ist aber kaum sinnvoll, da der IKE-Daemon die Security Parameter Indices dynamisch aushandelt.
Weit nützlicher ist der Einsatz der Option »--reqid«. Jede Policy kann eine eigene Request-ID erhalten, die auch einige IKE-Daemons setzen. Zum Beispiel nutzt Pluto (von Openswan und Strongswan) diese Funktion. Damit gelingt es auch bei dynamischen IP-Adressen, die Tunnel spezifisch in der IPtables-Regel auszuwählen.
Bei geschachtelten Policies prüft Netfilter wahlweise auch deren Reihenfolge und Vollständigkeit. Hierzu dient die Option »--strict« in der IPtables-Regel; auf sie folgt die Definition der einzelnen Policies, die mit »--next« getrennt sind. Die Regel in Listing 4 prüft folglich, ob der Kernel ein Paket zunächst komprimiert und anschließend verschlüsselt überträgt. Ohne die Option »--strict« würde bereits die Angabe eines Elements der Policy genügen, um auf die komplette geschachtelte Policy zuzutreffen. Bei »--strict« muss die Regel dagegen alle Teil-Policies definieren.
01 iptables -A FORWARD -m policy --dir out --strict --proto ipcomp --next --proto esp -j ACCEPT
|
Alles in allem erlaubt das Policy-Match genaueres und besseres Filtern als die alten virtuellen Netzwerkkarten. Hier konnte IPtables nur prüfen, ob Freeswan die Pakete irgendwie verarbeitet hat. Ob ESP die Übertragung schützt und zu welchem Tunnelendpunkt das verschlüsselte Paket fließt, konnte die Firewall nicht prüfen und musste sich auf Freeswan verlassen.
| 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)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
