Das in bester Unix-Manier von vorneherein als Netzwerk- und Multiuser-Betriebssystem konzipierte Linux glänzt mit einer ganzen Reihe eingebauter Sicherheitsmechanismen. Wie sich diese Bordmittel zum Schutz des Rechners gegen unberechtigte Nutzung einsetzen lassen, haben wir im ersten Teil unseres Workshops gezeigt.
Doch selbst auf bestens gepflegten Systemen bleiben noch potentielle Eingangstüren offen: Dabei handelt es sich um die Ports jener Dienste, die der Rechner nach dem Willen seines Benutzers nach außen anbieten soll. Auch hier kann Linux mit eingebautem Werkzeug Abhilfe schaffen: Bereits seit Kernel 1.1 bringt das freie Unix auch Firewalling-Werkzeuge mit.
Einen umfassenden Überblick über die Möglichkeiten der bis Kernel 2.2 genutzten Ipchains zur sicheren Konfiguration von Servern bietet unsere Serie zum Thema Firewall unter Linux. An dieser Stelle wollen wir uns daher mit dem Einsatz der seit Kernel 2.3 eingeführten Iptables-Firewall auf dem Desktop beschäftigen. Als Basis für die Beispiele verwenden wir die aktuelle Red Hat Linux 7.1.
Iptables
Die Iptables-Architektur arbeitet mit einer im Gegensatz zum Vorgänger Ipchains wesentlich einfacheren Systemarchitektur. Der Kernel hält drei Listen von Filterregeln namens INPUT, OUTPUT und FORWARD vor. Man nennt sie auch Ketten, da sie jeweils aus einer Liste sequentiell abzuarbeitender Regeln bestehen.
Jede Regel bestimmt anhand des Paketheaders, was mit anfallenden Paketen zu geschehen hat. Entspricht der Paketheader nicht dem Regelkriterium, wird das Paket an die nächste Regel der Kette weitergereicht. Hat ein Paket die Kette ohne Zutreffen einer Regel bis zum Ende durchlaufen, greift die Policy der Kette. Sie wird ein solches nicht identifizierbares Paket im Regelfall verwerfen ("DROP" oder "REJECT").
Geht ein Paket an der Netzwerk-Schnittstelle ein, wertet der Kernel zunächst dessen Zieladresse aus (Routing-Entscheidung). Ist das Paket für den lokalen Rechner bestimmt, reicht er es an die INPUT-Kette weiter. Falls nicht, entscheidet die Forwarding-Konfiguration über das weitere Schicksal des Paketes. Bei aktivem Forwarding übernimmt die FORWARD-Kette die Weiterverarbeitung, anderenfalls wird das Paket verworfen.
Auch alle von Prozessen auf dem lokalen Rechner versendeten Pakete müssen die OUTPUT-Liste durchlaufen. Falls diese das Paket nicht ausfiltert, verlässt es anschließend den Rechner über die angeforderte Schnittstelle.
Implementation
Jede Regel in den Filterketten besteht aus zwei Komponenten: Die eine prüft, ob die Regel überhaupt auf das Paket anzuwenden ist ("matcht"). Die andere bestimmt, was in diesem Fall mit dem Paket zu geschehen hat. Beide Regelteile lassen sich über Kernelmodule flexibel konfigurieren - eine der wichtigsten Neuerungen von Iptables.
Im Fall von Red Hat 7.1 beispielsweise lagern die entsprechenden Shared Libraries im Verzeichnis /lib/iptables, insgesamt bringt das Betriebssystem 30 davon mit. Einige davon stellen nützliche Paket-Matches zur Verfügung, andere legen spezielle Aktionen für durch die Regel erfasste Pakete fest. Jedes Modul muss zunächst geladen und anschließend über Kommandozeilenoptionen für den jeweiligen Einsatzzweck angepasst werden.
Entsprechend umfangreich gestalten sich die Skripts, die eine typische Firewall-Konfiguration aufsetzen. Nun ist das manuelle Editieren seitenlanger Textdateien ohnehin nicht jedermanns Sache, zudem schleichen sich dabei nur allzu leicht Fehler ein. Gerade Linux-Einsteiger und Desktopnutzer geben daher meist nach einigen Versuchen klein bei und verzichten auf die Nutzung der Firewall.
Firewall Builder
Tatsächlich gibt es jedoch auch für Einsteiger und Mausverliebte keinen Grund, auf die Sicherheit einer Firewall zu verzichten. Im umfangreichen Fundus von Sourceforge.net findet sich ein Tool, mit dem nahezu jedermann auf einfache Weise eine Iptables-Konfiguration einrichten kann: Der modular aufgebaute Firewall Builder besteht aus einer komfortablen GUI -Komponente und Regelcompilern für Iptables- sowie Ipchains-Firewalls.
Zwar befindet er sich Firewall Builder offiziell noch in der Betaphase, zeigte jedoch beim Probeeinsatz bei tecChannel.de bislang keine gravierenden Schwächen. Die Entwickler bieten das Werkzeug sowohl in Binärvarianten für Red Hat und SuSE, als auch im Sourcecode an. Für unseren Workshop verwenden wir die Red-Hat-Variante von Konfigurationsprogramm und Iptables-Compiler. Beide installieren wir auf einem Rechner unter Red Hat Linux 7.1 Deluxe.
Rahmenbedingungen
Als Aufgabenstellung wählen wir uns die Absicherung eines typischen Netzwerk-Clients. Die Maschine soll also Windows-Shares sowohl bereitstellen als auch nutzen. Zudem wollen wir vollen Internet-Zugriff ermöglichen: Neben Web- und Mailzugriff soll der Benutzer also auch Usenet-News lesen und FTP -Zugriffe vornehmen können.
Auch einfache Managementaufgaben stehen mit im Pflichtenheft: So muss sich die geschützte Maschine von lokalen Überwachungsrechnern aus per ICMP und SNMP erreichen lassen, der Benutzer soll grundlegende Diagnosetools wie ping und traceroute einsetzen können.
"They can't crack what they can't find", so lautet die Goldene Regel der Rechnersicherheit. Daran wollen wir uns halten und den abgesicherten Rechner außer für seine dedizierten Kommunikationspartner unsichtbar machen.
Basiskonfiguration
Bevor wir den Firewall Builder das erste Mal starten, legen wir in /etc als künftiges Arbeitsverzeichnis für die Applikation das Directory /etc/fwbuilder an. Dort sollen später die Konfigurationsdatei des Tools sowie die erstellten Firewall-Regeln lagern.
Jetzt starten wir den Firewall Builder. Als erstes gilt es, einige grundlegende Einstellungen für die Applikation selbst zu treffen. Dazu rufen wir den Menüpunkt Edit/Options auf. Im ersten Tab des daraufhin erscheinenden Popup-Fensters tragen wir den Pfad zu unserem Arbeitsverzeichnis - also /etc/fwbuilder - ein. Die Einstellungen des Netzwerk-Tabs können wir bei den Defaultwerten belassen: Also je 10 Sekunden Timeout und einen Wiederholungsversuch.
Auf dem dritten Tab sollte auf jeden Fall unter Behavior die automatische Sicherung aller Einstellungen beim Wechsel zwischen den Objekten aktiviert sein. Die Anzeigeoptionen für Icons und Objekte können Sie ganz nach Geschmack variieren. Allerdings erweisen sich die eingestellten Vorgaben bei der weiteren Arbeit erfahrungsgemäß als hilfreich.
Das Firewall-Objekt
Ein wesentliches Stichwort beim Umgang mit dem Firewall Builder ist bereits gefallen: Objekte. Bei der weiteren Konfiguration baut das Tool auf die Definition diverser Objekte auf. Dazu zählen Netzwerke und Hosts ("Objects"), Protokolle und Ports ("Services"), sowie Zeitspannen ("Time"). Das wichtigste davon stellt das Firewall-Objekt selbst dar: Also der lokale Rechner, den es über eine zugeordnete Policy zu schützen gilt. Daher erstellen wir als erstes über den Menüpunkt Insert/Firewall ein entsprechendes Objekt.
Dieses muss über insgesamt fünf Reiter mit Einstellungen versorgt werden. Auf dem Tab General tragen wir eine eingängige Bezeichnung für das Objekt sowie dessen Netzwerkadresse ein. Als unterstützte Firewall-Software wählen wir Iptables, die anderen Werte belassen wir auf den Voreinstellungen.
Firewall-Interfaces
Auf dem Tab Interfaces legen wir mit Hilfe des New-Buttons die beiden Interfaces lo (den internen Loopback) und eth0 (die Netzwerkkarte) an. Dabei definieren wir eth0 als externes Interface. Anschließend definieren wir per Rechtsklick in der unteren Hälfte für beide Interfaces jeweils eine Default-Policy. Die Konfiguration sieht für beide Interfaces fast identisch aus: Source, Destination und Service lassen wir auf Any stehen, als Direction wählen wir Both. Die so erstellte Policy gilt also jeweils für alle Pakete in alle Richtungen.
Der kleine, aber wesentliche Unterschied: Für den internen Loopback tragen wir als Regel ("Action") Accept ein, lassen also alle Pakete zu. Für die Netzwerkschnittstelle dagegen verbieten wir per Deny alles. Um die Filterregel anzuwählen, genügt jeweils ein Rechtsklick der Maus auf das entsprechende Feld. Auf ein Protokollieren der jeweiligen Aktionen können wir ebenso verzichten wie auf die Angabe von Zusatzoptionen. Die Felder Log und Options lassen wir daher leer.
Die Angaben des Reiters Sysinfo benötigen wir für unsere Aufgabenstellung nicht. Wir können ihn daher überspringen und uns den Angaben auf dem Tab Compile / Install widmen.
Compilierung und Installation
Der Regelcompiler liegt nach einer Standardinstallation von Firewall Builder im Verzeichnis /usr/bin. Da wir Regeln für die Iptables-Firewall erstellen wollen, geben wir als Pfad zum Compiler also /usr/bin/fwb_iptables an.
Als Installationsskript können wir, da wir lediglich eine Firewall für die lokale Maschine einrichten, direkt das von Firewall Builder später erstellte Konfigurationsskript angeben. Es liegt im Arbeitsverzeichnis der Applikation - bei uns also /etc/fwbuilder - und trägt den Namen des Firewall-Objekts mit der Endung .fw.
Auf dem letzten Tab namens iptables benötigen wir als einzige Option die Anweisung zum Laden der passenden Kernelmodule. Sie findet sich auf der rechten Seite des Fensters in der Gruppe Options.
Nachdem wir diese Grundeinstellungen erledigt haben, speichern wir den momentanen Status über den Menüpunkt File/Save As als /etc/fwbuilder_rules.xml.
Hosts und Netzwerke
Als nächstes definieren wir über Insert/Host und Insert/Network die Rechner und Netzwerke, mit denen wir dediziert kommunizieren wollen. Im Fall der Hosts geben wir dazu jeweils Rechnername und IP-Adresse ein, für die Netzwerke vergeben wir einen eingängigen Namen und definieren die Netzwerkadresse. In unserem Beispiel verwenden wir die zwei Class-C-Subnetze netIDG10 und netIDG80 (192.168.10.0 und 192.168.80.0, Netzmaske 255.255.255.0). Sie bilden unser internes Firmennetzwerk. Hinzu kommt das Class-B-Netz des Providers, netSpaceNet (195.30.0.0/255.255.0.0)
Nachdem wir unsere Änderungen sicherheitshalber gespeichert haben, gruppieren wir die Hosts nach Funktionsbereichen. Dazu bilden wir zunächst per Insert/Group of Objects die Gruppen
hostsDNS (DNS-Server),
hostsLocal (interne Subnetze)
hostsMail (Mailserver),
hostsNews (Newsserver),
hostsNBT (lokales Windows-Netzwerk) und
hostsMgmt (lokale Management-Stationen).
Diesen ordnen wir jetzt die Hosts und Netze zu, indem wir sie per rechtem Mausklick kopieren und in der entsprechenden Gruppe wieder einfügen.
Dienste und Protokolle
Im Abschnitt Services bringt Firewall Builder bereits eine reiche Auswahl an vordefinierten Diensten in den Kategorien ICMP , IP , TCP und UDP mit. Darunter finden sich mit Ausnahme eines einzigen auch schon alle, die wir für unsere Aufgabenstellung benötigen. Den fehlenden Service definieren wir über Insert/TCP, da es sich dabei um TCP-Pakete zur Abwicklung einer Session in Windows-Netzwerken handelt.
Wir geben ihm einen aussagekräftigen Namen, in unserem Fall tcpNBT-ssn (TCP-Paket für Sessions via NetBIOS over TCP/IP). Als Quellport lassen wir alle Anschlüsse zu, in Firewall-Builder-Nomenklatur: 0 bis 0. Als Zielport nutzen wir Port 139 (alias netbios-ssn). Die TCP-Flags können wir für unseren Einsatzzweck ignorieren und belassen sie abgewählt.
Dienstegruppen
Wie bei den Hosts fassen wir jetzt auch die Protokolle zu Funktionsgruppen zusammen. Für Dienste, die nur ein einziges Protokoll nutzen, können wir uns diese Arbeit allerdings sparen. Darunter fallen bei unserer Aufgabenstellung UDP /dns (DNS ), TCP /ftp_data (FTP -Daten) und TCP/nntp (News).
Für die restlichen Verbindungstypen definieren wir über Insert/Group of Services die Dienstegruppen:
svcHTTP_FTP (Web und FTP),
svcIPTools (lokales ping und traceroute),
svcMail (Mailversand und Empfang),
svcMgmt (Echo und SNMP für Managementzwecke) und
svcNBT (Windows-Netzwerk).
Auch hier speichern wir die Einstellungen nach der Definition ab. Anschließend fügen wir den Dienstegruppen per Copy und Paste die nötigen Protokolle hinzu.
Dienstefunktionen
Die Gruppe svcHTTP_FTP dient dazu, sowohl Web-Browsern als auch FTP -Clients den Betrieb zu ermöglichen. Dazu fügen wir die Dienste TCP /http, TCP/https sowie TCP/ftp ein. svcIPTools stellt die wichtigsten Netzdiagnose-Funktionen für unsere Workstation bereit. Dazu benötigen wir ICMP /ping_request und UDP /traceroute.
Die Dienste der Gruppe svcMail ermöglichen den Betrieb unseres Mailclients. Alle gehören zur TCP-Protokollfamilie. Die Services smtp und smtps dienen zum Versenden von Nachrichten. Die Abholung von Mails erfolgt je nach Mailserver über pop3 oder imap/imaps.
Lokale Managementrechner müssen unsere Workstation über Ping und SNMP erreichen können. Dies stellt die Gruppe svcMgmt mit den Diensten ICMP/ping_request und ping_reply sowie UDP/snmp und snmp-trap sicher.
Last not least soll unsere Maschine auch im Windows-Netzwerk Funktionen nutzen und bereitstellen können. Dazu tragen wir in die Gruppe svcNBT die Dienste UPD/netbios-ns (Name Service), UDP/netbios-dgm (Datagramme), UDP/netbios-ssn (Session) sowie das selbst definierte tcpNBT-ssn ein. Anschließend speichern wir unsere Änderungen ab.
Die Firewall-Policy
Damit haben wir alle notwendigen Vorarbeiten abgeschlossen und können nun an die Definition der eigentlichen Firewall-Policy gehen. Dazu wählen wir bei unserem Firewall-Objekt den Punkt Policy an. Bei den ersten Regeln lassen wir uns vom Firewall Builder zur Hand gehen, indem wir im Menü Rules den Punkt "Help me build firewall policy" selektieren.
Im hier erscheinenden Fenster überspringen wir den Einführungstext und wählen auf der nächsten Seite "Firewall protects local host". Nach einem Klick auf den "Weiter"-Button weisen wir die Firewall durch Auswahl des ersten und letzten Punktes an, kurze IP-Fragmente stets auszufiltern und unbekannte Pakete stets zu verwerfen.
Beides dient der Sicherheit: Diverse Angriffsmethoden versuchen mit Short Fragments Firewalls zu unterlaufen. Im lokalen Netzbetrieb dagegen kommen solche Pakete nicht vor. Das Verwerfen aller unbekannten Pakete lässt nur solche Daten die Firewall passieren, die wir im Folgenden explizit zulassen.
Regeln für FTP und HTTP
Über einen Rechtsklick auf das Nummernfeld der untersten Filterregel fügen wir darüber eine neue Zeile ein. Die einzelnen Felder dieser neuen Regel füllen wir aus den Objektdefinitionen per Copy and Paste. Als Source geben wir die Firewall an, als Destination Any. In die Service-Spalte tragen wir unsere Dienstegruppe svcHTTP-FTP ein. Die Action lautet Accept, auf ein Log der Pakete können wir verzichten. Als Time lassen wir Any zu. Per Rechtsklick editieren wir die Optionen und markieren, wie später auch bei fast allen anderen Regeln, den Punkt "Turn off stateful inspection for this rule". Unter Comment können wir einen beliebigen Erläuterungstext angeben.
In svcHTTP_FTP haben wir die Pakettypen http , https und ftp zusammengefasst. Dies erlaubt Browsern, Pages von Webservern abzurufen sowie Kontakt zu FTP -Servern aufzunehmen. Letzteres gilt ebenso für FTP-Clients. Weder Browser noch FTP-Programm können mit dieser Regel aber FTP-Daten empfangen. Dazu muss der eingehende Port 20 (ftp-data) geöffnet werden. Dabei handelt es sich jedoch um einen klassischen Angriffspunkt von Crackern. Daher definieren wir hier eine eigene Regel, die wir unter der ersten einfügen.
Source ist hier Any, Destination unsere Firewall. Als Dienst kommt wie erwähnt TCP/ftp_data zum Zuge. Als Action geben wir Deny an, lassen dafür jedoch bei Options die Stateful Inspection aktiviert. Dies hat zur Folge, dass nur solche Pakete abgelehnt werden, die unverlangt bei uns eintreffen. Daten von Verbindungen, die wir selbst per svcHTTP_FTP initiiert haben, lässt die Firewall dagegen durch. Sicherheitshalber schalten wir hier die Protokollierung dennoch ein.
Regel für DNS
Unternähmen wir jetzt einen Versuch, die bislang definierten Regeln auszutesten, käme dennoch keine Verbindung zustande. Bislang fehlt unserem Rechner die Möglichkeit, die Hostnamen der Gegenstellen per DNS aufzulösen. Dazu fügen wir jetzt oberhalb der HTTP /FTP -Einstellungen eine passende Regel ein.
Hier kommt zum ersten Mal eine der von uns definierten Hostgruppen zum Einsatz: hostsDNS. Die Angabe der zugelassenen Hosts über eine Gruppe bietet zwei Vorteile: Zum einen lässt sich die Regel kürzer fassen, da statt aller Hosts nur die Gruppe eingetragen werden muss. Zum anderen kann bei Veränderung der Hosts die Regel gleich bleiben, lediglich der Inhalt der Gruppe ändert sich.
hostsDNS und unsere Firewall tauchen hier sowohl als Quelle wie auch als Ziel auf, als Protokoll geben wir TCP /dns an. Da wir die Pakete akzeptieren, können wir uns eine Protokollierung sparen. Auch eine Prüfung per Stateful Inspection ist hier überflüssig.
Regeln für Mail und News
Da wir ohnehin gerade Regeln für Internet-Dienste aufstellen, können wir hier gleich noch Mail und News ergänzen. Wir fügen sie direkt unter dem DNS -Eintrag ein. Als Source fungiert in beiden Fällen unsere Firewall, und natürlich erlauben wir die Pakete. Auf Logging und Stateful Inspection können wir dementsprechend verzichten. Für das Protokoll TCP /nntp, also die News, fungiert als Gegenstelle unsere Newsserver-Gruppe hostsNews.
Für die Maildienste kommt als Service unsere Gruppe svcMail zum Einsatz. Damit lassen sich via SMTP oder Secure SMTP Mails verschicken respektive Nachrichten per POP3 oder IMAP empfangen. Im Feld Destination setzen wir unsere Mailserver-Gruppe hostsMail ein.
Regeln für Management-Tools
Im nächsten Schritt fügen wir am Ende unserer Filterkette die Regeln für interne und externe Managementtools hinzu. Zu Überwachungszwecken erlauben wir den Stationen der Gruppe hostsMgmt den Zugriff per ping und SNMP auf unseren Rechner. Dabei erfolgt der Datenfluss in beide Richtungen, weshalb alle beteiligten Rechner sowohl als Source wie auch als Destination auftauchen.
Anders bei der Regel für die gängigsten IP-Diagnosetools: Hier ist nur Verkehr von der Firewall zu beliebigen anderen Rechnern gestattet. Die erlaubten Dienste umfassen TCP /ping_request und UDP /traceroute, die wir in der Servicegruppe svcIPTools gebündelt haben. Damit lässt sich nicht nur die Erreichbarkeit entfernter Rechner überprüfen, sondern gegebenenfalls auch der Leitweg dorthin.
Regeln für Windows-Netze
Zu guter Letzt definieren wir noch die Regel für das File- und Printsharing unter Windows. Dazu fügen wir unterhalb des Fragmentfilters zwei Zeilen ein. Sie unterscheiden sich nur durch die Richtung der Pakete: Um Shares im Netz zu nutzen, dient die Firewall als Source und die Gruppe hostsNBT als Destination. Um Shares im Netz zur Verfügung stellen, kehren wir die Richtung der Daten in der zweiten Zeile um. In beiden Fällen nutzen wir die Dienste aus svcNBT als Protokoll.
Das stellt die Verbindungen zu jenen Rechnern sicher, mit denen unsere Firewall als Server oder Client via NBT Daten austauscht. Allerdings klopfen an den entsprechenden lokalen Ports 137 bis 139 auch solche Rechner aus den lokalen Subnetzen an, die keine Verbindung erhalten sollen. Dies bläht das Log unnötig auf, da solche Pakete erst durch die Schlussregel abgefangen und dabei protokolliert werden.
Daher definieren wir als vorletzte Regel in unserer Kette einen "NBT Silencer". Er blockt solche Pakete ohne Protokollierung ab. Als Source geben wir die Gruppe hostsLocal an, in der die lokalen Subnetze zusammengefasst sind. Als Destination fungiert die Firewall, als Dienste wiederum svcNBT. Stateful Inspection ist hier überflüssig.
Firewall starten
Damit haben wir die Konfiguration der Firewall abgeschlossen und speichern sie ein letztes Mal ab. Anschließend wählen wir im Menü den Punkt Rules/Compile an. Firewall Builder generiert jetzt das Firewall-Skript und speichert es im Arbeitsverzeichnis /etc/fwbuilder ab. Von dort kann es über Rules/Install gestartet und anschließend ausgetestet werden.
Um automatisch bei jedem Systemstart das aktuelle Firewall-Skript zu laden, tragen wir es in /etc/init.d/iptables, das Startup-Skript für Iptables, ein. Dazu suchen wir die Marken start) und restart) und ergänzen sie um den Befehl zur Ausführung der in /etc/fwbuilder/ gespeicherten Regeln.
Eine Überprüfung unserer Firewall mit einem Portscanner a la nmap zeigt, dass unser Rechner durch nicht autorisierte Stationen tatsächlich nicht mehr entdeckt werden kann. Potentiellen Angreifern bleibt er also künftig verborgen.
Fazit
Das beschriebene Konfigurationsbeispiel reizt die Fähigkeiten des Firewall Builder bei weitem nicht aus. So lässt sich durch die Definition und Einbindung von Zeitspannen die Geltungsdauer von Regeln zeitlich beschränken. Daneben kann das Tool mehrere Firewall-Konfigurationen parallel vorhalten und bei Bedarf auf verschiedene Rechner verteilen. Viele dazu notwendigen Informationen holt sich Firewall Builder bei Bedarf per Knopfdruck via DNS und SNMP .
In jedem Fall reduziert Firewall Builder den Aufwand beim Erstellen, Austesten und Verteilen von Firewall-Policies drastisch. Selbst Einsteiger mit minimalem Vorwissen konfigurieren mit diesem Tool aufgrund der fast intuitiven Bedienung innerhalb kürzester Zeit einen brauchbaren Paketfilter. Es gibt also wirklich keine Ausrede mehr, die hervorragenden Firewall-Fähigkeiten von Linux weiter brachliegen zu lassen. (jlu)