Sie wollen mehr?
Weitere Artikel im Archiv
So setzen Sie einen Proxy mit Kerberos auf
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.
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.
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.
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.
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.
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.
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.
Unsere Spezialisten kontaktieren Sie gern!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Unsere Spezialisten kontaktieren Sie gern!