Es muss vor ungefähr vier Jahren gewesen sein, als ich den ersten Squid Proxy in unserer Firma aufgesetzt hatte. Wir hatten das Ziel insgesamt 15 Standorte über deren lokalen Internet-Breakout surfen zu lassen.
Ich weiß noch als wäre es gestern gewesen, die squid.conf hat mich umgehauen; so viele Einstellungsmöglichkeiten! Ob das gut kommt?
Noch vor Squid hatte ich E2Guardian angeschaut
Eben weil ich mir unsicher war ob Squid Proxy nicht doch zu komplex sei, hatte ich mir auch noch Alternativen angeschaut. An E2Guardian mag ich mich sehr gut erinnern: Ein Proxy der sich selbst als Web-Filtering Server bezeichnet, mit SSL Inspection und ICAP AntiVirus und Blocklist Funktionen direkt im Core einprogrammiert. Aber schon damals fand ich es merkwürdig, dass die Webseite e2guardian.org einen Zeitstempel von 2013 aufwies. Auf Github nämlich gibt es bis heute aktuelle Releases, die neuste Version ist von April 2021.
Über diverse Social Kanäle hatte ich Kontakt zum Entwicklerteam weil in der Testphase doch einige kritische Bugs bis zu Abstürzen auftraten. Diese Fehler konnte ich nie so beheben, dass mir die Software als stabil genug galt für 500-1500 Mitarbeitende täglich darüber surfen zu lassen. Also hatte ich mich doch in die Squid Proxy Konfiguration eingelesen.
15+ Squid Server mit ICAP, SSL Inspection, NTLM/SSO, zentral verwaltet
Ein bisschen konnte ich beim ersten Aufsetzen abgucken, denn mein Vorgänger hatte am Hauptstandort einen Squid schon am Laufen gehabt, nur halt mit den nötigsten Einstellungen ohne viel Schnick-Schnack. Ich hatte durch das Projekt „dezentrale Internet-Breakouts“ damals einige weitere Anforderungen:
- Die User müssen automatisiert Authentifiziert werden aus der Active Directory und dürfen nur mit einer Internet-AD-Gruppe surfen. Dadurch schafft es keine unpersönliche Maschine oder Server ungewollt ins Internet. Ich setzte auf NTLM (nicht Kerberos) mit Basic Auth als Fallback.
- Der Internetzugang muss gefiltert und gescannt werden. Am Ende setzten wir ESETS im ICAP Modus ein um den Traffic zu filtern.
- Für einen Virenfilter im HTTPS Stream musste selbstverständlich SSL Inspection aktiviert werden, also den HTTPS Traffic aufbrechen, scannen und neu verschlüsseln. Das ging anfangs relativ gut, über die Jahre hinweg mussten wir die Whitelist dann doch fast monatlich um eine Domain ergänzen.
- Der Traffic zu Banken bzw. Finanz Webseiten durfte nicht aufgebrochen werden, also musste eine Blacklist/Blocklist beziehungsweise Whitelist her. Sie sollte auch halbwegs aktuell sein.
- Die Verwaltung muss zentral passieren, keiner hat lust 15+ Server von Hand zu pflegen. Hierzu hatte ich von Beginn an auf Ansible gesetzt und das Squid Playbook schnurrte bis zum Schluss wie ein Kätzchen 🙂
- IDS bzw IPS mitlaufen lassen in Form von Suricata
- Welchen Squid nutze ich? http://wpad/wpad.dat musste hochverfügbar erreichbar sein ohne LoadBalancer.
Warum ich überhaupt über Squid Proxy schreibe? Wer nutzt denn heutzutage noch Squid Proxies? Also zur letzten Frage weiß ich, dass Vodafone für MPLS Geschäftskunden auch einen Squid Proxy zur Verfügung stellt. Und ich habe einfach das Bedürfnis Squid Proxy einen ehrenvollen Abgang zu bereiten, hat dieses Programm doch jetzt 4 Jahre fast problemlos seinen Dienst verrichtet.
Noch im Dezember 2021 werden wir den letzten Squid Proxy herunter fahren. Wir haben an jedem Standort eine Aktiv-Passiv Firewall ausgerollt, diese übernimmt mindestens alle Aufgaben von Squid Proxy und bringt selbst noch weitere Security-Features mit.
Squid NTLM Auth in der Praxis
Die Erkennung des Mitarbeiters durch eine AD-Gruppe funktionierte mit NTLM auf dem Squid Proxy problemlos. Es gab vereinzelt Fälle wie das Apple iTunes, das kein NTLM machen wollte. In solche Fällen schaltete sich der Fallback auf Basic Auth ein und das Problem war behoben.
Wir hatten erstaunlich wenig Probleme mit der Authentifizierung. Vielleicht auch, weil der Login mindestens 2h gecachet wurde. In den vergangen 4 Jahren kann ich mich nur an einen einzigen Ausfall der Authentifizierung erinnern.
Squid ICAP Virenfilter in der Praxis
Die gängisten Anleitungen zu einem Virenscanner am Squid Proxy werden dich zu ClamAV mit ClamAV ICAP führen. ClamAV und das Addon für ICAP scanning ist völlig okay, die Erkennungsrate aktuellster Pattern aber nach wie vor nicht Business tauglich weil kaum etwas erkannt wird.
Wir hatten uns für ESETS entschieden, nachdem ich mir u.a. auch Kaskperky und F-Secure angeschaut hatte. Mein Wunsch war ja, den Scanner direkt auf dem Linux Squid Proxy Server mitlaufen zu lassen, das alleine schon schränkte die Auswahl extrem ein. Die meisten grossen Anti Viren Hersteller bieten eine Appliance mit ICAP Scanning an. Das kam aber nicht in Frage, denn dann hätte ich an jedem Standort einzeln so einen Appliance installieren müssen. Der Verwaltungsaufwand wäre viel zu groß geworden.
ESETS verrichtete seinen Dienst im ICAP Modus ohne murren. Problematisch fand ich dagegen die schlechte Erkennungsrate der Makroviren, die ja schon in 2019 bzw. 2020 gewütet haben. Diese Signatur basierten Patterns die der ESETS ICAP Scanner unterstützt konnten fast nie bösartige Makros abfangen. Erkannt wurden solche VBA-Scripte erst 4-8 Stunden nach der Spam-Welle. Einfach zu spät. Wir hatten aber relativ zügig unser MS Office gehärtet damit nur noch durch uns signierte VBA-Scripte gestartet werden dürfen.
Die Lizenz bei ESETS bezahlt man natürlich auch auf Basis zu schützenden User. Kostet im Falle von ESETS nicht die Welt, schützt aber eben auch nicht die Welt. Es gibt bei ESETS für Linux Installationen im ICAP Modus kein Reputation Service für URLs, kein Reputation Service für Files und schon gar keine Sandboxfunktionen.
SSL Inspection (Deep Packet Inspection) mit Squid Proxy
Das Aufbrechen von HTTPS Verbindungen fand ich eines der spannendsten Themen. Unter Open Source Leuten wird es ja oft gar verpönt, den SSL Stream aufzumachen. Ich kann es aus ideologischer Sicht schon verstehen. Im Geschäftlichen Umfeld entfallen aber super viele Sicherheitsvorkehrungen auf der Ebene Proxy bzw. Firewall/Internet-Stream, wenn nicht aufgebrochen wird.
Google wollte ja das Aufbrechen mit ihrem Chrome Browser extrem erschweren, ich meine das war um das Jahr 2017 herum. Plötzlich gab es dort wohl eine Kehrtwende und alle Sicherheitsfunktionen die das Aufbrechen erschweren sollten wurden aus Chrome entfernt. „Feuer Frei, brich es auf!“ sozusagen. Certificate Pinning hat sich auch kaum durchgesetzt, bis auf Apps wie z.B. Zoom lässt sich auch 2021/2022 fast alles aufbrechen. Wie man mit QUIC umgeht, also HTTPS via UDP und längst im Einsatz bei allen Google Webseiten, wird sich zeigen.
Leider hatte unser Squid dann doch in den letzten 2 Jahren öfters Probleme mit dem Aufbrechen. Zum Beispiel rief mich das Sekretariat an, man könne keine Flüge buchen bei EasyJet.com. Das Auswahlmenü wurde nicht korrekt angezeigt, die Felder ließen sich teilweise nicht befüllen. Herausgestellt hatte sich, dass das Aufbrechen eines gewissen CDN manche Javascripts nicht nachladen ließ. Nervig, denn jetzt mit der FortiGate Firewall hat man bei eben diesen Webseiten auch mit Aufbruch keinerlei Probleme.
Die mir unerklärlichen SSL Inspection Probleme hatte ich auch an die Squid Mailing List geschickt, zwei mal sogar. Wirklich geholfen wurde mir nie, wenngleich innerhalb dieser Squid Mailing List sehr aktiv supported wird.
Squid Proxy und URL Blocklist / Whitelist
Der Squid Proxy selbst kann durch eine eigene Datei mit URLs im normalen oder Regex Format den Zugriff sperren bzw. freigeben. Aber wenn diese Blocklist/Whitelist zu groß wird, sollte man auf UFDBGuard ausweichen. UFDBGuard ist ein Modul das sich in den Squid einklinkt und die Blocklist/Whitelist aller URLs im binären Format vorhält.
In das UFDBGuard hatte ich die einzige brauchbare Blacklist geladen: Die URL Blacklist der Universität Toulouse aus Frankreich. Sie wird noch aktiv befüllt, man kann selbst weitere URLs für vorgegebene Kategorien vorschlagen und hat wenige False Postive. Die Alternative Shallalist könnt ihr meiner Meinung nach vergessen. Shallalist hat war rieseige Mengen an Domains, es fehlen aber grundsätzlich alle neuen URLs die man geblockt haben möchte. Meiner Meinung nach wird Shallalist nicht mehr vom Macher unterstützt. Das erklärt auch, wieso die Website von Shallalist optisch im Jahre 2000 stehen geblieben ist :-O
Wie schon eingangs erwähnt, habe ich die Kategorie Finance/Banking als Whitelist verwendet, um gegen diese Domains keine SSL Inspection durchzuführen. Das funktionierte problemlos.
Ansible zur Verwaltung von Squid Proxy
Also wenn es eine GUI gibt um viele Squid-Instanzen zentral zu verwalten, dann kenne ich diese GUI bis heute nicht. Mein Ansible hat es auch getan, problemlos sogar. Mein Playbook „proxy“ dürfte mitunter das am meisten aufgeführte Playbook überhaupt sein hier auf Arbeit. Die meisten Änderungen waren URLs auf die SSL Inspection Whitelist zu setzen.
Meiner Meinung nach hat Squid (4) das größte Problem, dass UDP nicht unterstützt wird. Azubis, die von der Arbeit auf eine Videokonferenzlösung zugreifen wollen die nur Schulen nutzen, da will der Browser eine UDP Verbindung herstellen für Audio bzw. Video. Hier hat der Squid Proxy mit SSL Inspection die meisten Zickereien gemacht. Die Lösung war immer dieselbe: Betroffene URLs auf die Whitelist setzen, SSL nicht aufbrechen, ansible-playbook proxy.yml ausführen. Durch den nicht aufgebrochenen TCP Stream hat es dann doch geklappt. Gegen Ende fand ich das nervig und war froh, schreitete der Rollout unserer Firewall für jeden Standort zügig voran.
IDS Suricata mit Squid Proxy
Zu guter Letzt hatte ich unsere Squid Proxies an Suricata gehängt, Suricata wiederum per Filebeat an eine Elasticsearch/ELK Stack Instanz schreiben lassen. Also eigentlich habe ich einen reinen Squid Internetzugang versucht zu einer Firewall mit IDS/IPS aufrüsten. Naja, es klappte weniger gut. Ich hatte Suricata am Ende über alle Standorte als IDS ohne IPS am laufen, was ja schonmal wenig bringt. Die erkannten Alerts von Suricata waren allesamt nicht spannend. Am spannendsten fand ich noch die Erkennung, wenn sich ein Mitarbeiter im Internet ohne HTTPS irgendwo angemeldet hat. Wobei mir schon klar ist, viel kann man ja nicht erwarten, denn hier geht es um ausgehende Verbindungen vom LAN ins WAN, nicht etwa Scans auf eingehende Attacken.
WPAD.dat als HA bereitstellen ohne LoadBalancer
Eine weitere Anforderung bestand darin, die wpad.dat von 2 verschiedenen Quellen auszuliefern je Standort, also Hochverfügbar (HA). Primary ist die http://wpad/wpad.dat am Hauptstandort, secondary hingegen ist eine http://proxyamstandort.domain.intra/wpad.dat außerhalb des Headquarters.
Nach etwas testen und herum probieren (und manch krass veraltete Homepage zum Thema WPAD durchlesen) hat das geklappt. Die GPO für das erste Häkchen [x] Proxy automatisch erkennen setzt man wie gewohnt in den Interneteinstellungen. Dieses Häkchen sucht ab sofort die WPAD unter anderem unter eben http://wpad/wpad.dat. Das zweite Feld [x] Skript für automatische Konfiguration verwenden ist ein Registry Key, den man auch per GPO setzen kann. Diesen Registry Key haben wir für jeden Standort direkt auf den Squid Proxy vor Ort zeigen lassen, auf dem Squid Proxy Linux Server lief noch ein Apache mit einer Kopie der wpad.dat mit.
Innerhalb der WPAD selbst konnte ich mehrere Proxies hintereinander im Failover Verbund angeben. Fällt ein Proxy aus, springt Chrome oder Edge innerhalb 30 Sekunden auf den nächsten Proxy – und wieder zurück, wenn der erste Proxy wieder online gekommen ist. Dadurch surft der Mitarbeiter mit einer IP von einer Aussenlokation direkt über den Squid Proxy seines Standortes. Fällt dieser aus, springt sein Browser auf den nächsten Proxy. Dieser 2te oder 3te Proxy war in aller Regel am Hauptstandort, erreichbar mittels MPLS (inzwischen schwenken wir um auf SD-WAN).
Nur der IE11 bekam das nicht geschissen, aber den haben wir schon vor 4 Jahren so gut wie möglich deaktiviert.
Wenn ich einmal eine Änderung an der wpad.dat machen musste, konnte ich mit einem Schuss per Ansible die wpad.dat konzernweit ausrollen. Easy.
Die WPAD.dat sah in unserem Fall in etwa so aus:
// Last update 2021101
function FindProxyForURL(url, host) {
// URLs ohne Domainsuffix
if (isPlainHostName(host))
return "DIRECT";
// lokale Domains
else if (dnsDomainIs(host, "domain.intra") ||
dnsDomainIs(host, "domain2.intra"))
return "DIRECT";
// lokale Subnetze
else if (isInNet(host, "10.22.0.0,"255.255.0.0") ||
isInNet(host, "10.33.0.0","255.255.0.0") ||
isInNet(host, "10.44.0.0","255.255.0.0") ||
isInNet(host, "127.0.0.1","255.255.255.255"))
return "DIRECT";
// Standort XX
if (isInNet(myIpAddress(), "10.45.33.0", "255.255.255.0"))
return "PROXY proxy01xx.domain.intra:8080; PROXY proxy02xx.domain.intra:8080; PROXY proxy03xx.domain.intra:8080";
// Standort YY
if (isInNet(myIpAddress(), "10.45.34.0", "255.255.255.0"))
return "PROXY proxy01yy.domain.intra:8080; PROXY proxy02yy.domain.intra:8080; PROXY proxy03yy.domain.intra:8080";
// Standort ZZ
// Bereits auf transparente Firewall umgezogen, DIRECT
if (isInNet(myIpAddress(), "10.45.35.0", "255.255.255.0"))
// return "PROXY proxy01zz.domain.intra:8080; PROXY proxy02zz.domain.intra:8080; PROXY proxy03zz.domain.intra:8080";
return "DIRECT";
// Alternativ wenn nix matched gehe DIRECT
else
// return "PROXY proxy01xx.domain.intr:8080; PROXY proxy02xx.domain.intr:8080; PROXY proxy03xx.domain.intr:8080";
return "DIRECT";
}
Würde ich nochmal Squid wählen?
Ganz klar: Ja! Squid gibt es inzwischen in Version 5, die recht viele Anpassungen mitbringt um zeitgemäß den Internet Traffic zu lenken.
Müsste ich nochmal Squid einsetzen würde ich aber den Entwicklern bzw. der Community auf die Pelle rücken um das Problem zu lösen, wieso Squid sehr oft mit SSL Inspection Probleme hat während auf denselben Webseiten andere Enterprise Firewalls keine Probleme haben. Ob Squid 5 inzwischen auch UDP unterstützt? Ich glaube nicht.
Ich jedenfalls bin froh mich von Squid in Freude und Anerkennung verabschieden zu können. Danke, Squid Proxy, ich wünsche dir eine gute Zukunft mit vielen weiteren aktuellen und stabilen Releases.
Goodbye, Squid Proxy!
0 Kommentare