Im Zuge meiner Ausbildung bei NETWAYS durfte ich mich diese Woche mit Squid auseinandersetzen. Dabei merkte ich, dass man sich bezüglich LDAP & SSL-BUMP wirklich nur auf die offiziellen Squid Dokus und die Red Hat Dokus verlassen konnte.

Squid ist ein Caching Proxy für Web Seiten das HTTP, HTTPS, FTP und vieles mehr unterstützt. Es reduziert Bandbreite und verbessert Aufrufzeiten. Dabei kann es den effektiven Netzwerkdurchsatz verbessern.

  • Es ermöglicht Caching und Verteilung.
  • Es erlaubt Content Filtering.
  • Es unterstützt LDAP-Anbindung für die Authentifizierung.
  • Es kann als transparent / MITM Proxy genutzt werden.

 

 

Ubuntu 20.04.01 Server: Die für SSL Bump benötigten Kompilerflags lauten --enable-ssl-crtd & --with-openssl. Aktuell ist Squid in Version 4 mit diesen Flags in den Ubuntu-Server-Repos nicht vorkompiliert, sodass man man sich Squid praktisch selbst damit bauen muss. Ob die Flags aktiv sind kann man folgendermaßen checken:

$ squid -v | grep ssl

CentOS 8: Unter CentOS kommt Squid direkt mit SSL-Bump vorkompiliert.

  • Der folgende Artikel basiert auf Squid Version 4.4 unter CentOS 8.

 

Vorab-Konfiguration

  • Firewallregeln sollten Squid entsprechend angepasst werden.
$ sudo firewall-cmd --permanent --add-port=3128/tcp
$ sudo firewall-cmd --reload
  • Falls jemand sich wie ich noch nicht so sehr mit SELinux auskennt, empfiehlt es sich die SELinux Policies erstmal auf Permissive zu stellen. Dies geschieht in der /etc/selinux/config. Später nach erfolgreicher Installation sollte man sie wieder zurück auf Enforcing setzen.
SELINUX=permissive

LDAP

  • Das Root Zertifikat der Umgebung muss heruntergeladen, in den Zertifikatsordner des Squid Servers geschoben und aktualisiert werden damit LDAP signiert via TLS funktioniert.
$ sudo cp ROOT_ZERTIFIKAT.cer /etc/pki/ca-trust/
$ sudo update-ca-trust

Die auth_param Parameter sollten schon in der Konfigurationsdatei /etc/squid/squid.conf stehen und entsprechend aktiviert und vervollständigt werden.

  • Wichtig ist es exakt passend Base/Domain/Suchfilter und Server zu übergeben. Hilfreich hierzu sind die Man Page von basic_ldap_auth sowie ldapsearch.
  • Folgendes Beispiel basiert auf einer Microsoft Active-Directory Umgebung was an dem -f Suchparameter erkannt werden kann. Zwingend wichtig ist es hier das %s für den User mitzugeben.
Das –R Flag muss manchmal gesetzt werden um Referrals nicht zu folgen, da ansonsten mehrere Aufrufe stattfinden und Konflikte auslösen womit Squid LDAP verweigern wird.

 

auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "dc=FIRST_DOMAIN,dc=SECOND_DOMAIN,dc=ROOT_DOMAIN"
-D "CN=LDAP/USERNAME,OU=SERVICEGROUP,OU=COMPANY,OU=NET,OU=COMPANY,DC=FIRST_DOMAIN,DC=SECOND_DOMAIN,DC=TOP_DOMAIN"
-w "password" -f "(&(objectCategory=Person)(samAccountName=%s))" -R -H ldaps://FIRST_DOMAIN.SECOND_DOMAIN.TOP_DOMAIN:636
auth_param basic children 5
auth_param basic realm Hi this is your Squid Proxy speaking
auth_param basic credentialsttl 5 minutes
#Falls die LDAP Authentifizierung nicht durching,HTTP Traffic sperren.
acl ldap-auth proxy_auth REQUIRED
http_access deny !ldap-auth

 

  • Jetzt braucht Squid noch einen Neustart
$ sudo systemctl restart squid
  • Innerhalb weniger Sekunden sollte die LDAP/AD Passwortabfrage kommen.

 

SSL-Bump

Das Entschlüsseln und Mitschneiden von HTTPS Verbindungen muss von Nutzern erst erlaubt werden und es sollte immer eine schriftliche Genehmigung vorliegen! Es ist ansonsten rechtlich absolut illegal und strafbar!

Es wird keine Haftung übernommen. Folgender Teil dient allein der Sensibilisierung, Aufklärung und Weiterbildung.

 

TLS Entschlüsselung kann zum Guten oder Bösen verwendet werden:

  • Zum Guten: Verschlüsselt Malware seine Kommunikation zum Command & Control Server, ist es ohne Entschlüsselung schwer diese aufzuspüren, sodass SSL-Man-in-the-Middle in sicherheitskritischen Bereichen überlebenswichtig ist.
  • Zum Bösen: Akzeptiert der Benutzer ein falsches Zertifikat wie im unten genannten Beispiel gezeigt, oder werden Browser oder Betriebssystem bösartig manipuliert, ist es möglich die komplette Verschlüsselung sensibler Daten mitzulesen.

 

Installation von SSL-Bump

  • Zuerst müssen ein entsprechender Ordner angelegt und Squid Rechte müssen angepasst werden.
$ sudo cd /etc/squid
$ sudo mkdir ssl_cert
$ chown squid:squid
$ chmod 700 ssl_cert
$ cd ssl_cert
  • Danach muss man sich ein eigenes Zertifikat für den Server generieren und das Dateiformat browserfreundlich machen. In folgendem Beispiel generiert man sich ein einfaches, selbst signiertes Zertifikat. In den meisten Fällen will man ein Zertifikat das von der eigenen Zertifikatsstelle wie der eigenen Firma abstammt.
$ openssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -extensions v3_ca -keyout myCA.pem -out myCA.pem
$ openssl x509 -in myCA.pem -outform DER -out myCA.der
  • Jetzt muss man es in den Ziel Browser importieren.

Firefox

  • Via Firefox ist die Lösung folgende:
  • Man geht auf Preferences und gibt in der Suchleiste “Cert” ein.
  • Jetzt geht man auf View Certificates und danach gibt es einen Import Certificates Button den man auswählt und beide Firefox Abfragen bestätigt.

 

Squid Konfiguration

  • Folgender Code muss jetzt in die Konfiguration unter /etc/squid/squid.conf übernommen werden:
http_port 3128 ssl-bump \
  cert=/etc/squid/ssl_cert/myCA.pem \
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

sslcrtd_program /usr/lib64/squid/security_file_certgen -s /var/lib/ssl_db -M 4MB

acl step1 at_step SslBump1

ssl_bump peek step1
ssl_bump bump all
  • Es sollte nun so aussehen:

  • Im Anschluss wirft man noch den dynamischen Zertifikat-Generator an und passt die Rechte an.
$ sudo /usr/lib64/squid/security_file_certgen -c -s /var/lib/ssl_db -M 4MB
$ chown squid:squid -R /var/lib/ssl_db
  • Nach einem Neustart sollte man überall seine eigenen Zertifikate sehen und sämtlichen Traffic mitschneiden können.
$ sudo systemctl restart squid

 

  • Beispiel Anhand der Sparkasse Berlin: Wir sind jetzt die Zertifikatsstelle.

 

 

Wie kann ich mich als Benutzer vor MITM Angriffen schützen?

Ein Ansatz entwickelte sich auf Basis von Certificate Pinning und Certificate Transparency wo von höheren Zertifikatsstellen über Filterlisten überprüft wird ob das aktuelle Zertifikat dem entspricht das für die jeweilige Domain zu erwarten ist, und dann Seiten freizugeben oder zu blockieren. Natürlich geht so etwas nicht überall wie z.B. in internen Netzwerken oder kleineren unabhängigeren Seiten. Hier wäre dann HPKP sinnvoll gewesen wo man sich selbst den Root Trust ausspricht – ohne Gegenstellen. Leider haben Konfigurationsfehler und die Idee dass potentielle Angreifer den Server übernehmen könnten und dann Lösegeld zum Freigabe fordern könnten HPKP als problematisch erscheinen lassen.

  • Schulungen & Umsicht: Eine Manipulation an Zertifikaten, dem Browser oder Betriebssystem ist schwer wenn Nutzer aufmerksam sind.
  • Zertifikate wirklich anklicken und ansehen! Wie in den Bildern zu erkennen steht bei Certificate Authority: No.
  • Umgebungsmonitoring betreiben: NETWAYS bietet mit Icinga eine Plattform nahezu jede Infrastruktur zu monitoren, z.B. auch Zertifikate.
  • 2-Fakor-Authentifizierung: Selbst wenn Angreifer wie in diesem Beispiel Logins abfangen könnten und Kontostände einsehen, würde man für eine Transaktion immer noch einen TAN benötigen.

 

Patrick Dolinic
Patrick Dolinic
Junior Consultant

Nachdem Patrick sein Psychologiestudium abgeschlossen hat, ist er 2020 zu NETWAYS, wo er nun sein Hobby zum Beruf macht: Endlich kann er sich voll und ganz der Linux-Welt widmen und sein Faible für Computersicherheit ausleben. Wenn er nicht gerade arbeitet, arbeitet oder zockt er. Nebenbei versucht er beim Joggen 8 km zu reißen, schafft aktuell aber nicht mal die ersten 7.