net-it.de

Was ist "Stateful packet filtering" (SPF)?

Wie im gleichnamigen Abschnitt des Firewall-Artikels beschrieben, kann durch Unterscheidung der IP-Verbindungen nach ihrem Verbindungsstatus der IP-Verkehr mit weniger Regeln gesteuert werden. Linux (ab Kernel Version 2.4) kann über das entsprechende Kernel-Modul (ipt_state) den Status von TCP/IP-Verbindungen in die Filterregeln von iptables/netfilter mit einbeziehen.

Der Status einer TCP-Verbindung (TCP state) in nicht gleichbedeutend mit dem Status der ipt_state-Verbindungstabelle (iptables state).

Zum Aufbau einer TCP-Verbindung gehört ein sogenannter Drei-Wege-Handshake, d.b. Sender und Empfänger tauschen drei Pakete aus, bevor die TCP-Verbindung hergestellt ist. Im Gegensatz dazu gilt die Verbindung in Bezug auf iptables/netfilter bereits als hergestellt (State: ESTABLISHED), wenn das zweite Paket als Antwort auf ein vorangegangenes erstes Paket der neuen Verbindung versendet oder empfangen wird. Diese Verbindung ist also bereits hergestellt, obwohl der TCP-Handshake noch nicht vollständig durchlaufen wurde!

UDP-Verbindungen gelten auf der Transportebene als verbindungslos (stateless), aber auch hier gilt in Bezug auf iptables/netfilter eine Verbindung als hergestellt, sobald auf das erste Paket eine Antwort erfolgt.

Zu einer TCP-Verbindung gehören auch ICMP-Pakete, mit deren Hilfe die korrekte Abwicklung des Paketflusses gewährleistet wird. Solche Pakete müssen bei der konventionellen Paketfilterung mittels eigener Regeln explizit erlaubt werden. Beim SPF gelten solchen Pakete als "einer bestehenden Verbindung zugehörend" (State: RELATED).

Was braucht man?

Einen Linux Kernel der Version 2.4.x oder höher und das Programm iptables. Alle modernen Linux-Distributionen sollten diese Komponenten enthalten. Sollte die Verwendung des älteren ipchains zum Installationsstandard gehören (z.B. bei RedHat 7.x), muss dieses zunächst deaktiviert und entladen werden.

Das Konzept

Ich habe viele Beispiele für Konfigurationen von iptables/netfilter gesehen, die die Fähigkeiten des ipt_state-Moduls als zusätzliches Merkmal eines Regelsatzes nutzen, der auch für die konventionelle Paketfilterung gelten könnte oder ursprünglich daher kommt.

Das hier verwendete Konzept verlässt sich voll und ganz auf die korrekte Funktionsweise des ipt_state-Moduls. Sicherheitsfanatikern wird dieses Konzept unter Umständen zu heikel sein. Ich bevorzuge es deshalb, weil es zu den geringsten Prozessorbelastungen und der einfachsten Handhabung führen soll:

- explizites Erlauben aller Pakete bestehender Verbindungen
- explizites Erlauben der ersten Pakete neuer erwünschter Verbindungen
- implizites Verbieten aller anderen Verbindungen oder Pakete

Das Grundgerüst

Zunächst werden die drei Standard-Ketten (chains) INPUT, FORWARD und OUTPUT auf das Ziel (Policy) DROP umgestellt. Damit werden alle Pakete verworfen, die nicht explizit erlaubt wurden.

#iptables -P INPUT DROP
#iptables -P FORWARD DROP
#iptables -P OUTPUT DROP

Anschließend werden die Pakete aller bestehenden Verbindungen und neue Verbindungen zum loopback-interface erlaubt, alle anderen im System-Logbuch (/var/log/messages) verzeichnet. (Je nach Art der Zugriffe auf das loopback-interface können auch zusätzliche Regeln mit der Quell- und Zieladdresse z.B. des ersten Ethernet-Interfaces nötig werden.)

#iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
#iptables -A INPUT -j ACCEPT -i lo -s 127.0.0.1 -d 127.0.0.1 -m state --state NEW
#iptables -A INPUT -j LOG
#iptables -A OUTPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
#iptables -A OUTPUT -j ACCEPT -o lo -s 127.0.0.1 -d 127.0.0.1 -m state --state NEW
#iptables -A OUTPUT -j LOG

Sollen auch Pakete weitergeleitet werden, gilt entsprechendes auch für die FORWARD-Kette. Da implizit weder neue Verbindungen außer von und zum loopback-interface möglich sind (State: NEW) noch ungültige Pakete angenommen werden (State: INVALID) gilt: In diesem Zustand ist jede Kommunikation über andere Netzwerkgeräte (ppp0, eth0 etc.) verboten - alle Pakete werden geloggt und verworfen.

Beispiele

Die IP-Adresse unseres Beispielsystems sei 192.168.1.1 und die einzige Netzwerkkarte des Systems wird über eth0 angesprochen.

Erlaubte neue eingehende Verbindungen werden explizit über

#iptables -I INPUT 2 -j ACCEPT -i eth0 -p Protokoll -s Quelle -d 192.168.1.1 -m state \
--state NEW --sport Quellport --dport Zielport [...]

zugelassen. Soll zum Beispiel ein Webserver Pakete auf dem TCP-Port 80 (http) aus dem gesamten Subnetz heraus annehmen, so wird dies durch

#iptables -I INPUT 2 -j ACCEPT -i eth0 -p tcp -s 192.168.1.0/24 -d 192.168.1.1 -m state \
--state NEW --dport 80

ermöglicht. Diese Regel wird im Betrieb nur dann angewandt, wenn eine neue http-Verbindung zum Webserver aufgebaut wird - also nur für das erste Paket. Alle auf das erste Paket folgenden Pakete werden von der ersten Regel (für bestehende Verbindungen, s.o.) erlaubt.

Erlaubte neue ausgehende Verbindungen werden explizit über

#iptables -I OUTPUT 2 -j ACCEPT -o eth0 -p Protokoll -s 192.168.1.1 -d Ziel -m state \
--state NEW --sport Quellport --dport Zielport [...]

zugelassen. Soll zum Beispiel mit einem Zeitserver über das ntp-Protokoll kommuniziert werden, so wird dies durch

#iptables -I OUTPUT 2 -j ACCEPT -o eth0 -p tcp -s 192.168.1.1 -d ntp1.ptb.de -m state \
--state NEW --sport 123 --dport 123

ermöglicht.

Sonderfall FTP

Bei der Kommunikation über das FTP-Protokoll (aktiv oder passiv) fallen neben der Steuerungsverbindung über den TCP-Port 21 noch davon aus der Sicht von iptables/netfilter zunächst unabhängige Datenverbindungen an.

Die Parameter dieser Datenverbindungen werden über die Paketinhalte der Steuerungsverbindung ausgehandelt. Damit iptables/netfilter diese Datenverbindungen der Steuerungsverbindung zuordnen kann (State: RELATED), muss das Kernelmodul ip_conntrack_ftp geladen werden.

Durch die Analyse der Paketinhalte wird hier die Grenze zur "Stateful Packet Inspektion" (SPI) überschritten.

Beispiel aus der Praxis

Ein Shellskript, dass aus einer iptables-save-Datei erstellt wurde, demonstriert die umfassenden Möglichkeiten, mit iptables/netfilter den Paketfluß zu kontollieren.

zuletzt geändert am 1.7.2003: joerg trawinski

Valid XHTML 1.1! Valid CSS!

© 2003 net-it.de impressum