Ein Modell für Iptables bei OpenWrt
Graphische Oberflächen haben manchmal Vorteile, vor allem, wenn man den Umgang mit einem Programm erst erlernen muss, und sich noch nicht so gut damit auskennt. Je nach Ausführung können sie auch fast so effizient wie die Kommandozeile oder Konfiguration via Textdateien sein. Allerdings verhindern sie oft ein tieferes Verstehen des Programms, wenn sie das zugrunde liegende Modell nicht adäquat abbilden.
Wenn man keine geeigneten Informationen über das Programm findet, muss man sich eben selbst auf den Weg machen und sich ein Modell des Programms erarbeiten und den Zusammenhang zwischen graphischer Oberfläche des Programms und Modell herstellen.
Genau das habe ich für die Konfiguration der Paketfilter-Firewall von OpenWrt mit der Weboberfläche LuCI getan und hier berichte ich, was ich dabei herausgefunden habe. Objekt der Untersuchung war OpenWrt Backfire 10.3.1 mit LuCI 0.10. Bei anderen Versionen werden die Ergebnisse vielleicht nicht mehr ganz stimmen, aber die Vorgehensweise kann vermutlich beibehalten werden.
Herangehen
Als erstes habe ich versucht, mir die Struktur der Paketfilterregeln vertraut zu machen. Dazu habe ich mir mit einem Script, welches ich in einem älteren Artikel bereits vorgestellt hatte, sowie dem Programm dot aus dem GraphViz Paket eine Visualisierung der Regelketten erstellt.
Zur Erinnerung noch einmal die Visualisierung der Paketfilterregeln der Tabelle filter aus diesem Artikel:
Bei dieser Visualisierung habe ich die Regeln als Liste bei den Konten
für die jeweilige Kette angezeigt, wodurch der genaue
Entscheidungsablauf verfolgt werden kann. Es sind keine wichtigen
Informationen aus der zugrunde liegenden Ausgabe von iptables-save
verloren gegangen. Dementsprechend ist das Bild recht komplex und
wohl am übersichtlichsten ausgedruckt auf großem Papier. Wegen der
Komplexität und vor allem auch, weil zwar einerseits alle
Regelketten für alle Zonen aufgeführt sind, andererseits nicht alle
möglichen Verbindungen zwischen Regelketten aufgeführt sind, eignet sich
diese Darstellung zwar als Visualisierung und Verständnishilfe für eine
konkrete Firewallkonfiguration, nicht jedoch als allgemeines Modell.
Immerhin ist es ein Anfang, von dem aus man weitergehen kann.
Anschließend habe ich die verschiedenen Einstellungen im Webinterface
durchprobiert und die Änderungen in der Ausgabe von iptables-save
dabei beobachtet. Dazu hatte ich OpenWrt mit ext2fs installiert und
dieses read-only eingehängt, so dass die Änderungen zwar
ausgeführt und
mit iptables-save sichtbar wurden, anschließend aber einfach im
Webinterface zurückgenommen werden konnten. Über eine SSH-Sitzung war
ich gleichzeitig an dem Gerät angemeldet und hatte mir gleich am Anfang
eine Referenzausgabe angelegt:
# mkdir /tmp/iptables
# iptables-save > /tmp/iptables/first
Nun konnte ich jede einzelne Änderung sehr leicht mit zwei Befehlen verfolgen:
# iptables-save > /tmp/iptables/second
# diff -u /tmp/iptables/*
Das Modell
Damit konnte ich den Einfluss der einzelnen Einstellungen in LuCI auf die Regeln sehr differenziert beobachten und mit dem gewonnenen Wissen bin ich zu folgendem Modell für die Tabelle filter gekommen:
In diesem Bild steht das Teilwort bereich in den Namen der
Regelketten für eine in LuCI definierte Zone. Das heißt, wenn ich in der
Firewall die Zonen lan und wan definiert habe, gibt es die
Regelketten zone_lan, zone_wan, zone_lan_ACCEPT,
zone_wan_ACCEPT, zone_lan_DROP, zone_wan_DROP und so weiter.
Kanten mit durchgehenden Linien im Modell stehen für feste Sprungziele. Kanten mit gestrichelten Linien stehen für Sprungziele, die je nach den Einstellungen im Webinterface auftreten können oder nicht.
Ein Sprung aus einer Zonenkette in eine andere, kann, je nach
Einstellung in LuCI zwischen verschiedenen Ketten erfolgen. So gibt es
zum Beispiel einen Sprung aus der Regelkette zone_lan_forward in die
Kette zone_wan_ACCEPT, wenn im Webinterface Datenverkehr aus der Zone
lan in die Zone wan zugelassen ist.
Der Sprung aus der Kette INPUT zur Kette syn_flood ist abhängig davon,
ob in den allgemeinen Einstellungen Enable SYN-flood protection markiert
wurde oder nicht.
Schließlich muss zu diesem vereinfachten Modell noch angemerkt werden, dass hier aus der Darstellung nicht auf die Reihenfolge der Sprünge zwischen den Zonen geschlossen werden kann. Das bleibt der detaillierten Visualisierung vorbehalten.
Das Modell für die Tabelle nat ist etwas einfacher:
Der Sprung aus der Kette zone_bereich_nat zu MASQUERADE wird durch
Markieren von Masquerading in den Zoneneinstellungen aktiviert.
Die Ketten nat_reflection_in und nat_reflection_out werden bei
Weiterleitungen (Redirection) von externen Adressen/Ports auf interne
Rechner verwendet, damit dieselbe Kombination von Adresse/Port extern
wie intern funktioniert. Näheres dazu in der detaillierten Beschreibung
der Konfiguration in einem Folgeartikel.
Noch einfacher sind die Modelle für raw
und mangle.
Der Sprung von FORWARD zu zone_bereich_MSSFIX ist abhängig davon, ob für
die betreffende Zone MSS clamping in den Zoneneinstellungen markiert wurde,
oder nicht.
Konfiguration mit LuCI
Wie die Konfiguration der Iptables-Firewall bei OpenWrt mit LuCI mit diesem Modell zusammenpasst, bleibt einem späteren Artikel vorbehalten.
Updates
20150123: Buch zu Paketfilter bei OpenWrt
Ich plane im Moment die Informationen zum Paketfilter von OpenWrt in einem Buch zusammen zu fassen. Dieses soll zunächst bei Leanpub herauskommen. Dafür benötige ich Feedback, ob daran interesse besteht.
20170314: Das Buch ist veröffentlicht.
Die Ebook-Versionen gibt es unter anderem bei Leanpub, das Paperback bei CreateSpace.
Posted 2012-02-02