debian squid proxy vor Gateway

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Benutzeravatar
joe2017
Beiträge: 1182
Registriert: 07.08.2017 14:29:51

debian squid proxy vor Gateway

Beitrag von joe2017 » 05.06.2024 08:14:36

Hallo zusammen,

ich überlege gerade ob ich mir für das Unternehmen einen Squid Proxy einrichten soll.
Jetzt frage ich mich, ob ich anschließend jeden einzelnen Client konfigurieren muss, damit diese meinen Proxy verwenden, oder ob ich einfach nur meinen debian Gateway Server konfigurieren kann, durch welchen meine Clients sowieso ins Internet geroutet werden.

Ist das möglich, ohne jeden Client anpassen zu müssen?

uname
Beiträge: 12163
Registriert: 03.06.2008 09:33:02

Re: debian squid proxy vor Gateway

Beitrag von uname » 05.06.2024 12:14:14

Was sind die Gründe, warum du einen Proxy wie Squid verwenden willst? Das Caching ist in 2024 nicht mehr relevant bzw. sinnvoll. Für die Sicherheit auch nicht, da du bestimmt TLS nicht aufbrichst und somit sowieso nur effektiv am Client nach Viren scnanen kannst. Du kannst Squid als transparenten Proxy einrichten. Dann musst du nicht jeden Client konfigurieren.

Benutzeravatar
MSfree
Beiträge: 10980
Registriert: 25.09.2007 19:59:30

Re: debian squid proxy vor Gateway

Beitrag von MSfree » 05.06.2024 12:41:19

joe2017 hat geschrieben: ↑ zum Beitrag ↑
05.06.2024 08:14:36
ich überlege gerade ob ich mir für das Unternehmen einen Squid Proxy einrichten soll.
uname hat geschrieben: ↑ zum Beitrag ↑
05.06.2024 12:14:14
Das Caching ist in 2024 nicht mehr relevant bzw. sinnvoll.
Relevant und sinnvoll wäre es durchaus, aber seit alle Webseiten (mit homöopathischen Ausnahmen) verschlüsselt sind, kann man nichts mehr cachen. Das ist aber schon deutlich länger als seit 2024 der Fall.
Jetzt frage ich mich, ob ich anschließend jeden einzelnen Client konfigurieren muss
Nein, muß man nicht. In der Standardeinstellung verwenden Browser WebProxyAutomaticDiscovery (WPAD). Man muß im Nameserver einen CNAME eintragen, der auf einen Webserver (im LAN) verweist, der die Datei wpad.dat ausliefern können muß. Das ist ein in den meisten Fällen simples Stück Javascript, das dem Browser die Proxyadresse übermittelt.

Ein Proxy ist zur Zeit noch als Ersatz für PiHole nutzbar, indem man dort die ganzen unerwünschten Domains per ACL sperrt. Konterkariert wird das aber durch DoH (DNS over HTTPS).

uname
Beiträge: 12163
Registriert: 03.06.2008 09:33:02

Re: debian squid proxy vor Gateway

Beitrag von uname » 05.06.2024 14:14:30

MSfree hat geschrieben:Relevant und sinnvoll wäre es durchaus, aber seit alle Webseiten (mit homöopathischen Ausnahmen) verschlüsselt sind, kann man nichts mehr cachen. Das ist aber schon deutlich länger als seit 2024 der Fall.
Ob die Einsparung wirklich groß wäre? Die tatsächlich großen Datenmengen entstehen eher durch nur von einer Person aufgerufene Daten wie z. B. Audio- und Video-Dateien oder Zugriffe auf Daten in Clouds. Um Daten einzusparen ist es wohl eher sinnvoll, wenn die Browser-Caches bei jedem Anwender korrekt konfiguriert sind, um hier ein lokales Caching zu ermöglichen. Zudem kann man besser mehr Geld für die Internetleitung ausgeben und sich den Ärger mit einen Proxy sparen. Bei Einsparung von vielleicht 25%: Was kostet eine Leitung, die 25% mehr Durchsatz hat tatsächlich mehr?
MSfree hat geschrieben:Ein Proxy ist zur Zeit noch als Ersatz für PiHole nutzbar, indem man dort die ganzen unerwünschten Domains per ACL sperrt. Konterkariert wird das aber durch DoH (DNS over HTTPS).
Dazu gibt es doch z. B. Google Safebrowsing. Wer das schlimm findet sollte wissen, dass für jeden HTTP-Request bei Google und anderen Hostern auch eine digitale Spur hinterlegt wird.
MSfree hat geschrieben:Nein, muß man nicht. In der Standardeinstellung verwenden Browser WebProxyAutomaticDiscovery (WPAD) ...
Das ist doch die automatische Proxy-Konfiguration. Kann bei einem transparenten Squid-Proxy nicht selbst die weggelassen werden? Wird dabei nicht Port 80/443 Richtung Internet einfach durch den Proxy geleitet?

Benutzeravatar
MSfree
Beiträge: 10980
Registriert: 25.09.2007 19:59:30

Re: debian squid proxy vor Gateway

Beitrag von MSfree » 05.06.2024 14:55:05

uname hat geschrieben: ↑ zum Beitrag ↑
05.06.2024 14:14:30
Ob die Einsparung wirklich groß wäre?
Früher ja. Zu Zeiten, als ich noch mit 1.5MBit/s unterwegs war, hat squid ziemlich effektiv gecacht. Dann aber haben die Seitenbetrieber angefangen, HTML-Code einzubauen, um das Caching zu unterbinden, z.B.

Code: Alles auswählen

<meta http-equiv="Cache-control" content="no-cache">
Einerseits, um wechselnde Werbung einblenden zu können, andererseits, um zu gewährleisten, daß bei einem Reload auch wirklich die neuste Seitenversion kommt, z.B. bei Newstickern. Letztlich hatte fast jede Webseite so etwas im Header und squid war ausgebootet.
z. B. Audio- und Video-Dateien
Streams zu cachen, war noch nie sinnvoll.
Um Daten einzusparen ist es wohl eher sinnvoll, wenn die Browser-Caches bei jedem Anwender korrekt konfiguriert sind, um hier ein lokales Caching zu ermöglichen.
Der Nachteil hier ist, daß der lokale Cache halt auch einiges an Analysen zuläßt. Ich habe früher den lokalen Cache auf Null gestellt und das Caching squid überlassen. Man darf auch nicht vergessen, daß die Festplatten früher kleiner waren und man froh war, wenn nicht so viel temporärer Kram auf der Platte lag.
Zudem kann man besser mehr Geld für die Internetleitung ausgeben und sich den Ärger mit einen Proxy sparen.
So viel Ärger macht ein Proxy nun nicht und er kostet weniger als eine fettere Leitung.
Dazu gibt es doch z. B. Google Safebrowsing. Wer das schlimm findet sollte wissen, dass für jeden HTTP-Request bei Google und anderen Hostern auch eine digitale Spur hinterlegt wird.
Mir ging es bei PiHole weniger um privates oder Safe Browsing sondern darum, die Werbeflut einzudämmen. Die nagelt einem ja nicht nur die Leitung zu, sie verunstaltet auch ganze Webseiten mit teilweise ganzseitigen Überblendungen etc. Was nicht geladen wird, weil vom Proxy blockiert, erscheint gar nicht erst im Browser.
Kann bei einem transparenten Squid-Proxy nicht selbst die weggelassen werden? Wird dabei nicht Port 80/443 Richtung Internet einfach durch den Proxy geleitet?
Tranparent Proxy funktioniert mit HTTPS nicht. HTTPS geht grundsätzlich nur über einen dedizierten Proxy, auch wenn der über WPAD konfiguriert wird. Der Proxy kann ja nicht im verchlüsselten Datenstrom lesen. Squid fungiert dabei aber nur als Portforwarder für den Port 443 und bricht (normalerweise) keine Verschlüssleung auf. Man kann alledings squid so konfigurieren, daß der die Verschlüsselung aufbricht und dann alle ACLs zugänglich macht, die auch mit HTTP schon gingen. Ich empfehle das hier aber ausdrücklich nicht, es unterminiert die Privatsphäre und könnte die Sicherheit des Proxys gefährden, in dem dort Schadcode eingeschleust wird.

Ich habe auf meine Linuxrouter nach wie vor einen squid laufen mit einer Konfiguration, die über Jahrzehnte gereift ist. Ich nutze unter anderem auch SSH, um den Proxyport zu tunneln, so daß ich unterwegs mittels getunneltem Proxy auf meinen Webserver zuhause zugreifen kann und von deutlich weniger Werbung belästigt werde.

Wenn ich heute aber nochmal anfangen müßte, würde ich den Proxy weglassen und Werbung ggfls. mittels PiHole verwerfen. Den Server zuhause könnte man auch über ein VPN ansprechen, so daß der getunnelte Proxy überflüssig wäre.

Benutzeravatar
joe2017
Beiträge: 1182
Registriert: 07.08.2017 14:29:51

Re: debian squid proxy vor Gateway

Beitrag von joe2017 » 06.06.2024 08:26:55

Guten Morgen zusammen,

mir geht es in erster Linie um Firewall freigaben auf Cloud Domains. VIelleicht ist der Proxy auch der falsche weg.
Früher konnte ich meistens einen Port (Bsp. 443) auf eine Public IP freigeben. Leider geht das heute nicht mehr wirklich, da die Cloudserver eine ganze Kaskade von IP Adressen nutzen.
Somit muss ich einen FQDN freigeben. Das kann ich wiederrum mit der debian firewall (nftable) nicht.

uname
Beiträge: 12163
Registriert: 03.06.2008 09:33:02

Re: debian squid proxy vor Gateway

Beitrag von uname » 06.06.2024 08:54:58

joe2017 hat geschrieben:mir geht es in erster Linie um Firewall freigaben auf Cloud Domains.
Ich denke die Zeit das Internet in Kategorien einzuteilen sind vorbei. Schau dir aber gerne Debiansquidguard (Wikipedia) als Erweiterung von Debiansquid an. Oder willst du sagen, dass der Rest des Internet gesperrt ist?

Ich weiß gar nicht wie viele Hunderttausend Nextcloud-Instanzen (Wikipedia) es alleine mittlerweile gibt. Jeder hat hierbei seinen eigenen Namen. Gibt es nicht nur kostenlos, sondern ist auch schnell auf einem Webserver, V-Server, root-Server usw. installiert.

Es ist einfach absurd irgendeine Liste zu pflegen, die Clouds verbietet oder erlaubt. Zudem unterscheiden sich Clouds wie MagentaCLOUD nicht wirklich von Webspace siehe meine XmasCLOUD. Was verstehst du unter Cloud?

Kannst du mal ein Beispiel für eine Cloud nennen? Es kann sein, dass gewisse Zusatzdienste wie Videokonferenzen gar nicht über den Proxy übertragen werden können. Da bleibt dir dann nur ein Paketfilter. Hier mal eine Liste von Microsoft 365.
Zuletzt geändert von uname am 06.06.2024 09:03:49, insgesamt 1-mal geändert.

Benutzeravatar
MSfree
Beiträge: 10980
Registriert: 25.09.2007 19:59:30

Re: debian squid proxy vor Gateway

Beitrag von MSfree » 06.06.2024 09:03:28

joe2017 hat geschrieben: ↑ zum Beitrag ↑
06.06.2024 08:26:55
Früher konnte ich meistens einen Port (Bsp. 443) auf eine Public IP freigeben. Leider geht das heute nicht mehr wirklich, da die Cloudserver eine ganze Kaskade von IP Adressen nutzen.
Whitelisting wird dich hier nicht weiterbringen, weil praktisch alles über Port 443 geht. Du müßtest fast das komplette Internet auf deine Whitelist packen, das dürfte ein wenig zu viel Plattenplatz benötigen. :mrgreen:

Benutzeravatar
joe2017
Beiträge: 1182
Registriert: 07.08.2017 14:29:51

Re: debian squid proxy vor Gateway

Beitrag von joe2017 » 06.06.2024 16:13:45

MIr geht es ehr darum, dass ein bestimmter PC nur ganz spezielle Webseiten öffnen darf.
Also ein whitelisting wäre hier schon das richtige.

uname
Beiträge: 12163
Registriert: 03.06.2008 09:33:02

Re: debian squid proxy vor Gateway

Beitrag von uname » 06.06.2024 16:15:52

Ich denke da würde ich einfach entweder auf dem PC oder auf dem Gateway normale Filterregeln verwenden.

wanne
Moderator
Beiträge: 7504
Registriert: 24.05.2010 12:39:42

Re: debian squid proxy vor Gateway

Beitrag von wanne » 11.06.2024 14:19:13

Also ein whitelisting wäre hier schon das richtige.
Dann ist die proxy Lösung eigentlich genau das richtige.
MIr geht es ehr darum, dass ein bestimmter PC nur ganz spezielle Webseiten öffnen darf.
Beachte dass moderne Websiten meist Ressourcen von mehreren Dutzend anderen oft wechselnden Websiten nachladen. Wenn du ein Script hast ist das meist harmlos. Wenn du da ein Mensch hast: Fast alle Websiten nutzen heute für die Suche und Schriften Google, für Kommentare Facebook oder Discourse für Bilder eigene Subdomains und für Videos Youtube. Wenn du die blockst tut nur noch wenig. Machst du sie auf ist insbesondere mit Google fast alles offen. In einigen Fällen kannst du da mit einer sehr sorgfältig und aktiv moderierten Liste was machen. Aber das Web ist nun mal ein Netz das darauf ausgelegt ist, Wissen zu vernetzen und so ist es ähnlich einfach da was raus zu brechen, wie aus einem Spinnennetz. Wenn die Webseiten da nicht mitspielen und sich explizit auf eine feste Liste von Ressourcen einschränken wird die Nutzererfahrung praktisch immer grauenhaft.
Jetzt frage ich mich, ob ich anschließend jeden einzelnen Client konfigurieren muss, damit diese meinen Proxy verwenden, oder ob ich einfach nur meinen debian Gateway Server konfigurieren kann, durch welchen meine Clients sowieso ins Internet geroutet werden.
http ohne TLS ist mittlerweile ziemlich irrelevant. Transparente Proxys und TLS sind kompliziert. Aber es gibt diverse Methoden proxys per dhcp/WPAD/PAC oder ähnliches automatisch konfigurieren zu lassen. Da einige Provider das noch immer verlangen funktioniert das relativ zuverlässig.
Wenn du wirklich transparent sein soll, kannst du mit haproxy was bauen. mit nft alles auf nen haproxy redirecten und mit acl [BACKEND] req_ssl_sni -i [DOMAIN] und einem tcp-Backend für jede domain.
Das nächste, was du beachten musst ist DNS. Das musst du irgend wie funktionieren lassen dass es gewünschte domains auflöst, andere aber nicht, da sonst etwas versierte Nutzer oder Malware halt da durch tunneln.
Immer ist das ein etwas komplexeres setup mit mehr als einem Server.

Zuletzt möchte ich noch auf "tls interception", "ssl_bumping", "termination" aufmerksam machen. Wenn du in die Richtung googelst, wirst du fast nur solche Ergebnisse finden. Wenn du in erster Linie Nutzer einschränken willst, kannst du dann deutlich freier – also auf ganze URLs statt nur auf domains filtern. Hat den Vorteil, dass dann auch caching und ausführliches überwachen funktioniert. Sind aber halt alles ein Euphemismus für einen MitM-Angriffe – Die Browser merken das und warnen. Man kann natürlich den Nutzern erklären, wie sie die weg klicken sollen. Dann hast du aber halt der Sicherheit auch einen Kopfschuss verpasst, weil andere dann halt auch mitlesen und vor allem Malware einschleusen können.
Ich denke da würde ich einfach entweder auf dem PC oder auf dem Gateway normale Filterregeln verwenden.
Was halt darauf raus läuft, dass du ein paar seit 25 Jahren nicht mehr verwendete Protokolle "filterst" (also du filterst eigentlich nichts, weil wird ja seit Jahrzehnten nicht mehr verwendet) und sonst alles unangepasst bleibt, weil https ist ja erlaubt und jede Anwendung nutzt das heutzutage.
rot: Moderator wanne spricht, default: User wanne spricht.

Antworten