Ein Web-Proxy-Server ist ein Webserver, der als Gateway zwischen einer Clientapplikation, beispielsweise ein Webbrowser, und dem Ziel-Webserver agiert. Dabei kommuniziert der Proxy-Server mit dem Ziel-Webserver im Auftrag der Clientapplikation. Ein Proxy kann als Cache für Webinhalte eingesetzt werden, um den Datenverkehr zu reduzieren. Eine weitere Aufgabe des Proxy-Servers ist den Zugriff ins Internet zu kontrollieren. Auf dem Proxy wird konfiguriert, welche Applikation, welcher Benutzer und welches System auf welche Ressource zugreifen kann. Somit ist der Proxy-Server ein wichtiger Bestandteil bei der Absicherung von ausgehenden Zugriffen.

Benutzer und Computer müssen sich gegenüber dem Proxy-Server authentisieren, dazu wurde oft Basic Authentication oder NTLM eingesetzt. NTLM sollte soweit als möglich deaktiviert werden und bei Basic Authentication werden Benutzername und Passwort unverschlüsselt im HTTP-Header übertragen, nur geschützt durch die TLS-Transportverschlüsselung. Daher sollte auf den Einsatz beider Authentisierungsmethoden verzichtet und auf Kerberos gesetzt werden.

Wir setzen in unserer Testumgebung den Proxy-Server Squid ein. In diesem Artikel beschreiben wir die Grundkonfiguration einer Squid-Instanz mit Kerberos. Die vollständige Konfiguration eines Proxy-Serves mit Ausnahmen für Systeme und Applikationen, die keine Unterstützung für Kerberos haben, sowie das Filtern und Überwachen des Netzwerkverkehrs und eines Berechtigungskonzept, wer auf welchen Inhalt zugreifen darf, ist nicht Bestandteil des Artikels.

Konfiguration der Kerberos-Anbindung

Wir haben den Proxy-Server auf der Basis von Fedora Linux aufgebaut. Der Server wird dediziert betrieben und ist nicht mit der Domäne verbunden. Der Proxy-Server ist das einzige System innerhalb der Infrastruktur, das externe DNS-Server verwenden darf, als Massnahme gegen DNS-Tunneling auf Systemen der Domäne.

Damit die Kerberos-Authentisierung möglich ist, muss der Proxy-Server mit den Domain Controller kommunizieren können. Die Konfiguration dazu wird in der Datei /etc/krb5.conf vorgenommen.

[libdefaults]
...
default_realm = LABS.EXAMPLE.ORG
dns_lookup_kdc = no
dns_lookup_realm = no

default_tgs_enctypes = aes256-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96

[realms]
LABS.EXAMPLE.ORG = {
    kdc = dc01.labs.example.org
    admin_server = dc01.labs.example.org
}

[domain_realm]
.labs.example.org = LABS.EXAMPLE.ORG
labs.example.org = LABS.EXAMPLE.ORG

Die Gross-/Kleinschreibung des Realms und der Domäne ist essentiell und muss im weiteren Verlauf überall gleich umgesetzt werden, ansonsten klappt die Verbindung nicht. Positiv anzumerken ist, dass Fedora und Red Hat Linux den Verschlüsselungsalgorithmus RC4 sowie ältere Algorithmen standardmässig nicht mehr unterstützen. Der Forest example.org ist so konfiguriert, dass für Kerberos nur AES256 and future encryption types erlaubt sind.

Konfiguration Squid

Squid wird aus dem Fedora-Repository installiert, zusätzlich wird das Paket krb5-workstation benötigt, welches Werkzeuge zum Arbeiten mit Keytab-Dateien und Kerberos-Tickets beinhaltet. Keytab steht für Key Table und wird verwendet, um Langzeit gültige Schlüssel für einen oder mehreren Service Principals zu speichern. Damit sich Squid gegenüber dem Active Directory authentisieren kann, wird eine solche Keytab-Datei auf einem mit der Domäne verbundenen System für das Dienstkonto proxyuser erstellt.

Die folgenden Befehle erstellen eine Keytab-Datei für die zwei Principals HTTP/proxyserver und HTTP/proxyserver.labs.example.org, welche mit dem Benutzer proxyuser verbunden werden, die Service Principal Names (SPN) werden dabei automatisch erstellt. In der Keytab-Datei wird nur AES256-SHA1-Schlüsselmaterial hinterlegt.

PS C:\> ktpass.exe /princ HTTP/proxyserver@LABS.EXAMPLE.ORG /mapuser proxyuser /pass * -crypto AES256-SHA1 +dumpsalt -setupn -setpass -ptype KRB5_NT_PRINCIPAL /out proxyuser.keytab
PS C:\> ktpass.exe /princ HTTP/proxyserver.labs.example.org@LABS.EXAMPLE.ORG /mapUser proxyuser /pass * -crypto AES256-SHA1 +dumpsalt -setupn -setpass -ptype KRB5_NT_PRINCIPAL /mapOp add /in proxyuser.keytab /out proxyuser.keytab

Die Keytab-Datei wird auf dem Proxy-Server unter /etc/squid/proxyuser.keytab abgelegt und der Zugriff soweit als möglich eingeschränkt. Mit dem Tool klist kann der Inhalt unter Linux angezeigt werden.

[user@proxyserver ~] sudo chown root:squid /etc/squid/proxyuser.keytab 
[user@proxyserver ~] chmod 640 root:squid /etc/squid/proxyuser.keytab
[user@proxyserver ~] sudo klist -e -k /etc/squid/proxyuser.keytab
Keytab name: FILE:/etc/squid/proxyuser.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  16 HTTP/proxyserver@LABS.EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
  16 HTTP/proxyserver.labs.example.org@LABS.EXAMPLE.ORG (aes256-cts-hmac-sha1-96)

Damit sich Squid mit der Keytab-Datei authentisieren kann, ist die folgende Konfiguration in /etc/squid/squid.config nötig. Die Authentisierung ist notwendig, damit Squid mit den Domain Controllern kommunizieren kann und alle Konten (Benutzer und Computer), die sich am Proxy anmelden wollen, verifizieren kann.

# Kerberos Authentication
# Use the switch "-d" (debugging) for troubleshooting
auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/proxyuser.keytab -s HTTP/proxyserver.labs.example.org@LABS.EXAMPLE.ORG -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive on
acl kerb proxy_auth REQUIRED

Bei negotiate_kerberos_auth muss darauf geachtet werden, dass der SPN genau gleich geschrieben wird wie im Active Directory. Der Realm muss ausschliesslich in Grossbuchstaben geschrieben werden.

Zugriff einschränken

Der Internetzugriff ist nur für Mitglieder der Gruppe grp-proxyallow01 erlaubt. Squid verwendet LDAPS um die Mitglieder abzufragen. Leider gelang es bei unseren Konfiguration nicht, die Keytab-Datei auch für die LDAPS-Authentisierung zu verwenden, sodass in der Squid-Konfiguration die Zugangsdaten des Dienstkontos hinterlegt werden müssen. Der Zugriff auf die Konfiguration ist jedoch auf die Benutzer squid und root eingeschränkt.

# Definition of a specific AD group (LDAP request)
# Use the switch "-d" (debugging) for troubleshooting
external_acl_type proxy_ad_grp-proxyallow01 ttl=3600 negative_ttl=3600 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g "grp-proxyallow01" -s -a -i -l ldaps://dc01.labs.example.org:636 -u "proxyuser" -p "<secret>" -D "LABS.EXAMPLE.ORG"
acl ad_grp-proxyallow01 external proxy_ad_grp-proxyallow01

Mit diesen Informationen können Domain-Listen und ACLs erstellt werden, um den Zugriff ins Internet zu regeln. Die ACLs werden entweder direkt in der Konfiguration oder über das Einbinden von Dateien definiert.

# Definition of domain lists used for allow/deny acls
acl youtube_domains dstdomain .youtube.com .googlevideo.com .ytimg.com
acl allowed_domains dstdomain /etc/squid/acl_allowed_domains.conf

# Deny access for all to YouToube
http_access deny youtube_domains

# Allow access based on Kerberos auth / AD groups
http_access allowed_domains ad_grp-proxyallow01

# And finally deny all other access to this proxy
http_access deny all

In diesem Ausschnitt wurden die ACLs für YouTube und eine Liste erlaubter Domains definiert. Der Zugriff auf YouTube wird allen Benutzern verwehrt, während der Zugriff auf die Liste der Domains den Mitgliedern der AD-Gruppe ad_grp-proxyallow01 erlaubt wurde.

Troubleshooting

Die Dateien access.log und cache.log enthalten Informationen für Troubleshooting und Überwachung der Zugriffe. Diese Dateien sollten an die Log-Infrastruktur weitergeleitet und ausgewertet werden. Grundsätzlich wird jeder Request zuerst mit dem Status TCP_DENIED/407 geblockt und damit dem Benutzer signalisiert, dass eine Authentisierung mit Kerberos erforderlich ist. Danach erfolgt derselbe Request mit der Authentisierung des Benutzers.

1651764387.820   16 192.168.10.101 TCP_DENIED/407 3965 CONNECT europe.cp.wd.microsoft.com:443 - HIER_NONE/- text/html
1651764397.612   9790 192.168.10.101 TCP_TUNNEL/200 3957 CONNECT europe.cp.wd.microsoft.com:443 dc01$@LABS.EXAMPLE.ORG HIER_DIRECT/20.54.122.82

In den Logdateien ist ersichtlich, welches System mit welchem Benutzer auf welche URL zugriffen hat. Interessant ist es auch auszuwerten, welches System sich nicht authentisieren konnte. Entweder liegt eine Fehlkonfiguration vor, oder eine Softwarekomponente hat keine Unterstützung für Kerberos. Dabei kann es sich auch beispielsweise um Malware handeln.

Proxy-Konfiguration in Windows

Die Proxy-Server-Konfiguration in Windows kann über unterschiedliche Wege realisiert werden, unter anderem mittels des Protokolls Web Proxy Auto-Discovery (WPAD) oder der statischen Konfiguration in der Registry über Gruppenrichtlinien. Der Schlüssel ProxyEnable unter dem Pfad HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings wird auf den Wert 1 gesetzt und der Schlüssel ProxyServer unter demselben Pfad auf die Adresse des Proxy-Servers, wie zum Beispiel proxyserver.labs.example.org:3128.

Die Windows-HTTP-Dienste (WinHTTP) verfügen über eine eigene Proxy-Konfiguration. Diese kann ebenfalls über Registry-Schlüssel verteilt werden. Auf einem System kann mit dem Befehl netsh winhttp import proxy source=ie die Konfiguration aus dem vorherigen Abschnitt für WinHTTP importiert oder statisch mittels netsh winhttp set proxy <proxy>:<port> gesetzt werden. Der Binärwert der Einstellung befindet sich im Schlüssel WinHttpSettings unter dem Pfad HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections. Dieser Schlüssel kann ebenfalls via Gruppenrichtlinien verteilt werden.

Für Anwendungen wie Microsoft Defender for Endpoint muss, wie in der Anleitung von Microsoft beschrieben, die Einstellung Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure Authenticated Proxy usage for the Connected User Experience and Telemetry Service auf den Wert Enabled und Disable Authenticated Proxy usage gesetzt werden. Der Proxy-Servers wird unter Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure connected user experiences and telemetry sowie unter Administrative Templates > Windows Components > Microsoft Defender Antivirus > Define proxy server for connecting to the network. konfiguriert.

Gemäss der Anleitung für Microsoft Defender for Identity kann für den Proxy ein Benutzername und Passwort hinterlegt werden. Wenn keine Anmeldedaten definiert werden, schlägt die Authentisierung auf dem Proxy fehl, eine native Unterstützung für Kerberos-Authentisierung scheint zu fehlen. Wir haben für den Endpunkt <your_workspace_name>sensorapi.atp.azure.com und die jeweiligen Systeme eine Ausnahmeregel in Squid konfiguriert.

acl system01 src 192.168.10.101/32
acl defender_for_identity dstdomain <your_workspace_name>sensorapi.atp.azure.com
http_access allow defender_for_identity system01

Microsoft stellt Werkzeuge zum Testen der Verbindung zu Verfügung, wie zum Beispiel das Microsoft Defender for Endpoint Client Analyzer Tool. Dies hilft bei der Konfiguration des Proxys und beim Troubleshooting, wenn Applikationen und Dienste nicht wie gewünscht funktionieren.

Fazit

Bei der Konfiguration eines Web-Proxy-Servers mit Kerberos-Authentisierung gibt es einige Hürden. Einerseits muss der Proxy-Server mit dem Active Directory verbunden sein, oder so konfiguriert werden, dass alle Proxy-Dienste sich authentisieren können. In unserer Testumgebung gelang es nicht das Squid-LDAP-Modul mit einer Keytab-Datei zum Laufen zu bringen. Die Verwendung von Kerberos stellt eine sichere Authentisierungsmethode dar. Da nicht alle Applikationen und Dienste über Kerberos-Unterstützung verfügen, werden Ausnahmen konfiguriert und dokumentiert werden müssen.

Tim MalcomVetter, Head of Managed Security Services bei Cyderes, hatte im Februar 2019 eine Twitter-Umfrage zur Konfiguration mit Squid Proxy und Kerberos durchgeführt. Von 68 Stimmen haben 75% noch keine solche Konfiguration vorgenommen und die anderen 25% haben zugestimmt, dass es nichts Schwierigeres gibt.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://www.squid-cache.org/
• https://aka.ms/mdeanalyzer
• https://docs.microsoft.com/en-us/defender-for-identity/configure-proxy
• https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/configure-proxy-internet
• https://getfedora.org/en/server/
• https://twitter.com/malcomvetter
• https://twitter.com/malcomvetter/status/1093664834221002752
• https://www.scip.ch/?labs.20210909