Techn. Frage zum Transparenter Proxy

[MopedHans]

Hallo,

ich möchte für ein Netzwerk den URL Zugriff reglementieren (aber kein AV nutzen!). Dazu wäre wohl der Webfilter die geeignete (einzige?) Wahl, was dann auch die Verwendung des Proxys voraussetzt (oder habe ich das total falsch verstanden, dann wäre hier schon Schluss )

Variante a) wäre die explizite Angabe des Proxys auf den Systemen im Netzwerk. Das bringt aber einiges an Aufwand mit sich. Variante b) wäre die Nutzung des transparenten Proxys, was ich im Prinzip als deutlich sinnvoller und eleganter ansehe.

Einen Haken hat Variante b) dann aber doch. Die Pflicht zur SSL-Interception bei HTTPs Traffic. 

Nur verstehe ich nicht ganz, warum ohne Nutzung des AVs SSL-Interception überhaupt notwendig ist. Ist das techn. einfach nicht anders möglich oder einfach nur so von euch implementiert.

Danke
MH

[Bjoern]

Hallo,

Sie sollten den transparenten Proxy mit SSL-Interception auf "Webfilterbasis" verwenden. Dadurch werden Pakete nur noch aufgebrochen wenn diese geblockt werden sollen.

[MopedHans]

Nachdem ich nun eine Weile mit dem Transparenten Proxy experimentiert habe und sicherstellen möchte, dass ich das ganze Prinzip auch korrekt verstanden habe, wäre ich dankbar, wenn mir folgende Aussagen bestätigt/korrogiert werden könnten. Leider finde ich zu dem Thema auch kein Ablaufdiagramm.

Ein aktivierter transparenter Proxy gilt grundsätzlich für alle nicht externen Schnittstellen (Zugriff nur aus internen Quellen erlauben: Ja). Damit HTTP(s) aber überhaupt funktioniert, muss man entsprechend über include/exclude Regeln definieren, ob der transparente Proxy den HTTP(s) Traffic "abfängt" oder nicht.

Hat man eine include Regel, geht der entsprechende HTTP(s) Traffic über den Proxy. Will man den Proxy nicht für HTTP(s) nutzen, braucht man eine exclude Regel UND eine entsprechende Firewall Regel. Daraus folgt, hat man bei aktiven transparentem Proxy weder include noch exclude (inkl. Firewall) Regeln definiert, geht einfach kein HTTP(s).

Der aktivierter transparenter Proxy samt include Regel benötigt keine Firewall Regeln um ihn für HTTP(s) nutzen zu können. Weder für Clients (den Proxy als Dienstobjekt "Proxy" am internen Interface erreichbar machen), noch für ausgehenden HTTP(s) Datenverkehr (Hide-Nat am externen Interface).

Der aktivierte transparente Proxy prüft nicht das HTTP(s) Protokoll, sondern ob es sich bei HTTP um TCP/80 handelt und bei HTTPS um TCP/443.

[Bjoern]

Hallo,

der Proxy lauscht auf alle Schnittstellen wie alle Dienste der Firewall. Erst durch die include Regel wird dem transparenten Modus mitgeteilt von wo nach wo. Dadurch kann auch aus dem Internet theoretisch die Firewall mit dem transparenten Modus angesprochen werden.
Der Regler (Zugriff nur aus internen Quellen erlauben: Ja) erlaubt Zugriff auf alle lokalen Netze über den Proxy ohne Portfilterregel. Sie müssen also kein http/https per Regel in die anderen Netze freigeben.

Hat man eine include Regel, geht der entsprechende HTTP(s) Traffic über den Proxy. Will man den Proxy nicht für HTTP(s) nutzen, braucht man eine exclude Regel UND eine entsprechende Firewall Regel. Daraus folgt, hat man bei aktiven transparentem Proxy weder include noch exclude (inkl. Firewall) Regeln definiert, geht einfach kein HTTP(s).
Korrekt. Kein include wird auch der transparente Modus nicht verwendet und muss dann alles per Regelwerk geklärt werden.

Der aktivierter transparenter Proxy samt include Regel benötigt keine Firewall Regeln um ihn für HTTP(s) nutzen zu können. Weder für Clients (den Proxy als Dienstobjekt "Proxy" am internen Interface erreichbar machen), noch für ausgehenden HTTP(s) Datenverkehr (Hide-Nat am externen Interface).
Das ist aktuell korrekt.

Der aktivierte transparente Proxy prüft nicht das HTTP(s) Protokoll, sondern ob es sich bei HTTP um TCP/80 handelt und bei HTTPS um TCP/443.
Doch des wird geprüft. Es kann nicht einfach TCP Port 443 oder TCP Port 80 verwendet werden es sei denn Sie erlauben es mit "Nicht erkannte Protokolle erlauben".