Firewall selbst entwickeln

Ein Firewall-Skript, das man noch durchschauen kann, ist die bessere Alternative zu vorgefertigten Skripten.

Vorwort

Es gibt zahlreiche sogenannte Firewall-Skripte und Frontends für Linux. Doch ihrer praktischen Verwendung stehen oft mehrere Gründe im Weg:

Sie passen nicht auf die eigenen Anforderungen
Ihre Konfiguration oder ihre Wirkungsweise ist undurchschaubar
Sie erfordern eine bestimmte Kernel-Version (2.0, 2.2 oder 2.4)

Besonders der zweite Punkt ist entscheidend. Wenn ich einen Firewall einrichte, will ich 100% sicher sein, daß er so funktioniert, wie ich mir das vorstelle. Wie aber will ich das bei einem vorgefertigten Programm bewerkstelligen? Trial and Error wäre hier angesagt. Doch bevor ich mehrere Programme daraufhin untersucht habe, ob sie korrekt funktionieren, habe ich schneller etwas Eigenes geschrieben.

Daher stelle ich hier eine Art Baukasten für einen Paketfilter vor, der folgende Bedingungen erfüllt:

Benötigt nur die Shell (und die üblichen Tools)
Kann in den Init-Skripten gestartet und gestoppt werden
Bietet maximale Sicherheit
Funktioniert mit Kernel-Version 2.4 (andere Versionen später)
Seine Wirkungsweise ist (hoffentlich) verständlich

Ich gehe nicht davon aus, daß das hier vorgestellte Skript der Weisheit letzter Schluß ist. Vielmehr werden sich vermutlich noch einige Änderungen und Erkenntnisse ergeben, die in eine neuere Version dieses Artikels einfließen werden. Die Hauptsache ist zunächst einmal, daß das Skript tut, was ich mir als Ziel gesetzt habe.

Dieser Artikel ist kein Tutorial zur Wirkungsweise von Netfilter oder dem iptables-Programm. Entsprechende Dokumentation, teilweise auch in Deutsch, gibt es bereits (s. Quellen). Es wäre unsinnig, dies zu wiederholen. Stattdessen liefert dieser Artikel ein Beispiel aus der Praxis und hilft damit hoffentlich, die Lücke zwischen Dokumentation und realer Anwendung kleiner zu machen.

Einleitung

Allzu oft wird Firewall mit Paketfilter gleichgesetzt. Das ist falsch. Paketfilter sind nur ein Teil einer Firewall-Konfiguration. Ich will hier aber trotzdem nur auf Paketfilter eingehen, und zwar auf die Paketfilter, die Bestandteil des Linux-Kernels sind. Es gibt auch eine oder mehrere Implementierungen außerhalb des Kernels, doch habe ich noch keine näheren Informationen darüber.

Definieren wir schnell einmal ein paar Begriffe. Der Firewall-Rechner ist der Rechner, der die Paketfilter implementiert. Es kann ein einzelner Rechner mit Internet-Zugang (Modem, ISDN, DSL oder gar LAN) sein, es kann aber auch ein Router sein, an den ein oder mehrere (bei mir letzteres) lokale Netze angeschlossen sind. Das "Draußen" ist demzufolge das Internet und wird über das Netzwerk-Interface erreicht, das dorthin führt. Bei Modem-Zugang also ppp0, bei ISDN ippp0, und bei anderen Zugängen eth0, eth1 oder was auch immer.

Ein Paketfilter ist zwar wichtig, garantiert für sich allein aber noch keine absolute Sicherheit. Würde man alle Pakete nach draußen sperren, hätte man absolute Sicherheit erreicht, doch aus pragmatischen Gründen wird man das eine oder andere Paket durch den Filter durchlassen wollen. Dies könnte ein Angreifer jedoch ausnutzen, um mit gefälschten Paketen eventuell Zugang zu dem Rechner zu erlangen. Je mehr Löcher man im Paketfilter lassen muß, desto größer die Gefahr. Filter-Kriterien sind die IP-Adressen von Sender und Empfänger, die Portnummer von Sender und Empfänger, das Protokoll, die Schnittstelle, die hereinkommende und ausgehende Pakete nehmen, und die Richtung (ins Internet oder vom Internet kommend). Wir müssen davon ausgehen, daß die Adresse und die Portnummer eines hereinkommenden Paketes gefälscht sein können. Ferner müssen wir alle Pakete ablehnen, die nicht für uns bestimmt sind. Das mag trivial erscheinen, weil man glauben könnte, daß Pakete, die nicht für uns bestimmt sind, erst gar nicht bei uns ankommen. Doch dem ist nicht so.

Der Paketfilter von Kernel 2.4

Kernel 2.4 kommt mit einer neuen Implementierung der Paketfilter, der vierten oder fünften in der Geschichte von Linux. Der Name der Implementierung ist Netfilter. Um diese zu benutzen, bedarf es auch eines neuen Tools, iptables. Version 1.2 wird mindestens vorausgesetzt.

Zwar erlaubt Netfilter es mit Hilfe von Modulen, Rückwärtskompatibilität mit Linux 2.2 und sogar 2.0 herzustellen, doch ich rate davon ab. Erstens funktioniert dann Masquerading nicht, was für viele Nutzer wichtig ist, und zweitens bringt es nichts, auf einem Auslaufmodell herumzureiten. Kernel 2.4 ist hier und wird spätestens mit Version 2.4.3 weite Verbreitung erfahren. Netfilter ist endlich die Implementierung der Paketfilter, die die optimale Flexibilität und Erweiterbarkeit garantiert und dazu noch exzellente Performance bietet. Man darf davon ausgehen, daß sie mehr Bestand haben wird als ihre Vorgänger.

Es ist wichtig, die grundlegenden Konzepte von Netfilter zu kennen. Hier eine Kurzfassung. Netfilter arbeitet mit "Ketten" von Regeln. Ketten sind wie Unterprogramme. Regeln können in eine neue Kette verzweigen, und Ketten können zur aufrufenden Kette zurückkehren. Dieses Konzept stammt von den ipchains von Linux 2.2.

Es gibt drei vordefinierte Ketten: INPUT, OUTPUT und FORWARD. Ferner kann man beliebige weitere Ketten definieren. Standardmäßig sind nach dem Booten alle Ketten leer, und alle Pakete werden durchgelassen. Im Unterschied zu früher durchläuft jedes eingehende oder ausgehende Netzwerk-Paket nur noch eine einzige Kette:

Pakete, die auf den lokalen Rechner erzeugt werden, durchlaufen die OUTPUT-Kette.
Pakete, die für den lokalen Rechner bestimmt sind, durchlaufen die INPUT-Kette.
Pakete, die lediglich geroutet werden, also den Rechner auf einem Netzwerk-Interface erreichen und auf einem anderen wieder verlassen, durchlaufen die FORWARD-Kette. Offensichtlich muß der Rechner als Router konfiguriert sein, damit dies funktioniert.

Ein Paket durchläuft eine Kette, indem alle Regeln in der Kette der Reihe nach abgearbeitet werden, bis entweder eine Regel entscheidet, was mit dem Paket passiert, oder alle Regeln durchlaufen sind, worauf die Default Policy angewandt wird. Das Schicksal des Pakets kann im Wesentlichen nur zwei mögliche Verläufe nehmen: Es wird ignoriert (DROP) oder normal verarbeitet (ACCEPT). Der Weg bis zu dieser Entscheidung kann natürlich beliebig komplex werden, je nach Umfang der Anforderungen. Darüber hinaus kann auf diesem Weg noch einiges mit dem Paket passieren. Wir beschränken uns hier aber auf das Logging.

Die Konstruktion

Grundsätzliches

Das von mir entwickelte Skript behandelt kein Masquerading (auch Network Address Translation, NAT, genannt). Das kann man in einem separaten Skript behandeln, das nicht Thema dieses Artikels sein soll.

Das Skript sollte aufgerufen werden, bevor die entsprechenden Netzwerk-Schnittstellen definiert sind. Dadurch entsteht kein Loch im Filter, auch wenn dieses nur Sekundenbruchteile lang sein sollte.

Sicherheit läßt sich nur erreichen, wenn der Paketfilter möglichst restriktiv ist. Das heißt, es muß alles ausgefiltert werden, was nicht explizit erlaubt ist. Die umgekehrte Vorgehensweise, nämlich alles zu erlauben, was nicht explizit verboten ist, bietet keinerlei Schutz vor unvorhergesehenen Attacken.

Alle Verstöße gegen die Filterregeln werden protokolliert (sie erscheinen im Kernel-Log). Das ist neben dem Entdecken von Angriffen auch für das Debuggen nützlich.