Proxy Authentication
We implement proxy servers to improve internal network security. Mainly we’re attempting to keep bad traffic from communicating with the outside world. If malware lands on an internal box, it may for example attempt a call back to its command and control server. Typically this occurs over port 443 and is lost in the sea of legitimate traffic because your typical firewall is rather dumb. Compared to a proxy it does not inspect all 7 layers of the OSI model. It doesn’t understand there is a covert channel pretending to be SSL encrypted traffic.
By funneling all outbound traffic through a proxy we can stop most of these bad packets. Often malware is not proxy aware and it will attempt to escape your network through the default gateway (typically your firewall). When implementing a proxy server, you should be adding a DENY ALL rule blocking ALL hosts from leaving out your front door. While this sounds like a great solution, there is a small loophole. Modern malware is slowly becoming proxy aware. Hence some bad traffic may evade even your smart proxy server trough a covert channel especially when configured in transparent mode.
Enter, Proxy Authentication to the rescue. It’s a simple concept, before a proxy accepts your request you have to present your credentials and be authenticated, otherwise your packets become lost in space, hence no reverse shell connection to a command and control server. I’ve talked about Squid, and its many features and benefits. And you guessed it this week I’ll discuss enabling Squid Proxy Authentication.
Squid supports the following authentication mechanisms;
- Basic – Simplest to implement but most insecure (clear text username and password)
- Digest – Easy to implement and more secure using MD5 hashed username and password
- NTLM – Harder to implement using Microsoft’s proprietary SMB protocol
- Negotiate – Hardest to implement but most secure with Kerberos and AD
Depending on your environment and requirements I would suggest NTLM or Negotiate for most Windows centric networks. Negotiate with Kerberos would be my first choice but there are a few hoops to jump through. NTLM is a good second choice but because Microsoft hasn’t been forth coming with its proprietary protocol implementation, it’s been reverse engineered by some very smart people.
Over the next several weeks I’ll take you through each authentication mechanism in more detail. If you’re currently not using Proxy authentication with your proxy I would strongly suggest you begin to think about it and plan to implement it in the near future. As malware evolves, so should we and our defenses.
Till next week.
