• Zielgruppen
  • Suche
 

Kurzüberblick IPTables

Hier soll nur ein Kurzüberblick über IPTables gegeben werden. Dieser richtet sich an Administratoren, die bereits das IP-Protokoll und Paketfilter unter Unix wie z.B. das alte IPChains kennen. Auch sollte die genaue Syntax der nötigen iptables-Aufrufe der Manpage entnommen werden. Auf ausführlichere Informationen wird auf der Seite Paketfilter für Linux verwiesen.

Filteraufbau

Eine Chain unter IPTables ist eine geordnete Liste von Einzelregeln, die sequentiell abgearbeitet wird (s.u.). IPTables besteht grundsätzlich aus drei Standardchains: INPUT, OUTPUT, FORWARD. Jedes Datenpaket, dass über ein Netzwerkgerät (z.B. Ethernetkarte eth0, Loopbackdevice lo) ankommt (INPUT) oder versendet werden soll (OUTPUT), jedes Paket, das der Rechner nur weitervermittelt (FORWARD) durchläuft grundsätzlich nur eine Chain:

Workstation und Server-Absicherung

Da es hier nur um die Absicherung von einzelnen Linux-Rechnern geht, soll auf die Besonderheiten von Network Address Translation (NAT) o.ä. nicht eingegangen werden. Auch sollte ein Rechner normalerweise nicht zwischen Netzen routen, daher wird die FORWARD-Chain nicht weiter betrachtet, die Chain sollte mit iptables -P FORWARD DROP gesperrt werden.

Neben der FORWARD-DROP-Regel sollte das Forwarding gar nicht erst aktiviert werden. Normalerweise ist eine Aktivierung über /proc/sys/net/ipv4/ip_forward nötig, unter Debian geschieht dies über einen Eintrag in /etc/network/options.

Man kann in den Filterregeln IP-Spoofing explizit unterbinden. Leichter ist es aber, IP-Spoofing bereits im Routing zu verbieten. Spoofprotection muss normalerweise über /proc/sys/net/ipv4/*/rp_filter explizit aktiviert werden,  unter Debian ist es bereits Standard über einen Eintrag in /etc/network/options.

INPUT- und OUTPUT-Chain

Jedes Datenpaket durchläuft also eine Chain. Eine Chain ist eine Abfolge von Regeln, die in fest definierter Reihenfolge geprüft werden. Eine einzelne Regel enthält Bedingungen (z.B. Ziel ist IP xy) und ein Target. Erfüllt ein Datenpaket die Bedingung, so entscheidet das Target, was mit dem Paket passieren soll und die nachfolgenden Regeln werden nicht mehr geprüft ("first match").

Hat man z.B. eine Regel, die ssh-Zugriffe aus dem Uni-Netz zulässt, und danach eine Regel, die ssh-Zugriffe generell verbietet, so werden ssh-Zugriffe nur aus der Uni zugelassen. Dreht man die Regeln um, ist kein ssh-Zugriff mehr erlaubt, die Uni-Regel würde dann für ssh-Zugriffe überhaupt nicht mehr durchlaufen.

Targets

Die häufigsten und auch als Chain-Policy verwendbaren Targets sind

  • ACCEPT: das Paket wird durchgelassen.
  • DROP: das Paket wird verworfen, d.h. nicht durchgelassen und der Absender wird auch nicht informiert.

Es gibt noch zusätzliche Targets, für die z.T. weitere Kernel-Module geladen werden. Interessant sind dabei:

  • REJECT: das Paket wird abgelehnt, d.h. nicht durchgelassen, aber der Absender wird mit einer ICMP-Meldung (port-unreachable) darüber informiert.
  • REJECT --reject-with tcp-reset: ist eine Unterform der REJECT-Regel für TCP-Pakete, jedoch wird der Absender nicht mittels ICMP benachrichtigt, sondern die TCP-Verbindung wird regulär geschlossen (interessant für ident-Anfragen bei Timeouts).
  • LOG: Hiermit können Informationen über die Logfunktionen des Kernels aufgezeichnet werden.

Bedingungen

Meist steht am Anfang jeder Kette eine Regel, die alles erlaubt, was mit erlaubten Dingen im Zusammenhang steht: Antworten auf DNS-Anfragen, Antwort-Pakete in TCP-Verbindungen etc.:

  • -m state: Dieses Modul erlaubt die Prüfung des Verbindungs-Status eines Pakets,Regeln der Form -m state --state RELATED,ESTABLISHED -j ACCEPT machen aus IPTables eine Stateful-Firewall.

Die am meisten benutzten Regeln dürften sich auf Protokoll (ICMP, TCP, UDP), auf IP-Adresse von Quelle/Ziel und ggf. auf die Port-Nummer Quelle/Ziel (meist eher Ziel) beziehen. Die folgenden Bedingungen können dabei in einer Regel vermischt werden (wirkt wie Und-Verknüpfung), meist ist eine Negation mit ! möglich:

  • Protokoll: -p tcp|udp|icmp
  • Ziel-IP: -d ipnummer oder -d ipnetznummer/netmask
  • Ziel-Port: --dport portnummer oder --dport startport:endport
  • Quell-IP: -s ipnummer oder -d ipnetznummer/netmask
  • Quell-Port: --sport ipnummer oder --sport startport:endport

Zusätzlich gibt es weitere Bedingungen, die meist in Kernel-Modulen implementiert sind. Interessant zur Vermeidung von Bruteforce-Angriffen, Denial-of-Service-Attacken und sogar Port-Scans sind noch die Limit-Regeln:

  • -m limit: Kann die Rate von Paketen (z.B. auch die von TCP-Verbindungsaufbauten) begrenzen; zum Einen durch ein Maximum, zum Anderen durch eine danach wirksamene Durchschnittsbegrenzung.
  • -m connlimit: Hiermit kann die Zahl der gleichzeitigen Verbindungen begrenzt werden. Das kann sowohl die maximale Anzahl insgesamt sein, aber auch z.B. eine Verbindung je Host.

Jedoch ist die Implementierung dieser Limit-Regeln nicht so einfach. Sie sollten hierfür speziell für Ihren Wunsch im Internet nach Beispielen suchen oder die ausführlichen Tutorials zu IPTables befragen.

Chains

Will man sehr viele Regeln einpflegen, so verliert man leicht die Übersicht. Eine Möglichkeit, die sich auch in der Testphase anbietet, ist die Verwendung von benutzereigenen Chains. Man kann Chains selbst anlegen, und diese von einer Regel aus als Target anspringen. Beispielsweise könnte man eine eigene Chain mit Limit-Regeln erstellen und diese dann am Anfang der INPUT-Chain einfügen. Dieses hat die Wirkung, als würde man die Regeln der eigenen Chain direkt am Anfang der INPUT-Chain einfügen:

Ebenso ist es denkbar, dass die eigene Chain nur unter gewissen Bedingungen angesprungen wird. Zum Beispiel könnte eine Sammlung von Limit-Regeln nur für Quell-IPs außerhalb des UH-Netzes gelten, indem die eigene, limitierende Chain nur für -s !130.75.0.0/16 als Target angegeben wird.

Eine benutzerdefinierte Chain allein hat keine Wirkung, erst durch das Einhängen (d.h. als Target in einer Regel) in eine der drei Standard-Chains erlangt eine eigene Chain Bedeutung.

Chain-Verwendung in Debian-ifup/down

In der für Debian vorgeschlagenen Lösung, IPTables an den Ifupdown-Mechanismus zu koppeln, werden ebenfalls eigene Chains benutzt. Dort werden die eigenen Chains eigentlich nicht als Unterlisten verwendet, sondern zur Trennung je nach Interface: