|
Paketfilter sind ein preiswerter und nützlicher Sicherheitsmechanismus für Gateways. Sie sind billig oder gar kostenlos, denn die Router-Software hat schon die Fähigkeit zur Paketfilterung, und man braucht meist sowieso einen Router, um sich überhaupt ans Internet anzuschließen. Selbst wenn der Router dem Provider gehört, wird dieser die Filter gerne installieren.
Paketfilter verwerfen Pakete in Abhängigkeit ihrer Quell- oder Zieladressen oder -Ports. Dies geschieht im allgemeinen kontextfrei, nur auf den Inhalt des aktuellen Paketes gestützt. 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 läß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 für A jeglichen Zugang zu B sperren.
Die meisten Sicherheitskonzepte benötigen feinere Kontrollmöglichkeiten. Nicht vertrauenswürdige Maschinen soll der selektive Zugang zu einzelnen Diensten gewährt werden. So möchte man vielleicht jedem Host erlauben, den Mail-Service der Maschine A zu kontaktieren. Der Zugang zu anderen Diensten soll unabhängig hiervon regelbar sein. Dies läßt sich zum Teil mit Paketfiltern erreichen, doch die Konfiguration ist schwierig und fehleranfällig. Um sie korrekt durchzuführen, braucht man detaillliertes Fachwissen über TCP- und UDP-Port-Belegung in mehreren Betriebssystemen.
Dies ist einer der Gründe, der gegen Paketfilter spricht. Champman [1992] hat gezeigt, daß Konfigurationsfehler bei der Paketfilterung leicht Hintertürchen für den Angreifer öffen.
Selbst wenn der Filter völlig korrekt eingestellt wurde, können manche Kompromisse gefährliche Konsequenzen haben - mehr dazu später.
Die Konfiguration eines Paketfilters ist ein dreistufiger Prozeß. Zu allererst maß man sich darüber klar sein, was erlaubt und was verboten sein soll. Man muß also ein Sicherheitskonzept haben.
Als nächstes müssen die verschieden Paketklassen formal als logische Ausdrücke über Paketinhalte spezifiziert werden. Schließlich müssen die Ausdrücke in die vom Router unterstütze Syntax übersetzt 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 vertrauenswürdig
erlaubt Unser-GW 25 * * Zugang zum SMTP Port
Die Regeln werden gemäß 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 tatsächlich der normale Mail-Port, bloß können wird dies auf fremden Hosts nicht sicherstellen. Ein Angreifer könnte jeden beliebigen Port unserer internen Computer attackieren, indem er seine Verbindung vom Port 25 der externen Maschine ausgehen läßt.
Besser wäre, 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 könnten einen beliebigen Dienst nach Wahl des Angreifers realisieren. Glücklicherweise 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 strömen, sind Quittungs- und Steuerpakete in die Gegerichtung unterwegs. Wir können 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 gehören also zu einer laufenden Verbindung, Pakete ohne es stellen einen nur für interne Hosts erlaubten Verbindungsaufbau dar. Externen Computern soll der Verbindungsaufbau verweigert, aber die Fortführung von Verbindungen ermöglicht werden. Interne Kernel akzeptieren keine Fortsetzungspakete für nicht vorhandene TCP-Verbindungen.
Damit können wir mit den Begriffen Quell- und Zieladresse statt des nebulösen "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 für eine Menge zulässiger Maschienen.
Filtern von FTP-Sitzungen
Dateien werden bei FTP über eine zweite Verbindung transportiert. Nutzt der Kontrollkanal zum Server IHRHOST die Verbindung
so erfolgt der Dateitransfer üblicherweise über den Datenkanal
Zudem geht der Verbindungsaufbau vom Server aus. Wir sehen uns mit einem bekannten Problem konfrontiert, diesmal aber ohne die Möglichkeit, anhand der Richtung des Verbindungsaufbaus zu selektieren.
Ein mögliches Selektionskriterium wäre der Wertebereich für UnserPort. Die meisten Server, und damit die meisten Angriffsziele, finden sich auf niedrigen Port-Nummern, während abgehende Verbindungen eher von hohen (also oberhalb von 1023) Port-Nummern ausgehen. Ein Regelsatz könnte dann etwas so aussehen:
Zugang Quelle Port Ziel Port Attr Kommentar
erlaubt {unsere Hosts} * * * abgehende Verbindungen
erlaubt * * * * ACK Antworten für uns
erlaubt * * * >1023 nichtprivilegierte Verbindungen
Pakete werden also durchgeschleust, wenn sie eine der folgenden Bedingungen erfüllen:
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 auswärtige Pakete, sondern auf alle. Allerdings werden Pakete von innen schon von der ersten Regel akzeptiert und daher die folgenden nicht mehr angewandt.
Eine andere Möglichkeit wäre der FTP-PASV Befehl. Man könnte den Clienten dahingehend modifizieren, dem Server einen PASV zu geben. Der Server wählt dann ein beliebige Port Nummer und fordert den Client auf, die Verbindung zu initieren.
Die Zähmung des DNS
Der Umgang mit DNS ist eines der kniffligsten Probleme beim Aufbau einer Firewall. Der Dienst selbst ist für ein Gateway unerläßlich, doch er birgt viele Gefahren.
Chapmans Ansatz besteht darin, Name-Server für 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 "öffentliche\") liefert nur minimale Auskünfte 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 für Mail und FTP (wieder foo.bar.com) angegeben und alle Mail für Maschinen in der bar.com-Domain über das Relais geleitet.
Knifflige Details sind:
der Zugriff des Gateways auf interne Namen, etwa für die Mail-Zustellung
der Zugriff interner Maschinen auf externe Namen
das Durchschleusen der nötigen 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, lösen 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 für Teilbaume zuständige Name-Server. Anfragen nach unbekannten Namen werden auf diese Weise korrekt aufgelöst.
Das zweite Problem sind an den interenen DNS-Server gerichtete Anfragen nach externen Namen. Natürlich kennt dieser Server keine externen Maschinen. Statt mit den wirklichen, externen DNS-Servern direkten Kontakt aufzunehmen (das können wir nicht zulassen, da wir Antworten nicht auf sichere Weise durch die Firewall schleusen können), 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 über die Firewall zurück 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 zurück.
Der interne und der Gateway-Name Server können 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 für solche Pakete unterbunden werden.
Dies löst das dritte Problem.
Plazierung der Filter
Bei einem typischen Firewall-Router
kann die Paketfilterung an mehreren Stellen erfolgen. Pakete können 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 hängt von den Fähigkeiten des Routers ab: Nicht jeder erlaubt all diese Möglichkeiten, und manche besitzen noch einige mehr.
Filtern am Router-Ausgang effizienter sein, da sich die Anwendung der Selektionskritäreien meist mit Wegwahloperationen kombinieren läßt. Andererseits gehen Informationen verloren, etwa über welche Leitung das Paket empfangen wurde. Dieses Wissen ist besonders wichtig bei der Abwehr von Adreßfälschungen. Filtern am Router-Eingang bietet auch dem Router selbst Schutz vor Angriffen. Verdächtige Pakete sollten so früh wie möglich 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 vertrauenswürdig
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 Gründen ist es manchmal wünschenswert, denselben Router als Firewall und für internes Routing zu verwenden.
Sicherheitskonzept:
Sehr eingeschränkte Verbindungen zwischen GW und der Außenwelt werden durch den Router geschleust
Zwischen GW und Systemen in Netz 2 oder Netz 3 werden sehr eingeschränkte Verbindungen zugelassen. Dies ist ein Schutz, falls GW gekapert wird.
Zwischen NETZ 2 und NETZ 3 herrscht uneingeschränkter 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 können, daß eine Quelladresse auch wirklich zu NETZ 3 gehört. Nichts hindert aber einen Angreifer daran, von außen Pakete zu senden, die behaupten, von einer internen Maschine zu stammen. Wichtige Information - nämlich, daß rechtmäßige Pakete von NETZ 3 nur über ein bestimmte Leitung kommen können - würde vernachlässigt. Solche Adresßschwindelein sind nicht ganz einfach, aber keineswegs unrealistisch.
Wir wollen also annehmen, daß wir an den Eingängen filtern und daß wir jede abgehende Verbindung, aber eingehende Verbindungen nur für 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} * * * Fälschungen ausperren
blockiert {NETZ 2} * * *
blockiert {NETZ 3} * * *
erlaubt * * GW 25 eingehende Mail-Verb
erlaubt * * {NETZ 2} * ACK Rückantworten für abg. Verb.
erlaubt * * {NETZ 3} * ACK
In Worten:
Addreßfälschungen vermeiden
eingehende Mail Verbindungen zum Gateway
Rückantworten innerhalb beliebiger abgehender Verbindungen erlauben
Alles andere wird abgewiesen
Paketfilter und UDP
Es ist schwierig TCP-Verbindungen zu filtern. Es ist beinahe unmöglich, UDP-Pakete ohne Funktionalitätsverluste zu filtern. Dies liegt an einem grundsätzlichen Unterschied zwischen TCP und UDP: TCP ist verbindungsorientiert und merkt sich daher Kontext, während UDP paketorientiert ist, und daher die Datagramme unabhängig voneinander betrachtet werden. Bei TCP erlaubt uns das ACK-Bit die Unterscheidung zwischen eingehenden und abgehenden Verbindungen. Doch bei UDP fehlt uns solches Selektionskritärium.
Angenommen, ein internen Host möcht 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
Für 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 könnten zwar die Angriffsziele explizit aufführen, aber wissen wir, welche neuen Schwachstellen irgendein Systemverwalter in irgendeiner abgelegenen Ecke unseres Datennetzes nächst Woche installiert.
Ein konservatives Sicherheitskonzept fordert daher, abgehenden UDP-Verkehr praktisch vollständig zu verbieten. Nicht, daß im abgehenden Verkehr selbst irgendeine Gefahr begründet wäre, doch können 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 für jede gewünschte 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 genügt, einige ausgewählte Programme unter die Lupe zu nehmen. Anwendungsschicht-Gateways bieten einen weiteren, für 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 für 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 gewünschte Dateinen leicht auf Disketten oder Streamer kopieren könnten. Es ist aber auch nicht die Aufgabe einer Firewall, gegen Angriffe von innen zu schützen - sie schottet bloß nach außen ab.
|
