Application Proxy Erklärung: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „=Gateways auf Anwendungsebene= *Im Gegensatz zu einem Circuit-Level-Gateway bedient ein Application-Level-Gateway nur ein Anwendungsprotokoll. *Um diesen Punkt…“)
 
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
=Gateways auf Anwendungsebene=
 
=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.
+
*Ein Application-Level-Gateway (ALG) arbeitet auf der Anwendungsschicht (OSI-Schicht 7).
 +
*Im Gegensatz zu einem Circuit-Level-Gateway ist ein Application-Level-Gateway auf ein bestimmtes Anwendungsprotokoll spezialisiert (z. B. HTTP, FTP, SMTP oder DNS).
 +
*Es versteht den Aufbau und die Semantik des jeweiligen Protokolls und kann dadurch gezielt Inhalte analysieren, filtern oder umschreiben.
 +
*Diese tiefe Protokollkenntnis ermöglicht eine sehr feingranulare Kontrolle, erfordert jedoch mehr Rechenleistung und Anpassung auf Client- oder Serverseite.
  
−
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).
+
==Funktionsweise==
 +
*Ein Application-Level-Gateway vermittelt Anwendungsdaten zwischen Client und Server.
 +
*Der Client kommuniziert direkt mit dem Gateway, nicht mit dem Zielserver.
 +
*Das Gateway prüft und verarbeitet die Daten auf Anwendungsebene und stellt im Anschluss eine zweite Verbindung zum Zielsystem her.
 +
*So kann das Gateway z. B. schädliche Kommandos filtern, Befehle umschreiben oder die Sitzung überwachen.
 +
*Da das Protokoll vollständig interpretiert wird, können auch Sicherheitsfunktionen wie Virenscan, URL-Filter oder Inhaltsprüfung integriert werden.
  
−
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).
+
==Client-Interaktion==
 +
*Die Nutzung eines Application-Level-Gateways kann eine Anpassung des Benutzerverhaltens oder der Client-Software erfordern.
 +
*Bei manueller Nutzung stellt der Benutzer zunächst eine Verbindung zum Application-Gateway her und fordert dann den Aufbau einer zweiten Verbindung zum Zielserver an.
 +
*Dieser Ansatz ist einfach umzusetzen, erfordert jedoch eine kurze Einweisung der Benutzer.
 +
*Alternativ kann die Client-Software angepasst werden, um die Kommunikation über das Gateway transparent abzuwickeln.
 +
*Diese Variante bietet Komfort und Automatisierung, ist jedoch aufwendiger, da die Software modifiziert oder speziell konfiguriert werden muss.
  
−
*Aus Sicht des Clients erfordert die Interaktion mit einem Application Gateway einige zusätzliche Schritte.  
+
==Transparente Proxys==
−
*Im Allgemeinen erfordert die Verwendung eines Anwendungs-Gateways einige Anpassungen und Modifikationen entweder der Benutzerverfahren oder der Client-Software:
+
*Eine Alternative sind transparente Proxys.
−
*Die Anpassung und Änderung der Benutzerprozeduren ist ein einfacher und unkomplizierter Ansatz zur Implementierung der Anwendungsgateway-Unterstützung
+
*Hier wird die Kommunikation des Clients automatisch von der Firewall oder dem Router an den Application-Proxy weitergeleitet.
−
*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 Benutzer merkt davon nichts – die Vermittlung erfolgt vollständig im Hintergrund.
 +
*Dieser Ansatz kombiniert zentrale Kontrolle mit hoher Benutzerfreundlichkeit.
  
−
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.
+
==Beispiele==
 +
*HTTP-Proxy (z. B. Squid, Apache mod_proxy)
 +
*FTP-Proxy (z. B. frox)
 +
*SMTP-Proxy (z. B. amavisd, postfix-filter)
 +
*DNS-Proxy oder -Resolver (z. B. dnsmasq, Unbound)
 +
*Web-Application-Firewalls (z. B. ModSecurity)
  
−
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]
+
==Fazit==
−
 
+
*Application-Level-Gateways analysieren und steuern Anwendungsprotokolle auf Schicht 7.
−
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.
+
*Sie bieten hohe Sicherheit und detaillierte Kontrolle, erfordern aber mehr Konfiguration und Rechenleistung.
−
 
+
*Transparente Proxys können viele ihrer Vorteile mit geringem Aufwand für den Benutzer kombinieren.
−
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
 

Aktuelle Version vom 4. November 2025, 20:49 Uhr

Gateways auf Anwendungsebene

  • Ein Application-Level-Gateway (ALG) arbeitet auf der Anwendungsschicht (OSI-Schicht 7).
  • Im Gegensatz zu einem Circuit-Level-Gateway ist ein Application-Level-Gateway auf ein bestimmtes Anwendungsprotokoll spezialisiert (z. B. HTTP, FTP, SMTP oder DNS).
  • Es versteht den Aufbau und die Semantik des jeweiligen Protokolls und kann dadurch gezielt Inhalte analysieren, filtern oder umschreiben.
  • Diese tiefe Protokollkenntnis ermöglicht eine sehr feingranulare Kontrolle, erfordert jedoch mehr Rechenleistung und Anpassung auf Client- oder Serverseite.

Funktionsweise

  • Ein Application-Level-Gateway vermittelt Anwendungsdaten zwischen Client und Server.
  • Der Client kommuniziert direkt mit dem Gateway, nicht mit dem Zielserver.
  • Das Gateway prüft und verarbeitet die Daten auf Anwendungsebene und stellt im Anschluss eine zweite Verbindung zum Zielsystem her.
  • So kann das Gateway z. B. schädliche Kommandos filtern, Befehle umschreiben oder die Sitzung überwachen.
  • Da das Protokoll vollständig interpretiert wird, können auch Sicherheitsfunktionen wie Virenscan, URL-Filter oder Inhaltsprüfung integriert werden.

Client-Interaktion

  • Die Nutzung eines Application-Level-Gateways kann eine Anpassung des Benutzerverhaltens oder der Client-Software erfordern.
  • Bei manueller Nutzung stellt der Benutzer zunächst eine Verbindung zum Application-Gateway her und fordert dann den Aufbau einer zweiten Verbindung zum Zielserver an.
  • Dieser Ansatz ist einfach umzusetzen, erfordert jedoch eine kurze Einweisung der Benutzer.
  • Alternativ kann die Client-Software angepasst werden, um die Kommunikation über das Gateway transparent abzuwickeln.
  • Diese Variante bietet Komfort und Automatisierung, ist jedoch aufwendiger, da die Software modifiziert oder speziell konfiguriert werden muss.

Transparente Proxys

  • Eine Alternative sind transparente Proxys.
  • Hier wird die Kommunikation des Clients automatisch von der Firewall oder dem Router an den Application-Proxy weitergeleitet.
  • Der Benutzer merkt davon nichts – die Vermittlung erfolgt vollständig im Hintergrund.
  • Dieser Ansatz kombiniert zentrale Kontrolle mit hoher Benutzerfreundlichkeit.

Beispiele

  • HTTP-Proxy (z. B. Squid, Apache mod_proxy)
  • FTP-Proxy (z. B. frox)
  • SMTP-Proxy (z. B. amavisd, postfix-filter)
  • DNS-Proxy oder -Resolver (z. B. dnsmasq, Unbound)
  • Web-Application-Firewalls (z. B. ModSecurity)

Fazit

  • Application-Level-Gateways analysieren und steuern Anwendungsprotokolle auf Schicht 7.
  • Sie bieten hohe Sicherheit und detaillierte Kontrolle, erfordern aber mehr Konfiguration und Rechenleistung.
  • Transparente Proxys können viele ihrer Vorteile mit geringem Aufwand für den Benutzer kombinieren.
Abgerufen von „http://wiki.ixheim.de/index.php?title=Application_Proxy_Erklärung&oldid=65327“