Paketfilter

Paketfilter sind ein preiswerter und nutzlicher Sicherheitsmechanismus fur Gateways. Sie sind billig oder gar kostenlos, denn die Router-Software hat schon die Fahigkeit zur Paketfilterung, und man braucht meist sowieso einen Router, um sich uberhaupt ans Internet anzuschlie?en. Selbst wenn der Router dem Provider gehort, wird dieser die Filter gerne installieren.

Paketfilter verwerfen Pakete in Abhangigkeit ihrer Quell- oder Zieladressen oder -Ports. Dies geschieht im allgemeinen kontextfrei, nur auf den Inhalt des aktuellen Paketes gestutzt. Je nach Typ des Routers erfolgt die Filterung entweder bei eingehenden oder abgehenden Pakete oder bei beiden. Der Systemverwalter gibt eine Positivliste akzeptabler, und eine Negativliste der verbotenen an. Damit la?t sich auf Host- und Datennetzt der Zugang leicht steuern. So kann man beispielsweise beliebenigen IP-Verkehr zwischen den Hosts A und B zulassen oder au?er fur A jeglichen Zugang zu B sperren.

Die meisten Sicherheitskonzepte benotigen feinere Kontrollmoglichkeiten. Nicht vertrauenswurdige Maschinen soll der selektive Zugang zu einzelnen Diensten gewahrt werden. So mochte man vielleicht jedem Host erlauben, den Mail-Service der Maschine A zu kontaktieren. Der Zugang zu anderen Diensten soll unabhangig hiervon regelbar sein. Dies la?t sich zum Teil mit Paketfiltern erreichen, doch die Konfiguration ist schwierig und fehleranfallig. Um sie korrekt durchzufuhren, braucht man detaillliertes Fachwissen uber TCP- und UDP-Port-Belegung in mehreren Betriebssystemen.

Dies ist einer der Grunde, der gegen Paketfilter spricht. Champman [1992] hat gezeigt, da? Konfigurationsfehler bei der Paketfilterung leicht Hinterturchen fur den Angreifer offen.

Selbst wenn der Filter vollig korrekt eingestellt wurde, konnen manche Kompromisse gefahrliche Konsequenzen haben – mehr dazu spater.

Die Konfiguration eines Paketfilters ist ein dreistufiger Proze?. Zu allererst ma? man sich daruber klar sein, was erlaubt und was verboten sein soll. Man mu? also ein Sicherheitskonzept haben.

Als nachstes mussen die verschieden Paketklassen formal als logische Ausdrucke uber Paketinhalte spezifiziert werden. Schlie?lich mussen die Ausdrucke in die vom Router unterstutze Syntax ubersetzt werden.

Beispiel

Sicherheitskonzept

eingehende Mail (SMTP, Port 25), allerdings nur von der Gateway Maschine

keine Mail von QUAXI, weil er immer Gigabyte schickt

Filer

Zugang Wir Port Sie Port Kommentar

blockiert * * QUAXI * nicht vertrauenswurdig

erlaubt Unser-GW 25 * * Zugang zum SMTP Port

Die Regeln werden gema? ihrer Reihenfolge angewandt. Pakete, deren Zugang nicht explizit erlaubt ist, werden blockiert. Dies entspricht folgender impliziter Regel am Ende des Regelwerks:

Zugang Wir Port Sie Port Kommentar

blockiert * * * * Default

und folgt der generellen Entwurfsphilosophie: Was nicht explizit erlaubt ist, ist verboten.

Unterschiede

Folgendes Regelwerk soll „jeder Host innen darf Mail nach au?en schicken“ implementieren.

Zugang Wir Port Sie Port Kommentar

erlaubt * * * 25 Verbindung zum fremden SMTP Port

Die Verbindung kann von einem beliebigen Port auf einer Maschine ausgehen, mu? aber au?en den Port 25 als Ziel haben. Das Regelwerk scheint klar und offensichtlich – und es ist falsch.

Der Fehler ligt darin, da? die Filterung ausschlie?lich auf Port-Nummern fremder Maschinen basieret. Port 25 ist zwar tatsachlich der normale Mail-Port, blo? konnen wird dies auf fremden Hosts nicht sicherstellen. Ein Angreifer konnte jeden beliebigen Port unserer internen Computer attackieren, indem er seine Verbindung vom Port 25 der externen Maschine ausgehen la?t.

Besser ware, nur abgehende Verbindungen mit Zielport 25 zuzulassen. Wir erlauben also unseren Computern, fremde Ports 25 zu kontaktieren, da wir ihr Anliegen kennen: Mail-Zustellung. Eingehende Verbindungen von Port 25 konnten einen beliebigen Dienst nach Wahl des Angreifers realisieren. Glucklicherweise kann die Unterscheidung zwischen eingehenden und abgehenden Paketen leicht durch einen einfachen Paketfilter getroffen werden, idem wir unsere Notation erweitern.

Bei einer TCP-Verbindung flie?en Pakete immer in beide Richtungen. Selbst wenn die Daten ausschlie?lich in eine Richtung stromen, sind Quittungs- und Steuerpakete in die Gegerichtung unterwegs. Wir konnen unser Ziel erreichen, indem wir die Flu?richtung des Pakets und einige Steuerfelder untersuchen. Insbesondere hat das erste Paket zum Aufbau einer Verbindung einer TCP-Verbindung im Gegensatz zu allen anderen TCP-Paketen im Kopf kein ACK-Bit. Pakete mit gesetztem ACK-Bit gehoren also zu einer laufenden Verbindung, Pakete ohne es stellen einen nur fur interne Hosts erlaubten Verbindungsaufbau dar. Externen Computern soll der Verbindungsaufbau verweigert, aber die Fortfuhrung von Verbindungen ermoglicht werden. Interne Kernel akzeptieren keine Fortsetzungspakete fur nicht vorhandene TCP-Verbindungen.

Damit konnen wir mit den Begriffen Quell- und Zieladresse statt des nebulosen „WIR“ und „SIE“ folgendes Regelwerk formulieren:

Zugang Quelle Port Ziel Port Attr Kommentar

erlaubt {unsere Hosts} * * 25 unsere Pakete zu ihrem SMTP-Port

erlaubt * 25 * * ACK ihre Antworten darauf

Die Schreibweise „{usere Hosts}“ steht fur eine Menge zulassiger Maschienen.

Filtern von FTP-Sitzungen

Dateien werden bei FTP uber eine zweite Verbindung transportiert. Nutzt der Kontrollkanal zum Server IHRHOST die Verbindung

so erfolgt der Dateitransfer ublicherweise uber den Datenkanal

Zudem geht der Verbindungsaufbau vom Server aus. Wir sehen uns mit einem bekannten Problem konfrontiert, diesmal aber ohne die Moglichkeit, anhand der Richtung des Verbindungsaufbaus zu selektieren.

Ein mogliches Selektionskriterium ware der Wertebereich fur UnserPort. Die meisten Server, und damit die meisten Angriffsziele, finden sich auf niedrigen Port-Nummern, wahrend abgehende Verbindungen eher von hohen (also oberhalb von 1023) Port-Nummern ausgehen. Ein Regelsatz konnte dann etwas so aussehen:

Zugang Quelle Port Ziel Port Attr Kommentar

erlaubt {unsere Hosts} * * * abgehende Verbindungen

erlaubt * * * * ACK Antworten fur uns

erlaubt * * * >1023 nichtprivilegierte Verbindungen

Pakete werden also durchgeschleust, wenn sie eine der folgenden Bedingungen erfullen:

Sie stammen von einer unserer Maschinen

Es sind Antworten innerhalb einer von uns initierten Verbindung

Sie zielen auf eine hohe Port-Nummer bei uns

Genaugenommen beziehen sich die beiden letzten Regeln nicht nur auf auswartige Pakete, sondern auf alle. Allerdings werden Pakete von innen schon von der ersten Regel akzeptiert und daher die folgenden nicht mehr angewandt.

Eine andere Moglichkeit ware der FTP-PASV Befehl. Man konnte den Clienten dahingehend modifizieren, dem Server einen PASV zu geben. Der Server wahlt dann ein beliebige Port Nummer und fordert den Client auf, die Verbindung zu initieren.

Die Zahmung des DNS

Der Umgang mit DNS ist eines der kniffligsten Probleme beim Aufbau einer Firewall. Der Dienst selbst ist fur ein Gateway unerla?lich, doch er birgt viele Gefahren.

Chapmans Ansatz besteht darin, Name-Server fur die Domain sowohl auf dem Gateway als auch auf einer internen Maschine zu fahren. Letztere hat die echten Informationen – der Name-Server auf dem Gateway (der „offentliche“) liefert nur minimale Auskunfte wie zB:

bar.com. IN NS foo.bar.com.

bar.com. IN NS x.trusted.edu.

foo.bar.com IN A 2000.2.3.4

x.trusted.edu IN A 5.6.7.8

foo.bar.com IN MX foo.bar.com.

*.bar.com IN MX foo.bar.com.

bar.com IN MX foo.bar.com.

ftp.bar.com IN CNAME foo.bar.com

Es werden nur die Name-Server selbst (foo.bar.com und x.trusted.edu) sowie das Relaissystem fur Mail und FTP (wieder foo.bar.com) angegeben und alle Mail fur Maschinen in der bar.com-Domain uber das Relais geleitet.

Knifflige Details sind:

der Zugriff des Gateways auf interne Namen, etwa fur die Mail-Zustellung

der Zugriff interner Maschinen auf externe Namen

das Durchschleusen der notigen UDP-Pakete durch die Firewall

Das erste Problem wird durch eine /etc/resolv.conf Datei auf dem Gateway, die auf den internen DNS-Server verweist, erschlagen. Applikatioenen auf dem Gateway, nicht aber der Name-Server selbst, losen ihre Adre?anfragen anhand dieser Datei. Wenn also beispielsweise mail die IP-Adresse zu einem Namen sucht, fragt es den interenen DNS-Server.

Der Name-Server-Proze? selbst ignoriert die /etc/resolv.conf Datei. Er bearbeitet Anfragen allein anhand der Baumstruktur des Namensadressbaumes und seines Wissens fur Teilbaume zustandige Name-Server. Anfragen nach unbekannten Namen werden auf diese Weise korrekt aufgelost.

Das zweite Problem sind an den interenen DNS-Server gerichtete Anfragen nach externen Namen. Naturlich kennt dieser Server keine externen Maschinen. Statt mit den wirklichen, externen DNS-Servern direkten Kontakt aufzunehmen (das konnen wir nicht zulassen, da wir Antworten nicht auf sichere Weise durch die Firewall schleusen konnen), kontaktiert er das Gateway, welches in seiner Konfigurationsdatei in einem forward vermerkt ist. Dieser Befehl gibt an, welcher Server wegen unbekannter Namen befragt werden soll. Damit beantwortet er also Fragen nach internen Maschinen unmittelbar und leitet Anfragen nach exterenen Maschinen an den Name-Server des Gateways weiter.

Folien

Gateway ruft intern/extern

Interne ruft intern/extern

Insbesondere interessant ist dieses Vorgehen dann, wenn Prozesse auf dem Gateway nach externen Namen fragen. Zuerst geht die Anfrage zum interen Server, der die Antwort gar nicht kennen kann. Dann springt sie uber die Firewall zuruck zum Name-Server des Gateway und von dort weiter zu externen DNS-Servern, von denen schlie?lich eventuell einer die Antwort kennt. Diese Antwort kehrt schlie?lich denselben verschlungen Pfad zuruck.

Der interne und der Gateway-Name Server konnen sich desewegen durch den Paketfilter hindurch unterhalten, weil beide den offiziellen DNS-UDP-Port(53) als Quellport verwenden, wenn sie Anfragen weiterleiten. Dies erlaubt eine sichere Filterregel, die den Durchgang von Paketen vom Gateway zum Port 53 des internen Servers gestattet. Die Konfiguration des Routers stellt sicher, da? falsche Quelladressen fur solche Pakete unterbunden werden.

Dies lost das dritte Problem.

Plazierung der Filter

Bei einem typischen Firewall-Router

kann die Paketfilterung an mehreren Stellen erfolgen. Pakete konnen entweder am Punkt (a) oder (b) oder an beiden gefiltert werden, und zwar entweder die eingehenden oder die abgehenden Pakete oder auch beide Richtungen. Die Filterstrategie hangt von den Fahigkeiten des Routers ab: Nicht jeder erlaubt all diese Moglichkeiten, und manche besitzen noch einige mehr.

Filtern am Router-Ausgang effizienter sein, da sich die Anwendung der Selektionskritareien meist mit Wegwahloperationen kombinieren la?t. Andererseits gehen Informationen verloren, etwa uber welche Leitung das Paket empfangen wurde. Dieses Wissen ist besonders wichtig bei der Abwehr von Adre?falschungen. Filtern am Router-Eingang bietet auch dem Router selbst Schutz vor Angriffen. Verdachtige Pakete sollten so fruh wie moglich ausgesondert werden. Es ist nicht ausreichend, TCP-Antworten abzufangen, manche Angriffe funktionieren, ohne da? der Angreifer jemals eine Antwort zu Gesicht bekommt. Entsprechend sollte also der erste Regelsatz so formuliert werden:

Zugang Quelle Port Ziel Port Kommentar

blockiert QUAXI * * * nicht vertrauenswurdig

erlaubt * * UNSER-GW 25 Zugang zu unserem SMTP

erlaubt UNSER-GW 25 * * unsere Antworten

statt unsere Antworten zu filtern:

Zugang Quelle Port Ziel Port Kommentar

blockiert * * QUAXI *

erlaubt * * UNSER-GW 25

erlaubt UNSER-GW 25 * *

Netztopologie und Adre?schwindeleien

Aus wirtschaftlichen Grunden ist es manchmal wunschenswert, denselben Router als Firewall und fur internes Routing zu verwenden.

Sicherheitskonzept:

Sehr eingeschrankte Verbindungen zwischen GW und der Au?enwelt werden durch den Router geschleust

Zwischen GW und Systemen in Netz 2 oder Netz 3 werden sehr eingeschrankte Verbindungen zugelassen. Dies ist ein Schutz, falls GW gekapert wird.

Zwischen NETZ 2 und NETZ 3 herrscht uneingeschrankter Verkehr.

Zwischen dem externen Netz und NETZ 2 oder NETZ 3 sind nur abgehende Verbindungen erlaubt.

Welche Sorte von Filterregeln wollen wir benutzen? Wenn wir nur am Ausgang filtern, wird es ziemlich schwierig. Eine Regel, die offenen Zugang zum NETZ 2 gestattet, mu? sich darauf verlassen konnen, da? eine Quelladresse auch wirklich zu NETZ 3 gehort. Nichts hindert aber einen Angreifer daran, von au?en Pakete zu senden, die behaupten, von einer internen Maschine zu stammen. Wichtige Information – namlich, da? rechtma?ige Pakete von NETZ 3 nur uber ein bestimmte Leitung kommen konnen – wurde vernachlassigt. Solche Adres?schwindelein sind nicht ganz einfach, aber keineswegs unrealistisch.

Wir wollen also annehmen, da? wir an den Eingangen filtern und da? wir jede abgehende Verbindung, aber eingehende Verbindungen nur fur Mail und nur zu unserem Gateway zulassen. Der Regelsatz an der externen Schnittstelle sollte dann lauten:

Zugang Quelle Port Ziel Port Attr Kommentar

blockiert {NETZ 1} * * * Falschungen ausperren

blockiert {NETZ 2} * * *

blockiert {NETZ 3} * * *

erlaubt * * GW 25 eingehende Mail-Verb

erlaubt * * {NETZ 2} * ACK Ruckantworten fur abg. Verb.

erlaubt * * {NETZ 3} * ACK

In Worten:

Addre?falschungen vermeiden

eingehende Mail Verbindungen zum Gateway

Ruckantworten innerhalb beliebiger abgehender Verbindungen erlauben

Alles andere wird abgewiesen

Paketfilter und UDP

Es ist schwierig TCP-Verbindungen zu filtern. Es ist beinahe unmoglich, UDP-Pakete ohne Funktionalitatsverluste zu filtern. Dies liegt an einem grundsatzlichen Unterschied zwischen TCP und UDP: TCP ist verbindungsorientiert und merkt sich daher Kontext, wahrend UDP paketorientiert ist, und daher die Datagramme unabhangig voneinander betrachtet werden. Bei TCP erlaubt uns das ACK-Bit die Unterscheidung zwischen eingehenden und abgehenden Verbindungen. Doch bei UDP fehlt uns solches Selektionskritarium.

Angenommen, ein internen Host mocht den UDP-Dienst Echo eines externen Systems in Anspruch nehmen. Das abgehende Paket hat das Adre?tupel

wobei interner Port im unprivilegierten Bereich liegt. Die Antwort ist

Fur den Router ist nicht erkennbar, ob interner Porrt wirklich ein harmloses Ziel ist.

Ein eingehendes Paket

stellt wahrscheinlich einen Angriff auf unseren NFS-Server dar. Wir konnten zwar die Angriffsziele explizit auffuhren, aber wissen wir, welche neuen Schwachstellen irgendein Systemverwalter in irgendeiner abgelegenen Ecke unseres Datennetzes nachst Woche installiert.

Ein konservatives Sicherheitskonzept fordert daher, abgehenden UDP-Verkehr praktisch vollstandig zu verbieten. Nicht, da? im abgehenden Verkehr selbst irgendeine Gefahr begrundet ware, doch konnen wir den Antworten darauf nicht trauen.

Anwendungsschicht Gateways

Anwendungsschicht Gateways stellen das andere Extrem beim Firewall Entwurf dar. Statt den gesamten Verkehrsflu? mit einem Allzweckmechanismus zu kontrollieren, wird fur jede gewunschte Applikation spezialisierter Code eingesetzt. Dies ist gewi? hoher Aufwand, aber wahrscheinlich viel sicherer als jede Alternative. Man braucht sich nicht um Wechselwirkungen zwischen verschiedenen Filterregeln zu sorgen, noch um Lecks in den vorgeblich sicheren Diensten, die tausende interner Hosts au?en anbieten. Es genugt, einige ausgewahlte Programme unter die Lupe zu nehmen. Anwendungsschicht-Gateways bieten einen weiteren, fur gewisse Anwendungen recht wichtigen Vorteil: der gesamte ein- und abgehende Verkehr kann kontrolliert und protokolliert werden. Das SEAL-Paket von DEC nutzt dies aus. Abgeheder FTP-Verkehr wird nur fur befugte Personen zugelassen. Ziel ist es, den Diebstahl wertvoller Programme oder Daten der Firma zu verhindern. Dies ist allerdings von begrenztem Nutzen gegen Interne, die gewunschte Dateinen leicht auf Disketten oder Streamer kopieren konnten. Es ist aber auch nicht die Aufgabe einer Firewall, gegen Angriffe von innen zu schutzen – sie schottet blo? nach au?en ab.