Circuit Level Proxy (generischer Proxy) Erklärung - Versionsgeschichte

Thomas.will am 4. November 2025 um 20:47 Uhr

2025-11-04T20:47:56Z

Thomas.will am 6. Dezember 2022 um 10:41 Uhr

2022-12-06T10:41:49Z

Thomas.will am 30. August 2022 um 11:32 Uhr

2022-08-30T11:32:47Z

Thomas.will: Die Seite wurde neu angelegt: „*Als Circuit Level Proxy (auch Generischer Proxy genannt) wird ein Paketfiltermodul bezeichnet, mit dem man auf einer Firewall beliebige IP-Adressen und Ports…“

2022-08-30T10:33:40Z

Die Seite wurde neu angelegt: „*Als Circuit Level Proxy (auch Generischer Proxy genannt) wird ein Paketfiltermodul bezeichnet, mit dem man auf einer Firewall beliebige IP-Adressen und Ports…“

Neue Seite

*Als Circuit Level Proxy (auch Generischer Proxy genannt) wird ein Paketfiltermodul bezeichnet, mit dem man auf einer Firewall beliebige IP-Adressen und Ports sperren bzw. freischalten kann, ohne jedoch die Möglichkeit zu haben, die Paketinhalte damit zu analysieren.
*Ein solcher Proxy, der auf den OSI-Schichten 3 und 4 operiert, reicht die Pakete mitunter einfach durch, ohne die Verbindungen selbst zu terminieren.
*Der Circuit Level Proxy realisiert die Adressumsetzung dann mithilfe von NAT auf der OSI-Schicht 3.
*Während die Adressfilterung ebenfalls auf der dritten OSI-Schicht angesiedelt ist, realisiert er zudem eine Port-Filterung auf der vierten OSI-Schicht.
*Es gibt auch Circuit Level Proxys, die dank einem speziellen Protokoll eine Authentifizierung auf der OSI-Schicht 5 realisieren können.
*Der Client holt sich so eine Verbindungsgenehmigung z. B. per Eingabe einer Kennung nebst Passwort.
*Dieses spezielle Authentifizierungsprotokoll muss der Client allerdings kennen, weshalb ein derart befähigter Circuit Level Proxy weniger generisch ist (er funktioniert nur mit Anwendungen auf dem Client zusammen, die entsprechend erweitert wurden). Als Beispiel für ein solches Authentifizierungsprotokoll sei SOCKS genannt.
*Solch ein erweiterter Circuit Level Proxy greift nicht zwangsläufig auf NAT zurück.
*Einige von ihnen machen dies gar vom Protokoll abhängig; so wird z. B. die TCP-Verbindung terminiert, während eine UDP-Verbindung schlicht weitergereicht wird.
*Ein generischer Proxy kann auch für eine einfache Weiterleitung genutzt werden.
*Der denkbar einfachste Proxy ist das Linux-Programm Redir, das auf einer Schnittstelle und einem Port lauscht und die Daten auf ein anderes Interface und Port weitergibt.
*Dies ist auch mit dem iptables-Kommando unter Linux möglich und wird beispielsweise verwendet, um den Exit-Datenverkehr eines Tor-Servers über mehrere Proxys zu leiten, um so den Tor-Server zu schützen.

@@ Zeile 1: / Zeile 1: @@
 =Gateways auf Leitungsebene=
-*Im Wesentlichen ist ein Circuit-Level-Gateway ein Proxy-Server für TCP
-*Genauer gesagt macht ein Circuit-Level-Gateway die folgenden drei Dinge, wenn ein Client eine TCP-Verbindung zu einem Server herstellen möchte
+*Ein Circuit-Level-Gateway (Schaltungsebene-Gateway) arbeitet auf der Transportebene (OSI-Schicht 4) und vermittelt TCP- oder UDP-Verbindungen zwischen zwei Netzwerken.
-*Es empfängt die TCP-Verbindungsaufbauanforderung, die vom Client gesendet wird (weil der Client so konfiguriert ist, dass er das Circuit-Level-Gateway verwendet).
+*Im Wesentlichen handelt es sich dabei um einen Proxy-Server für TCP-Verbindungen.
-*Es authentifiziert und autorisiert möglicherweise den Client (oder den Benutzer hinter dem Client).
+*Das Gateway übernimmt die Sitzungserstellung zwischen Client und Server, ohne in den Datenstrom auf Anwendungsebene einzugreifen.
-*Er baut im Auftrag des Clients eine zweite TCP - Verbindung zum Server auf .
-*Nachdem die zweite TCP-Verbindung erfolgreich aufgebaut wurde, leitet das Circuit-Level-Gateway einfach Anwendungsdaten hin und her.
+==Funktionsweise==
-*Als solches stört es den Datenstrom nicht.
+*Ein Client ist so konfiguriert, dass er seine Verbindungen über das Circuit-Level-Gateway aufbaut.
-*Dies unterscheidet ein Circuit-Level-Gateway von einem Application-Level-Gateway.
+*Wenn der Client eine TCP-Verbindung zu einem Zielserver öffnen möchte:
-*Da der  Application-Level-Gateway das von den beiden Endpunkten der Verbindung verwendete Anwendungsprotokoll verstehen kann.
+**Das Gateway empfängt die Verbindungsanforderung vom Client.
-*Das bedeutet im Grunde, dass das Circuit-Level-Gateway das verwendete Anwendungsprotokoll nicht verstehen muss.
+**Es kann den Benutzer oder den Client authentifizieren und autorisieren.
-*Dies vereinfacht die Implementierung und den Einsatz von Circuit-Level-Gateways erheblich.
+**Es baut im Auftrag des Clients eine zweite TCP-Verbindung zum Zielserver auf.
-*Das wichtigste Gateway auf Schaltungsebene, das heute verwendet wird, ist SOCKS.
+*Nach erfolgreichem Aufbau der zweiten Verbindung leitet das Gateway die Datenpakete zwischen den beiden Verbindungen unverändert weiter.
-*Es ist ein Circuit-Level-Gateway, das einem angepassten Client-Ansatz folgt, was bedeutet, dass es Anpassungen und Modifikationen an der Client-Software erfordert
+*Das Circuit-Level-Gateway analysiert oder verändert die übertragenen Daten nicht – es kennt das verwendete Anwendungsprotokoll nicht.
-*Genauer gesagt erfordert SOCKS Änderungen entweder an der Client-Software oder am TCP/IP-Stack, um das Abfangen an der Firewall zwischen dem Client und dem Server zu ermöglichen:
+*Dadurch ist die Implementierung einfacher als bei Application-Level-Gateways, die das Protokoll interpretieren können.
-*Ein Client, der modifiziert wurde, um SOCKS-Interaktionen zu handhaben, wird allgemein als ˜ ˜socksifizierter Client bezeichnet.
-*Gemäß dieser Terminologie sind die meisten Webbrowser (z. B. Microsofts Internet Explorer) SOCKS-Clients und geben SOCKS-Aufrufe aus, die für ihre Benutzer transparent sind.
+==Abgrenzung zum Application-Level-Gateway==
-*Sockified TCP/IP-Stacks sind ebenfalls verfügbar, was die Notwendigkeit von Client-Software-Modifikationen überflüssig machen kann.
+*Ein Application-Level-Gateway (ALG) versteht die verwendeten Anwendungsprotokolle (z. B. HTTP, SMTP, FTP) und kann die übertragenen Inhalte prüfen, filtern oder verändern.
-*In beiden Fällen befindet sich der SOCKS-Server an der Firewall und interagiert mit den Socksified-Clients oder TCP/IP-Stacks.
+*Ein Circuit-Level-Gateway hingegen leitet nur die TCP- oder UDP-Verbindung selbst weiter, unabhängig vom darüberliegenden Protokoll.
-*Für die Server, die sich entweder im Internet oder im Intranet befinden können, sind keine weiteren Änderungen erforderlich.
+*Damit bietet es eine gute Balance zwischen Sicherheit und Performance, jedoch ohne inhaltsbasierte Kontrolle.
 =Quelle=
-*https://flylib.com/books/en/4.179.1.22/1/
+*[https://flylib.com/books/en/4.179.1.22/1/ Flylib – Circuit-Level Gateway]

@@ Zeile 8: / Zeile 8: @@
 *Als solches stört es den Datenstrom nicht.
 *Dies unterscheidet ein Circuit-Level-Gateway von einem Application-Level-Gateway.
-*Da dieser das von den beiden Endpunkten der Verbindung verwendete Anwendungsprotokoll verstehen kann.
+*Da der  Application-Level-Gateway das von den beiden Endpunkten der Verbindung verwendete Anwendungsprotokoll verstehen kann.
 *Das bedeutet im Grunde, dass das Circuit-Level-Gateway das verwendete Anwendungsprotokoll nicht verstehen muss.
 *Dies vereinfacht die Implementierung und den Einsatz von Circuit-Level-Gateways erheblich.

@@ Zeile 1: / Zeile 1: @@
-*Als Circuit Level Proxy (auch Generischer Proxy genannt) wird ein Paketfiltermodul bezeichnet, mit dem man auf einer Firewall beliebige IP-Adressen und Ports sperren bzw. freischalten kann, ohne jedoch die Möglichkeit zu haben, die Paketinhalte damit zu analysieren.
+=Gateways auf Leitungsebene=
-*Ein solcher Proxy, der auf den OSI-Schichten 3 und 4 operiert, reicht die Pakete mitunter einfach durch, ohne die Verbindungen selbst zu terminieren.
+*Im Wesentlichen ist ein Circuit-Level-Gateway ein Proxy-Server für TCP
-*Der Circuit Level Proxy realisiert die Adressumsetzung dann mithilfe von NAT auf der OSI-Schicht 3.
+*Genauer gesagt macht ein Circuit-Level-Gateway die folgenden drei Dinge, wenn ein Client eine TCP-Verbindung zu einem Server herstellen möchte
-*Während die Adressfilterung ebenfalls auf der dritten OSI-Schicht angesiedelt ist, realisiert er zudem eine Port-Filterung auf der vierten OSI-Schicht.
+*Es empfängt die TCP-Verbindungsaufbauanforderung, die vom Client gesendet wird (weil der Client so konfiguriert ist, dass er das Circuit-Level-Gateway verwendet).
-*Es gibt auch Circuit Level Proxys, die dank einem speziellen Protokoll eine Authentifizierung auf der OSI-Schicht 5 realisieren können.
+*Es authentifiziert und autorisiert möglicherweise den Client (oder den Benutzer hinter dem Client).
-*Der Client holt sich so eine Verbindungsgenehmigung z. B. per Eingabe einer Kennung nebst Passwort.
+*Er baut im Auftrag des Clients eine zweite TCP - Verbindung zum Server auf .
-*Dieses spezielle Authentifizierungsprotokoll muss der Client allerdings kennen, weshalb ein derart befähigter Circuit Level Proxy weniger generisch ist (er funktioniert nur mit Anwendungen auf dem Client zusammen, die entsprechend erweitert wurden). Als Beispiel für ein solches Authentifizierungsprotokoll sei SOCKS genannt.
+*Nachdem die zweite TCP-Verbindung erfolgreich aufgebaut wurde, leitet das Circuit-Level-Gateway einfach Anwendungsdaten hin und her.
-*Solch ein erweiterter Circuit Level Proxy greift nicht zwangsläufig auf NAT zurück.
+*Als solches stört es den Datenstrom nicht.
-*Einige von ihnen machen dies gar vom Protokoll abhängig; so wird z. B. die TCP-Verbindung terminiert, während eine UDP-Verbindung schlicht weitergereicht wird.
+*Dies unterscheidet ein Circuit-Level-Gateway von einem Application-Level-Gateway.
-*Ein generischer Proxy kann auch für eine einfache Weiterleitung genutzt werden.
+*Da dieser das von den beiden Endpunkten der Verbindung verwendete Anwendungsprotokoll verstehen kann.
-*Der denkbar einfachste Proxy ist das Linux-Programm Redir, das auf einer Schnittstelle und einem Port lauscht und die Daten auf ein anderes Interface und Port weitergibt.
+*Das bedeutet im Grunde, dass das Circuit-Level-Gateway das verwendete Anwendungsprotokoll nicht verstehen muss.
-*Dies ist auch mit dem iptables-Kommando unter Linux möglich und wird beispielsweise verwendet, um den Exit-Datenverkehr eines Tor-Servers über mehrere Proxys zu leiten, um so den Tor-Server zu schützen.
+*Dies vereinfacht die Implementierung und den Einsatz von Circuit-Level-Gateways erheblich.