Abbildung 1: Aufbau des Beispiel-Netzwerks mit einem Mailserver im inneren Netz und einem reinen Mailrelay in der DMZ.

Mit GUI-Unterstützung wird das Zusammenstellen eines Firewall-Regelwerks übersichtlicher, einfacher und damit weniger fehleranfällig. Mit Hilfe des freien Firewall Builders zeigen wir hier beispielhaft die Konfiguration einer kleinen Firmen-Firewall.

Eine Firewall muss nicht nur den Datenverkehr filtern, sie muss sich auch selbst vor Angriffen schützen. Das geht umso besser, je weniger unnötige Software auf ihr installiert ist. Eine grafische Oberfläche direkt auf der Firewall fällt also aus, “back to the roots” ist angesagt: die Firewall wird an der Kommandozeile oder per Datei konfiguriert. Das hindert uns aber nicht daran, das Regelwerk mit einem GUI zu erstellen – solange das GUI nicht auf der Firewall selbst läuft. Es müssen dann nur noch die erzeugten Regeln auf die eigentliche Firewall übertragen werden.

Handarbeit

Linux bringt mit den Iptables bereits eine mächtige Firewall mit, genauer gesagt einen “stateful packet filter”. Dieser Filter wird zunächst an der Kommandozeile konfiguriert. Die folgende Regel sorgt zum Beispiel dafür, dass ICMP-Pakete vom Loopback-Interface 127.0.0.1 verworfen werden ( DROP). Der Absender wird keine Antwort erhalten, auch keine negative. Versucht man mit ping 127.0.0.1 eine Antwort vom Loopback-Interface zu erhalten, wird die Antwort (ein ICMP-Typ-0-Paket, also echo reply) verworfen:

iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP

Deutlich komplizierter fiele das Beispiel bereits aus, wenn nur jene ICMP-Pakete verworfen werden, die durch die Firewall laufen und von bestimmten Sendern kommend an bestimmte Empfänger gerichtet sind. Produktive Firewalls bestehen aber aus einer Vielzahl noch komplexerer Anforderungen.

Werkzeuge: GUI und Compiler

So praktisch die Kommandozeile in vielen Fällen ist, manchmal wünscht man sich doch die Unterstützung eines grafischen Werkzeugs. Die Konfiguration einer Firewall ähnelt ja fast schon der Software-Entwicklung: Warum sollte der geplagte Admin dann nicht auch über ähnliche Hilfsmittel verfügen? Nicht als Ersatz für die Kommandozeile, sondern als Hilfe beim Schreiben der Regeln.

Abbildung 1: Aufbau des Beispiel-Netzwerks mit einem Mailserver im inneren Netz und einem reinen Mailrelay in der DMZ.

Praktisch alle kommerziellen Firewalls arbeiten in irgendeiner Form mit GUIs zur Konfiguration des Regelwerks (Rulebase). Das GUI der Checkpoint-Firewall-1 etwa ist dem hier verwendeten Firewall Builder ähnlich. Seit einiger Zeit sind die Filter der Checkpoint-Firewall-1 zwar auch unter Red Hat Linux 6.1 erhältlich, aber die Oberfläche ist vorerst nur für Windows und einige kommerzielle Unix-Systeme verfügbar.

Ähnlich dem Firewall-1-GUI ist der Firewall Builder unabhängig von der eigentlichen Firewall. Er besteht aus dem GUI und einem austauschbaren Compiler, der das grafisch erstellte Regelwerk in Textform übersetzt (kompiliert). Welche Firewall damit konfiguriert wird, hängt vom eingesetzten Compiler ab: Aktuell stehen Compiler für Iptables, Ipchains und Ipfilter zur Verfügung. Es werden direkt die Konfigurationsanweisungen für die Ziel-Firewall erzeugt, die nur noch dorthin übertragen werden müssen (etwa mit ssh).

Durch den objektorientierten Ansatz des Firewall Builders kann eine Regel im GUI viele einzelne Iptables-Regeln erzeugen. Darum braucht man sich aber nicht zu kümmern, denn der Compiler erzeugt das entsprechende Material. Die Ausgaben des Compilers sind direkt Iptables-Befehle, die man durchaus noch verstehen und auch überprüfen kann.

Keep it small and simple

Der eine oder andere mag glauben, dass eine Firewall erst dann richtig professionell ist, wenn sie durch die Anzahl der Regeln beeindruckt. In der Praxis ist aber eher das Gegenteil der Fall. Die Regeln werden sequenziell abgearbeitet, der erste Treffer kommt zum Zuge. Steht eine häufig zutreffende Regel erst am Ende einer langen Rulebase, muss der Filter jedes Mal die Anwendbarkeit aller vorherigen Regeln prüfen. Das geht dann zu Lasten der Performance.

Steht die Regel bereits am Anfang der Rulebase, wird der Treffer schneller erzielt, die Performance verbessert sich. Demnach sind wenige Regeln an gut überlegten Positionen erstrebenswert. Zusätzlich ist ein kurzes Regelwerk übersichtlicher und mögliche Fehler sind leichter erkennbar.

Abbildung 2: Grundkonfiguration der Firewall.

Beim Firewall Builder und anderen (auch bei kommerziellen) GUIs beginnt man mit einer leeren Regel und fügt ihr dann (etwa per Drag & Drop) Objekte hinzu. Jede Firewall Policy besteht aus folgenden Elementen: Source, Destination, Service, Action, Logging, Comment.

Abbildung 3: Verbindungen von innen nach außen erlauben.

Das Objekt, von dem der Verbindungsaufbau ausgeht, muss in der Spalte Source stehen, die Ziel-IP-Adresse in der Spalte Destination und so weiter. Das benutzte Protokoll gehört unter Service. Die Action kann Accept, Deny oder Reject sein, das Logging lässt sich in der entsprechenden Spalte ein- oder ausschalten.

Wenn die Regel für alle Source- oder Destination-IPs oder für alle Services gelten soll, wird die entsprechende Spalte leer gelassen. Das GUI zeigt dann in dieser Spalte das Wort Any.

Regeln für SOHO

Das einfache Netzwerk in Abbildung 1 stammt aus dem SOHO-Bereich (Small Office Home Office) und dient hier zur Veranschaulichung der Konfiguration einer Rulebase. Im Zentrum steht eine Firewall, die drei Netzwerke miteinander verbindet. Im Techniker-Jargon hat die Firewall drei Beine: eins für den Zugang zum Internet, eins zur DMZ mit einem Mail-Relay und schließlich ein Bein zum internen LAN (Hausnetzwerk).

Im LAN verwenden wir private IP-Adressen nach RFC 1918. Generell sollen Verbindungen nur vom LAN nach außen möglich sein. Zur Mail-Zustellung ist aber auch der umgekehrte Weg erlaubt, dann aber nur über den Mail-Relay in der DMZ und von dort aus zum internen Mailserver.

Da wir private IP-Adressen verwenden, wollen wir für den Betrieb der Firewall auch NAT (Network Address Translation) einrichten. Dabei werden an der Firewall die privaten IP-Adressen in eine öffentliche Adresse übersetzt, die aber von der öffentlichen IP der Firewall verschieden ist.

Zuerst muss im GUI das Firewall-Objekt erstellt werden. Name, IP, Plattform und alle anderen Daten werden in der entsprechenden Maske konfiguriert (Abbildung 2). Die NICs der Firewall lassen sich entweder von Hand eingeben oder mit einer SNMP-Abfrage automatisch konfigurieren. Voraussetzung dafür ist jedoch, dass man von der Admin-Workstation aus die künftige Firewall mit SNMP erreichen kann. Ob diese Zugriffsmöglichkeit überhaupt erwünscht ist, steht auf einem anderen Blatt.

Für jedes Bein der Firewall, also jedes direkt angeschlossene Netzwerksegment, ist ebenfalls ein Objekt zu erstellen. Wenn alle benötigten Objekte vorhanden sind, kann man die ersten Regeln eingeben.

Besondere Regeln: Cleanup und Stealth

Zuerst sollte eine Cleanup-Rule, die in der Rulebase immer die allerletzte Regel ist, definiert werden (Zeile 01 in Abbildung 3). Diese Regel blockt einfach jegliche Kommunikation. Danach kann man die benötigten Dienste durch das Einfügen von Regeln vor der Cleanup-Rule Stück für Stück wieder freischalten.

Abbildung 4: Eine Stealth-Rule versteckt die Firewall vor neugierigen Blicken.

Durch das explizite Verbot jeder nicht ausdrücklich erlaubten Kommunikation wird sichergestellt, dass keine unnötigen Löcher in der Policy verbleiben. Zudem eröffnet die Cleanup-Rule eine Möglichkeit, alles, was nicht unter eine bestimmte Regel fällt, mitzuloggen und auf diese Weise zu verfolgen.

Da wir im Beispiel für NAT zwar eine eindeutige IP, aber nicht die externe IP der Firewall verwenden, sollten wir auch eine Stealth-Rule hinzufügen (Abbildung 4). Im Gegensatz zur Cleanup-Rule steht eine Stealth-Rule an erster Stelle. Sie versteckt die Firewall als Ganzes vor neugierigen Blicken oder Angreifern und stellt sicher, dass sich niemand mit ihr verbinden kann.

Versteckspiele mit NAT

Nun können weitere, auf die eigene Topologie und spezielle Bedürfnisse zugeschnittene Regeln hinzugefügt werden. Am Beispiel fügen wir zuerst Regeln hinzu, die es erlauben, von unserem internen LAN Verbindungen ins Internet aufzubauen. Das oben erstellte Netzwerkobjekt für das interne Netz bauen wir per Drag & Drop als Source in die Regel ein (Zeile 00 in Abbildung 3).

Abbildung 5: NAT und DNAT verwandeln private IP-Adressen in öffentliche.

Weil wir NAT einrichten wollen, brauchen wir für unser Hausnetzwerk eine spezielle NAT-Regel. NAT-Regeln bestehen zwar aus anderen, aber zu herkömmlichen Regeln analogen Elementen: Original Source, Original Destination, Original Service, Translated Source, Translated Destination und Translated Service. Damit lassen sich Source-IP, Destination-IP und/ oder Service (oder besser Portnummer in UDP- und TCP-Paketen) übersetzen. Nicht alle Linux-Firewalls unterstützen dieses Feature, aber der Compiler sorgt dafür, dass auf jeden Fall für die ausgewählte Plattform verwendbares Material entsteht.

Die NAT-Regel hat also das gleiche Netzwerkobjekt als Original Source sowie ein spezielles Objekt, die hiding_translation_address, als Translated Source. Diese Regel konfiguriert die Firewall so, dass die Source-IP-Adresse aller ins Internet gesendeten Pakete in die des hiding_ translation_object übersetzt wird (Zeile 00 in Abbildung 5).

E-Mail

Unser Hausnetzwerk ist vorerst gut mit Regeln versorgt und wir können mit den Regeln für die DMZ fortfahren. Im Beispiel steht nur ein einziger Rechner in der DMZ: unser Mail-Relay. Dem Mail-Relay müssen die Dienste SMTP und DNS reverse lookups erlaubt werden (Zeile 00 bis 02 in Abbildung 6).

Regeln für eine DMZ können auf zweierlei Arten verwirklicht werden: Als Source fungieren entweder einzelne Rechner aus der DMZ oder das DMZ-Subnetz als Ganzes. Da unsere DMZ aus nur einem einzigen Host besteht, kümmert uns der Unterschied nicht weiter.

Der interne Mailserver braucht außerdem noch eine weitere NAT-Regel (Zeile 01 in Abbildung 5), damit der Mail-Relay mit ihm sprechen kann. Unter Iptables werden solche Regeln DNAT oder NAT for Destination IPs genannt.

Feinschliff

Nun ist unser Ziel fast erreicht, wir haben ein kleines Regelwerk für den SOHO-Bereich erstellt, das sich bereits sehen lassen kann. Es gibt aber noch einige weitere, in der Praxis durchaus sinnvolle Regeln, die wir vielleicht hinzufügen möchten. Beispielsweise könnten uninteressante Einträge aus dem Logging der Cleanup-Rule gestrichen werden, um die Logfiles in einem halbwegs erträglichen Umfang zu halten.

Kandidaten sind zum Beispiel geschwätzige NT-Maschinen mit NBT – solche Pakete können durch eine eigene Regel ohne Logging ignoriert (und verworfen) werden. Oder das Ident-Protokoll. Es wird oft als nutzlos oder sogar als Sicherheitsrisiko dargestellt, demnach sollten wir Ident-Requests verwerfen ( DROP). Allerdings nutzt beispielsweise Sendmail das Ident-Protokoll um herauszufinden, welcher User die Verbindung aufgebaut hat.

Abbildung 6: Sonderbehandlung für Netbios und Ident.

Wenn alle Ident-Requests nun heimlich still und leise ignoriert werden, würden die Mailserver einige Sekunden warten und erneut versuchen, eine Ident-Verbindung zu uns aufzubauen. Woher sollen sie auch wissen, dass wir nicht antworten werden. Das führt aber zu Verzögerungen bei der Zustellung von E-Mails.

Um das Problem zu umgehen, schreiben wir den ersten sinnvollen Anwendungszweck für die Aktion REJECT in unsere Rulebase: Wir ersetzen DROP durch REJECT für das Ident-Protokoll. Dadurch sendet unsere Firewall ICMP protocol unreachable zurück zum Sender und gibt ihm somit Bescheid, dass die Ident-Verbindung nicht hergestellt werden kann. Der Sender kann dann ohne weiteres Warten mit dem Zustellen der Mail beginnen (Abbildung 6).

So viel zur Konfiguration unseres Regelwerks. Die Policy wird durch den Aufruf des Menüpunkts Compile Policy übersetzt. Das resultierende Firewall-Skript wird auf den eigentlichen Firewall-Rechner kopiert und dort ausgeführt. ( fjl)