A web proxy server is a web server that acts as a gateway between a client application, for example a web browser, and the target web server. Thereby, the proxy server communicates with the target web server on behalf of the client application. A proxy can be used as a cache for web content to reduce traffic. Another task of the proxy server is to control access to the Internet. It is configured on the proxy which application, which user and which system can access which resource. Thus, the proxy server is an crucial element in securing outgoing connections.

Users and computers need to authenticate themselves to the proxy server; Basic Authentication or NTLM was often used for this task. However, NTLM should be deactivated as far as possible and Basic Authentication sends username and password unencrypted in the HTTP header, protected only by the TLS transport encryption. Therefore, the use of both authentication methods should be discontinued, and Kerberos should be preferred.

We use the proxy server Squid in our test environment. In this article we describe the basic configuration of a Squid instance with Kerberos. The complete configuration of a proxy server with exceptions for systems and applications that do not support Kerberos, as well as the filtering and monitoring of network traffic and an authorisation concept of who is allowed to access what content, is not part of the article.

Configuration of Kerberos Integration

We have built the proxy server on the basis of Fedora Linux. The server is run as a dedicated system and is not joined to the domain. The proxy server is the only system within the infrastructure that is allowed to use external DNS servers, as a measure against DNS tunnelling on systems in the domain.

The proxy server must be able to communicate with the domain controller so that Kerberos authentication is possible. The configuration for this is done in the file /etc/krb5.conf.

[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

The upper/lower spelling of the realm and the domain is essential and must be applied in the same way everywhere, otherwise the connection will not work. On a positive note, Fedora and Red Hat Linux no longer support the encryption algorithm RC4 or older algorithms by default. Our forest example.org is configured to only allow AES256 and future encryption types for Kerberos.

Squid Configuration

Squid is installed from the Fedora repository, additionally the package krb5-workstation is installed, which contains tools for working with keytab files and Kerberos tickets. Keytab stands for Key Table and is used to store long-term valid keys for one or more Service Principals. In order for Squid to authenticate itself to the Active Directory, a keytab file of this type is created on a system connected to the domain for the proxyuser service account.

The following commands create a keytab file for the two principals HTTP/proxyserver and HTTP/proxyserver.labs.example.org, which are connected to the user proxyuser, the Service Principal Names (SPN) are created automatically. Only AES256-SHA1 key material is stored in the keytab file.

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

The keytab file is stored on the proxy server under /etc/squid/proxyuser.keytab and the access is restricted as far as possible. With the tool klist the content can be shown under Linux.

[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)

In order for Squid to authenticate itself with the keytab file, the following configuration in /etc/squid/squid.config is necessary. Authentication is necessary so that Squid can communicate with the domain controllers and verify all accounts (users and computers) that want to log on to the proxy.

# 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

For negotiate_kerberos_auth, the SPN must be written exactly the same as in the Active Directory. The realm must be written only in capital letters.

Restrict Access

Internet access is only allowed for members of the group grp-proxyallow01. Squid uses LDAPS to query the members. Unfortunately, we did not succeed in using the keytab file for LDAPS authentication in our configuration, so the credentials of the service account must be stored in the Squid configuration. However, access to the configuration is restricted to the users squid and root.

# 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

With this information, domain lists and ACLs can be created to control access to the Internet. The ACLs are defined either directly in the configuration or by including files.

# 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 this extract, the ACLs for YouTube and a list of allowed domains have been defined. Access to YouTube is denied to all users, while access to the list of domains has been allowed to members of the AD group ad_grp-proxyallow01.

Troubleshooting

The files access.log and cache.log contain information for troubleshooting and monitoring access. These files should be forwarded to the log infrastructure and analysed. Each request is first blocked with the status TCP_DENIED/407, thus signalling to the user that authentication with Kerberos is required. Then the same request is made with the authentication of the user.

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

The log files show which system accessed which URL with which user. It is also interesting to analyse which system could not authenticate itself. Either there is a misconfiguration, or a software component does not support Kerberos. This can also be malware, for example.

Windows Proxy Configuration

The proxy server configuration in Windows can be implemented in several ways, including using the Web Proxy Auto-Discovery (WPAD) protocol or the static configuration in the registry via group policies. The key ProxyEnable under the path HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings is set to the value 1 and the key ProxyServer under the same path is set to the address of the proxy server, such as proxyserver.labs.example.org:3128.

The Windows HTTP services (WinHTTP) have their own proxy configuration. This can also be distributed via registry keys. On a system, the configuration from the previous section can be imported for WinHTTP with the command netsh winhttp import proxy source=ie or set static with netsh winhttp set proxy <proxy>:<port>. The binary value of the setting is located in the key WinHttpSettings under the path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections. This key can also be distributed via group policies.

For applications such as Microsoft Defender for Endpoint, the setting Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure Authenticated Proxy usage for the Connected User Experience and Telemetry Service must be configured to the values Enabled and Disable Authenticated Proxy usage as described in the Instructions from Microsoft. The proxy server is configured under Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure connected user experiences and telemetry and under Administrative Templates > Windows Components > Microsoft Defender Antivirus > Define proxy server for connecting to the network.

According to the Instructions for Microsoft Defender for Identity, a user name and password can be defined for the proxy. If no credentials are defined, authentication on the proxy fails, native support for Kerberos authentication seems to be missing. We have configured an exception rule in Squid for the endpoint <your_workspace_name>sensorapi.atp.azure.com and the respective systems.

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 provides tools for testing the connection, such as the Microsoft Defender for Endpoint Client Analyzer Tool. This helps with configuring the proxy and troubleshooting when applications and services do not work as desired.

Summary

There are some obstacles when configuring a web proxy server with Kerberos authentication. On the one hand, the proxy server must be connected to the Active Directory or configured so that all proxy services can authenticate themselves. In our test environment, we could not get the Squid LDAP module to work with a keytab file. If anyone has a hint or solution to this, we would be happy to receive feedback. The use of Kerberos is a secure authentication method. Since not all applications and services have Kerberos support, exceptions will need to be configured and documented.

Tim MalcomVetter, Head of Managed Security Services at Cyderes, had conducted a Twitter poll on the configuration of Squid Proxy and Kerberos in February 2019. Out of 68 votes, 75% have not yet done such a configuration and the other 25% agreed that there is nothing more difficult. With this in mind, we hope that this article will be of help for upcoming installations and configurations and that the implementation can be accomplished successfully.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (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