22.6    Firewalls mit »netfilter« und »iptables«

In den meisten Fällen wird bei Linux, wenn es um Firewalls geht, von iptables gesprochen – aber eigentlich ist netfilter gemeint, da dies hinter dem Frontend iptables steht. netfilter ist die Schnittstelle im Kernel, mit der sich Pakete abfangen und manipulieren lassen. iptables hingegen ist nur ein Tool, mit dem netfilter angesprochen werden kann. Für andere Schichten und Protokolle gibt es noch ebtables, ip6tables und arptables. In diesem Abschnitt zeigen wir Ihnen die Möglichkeiten von iptables. Sowohl der Ablauf als auch die Syntax und die Kommandos lassen sich fast 1:1 auf ip6tables (das entsprechende Pendant für IPv6-Umgebungen) übertragen.

22.6.1    Der Weg ist das Ziel – wie Pakete durch den Kernel laufen

Mit iptables werden Filterregeln gesetzt, die darüber entscheiden, was mit einem Paket passiert. Diese Regeln werden in unterschiedliche Ketten, die sogenannten Chains, geschrieben. Je nach Ursprung und Ziel eines Pakets werden unterschiedliche Chains durchlaufen. Abbildung 22.3 zeigt den Verlauf eines Pakets im Kernel.

Paketverlauf im Kernel

Abbildung 22.3    Paketverlauf im Kernel

Alle Pakete, die das System erreichen, durchlaufen zunächst die PREROUTING-Chain. Wie der Name bereits sagt, wurde zu diesem Zeitpunkt noch keine Routing-Entscheidung getroffen. Daher ist auch noch nicht bekannt, ob das Paket an das System adressiert ist oder den Rechner nur als Router durchläuft. Aus diesem Grund werden in der PREROUTING-Chain auch keine klassischen Filterregeln gesetzt, sondern beispielsweise Regeln für Network Address Translation (NAT).

Nach der PREROUTING-Chain wird die Routing-Entscheidung getroffen. Falls das Paket an das System adressiert ist, wird als Nächstes die INPUT-Chain angesprochen. Daher werden in der INPUT-Chain auch Regeln definiert, die sich auf eingehende Pakete beziehen. Nach erfolgreichem Durchlauf kann das Paket dann an den lokalen Prozess zugestellt werden. Dies kann zum Beispiel ein Webserver sein, der lokal auf der Maschine läuft. Die Antworten des Prozesses werden in die OUTPUT-Chain eingeliefert. Der ausgehende Datenverkehr kann daher ebenfalls gefiltert werden. Zu guter Letzt wird das Paket in die POSTROUTING-Chain geliefert. Hier können Pakete analog zum PREROUTING manipuliert werden.

Pakete, die von dem System geroutet werden, durchlaufen weder die INPUT- noch die OUTPUT-Chain, sondern die FORWARD-Chain. Dort werden also alle Regeln gesetzt, um ein dahinter liegendes Netzwerk zu schützen.

Jede Chain besteht aus mehreren tables (zu deutsch Tabellen). Aber nicht jede Tabelle ist in allen Chains vorhanden. Wenn in iptables nicht explizit eine Tabelle angegeben wird, so wird automatisch die filter-Tabelle verwendet. Folgende Tabellen können von iptables genutzt werden:

22.6.2    Einführung in »iptables«

Mit iptables können Sie nicht nur die Firewallregeln definieren, sondern auch die Chains verwalten. Diese Möglichkeiten wollen wir Ihnen nun der Reihe nach vorstellen.

Ausgabe der Regeln: »-L <CHAIN> [-t <TABLE>]«

Mit der Option -L können Sie sich alle Regeln ausgeben lassen. Ohne weiteren Parameter werden alle Regeln der Tabelle filter von allen Chains ausgegeben. Geben Sie eine Chain an, werden nur deren Regeln der Tabelle filter ausgegeben. In Kombination mit der Option -t <TABLE> können auch andere Tabellen ausgegeben werden.

[+]  Zusätzliche Angaben: »-n« und »-v«

Sie sollten zusätzlich zu -L auch noch -n und -v angeben. Mit -n unterbinden Sie die Namensauflösung der IP-Adressen und sparen somit bei großen Listen viel Zeit. -v gibt zusätzliche wichtige Statistiken mit an, und darüber hinaus wird die Default Policy der Chain mit angezeigt.

In Listing 22.68 sehen Sie eine Ausgabe der Auflistung aller Chains:

Chain INPUT (policy ACCEPT 19 packets, 1406 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 8 packets, 1120 bytes)
 pkts bytes target     prot opt in     out     source               destination

Listing 22.68    Auflistung aller Chains

Regeln löschen: »-F <CHAIN> [-t <TABLE>]«

Mit der Option -F können Sie alle Regeln aus einer Chain und deren Tabellen löschen. Ohne weitere Parameter werden lediglich die Regeln der filter-Tabelle entfernt.

[ ! ]  Beim Löschen nicht »mangle«, »raw« und »nat« vergessen!

Die Tabellen mangle, raw und nat müssen Sie explizit angeben, um deren Inhalt zu löschen. Wenn Sie mit diesen Tabellen arbeiten, dürfen Sie das nicht vergessen! Da diese Tables mit -L im Normalfall unterschlagen werden, vergisst man sie häufig. Unter Umständen bleiben dadurch noch Reste einer alten Konfiguration aktiv.

Angabe der »Default Chain«: »-P <CHAIN> <TARGET>«

Mit der Option -P wird für die angegebene Chain die Default Policy gesetzt. Diese wird auch oft als Clean Up Rule bezeichnet, da sie immer zutrifft, wenn vorher keine andere Regel zugetroffen hat – sie ist sozusagen das Aufräumkommando. Über <TARGET> wird das Standardverhalten angegeben. (Mehr zum Thema TARGET finden Sie in Abschnitt 22.6.4, »Die klassischen Targets«.)

Nach dem Systemstart steht die Default Policy auf ACCEPT – daher werden alle Pakete, für die keine expliziten Regeln existieren, einfach zugelassen. Die Default Policy kann nur auf die vordefinierten Chains gesetzt werden, nicht auf selbst erstellte.

[+]  Beim Löschen nicht enthalten!

Beim Löschen aller Regeln mittels -F wird die Default Policy auf ACCEPT zurückgesetzt! Beachten Sie dies, bevor Sie Regeln löschen, damit Sie keine ungewollte Kommunikation zulassen.

Anlegen und Löschen von Chains: »-N <CHAIN>« und »-X <CHAIN>«

Mit der Option -N werden eigene Chains angelegt. Die maximale Länge für einen Namen beträgt im Übrigen 30 Zeichen. Verwenden Sie nur Klein- und Großbuchstaben, Zahlen, den Binde- und Unterstrich. Vermeiden Sie Sonderzeichen (auch deutsche Umlaute), da dies zu Fehlern führen kann.

Äquivalent zum Anlegen können Sie mit der Option -X eine Chain angeben, die gelöscht werden soll.

Anlegen und Bearbeiten von Regeln: »-A <CHAIN>«, »-I <CHAIN> [<POS>]« und »-D <CHAIN> <POS/RULE>«

Mit der Option -A können Sie eine Regel in der angegebenen Chain anlegen. Dabei wird diese Regel als letzte Regel zur Chain hinzugefügt.

Die Option -I erwartet zusätzlich zur Chain die Position, an der die neue Regel hinzugefügt werden soll. Die Position geben Sie dabei als Zeilennnummer an. Falls Sie nicht stumpf die Zeilen abzählen wollen, können Sie auch den Befehl iptables -L --line-numbers absetzen. Dieser gibt Ihnen die bestehenden Regeln mit vorangestellter Zeilennummer aus. Geben Sie keine Position an, wird die Regel an erster Stelle der Chain hinzugefügt.

Zum Entfernen einer Regel können Sie die Option -D verwenden. Dabei müssen Sie entweder die entsprechende Regel vollständig angeben, oder Sie geben erneut, wie bereits beim Einfügen mittels -I, die Zeilennummer der entsprechenden Regel an.

22.6.3    Regeln definieren

Regeln bestehen aus einem oder mehreren Filtern, die zum einen das Paket beschreiben und zum anderen das Ziel (target) beinhalten, das angibt, was mit dem Paket passieren soll. Folgende Filter können Sie verwenden:

[+]  Pakete durchlaufen nacheinander die beschriebenen Chains. Die meisten Targets sind terminierend, sie entscheiden sofort, was mit dem Paket passieren soll. Daher greift immer die erste zutreffende Regel – somit ist die Reihenfolge der Regel von essenzieller Wichtigkeit.

Zusätzlich zur Funktionalität spielt die Reihenfolge auch eine große Rolle bei der Performance. netfilter ist zwar sehr performant, aber bei Regelwerken mit vielen und komplexen Regeln kann sich eine nicht optimal gewählte Reihenfolge durchaus bemerkbar machen. Regeln, die viele Pakete verarbeiten, sollten daher immer möglichst weit oben im Regelwerk stehen. Falls Sie viele Webserver betreiben, sollte die Regel für HTTP entsprechend weit oben in Ihrem Regelwerk einsortiert werden und nicht erst an Position 1.000.

22.6.4    Die klassischen Targets

Wie wir bereits erörtert haben, entscheiden Targets darüber, was mit einem Paket geschieht, das für eine Regel zutrifft. Nachstehend haben wir die möglichen Targets aufgelistet:

22.6.5    Ein erster Testlauf

In diesem Abschnitt wollen wir Ihnen zeigen, wie Sie das bisher erworbene Wissen in der Praxis anwenden können. Listing 22.69 zeigt, wie Sie eine Webseite mit iptables sperren:

root@saturn:~# iptables -A OUTPUT -p tcp --dport http \
                        -d www.rheinwerk-verlag.de -j REJECT
root@saturn:~# telnet www.rheinwerk-verlag.de 80
Trying 46.235.24.168...
telnet: Unable to connect to remote host: Connection refused

root@saturn:~# iptables -vnL OUTPUT
Chain OUTPUT (policy ACCEPT 2356 packets, 198K bytes)
pkts bytes target prot opt in  out  source    destination
2   120 REJECT    tcp  --  *   *   0.0.0.0/0  46.235.24.168  tcp dpt:80\
          reject-with icmp-port-unreachable

Listing 22.69    Sperren einer Webseite mit »iptables«

Die Regel aus Listing 22.69 blockiert (REJECT) den ausgehenden (-A OUTPUT) HTTP-Verkehr (--dport http) auf den Webserver des Rheinwerk Verlags (-d www.rheinwerk-verlag.de). Da wir als Target REJECT gewählt haben, wird die Verbindung abgewiesen – was durch die Rückmeldung Connection refused von telnet dargestellt wird. Hätten wir DROP gewählt, würde telnet bis zum Timeout gewartet haben, bevor es aufgegeben hätte. Abschließend haben wir die Informationen zur OUTPUT-Chain abgefragt. Der Ausgabe können Sie entnehmen, dass die Regel bisher für zwei Pakete mit insgesamt 120 Byte zugetroffen hat.

[+]  Bei der Regel aus Listing 22.69 haben wir einen DNS-Namen anstelle einer IP-Adresse verwendet. Dies ist durchaus legitim und kann sehr praktisch sein, vor allem, wenn sich hinter einem Namen mehrere IP-Adressen verbergen. Allerdings müssen Sie dabei beachten, dass iptables die Namensauflösung durchführt, bevor es die Regel in den Kernel schreibt. Ändert sich anschließend die Zuordnung von Namen zur IP-Adresse, müssen Sie die Regel erneut setzen – die Namensauflösung findet also nicht bei jedem Zugriff (oder nach Ablauf der Gültigkeitsdauer des DNS-Eintrags) statt!

22.6.6    Rein wie raus: »Stateful Packet Inspection«

Die Stateful Packet Inspection (SPI) kontrolliert nicht nur Quelle, Ziel und Protokoll, sondern prüft auch den Zustand einer Verbindung. Es wird dabei geprüft, ob ein Paket zum Aufbau einer Verbindung verwendet wird oder es zu einer bereits bestehenden Verbindung gehört. Der Kernel führt dafür mit dem Connection Tracking eine Liste der bestehenden Verbindungen. Mit den bisher vorgestellten Optionen kann diese Funktion nicht eingerichtet werden. Um zum Beispiel von internen Systemen den Zugriff auf einen Webserver zu erlauben, müssten Sie die Regel aus Listing 22.70 einrichten:

root@saturn:~# iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
root@saturn:~# iptables -A INPUT -p tcp --sport 80 -j ACCEPT

Listing 22.70    Zugriff auf Port 80 freischalten

Diese Regel funktioniert zwar, ist aber zum einen unschön, und zum anderen provoziert sie auch ein Verhalten, das meistens nicht gewünscht ist. Unschön ist die Regel vor allem, da wir für eine Verbindung zwei Regeln einrichten mussten. Darüber hinaus besagen die Regeln lediglich, dass Daten aus dem internen Netzwerk an Systeme über Port 80 gesendet werden dürfen und dass Antworten von Port 80 zugelassen werden – diese Regeln haben keine Verbindung, und daher ist nicht sichergestellt, dass nur Antworten auf vorherige Anfragen zugelassen werden. Somit könnte das interne System A eine Anfrage an den Server C stellen, und völlig unabhängig davon könnte Server B Daten in das interne Netzwerk senden. Die wahre Krux besteht aber darin, dass nicht alle Protokolle immer mit dem gleichen Port antworten – in der Regel spricht der Client den Server auf einem definierten Port an, und während des Kommunikationsaufbaus handeln beide den gültigen Rückkanal aus, meist einen beliebigen high port (Port > 1024).

Dank SPI müssen Sie nicht unnötig viele Regeln erzeugen, um Datenverkehr gezielt freigeben zu können. Damit iptables die SPI verwendet, müssen Sie das Modul state laden. Dieses Modul bietet Ihnen nun die zusätzliche Option --state an. Diese Option kann nachstehende Parameter verarbeiten:

Bei TCP-Verbindungen kann, da das Protokoll zustandsorientiert ist, leicht festgestellt werden, ob ein Paket zu einer bestehenden Verbindung gehört. Aber auch beim zustandslosen UDP ist netfilter in der Lage, den Zustand festzustellen. Dafür werden einfach die Rahmenbedingungen wie zum Beispiel Quelle, Ziel, Portnummern und auch die Zeit zur Zuordnung hinzugezogen. Das Connection Tracking kann daher unabhängig vom eingesetzten Protokoll verwendet werden und stellt ein großes Hilfsmittel bei der Erstellung effektiver und übersichtlicher Regelwerke dar.

Das Regelwerk aus Listing 22.70 kann mit SPI so abgebildet werden, wie in Listing 22.71 dargestellt:

root@saturn:~# iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED \
               > --dport 80 -j ACCEPT
root@saturn:~# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

Listing 22.71    Regel für Port 80 mit »SPI«

Wie Sie Listing 22.71 entnehmen können, wird bei den Regeln nun mit der Option -m das Modul state geladen. Daher kann über die Option --state auch der für die Regel erlaubte Zustand angegeben werden. Die erste Regel lässt also ausgehende (-A OUTPUT) Pakete auf tcp/80 für neue (NEW) und bereits etablierte (ESTABLISHED) Verbindungen zu. Die zweite Verbindung erlaubt nur Antwortpakete an bereits etablierte Verbindungen.

In der Praxis wird fast ausschließlich mit SPI gearbeitet. Nicht nur, weil dadurch die Sicherheit deutlich erhöht wird, sondern auch, weil die Übersichtlichkeit der Regelwerke deutlich gesteigert wird. Die Steigerung der Übersichtlichkeit wird vor allem daran deutlich, dass Sie nur für die drei Filter-Chains je eine Regel für die Zustände RELATED und ESTABLISHED einrichten müssen, um alle möglichen Antworten an bestehende Verbindungen zuzulassen.

Daher reicht es, bei so eingerichteten Regeln anschließend nur noch Regeln für den Zustand NEW einzurichten. In Listing 22.72 sehen Sie die Regeln, über die alle Antworten zu bestehenden Verbindungen bei allen Chains automatisch zugelassen werden:

root@saturn:~# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
root@saturn:~# iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
root@saturn:~# iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Listing 22.72    Freischaltung aller Antworten für bestehende Verbindungen

22.6.7    Das erste Firewallskript

iptables-Regelwerke werden in Skripten organisiert, da sie darüber leicht beim Systemstart geladen werden können. Zum Einstieg erstellen wir ein Skript für einen Host. Diesem werden sowohl Web- als auch DNS-Zugriffe in Richtung Internet erlaubt. Zusätzlich sollen aus- und eingehende Pings freigeschaltet werden. Erstellen Sie dafür ein Skript mit dem Inhalt aus Listing 22.73:

#!/bin/bash
IPT="/sbin/iptables"

# Setzen der Default Policy
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# Loeschen evtl. vorhandener alter Regeln
$IPT -F

# Loopback freischalten
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# Bestehende Verbindungen erlauben
$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Ausgehend HTTP(S) erlauben
$IPT -A OUTPUT -m state --state NEW -m multiport -p tcp --dport http,https -j ACCEPT

# DNS-Abfragen zulassen
$IPT -A OUTPUT -m state --state NEW -p udp --dport domain -j ACCEPT
$IPT -A OUTPUT -m state --state NEW -p tcp --dport domain -j ACCEPT

# Aus- und eingehend ping erlauben
$IPT -A OUTPUT -m state --state NEW -p icmp --icmp-type echo-request -j ACCEPT
$IPT -A INPUT -m state --state NEW -p icmp --icmp-type echo-request -j ACCEPT

Listing 22.73    Ein erstes Firewallskript

Wie Sie Listing 22.73 entnehmen können, besteht das Skript aus acht Blöcken, die jeweils mit einer Raute eingeleitet werden. Sehen wir uns diese etwas genauer an.

Im ersten Block wird der Shebag gesetzt und die Variable IPT auf den Programmpfad von iptables gesetzt – passen Sie dieses gegebenenfalls an Ihre Umgebung an. Der zweite Block setzt zunächst die Default Policy auf DROP, sodass der nicht von uns freigegebene Datenverkehr verworfen wird – dieser Block gehört quasi zum Standard, da bei jedem Neuladen des Regelwerks die Default Policy von iptables auf ACCEPT gesetzt wird.

Im dritten Block werden etwaige Reste aus den Chains gelöscht, damit wir nicht in einen unbekannten Zustand hinein neue Regeln definieren. Der vierte Block gibt den Zugriff von und auf das Loopback-Interface frei. (Dies schauen wir uns im Anschluss noch genauer an.)

Der fünfte Block gehört ebenfalls zum Standardrepertoire eines Regelwerks, da dort die generelle Freischaltung für gültige (also zu bestehenden Verbindungen gehörende) Antwortpakete gesetzt wird. Im fünften, sechsten und siebten Block werden nun endlich die eigentlichen Freigaben eingerichtet. Dort wird das zusätzliche Modul multiport verwendet.

Neben den bisher vorgestellten Standardregeln haben wir im Firewallskript zwei Besonderheiten verwendet, die wir Ihnen nun näher erläutern möchten:

  1. Loopback-Interface freischalten
    Nach dem Setzen der Default Policy im zweiten Block werden sämtliche Verbindungen verboten. Damit werden auch Pakete vom Loopback-Interface (lo) unterbunden, was sehr gerne vergessen wird. Wenn über lo keine Daten mehr ausgetauscht werden können, funktionieren einige Dienste überhaupt oder teilweise nicht. Daher gehört dieser Block zum Standardrepertoire eines Regelwerks.

  2. Multiport-Modul
    Dieses Modul ermöglicht es Ihnen, mit den Optionen --dport und --sport eine kommaseparierte Liste von Ports anzugeben. Die Optionen können sonst nur einzelne Ports oder Portbereiche verarbeiten. Das Modul multiport erhöht die Übersichtlichkeit enorm.

[+]  Es gibt seit jeher die Diskussion, ob Paketfilter standardmäßig mit DROP oder REJECT arbeiten sollten. Für beide Varianten gibt es gute Gründe. Leider existieren auch eine Menge falscher Gründe.

Einer wäre z.B., dass behauptet wird, dass Portscans durch die Verwendung von DROP verlangsamt werden. Das ist aber nur zum Teil korrekt. Ein Portscanner wartet in der Regel nicht den Timeout ab. Das heißt, die Verlangsamung ist marginal bis gar nicht existent. Bei intelligent ausgeführten Portscans wird der Timeout so gewählt, dass er für einen bestimmten Zielhost nicht langsamer ist, ob nun das System oder eine Firewall mit einer REJECT"=Policy antwortet. Die Einzigen, die in der Regel in Timeouts laufen, sind meist Anwender – was die Usability nicht gerade erhöht.

Ein weiteres gern verwendetes Argument für die Nutzung von DROP ist, dass darüber verschleiert werden kann, welche Dienste ein System anbietet. Leider ist auch dieser Ansatz nicht korrekt, da insbesondere das Verwerfen eines Pakets darauf hindeutet, dass eine Firewall im Spiel ist. Ansonsten würde das angesprochene System eine entsprechende ICMP-Meldung an das anfragende System zurücksenden (was im Übrigen im RFC1122 auch vorgeschrieben wird). Daher ist der einzig wahre Grund, DROP zu verwenden, der, nicht als ICMP-Schleuder missbraucht werden zu können. Falls ein Angreifer mit gefälschten Absenderadressen agiert, würde der eigentliche Besitzer der Adressen von Ihrer Firewall mit ICMP-Meldungen bombadiert werden.

[+]  Im Übrigen wurde im Skript aus Listing 22.73 kein REJECT gewählt, weil es nicht als Default Policy gesetzt werden kann.

Falls Sie dennoch ein REJECT vorziehen, müssen Sie als letzte Regel im Skript iptables -A <CHAIN> -j REJECT angeben. Sie müssen als Administrator selbst entscheiden, welcher Mechanismus Ihnen lieber ist oder eher für Ihre Umgebung zutrifft. Wir empfehlen Ihnen, zumindest für das interne Netz REJECT zu verwenden, denn dann laufen wenigstens Ihre Anwender nicht in Timeouts, und die Fehlersuche wird erleichtert.

22.6.8    Externe Firewall

Bisher haben wir iptables lediglich in einer relativ flachen Umgebung genutzt. Um zum Beispiel Netzwerke voneinander zu trennen, wie das Internet, eine Demilitarized Zone (DMZ) oder das interne Netz (LAN), muss deutlich mehr Aufwand betrieben werden.

Zunächst besteht der größte Unterschied darin, dass wir mit der FORWARD-Chain arbeiten müssen. Dort verfügen wir aber nicht über die Richtungsinformationen – also von wo nach wo das Paket fließt, was in den Chains INPUT und OUPUT vorhanden ist. Da dies aber für die Regeln von entscheidender Bedeutung ist, da wir nun ja mehrere Netze verwalten, müssen wir eine Möglichkeit finden, an diese Information zu gelangen.

Eine Möglichkeit wäre, bei jeder Regel mit -i und -o anzugeben, in welche Richtung diese Regel greifen soll. Dies könnte dann so aussehen:

iptables -A FORWARD -m state --state NEW -p tcp --dport 80 -o eth2 -i eth0 -j ACCEPT

Listing 22.74    Firewallregel mit Angabe der Richtung über »-i« und »-o«

Bei der Regel aus Listing 22.74 wurde mit angegeben, dass die Regel nur für Pakete greift, die auf eth0 eintreffen und nach eth2 geroutet werden. Deutlich eleganter ist aber die Möglichkeit, den Paketfluss über selbst definierte Chains zu regulieren:

iptables -N int_to_ext
iptables -A FORWARD -i eth0 -o eth2 -j int_to_ext

Listing 22.75    Richtung über eine eigene Chain festlegen

Der erste Befehl aus Listing 22.75 erzeugt die neue Chain int_to_ext. Im zweiten Befehl wird eine Regel erzeugt, die alle Pakete aus der FORWARD-Chain, die über eth0 in das System gelangt sind und über eth2 das System verlassen sollen, an die neu angelegte Chain int_to_ext weitergibt.

In der neuen Chain können Sie dann alle Regeln setzen, die sich auf die entsprechende Traffic-Richtung beziehen (im Beispiel also auf den Datenverkehr vom LAN zum Internet). Sie können somit zum Beispiel den Webzugriff aus dem LAN erlauben, wie Sie in Listing 22.76 sehen können:

iptables -A int_to_ext -m state --state NEW -p tcp --dport 80 -j ACCEPT

Listing 22.76    Neue Regel in Bezug auf die eigene Chain

Trifft keine Regel aus der erstellten Chain auf ein Paket zu, so wird die Verarbeitung zurück an die aufrufende Chain gegeben – im Beispiel geht das Paket also zurück an die FORWARD-Chain.

[»]  Nun wollen wir ein Firewallskript erstellen, das eine Firewall mit drei Schnittstellen konfiguriert – je eine für extern, intern und DMZ. Folgende Bedingungen sollen erfüllt werden:

Den Netzwerkaufbau mit den entsprechenden Freigaben haben wir für Sie in Abbildung 22.4 noch einmal zusammengefasst.

Netzwerkaufbau: Firewall mit drei Schnittstellen

Abbildung 22.4    Netzwerkaufbau: Firewall mit drei Schnittstellen

Um die Anforderungen erfüllen zu können, müssen Sie ein Firewallskript mit dem Inhalt aus Listing 22.77 erstellen:

#!/bin/bash

# iptables binary
IPT="/sbin/iptables"

# Alte Konfiguration loeschen
$IPT -F
$IPT -X

# Default Policy setzen
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# Routing aktivieren
echo "1" > /proc/sys/net/ipv4/ip_forward

# Interfaces (Intern, DMZ, Extern)
INT=eth0
DMZ=eth1
EXT=eth2

# Management-Konsole fuer Firewall
MGMT=192.168.100.200

# Server DMZ
PROXY=10.10.10.20
MAIL=10.10.10.30
MONITOR=10.10.10.40
WEBSERVER=10.10.10.50
DNS=10.10.10.60

# Server extern
NTP=172.16.15.14

# Bestehende Verbindungen erlauben
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Loopback freischalten
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# Eigene Chains anlegen
$IPT -N int_to_dmz
$IPT -N dmz_to_ext
$IPT -N ext_to_dmz

# Verkehr aufteilen
$IPT -A FORWARD -i $INT -o $DMZ -j int_to_dmz
$IPT -A FORWARD -i $DMZ -o $EXT -j dmz_to_ext
$IPT -A FORWARD -i $EXT -o $DMZ -j ext_to_dmz

### Verkehr aus dem internen Netz in die DMZ
$IPT -A int_to_dmz -m state --state NEW -p tcp --dport 8080 -d $PROXY -j ACCEPT
$IPT -A int_to_dmz -m state --state NEW -p tcp --dport ftp -d $WEBSERVER -j ACCEPT
$IPT -A int_to_dmz -m state --state NEW -p tcp --dport https -d $MONITOR -j ACCEPT
$IPT -A int_to_dmz -m state --state NEW -p tcp -m multiport --dport pop3,imap \
      -d $MAIL -j ACCEPT
$IPT -A int_to_dmz -m state --state NEW -p tcp --dport ssh -s $MGMT -j ACCEPT
$IPT -A int_to_dmz -m state --state NEW -p icmp --icmp-type echo-request -j ACCEPT
$IPT -A int_to_dmz -j ext_to_dmz

### Verkehr aus der DMZ in das Internet
$IPT -A dmz_to_ext -m state --state NEW -p udp --dport ntp -d $NTP -j ACCEPT
$IPT -A dmz_to_ext -m state --state NEW -p tcp -m multiport --dport smtp,smtps \
      -s $MAIL -j ACCEPT
$IPT -A dmz_to_ext -m state --state NEW -p tcp -m multiport --dport http,https \
      -s $PROXY -j ACCEPT
$IPT -A dmz_to_ext -m state --state NEW -p tcp --dport domain -s $DNS -j ACCEPT
$IPT -A dmz_to_ext -m state --state NEW -p udp --dport domain -s $DNS -j ACCEPT
$IPT -A dmz_to_ext -j REJECT

### Verkehr aus dem Internet in die DMZ
$IPT -A ext_to_dmz -m state --state NEW -p tcp -m multiport \
      --dport smtp,smtps -d $MAIL -j ACCEPT
$IPT -A ext_to_dmz -m state --state NEW -p tcp -m multiport \
      --dport http,https -d $WEBSERVER -j ACCEPT
$IPT -A ext_to_dmz -m state --state NEW -p tcp --dport domain \
      -d $DNS -j ACCEPT
$IPT -A ext_to_dmz -m state --state NEW -p udp --dport domain \
      -d $DNS -j ACCEPT
$IPT -A ext_to_dmz -m state --state NEW -p icmp \
      --icmp-type fragmentation-needed -j ACCEPT
$IPT -A ext_to_dmz -j REJECT

### Regeln fuer die Firewall
# Eingehend
$IPT -A INPUT -i $INT -m state --state NEW -p tcp --dport ssh -s $MGMT -j ACCEPT
$IPT -A INPUT -i $DMZ -m state --state NEW -p udp --dport snmp -s $MONITOR -j ACCEPT

# Ausgehend
$IPT -A OUTPUT -o $DMZ -m state --state NEW -p tcp --dport 8080 -d $PROXY -j ACCEPT
$IPT -A OUTPUT -o $DMZ -m state --state NEW -p tcp --dport domain -d $DNS -j ACCEPT
$IPT -A OUTPUT -o $DMZ -m state --state NEW -p udp --dport domain -d $DNS -j ACCEPT
$IPT -A OUTPUT -o $EXT -m state --state NEW -p udp --dport ntp -j ACCEPT
$IPT -A OUTPUT -o $EXT -m state --state NEW -p icmp \
      --icmp-type fragmentation-needed -j ACCEPT

Listing 22.77    Firewallskript für eine Firewall mit drei Schnittstellen

In dem Skript aus Listing 22.77 werden nach dem Aufräumen, dem Erlauben von Antworten auf bestehende Verbindungen und dem Setzen von Variablen zunächst drei eigene Chains definiert: int_to_dmz, dmz_to_ext und ext_to_dmz. Damit diese den für sie zutreffenden Datenverkehr enthalten, werden unter Angabe der Optionen -i und -o Weiterleitungen in der FORWARD-Chain definiert. Anschließend folgen die Firewallregeln für die jeweiligen Chains.

Dabei sind besonders zwei Punkte wichtig. Zum einen sorgt der letzte Eintrag für die Regeln vom internen Netz zur DMZ, $IPT -A int_to_dmz -j ext_to_dmz, dafür, dass nach dem Durchlaufen von int_to_dmz noch die Chain ext_to_dmz nach passenden Regeln durchsucht wird. So ist gewährleistet, dass die internen Rechner zumindest genauso viel dürfen wie externe Besucher, ohne diese Regeln explizit einrichten zu müssen – dadurch vermeiden Sie doppelten Pflegeaufwand.

[+]  Der zweite wichtige Punkt ist die dedizierte Freigabe von ICMP. Es ist zwar möglich, ICMP vollständig zu unterbinden, dies kann allerdings zu unerwünschten Nebeneffekten führen. Erlauben Sie zumindest ICMP Typ 3 Code 4 Fragmentation required und DF flag set, damit die Automatismen zur Regulierung der Paketgrößen über die Firewallgrenzen hinweg funktionieren. Mit gesetztem don't fragment-(DF)-Bit im IPv4-Header darf ein Paket nicht fragmentiert, das heißt nicht in kleinere Pakete aufgeteilt werden. Sollte das aber nötig sein, weil ein Router in der Kommunikationskette mit einer kleineren Maximum Transfer Unit (MTU) arbeitet, dann wird das Paket verworfen, und ein ICMP-Typ-3-Code-4-Paket wird zurückgesendet. Wenn Ihre Firewall dieses Paket nun aufgrund eines zu strengen Regelwerks verwerfen sollte, kommt die Kommunikation unter Umständen gar nicht zustande.

[ ! ]  Filtern Sie auch ausgehende Verbindungen!

Die Filterung von ausgehenden Verbindungen ist sehr wichtig und wird heutzutage leider immer noch sehr oft vergessen oder unterschätzt. Viele Administratoren gehen immer noch fälschlicherweise davon aus, dass ihre Systeme nie Ärger machen, korrumpiert werden oder einfach Fehlkonfigurationen aufweisen. Diese Annahmen sind nicht nur falsch, sondern auch gefährlich! Es besteht nicht nur die Gefahr, dass Ihre Infrastruktur als Basis von Angriffen genutzt wird, sondern Sie machen sich auch leicht zum Opfer. Ein beträchtlicher Teil der zurzeit genutzten Angriffe lässt sich auf Schwachstellen von Webservern oder darauf laufenden Applikationen wie CMS-Systemen (Blogs, Webseiten etc.) zurückführen. Die so eingeschleuste Schadsoftware versucht zum einen, Kontakt nach Hause aufzubauen, um Schadcode nachladen zu können, und zum anderen versucht sie, gefundene Daten zu versenden oder sich über ein Botnetz fernsteuern zu lassen. Gerade Letztgenanntes lässt sich über strikt gesetzte Regeln zur Kommunikation nach außen erschweren oder sogar gänzlich verhindern.

22.6.9    Logging

Eines der Kernstücke einer Firewall ist das Logging. Dies hilft Ihnen nicht nur dabei, nachzuvollziehen, was passiert, sondern unterstützt Sie auch darin, herauszufinden, weshalb diese oder jene Kommunikation funktioniert oder nicht. Bei iptables wird zur Protokollierung das Target LOG verwendet. Da es sich dabei um ein nicht terminierendes Target handelt, werden Pakete nach dem Durchlauf zurück in die Verarbeitung gegeben. Alle Pakete, die LOG durchlaufen, werden an syslog übergeben.

In Listing 22.78 sehen Sie ein Beispiel für eine Regel, die über das Target LOG Meldungen an syslog weitergibt. Eine solche Log-Meldung aus der Datei /var/log/syslog wird anschließend mittels tail ausgegeben. Die Datei /var/log/syslog ist die Standard-Log-Datei bei Debian und Ubuntu, auf einem SUSE-System finden Sie die Meldungen in der Datei /var/log/messages.

root@saturn:~# iptables -A OUTPUT -m state --state NEW -p tcp --dport 80 -j LOG
root@saturn:~# tail -1 /var/log/syslog
Oct  9 10:03:32 saturn kernel: [560612.596981] IN= OUT=eth0 SRC=192.168.0.163 DST=\
             46.235.24.168 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=51197 DF PROTO=TCP \
             SPT=39430 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

Listing 22.78    Anzeige in der Datei »/var/log/syslog« bei Verwendung des Targets »LOG«

Um Log-Meldungen besser unterscheiden zu können, können Sie die Option --log-prefix verwenden. Diese Option erwartet einen String, der jeder Log-Meldung vorangestellt wird. Listing 22.79 zeigt das Ergebnis bei der Verwendung von --log-prefix:

root@saturn:~# iptables -A INPUT -m state --state NEW -p tcp --dport ssh \
               -j LOG --log-prefix "SSH-Eingehend: "
root@saturn:~# tail -1 /var/log/syslog
Oct  9 10:33:49 saturn kernel: [562430.358969] SSH-Eingehend: IN=eth0 OUT=\
             MAC=00:26:18:81:1d:63:00:0a:e4:26:f4:3c:08:00 SRC=192.168.0.20\
             DST=192.168.2.10 LEN=60 TOS=0x00\
             PREC=0x00 TTL=64 ID=56235 DF PROTO=TCP\
             SPT=45175 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Listing 22.79    Log-Meldung mit Präfix

Damit können Sie Regeln sehr einfach im Log finden, Gruppen von Log-Einträgen bilden und diese zum Beispiel über Ihren Syslog-Server mittels Syslog-Regeln in eigene Dateien schreiben lassen.

[+]  Neugierig geworden?

Mehr zum Thema syslog finden Sie in Kapitel 12, »Syslog«.

Zunächst stellt sich die Frage: Was sollte protokolliert werden? Die einfachste, wenn auch unbefriedigende Antwort ist: alles, was Sie zur Fehlersuche oder zum Finden von Sicherheitsproblemen benötigen (oder was gegebenenfalls durch die Beauftragten für Datenschutz und IT-Sicherheit aus Ihrem Unternehmen vorgegeben wurde). Dies ist natürlich im Vorfeld schwer festzustellen. Daher ist es gang und gäbe, einfach jeden unterbundenen Datenverkehr zu protokollieren. Dies ist prinzipiell nicht falsch, benötigt aber viel Speicherplatz und eine leistungsfähige Firewall – Sie werden erstaunt sein, wie schnell sich ein Firewall-Log füllen kann. Diese Protokolle sind für Sie aber auch nur dann nützlich, wenn Sie sie auswerten und die richtigen Schlüsse daraus ziehen können. Wenn Sie hingegen tagelang mehrere Gigabyte große Log-Daten durchgehen, nur um festzustellen, dass der Angriff von einem infizierten PC eines brasilianischen Internetcafes stammte, dann hilft Ihnen das Logging höchstwahrscheinlich kein Stück weiter. Legen Sie den Fokus stattdessen auf unerlaubte ausgehende Verbindungen.

Die Anzahl der ausgehenden Verbindungen sollte in einem gut gepflegten Netzwerk sehr übersichtlich sein. Eine Untersuchung der Meldungen lohnt sich daher auf jeden Fall. Eine weitere Möglichkeit ist, den Datenverkehr nur ausschnittsweise zu protokollieren. Das ist mit dem limit-Modul möglich. Mit diesem Modul können Sie iptables dazu bringen, auf eine bestimmte Anzahl von Paketen pro Zeiteinheit zu achten und nur diese zu protokollieren. In Listing 22.80 sehen Sie, wie Sie das Modul limit verwenden können:

root@saturn:~# iptables -A INPUT -m state --state NEW -m limit \
                        --limit 10/minute -p tcp --dport ssh -j LOG\
                        --log-prefix "SSH-Eingehend: "

Listing 22.80    Verwendung von »limit« zur Reduzierung der Log-Einträge

Eine so wie in Listing 22.80 mit dem Modul limit versehene Regel protokolliert maximal zehn Pakete pro Minute. Das Modul limit kann auch noch mit anderen Intervallen umgehen: second, hour oder day. Darüber hinaus können Sie mit der Angabe von --limit-burst definieren, wie viele Pakete am Stück protokolliert werden sollen, bevor eine Pause gemacht werden soll. Damit können Sie sicherstellen, dass Ihr gesetztes Limit nicht bereits nach einem Sekundenbruchteil »aufgebraucht« ist. Ohne Angabe der Option --limit-burst liegt der Standardwert bei 5.

[ ! ]  Verwenden Sie »limit« nicht, um »DoS«-Angriffe abzuwehren!

Wenn Sie das Modul limit auf eine andere Chain als die LOG-Chain anwenden, können Sie darüber auch die maximale Anzahl der Pakete für ein Zeitintervall definieren – was aber nicht sinnvoll und ratsam ist, da das limit-Modul nicht dazu geeignet ist, Datenverkehr sinnvoll einzuschränken.

Auch wenn dies oft die Empfehlung ausgesprochen wird, für verschiedene Dienste ein Limit zu setzen, um Denial of Service-(DoS-)Angriffe zu unterbinden, ist dies nicht sinnvoll. Um DoS-Angriffe abzuwehren, sollten Sie besser das Modul connlimit verwenden, das wir in Abschnitt 22.6.1, »Weitere nützliche Module für ›iptables‹«, näher betrachten.

22.6.10    Network Address Translation und Masquerading

Als Network Address Translation (NAT) wird die Übersetzung einer IP-Adresse in eine andere bezeichnet. Da private Adressbereiche nicht im Internet geroutet werden, ist dies der normale Weg, um zum Beispiel aus dem heimischen Netzwerk über den DSL-Router ins Internet kommunizieren zu können, da somit nur der DSL-Router eine offizielle IP-Adresse benötigt. Dabei merkt sich der Router, welche interne IP-Adresse sich mit welchem externen Dienst verbinden will. Zu diesem Zweck betrachtet der Router die Quell- und Ziel-IP-Adresse und die Quell- und Zielports. Als Absenderadresse tauscht der Router dann die eigentliche Quell-IP-Adresse durch seine offizielle IP-Adresse aus. Bei den Antwortpaketen auf dieser Verbindung tauscht der Router dann die Adressen wieder zurück (also die offizielle IP-Adresse zurück zur internen).

Diese Variante wird als Source-NAT oder kurz SNAT bezeichnet, da die Quell-IP-Adresse ausgetauscht wird. Der andere Weg, also der Austausch der Zieladresse, wird als Destination-NAT (DNAT) bezeichnet. Dies findet Anwendung, wenn Sie zum Beispiel einen Webserver mit einer internen IP-Adresse betreiben. Der Router muss Anfragen an seine offizielle IP-Adresse auf dem Port tcp/80 entsprechend in die interne IP-Adresse des Webservers übersetzen. Zum Umsetzen von NAT gibt es bei iptables drei Targets: SNAT, DNAT und MASQUERADE.

Quell-Adressumsetzung mit »SNAT«

Die Regel aus Listing 22.81 übersetzt alle ausgehenden Pakete von 192.168.0.25 in die offizielle IP-Adresse 172.16.2.17:

root@saturn:~# iptables -A POSTROUTING -t nat -s 192.168.0.25 \
                        -j SNAT --to-source 172.16.2.17

Listing 22.81    Beispiel für die Umleitung mit »SNAT«

Nach der Angabe des Targets SNAT folgt mit der Option --to-source die Angabe der Quelladresse, auf die die Übersetzung erfolgen soll.

Dabei können Sie auch weitere Einschränkungen vornehmen. So können Sie ein SNAT auch für nur einen Port oder ein Protokoll einrichten. Auch die Einschränkung auf einen Portbereich, in den übersetzt werden soll, kann angegeben werden. Die folgende Regel übersetzt den ausgehenden Webverkehr des Netzes 192.168.100.0/24 in eine feste IP-Adresse. Der dafür genutzte Portbereich ist 15000 bis 20000:

root@saturn:~# iptables -A POSTROUTING -t nat -s 192.168.100.0/24 -p tcp \
                   --dport http -j SNAT --to-source 172.16.2.25:15000-20000

Listing 22.82    Einschränkung des Portbereichs bei »SNAT«

Ziel-Adressumsetzung mit »DNAT«

Das DNAT funktioniert analog zum SNAT. Um beispielsweise eingehende Pakete auf Port 80 an einen internen Webserver weiterzuleiten, genügt die Regel aus Listing 22.83:

root@saturn:~# iptables -A PREROUTING -t nat -p tcp --dport http \
               -j DNAT --to-destination 192.168.100.20

Listing 22.83    Beispiel für die Umleitung mit »DNAT«

Auch das Target DNAT erwartet eine Option, hier die Option --to-destination. Diese gibt die Zieladresse an, in die übersetzt werden soll.

Quell-Adressumsetzung mit »MASQUERADE«

Das MASQUERADE ist eine spezielle Variante von SNAT. Beim SNAT muss die Quelladresse, in die übersetzt wird, fest angegeben werden. Damit Sie SNAT auch in Umgebungen nutzen können, bei denen die externe Adresse dynamisch ist (wie zum Beispiel beim heimischen DSL, bei dem sich meist alle 24 Stunden die offizielle IP-Adresse ändert), wurde das MASQUERADE-Target entwickelt. Listing 22.84 zeigt eine typische MASQUERADE-Regel:

root@saturn:~# iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE

Listing 22.84    Beispiel für die Umleitung mit »MASQUERADE«

Wie Sie Listing 22.84 entnehmen können, wurde bei der Regel keine feste Quelladresse angegeben, sondern nur das ausgehende Interface mit der Option -o. Mit dieser Konfiguration verwendet iptables als Quelladresse immer die gerade aktuelle Adresse des angegebenen Interface.

22.6.11    Weitere nützliche Module für »iptables«

iptables verfügt über viele weitere Module. In diesem Abschnitt wollen wir Ihnen noch zwei Module vorstellen, die Sie zur Steigerung der Sicherheit verwenden können: connlimit und recent.

Verbindungen limitieren: »connlimit«

Das Modul connlimit ermöglicht es Ihnen, die Anzahl der parallelen Verbindungen pro Client oder Netzwerk zu prüfen. Dies kann hilfreich sein, um zum Beispiel sicherzustellen, dass nicht ein Client alle Ressourcen verbraucht. Das Modul connlimit kann zwei Optionen verarbeiten:

  1. --connlimit-above <N>
    Mit dieser Option treffen nur Regeln zu, wenn mehr als <N> Verbindungen bestehen.

  2. --connlimit-mask <PREFIXLENGTH>
    Mit dieser Option können Sie angeben, dass sich das Limit immer auf ein Netzwerk bezieht und nicht auf die Gesamtzahl der Verbindungen.

Um zum Beispiel die gleichzeitigen Verbindungen aus einem 24er-Netz auf Ihren Webserver zu beschränken, können Sie die Regel aus Listing 22.85 verwenden:

root@saturn:~# iptables -A FORWARD -d 172.16.1.1 -m state --state NEW \
                        -m connlimit -p tcp --dport http --connlimit-above 10 \
                        --connlimit-mask 24 -j REJECT

Listing 22.85    Limitierung der Verbindungsanfragen mit »connlimit«

[ ! ]  Ungewollte Sperrungen mit »connlimit«

Eine Verbindungslimitierung ist ein zweischneidiges Schwert. Auf der einen Seite kann sie Angriffsversuche eindämmen oder defekte Clients zähmen, aber auf der anderen Seite können Sie auch Ihre Besucher aussperren. Gerade bei Anwendern hinter einem Proxy-Server kommt es oft zu ungewollten Sperrungen. Da der Proxy als Stellvertreter arbeitet, kommen die Anfragen aller Clients von der gleichen IP-Adresse. Daher können Sie nicht unterscheiden, wer genau die Verbindungen erzeugt. Besonders bei UMTS gibt es bei den meisten Providern Zwangsproxys. Überlegen Sie daher genau, wie hart Sie die Regeln formulieren. Am besten ist es, wenn Sie die Pakete oberhalb des Limits nicht gleich verwerfen, sondern zunächst nur protokollieren. Damit können Sie ein Gefühl dafür bekommen, wie häufig Ihr Limit übertreten wird. Anschließend können Sie Obergrenzen definieren, um Ihre Umgebung vor Überlastung zu schützen.

Dynamische Sperrlisten: »recent«

Das Modul recent ist in der Lage, Absenderadressen einer zutreffenden Regel in eine dynamische Liste zu laden. Diese Liste können Sie wiederum in anderen Regeln verwenden und weiterverarbeiten. Damit können Sie relativ leicht ein kleines Intrusion Prevention System (IPS) aufbauen, das alle Zugriffe von Systemen unterbindet, die unerlaubt versucht haben, einmal (oder mehrfach) mit Ihrem Netzwerk zu kommunizieren. Möchten Sie zum Beispiel eine Blacklist erstellen, die alle Systeme enthält, die versuchen, auf Ihre DMZ mit dem Port 445 (Windows-Dateifreigaben) zuzugreifen, und die dann den Systemen auf dieser Liste jeglichen Zugriff in Ihr Netzwerk untersagt, so müssen Sie die Befehle aus Listing 22.86 absetzen:

iptables -A ext_to_dmz -m recent --update --name blacklist --seconds 60 -j DROP
iptables -A ext_to_dmz -p tcp --dport 445 -m recent --name blacklist --set

Listing 22.86    Erstellen einer »blacklist« mit dem Modul »recent«

Der erste Befehl aus Listing 22.86 prüft, ob eine IP-Adresse auf der Blacklist ist und innerhalb der letzten 60 Sekunden aktiv war (--seconds 60). Falls dem so ist, wird das Paket verworfen (DROP) und der Eintrag aktualisiert (--update), sodass der Timer erneut auf 60 Sekunden gestellt wird. Der zweite Befehl befüllt die Liste. Jedes TCP-Paket an den Zielport 445 wird auf die Blacklist gesetzt.

[+]  Der Port 445 steht hier stellvertretend für beliebige Dienste, die Sie gar nicht anbieten. Wenn Sie lediglich Web- und Maildienste anbieten, ist davon auszugehen, dass es sich bei dem Zugriffsversuch auf den Port 445 um einen Scan nach offenen Freigaben handelt und somit nicht um einen gültigen Kommunikationsversuch.

Die Liste der aktuell gesperrten Adressen können Sie unter /proc/net/xt_recent/<LISTNAME> einsehen. Listing 22.87 zeigt ein Beispiel für eine solche Liste:

root@saturn:~# cat /proc/net/xt_recent/blacklist
src=192.168.0.20 ttl: 64 last_seen: 4354078769 oldest_pkt: 7 4354073600,\
   4354073900, 4354074500, 4354075699, 4354077869, 4354078169, 4354078769

Listing 22.87    Auszug aus der »Blacklist«

[✓]  Im Übrigen werden die Einträge nicht automatisch gelöscht. Wenn die Liste voll ist, wird der älteste Eintrag überschrieben. Standardmäßig fasst die Liste 100 Einträge, wobei Sie beim Laden des Moduls jedoch einen anderen Wert angeben können. Falls Sie mit 1.000 Einträgen arbeiten möchten, können Sie den Befehl aus Listing 22.88 verwenden:

root@saturn:~# modprobe xt_recent ip_list_tot=1000

Listing 22.88    Die maximalen Anzahl von Einträgen in einer Liste erhöhen

[ ! ]  Auch das Modul »recent« hat seine Tücken!

Vorsicht ist geboten, da Sie sich mit dem Modul recent ins eigene Fleisch schneiden können: Mit dem automatisierten Sperren können Sie sich schnell selbst ausschließen. Auch der Ausschluss von Unbeteiligten, wenn zum Beispiel ein Angreifer mit gefälschten Adressen agiert, ist möglich. Damit können Sie unter Umständen schnell gültige und auch gewollte Kommunikation unterbinden. Verwenden Sie das Modul daher mit Bedacht, und überlegen Sie im Vorhinein, welche Konsequenzen auf Sie zukommen können!

22.6.12    Abschlussbemerkung

Mit iptables lassen sich hervorragend Paketfilter-Firewalls aufsetzen. Dank der unzähligen Module können auch die komplexesten Setups und Anforderungen umgesetzt werden – dabei bleiben nicht viele Wünsche offen. Auch etliche kommerzielle Tools oder Appliances nutzen unter der Haube iptables. Das Tool hat sich im Praxiseinsatz millionenfach bewährt und kann bedenkenlos eingesetzt werden.

Oft wird gegen die Nutzung von iptables angeführt, dass es komplex, unübersichtlich und aufwendig sei. Diese Feststellung gilt aber für alle Firewalls. Auch Lösungen mit bedienerfreundlichen GUIs führen im Hintergrund komplexe Berechnungen aus und täuschen die Einfachheit durch die grafische Oberfläche nur vor. Als Firewalladministrator müssen Sie nicht nur die Umgebung, sondern auch die Applikationen, deren Arbeitsweise und Kommunikationsabläufe sehr gut kennen. Ohne dieses Wissen bringt eine GUI Sie nur schneller ans falsche Ziel. Es gilt wie so oft der Grundsatz: »Sie sollten wissen, was Sie tun!«

Aber auch für iptables gibt es gleich mehrere grafische Oberflächen. Eine der bekanntesten und gleichzeitig sehr gut umgesetzen ist Firewall Builder aus dem Paket fwbuilder. Die mit Firewall Builder erstellten Skripte sind gut lesbar und umfangreich dokumentiert. So können Sie leicht überprüfen, ob die Intention einer Regel auch korrekt umgesetzt wurde. Den Firewall Builder finden Sie unter www.fwbuilder.org.