AA_mesh_sxc1128879_SachinGhodke.jpg

© Sachin Ghodke, sxc.hu

Feines Sieb

Iptables-Grundlagen für Desktop-Nutzer

10.01.2013 Nicht jeder Linux-Desktop braucht eine Firewall. Mit grafischen Werkzeugen lässt sie sich aber bei Bedarf im Handumdrehen einrichten.

Canonical liefert den Ubuntu-Desktop bekanntlich ohne Firewall aus. Das verunsichert gerade Ein- und Umsteiger, bringen doch OpenSuse und Fedora sehr wohl eine vorkonfigurierte Firewall mit. Dabei handelt es sich um den Paketfilter Iptables, der sogar einen festen Bestandteil des Kernels bildet.

Woher rührt diese Diskrepanz? Warum konfiguriert Ubuntu die Firewall nicht, wenn der Kernel sie doch schon mitbringt? Macht das Fehlen einer Firewall den Ubuntu-Desktop unsicherer als OpenSuse und Fedora? Diesen Fragen gehen wir im Folgenden nach. Außerdem zeigen wir, wie Iptables im Grundsatz funktioniert, und stellen komfortable Frontends zum Konfigurieren der Firewall vor.

Desktop-Firewalls

Bevor Sie Energie in das Installieren einer Desktop-Firewall stecken, sollten Sie erst einmal darüber nachdenken, warum beispielsweise Ubuntu per Default überhaupt keine Firewall installiert – und das, obwohl Canonicals Distribution inzwischen in vielen Unternehmen als Desktop zum Einsatz kommt. Irritationen bei Anwendern, insbesondere bei Windows-Umsteigern, rühren meist daher, dass der im Windows-Umfeld gebrauchte Begriff "Personal Firewall" etwas völlig Anderes meint, als eine auf Iptables basierende Desktop-Firewall unter Linux.

Eine Personal-Firewall unter Windows kümmert sich vor allem um Anwendungen: Sie kontrolliert, welche Programmteile oder Prozesse eine Verbindung ins Netz herstellen dürfen ("Application Level Gateway"), und kann außerdem Pakete auf Basis Ihres Inhalts verwerfen (Content-Filter). Unter Linux dagegen meint der Begriff "Firewall" tatsächlich nur einen Paketfilter. Ob der Sinn macht oder nicht, hängt primär von zwei Kriterien ab: Ob sich der betreffende PC im Rahmen seiner Rolle im lokalen Netz überhaupt aus dem Internet erreichen lässt, und ob er aus dem LAN heraus Dienste nach außen anbietet.

Canonical hat Ubuntu in seiner Produktphilosophie als Desktop-Betriebssystem konzipiert, das als solches hinter einem NAT-Router um Einsatz kommt. Bei einer solchen Position innerhalb der eigenen Netzstruktur ist eine Firewall tatsächlich überflüssig, da ein Host hinter einem NAT-Router keine öffentliche IP-Adresse besitzt und sich daher nicht aus dem Internet erreichen lässt. Verbindungen ins Internet baut ein Desktop-System ausschließlich über den Router auf.

Um Dienste von einem solchen Host aus im Internet zur Verfügung zu stellen, müssen Sie auf dem Router Port-Forwarding für den gewünschten Port und mit dem betroffenen Host als Ziel konfigurieren. In eine solchen Szenario kommt demnach dem NAT-Router die eigentliche Aufgabe des Paketfilters zu: Die Einschätzung Canonicals, bei einem Desktop-Betriebssystem hinter einem NAT-Router sei eine Firewall überflüssig, erweist sich insofern also als richtig.

Das sieht sogar das ansonsten recht pingelige BSI so: In seinem jährlich aktualisierten Sicherheitsleitfaden, den es angesichts der Bedeutung von Ubuntu als Desktop inzwischen auch in einer Linux-Version [1] gibt, sieht es keinerlei Anlass zum Einsatz einer Desktop-Firewall unter Ubuntu.

Das BSI bezieht sich bei seiner Einschätzung explizit auf den Umstand, dass Ubuntu in seiner Standard-Konfiguration "keine Kommunikationsschnittstellen (keine Ports) nach außen anbietet, die für Angriffe genutzt werden könnten". Daher sei das Verwenden einer Firewall unter Ubuntu nicht erforderlich.

Allerdings betont auch das BSI die Notwendigkeit des Absicherns von zusätzlich installierten Programmen, die dennoch Ports nach außen öffnen. Es empfiehlt dazu den Einsatz des Firewall-Werkzeugs Firestarter [2], das sich problemlos über das Ubuntu-Software-Center nachinstallieren lässt.

Sicher ohne Firewall?

Folgt man Canonicals Argumentation, drängt sich die Frage auf, warum dann beispielsweise Fedora und OpenSuse eine eigene, grafisch administrierbare Firewall an Bord haben – bei Fedora ist sie sogar standardmäßig aktiv und sehr restriktiv eingestellt.

Das liegt bei Red Hats Community-Distribution zweifelsohne daran, dass diese sich keineswegs als reines Desktop-System versteht, sondern als Spielwiese der Red-Hat-Entwickler dient: Sie bauen in Fedora aktuelle Server- und Cloud-Funktionen ein, die später in Red Hat Enterprise Linux zum Einsatz komme sollen. Bei OpenSuse liegen die Gründe ähnlich, auch wenn hier die Beziehungen zu Suse Linux Enterprise nicht ganz so direkt ausfallen.

Bei Ubuntu kommt dagegen kommen bei den per Default installierten Software-Paketen keine Serverdienste zum Einsatz. Werden dennoch Client/Server-Anwendungen installiert, konfiguriert Ubuntu diese so, dass sie sich zunächst nur lokal über das Loopback-Interface lo erreichen lassen. Um sie von außen oder im lokalen Netz erreichbar zu machen, müssen Sie die Dienste in den jeweiligen Konfigurationsdateien für andere Schnittstellen, Hosts und Netze explizit freischalten.

Hier liegt tatsächlich ein entscheidender Unterschied zu Fedora oder OpenSuse vor, die Server-Dienst beim Installieren in der Regel so konfigurieren, dass diese sich aus dem lokalen Netz erreichen lassen. Bei einer frischen Desktop-Installation von Ubuntu ist dagegen tatsächlich kein einziger Port nach außen geöffnet und der Rechner damit unangreifbar. Allerdings bezieht sich der Begriff "unangreifbar" ausschließlich auf solche Angriffsszenarien, vor denen ein Paketfilter rein prinzipiell überhaupt schützen kann.

Ausnahmen

Jenseits von Canonicals Argumentation gibt es aber dennoch gelegentlich gute Gründe für den Einsatz einer Desktop-Firewall – auch wenn der Rechner keine Dienste nach außen anbietet.

Zwar trifft Canonicals Einschätzung zu, dass die weitaus meisten Desktop-Systeme mit Ubuntu hinter einem NAT-Router zum Einsatz kommen. Es gibt aber auch Linux-Rechnern, die die Verbindung zum Internet direkt über ein DSL-Modem herstellen. In den heimischen vier Wänden sterben inzwischen solche Konfigurationen zunehmend aus, doch das Problem betrifft auch jedes Notebook mit UMTS-Surfstick.

Schon aus diesem Grund ist der Einsatz einer Desktop-Firewall unter Linux keineswegs immer überflüssig, was erklärt, warum es eine Vielzahl brauchbarer Frontends gibt.

Da wir in der Vergangenheit wiederholt solche Werkzeuge vorgestellt haben (siehe Kasten "Iptables-Frontends"), wollen wir im Folgenden weder weitere Tools aufspüren noch jedes bekannte Tool erneut im Detail beschreiben. Stattdessen stellen wir Ihnen die wichtigsten Iptables-Grundlagen vor – was Sie in die Lage versetzt, mit jedem GUI-Programm dieser Art zurecht zu kommen.

Iptables-Frontends

Linux User hat in den vergangenen Jahren wiederholt verschiedene GUI-Oberflächen für Iptables vorgestellt [5]. Ubuntu favorisiert für diesen Zweck die beiden GTK-basierten Programme Firestarter und Gufw. Firestarter [6], das sich auch in den Paketquellen anderer Distributionen findet, liegt seit 2005 in der stabilen Version 1.03 vor und wird offenbar kaum noch weiterentwickelt. Gufw [7], wie Firestarter im Universe-Repository beheimatet, steuert direkt Ubuntus konsolenbasiertes Firewall-Tool Ufw an. Nutzer anderer Distributionen greifen sehr gern zum von Vadim Kurland entwickelten Firewall Builder [8], der sich mit seiner auf Qt basierenden Oberfläche gut in den KDE-Desktop einfügt. Fedora und OpenSuse haben mit System-config-firewall und dem YaST-Modul Firewall eigene grafische Konfigurationswerkzeuge im Gepäck.

Iptables

Um den kernelbasierten Paketfilter nutzen zu können, muss das Paket iptables eingerichtet sein. Es enthält das gleichnamige Dienstprogramm zur Steuerung der Netfilter-Architektur [3] im Linux-Kernel. Sie starten den Paketfilter als Root mit dem Kommando service iptables start (bei Ubuntu) beziehungsweise systemctl start iptables.service (bei Fedora und anderen auf Systemd basierenden Distributionen).

Das Einschalten bleibt jedoch vorerst ohne Effekt, da Sie noch keine Filterregeln definiert haben. Die übergeben Sie auf der Kommandozeile mit Befehlen der Struktur iptables Option an den Kernel. Solche Regeln gehen allerdings beim Ausschalten des Computers wieder verloren. Um sie dauerhaft zu nutzen, müssen Sie sie in ein Shell-Skript verpacken (zum Beispiel fwstart.sh), das Sie nach dem Systemstart entweder manuell aufrufen oder fest in das Init-System [4] der verwendeten Distribution einbinden (SysV-Init, Systemd, Upstart) einbauen.

Im Kontext von Iptables sind drei Konzepte von zentraler Bedeutung: Tabellen ("tables"), Ketten ("chains") und Regeln ("rules"). Dabei enthält eine Tabelle jeweils mehrere Ketten, jede Kette wiederum mehrere Regeln. Anhand der Regeln entscheidet Iptables, was mit einem ankommenden oder abgehenden Datenpaket passieren soll.

Jede Regel besteht aus einen Satz von Parametern, anhand derer Iptables prüft, ob die Regel für ein zu behandelndes IP-Paket greift. Trifft keiner der Parameter zu, wird das Paket an die nächste Regel der Kette weitergereicht. Anderenfalls verweist die Regel das Paket entweder an ein neues Ziel ("target") oder wendet eine Methode ("policy") auf das Paket an. Die wichtigsten davon fasst die Tabelle "Iptables-Policies" zusammen.

Iptables-Policies

Policy Aktion
ACCEPT Das Paket darf passieren.
DROP Verwirft das Paket ohne Nachricht an den Absender.
MASQUERADE Ersetzt die Quelladresse des Pakets durch die IP-Adresse der Schnittstelle, auf dem es den aktuellen Host Rechner verlässt.
REDIRECT Akzeptiert das Paket, ändert die Ziel-Adresse aber so dass es an den lokalen Host gesendet wird.
REJECT Verwirft das Paket und sendet ein Fehlerpaket zur Bestätigung.

Eine Kette besteht aus einer Sammlung von Regeln. Da Iptables ein Paket bei Nichtzutreffen der Parameter einer Regel an die nächste Regel der Kette weiterreicht, kann es in jeder Kette durchaus mehrere Regeln geben, die ein Paket blockieren oder passieren lassen. Weil der Paketfilter die Regeln einer Kette sequenziell abarbeitet, gilt die Bearbeitung einer Kette als beendet, sobald die erste Regel zutrifft. Iptables kennt fünf Standardketten (siehe Tabelle "Standard-Chains"), wobei einige dieser Ketten stets von allen Paketen durchlaufen werden, andere nur in Abhängigkeit des Ziels eines Pakets.

Standard-Chains

Name betrifft
PREROUTING Alle Pakete (vor jeder Routing-Entscheidung)
FORWARD Pakete, die zu einer anderen Netzwerkschnittstelle weitergeleitet werden (keine Pakete für lokale Dienste)
INPUT Eingehende Pakete, die einen Dienst auf dem lokalen Rechner ansprechen
OUTPUT Ausgehende Pakete von lokalen Diensten
POSTROUTING Alle Pakete (am Ende der Verarbeitung)

Die Ketten INPUT, FORWARD und OUTPUT nutzen jeweils einer Standardregel, die dann zur Anwendung kommt, wenn keine der in der jeweiligen Kette vorhandenen Regeln zutrifft oder wenn es gar keine Regel gibt. In den Ketten PREROUTING und POSTROUTING lassen sich Pakete zwar manipulieren, jedoch nicht ausfiltern. Zusätzlich zu den fünf Standard-Chains dürfen Sie auch benutzerdefinierte Ketten erstellen.

Die Art der Verarbeitung von Netzwerkpaketen klassifizieren drei verschiedene Tabellen namens mangle,nat und filter. Iptables prüft nur in der Tabelle filter alle ankommenden Pakete, um festzustellen, ob es ein Paket durchlassen oder blockieren soll. Iptables kann aber mehr, als nur Pakete zu filtern: Die Tabelle mangle ermöglicht es dem Kernel, Daten im Header des Pakets zu verändern. Mithilfe von nat kann Iptables interne und externe IP-Adressen übersetzen (NAT, Network Adress Translation), bei Routern die wichtigste Funktion.

Jede der genannten Tabellen enthält eine bestimmte Auswahl an Ketten. Die Tabelle filter (der eigentliche Paketfilter) enthält nur die Ketten FORWARD, INPUT und OUTPUT – das genügt für das Umsetzen einer einfachen Firewall bereits. Der Vollständigkeit halber sei noch erwähnt, dass die Tabelle nat die Ket ten PREROUTING, OUTPUT und POSTROUTING enthält, die Tabelle mangle alle Ketten.

Iptables ausprobieren

Beschränkt man sich auf die Basis-Funktion einer Firewall, könnte eine Minimalversion einer Desktop-Firewall in Iptable-Syntax also etwa so aussehen wie in Listing 1. Das Beispiel erlaubt ausschließlich ausgehende Kommunikation über das HTTP-Protokoll auf den Zielport 80. Mit dieser Konfiguration können Sie daher nicht auf SSL-geschützten Webseiten surfen. Die letzten beiden ESTABLISHED-Regeln sind für eine SPI-Firewall sehr wichtig und erlauben das Durchlassen sämtlicher Pakete bereits bestehender Verbindungen.

Listing 1

# F für 'flush' löscht alle möglicherweise bestehenden Regeln.
  iptables -F
# P steht für 'Policy'.
# Alle Pakete verwerfen, die via INPUT eingehen oder
# via OUTPUT oder FORWARD hinaus wollen
  iptables -P INPUT DROP
  iptables -P OUTPUT DROP
  iptables -P FORWARD DROP
# erlaubt (A='Accept') alle eingehenden (INPUT) und ausgehenden (OUTPUT)
# Pakete auf dem Interface (-i) lo (Localhost)
  iptables -A INPUT -i lo -j ACCEPT
  iptables -A OUTPUT -o lo -j ACCEPT
# bis hier ist alles verboten, außer Verbindungen von und zu Localhost
# erlaubt auf den Quell-Ports 1024 bis 65535 (-j ACCEPT) ausgehende (OUTPUT)
# HTTP-Verbindungen (port 80) für das TCP-Protokoll (-p tcp)
  iptables -A OUTPUT -o eth0 -p tcp --dport 80 --sport 1024:65535 -j ACCEPT
# erlaubt für bereits etablierte Verbindungen ein- und ausgehende Pakete
  iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
  iptables -A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Iptables-Frontends

Mit diesen Grundlagen kommen Sie mit jedem grafischen Iptables-Frontend zurechtkommen und können sich ihre Regeln nach Bedarf "zurechtklicken": Diese Werkzeuge tun nichts anderes, als die von Ihnen in der GUI zusammengestellten Regeln in eine Iptables-Konfigurationsdatei zu schreiben, die Sie mit jedem Editor überprüfen können.

Im folgenden Beispiel verwenden wir Fedora und dessen grafisches Iptables-Frontend System-config-firewall. Starten Sie das Werkzeug – es benötigt wie jedes Iptables-Werkzeug Root-Rechte – dürfte es für Sie jetzt kein kein Problem mehr sein, die Firewall mit den Schaltflächen Aktivieren beziehungsweise Deaktivieren in der Symbolleiste ein- oder auszuschalten sowie im Bereich Trusted Dienste durch einfaches Setzen von Häkchen die benötigen Ports und Dienste freizugeben (Abbildung 1).

Abbildung 1

Abbildung 1: So sperren Sie sukzessive per Mausklick Dienste auf einem Fedora-Rechner aus.

Um die oben genannten Informationen zu überprüfen, entfernen Sie exemplarisch sämtliche Regeln mit Ausnahme der letzten (WWW(HTTP) 80/tcp) und klicken dann auf Anwenden. Das Tool weist Sie noch einmal darauf hin, dass für das Funktionieren der Firewall das Paket Iptables installiert sein muss (Abbildung 2).

Abbildung 2

Abbildung 2: Fedoras System-config-firewall setzt das Installieren von Iptables voraus.

Nun werfen Sie zur Überprüfung mit einem beliebigen Editor einen Blick in die Datei /etc/sysconfig/iptables (Abbildung 3). Das Ergebnis entspricht in seiner Einfachheit in etwa der Konfiguration, die wir oben manuell erarbeitet haben. Stoppen Sie die Firewall über das GUI oder mittels systemctl stop iptables.service, leert sich die Datei sofort.

Abbildung 3

Abbildung 3: Das GUI-Tool erzeugt die gleiche Konfiguration wie unser manuell erstellten Iptables-Regelwerk.

Die hier genannten Namen und Pfade gelten für Fedora und das Tool System-config-firewall. Andere Firewall-Frontends und andere Distributionen verwenden andere Dateien, das ändert aber nichts am Prinzip. Exemplarisch konfigurieren wir das gleiche Minimal-Beispiel unter Ubuntu mit Firestarter. Der verlangt erst das Abarbeiten eines Assistenten, indem Sie unter anderem das zu überwachende Interface wählen (Abbildung 4). Diesen Assistenten können Sie über das Menü Firewall jederzeit wieder aufrufen.

Abbildung 4

Abbildung 4: Der Firestarter bringt einen Konfigurationsassistenten mit.

Sie können jedes Iptables-Regelwerk im Whitelist- (restriktiv) oder Blacklist-Verfahren (liberal) konfigurieren. Unser Beispiel folgt der gängigen Methode, zunächst jegliche Kommunikation zu verbieten, alle Pakete zu verwerfen und danach sukzessive die tatsächlich benötigten Dienste nebst Ports zu öffnen.

In Firestarter wechseln Sie dazu zum Reiter Richtlinie und wählen zunächst im Auswahlfeld Bearbeiten der den Eintrag Richtlinie für ausgehenden Verkehr. Danach aktivieren Sie per Radio-Button die Option Einschränkende Voreinstellung, Whitelist-Verkehr, womit der Bereich direkt darunter seine Bezeichnung zu Verbindungen zulassen zu Rechner wechselt.

Hier wählen Sie per Kontextmenü (rechte Maustaste) den Eintrag Regel hinzufügen und füllen nach Bedarf das Eingabefeld Verbindungen zulassen zu aus, indem Sie die gewünschte IP-, Rechner- oder Netzwerkadresse eingeben. Danach fügen Sie im dritten Bereich Erlaube Dienst ganz unten ebenfalls per Kontextmenü eine weitere neue Regel ein. Den Dienstnamen (HTTP) wählen Sie aus der Listenauswahl, was den Standardport (80) automatisch setzt (Abbildung 5). Mit einem Klick auf Hinzufügen haben Sie dann nominell das Gleiche erreicht wie beim Fedora-Tool.

Abbildung 5

Abbildung 5: Das manuelle Erstellen einer neuen Firestarter-Regel.

Mit den bisherigen Erkenntnissen sollte es für Sie kein Problem sein, Firestarter, System-config-firewall, Firewall Builder oder andere entsprechende GUI-Tools sukzessive weiter mit eigenen Regeln zu bestücken.

Fazit

Während sogenannte Personal Firewalls unter Windows durchaus Ihren Zweck erfüllen, sind Desktop-Firewalls unter Linux nicht mehr, als eine Konfigurationshilfe für den Kernel-Paketfilter. Der filtert allerdings vereinfacht ausgedrückt lediglich die aus dem Internet ankommenden beziehungsweise dorthin gesendeten Datenpakete. Er arbeitet aber prinzipbedingt nur auf Paket-Ebene, schaut also nicht in die eigentlichen Daten hinein, wie die Content-Filter der einschlägigen Windows-Security-Suiten.

Unabhängig davon macht ein Paketfilter aber nur dann Sinn, wenn die Rolle des betreffenden Hosts im Netzwerk sowie dessen Konfiguration und Ausstattung in Bezug auf Serverdienste diesen überhaupt angreifbar macht. Linux-Desktops hinter einem NAT-Router brauchen in aller Regel keine Firewall. Für den Fall der Fälle sollten die im Betrag vermittelten Kenntnisse aber ausreichen, auch einen einfachen Server oder ein Notebook mit UMTS-Modem auf Paket-Ebene abzusichern.

Das Aufsetzen eines Paketfilters stellt allerdings nur ein Puzzleteil einer übergreifenden Sicherheitsstrategie dar und darf nicht dazu verführen, andere Aspekte zu vernachlässigen oder den gesunden Menschenverstand abzuschalten: Kann er über andere verwundbare Stellen eindringen, ist jeder ambitionierte Angreifer in der Lage, den Paketfilter binnen weniger Minuten zu umgehen, auszutricksen oder zu durchtunneln. 

Glossar

BSI

Bundesamt für Sicherheit in der Informationstechnik. Diese für Fragen der IT-Sicherheit zuständige Bundesbehörde untersteht dem Innenministerium. Sie gibt unter anderem Empfehlungen für Standardschutzmaßnahmen an typischen IT-Systemen heraus.

Netfilter

Software-Schicht innerhalb des Kernels, die beim Senden und Empfangen von Netzwerkpaketen aufgerufen wird. Sie leitet gegebenenfalls den Aufruf weiterer Module zur Behandlung der Pakete ein, wie etwa Iptables.

SPI

Stateful Packet Inspection. Die zustandsorientierte Paketprüfung bezieht den Status der Verbindung zur Gegenstelle in die Entscheidung zum Akzeptieren oder Verwerfen eines Pakets mit ein.

Infos

[1] BSI-Sicherheitsleitfaden Ubuntu: http://tinyurl.com/lu0213-bsi-ubuntu

[2] Firestarter: http://www.fs-security.com

[3] Netfilter-Projekt: http://netfilter.org

[4] Init-Systeme: Tim Schürmann, "Staffellauf", LU 11/2010, S. 86, http://www.linux-community.de/22207

[5] Firewall-GUIs im Vergleich: Jörg Harmuth, "Feurige Künste", LU 03/2006, S. 54, http://www.linux-community.de/10356

[6] Workshop Firestarter: Markus Nasarek, "Brandmelder", LU 01/2007, S. 32, http://www.linux-community.de/11962

[7] Workshop Gufw: Kristian Kissling, "Mauern mit Ubuntu", LU 07/2009, S. 78, http://www.linux-community.de/22939

[8] Workshop Firewall Builder: Florian Effenberger, "Aufbauhilfe", LU 05/2012, S. 70, http://www.linux-community.de/22939

Tip a friend    Druckansicht beenden Bookmark and Share
Kommentare