Application Proxy Erklärung: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
← Zum vorherigen Versionsunterschied
Keine Bearbeitungszusammenfassung
 
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).
*Aus Sicht des Clients erfordert die Interaktion mit ihm einige zusätzliche Schritte.  
*Im Gegensatz zu einem Circuit-Level-Gateway ist ein Application-Level-Gateway auf ein bestimmtes Anwendungsprotokoll spezialisiert (z. B. HTTP, FTP, SMTP oder DNS).
*Im Allgemeinen erfordert die Verwendung eines ihm einige Anpassungen
*Es versteht den Aufbau und die Semantik des jeweiligen Protokolls und kann dadurch gezielt Inhalte analysieren, filtern oder umschreiben.
*Die kann über eine Modifikationen entweder der Benutzerverhaltens oder der Client-Software erfolgen
*Diese tiefe Protokollkenntnis ermöglicht eine sehr feingranulare Kontrolle, erfordert jedoch mehr Rechenleistung und Anpassung auf Client- oder Serverseite.
*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.  
==Funktionsweise==
*Der Hauptnachteil dieses Ansatzes besteht darin, dass der Benutzer für einen zusätzlichen Schritt geschult werden muss, um sich beim Proxy-Server anzumelden.
*Ein Application-Level-Gateway vermittelt Anwendungsdaten zwischen Client und Server.
*Der andere Ansatz zur Implementierung von Anwendungs-Gateway-Unterstützung besteht darin, die Client-Software anzupassen und zu modifizieren
*Der Client kommuniziert direkt mit dem Gateway, nicht mit dem Zielserver.
*Der Hauptvorteil dieses Ansatzes besteht darin, dass er Benutzern beim Zugriff auf das Internet und beim Durchqueren von Firewall-Systemen Transparenz bieten kann.
*Das Gateway prüft und verarbeitet die Daten auf Anwendungsebene und stellt im Anschluss eine zweite Verbindung zum Zielsystem her.
*Der Hauptnachteil besteht jedoch darin, dass offensichtlich Änderungen an der Client-Software erforderlich sind.  
*So kann das Gateway z. B. schädliche Kommandos filtern, Befehle umschreiben oder die Sitzung überwachen.
*Dies ist nicht immer möglich und selten einfach zu bewerkstelligen.
*Da das Protokoll vollständig interpretiert wird, können auch Sicherheitsfunktionen wie Virenscan, URL-Filter oder Inhaltsprüfung integriert werden.
*Ein Alternative ist der Transparente Proxy
 
*Die Firewall leitet die Pakete an einen Proxy weiter und der übernimmt dann die Vermittelung.
==Client-Interaktion==
*Der Benutzer merkt nichts.
*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.

Aktuelle Version vom 4. November 2025, 22: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.xinux.net/index.php?title=Application_Proxy_Erklärung&oldid=65327“