Tabellen¶

Die Tabellen unterteilen das gesamte Regelwerk nach der grundsätzlichen Aufgabe. Es gibt vier wichtige Tabellen (= Regelsätze):

⚓︎

Es gibt eine fünfte, noch ungebräuchliche Tabelle security. Eigene Tabellen kann man nicht anlegen.

Regelketten¶

Jede Tabelle enthält verschiedene Regelketten.

Es gibt fünf verschiedene Standardketten, davon kommt nicht jede in jeder Tabelle vor. Diese bestimmen, wann ein Paket geprüft wird und unterscheiden, woher ein Paket stammt und/oder wohin es gesendet werden soll:

⚓︎

Man kann in jeder Tabelle zusätzliche Regelketten anlegen, eine solche ist dann aus den Standardketten quasi als Unterprogramm aufrufbar.

Definition der Filterregel¶

In den Regelketten werden die Regeln festgelegt. Dies geschieht über einen Aufruf von iptables im Terminal^[2].

sudo iptables OPTION… 

Bei der Arbeit mit iptables sollte man wegen der Übersichtlichkeit die benötigten Optionen in einer einheitlichen Reihenfolge angeben, z.B.:

iptables «Stelle-im-Regelwerk-und-Art-der-Bearbeitung» «Eigenschaft-des-IP-Pakets»… «Aktion» 

Durch die Notation „«...»“ wird angedeutet, dass hierfür mehrere zusammengehörende Optionen stehen können:

• Für «Stelle-im-Regelwerk-und-Art-der-Bearbeitung» benötigt man die Option -t mit dem Namen einer Tabelle, eine der Optionen -I/A/D usw., ggf. mit einer Regelkette und ggf. eine Zahl zur Angabe der Position in der Regelkette.

• Für «Eigenschaft-des-IP-Pakets» benutzt man die Optionen -i, -o, -s, -d, -p, --sport, --dport und -m und ggf. weitere zusätzliche Optionen. Man muss keinen und kann mehrere Selektoren angeben.

• Die ggf. auszuführende «Aktion» wird mit der Option -j bezeichnet. Man kann höchstens eine Aktion angeben; wenn man für bestimmte IP-Pakete mehrere Aktionen benötigt, muss man mehrere Regeln anlegen.

Dazu kennt iptables eine Vielzahl von Optionen, von den im folgenden einige (primär für die Tabelle filter und die Chains INPUT, OUTPUT und FORWARD) erklärt werden.

⚓︎

⚓︎ Trifft eine Filterregel auf ein Paket zu, muss noch festgelegt werden, wie mit dem Paket verfahren werden soll (Option -j Aktion, siehe oben). Bei normaler Filterung sind die häufigsten Aktionen:

Das sind nur einige wenige Optionen und Aktionen, welche hauptsächlich zur reinen Filterung angewendet werden. iptables kennt noch viele weitere Optionen und Möglichkeiten.

Policy¶

Aufgrund der Vielzahl von Möglichkeiten wird nicht immer für jedes mögliche Paket (d.h. Kombination aus Protokoll, Netzwerkschnittstelle, Port etc.) eine Filterregel existieren. Daher wird für jede Standardkette als Grundsatzregel (policy) eine Methode für den Fall vereinbart, dass keine Filterregel zutrifft.

Die Policy setzt sich aus dem Tabellennamen, dem Namen der Standardkette und der Methode (DROP oder ACCEPT) zusammen. Beispiele:

iptables -P INPUT DROP
iptables -t mangle -P PREROUTING ACCEPT 

Im ersten Beispiel wird festgelegt, dass für die Standardkette INPUT in der Tabelle filter (im Befehl nicht explizit erwähnt, da Standard) alle eingehenden Pakete verworfen werden, sofern sie keiner Filterregel entsprechen. Im zweiten Beispiel wird für die Standardkette PREROUTING in der Tabelle mangle als Standard-Verfahrensweise „vorläufig annehmen“ eingestellt, was auch der Vorgabe für alle Standardketten entspricht.

Für eine selbst definierte Regelkette kann keine Policy festgelegt werden; sie ist unveränderlich immer RETURN.

Regelwerk anzeigen¶

Zur Überprüfung, welche Filterregeln in einer Tabelle bereits hinterlegt sind, kann man diesen Befehl benutzen:

iptables -t filter -L 

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Das funktioniert natürlich auch mit den anderen Tabellen, wenn man anstatt filter deren Namen raw, mangle oder nat einträgt.

In der Grundinstallation von Ubuntu sollten in jeder Tabelle nur leere Standardketten mit jeweils der Policy ACCEPT angezeigt werden.

Die Ausgabe von iptables mit Option -L kann noch mit zusätzlichen Optionen beeinflusst werden:

Im laufenden Betrieb ist zur Kontrolle der Arbeitsweise dieser Befehl praktisch: (Hier am Beispiel der Tabelle nat.)

iptables -t nat -nvL 

Regelsatz löschen¶

Zur Entfernung eines Regelsatzes (also aller Regeln in jeder Regelkette einer Tabelle, hier beispielhaft. mangle) dient dieser Befehl:

iptables -t mangle -F 

Damit werden in selbst definierten Regelketten zwar alle Regeln gelöscht, jedoch die dann leeren Ketten selbst nicht entfernt. Das erfolgt erst mit einem weiteren Befehl, der jedoch nur bei leeren Regelketten funktioniert:

iptables -t mangle -X 

Vorstehende Befehle ändern auch nicht die Policy! Die Rücksetzung auf den Standardwert ACCEPT muss man für jede Standardkette einzeln vornehmen:

iptables -t mangle -L | grep Chain | while read _ Chain _ ; do iptables -P $Chain ACCEPT ; done 

Firewall¶

Im Artikel Router/Paketfilter wird ein mit iptables realisierter Paketfilter als Firewall für einen Router auf der Grenze (border) des eigenen Bereiches zum Internet vorgestellt.

Hier wird zur Illustration der Bedienung von iptables eine rudimentäre Personal Firewall betrachtet, welche

1. die Kommunikation im Rechner intern und

2. im lokalen Netzwerk (hier beispielhaft: 192.168.178/24) uneingeschränkt zulässt,

3. allen Stationen im Internet die Kontaktaufnahme mit diesem Rechner verbietet,

4. dem lokalen Rechner die Kontaktaufnahme zu Stationen im Internet nur über die Protokolle HTTP (= Port 80) und HTTPS (= Port 443) erlaubt.

Zur Einrichtung des Regelwerks ist iptables mehrmals mit folgenden Optionen aufzurufen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

-F									# in Tabelle filter alle Regeln löschen
-X									# in Tabelle filter zusätzliche Ketten löschen
-P INPUT	ACCEPT			 				# Policy für Tabelle filter, INPUT Chain 
-P OUTPUT	ACCEPT			 				# Policy für Tabelle filter, OUTPUT Chain
-P FORWARD	ACCEPT		 					# Policy für Tabelle filter, FORWARD Chain

-N LogDrop
-A LogDrop	-j LOG
-A LogDrop	-j DROP

-A INPUT	-i lo					-j ACCEPT 	# eingehende Kommunikation für lo (Localhost) zulassen
-A INPUT	-m state    --state INVALID,UNTRACKED	-j DROP		# Schrott von draussen verbieten
-A INPUT	-s 192.168.178.0/24			-j ACCEPT	# LAN erlauben
-A INPUT	-m state  ! --state NEW			-j ACCEPT	# Verbindungsaufbau aus dem Internet verbieten
-A INPUT						-j LogDrop	# Catch all

-A OUTPUT	-o lo					-j ACCEPT	# ausgehende Kommunikation für lo (Localhost) zulassen
-A OUTPUT	-d 192.168.178.0/24			-j ACCEPT	# LAN erlauben
-A OUTPUT	-m state    --state RELATED,ESTABLISHED	-j ACCEPT	# ausgehende Pakete für existierende Verbindungen zulassen
-A OUTPUT	-p tcp --dport  80			-j ACCEPT	# Verbindungsaufbau von drinnen für HTTP Verbindungen zulassen
-A OUTPUT	-p tcp --dport 443			-j ACCEPT	#   und ebenso für HTTPS
-A OUTPUT						-j LogDrop	# Catch all

• In der Zeilen 1-5 werden in der Tabelle filter zuerst alle Regeln gelöscht und ggf. verbliebene leere selbst definierte Regelketten entfernt und dann für die Standardketten die Standard-Policy ACCEPT definiert.

• Oft wird empfohlen, die Policies auf DROP zu ändern, weil dann alle „Ports geschlossen werden“ und man dann „sicherer“ wäre. Das beruht auf einem Missverständnis: Da Setzen der Policies selbst ändert gar nichts daran, ob ein Port im fremden Portscanner als „offen“, „geschlossen“ oder „gefiltert“ erscheint. Das Ergebnis des fremden Portscanners kann nur dadurch geändert werden, indem man Pakete tatsächlich verwirft oder nicht verwirft und ob man verworfene Pakete zurück meldet oder nicht. In diesem Beispiel werden die Policies auf dem Standardwert ACCEPT belassen, weil die Policies ohnehin niemals benutzt werden sollen. Dies erfordert Regelsätze, die ausnahmslos jedes Paket erfassen.

• In den Zeilen 7-9 wird eine eigene Regelkette definiert, welche später als Unterprogramm aufgerufen werden kann. Alles was in diese Regelkette gerät, wird im Systemlog notiert und vernichtet.

• Die Zeilen 11 und 17 realisieren Aufgabe 1. Unter Linux läuft ein Teil der Interprozesskommunikation über das (interne) Netzwerk unter Verwendung der Netzwerkschnittstelle lo (z.B. XServer oder CUPS). Blockierung dieser Schnittstelle kann zu Fehlfunktionen bis hin zum Einfrieren/Absturz des Systems führen.

• Zeilen 13 bzw. 18 erlauben eingehenden Verkehr von allen Stationen im LAN (d.h. Absender Adresse in 192.168.178/24) bzw. ausgehenden Verkehr an alle Stationen im LAN (d.h. Empfänger Adresse in 192.168.178/24).

• Zeile 12 ist optional und verbietet mit Hilfe des zusätzlichen Moduls Connection Tracking, hier in der Variante state, Paket mit Sonderstatus INVALID oder UNTRACKED, die aber ohnehin vom Netzwerkstack verworfen würden. Da solcher Schrott auch von Stationen im LAN unerwünscht ist, steht die Regel vor der Regel in Zeile 13. Das Modul state kennt außer diesen beiden auch als Status NEW, ESTABLISHED und RELATED, die in anderen Zeilen verwendet werden.

• Zeile 14 realisiert Aufgabe 3: Nach der Regel in Zeile 13 erreichen nur noch Pakete von Absendern außerhalb des LANs diese Zeile, also aus dem Internet. (Das stimmt nicht exakt, weil es Multicast-Verkehr übersieht! Aber für das Beispiel ist es richtig genug.) Verkehr von Stationen im Internet erlauben wir, aber nur, wenn es keine neue Kontaktaufnahme ist.

• Zeile 15 (und entsprechend auch Zeile 22) übergibt alle restlichen Pakete an die Regelkette LogDrop zur Vernichtung. Es ist eine gute Praxis, die Regelketten immer mit einer solchen "Catch-All"-Regel zu beenden. Alternativ kann man auch andere Aktionen vorsehen oder auch eine reine Zählregel verwenden. Die Aktion LOG macht natürlich nur dann Sinn, wenn man auch regelmäßig die Systemlogs liest. Eine Überwachung und Nachdenken über die Pakete, welche das Ende der Regelketten INPUT und OUTPUT erreichen, sollte sich aber jeder Systemverwalter als Pflicht auferlegen.

• Aufgabe 4: Zeile 19 erlaubt dem lokalen Rechner, bestehende Verbindungen weiterhin aufrecht zu erhalten, indem Pakete an Rechner im Internet gesendet werden. Der Empfang solcher Pakete wurde bereits in Zeile 14 erlaubt. Diese beiden Zeilen erlauben aber noch nicht den Aufbau neuer Verbindungen.

• Um dem lokalen Rechner den Aufbau von Verbindungen zu erlauben, wird dies in Zeilen 20 und 21 explizit erlaubt. Jedoch werden nicht beliebige Verbindungen, sondern nur Verkehr über das Protokoll TCP mit den Zielports 80 und 443 zugelassen.

In der Datei /etc/services befindet sich eine vollständige Liste aller (systemspezifischen) Ports und der zugehörigen Protokolle.

Es handelt sich hier um ein Beispiel und keine vollständig eingerichtete Firewall!

Regelwerk speichern und laden¶

Will man dauerhaft Regeln einrichten, müssen die Regeln in Dateien gesichert und beim Hochlauf wieder aus diesen Dateien in den Kernel geladen werden. Dazu kann man ein Skript verwenden, welches von Init-System (systemd) automatisch gestartet wird.

Das Paket iptables bringt auch die Programme iptables-save und iptables-restore mit, die tun, was ihre Namen versprechen, wenn sie von root benutzt werden.

iptables-save  > /etc/Netfilter
ip6tables-save > /etc/Netfilter-6 

bzw.

iptables-restore  < /etc/Netfilter
ip6tables-restore < /etc/Netfilter-6 

iptables-restore löscht die aktiven Regeln, bevor es die Regeln aus der Datei in den Kernel schreibt. Wenn man dies nicht möchte, sondern die Regeln aus der Datei den aktiven Regelsatz ergänzen sollen, kann man dies mit der Option --noflush erreichen.

Weitere Details kann man der Manpage des Programms entnehmen:

man iptables-save
man iptables-restore 

Alternativ zur Benutzung dieser beiden Programme kann man natürlich auch die vollständigen Befehle für iptables in ein Skript schreiben.

Im UbuntuUsers.de-Wiki gibt es hierfür bereits einige nützliche Skripte:

• IPTadmin – Bash-Skript zum Laden/Überwachen/Sichern/Verwalten von Netfilter-Regelwerken

• nathelper – Perl-Skript zum Einrichten von NAT

In den Ubuntu-Paketquellen gibt es mehrere Hilfsprogramme zur Einrichtung und Verwaltung von Regelwerken, teilweise auch mit graphischer Bedienoberfläche.