Brandschutz-2.2

von Frank Bernard

Mechanismen und Möglichkeiten für Firewalls des neuen Linux-Kerns

Kein anderer Markt innerhalb der IT hat solche Wachstumsschübe wie die Rechner-Sicherheit. Durch die zunehmende Vernetzung der Firmen und die Anbindung an das Internet muß, das ist mittlerweile sogar Entscheidern klar, das eigene Netz nicht nur vor Viren, die offline per Datenträger eingeschleppt werden, sondern auch vor Hackern, die online arbeiten, geschützt werden. Ist eine Firma direkt an das Internet angebunden, dauert es meist nicht lange bis zum ersten Einbruchsversuch. Der Rekord des Autors liegt bei 4 Stunden vom Anschluß einer Firma bis zum ersten Einbruchsversuch aus dem Internet. Ohne Firewall merken die Unternehmen noch nicht einmal, daß Einbrüche stattfinden.

Ein Firewall soll heutzutage eine Vielzahl von Aufgaben wahrnehmen, von denen der Schutz des lokalen Netzes nur die wichtigste aber bei weitem nicht die einzige ist. Er soll

Eines ist bei dieser Liste, die keinen Anspruch auf Vollständigkeit erhebt, völlig klar : mit einem klassischen Paketfilter alleine ist diese Liste nicht abzuhandeln. Bei dem Kauf eines Firewall hat man die Qual der Wahl unter hunderten. Wenn man das Wort "Firewall" durch das Wort "Auto" ersetzt (ich kaufe mir ein Auto), weiß man, warum die Preisspanne auch zwischen dem eines zehn Jahre alten Uno und einer fabrikneuen RollsRoyce-Flotte schwankt. Und ähnlich wie beim Neuwagenkauf muß man sehr genau auf die Serienausstattung schauen. Wenn überhaupt möglich, sind für einen Firewall mit allen genannten Eigenschaften sechsstellige Beträge fällig.

Aber es geht auch preiswerter und ohne Qualitätsverlust : mit Linuxwall.

Warum Linux?

Nun, zuallererst wegen der Stabilität. Linux läuft wie anno dunnemals der VW Käfer und muß nicht wie andere Betriebssysteme jede Woche mindestens einmal gebootet werden.

Es soll Administratoren geben, die einen dringend nötigen Hardware-Update des Rechners vermeiden, damit nicht der Uptime-Rekord (cat /proc/uptime) gefährdet wird. Der Netzwerkteil ist ausgereift und kann dem Vergleich mit anderen Unix-Betriebssystemen standhalten.

Als nächstes Argument ist die Verfügbarkeit zu nennen. Für kein anderes Betriebssystem gibt es derart viele Kernel-Features und (freie) Tools wie für Linux. Zu jedem, wirklich jedem Anwendungsfall hat sich irgend jemand in der Linux-Gemeinde schon einmal Gedanken gemacht und etwas darüber geschrieben oder gar ein Programm veröffentlicht. Mag sein, daß manchmal die Begeisterung die Kompetenz überwiegt, trotzdem lohnt sich die Suche nach einem Startpunkt, der Arbeit vermeidet.

Der Linux-Kernel bietet eine Fülle von Möglichkeiten, um einen Firewall zu realisieren. Das galt für 2.0, in 2.2 hat sich Erhebliches getan. Die Aktualität von Treibern hinkt im Moment dem "Programmlader mit GUI" noch etwas hinterher. Man sollte nicht die allerneueste Hardware einsetzen, wenn man nicht sicher weiß, daß es dazu einen Linux-Treiber gibt. Das Warten von ein bis zwei Monaten wirkt da oft Wunder. Sehr oft sind hingegen kommerzielle Firewalls mit anderen Unix-Derivaten entwickelt und nur auf ganz speziellen Hardwareplattformen (sprich alten) lauffähig. Da kann dann ganz schnell ein Ersatzteilproblem entstehen, das man mit Linux wegen der großen Verbreitung nicht hat.

Die Skalierbarkeit ist hingegen unerreicht. Es gibt einen inoffiziellen Wettbewerb, wer Linux auf dem minimalsten und auf dem maximalstenr Rechner betreiben kann. Die Spanne reicht dabei von einem 2-MB-386 bis zu dem Clone-Projekt (Linux-Magazin 2/99) mit über 500 Knoten. Der Autor hat seinen ersten Linux-Firewall mit einem plattenlosen ausgedienten 8-MB 386 entwickelt, der per Diskette bootet und sein root-Dateisystem von einem anderen Linux-Server via NFS bezieht.

Und da ist da noch die Hilfsbereitschaft. Andere Betriebssysteme sollen den Vorteil haben, daß der Hersteller für das Betriebssystem geradesteht und Fehler behebt, sobald diese entdeckt werden. Je nach Hersteller kostet das unterschiedlich viel Geld und im Fehlerfall zusätzlich viel Zeit und Nerven. Es bringt meist wenig bis gar nichts. Linux hat keine Herstellerfirma, die ich als IT-Verantwortlicher verantwortlich machen kann (CYA : Cover Your A..) und deshalb ist es den meisten Entscheidern suspekt. Jedoch ist es mit Linux dem Autor mehrmals passiert, daß in wirklich hoffnungsloser Lage nach dreitägigen Tests und dem ersten Hilferuf mit allen Fakten in die Newsgruppen binnen eines Tages mehrere funktionierende Problemlösungen, zum Teil von den Entwicklern selber, vorlagen. (Fußnote : jemand fragte in einer Newsgruppe einmal, wie man unter bash die Versionsnummer herausbekommt. Nach 5000 Antworten hat er "Danke, jetzt bitte keine weiteren Antworten mehr" gemailt). Die Fehlerbehebung ist bei Linux schneller als bei irgendeinem anderen Betriebssystem. Für einen illegalen Befehl des Pentium, der im User-Mode den Rechner lahmlegte, war innerhalb von zwölf Stunden ein Patch für Linux verfügbar. Intel bestätigte die Richtigkeit dieses Patches und alle anderen Betriebssystem haben dann nur noch abgeschrieben.

Ein ganz wesentlicher Faktor ist auch die Transparenz. Man kann - im Gegensatz zu allen anderen Firewall-Anbietern - beweisen, daß im Firewall keine Hintertürchen vorhanden sind.

Und schließlich der Preis. Das gesamte Betriebssystem, die Dienstprogramme und fast alle sonstigen Teile sind frei und kosten nichts. Der einzige Aufwand, aber der kann für die angesprochenen Aufgaben ganz erheblich sein, ist die Arbeitskraft, die man aufwenden muß, alle freien Teile zu sammeln und zusammenzukleben.

Kerniges

Der neue Linux-Kern bietet eine Reihe von Eigenschaften, die Firewalling unterstützen. Zusätzlich gibt es für Spezialanwendungen wie VPN noch externe Kernel-Patches.

Da ein Linux-Firewall auch gleichzeitig Router ist, läßt sich diese Kombination feiner einstellen als bei getrennten Geräten. Es empfiehlt sich generell, an einem Linux-Firewall die vielen Netzwerksegmente eines LANs zusammenzuführen, bei den heute üblichen Mehrfach-Ethernetkarten bis zu 16 Segmente. Bei anderen Firewalls ist die Anzahl der Netzwerkschnittstellen auf zwei oder drei begrenzt und deshalb hat man diesen Freiheitsgrad nicht.

Paketfilter

Das Programm ipchains ist die Benutzerschnittstelle zum Paketfilter im Kern. Je Aufruf des Programms wird eine Regel für IP-Pakete angegeben, andere Protokolle (z.B IPX oder NetBEUI) können nicht behandelt werden. Eine Regel gibt die Eigenschaften eines Paketes an und definiert eine Aktion, wenn das Paket allen angegebenen Eigenschaften entspricht. Die Eigenschaften sind u.a.

Auf die Angabe der Eigenschaften folgt eine Aktion :

Zusätzlich kann ein Paket, das alle angegebenen Eigenschaften erfüllt, an das Kernel-Logging übergeben und/oder an das Netlink-Gerät (s.u.) weitergereicht werden.

Durch eine Verknüpfung von Eigenschaften und Aktion lassen sich einzelne Regeln angeben, z.B. akzeptiere ein eingehendes Paket an Schnittstelle eth0 von beliebigem Rechner und beliebigem Port zum Rechner 123.234.1.2 Zielport 80; als Befehl ipchains -A input -i eth0 -d 123.234.1.2 80 -j ACCEPT

Für eine normale TCP-Verbindung über den Firewall sind sechs Regeln notwendig, jeweils drei für den Hin- und drei für den Rückweg. Wenn wir z.B. Web-Zugriffe aus dem lokalen Netz ins Internet zulassen wollen, so lauten diese Regeln mit dem lokalen Netz 212.212.212.0/24 an eth0 und dem Internet an eth1 :

LAN=212.212.212.0/24
ipchains -A input -i eth0 -p tcp -s $LAN -d 0.0.0.0/0 80 -j ACCEPT (Input vom lokalen Netz)
ipchains -A forward -i eth1 -p tcp -s $LAN -d 0.0.0.0/0 80 -j ACCEPT (Übergabe an eine andere Schnittstelle)
ipchains -A output -i eth1 -p tcp -s $LAN -d 0.0.0.0/0 80 -j ACCEPT (Ausgabe ins Internet)

ipchains -A input -i eth1 -p tcp -s 0.0.0.0/0 80 -d $LAN -j ACCEPT (Input vom Internet)
ipchains -A forward -i eth0 -p tcp -s 0.0.0.0/0 80 -d $LAN -j ACCEPT (Übergabe an eine andere Schnittstelle)
ipchains -A output -i eth0 -p tcp -s 0.0.0.0/0 80 -d $LAN -j ACCEPT (Ausgabe ins lokale Netz)

PaketEine typische Paketfilterschicht eines Firewall besteht aus hunderten von Regeln. Die erste passende Regel mit einer echten Aktion wird genommen und ausgeführt. Eine einzige Regel, die falsch angegeben ist, kann ein fatales Sicherheitsloch sein. Es ist deshalb immer anzuraten, die Regeln so eng wie möglich anzugeben und dann erst bei Bedarf zu erweitern. Als letzte Regel für die drei Ketten (ipchains) input, forward und output wird deshalb von mir immer eine "Log-Regel" angegeben. Die gilt für alle Pakete, die bis zum Ende der Ketten gelangt sind und bislang noch nicht paßten. Sie werden abgelehnt und gleichzeitig im syslog ausgegeben, so daß dann eine passende Regel angegeben werden kann.

Nehmen wir nun den Fall, daß wir nur eine einzige echte (feste) Internet-Adresse benutzen. Dann wird das interne Netzwerk "maskiert", d.h. auf dem Firewall werden die Netzwerkverbindungen umgesetzt. Ein Beobachter im Internet sieht einen einzigen Rechner, der viele Verbindungen zu verschiedenen Zielen hat, ein Beobachter im lokalen Netzwerk sieht direkte Verbindungen zu den Zielrechnern. Die Verallgemeinerung der Maskierung (masquerading), bei der eine n:1-Beziehung realisiert wird, heißt NAT (Network Address Translation). Bei NAT wird eine m:n-Zuordnung gemacht. Im Firewall wird eine Tabelle geführt mit der Zuordnung von vermeintlichen Verbindungen zwischen Client und Server, Verbindungen zwischen Client und Firewall sowie maskierten Verbindungen zwischen Firewall und Server. Für den Client ist bei Masquerading der Firewall transparent, der Server hingegen sieht eine Verbindung zum Firewall. Die maskierten Pakete werden so im Firewall verändert, daß die beiden anderen beteiligten Rechner präsentiert wird, was sie sehen sollen.
Masquarading

Deshalb haben sich unsere Regeln auch wie folgt verändert :

LAN=10.1.2.0/24 # privater Adressraum nach RFC1918
FWADDR=212.212.212.212
ipchains -A input -i eth0 -p tcp -s $LAN -d 0.0.0.0/0 80 -j ACCEPT (Input vom lokalen Netz)
ipchains -A forward -i eth1 -p tcp -s $LAN -d 0.0.0.0/0 80 -j MASQ (Übergabe an eine andere Schnittstelle)
ipchains -A output -i eth1 -p tcp -s $FWADDR -d 0.0.0.0/0 80 -j ACCEPT (Ausgabe ins Internet)

ipchains -A input -i eth1 -p tcp -s 0.0.0.0/0 80 -d $FWADDR -j ACCEPT (Input vom Internet) (die Demaskierung wird vom Kernel übernommen, Regel entfällt)(Übergabe an eine andere Schnittstelle)
ipchains -A output -i eth0 -p tcp -s 0.0.0.0/0 80 -d $LAN -j ACCEPT (Ausgabe ins lokale Netz)

Bei dynamischer IP-Adressenzuweisung, die man bei Einwählverbindungen normalerweise hat, kann man diese Regeln nicht statisch angeben. Im Skript ip-up müssen diese Regeln (mit -I statt -A) und der zugewiesenen IP-Adresse eingefügt und im Skript ip-down (mit -D statt -A) wieder entfernt werden.

In vielen Veröffentlichungen wird über die Probleme berichtet, die bei FTP und Paketfilterung entstehen. Aus diesem Grund wurde das passive FTP erfunden, das standardmäßig von Browsern, aber nicht von Online-Sitzungen, benutzt wird. Generell haben Paketfilter dann potentielle Sicherheitsprobleme, wenn eine Sitzung mehrere Verbindungen benötigt, oft auch im UDP-Bereich. Bekannte Kandidaten sind z.B. FTP, IRC, pcAnywhere. Um statisch diese Verbindungen zuzulassen, müssen die Regeln weiter gefaßt werden als eigentlich beabsichtigt. Nur ein sogenannter Proxy-Prozeß kann Regeln dynamisch ein- und ausfügen, indem er das zugrunde liegende Protokoll (z.B. FTP) interpretiert und die nötigen Aktionen vornimmt.

Proxy

Wie man am Beispiel FTP sieht, reicht ein Paketfilter alleine für eine akzeptable Sicherheit im LAN nicht aus. Proxy heißt nichts anderes als Stellvertreter, ein Proxy im Firewall vertritt den eigentlichen Dienst, den er verbirgt, ein FTP-Proxy also den FTP-Server, ein HTTP-Proxy den Web-Server, usw. .

Ein Proxy-Prozeß kann viele Aufgaben haben :

Proxies können geschachtel sein, etwa bei einem HTTP-Zugriff. Der Proxy, der dem Client zugewandt ist, prüft z.B. Berechtigungen und gibt die Anfrage an einen speziellen HTTP-Proxy, z.B. Squid oder Apache, weiter.

Wenn ein Proxy benutzt wird, entfallen die forward-Regeln. Ein Masquerading ist unnötig, da die Pakete aus den Netzen jeweils am Proxy enden und somit für en Client die Zieladresse und den Server die Quelladresse sind. Das Problem dieser Art von Proxies ist damit aber auch, daß der Benutzer den Proxy wahrnimmt und zusätzliche Aktionen, z.B. Einstellungen im Browser, vornehmen muß.

Transparentes Proxy

Ein echtes Highlight im Kern - wenn auch nicht neu - ist die Möglichkeit für transparente Proxies. Dazu kann mit der ipchains-Option "-j REDIRECT" ein ankommendes Paket auf den Firewall umgeleitet werden. Der Linux-Kern stellt dann Mechanismen bereit, die das ursprüngliche Ziel wieder erkennen lassen. Transparente Proxies maskieren die Quell-Adresse automatisch, alle Verbindungen scheinen von einem Rechner zu kommen. Durch diese Eigenschaft läßt sich ENskip, ein an der ETH Zürich entwickeltes Paket zum Bauen von VPNs, überhaupt erst benutzen.

TCP

Bei TCP-Verbindungen setzt man einen Proxy auf, der diese Verbindung annimmt. Mittels getsockname(), der bei einer redirektionierten Verbindung nicht die eigene Adresse zurückliefert, läßt sich feststellen, welcher Rechner ursprünglich erreicht werden sollte. Zu diesem Rechner baut man den zweiten Socket auf. Der Rest ist dann simples hin- und herkopieren. Client und Server nehmen den Firewall nicht wahr, q.e.d. .

Es lassen sich auch geschachtelte Proxies realisieren. Interessant wird das z.B. für Proxy-Web-Caches wie Squid oder Apache. Bei diesem seltenen aber interessanten und häufig benutzten Spezialfall konfiguriert man den HTTP-Proxy-Server so, daß er auf die Adresse 127.0.0.1 statt 0.0.0.0 gebunden wird. Die bedienenden äußeren Proxies wiederum werden auf die Adressen der Netzwerkschnittstellen gebunden, je Netzwerkschnittstelle ein Prozeß. Ein Verbindungswunsch läuft zur Netzwerkschnittstelle, wird dort redirektioniert auf die Adresse dieser Netzwerkschnittstelle, damit vom äußeren Proxy-Prozeß empfangen und akzeptiert. Eine zweite Verbindung wird zum HTTP-Proxy-Prozeß (Squid oder Apache) aufgebaut und dieser erst baut die eigentliche Verbindung zum Zielrechner auf. Damit nun HTTP-Requests auf den Firewall selbst keine rekursiven Prozesse aufbauen (leidvolle eigene Erfahrung), muß der HTTP-Header in diesem Fall umgeschrieben werden, also "http://localhost/..." statt "http://firewall/...". Dazu wird die Zieladresse des eigentlichen Ziels gegen alle Adressen der Netzwerkschnittstellen geprüft.Der Nachteil bei dieser Konstruktion ist, daß im Browser kein Proxy eingestellt sein darf. Alle Requests landen sonst auf dem lokalen Web-Server. Der Rest ist dann wieder simples hin- und herkopieren.

UDP

Braucht man keine VPNs mit ENskip, oder zusätzliche Eigenschaften wie Authentisierungsprüfung oder Logginginformation, so läßt sich ein transparentes UDP-Proxy mittels Masquerading emulieren. Der Kernel übernimmt dann alles Weitere. Der Autor mußte ENskip benutzen und konnte damit von dieser Möglichkeit keinen Gebrauch machen.

Bei UDP liegt der Fall komplizierter als bei TCP, man hat keine Verbindung. Jedes Paket kann für sich alleine stehen oder auch die Antwort auf ein anderes Paket sein. Es gibt viele Applikationen, angefangen bei DNS und traceroute, die UDP benutzen. Da man nicht weiß, ob ein bestimmtes Paket die Antwort auf ein anderes Paket ist, bleibt keine andere Möglichkeit, als sich alle UDP-Pakete zu merken und Verfallsdaten für Quasi-UDP-Verbindungen zu definieren (z.B. DNS-Request und DNS-Reply). Beim Eintreffen eines Antwort-Pakets wird die Zeitschranke wieder auf den Maximalwert gesetzt. Je beobachtetem UDP-Port (und ggf. Netzwerkschnittstelle) wird wie bei TCP ein Prozeß benötigt. Der Proxy-Prozeß hat eine Tabelle, die Originalquelle und -ziel, die beteiligten UDP-Ports, Zeitschranke und den Filedeskriptor des Antwort-Sockets enthält. Trifft nun ein UDP-Paket mittels select() auf dem gebundenen UDP-Port ein, wird die Tabelle nach der echten Zieladresse (der Trick hier ist das undokumentierte recvfrom(...,MSG_PROXY,...) und das Lesen der Kernel-Sourcen) durchforstet. Wenn der Eintrag nicht gefunden wird, ein Antwort-Socket eröffnet, und dann wird das Paket über diesen Antwort-Socket ausgeliefert. Ein ankommendes Paket auf diesem Socket wird mit Hilfe der Informationen der Tabelle mit einem neuen Header versehen und an die ursprüngliche Quelle ausgeliefert.

Das hier beschriebene Verfahren ist nicht der Weisheit letzter Schluß und hat eine Reihe von Schwachstellen, unter anderem die vielen Prozesse und Dateien (traceroute !), aber es läuft in der Praxis sehr zuverlässig. Verbesserungsvorschläge und Geistesblitze sind trotzdem jederzeit herzlich willkommen.

ICMP

Ein transparenter Proxy wie bei TCP und UDP läßt sich mit den bis jetzt beschriebenen Mitteln nicht bauen, es fehlt nämlich die dafür notwendige Kernel-Unterstützung. Deshalb muß man sich hier etwas Neues einfallen lassen, wenn man mit dem ping-Kommando, das von allen Kunden erwartet wird, arbeiten will. Glücklicherweise gibt es im ipchains-Kommando die Option -o, die Pakete an das Netlink-Gerät 36,3 ausliefert. Da auch in den Standard-Dokumenten kein Name für dieses Gerät existiert, habe ich es der Einfachheit halber /dev/firewall genannt. Auf dieses Gerät greift unser Proxy-Prozeß zu. Zunächst werden anders als bei TCP und UDP die Pakete nicht redirektioniert, sondern verworfen und gleichzeitig an /dev/firewall geschickt, also "-o -j DENY". Der Proxy-Prozeß öffnet dieses Gerät und liest. Alle Pakete werden so wie sie ankommen, vorneweg ein Header mit Angaben zur Gesamtlänge dorthin geschrieben. Das weitere Vorgehen ist wieder wie beim transparenten UDP-Proxy : eine Tabelle wird gehalten und Quelle, Ziel, Typ, Code und ID verglichen. Im Falle einer Übereinstimmung wird ein neues ICMP-Paket mit angepaßter Quelle und Ziel vom Proxy losgeschickt. Da es möglicherweise mehrere Routen gibt, muß für sendto() vorher ermittelt werden, welches der richtige Gateway ist.

Das Erstaunliche ist : leitet man alle ankommende Pakete mit "-o -j DENY" um, so hat man einen monolithischen Ansatz, bei dem ein einziger Prozeß alle Pakete (auch TCP und UDP) inspiziert, und entscheidet, was mit diesen angestellt wird. Dieser Ansatz steht dem Schichtenmodell gegenüber, heißt "stateful inspection" und wird in der Firewall des derzeitigen Marktführers Checkpoint, Produktname Firewall-1, verfolgt.

Andere IP-Protokolle

Es gibt eine Reihe von interessanten Protokollen, etwa SKIP, IPIP, GRE, IGMP und EGP, die einen transparenten Proxy verdienen. Insbesondere die Multicast-Protokolle und die Kapselung IPV6 in IPV4 werden in nächster Zeit Bedeutung erlangen. Prinzipiell lassen sich diese Protokolle nur durch direkte Interpretation der Paketinhalte und mit dem Vorgehen wie bei ICMP handhaben.

Web- und FTP-Caching

Auch wenn fast jeder Browser heutzutage einen integrierten Cache hat, kann damit der Mehrfachaufruf einer Web-Seite von verschiedenen Clients nicht bedient werden. Ein häufiger Anwendungsfall für geschachtelte transparente Proxies sind Anwendungen wie z.B. Squid oder Apache, die als Web-Cache und -Proxy konfigurierbar sind. Apache hat dabei noch den Vorteil, daß ein HTTP-Server integriert ist und mit Zusatzmodulen zu einem HTTPS-Server aufgemotzt werden kann. Dadurch ist zusätzlich - die entsprechenden Web-Seiten vorausgesetzt - eine verschlüsselte Fernkonfiguration möglich.

Rechner A ruft eine eine Internet-Webseite von Rechner B über den Firewall auf. Die Anforderung (Port 80/www) wird per REDIRECT auf den Proxy-Prozeß (A) umgeleitet. Dieser schreibt den HTTP-Header um und addressiert den Firewall-HTTP-Proxy (B) (Squid oder Apache). Der HTTP-Proxy (B) holt die Web-Seite, leitet sie an den Proxy-Prozeß (A) weiter und legt sie zusätzlich im lokalen Cache ab. Der Proxy-Prozeß (A) nimmt zusätzliche Prüfungen vor. Beispielweise werden beim sogenannten Content Filtering Viren gesucht, JavaScript, Java- oder DCOM(ActiveX)-Objekte ausgeblendet, Cookies nicht durchgelassen, usf.. Anschließend wird diese (oder im Falle eines Virus eine Ersatzseite) an den Client (Rechner A)zurückgeleitet.

Die Benutzung als FTP-Cache ist auch einfach : als URL ist der FTP-Zugriff ftp:://der.server/pfad.zur.datei. Man schreibt einen transparenten FTP-Proxy, der das FTP-Protokoll bis zu dem Zeitpunkt bedient, an dem eine Datei angefordert wird. Statt nun die Datei per FTP zu holen, wird ein HTTP-Request an den Firewall-HTTP-Proxy abgesetzt. Damit wird auch automatisch dessen Cache benutzt. Damit sind mehrfache Downloads großer Dateien möglich, ohne die Internet-Bandbreite tatsächlich zu beanspruchen.

Ethertap

Beim ipchains-Kommando gab es die -o-Option, um bestimmte Pakete auf ein Pseudo-Gerät umzuleiten. Diese Pakete haben zusätzlich einen Header zu dem eigentlichen Paket, wenn sie gelesen werden. Ethertap-Geräte (/dev/tap0 bis /dev/tap15) sind Schnittstellen zwischen IP-Schicht und Gerät. Die Netzwerkschnittstelle tapN läßt sich wie jede andere Schnittstelle mit Adresse, Netzmaske, etc. versehen und im Routing benutzen, das Gerät /dev/tapN läßt sich wie ein normales Gerät (das allerdings nur formal korrekte IP-Pakete verarbeitet) benutzen. Alle IP-Pakete, die auf ein Ethertap-Gerät /dev/tapN geschrieben werden, werden als Pakete auf der Netzwerkschnittstelle tapN ausgegeben, alle Pakete, die auf der Netzwerkschnittstelle tapN ankommen, können auf dem Ethertap-Gerät /dev/tapN gelesen werden.

Der Unterschied zum ipchains-Kommando besteht darin, daß nicht bestimmte Pakete aller Netzwerkschnittstellen umgeleitet werden, sondern alle Pakete einer bestimmten Netzwerkschnittstelle.

Mit diesen Geräten ist es beispielsweise möglich, Routen auf die virtuellen Ethertap-Netzwerkschnittstellen umzuleiten und auf dieser Ebene Proxies bis hin zu "stateful inspection" auf Benutzerebene zu realisieren.

Linux Socket Filter

Bei diesem Mechanismus hat der Berkeley Packet Filter (BPF) Pate gestanden. Man eröffnet einen beliebigen Socket, gibt ein Stückchen Programmcode zum Filtern dieses Sockets an und injiziert diesen Programmcode mittels eines ioctl-Aufrufs in den Kernel. Das Programm selbst dient dann nur dazu, den Socket offenzuhalten und den Filter wieder zu beseitigen. Diese Methode ist sicherlich die schnellste Filterung, geeignet für hohen Durchsatz. Der Nachteil liegt in der Programmierung auf Kernel-Ebene mit den schlechteren Debug- und Trace-Möglichkeiten, die auch die Möglichkeit eines Komplettausfalls des Firewall einschließt.

/proc-Dateisystem

Mit Hilfe des Pseudo-Dateisystems /proc können ohne reboot oder Neukompilierung Systemvariablen im laufenden Betrieb abgefragt oder verändert werden. Mit cat Dateiname lassen sich die Variablen abfragen und sofern zugelassen mittels echo 'Wert' >Dateiname setzen.

Wichtige Werte sind z.B. in /proc/net/, und /proc/sys/net/ipv4 zu finden. Damit läßt sich das System sehr fein als Firewall einstellen, etwa eine forward-Option je Interface (für klassische Firewall-Ansätze mit einem geschützten administrativen Interface). Für bekannte Angriffe wie SYN-Flooding, IP-Spoofing oder Source Routing läßt sich die Sicherheit und Geschwätzkeit des Kernels mit Hilfe dieser Variablen abhängig von der Netzwerkschnittstelle einstellen. Die Akzeptierung bekannter Router-Protokolle, die für Firewalls eine Angriffsmöglichkeit sind, können auf bestimmte Gateways einschränkt oder ganz verboten werden.

Die Dokumentation zu den einzelnen Dateien ist im Unterverzeichnis Documentation/networking des Linux-Quellcodes zu finden.

Traffic Shaper und Scheduling

Eine Bandbreitenbegrenzung kann mit dem traffic shaper realisiert werden. Er arbeitet Schnittstellenorientiert und kann nicht nach Diensten oder Quell-/Ziel-Paaren unterscheiden. Er ist im Alpha-Stadium und nur begrenzt nutzbar. Die Weiterentwicklung scheint im Moment zu ruhen.

Der Schwerpunkt der Weiterentwicklung wird im Moment auf Scheduling-Algorithmen gelegt, also das Verhalten in dem Fall, wenn mehr Pakete auszugeben sind als Bandbreite vorhanden ist. Hier kann man aus einer Fülle von Algorithmen wählen. Es läßt sich (als ein Algorithmus) mit dem ipchains-Kommando eine Markierung am Paket anbringen, die je übereinstimmender Regel aufaddiert wird. Je höher dieser Wert, desto eher wird dieses Paket bevorzugt.

VPN

Mit dem Modul ENskip, einem Sun-SKIP-kompatiblen Clone der ETH Zürich, Tunnelbau-Dienstprogrammen, entwickelt vom Routing-Guru Alexey Kuznetsov und einigen Patches des Autors lassen sich VPNs (Virtual Private Network), auch mit dynamischen Einwahladressen, realisieren. VPNs sind Netzwerke, die das Internet kryptographiert abgesichert benutzen, um zwischen den Standorten ein firmenumspannendes einheitliches Netzwerk aufzubauen. Statt teurer Standleitungen werden nur noch Ortsgebühren zur Einwahl in den lokalen Internet-Provider fällig, zusätzlich kann das Internet benutzt werden. Aufgrund der Zieladresse wird entschieden, ob ein Paket kryptographiert an einen Ziel-Firewall geschickt (und dort ausgepackt und weitertransportiert wird) oder ins Internet geht.

Durch die Verwendung von Standards (IPsec) ist Linux auch hier in der Lage, interoperabel mit anderen Herstellern zu sein.

Die Beschreibung, wie VPN mit einem Linux-Firewall funktioniert und welche Paketfilterregeln angegeben müssen, würde den Rahmen sprengen und Stoff für einen weiteren Artikel liefern ( :-) ). Der geneigte Leser kann vom Autor eine LinuxWall-Demo-CD anfordern, auf der die technischen Einzelheiten beschrieben sind.

Der Feind von innen : Beobachtungen beim NT-Setup

Eines Tages - es wurde bei einem Kunden NT-Systeme installiert - wurden auf dem Firewall-Log unzulässige Pakete moniert. Es stellte sich heraus, daß jeweils genau drei SNMP-Trap-Pakete von den gerade installierten Systemen an einen Internet-Rechner geschickt wurden. Der Versuch, der Zieladresse einen Namen zuzuordnen, brachte uns nicht weiter. Mit traceroute scheiterten wir irgendwann an einem Firewall, der uns nicht weiter durchreichte. Der Rechner antwortete auf einen Ping nicht. Die Analyse der Pakete brachte auch kein Ergebnis. War das nun Zufall oder steckt hier wieder eine (natürlich unbeabsichtigte) Registrierung von Winzigweich dahinter ? Der Autor ist für Hinweise auf ähnliche Erfahrungen dankbar.

Prinzipiell zeigt dieser Vorgang aber auch, wie wichtig es ist, nicht nur den Zugang von außen nach innen zu versperren, sondern auch den Zugang von innen nach außen zu regeln. Unbeabsichtigt können sonst Informationen in Hände geraten, in denen man sie nicht haben will. Gegen absichtliche Übermittlung ist ohnehin nur der gezogene Netzwerkstecker und das ausgebaute Diskettenlaufwerk wirksam.

Fazit

Linux ist eine erstklassige und sichere Plattform, Firewalls zu realisieren. In Analogie zu den anderen Gebieten, auf denen Linux erfolgreich ist : es funktioniert alles, was man benötigt, aber es fehlt eine Klick-and-Go-Oberfläche, die die Konfiguration etwas Einfacher werden läßt. Hier haben kommerzielle Produkte die Nase vorn, auch wenn sie nicht alles bieten, was Linux zu leisten imstande ist. Volles NAT wäre noch gut zu gebrauchen, in den letzten Kernel-Versionen ab 2.2.3 wurde damit begonnen. Hauptkritikpunkt ist die Isoliertheit der einzelnen Lösungsansätze, es fehlt ein koordinierendes Re-Design, was auch andere Protokolle (z.B. IPV6) mit einbezieht. Bei Tunneling und ENskip ist noch sehr viel Arbeit im Kern zu tun. Der Autor ist gerne bereit, Studien- und Diplomarbeiten fachlich zu unterstützen und zu betreuen.

Weiterführende Literatur und Referenzen

Durch das Studium von Teilen des Linux-Quellcodes, auch wenn nicht alles verstanden wurde, habe ich sehr viele Teile des Firewalls erst realisieren können und dabei viele Punkte gelernt. Das Unterverzeichnis Documentation ist bei aller Knappheit eine der wichtigsten Informationsquellen. Die HOWTOs des Linux Documentation Projects sind die nächste Informationsstufe. Für spezielle Fragen und Links zu Firewalls und insbesondere Linux-Firewalls sei auf die Homepage des Autors, www.linuxwall.de, verwiesen.

Der Autor

Frank Bernard ist Diplom-Informatiker und beschäftigt sich seit mehreren Jahren mit Firewalls. Seit Kernel-Version 0.99.12 (1992) ist er Linux-Fan und -Enthusiast und will jeden Rechner mit einem "richtigen" Betriebssystem ausstatten. Er ist Freiberufler und hat den LinuxWall entwickelt. Zu erreichen ist er unter frankb@fbit.de.