Schnellschutz

Firewall in Linux-2.4 mit iptables konfigurieren

von Frank Bernard


"Beständig ist bei Linux nur der Wechsel" [1]. Und so hat sich in nur zwei Monaten wieder mal viel geändert : netfilter heißt auf Benutzerebene jetzt iptables (auf Kernelebene weiterhin netfilter), das Kommando ipnatctl ist als spezielle Option -nat im Kommando iptables aufgegangen, NAT heißt jetzt SNAT und RNAT heißt jetzt DNAT. Verwirrt ? Das wird sich hoffentlich im Laufe dieser Artikelserie legen.

Da die Veränderungen weitergehen werden : dieser Artikel bezieht sich auf Linux-Version 2.3.99-4pre4 und iptables-1.0.0.
 

Billiglösung für Ungeduldige

Small Office / Home Office
Abbildung 1 : Small Office / Home Office (SOHO)

Viele haben nur eine ISDN- oder Modemverbindung ins Internet und wollen nur ein bißchen sicherer surfen (Abb. 1). Außerdem können diese Leser nicht bis zum Erscheinen des nächsten Linux-Magazins warten. Für all diese gibt es eine billige und schnelle Lösung :

#!/bin/sh
# ISDN
INTERFACE=ippp0
# Modem
#INTERFACE=ppp0
# Ethernet (eth0=LAN, eth1=DMZ, eth2=Internet)
#INTERFACE=eth2

insmod ip_tables
insmod ip_conntrack
insmod ip_conntrack_ftp
insmod ipt_state
insmod iptable_nat
insmod ipt_MASQUERADE

iptables -F

iptables -N block
iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A block -m state --state NEW -i ! $INTERFACE -j ACCEPT
iptables -A block -j DROP

iptables -A INPUT -j block
iptables -A FORWARD -j block

iptables -A POSTROUTING -t nat -o $INTERFACE -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Für ISDN oder Modem muß nur noch eine der drei Zeilen auskommentiert werden (hier ippp0). Das Aufsetzen und Initialisieren der Interfaces (Modem bzw. ISDN) muß vorher gemacht werden. Setzt man diesen Rechner jetzt als default-Router im Netz ein, hat man einen einfachen Firewall. Beim Übersetzen des Kernels sollte man CONFIG_NETFILTER auswählen sowie alle CONFIG_IP_NF_-Optionen als Module wählen. Wenn man noch ein wenig internen Ablauf im Kernel sehen möchte, kann man CONFIG_NETFILTER_DEBUG auch anschalten. Auch das /proc-Dateisystem muß man mitkompilieren, entweder als Modul oder fest in den Kernel.

Erläuterungen

Um in die Thematik von iptables [2] einzuführen, eignet sich dieses Beispiel sehr gut und wird deshalb hier erklärt : insmod ist ein Kommando zum Laden von Modulen in den Kernel, praktisch dynamische Kernelerweiterungen. Das eigentlich bessere modprobe, was automatisch abhängige Module laden würde, funktioniert nicht, wenn man ipchains auch als Modul (Rückwärtskompatibilität) übersetzt hat. Das Kommando "iptables -F" löscht alle Regeln. Das ist wichtig beim mehrmaligen Aufruf dieser Prozedur, da sonst Regeln doppelt angegeben würden. Bestehende selbstdefinerte Chains ("block") werden damit nicht gelöscht, aber geleert. Die Fehlermeldungen, die beim mehrmaligen Aufruf entstehen, können ignoriert werden. Mit "iptables -N block" wird eine neue Chain angelegt. Es gibt für Pakete drei fest definierte Chains INPUT, FORWARD, OUTPUT und für NAT (Option -nat) die Chains PREROUTING, POSTROUTING, OUTPUT. Wenn die Chain bereits existiert, kommt eine Fehlermeldung. Selbstdefinierte leere Chains können mit iptables -X <chain> gelöscht werden.

Jetzt kommt etwas Neues, was es mit ipchains und Linux-2.2 noch nicht gab. Mit "-m state" wird auf den Status eines Pakets Bezug genommen. Jedes Paket, egal ob es zu einer echten Verbindung im TCP oder im verbindungslosen UDP (z.B. als DNS-Antwortpaket) gehört, ICMP oder ein anderes IP-Protokoll benutzt, wird klassifiziert. Dabei gibt es die Zustände "NEW", "ESTABLISHED", "RELATED" und "INVALID".

Umgangssprachlich heißen die beiden Regeln mit "-m state" also : Die nächste Regel verwirft alle anderen Pakete, also z.B. Pakete für den Verbindungsaufbau von außen.

Mit den letzten beiden Regeln wird die Chain "block" für Pakete, die an den Firewall selbst ("INPUT") oder an andere Rechner ("FORWARD") geschickt werden aufgerufen, quasi in Form einer Unterprozedur.

Dann kommt der für die beteiligten Rechner des internen Netzes wichtigste Teil : man benutzt den Firewall als Gateway. Wenn klar ist, daß das Paket über $INTERFACE herausgeschickt wird,
wird ein spezieller Fall von NAT (Network Address Translation) aufgerufen, das sogenannte Masquerading. Dabei werden die Quelladressen so verändert, daß es so aussieht, als kämen Sie vom Firewall selbst. Zurückkommende Pakete werden dann ins interne LAN über eine Tabelle wieder korrekt umgesetzt [1]. Und schließlich muß der Firewall noch Pakete von einem Interface auf das andere ausgeben dürfen, das ist standardmäßig ausgeschaltet.

Billige DMZ für Ungeduldige


Abbildung 3 : Firewall mit DMZ

Rusty Russell hat es geschafft, in über einem Jahr Programmiertätigkeit den Wildwuchs mit ipmasqadm, ipportfw,  NAT als Patch zu ipchains und anderen Teillösungen in iptables und den Kernel zu integrieren. Für die "DMZ für Ungeduldige" brauchen wir nun das ehemalige ipportfw, bei iptables unter DNAT (Destination NAT) bekannt. Diese Lösung funktioniert
mit nur einer IP-Adresse. Auch wenn es sonst nicht viel Sinn macht, darf diese IP-Adresse sogar dynamisch sein (aber was will man mit einem Web-Server, der mal unter dieser und mal unter jener Adresse erscheint ?).

Oft will man Web- und Mailserver nicht ins lokale Netz stellen, sondern in ein eigenes Segment, der sogenannten De-Militarisierten Zone (DMZ). Verwaltet wird diese dann aus dem LAN, zugegriffen werden kann dann aus dem Internet.

iptables -A PREROUTING -t nat -p tcp --dport 80 -i $INTERFACE -j DNAT --to <WEBSERVER>:80

lenkt alle eingehenden HTTP-Anforderungen in die DMZ auf unseren Web-Server. Der Port 80 ist WWW. Doch halt : diese Verbindung muß auch bei den Paketfilterregeln zugelassen werden. Also fügen wir VOR die Regel "iptables -A input -j block" noch diese Regeln ein :

iptables -A FORWARD -p tcp -d <WEBSERVER> --dport 80 -i $INTERFACE -o eth1 -j ACCEPT
iptables -A FORWARD -p tcp -s <WEBSERVER> --sport 80 -i eth1 -o $INTERFACE -j ACCEPT

wobei unterstellt wird, daß eth1 die Schnittstelle in die DMZ ist.

Paranoiker werden bemängeln, daß ich nicht den kleinstmöglichen Regelsatz gewählt habe, der würde noch "! -syn" in die jeweils zweite Regel einfügen. Der Verbindungsaufbau geschieht immer von außen bzw. aus dem LAN, niemals aus der DMZ heraus. "-syn" charakterisiert ein Paket mit speziellen Flags zum Verbindungsaufbau, "!" ist die Negation, also würden wir aus der DMZ heraus nur HTTP-Pakete zulassen, die keine Verbindung aufbauen. In diesem speziellen Fall ist es kein Sicherheitsrisiko, generell sollte man schon den paranoischen Ansatz wählen.

Analog geht man bei Mail (SMTP, Port 25) vor. Für Port 110 (POP3), also das aktive Abholen von Mails, brauchen wir nichts mehr anzugeben.

Jetzt müssen wir noch DMZ und LAN gegeneinander schützen, bislang ist ein ungehinderter Datenverkehr zwischen beiden Segmenten möglich und das soll nicht sein. Natürlich erkaufen wir uns diesen Schutz mit anderen Regeln :

Statt

iptables -A block -m state --state NEW -i ! $INTERFACE -j ACCEPT

heißt es nun

iptables -A block -m state --state NEW -i eth0 -j ACCEPT

Für jeden Dienst aus der DMZ heraus (etwa SMTP-Auslieferung vom DMZ-Mailserver an einen LAN-Mailserver, aber auch Ping) müssen wir nun weitere Regeln angeben.

Die Regeln und die NAT-Einstellungen kann man sich mit den Kommandos "iptables -L -n -x -v" und "iptables -L -n -x -v -t nat" anschauen. Die Option "-n" verhindert dabei eine Namensauflösung, die Option "-x" zeigt die exakte Anzahl von Paketen und Bytes an, die die jeweilige Regel passiert haben und "-v" schaltet die exakte Regelsauflösung ein.

Wir sind jetzt sogar so flexibel, daß weitere Netzsegmente hinzugenommen werden können, die z.B. einen Datenbank-Server beinhalten, der vom Lieferanten per ISDN ferngewartet wird. Am Firewall wird nur der Datenbank-Port (und evtl.DHCP sowie DNS) durchgelassen, die Fernwartung ermöglicht damit nicht den Zugriff ins LAN. Bei Vierfach-Ethernetkarten und physisch bis zu zwanzig möglichen Segmenten darf jeder Lieferant sein eigenes Segment bekommen und kann nur noch seine eigenen Sachen kaputtmachen.

Solcherart eingerichtete Firewalls sind auch kaskadierbar, etwa wenn die Personalabteilung ein LAN im LAN sein will.

Wir haben mit dieser Lösung eine schnelle und halbwegs sichere Anbindung an das Internet inclusive DMZ bekommen und dieser Schutz ist schon sehr viel besser als nichts.


Abbildung 4 : Segmente mit unterschiedlichen Sicherheitsstufen und kaskadiertem Firewall

Stateful Inspection vs. Paketfilter mit Application Proxy

Mit der Einführung der Option "-state" hat man nun die Wahl, ob man "Stateful Inspection", ein Verfahren, was der Marktführer Checkpoint [4] verwendet, einsetzen will oder konventionell mit Paketfilter und Application Proxy [3] arbeitet. Auch Hybrid-Lösungen sind möglich. Hier zeigt sich Linux wieder einmal von seiner besten Seite : alles was es bei anderen schon gibt und gut zu sein scheint, wird integriert. Diese neue schnelle Lösung hat allerdings auch ihre Nachteile, es war nicht möglich, eine FTP-Verbindung aufzubauen. Mit Paketfilter und Application Proxy hingegen war das problemlos. Dies liegt zwar sicher an dem Beta-Zustand des Kernels, zeigt aber die Schwierigkeit der neuen Materie.

Ausblick

Bis jetzt haben wir folgende Punkte noch nicht, die für professionelle Firewalls gefordert werden und mit Linux machbar sind :