Application Proxy Erklärung: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
=Gateways auf Anwendungsebene=
 
=Gateways auf Anwendungsebene=
−
*Im Gegensatz zu einem Circuit-Level-Proxy bedient ein Application-Level-proxy nur ein Anwendungsprotokoll.
+
 
−
*Das bedeutet das eine Application Proxy das Anwendungsprotokoll verstehten muss.
+
*Ein Application-Level-Gateway (ALG) arbeitet auf der Anwendungsschicht (OSI-Schicht 7).
−
*Ein SSH Server kann als Application Proxy agieren, genau wie es in der Regel Mail und Nameserver tun.  
+
*Im Gegensatz zu einem Circuit-Level-Gateway ist ein Application-Level-Gateway auf ein bestimmtes Anwendungsprotokoll spezialisiert (z. B. HTTP, FTP, SMTP oder DNS).
−
*Aus Sicht des Clients erfordert die Interaktion mit ihm einige zusätzliche Schritte.  
+
*Es versteht den Aufbau und die Semantik des jeweiligen Protokolls und kann dadurch gezielt Inhalte analysieren, filtern oder umschreiben.
−
*Im Allgemeinen erfordert die Verwendung eines ihm einige Anpassungen
+
*Diese tiefe Protokollkenntnis ermöglicht eine sehr feingranulare Kontrolle, erfordert jedoch mehr Rechenleistung und Anpassung auf Client- oder Serverseite.
−
*Die kann über eine Modifikationen entweder der Benutzerverhaltens oder der Client-Software erfolgen
+
 
−
*Die Anpassung und Änderung der Benutzerprozeduren ist ein einfacher und unkomplizierter Ansatz zur Implementierung der Anwendungsgateway-Unterstützung
+
==Funktionsweise==
−
*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 Application-Level-Gateway vermittelt Anwendungsdaten zwischen Client und Server.
−
*Man verbindet sich mit einem SSH Server und von dort aus geht es dann auf andere Server.
+
*Der Client kommuniziert direkt mit dem Gateway, nicht mit dem Zielserver.
−
*Der Vorteil besteht darin, dass die Anpassung der Benutzerverfahren im Allgemeinen keine Auswirkungen auf die Client-Software erfordert.
+
*Das Gateway prüft und verarbeitet die Daten auf Anwendungsebene und stellt im Anschluss eine zweite Verbindung zum Zielsystem her.
−
*Der Hauptnachteil dieses Ansatzes besteht darin, dass der Benutzer für einen zusätzlichen Schritt geschult werden muss, um sich beim Proxy-Server anzumelden.
+
*So kann das Gateway z. B. schädliche Kommandos filtern, Befehle umschreiben oder die Sitzung überwachen.
−
*Der andere Ansatz zur Implementierung von Anwendungs-Gateway-Unterstützung besteht darin, die Client-Software anzupassen und zu modifizieren
+
*Da das Protokoll vollständig interpretiert wird, können auch Sicherheitsfunktionen wie Virenscan, URL-Filter oder Inhaltsprüfung integriert werden.
−
*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.  
+
==Client-Interaktion==
−
*Dies ist nicht immer möglich und selten einfach zu bewerkstelligen.
+
*Die Nutzung eines Application-Level-Gateways kann eine Anpassung des Benutzerverhaltens oder der Client-Software erfordern.
−
*Ein Alternative ist der Transparente Proxy
+
*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.
−
*Die Firewall leitet die Pakete an einen Proxy weiter und der übernimmt dann die Vermittelung.
+
*Dieser Ansatz ist einfach umzusetzen, erfordert jedoch eine kurze Einweisung der Benutzer.
−
*Der Benutzer merkt nichts.
+
*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.

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“