Squid is a capable proxy, and can be used to enforce security rules for small and medium sized organisations. It’s also a cost-effective solution, e.g. if you’re implementing AP17.
Many guides for configuring Squid provide some simple examples based on host name when defining ACLs. The basic format of a Squid ACL directive looks like this:
acl <acltype> <arguments>
acl <acltype> <filename>
There are a few other configuration options available, which can help implement better security controls for web traffic.
Here’s a run down of some useful ACL types:
- time – allows policies to be defined based on day of the week and a time range. You could for instance prohibit access to social media during working hours.
- url_regex – pattern match using a regex on the requested URL.
- browser – pattern match using a regex on the user browser agent string. You could for instance handle traffic from specific browser types or versions differently to others, such as restricting traffic from old versions of a vulnerable browser version.
- srcdomain – checks the client domain using a reverse lookup. This could be used to define access controls based on internal DNS domains for an organisation, but beware as it’s very slow.
- arp/eui64 – allows a MAC address to be specified for IPv4 clients on the same subnet as the proxy. You could use this as a (relatively weak) enhancement for network access control.
- dstdomain – quite a well understood ACL type, this can be used to define policies based on the destination domain of the request.
- dstdomain_regex – as above, but allowing a regex to be used in place of the dstdomain argument(s).
- req_mime_type – this can be used to detect file uploads by end users, for example denying the attempt.
- rep_mime_type – allows detection of the downloaded file type, for example allowing specific types of files to be handled in a particular way.
- proxy_auth – allows you to authenticate the user using an external service.
- max_user_ip – allows you to detect user logins from multiple IP addresses, which may indicate an exploitation attempt.
- random probability – allows a match based on a probability value.
- ssl::servername, ssl::servername_regex – allows the SSL server name to be detected and a specific rule applied.
An interesting SSL configuration option is server_cert_fingerprint, which is a fast matching algorithm for specific SSL certificate fingerprints. With some automation it should be possible to adapt one of the many sources of malicious SSL certificates (as used by threat actors) and integrate it into your Squid configuration, potentially expanding your ability to detect network-bourne malware and C&C traffic.
There are also various additional certificate properties that could be used to tighten up validation of SSL connections at the proxy server, before they reach the client. They are as follows, and self-explanatory:
[ssl::]certHasExpired [ssl::]certNotYetValid [ssl::]certUntrusted [ssl::]certSelfSigned [ssl::]certDomainMismatch
As recent high-profile malware discoveries have shown, it’s not that difficult for attackers to obtain SSL certificates from trusted authorities like Comodo. With that in mind, you might get some mileage with domain mismatches on the certificate, but other certificate properties might not detect a great deal. Detecting malicious fingerprints is probably the best certificate signature at the moment, over and above malicious domains and IP addresses.
So in summary there are some exciting fine-grained configuration directives available for Squid, and with some careful planning it should be possible to make your proxy control work much more effectively.