Unsichtbarer Schutz mit Linux: Firewall auf Bridge-Ebene
Zugbrücke
von Ralf Spenneberg
Erschienen im Linux-Magazin
2004/12
Firewalls sind meist als Router implementiert, aber das muss nicht sein. Paketfilter im Bridge-Betrieb haben einige Vorteile: Sie lassen sich nachträglich in ein Netzwerk einfügen, ohne die Konfiguration der Netzkomponenten zu ändern. Unter Linux sorgen drei Befehle für flexibles Bridgewalling.
Linux ist als stabile Firewall-Plattform fest etabliert. Mit Netfilter/IPtables[1] verfügt der Kernel über einen mächtigen Paketfilter. In der Regel kommt Netfilter auf einem Router zum Einsatz, es trennt in dieser klassischen Konfiguration zwei oder mehr Subnetze. Wer nachträglich in ein gewachsenes Netz eine Firewall einfügen will, muss daher dessen Infrastruktur entsprechend anpassen. Der Aufwand dafür kann enorm sein, da mit den geänderten IP-Adressen auch die Zugriffskontrolle von intern genutzten Diensten anzupassen ist.
Eine Bridge (besser bekannt unter dem Begriff Switch) lässt sich dagegen problemlos einfügen. Sie arbeitet auf OSI-Schicht 2 (Ethernet) und beachtet im Normalfall nur MAC-Adressen und nicht die IP-Nummern (siehe Kasten "Brückenbau"). Unter Linux lässt sich diese Eigenschaft trickreich nutzen, um die Firewall transparent in ein Netz einzufügen. Als Firewall wertet die Bridge dann sehr wohl auch höhere Protokollschichten aus (IP-Adressen, TCP-Ports). Davon bemerken die beteiligten Hosts jedoch nichts, wenn sie nur erlaubte Pakete versenden.
|
Bei einer Bridge (auch Switch genannt) handelt es sich um ein Netzwerkgerät, das gezieltes Forwarding von Netzwerkpaketen auf OSI-Layer 2 beherrscht. Hierzu lernt die Bridge sämtliche im lokalen Netz verwendeten MAC-Adressen und merkt sich, über welchen Anschluss (Interface, Port) sie den zugehörigen Rechner erreicht. Erhält die Bridge ein Paket, dessen Ziel-MAC-Adresse sie kennt, leitet sie das Paket nur an das passende Interface weiter und vermeidet damit überflüssige Übertragungen. Wenn die Bridge die Ziel-MAC-Adresse nicht kennt, sendet sie das Paket über jeden Anschluss.
MAC-Adressen lernen und vergessen
Alle von der Bridge gelernten MAC-Adressen zeigt der Befehl »brctl showmacs br0« an. Er listet die Einträge tabellarisch: Die erste Spalte enthält die Port-Nummer, über die ein Rechner angeschlossen ist, die zweite Spalte nennt dessen MAC-Adresse. Weitere Spalten enthalten zusätzliche Verwaltungsinformationen.
Um auf Änderungen zu reagieren, zum Beispiel wenn ein Rechner eine neue Netzwerkkarte erhält oder an anderer Stelle angeschlossen wird, verwirft die Bridge alte MAC-Adressen aus ihrer Forwarding-Datenbank. Wie lange eine MAC unbenutzt sein muss, bevor die Bridge sie vergisst, ist mit »brctl setageingtime br0 Sekunden« einstellbar.
Der interne Verwaltungsaufwand wäre unnötig hoch, wenn die Bridge jede veraltete MAC-Adresse sofort entfernen würde. Sie erklärt die Adresse daher zunächst für ungültig und entfernt in regelmäßigen Abständen alle ungültigen Einträge (Garbage Collector Interval). Dieser Abstand lässt sich mit dem Befehl »brctl setgcint br0 Sekunden« einstellen. Der Defaultwert ist 0 Sekunden.
Spanning Tree Protokoll
Moderne Switches erlauben mit dem Spanning Tree Protocol eine hochverfügbare Konfiguration. Wenn zwei oder mehr Switches zwei Teilnetze verbinden, ermitteln sie alle verfügbaren Wege von einem Netzwerk zu jedem anderen. Nach der Auswahl eines Root-Switch bestimmt dieser die aktiven und nicht aktiven Pfade im Netzwerk und übermittelt die Information an alle beteiligten Switches.
Die Switches blockieren alle nicht aktiven Pfade und Interfaces und verhindern so, dass ein Paket doppelt (auf zwei unterschiedlichen Wegen) in sein Zielnetzwerk gelangt (Abbildung 4). Fällt ein Switch aus, ermitteln die verbleibenden alle noch verfügbaren Pfade und umgehen das fehlerhafte Gerät.
Funktionstüchtig
Linux unterstützt das Spanning-Tree-Protokoll, allerdings muss es der Admin erst per »brctl stp br0 on« aktivieren. Die Priorität der Bridge lässt sich im Bereich von 0 bis 65535 frei definieren: »brctl setbridgeprio br0 Priorität«. Die Bridge mit der kleinsten Priorität übernimmt die Root-Funktion.
Bridges überwachen gegenseitig ihre Funktionstüchtigkeit, indem sie sich in regelmäßigen Abständen gegenseitig eine Hello-Nachricht zusenden. Der Abstand dieser Meldungen wird mit »brctl sethello br0 Sekunden« festgelegt. Der Befehl »brctl setmaxage br0 Sekunden« bestimmt, wie lange die anderen Bridges warten sollen, wenn die Hello-Meldungen ausbleiben. Nach der eingestellten Zeit geht das Bridge-Netzwerk davon aus, dass diese Bridge ausgefallen ist.
Neu angeschlossen darf eine Bridge erst nach einer Wartezeit damit beginnen, Pakete weiterzuleiten. In dieser Zeit muss sie prüfen, ob das STP-Protokoll im Netzwerk genutzt wird. Das Kommando »brctl setfd br0 Sekunden« ändert die Startverzögerung.
Auf einer filternden Bridge sollte das STP-Protokoll jedoch ganz deaktiviert sein: »brctl stp br0 off«. Die Firewall muss sich auf ihr Regelwerk verlassen und darf nicht durch gefälschte STP-Protokolle deaktivierbar sein.
|
Abbildung 4: Die beiden Bridges 1 und 2 verbinden die Netze A und B. Per STP legt die Bridge mit der niedrigsten Priorität fest, auf welchem Weg die Pakete von A und B kommen dürfen.
|
|
Kernelkonfiguration
Für den Linux-Kernel 2.4 haben Lennert Buytenhek und Bart de Schuymer ein Patch geschrieben, das die Firewall-Funktionalität im Bridge-Modus hinzufügt. Dieses Patch ist im Kernel 2.6 serienmäßig enthalten. Der Kernel muss lediglich richtig konfiguriert sein (siehe Abbildungen 1 und 2).
|
Abbildung 1: Um den Bridge-Modus im Kernel 2.6 zu aktivieren, muss unter »Networking Support« der Bereich »802.1d Ethernet Bridging« ausgewählt sein.
|
|
Abbildung 2: In der Netfilter-Kernelkonfiguration muss die Option »Bridged IP/ARP packets filtering« aktiviert sein, um Firewalling auf der Bridge zu erlauben.
|
Relevant sind in der Netfilter-Gruppe alle Optionen, die im Zusammenhang mit der Bridge stehen, zum Beispiel die ARPtables-Unterstützung »IP_NF_ARPTABLES«, »IP_NF_ARPFILTER« und »IP_NF_ARP_MANGLE«. Diese Funktionen dürfen als Module oder als fester Kernel-Bestandteil übersetzt werden. Wichtig ist außerdem die Unterstützung des Physdev-Match »IP_NF_MATCH_PHYSDEV«. Diese Option ist ab dem Kernel 2.6 erforderlich, um beim Filtern der Pakete auf der Bridge das physikalische Interface zu prüfen.
Userspace-Werkzeuge
Ist der neue Kernel erfolgreich übersetzt und installiert, fehlen nur noch die Userspace-Werkzeuge. Während das »iptables«-Programm meist vorhanden ist, sind auf vielen Distributionen die Kommandos »arptables« und »ebtables« eigens nachzuinstallieren. Wer einen aktuellen 2.6er Kernel auf einer älteren Linux-Distribution betreibt, muss eventuell noch eine aktuellere Version des »iptables«-Befehls aufspielen.
Um die Bridge zu konfigurieren, ist das Bridge-Utils-Paket erforderlich[4]. Moderne Distributionen enthalten es bereits. Darin findet sich der Befehl »brctl«, den normalerweise nur Root einsetzen darf. Der Aufruf »brctl addbr br0« erzeugt die Bridge mit dem Namen »br0«. Der Befehl »ip link show br0« bestätigt, dass die Bridge existiert. Da sie einen Namen trägt, ist es sogar möglich, mehrere virtuelle Bridges in einem Linux-Rechner zu betreiben.
Die Bridge muss als Nächstes wissen, für welche Ethernet-Netzwerkkarten sie zuständig ist. Dazu sind per »brctl« die Interfaces zur Bridge hinzuzufügen:
brctl addif br0 eth0
brctl addif br0 eth1
Die Netzwerkkarten sollten zu diesem Zeitpunkt noch nicht konfiguriert sein, also weder den Zustand »UP« aufweisen noch über eine eigene IP-Adresse verfügen. Aktiviert werden sie erst, wenn sie zur Bridge gehören:
ip link set eth0 up
ip link set eth1 up
ip link set br0 up
Die Bridge ist nun einsatzbereit, wie »ip link show« zeigt (Abbildung 3). Sie leitet Pakete weiter und pflegt ihren ARP-Cache. Der verzeichnet, welche MAC-Adressen sie über welches Interface erreicht (siehe Kasten "Brückenbau").
|
|
|
Option
|
Bedeutung
|
|
--physdev-in Name
|
Legt fest, über welchen Port der Bridge ein Paket gekommen
sein muss, damit diese Regel zutrifft.
|
|
--physdev-out Name
|
Legt fest, über welchen Port ein Paket die Bridge
verlassen muss, damit diese Regel zutrifft.
|
|
--physdev-is-in
|
Paket kam über ein Interface, das an einer Bridge
angeschlossen ist.
|
|
--physdev-is-out
|
Das Paket wird den Rechner über ein Interface verlassen,
das an einer Bridge angeschlossen ist.
|
|
--physdev-is-bridged
|
Das Paket durchläuft eine Bridge.
|
| 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.
|
Pascal Uhlmann,
31.03.2011 23:25