|
1.1 Sicherheitsphilospophie
Axiom 1 (Murphy):
Alle Programme haben Fehler.
Satz 1 (Gesetz der großen Programme)
Große Programme sind noch fehlerhafter als ihre Größe vermuten läßt.
Konklusion 1
Sicherheitsrelevante Programme haben sicherheitsrelevante Fehler.
Satz 2
Es spielt keine Rolle, ob ein Programm Fehler hat oder nicht, wenn Sie es nicht benutzen.
Konklusion 2
Es spielt keine Rolle, ob ein Programm sicherheitsrelevante Fehler hat, wenn Sie es nicht benutzen.
Satz 3
Gefährdete Computer sollten so wenig Programme wie möglich fahren. Die eingesetzten Programm sollten so klein wie möglich sein.
Korollar 3 (Fundamentalsatz für Firewalls)
Die meisten Hosts genügen unseren Anforderungen nicht: Sie fahren zu viele, zu große Programme. Die einzige Lösung ist daher, sie mit einer Firewall abzuschotten, wenn Sie überhaupt irgendwelche Programme benutzen wollen.
1.2 Grundidee
Eine Firewall besteht im allgemeinen aus verschiedenen Komponenten. "Filter" (engl. "Screens") schleusen nur ganz bestimmte Klassen von Verkehr durch und blockieren alle anderen. Ein Gateway besteht aus einer oder mehreren Maschinen, die als Relais für bestimmte, durch Filter blockierte Dienste dienen. Das Gateway-Datennetzsegment wird oft auch demilitarisierte Zone (DMZ) genannt.
Ein Gateway in der DMZ wird häufig durch den internen Gateway ergänzt. Im allgemeinen gesteht man dem äußeren Gateway durch den inneren Filter hindurch eine freizügigere Kommunikation zu dem internen Gateway zu, als zu anderern inneren Host. In der Regel dient der äußere Filter dem Schutz des Gateways selbst, während der innere das interne Datensegment schützt, falls der Gateway gekapert wird. Jeder einzelne oder auch beide Filter können das interne Datennetz von Angriffen von außen schützen. Einen exponierten Gatway nannt man Bastion Host (Vorwerk).
1.3 Schema einer Firewall
Man unterscheidet drei Hauptkategorien von Firewalls:
. Paketfilter
. Vermittler- oder Transportschicht-Gateway (cicuit gateway)
. Anwendungsschicht-Gateway (application gateway)
Meist werden mehrere Typen gleichzeitig eingesetzt. Wie schon erwähnt wird Mail häufig selbst dann über ein Gateway geleitet, wenn gar keine Firewall benötigt wird.
1.4 Kosten
1.4.1 Kosten einer Firewall
. Kauf der Hardware
. Wartung der Hardware
. Entwicklung oder Kauf der Software
. Wartung der Software
. Installation und Personlaschulung
. kontinuierliche Administration und Troubleshooting
. Geschäftseinbußen durch blockierte Dienste oder Störungen im Gateway
. Verzicht auf die Dienste oder Annehmlichkeiten einer offenen Anbindung
1.4.2 Mögliche Kosten des Verzichtes
. nötige Maßnahmen zur Bekämpfung eines erfolgreichen Einbruchs und zumWiederanlauf des Betriebs inklusive der Geschäftseinbußen
. juristische und andere Konsequenzen wegen der Duldung oder Unterstützung von Hackern
1.5 Firewall Marktentwicklung
Marktforscher vermuten, daß sich der Markt für Firewalls und damit verbundenen Dienstleistungen weltweit von serzeit 1,1 Mrd. Dollar bis zum Jahr 2000 auf 16,2 Mrd. wachsen wird. Dies entspricht einer jährlichen Steigerungsrate von 70 Prozent.
1.5.1 Firewall Software und -Dienstleitungen
Bisher hat sich noch kein Marktführer für "schlüsselfertige" Firewalls herauskristallisiert. Digital, Sun, IBM, Trusted Information, CheckPoint werden jedoch als vielversprechende Anwärter auf diesen Titel gehandelt.
1.6 Platzierung von Firewalls
Traditionell werden Firewalls zwischen der Organisation und dem Rest der Welt errichtet. Große Organisationen können aber durchaus interne Firewalls benötigen, um administrative oder Sicherheitsbereiche, "security domains" zu isolieren.
Datennetz Abbildung 3.2, S. 64
Der Pfeil zeigt nach außen, in Richtung der Bedrohung. Im Beispiel traut NETZ 1 keinem anderen Netz. Die Firewall kontrolliert Zugang und Vertrauen auf nachvollziehbare Weise.
1.6.1 Transitives Vertrauen
Transitives Vertrauen kann sich als Problem erweisen. Angenommen, Maschine A in
Abblildung 3.3 vertraut in völligem Einklang mit ihrem lokalen Sicherheitskonzept der Maschine B. Diese wiederum vertraut gemäß ihrem Sicherheitskonzept der Maschine C. Die Konsequenz ist, daß Maschine A, ob sie will oder nicht, und möglicherweise ohne ihr Wissen, nun Maschnie C traut. Eine Firewall verhindert dies. Die Dioden in Abbildung 3.2 deuten an, daß Maschine A der Maschine B oder diese der Maschine C kein Vertrauen aussprechen kann. Die Maschine C könnte aber durchaus der Maschine B vertrauen. Vertrauensverhältnisse können also mittels Firewalls kontrolliert werden.
1.7 Paketfilter
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.
1.7.1 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.
1.7.2 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.
1.7.3 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.
1.7.4 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.
1.8 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.
1.8.1 E-mail
E-mail wird, unabhänig von der sonstige Firewall Technologie, häufig mittels Anwendungsschicht-Gateways realisiert. Mail-Gateways sind, unabhängig von allen Sicherheitsgedanken, an und für sich nützlich. Benutzer bleiben unter der gleichen Adresse ereichbar, unabhängig davon, auf welcher Maschine sie gerade arbeiten. Der Mail-Gateway kümmert sich auch um die korrekte Formatierung der Mail-Header, um Protokollierung und bietet einen zentralen Überwachungspunkt für das Mail-System. Gateways gelten in der Tat als so wichtig, daß im DNS zu ihrer Unterstützung eigens der MX-Eintrag vorgesehen ist. Keine andere Applikation hat einen definierten indieketen Zugangsmechanismus.
Vom Sicherheitsstandpunkt aus ist der Nutzen sogar noch größer. Interne Systemnamen, und damit eventuell wertvolle Details können verborgen werden. Protokollierung und Analyse des Verkehrsflusses und des Postinhaltes zum Auffinden von Informationslecks ist durchführbar.
Häufig werden Anwendungsschicht-Gateways gemeinsam mit Paketfiltern und Transportschicht Gateways eingesetzt. Ein clever programmiertes Gateway könnte den Datenflluß modifizieren und so Versuche, falsche .rhosts Dateien oder shells mit S-Bit zu installieren, vereiteln.
Die Selektionskriterien hängen von lokalen Bedürfnissen und Bräuchen ab. Anlagen mit vielen PC-Benutzen wollen eingehende Daten vielleicht auf Viren untersuchen.
Der Hauptnachteil der Anwendungsschicht-Gateways liegt darin, daß für die meisten angebotenen Dienste spezielle Benutzeroberflächen oder -programme bereitgestellt werden müssen. Die praktische Konsequenz ist, daß in der Regel nur die wichtigesten Dienste angeboten werden.
1.9 Transportschicht Gateways
arbeiten auf der Verbindungsschicht. Sie vermittlen als Relais TCP-Verbindungen. Eine externe Vernbindung geht auf einem TCP-Port des Gateways ein, dieser kontaktiert dann ein internes Ziel. Während die Verbindung besteht, kopiert das Gateway die Daten zwischen den Schnittstellen um.
Manchmal wird die Verbindung automatisch hergestellt. Bei AT&T beispielsweise muß ein externer Host auf einen internen Drucker zugreifen. Er spricht den Druckdiest des Gateway an, der diese spezielle Verbindung an den Druckdienst der zuständigen internen Maschine durchreicht. Um sicherzustellen, daß nur dieser bestimmte externe Host auf den Druckdienst des Gateways zugreifen kann, benutzes sie Zugangskontrollen. Die Authetfizierung ist so stark, daß diese Verbindung selbst dann kein Schlupfloch bietet, wenn der externe Host gekapert wird.
In anderen Fällen muß den Vermittlungsdiensten das gewünschte Ziel mitgeteilt werden. Dazu wird ein kleines Protokoll zwischne Client und Gateway benötigt. Per Protokoll fordert der Client Ziel und Dienst an und empfängt gegebenenfalls Fehlermeldungen des Gateways. Eine solche Implementierung nennt man häufig proxy. Ist die Verbindungsanfrage erfolgreich, terminiert das Protokoll und der eigentliche Datentransfer beginnt. Diese Dienste setzten Modifikation im Client Programm oder seiner Bibliotheken voraus.
Im allgemeinen kontrollieren Relaisdienste den durchfließenden Datenstrom nicht, Größe und Ziel wird normalerweise protokolliert.
Für eingehende Logins müssen sich Benutzer mit Einmal-Paßwort-Geräten gegenüber einem Authenifikationsserver ausweisen, ehe sie Zugang zu internen Maschinen gestettet bekommen. Erhalten sie diese Erlaubnis, so schaltet sie der Gateway mittels einer vorauthenifizierten Verbindung, wie etwa rlogin, nach innen durch.
|
