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 KonzeptIch 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 Das GrundgerüstZunä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 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 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. BeispieleDie 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 \ 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 \ 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 \ 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 \ ermöglicht. Sonderfall FTPBei 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 PraxisEin 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 |
|
© 2003 net-it.de impressum |