LUGS - Vorträge: Netfilter vom 15.9.2000
LUGS Über die LUGS Statuten und Protokolle Sektionen Terminliste IRC Mailinglisten Kontaktadressen Mitglied werden Internes Mitgliederliste LINUX Was ist Linux?    Screenshots Distributionen    kmLinux Firmen Ressourcen LIB Dokumentation Events Projekte Vorträge Allgemeines ChangeLog Sprache Galerie	Am 15. September 2000 hat Arthur Korn einen Vortrag ueber Netfilter gehalten. Hier eine kleine Zusammenfassung des Vortrags. Nachteile von IPChains Packet passing zum userspace: Dynamische Filter sollten nicht in den Kernel. Kernel Entwicklung ist schwierig und muss in C gemacht werden. Mit Netlink (2.2.x) ist das wiedereinfügen von Paketen langsam und beschränkt. Mischen von filtern und NAT. Verschiedene Pakete durchlaufen die selben Chains. NAT ist nicht transparent für das Filtern. Viele Hacks für transparent Proxys, load balancing, fast NAT (im routing Code). Netfilter http://www.netfilter.org/ 1 Besteht aus: Hooks in den Protokoll Stacks (IPv4, IPv6 und DECnet sind implementiert) (Abb. Hooks) Figure: Netfilter Hooks Einigen Modulen (Abb. Modules) Figure: Netfilter Module Dem Administrationstool iptables libipq (Pakethandling im Userspace) Von Tables und Chains Tables Tabellen mit Mustern und Aktionen, die auf passende Pakete angewandt werden sollen. filter Die Regeln für den Paketfilter. Die Pakete werden nicht verändert, nur gefiltert. Eingebaut sind die INPUT, FORWARD und OUTPUT Chains. nat Die NAT Regeln. Nur das erste Paket einer Verbindung durchläuft diese Tabelle. Kennt die PREROUTING, OUTPUT und POSTROUTING eingebauten Chains. mangle Alle Regeln, die Pakete verändern aber nicht zu NAT gehören - zB mit den TOS und MARK targets - gehören in diese Tabelle. Eingebaute Chains sind PREROUTING und OUTPUT. Chains Teile einer Tabelle. Der Kernel weiss nichts von ihnen. Die Standard Chains: PREROUTING Hier werden uA alle Ziel-Adressmanipulationen vorgenommen. INPUT Nur Pakete für den lokalen Rechner kommen hier vorbei. FORWARD Neu erscheinen hier auch Maskierte Pakete in beiden Richtungen, und zwar unverändert (mit ihrer wirklichen Herkunfts- und Zieladresse.). OUTPUT Alle Pakete von den lokalen Prozessen. Hier werden auch die Ziel-Adressmanipulationen auf lokalen Paketen und andere Veränderungen an den Paketen vorgenommen. POSTROUTING Der richtige Ort für Herkunfts-Adressmanipulationen (also auch Maskierung). Highlights iptables Wie der Kernel Teil von Netfilter ist auch das Administrationstool iptables durch Module erweiterbar. Neu können die Paket- und Bytezähler der Regeln mit -LZ in einer atomischen Operation ausgelesen und Zurückgesetzt werden. Filter limit match Die limit match Erweiterung ist besonders für Regeln mit dem LOG-target oder ICMP interessant, und erlaubt es, die Anzahl der passenden Pakete pro Zeiteinheit einzuschränken. Ein kleines Beispiel: $ iptables -P FORWARD DROP $ iptables -A FORWARD -p tcp --dport 31337 -m \ limit --limit 1/hour --limit-burst 5 -j LOG state match Verbindungs-Status Informationen können nun auch im Paket Filter verwendet werden: $ iptables -N int2lan $ iptables -A int2lan -m state --state ESTABLISHED,RELATED -j ACCEPT $ iptables -P int2lan DROP -in-interface und -out-interface In den INPUT bzw OUTPUT und FORWARD chains. Wunderbar für sowas: $ iptables -A FORWARD -i ppp0 -o eth0 -j int2lan LOG target Ersetzt den -l Schalter von ipchains. Die Wichtigkeit der Nachrichten und ein Prefix können neu frei eingestellt werden, ausserdem werden wahlweise TCP-Optionen, TCP-Sequence-numbers und IP-Optionen mit geloggt. REJECT target Freundlichere Variante von DROP. Sendet standardmässig eine ICMP ``port-unreachable'' Nachricht zurück, kann aber auch diverse andere Nachrichten erzeugen. NAT Transparent Pakete deren Herkunftsadresse verändert wird, erscheinen für den Filter unverändert, dagegen werden die Ziel-Adressmanipulationen schon in der PREROUTING Chain gemacht, die effektiven Zieladressen sind also im Filter sichtbar. Intelligente Zuordnung iptable_nat versucht möglichst wenig an den Paketen zu verändern (zB werden Verbindungen von Ports >512, zu ebensolchen zugeordnet, genau so wie Ports ]512,102[ und <1023). Implizites NAT bei Kollisionen mit lokalen Verbindungen. Es ist kein Problem SNAT auf Adressen zu betreiben, die ``hinter'' dem betreffenden Router von anderen Interfaces verwendet werden. Es können auch mehrere Regeln in überlappende Adressbereiche abbilden. DNAT macht ein einfaches LRU-Loadbalancing wenn mehrere Zieladressen gegeben sind. Das Linux Virtual Server Project hat eigene Module entwickelt, die cleverer versuchen, die Last zu verteilen. Footnotes http://www.netfilter.org/ Hier gibt es sehr gute Dokumentation: Networking Concepts HOWTO, Linux 2.4 Packet Filtering HOWTO, Linux 2.4 NAT HOWTO und netfilter hacking HOWTO.