Firewalling im neuen Kernel

Brandneuer Schutz

von Frank Bernard

In der kommenden Linux-Version 2.4 gibt es neue und erweiterte Funktionen für den Betrieb als Firewall oder Router. Dieser Artikel will die Neuerungen vorstellen und Umstiegsmöglichkeiten aufzeigen.

Beständig ist bei Linux nur der Wechsel. Deshalb wird mit Kernel-Version 2.4 auch mittlerweile zum zweiten Mal die Paketfilterschicht ausgetauscht. Nach ipfwadm und ipchains ist jetzt netfilter angesagt. In schöner Tradition gibt es aber Kernel-Module, die ipfwadm- oder ipchains-Kommandos ermöglichen, so daß der Übergang nicht hart sein muß. Nur wer bisher ipfwadm und ipchains gleichzeitig benutzt, hat jetzt ein Problem : er muß sich für eines entscheiden oder besser gleich auf netfilter übergehen.

Entwickler von netfilter ist Paul "Rusty" Russell, der auch ipchains gemacht hat. Insofern kann man erwarten, daß ipchains nicht nur weiterentwickelt, wurde, sondern so fundamentale Änderungen erfahren hat, daß nicht nur eine neue Version, sondern gleich ein anderer Name nötig waren. Und das ist tatsächlich so.

Da im Folgenden oft von NAT, Masquerading und transparenten Proxies die Rede sein wird, hier eine kurze Beschreibung : wenn man eine Verbindung zu einem Provider über ISDN oder Modem herstellt, bekommt man eine "offizielle" IP-Adresse, die auch bei jedem Einwahlvorgang anders sein kann, für die Dauer der Verbindung zugeteilt. Wenn man mehrere Rechner im Internet betreiben will, muß man entweder jeden mit einem Modem oder einer ISDN-Karte und Telefonanschluß ausstatten oder man deutet einen Rechner im eigenen lokalen Netz aus, der diese Verbindungsmöglichkeit hat und die Pakete weiterschickt (Gateway). Da dies alleine nicht genügt - die lokal verwendeten Adressen erscheinen dann am nächsten Router, dem diese Adressen unbekannt sind und die Pakete wegwirft - muß auf dem Gateway eine Umsetzung der lokalen Adressen auf die einzige offizielle Adresse stattfinden(maskieren : Masquerading). Damit nun der Gateway bei ankommenden Paketen unterscheiden kann zwischen Paketen für sich selbst und Paketen für andere LAN-Rechner, hält dieser Gateway Tabellen mit Verbindungsinformationen über die wahren Ziele im LAN, ersetzt die Zieladresse im LAN und leitet die Pakete ins LAN.

Masquerading
 
Original Quelle maskierte Quelle Ziel
Adresse Port Adresse Port Adresse Port
192.168.1.2 1036 11.22.33.44 12345 10.17.89.12 80
192.168.1.3 2345 11.22.33.44 12346 67.87.34.14 80
192.168.1.4 2244 11.22.33.44 12347 34.64.75.8 80
192.168.1.5 23579 11.22.33.44 12348 2.33.111.55 80

Masquerading bildet also lokale Adressen auf offizielle Adressen im Verhältnis n:1 ab. NAT (Network Address Translation) ist die Verallgemeinerung von Masquerading und macht eine Abbildung n:m, wobei auch n=m sein kann. Bei NAT werden also n interne Adressen auf m externe Adressen abgebildet.

NAT

Unter RNAT (Reverse NAT) wird hier verstanden, daß eingehende Verbindungswünsche auf unterschiedliche interne Server verteilt werden, also z.B. HTTP auf einen anderen Server als FTP. Ein Teil der Funktionalität von RNAT ist als "port forwarding" aus früheren Erweiterungen zu ipchains bekannt, mit RNAT läßt sich aber auch load balancing realisieren.

RNAT

Ein Proxy ist aus den Browser-Einstellungen bekannt und dient dazu, einen Rechner zu benutzen, der Anfragen weiterleitet. Dies kann aus Caching-Gründen geschehen, aber auch deswegen, weil nur dieser Rechner direkten Zugang ins Internet hat. Bei einem normalen Proxy ist dieser Rechner also sichtbar und muß sogar explizit eingestellt werden. Ein transparenter Proxy hingegen ist für den benutzenden Rechner unsichtbar und erfüllt seine Aufgabe dadurch, daß er Pakete für das Internet auf sich selbst umleitet und als "man-in-the-middle" die Quell- und Ziel-Adressen der Pakete für die beteiligten Partner manipuliert, und zwar so, als sei er gar nicht da. Bei einem transparenten Proxy wird also beim Browser "direkter Internet-Zugang" eingestellt.

Während bisher ein Kommando (ipfwadm bzw. ipchains) genügte, um alle Funktionen abzudecken, gibt es nunmehr mit iptables und ipnatctl zwei Kommandos, die unterschiedliche Bereiche abdecken. Mit iptables werden wie bisher Paketfilterregeln angegeben, mit ipnatctl kann man masquerading und NAT vornehmen. Will man einen transparenten Proxy bereitstellen, konnte man Paketfilterregeln und Masquerading zusammen mit "ipchains ... -R" angeben. Nunmehr gibt man mit iptables die Regeln an und mit ipnatctl nimmt man das Masquerading vor.

Für Benutzer, die bislang ipfwadm und ipchains nehmen, bleibt der Trost, daß ein harter Umstieg auf die neuen Konzepte nicht zwangsläufig nötig ist. Es gibt zwei Kompatibilitäts-Module, die mit insmod in den Kernel geladen werden können und dann die gewohnte Umgebung zur Verfügung stellen. Dabei kann aber nur entweder ipchains oder ipfwadm geladen werden. Zumindest für ipchains kann man sagen, daß diese Umsetzung beeindruckend gut gelungen ist, sogar die bislang gewohnten Log-Meldung erscheinen bei geloggten Paketen, so daß auch Prozeduren, die Angriffe auf dieser Basis klassifizieren, weiterhin laufen.

Nicht mehr benutzbar hingegen ist die undokumentierte Kernel-Schnittstelle für transparente Proxies, bei der mit getsockname das tatsächliche Ziel erfragt werden konnte. Hier gibt es eine wrapper-Funktion nf_getsockname, die man in die Programme einbauen kann und 2.2-kompatibel ist. Diese Funktion benutzt die neue Socket-Option SO_ORIGINAL_DST und hebt damit das undokumentierte Schattendasein auf eine offizielle Basis. Transparente Proxies müssen also zumindest diese Wrapper-Funktion einbauen und neu übersetzt werden. Für einen Umstieg von ipfwadm/ipchains auf netfilter besteht kein Grund zur Eile, diese Schnittstellen werden mindestens bis 2003 unterstützt werden.

Neu gefaßt wurde der Paketlauf durch die Netzwerk-Schnittstellen. Bisher war für eine TCP-Verbindung vom LAN ins Internet über den Firewall die Angabe von insgesamt sechs Regeln nötig : jeweils für Hin- und Rückweg je eine input-, forward- und output-Regel. Für das verbindungslose UDP galt analog dasselbe, für ICMP ("ping") mußte ohnehin anders verfahren werden.

Paketfilterregeln bisher

Jetzt benötigt man nur noch zwei Regeln, nämlich eine forward-Regel für Hin- und Rückweg. Die entscheidende Verbesserung besteht darin, daß man zwei Netzwerkschnittstellen für input und output angeben kann, so daß der Paketweg eindeutig wird. Für transparente Proxies ist nach wie vor die Angabe von vier Regeln notwendig, jeweils für Hin- und Rückweg eine für input und output.

Paketfilterregeln neu

Das reduziert die Anzahl der Paketfilterregeln erheblich und trägt zur Übersichtlichkeit und etwas zur Performance bei. Bei bisher 300 Regeln für einfache und weit über 1000 Regeln für komplexe Firewall-Konfigurationen bedeutet diese Reduzierung einen großen Fortschritt. Schon alleine deshalb lohnt der Umstieg für professionelle Anwender. Aber es gibt noch weitere Verbesserungen.

Sowohl auf Kernel-Ebene in Form von Modulen als auch zum iptables-Kommando kann man nun eigene Erweiterungen vornehmen. Man kann zum erstenmal Regeln mit MAC-Adressen angeben, die es erlauben, Pakete speziell für dieses Gerät zu wählen, unabhängig von seiner IP-Adresse. Für Firewalls sehr wichtig ist auch die limit-Option, mit der man das Logging von Paketen beschränken kann. Nach einer angegeben Anzahl von Paketen ist für eine angegebene Zeit Schluß mit dem Logging, was natürlich eine syslog-Flutung (ein möglicher Firewall-Angriff) verhindert. Auch lassen sich jetzt mit der state-Option Regeln auf der Basis eines bestehenden Status' angeben, nicht nur für Verbindungsbeginn und -ende, sondern auch für die verbindungslosen Protokolle UDP und ICMP, etwa für DNS-Anfragen und ICMP-Fehlerrückmeldungen.

Die Entwicklung von VPNs (Virtual Private Networks) mit dem Projekt FreeS/WAN ist ein verwandtes Projekt, was jedoch bislang nicht ausreichend integriert wird. Bei VPNs werden Pakete u.U. in andere Pakete verpackt (Tunneling), es werden Paketinhalte authentifiziert und kryptographiert und möglicherweise umaddressiert. Auch für IPv6 (IPng) gibt es bislang keine Integration in netfilter. Ob eine Erweiterung des iptables-Kommando dafür ausreicht, wird die Zukunft zeigen. Aber immerhin stellt netfilter einen Mechanismus bereit, mit dem man anfangen kann, solche Probleme zu lösen.

Ansatzweise wurde an einer dynamische Optimierung der Regeln bereits zu Zeiten von ipchains gearbeitet. Das betrifft etwa die Umordnung von Regeln nach Häufigkeit oder die Zusammenfassung von mehreren Regeln zu einer, ähnlich einem hochoptimierendem Compiler. Durch den neuen Ansatz von netfilter ist es jetzt einfacher möglich, Arbeiten an einer Optimierung voranzutreiben.

Trotz aller Verbesserungen bleibt netfilter nach wie vor der Assembler eines Firewall : man gibt an, wie etwas gemacht wird. Darüberliegende Softwareschichten müssen eine objektorientierte Sicht der Dinge realisieren, also dafür sorgen, daß ein Administrator angeben kann, welche Dienste von wem wohin erlaubt sind. Wie auch beim Assembler für Prozessoren ist das Paket nur für Experten geeignet, der durchschnittliche Systemadministrator ist damit überfordert. Bis zur Benutzung in einer objektorientierten standardisierbaren Umgebung ("C/C++"), die eine formalisierbare Umsetzung der Sicherheits-Policy erlaubt und auch Authentifizierung, Logging und VPN mit integriert, ist es noch ein weiter Weg.

Paul Russell hat eine grandiose Arbeit gemacht, die nur durch Sponsoring von Watchguard möglich war, aber nun allen Linux-Benutzern zugute kommt. Neben der Festeinstellung von führenden Köpfen der Linux-Szene ist das projektbezogene Sponsoring ein mittlerweile fest etablierter Bestandteil der Open-Source-Bewegung. Im eigenen Rahmen sollte sich jede Firma überlegen, wieviel Nutzen und Ersparnis sie durch den Einsatz von Linux hat und inwieweit sie Weiterentwicklung von Linux unterstützen kann. Neben der Festeinstellung von Mitarbeitern ausschließlich für Linux, der Finanzierung von Projekten bei denen Linux verwendet wird oder der Entwicklung von Treibern gibt es auch noch die Möglichkeit, die Linux-Bewegung durch den Kauf von Linux-Produkten zu unterstützen. Und schlußendlich kann man mit TUX am Revers herumlaufen und sich damit als Linuxer outen.

Infos:
[1] netfilter Paket : z.B. http://www.samba.org/netfilter
[2] FreeS/WAN : http://www.freeswan.org
[3] IPv6/IPng : http://www.ipv6.org
[4] Brandschutz-2.2, Linux-Magazin 06/99, Brandschutz-2.2

Der Autor:

Frank Bernard ist Diplom-Informatiker und beschäftigt sich seit mehreren Jahren mit Firewalling. Seit Kernel-Version 0.99.12 (1992) will er als Linux-Fan und -Enthusiast jeden Rechner mit dem richtigen Betriebssystem ausstatten. Er ist Inhaber der "Frank Bernard Informationstechnik GmbH", die sich mit Internet-Sicherheitslösungen - natürlich auch mit dem selbst entwickelten LinuxWall (www.linuxwall.de) - beschäftigt. Zu erreichen ist er unter fbit@fbit.de.