Inhaltsverzeichnis:
2. Teil
3. Teil
In diesem Abschnitt wollen wir einige Richtlinien, die beim Afubau
von Bastion Hosts beachtet werden sollten, näher erläutern.
Dabei spielt es keine Rolle, ob der Bastion Host in einem Firewall
mit Paketfilterung oder Proxy-Diensten eingesetzt wird. Die Prinzipien
und Vorgehensweisen sind in beiden Fällen ähnlich.
Grundlagen
Einer der Prinzipien, die beim Aufbau von Bastion Hosts beachtet
werden sollte ist, daß die Bastion Hosts so einfach wie
möglich aufgebaut sein sollten. Da ein Bastion Host am ehesten
einem Angriff aus Internet ausgesetzt ist, sollte er besonders
geschützt werden. Je einfacher er aufgebaut ist, desto einfacher
ist er auch zu schützen. Nur die absolut nowendigen Dienste
sollten auf dem Bastion Host laufen, da durch Software- oder Konfigurationsprobleme
dieser Dienste Sicherheitslücken entstehen könnten.
Auswahl der Hard- und Software
Es empfiehlt sich, einen Rechner nur als Bastion Host einzusetzen, weil ein voll konfigurierter Bastion Host eine ziemlich eingeschränkte Umgebung und deswegen für andere Zwecke nicht geeignet ist. Als Betriebssystem empfehlen sich gängige Serverbetriebssysteme wie Windows NT oder verscheidene UNIX Varianten, wobei für Internetdienste UNIX häufiger eingesetzt wird. Im folgenden gehen wir deswegen davon aus, daß ein auf UNIX basierendes Bastion Host aufgebaut wird.
Beim Auswahl der Hardware ist meistens kein sehr schneller Rechner
notwendig, da die Leistung eines Bastion Hosts eher von der Bandbreite
der Netzanbindung als von der Leistungsfähigkeit des Rechners
abhängt. Diese Aussage gilt allerdings nur dann, wenn auf
dem Bastion Host nur einfache Dienste wie FTP oder SMTP eingesetzt
werden. Bei anspruchsvolleren Diensten wie NNTP oder Suchmaschinen
sollten entsprechend leistungsfähigere Rechner eingesetzt
werden. Allerdings sollte auch in diesem Fall kein überdimensionerter
Rechner als Bastion Host arbeiten, da langsame Rechner für
Angreifer weniger interessant sind. Bei der Zuverlässigkeit
und Ausbaufähigkeit des Rechners sollte man allerdings keine
Kompromisse eingehen. Beim Standplatz des Bastion Hosts sollte
man beachten, daß nur dazu berechtigte Leute physikalischen
Zugang zum Rechner haben.
Plazieren des Bastion Hosts im Netz
Da bei den Ethernet und Token Ring Netzen Datenpakete
auch Rechner passieren, für die sie nicht bestimmt sind,
sind Bastion Hosts in solchen Netzen besonders gefährdet.
Dadurch können Angreifer, die in den Bastion Host eingbrochen
sind, aus Datenpaketen von FTP , Telnet oder rlogin-Sitzungen
Loginnamen oder Paßwörter extrahieren. Deswegen sollte
man den Bastion Host möglichst in einem Grenznetz unterbringen,
der vom internen Netz durch einen Router getrennt ist. Falls das
nicht möglich ist, sollte man zumindest den Bastion Host
in einem nicht abhörgefährdeten Teil des internen Netzes
unterbringen. Ein intelligenter 10BaseT-Hub oder ein Ethernet
Switch ist dafür geeignet.
Auswahl der Dienste auf dem Bastion Host
Auf dem Bastion Host sind nur solche Dienste einzusetzen,
die man entweder im Internet anbieten möchte und/oder die
für den Zugang zum Internet notwendig sind. Von diesen Diensten
können diejenigen, die als sicher eingestuft wurden, über
Paketfilterung realisiert werden. Die restlichen müssen entweder
deaktiviert oder auf einem Bastion Host angeboten werden. Die
richtige Konfiguration der einzelnen Dienste für die Zusammenarbeit
mit dem Firewall wird im nächsten Abschnitt näher behandelt.
Einrichten eines Bastion Hosts
Absichern des Rechners
Am Anfang sollte auf dem für den Bastion Host vorgesehenen Rechner ein Betriebssystem in minimaler Konfiguration installiert werden. Als nächstes sollte man sich die Patches für die bekannten Probleme des Betriebssystems besorgen.
Der nächste Schritt ist einen sicheren Ort für die verschiedenen Systemprotokolle zu bestimmen. Als sicherheitsrelevanter Rechner wird der Bastion Host ausführliche Protokolle anlegen. Erstens sollten sie für den Administrator bequem erreichbar sein, gleichzeitig sollten sie für potentielle Angreifer unerreichbar bleiben. Diesen widersprüchlichen Anforderungen kann man gleichzeitig gerecht werden, indem man zwei Fassungen von Protokollen anlegt. Die erste Fassung der Protokolle kann man auf dem Bastion Host lassen oder in einem internen Rechner unterbringen. Diese Fassung wird im Normalfall verwendet. Eine zweite Fassung wird an einem Ort untergebracht, der von Angreifern nicht modifizert werden kann. Z.B kann man Protokolle an einen Drucker schicken oder auf einem nur einmal beschreibbaren Medium unterbringen.
Auf UNIX erfolgt die Protokollierung über den Syslog-Dämon.
Syslog nimmt Meldungen von lokalen oder entfernten Clients auf.
Diese Meldungen sind mit Herkunfts- und Prioritätsinformationen
versehen. Anhand dieser Auskunft und der Einstellungen in der
syslog.conf Datei kann syslog diese Meldungen ignorieren, in ein
oder mehreren Dateien speichern, zu einem anderen Syslog-Dämon
weiterleiten oder auf dem Bildschirm anzeigen. Auch Netzgeräte
wie Router können so konfiguriert werden, daß sie über
syslog protokollieren. Ein Nachteil von syslog ist, daß
er auf UDP basiert und deswegen nicht weiß, ob seine Pakete
richtig angekommen sind, wenn er Meldungen weiterleitet.
Deaktivieren überflüssiger Dienste
Da jedes auf dem Bastion Host angebotene Dienst Bugs oder Konfigurationsfehler enthalten kann, die zu Sicherheitsproblemen führen kann, sollten nicht benötigte Dienste deaktiviert werden.
Auf UNIX Systemen werden Dienste, die unbegrenzt laufen sollen, meistens durch Einträge in den Systemdateien /etc/rc* gestartet. DNS oder SMTP gehören zu solchen Diensten. Dienste, die nur bei Bedarf laufen sollen, werden vom inetd Server gestartet. Der inetd Server wartet, bis ein Dienst, der in /etc/inetd.conf festgelegt ist, benötigt wird und startet den benötigten Server. FTP oder Telnet zählt zu solchen Diensten. Dienste deaktiviert man, indem man die entsprechenden Zeilen in diesen Dateien auskommentiert. Stellt man nach dem Booten fest, daß der Rechner auch ohne die deaktivierten Dienste einwandfrei funktioniert, kann man die Programmdateien überflüssiger Dienste löschen, damit sie von anderen nicht mehr aktiviert werden können.
Die Frage, welche Dienste aktiv bleiben und welche deaktiviert werden sollten, ist nicht ganz einfach zu beantworten. Es gibt Dienste, die für den Betrieb eines UNIX Rechners unerläßlich sind. Dazu zählen init, swap, page, cron, syslogd, inetd und einige andere. Dazu kommen natürlich die Server-Prozesse zu den Diensten, die man auf dem Bastion Host anbieten möchte. Bei der Auswahl der zu deaktivierenden Dienste kann man nach folgenden Regeln vorgehen:
1)Dienste, die nicht benötigt werden, wird abgeschaltet.
2)Dienste, deren Zweck unklar ist, werden deaktiviert.
3)Funktioniert der Rechner nicht mehr, weiß man wozu der
Dienst gut war. Man kann ihn entweder wieder einschalten, oder
herausfinden, wie man ohne diesen Dienst auskommt.
Vor allem deaktivieren sollte man NFS und verwandte Dienste. Kein interner Rechner sollte dem Bastion Host soweit vertrauen, daß dieser die Platten des internen Rechners über NFS einhängen darf. Auch gibt es auf dem Bastion Host nichts, was man über NFS exportieren sollte.
Auch Dienste, die auf dem RPC System basieren, sollten deaktiviert werden. Dazu gehört NIS/YP (Network Information Services/Yellow Pages), rexd (Remote Execution Service) und walld (Write All Dämon). Deaktiviert man alle RPC Dienste, dann kann man auch portmap deaktivieren.
Da kein interner Rechner vom Bastion Host booten sollte, sollten auch Boot Dienste deaktiviert werden. Dazu zählen bootd und bootpd.
Auch routed kann auf dem Bastion-Host vermutlich deaktiviert werden. Anstelle dessen sollte man statische Routen einrichten, die in das interne Netz weisen. Dazu kommt eine Standard Route, der zum Internet führt. Für dynamisches Routing kann man statt routed gated verwenden, wo man angeben kann, von welchen Rechnern Routinginformationen akzeptiert werden. Sicherstellen sollte man auch, daß neben IP Forwarding auch Source Routing auf dem Bastion Host ausgeschaltet ist.
Auch fingerd gehört zu den Kandidaten für die Deaktivierung, da Angreifer durch finger wertvolle Informationen über Benutzer und ihre Kennungen erhalten können wie z.B. welche Kennungen überhaupt vorhanden sind, persönliche Angaben, welche Kennungen selten benutzt werden, etc.
Welche weitere Dienste deaktiviert werden können, hängt
von der jeweiligen Sicherheitspolitik des Standortes ab.
Neukonfiguration des Bastion Hosts für den Dauerbetrieb
Um den Bastion Host für den Dauer Betireb vorzubereiten,
ist es notwendig, wie wir im letzten Kapitel gesehen haben, alle
unnötigen Dienste zu löschen. Danach wird man aber feststellen,
daß es sich auf dem Bastion Host sehr eingeschränkt
arbeiten läßt, wenn es um die Installation oder Update
von Diensten geht. Deswegen sollte man für diesen Fall eine
externe Boot-Platte verwenden, die nach der Arbeit wieder entfernt
wird.
Unter Umständen ist es bei der Konfiguration des Rechners notwendig, den Kernel neu zu kompilieren. Dabei sollte man auf die Abhängigkeiten zwischen verschiedenen Funktionen achten. Man muß vermeiden, daß durch Weglassen von Funktionen der Kernel bootunfähig wird.
Der nächste Schritt ist das Entfernen von überflüssigen Programmen. Da der Bastion Host nur zum Anbieten von Internet Diensten und nicht als eine komfortable Arbeitsumgebung gedacht ist, sollten auch für die tägliche Arbeit als wichtig eingestufte Programme gelöscht werden. Dazu gehören u.a. setgid/setuid-Programme und Compiler. Auch Fenstersysteme wie X sollten, wenn vorhanden, gelöscht werden.
Hat man alle überflüssigen Programme gelöscht,
sollte man die Dateisysteme auf dem Bastion Host als nur lesbar
einhängen, damit die Konfiguration von niemandem geändert
werden kann. Nur für temporäre Dateien, Systemprotokolle,
Swapping und Mail Spool sollte man beschreibbare Bereiche vorsehen.
Programme zur Sicherheitsüberprüfung
Nach der Neukonfiguration des Bastion Hosts sollte man eine Sicherheitsüberprüfung
(auditing) vor. Damit stellt man einerseits sicher, daß
man nichts übersehen hat, andererseits bekommt man ein Basisprotokoll,
mit dem man spätere Basisprotokolle vergleichen und somit
Manipulationen aufdecken kann. Zu diesem Zweck kann man verschiedene
Auditing Pakete wie COPS, Tiger, Tripwire oder SATAN einsetzen.
Einige dieser Pakete beinhalten auch Programme, die auch Prüfsummen
von Dateien erstellen, sodaß man spätere Manipulationen
von Dateien entdecken kann.
Betrieb des Bastion Hosts
Nachdem man den Bastion Host in einem sicheren Raum aufgestellt hat, kann man ihn in Betrieb nehmen. Während dem Betrieb des Bastion Hosts ist es wichtig, das System genau zu überwachen. Um ungewöhnliche Begebenheiten zu entdecken, ist es notwendig zu wissen, wie viele Prozesse normalerweise laufen, wie viel CPU Zeit diese Prozesse etwa beanspruchen und mit welcher Belastung zu verschiedenenen Tageszeiten zu rechnen ist. Abweichungen von diesen Durchsichnittswerten sollten genauer untersucht werden.
Obwohl jeder Bastion Host anders aufgebaut ist, gibt es einige nützliche Tools, die die Überwachung des Bastion Hosts teilweise automatisieren können. SWATCH ist ein gutes Beispiel für ein solches Tool. SWATCH sichtet die von syslog erzeugten Protokolle und kann so konfiguriert werden daß er auf bestimmte Ereignisse reagiert. Mehrere Versuche, mit der gleichen Kennung einzuloggen oder eine 'file system full' Meldung wären z.B. solche Ereignisse.
Abstürze und erneutes Booten sollten auf dem Bastion Host
nur selten vorkommen. Ein gut konfiguriertes Bastion Host ist
eigentlich ein stabiles System, daß oft wochen- und monatelang
ohne Probleme läuft. Falls es aber doch abstürzen sollte,
sollte man sich an die Ursachen machen und herausfinden, ob ein
harmloses Problem oder ein Angriff dahintersteckt. Um sicherzugehen,
sollte man den Bastion Host so konfigurieren, daß es nach
einem Absturz nicht mehr bootet.
Paketfilterung ist ein Netzwerk-Sicherheitsmechanismus, der überprüft, welche Pakete an ein Netz und aus einem Netz weitergereicht werden dürfen. Dazu werden die Quelle- und Zieladressen in den Datenpaketen verwendet. Man kann auch mittels Paketfilterung Pakete bestimter Protokolle zulassen oder blockieren. Allerdings kann man nicht innerhalb eines Protokolls Verbindungen von bestimmten Benutzern zulassen oder blockieren, da Pakete keine Informationen darüber enthalten, von welchem Benutzer sie kommen. Der wesentliche Vorteil von Paketfilterung ist, daß man von einer einzigen Stelle aus detaillierte Schutzmaßnahmen ergreifen kann, die im ganzen Netzwerk wirksam sind.
Gewisse Schutzmechanismen können ausschileßlich durch Router mit Paketfilterung bereitgestellt werden und dies auch nur, wenn sie an bestimmten Stellen im Netzwerk eingestezt werden. Ein Router an der Grenze zwischen dem internen Netz und dem Internet kann zum Beispiel alle Pakete aus dem Internet zurückweisen wenn als Quelladresse im Paket eine interne Adresse angegeben ist. Solche Pakete gehören gewöhnlich zu Angriffen durch Adreßmogeleien. Ein anderer Vorteil von Paketfilterung ist, daß sie kein Anwenderwissen und keine Mitarbeit von Benutzern erfordert, da anders als bei der Proxy Technik keine Anpassung der Software auf der Clientseite notwendig ist. Außerdem ist Paketfilterung in vielen Hard- und Software-Routern enthalten, sodaß dafür nichts dazugekauft werden muß.
Paketfilterung hat allerdings auch einige Nachteile. Einer davon
ist, daß Paketfilterungsregeln oft schwer formulierbar und
einmal ausformuliert, auch schwer zu testen sind. Da Pakete zwar
angeben, zu welchem Port sie gehören, nicht aber zu welcher
Anwendung, muß man, wenn man Einschränkungen in bezug
auf höhere Protokolle als IP festlegen, dazu Portnummer verwenden.
Dabei kann man nur hoffen, daß nichts anderes über
den Port läuft, den sie einem bestimmten Protokoll zugewiesen
haben. Böswillige Eingeweihte können diese Art von Kontrolle
jedoch leicht hintergehen. Es gibt allerdings auch einige wenige
Paketfilterungssysteme, die Pakete anhand der Anwendungsprotokolle
filtern.
Kofigurieren eines Routers zur Paketfilterung
Um eine Router mit Paketfilterung einzurichten, muß man zuerst festlegen, welche Dienste man überhaupt zulassen möchte. Danach muß man die dazu notwendigen Regeln ausformulieren. Ein Punkt, der dabei beachtet werden sollte ist, daß Protokolle gewöhnlich bidirektional sind. Deswegen muß man, wenn man ein Protokoll zulassen oder unterbinden möchte, dafür sorgen, daß die Pakete in beiden Richtungen zugelassen oder blockiert sind.
Man sollte Paketfilterungsysteme so konfigurieren, daß mitprotokolliert wird, welche Pakete verworfen wurden, da man dadurch erkennen kann , welche Angriffe an der Paketfilterung gescheitert sind.
Ein weiterer Punkt, der bei der Konfiguration des Paketfilters
berücksichtigt werden sollte ist, ob der Router bei verworfenen
Paketen eine ICMP-Meldung an den Host, von dem der Paket
stammt, zurückschicken sollte oder nicht. Dabei sollte vermieden
werden, daß Angreifer durch diese Meldungen zu viele Informationen
über die Paketfilterung erhalten. Schickt man zu jedem abgelehnten
Paket eine ICMP-Meldung zurück, gibt man dem Angreifer die
Möglichkeit, das Filtersystem auszutesten und herauszufinden,
welcher Typ von Paketen überhaupt zugelassen sind. Deswegen
ist es sicherer, entweder überhaupt keine ICMP-Meldungen
oder nur an interne System zu schicken.
Aufstellen von Paketfilteregeln
Nun geben wir ein kleines Beispiel dafür, wie Paketfilterungsregeln ausschauen könnten. Der Router geht dabei der Reihe nach alle Regeln durch und führt für jeden Paket die entsprechende Regel durch. Wird für den jeweiligen Paket kein Regel gefunden, wird er abgelehnt. Wenn wir annehmen, daß man jeglichen IP-Verkehr zwischen einem zuverlässigen externen Rechner (Host 172.16.51.50) und Rechnern des internen Nezwerks (Netz der Klasse C 192.168.10.0) zulassen. Für das screend-Paketfilterungssystem würden dann die Regeln so ausschauen:
between host 172.16.51.50 and net 192.168.10 accept;
between host any and host any reject;
Filterung nach Adressen
Pakete nach ihrer Quell- und/oder Zieladresse zu filtern ist die einfachste Methode. Es gibt allerdings einige Risiken dabei. Wenn man z.B. nach der Quelladresse filtert, kann man nicht sicher sein, daß die Quelladressen nicht gefälscht sind. Dadurch können Angreifer das Filtersystem umgehen. Angriffe, wo die Quelladresse der Pakete gefälscht werden, finden meist dann statt, wo die Antwortpakete für den Angreifer nicht von Bedeutung sind, da die Antworten voraussehbar sind. Das wäre z.B. dann der Fall, wenn der Anfgreifer den Befehl absetzen möchte, die Paßwort-Datei per Email ihm zu schicken. Dabei ist auch wünschneswert, daß der echte Rechner, mit dem der angegriffene Rechner glaubt , in Verbindung zu stehen, keine Antwortpakete von diesem bekommt. Das ist zu erreichen, in dem man vor dem Angriff den echten Rechner zum Absturz bringt oder den Angriff dann ausführt, wenn der echte Rechner nicht einsatzbereit ist.
Es gibt aber auch Angriffsmethoden, wo man sowohl gefälschte
Pakete schicken als auch die Antwortpakete erhalten muß.
Das kann man bewerkstelligen, indem der angreifende Rechner unbemerkt
in den Pfad zwischen dem Firmennetz und dem echten Rechner eingehängt
wird. Oder aber kann man den Pfad so anpassen, daß er über
den angreifenden Rechner führt. Theoretisch kann man also
nie sicher sein, daß man mit dem vertrauten Rechner in Verbindung
steht. Ist nur der Pfad und nicht der externe Rechner gefährdet,
kann man mittels Kryptographie eine zuverlässige Verbindung
aufbauen.
Filterung nach Diensten
Den Risiken der Paketfilterung nach Adressen kann man zum Teil
entgehen, indem man in die Filterung auch die Dienste einbezieht.
Als Beispiel dafür wollen wir hier Telnet näher untersuchen.
Eine Beschreibung der Paketfilterungseigenschaften anderer Dienste
findet man im nächsten Abschnitt. Wir wollen mittels Paketfilterung
Telnet Verbindungen vom internen Netz zum Internet zulassen und
alles andere blockieren. Dazu müßte man drei Regel
aufstellen: Der erste Regel läßt TCP Pakete, die von
innen nach außen gerichtet sind und ein Quellport von >
1023 und ein Zielport von 23 haben, zu. Der zweite Regel erlaubt
kommende TCP Pakete zu, die als Quellport 23 und als Zielport
> 1023 haben und deren ACK Bit gesetzt ist. Der letzte Regel
blockiert schließlich alle Pakete, die von den obigen Regeln
nicht zugelassen wurden.
Wahl eines Routers zur Paketfilterung
Hier fassen wir einige Tips zusammen die bei der Wahl eines Routers für Paktfilterung nützlich sein können.
Ein wichtiger Regel ist, daß ein Router (egal, ob es als Hard oder Software implementiert ist), erlauben sollte, Paketfilterungsregeln einfach aufzustellen. Es sollte möglich sein, Regeln auf einer gewissen Abstraktionsebene aufstellen zu lassen. Es sollte eine komfortable Benutzeroberfläche vorhanden sein, mit der man Regeln bearbeiten kann.
Es sollte mit dem gewählten Router möglich sein, Regeln zu allen Header- und Metainformationen, die zu einem Paket vorhanden sind, aufzustellen. Zu den Header-Informationen zählen unter anderem:
Metainformationen sind solche Daten, die zwar nicht in den Datenpaketen stehen aber dem Router trotzdem bekannt sind. Dies wäre z.B. die Schnittstelle, über die ein Paket eintrifft oder weitergeleitet wird.
Es sollte möglich sein, verschiedene Regelsätze für
verschiedene Schnittstellen aufstellen zu können. Notwendig
ist auch, daß die Regeln in der Reihenfolge angewandt werden
sollten, in der sie aufgestellt wurden, da ansonsten das Verhalten
des Routers schwer nachvollziehbar wäre. Eine Möglichkeit,
abgelehnte Pakete zu protokollieren, wäre nützlich,
um einen Überblick über die bisherigen Angriffsversuche
zu erhalten. Der Router sollte sowohl eingehende als auch ausgehende
Pakete filtern können.
Ein Paketfilterungsbeispiel
Nun wollen wir anhand eines Beispiels zeigen wie die Regeln funktionieren. Der folgende Regelsatz ermöglicht ein- und ausgehende SMTP Verbindungen und blockiert alles andere:
| Regel | Richtung | Quelladr. | Zieladr. | Protokoll | Quellport | Zielport | ACK Bit | Aktion |
| A | ein | extern | intern | TCP | >1023 | 25 | beliebig | zulassen |
| B | aus | intern | extern | TCP | 25 | >1023 | ja | zulassen |
| C | aus | intern | extern | TCP | >1023 | 25 | beliebig | zulassen |
| D | ein | extern | intern | TCP | 25 | >1023 | ja | zulassen |
| E | beliebig | beliebig | beliebig | beliebig | beliebig | beliebig | beliebig | verbieten |
Die ersten zwei Regeln A und B erlauben eingehende SMTP-Verbindungen (eintreffendes E-Mail). Die nächsten zwei Regeln C und D ermöglichen hinausgehende SMTP-Verbindungen (hinausgehendes E-Mail). Der letzte Regel E ist die Standardregel, die angewandt wird, wenn keine der anderen Regel greift.
Die Überprüfung des Quellports ist notwendig, um Angriffe
von außen zu vermeiden, wo ein- und ausgehende Pakete
ein Zielport >1023 haben. Ohne Quellportüberprüfung
würden nämlich Regel B und D solche Verbindungen zulassen.
Um zu vermeiden, daß das Firmennetz mit Paketen angegriffen
wird, die als Quellport 25 verwenden, wird zustäzlich geprüft
(durch den Regel D), ob bei eingehenden Paketen der ACK Bit gesetzt
ist. Dadurch wird sichergestellt, daß nur Pakete akzeptiert
werden, die zu einer Verbindung gehören, deren Initiative
von einer internen Client ausgegangen ist.
Proxy Systeme bieten Internet-Zugang zu einem einzigen oder einigen
wenigen Rechnern, erwecken dabei jedoch den Anschein, Zugriff
auf alle Rechner im Netz zu gewähren. Die Rechner mit Zugriffsmöglichkeiten
dienen als Stellvertreter (Proxies) für die Maschinen ohne
Zugang, für die sie die gewünschten Aufgaben erledigen.
Der Server läuft normalerweise auf einem Dual-Homed Host
oder Bastion Host, sieht sich die Anfragen von Clients an und
entscheidet, welche an den echten Server weiterzureichen und welche
zu ignorieren sind. Dabei ist für den Bentuzer des Clients
nicht zu unterscheiden, ob er mit dem echten Server oder mit dem
Proxy server kommuniziert. Der Server glaubt dabei, mit Benutzer
zu kommunizieren, die auf dem Proxy Server arbeiten. Wichtig für
das ganze ist, daß Proxy Server in Kombination mit einem
Verfahren eingesetzt werden, der keine IP Verbindungen zwischen
dem Client und dem echten Server zuläßt. Ein Überwachungsrouter
etwa, der keine Pakete routet, wäre dazu geeignet.
Nachteile
Dem größten Vorteil der Proxies, nämlich der Transparenz
für die Benutzer, stehen einige Nachteile gegenüber.
Erstens erfordern Proxies u.U. für jeden Dienst einen eigenen
Server. Die Installation und Konfiguration all dieser Server kann
sehr umständlich werden. Zweitens müssen für den
Einsatz von Proxies gewöhnlich Clients angepaßt und/oder
geändert werden. Drittens schützen Proxies nicht vor
Schwächen im Protokoll (z.B. X11). Und zuletzt kann man nicht
jedes Dienst über Proxies einsetzen.
Funktionsweise
Um Proxies einzusetzen barucht man auf der Serverseite spezielles Proxysoftware. Auf der Clientseite gibt es zwei Ansätze:
Angepaßte Client-Software: Bei diesem Ansatz muß die Software wissen, wie sie bei einer Benutzeranfrage den Proxy-Server anstelle des eigentlichen Servers anspricht. Außerdem muß sie dem Proxy Server mitteilen, zu welchem echten Server eine Verbindung hergestellt werden soll.
Modifizierte Verfahren für Benutzer: Bei dieser Methode
kommuniziert der Benutzer anhand von Standard Client Software
nicht direkt mit dem eigentlichen Server, sondern mit dem Proxy
Server, den er anweist, eine Verbindung zum echten Server herzustellen.
Application- und Circuit-Level-Proxies
Bei Application Level Proxies kennt der Proxy Server die Anwendung, für die es Proxy Dienste leistet. Er versteht und interpretiert die Kommandos im Anwendungsprotokoll. Ein Circuit Level Proxy hingegen schließt ein Kreis zwischen Client und Server, ohne das Anwendungsprotokoll zu interpretieren. Deswegen haben sie bei Protokollen wie FTP, wo Protokollinformationen vom Client an den Server übermittelt werden, Probleme, da hier auf Anwendungsprotokollebene eingegriffen werden muß. Sie werden auch von Servern leicht getäuscht, die an Portnummern eingerichtet werden, die eigentlich anderen Servern zugeordnet sind.
Viele Proxy Server können mehr, als nur Anfragen weiterzureichen.
Sie können Daten im Cache behalten, sodaß Anfragen
nach denselben Daten nicht jedesmal ins Internet gesendet werden
müssen. Solche Server werden intelligente Proxies
genannt.
Geschrieben von Vahan Harput, 1996