Application Proxy Erklärung

Gateways auf Anwendungsebene

• Im Gegensatz zu einem Circuit-Level-Gateway bedient ein Application-Level-Gateway nur ein Anwendungsprotokoll.
• Um diesen Punkt zu verdeutlichen, stellen Sie sich die Situation vor, in der der Paketfilter einer Firewall alle eingehenden Telnet- und FTP-Sitzungen blockiert, es sei denn, die Sitzungen werden von einem Bastion-Host (der ebenfalls Teil der Firewall-Konfiguration ist) beendet. Der Bastion-Host wiederum hostet ein Anwendungs-Gateway, das auf der Transport- (Leitungs-) oder Anwendungsschicht arbeitet. Die Situation ist in beiden Fällen etwas anders:

Wenn das Anwendungs-Gateway auf der Transportschicht arbeitet, muss ein Circuit-Level-Gateway (z. B. ein SOCKS-Server) auf dem Bastion-Host laufen.

Wenn das Anwendungs-Gateway auf der Anwendungsschicht arbeitet, gibt es grundsätzlich zwei Gateways oder Proxy-Server auf Anwendungsebene, die auf dem Bastion-Host ausgeführt werden müssen (d. h. ein Proxy-Server für Telnet und ein weiterer Proxy-Server für FTP).

In beiden Fällen muss ein Benutzer, der eine eingehende Verbindung zu einem Intranetserver herstellen möchte, seinen Telnet- oder FTP-Client mit dem Anwendungsgateway verbinden, das auf dem Bastion-Host ausgeführt wird. Das Anwendungs-Gateway wiederum würde dann den Benutzer authentifizieren und autorisieren. Im positiven Fall würde er eine sekundäre TCP-Verbindung zum Intranet-Server aufbauen und Anwendungsdaten zwischen den beiden TCP-Verbindungen hin und her leiten. Wenn das Anwendungs-Gateway ein Circuit-Level-Gateway wäre, würde es nicht in die Anwendungsdaten schauen, die es weiterleitet. Wenn das Anwendungs-Gateway jedoch ein Gateway auf Anwendungsebene wäre, würde es den Anwendungsdatenstrom untersuchen und vollständig steuern. Um das Abrufen interner Dateien von Systemen im Internet zu erschweren, könnte beispielsweise ein Gateway auf Anwendungsebene so konfiguriert werden, dass es die Verwendung des FTP-PUT-Befehls zulässt, aber die Verwendung des FTP-GET ablehnt Befehl. In ähnlicher Weise könnte ein Gateway auf Anwendungsebene für HTTP konfiguriert werden, um den Datenverkehr zu überprüfen und Java-Applets und ActiveX-Steuerelemente herauszufiltern, um interne Hosts vor Angriffen durch mobilen Code und Software zu schützen (diese Art der Filterung ist im Fall von Circuit- Level-Gateways).

• Aus Sicht des Clients erfordert die Interaktion mit einem Application Gateway einige zusätzliche Schritte.
• Im Allgemeinen erfordert die Verwendung eines Anwendungs-Gateways einige Anpassungen und Modifikationen entweder der Benutzerverfahren oder der Client-Software:
• Die Anpassung und Änderung der Benutzerprozeduren ist ein einfacher und unkomplizierter Ansatz zur Implementierung der Anwendungsgateway-Unterstützung
• Bei diesem Ansatz stellt der Benutzer zunächst eine Verbindung zum Application Gateway her und fordert dann den Aufbau einer zweiten Verbindung zum Server an. Ein wichtiger Vorteil besteht darin, dass die Anpassung der Benutzerverfahren im Allgemeinen keine Auswirkungen auf die Client-Software erfordert. Angesichts des umfangreichen Vorhandenseins von Client-Software ist dieser Ansatz attraktiv für die Implementierung des Internetzugangs (tatsächlich funktionierten die ersten Internet-Firewalls auf diese Weise). Der Hauptnachteil dieses Ansatzes besteht darin, dass der Benutzer für einen zusätzlichen Schritt geschult werden muss, um sich beim Proxy-Server anzumelden.

Der andere Ansatz zur Implementierung von Anwendungs-Gateway-Unterstützung besteht darin, die Client-Software anzupassen und zu modifizieren (ähnlich dem Prozess der ˜ ˜ Socketsifizierung eines Clients). Der Hauptvorteil dieses Ansatzes besteht darin, dass er Benutzern beim Zugriff auf das Internet und beim Durchqueren von Firewall-Systemen Transparenz bieten kann. Der Hauptnachteil besteht jedoch darin, dass offensichtlich Änderungen an der Client-Software erforderlich sind. Dies ist nicht immer möglich und selten einfach zu bewerkstelligen.

Beachten Sie, dass beide Ansätze schwerwiegende Nachteile haben, da sie eine Anpassung und Modifikation entweder der Benutzerprozeduren oder der Client-Software erfordern. Welcher Ansatz einfacher ist, hängt von der Anwendung, ihrer Verfügbarkeit im Quellcode und der Organisation ab, die die Anwendung verwendet. [fünfzehn]

Vor diesem Hintergrund wäre es schön, eine Firewall zu haben, die alle Software-Modifikationen, die für die Application-Gateway-Unterstützung erforderlich sind, in der Firewall vorhält. In diesem Fall müssten weder die Benutzerprozeduren noch die Client-Software entsprechend angepasst oder modifiziert werden. Diese Idee hat zur Entwicklung transparenter Firewalls geführt.

Kurz gesagt, eine transparente Firewall ist so konfiguriert, dass sie das Netzwerksegment der Firewall auf ausgehende TCP-Verbindungen überwacht und diese Verbindungen autonom im Namen des Clients weiterleitet. Beachten Sie jedoch, dass die Transparenz nicht unbedingt in beide Richtungen gegeben ist. Tatsächlich wird Inbound-Transparenz selten benötigt oder verwendet, da sich Benutzer normalerweise an einem Firewall-System authentifizieren müssen. Beachten Sie auch, dass eine transparente Firewall immer noch erfordert, dass alle Nachrichten