Paranoid Penguin - Building a Secure Squid Web Proxy, Part III
July 1st, 2009 by Mick Bauer in
ACL Review
As you may recall from my last column, all we had to do to get Squid running on a standard Ubuntu 8.04 system was add two lines to the file /etc/squid/squid.conf:
acl mick_network src 10.0.2.0/24
http_access allow mick_network
We inserted those two lines, which allow outbound proxy connections from clients whose IP addresses fall within the network 10.0.2.0/24 (that is, addresses 10.0.2.1 through 10.0.2.254), right above Squid's default “deny all” ACL, which looks like this:
http_access deny all
You can correctly infer from this that, by default, Squid denies proxy connections from all clients. This is a refreshing change in default server application configurations during the past few years. Whereas in the past, many applications had default configurations that would “just work”, which is a very user-friendly but also excessively open stance, nowadays few network applications will do much of anything without some administrative intervention. This is only sensible. Connecting things to the Internet that you don't even know how to configure is the way of pain.
Getting back to our example ACL, the acl statement itself is fairly self-explanatory: acl tells Squid we're defining an ACL; mick_network is its name; src indicates it matches the client's source IP address or network address; and 10.0.2.0/24 is the network address in CIDR notation that will match this ACL.
This is the simplest type of ACL and still one of the most useful. In February 2002, if the New York Times had had a simple source-IP/network ACL correctly configured on its Internet-facing corporate Web proxies, the rogue hacker Adrian Lamos couldn't have gained access quite so easily to its editorial-page contributor database or its Lexus-Nexus portal.
ACLs in More Depth
Besides clients' (source) IP addresses, Squid also can match a great deal of other proxy transaction characteristics. Note that some of these deal with arcane HTTP headers and parameters, many of which are minimally useful for most Squid users anyhow.
Table 1. Complete List of ACL Types Supported in Squid 2.6
| ACL Type | Description |
|---|---|
| src | Client (transaction source) IP address or network address. |
| dst | Server (transaction destination) IP address or network address. |
| myip | Local IP address on which Squid is listening for connections. |
| arp | Client's Ethernet (MAC) address (matches local LAN clients only). |
| srcdomain | Client's domain name as determined by reverse DNS lookup. |
| dstdomain | Domain portion of URL requested by client. |
| srcdom_regex | Regular expression matching client's domain name. |
| dstdom_regex | Regular expression matching domain in requested URL. |
| time | Period of time in which transaction falls. |
| url_regex | Regular expression matching entire requested URL (not just domain). |
| urlpath_regex | Regular expression matching path portion of requested URL. |
| urllogin | Regular expression matching requested URL's “login” field. |
| port | Requested site's (destination) TCP port. |
| myport | Local TCP port on which Squid is listening for connections. |
| proto | Application-layer protocol of request (HTTP, HTTPS, FTP, WHOIS or GOPHER). |
| method | Request's HTTP method (GET, POST or CONNECT). |
| browser | Matches the client's browser, per HTTP “User-Agent” header. |
| referer_regex | Regular expression matching the unreliable HTTP “Referer” header (that is, the supposed URL of some page on which the user clicked a link to the requested site). |
| ident | Matches specified user name(s) of user(s) running client browser, per an “ident” lookup. Note that ident replies, which often can be spoofed, should not be used in lieu of proper authentication. |
| ident_regex | Regular expression defining which client user names to match per ident lookup. |
| src_as | Matches client IP addresses associated with the specified Autonomous System (AS) number, usually an ISP or other large IP registrant. |
| dst_as | Matches destination-server IP addresses associated with the specified AS number. |
| proxy_auth | Matches the specified user name, list of user names or the wild card REQUIRED (which signifies any valid user name). |
| proxy_auth_regex | Regular expression defining which user names to match. |
| snmp_community | For SNMP-enabled Squid proxies, matches client-provided SNMP community string. |
| maxconn | Matches when client's IP address has established more than the specified number of HTTP connections. |
| max_user_ip | Matches the number of IP addresses from which a single user attempts to log in. |
| req_mime_type | Matches a regular expression describing the MIME type of the client's request (not the server's response). |
| req_header | Matches a regular expression applied to all known request headers (browser, referer and mime-type) in the client's request. |
| rep_mime_type | Matches a regular expression describing the MIME type of the server's response. |
| rep_header | Matches a regular expression applied to all known request headers (browser, referer and mime-type) in the server's response. |
| external | Performs an external ACL lookup by querying the specified helper class defined in the external_acl_type tag. |
| urlgroup | Matches a urlgroup name, as defined in redirector setups. |
| user_cert | Matches specified attribute (DN, C, O, CN, L or ST) and values against client's SSL certificate. |
| ca_cert | Matches specified attribute (DN, C, O, CN, L or ST) and values against client certificate's issuing Certificate Authority certificate. |
| ext_user | Matches specified user name(s) against that returned by an external ACL/authentication helper (configured elsewhere in squid.conf). |
| ext_user_regex | Matches a regular expression describing user names to be matched against that returned by an external ACL/authentication helper. |
I've presented the full range of possible ACL types to give you a taste for how rich Squid's ACL functionality is. Needless to say, however, I can't cover usage scenarios for (or even adequately explain) all of these. ViServe's “Squid 2.6 Configuration Manual” (see Resources) gives complete syntax and usage examples for all.
Many, if not most, Squid installations don't go much beyond a few src ACLs, along with perhaps a few simple dstdomain blacklist entries thrown in for good measure. Many of the other most useful ACL types, such as myip, time, port, proto, method, dst_mime_type and rep_mime_type, should be reasonably self-explanatory (or at least easy enough to understand from the examples shown in squid.conf's comments).
One category of less-intuitive ACL types is particularly powerful and useful: the ones that enable Squid to authenticate client users via external authentication authorities. Before we tackle authentication, however, we should give a little more attention to ACL operators, the tags that perform some action (most commonly, to allow or deny a request) based on a matched ACL.
By far, the most important ACL operator is http_access, which specifies whether Squid should allow the transaction matching the specified ACL to proceed. Going back to the example ACL/operator pair from the beginning of this section, after we defined the ACL mick_network as all transactions involving client/source IP addresses within 10.0.2.0/24, we operated on it with this line:
http_access allow mick_network
This is simple enough to understand: “allow HTTP requests matching the ACL named mick_network.”
The most common use of ACLs is to specify a list of ACLs and http_access statements, ending (as we've seen) with a “drop by default” line, like this:
http_access deny all
This has the effect of creating a “whitelist”— a list of types of transactions that are allowed, with all others being denied.
Squid recognizes a number of additional ACL operators besides http_allow, including no_cache, ident_lookup_access, always_direct, never_direct and snmp_access. Because most of these concern cache performance, HTTP redirects and communications with other Squid servers rather than security per se, I'll leave it to you to explore those (or not) as your particular needs dictate. The Squid User's Guide referenced in the Resources section is a good source of information about Squid's various ACL operators.
Squid Authentication
As I mentioned previously, one of Squid's most handy capabilities is its ability to authenticate proxy users by means of a variety of external helper mechanisms. One of the simplest and probably most commonly used helper applications is ncsa_auth, a simple user name/password scheme that uses a flat file consisting of rows of user name/password hash pairs. The HOWTO by Vivek Gite and, to a lesser extent, the Squid User's Guide, explain how to set this up (see Resources).
Briefly, you'll add something like this to /etc/squid/squid.conf:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squidpasswd
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server at Wiremonkeys.org
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
And, in the ACL section:
acl ncsa_auth_users proxy_auth REQUIRED
http_access allow ncsa_auth_users
The block of auth_param tags specifies settings for a “basic” authentication mechanism:
program is the helper executable ncsa_auth, using the file /etc/squid/squidpassd as the user name/password hash list (created previously).
children, the number of concurrent authentication processes, is five.
realm, part of the string that greets users, is “Squid proxy-caching Web server at Wiremonkeys.org”.
credentialsttl, the time after authentication that a successfully authenticated client may go before being re-authenticated, is two hours.
casesensitive, which determines whether user names are case-sensitive, is off.
In the ACL section, we defined an ACL called ncsa_auth_users that says the proxy_auth mechanism (as defined in the auth_param section) should be used to authenticate specified users. Actually in this case, instead of a list of user names to authenticate, we've got the wild card REQUIRED, which expands to “all valid users”. The net effect of this ACL and its subsequent http_access statement is that only successfully authenticated users may use the proxy.
The main advantages of the NCSA mechanism are its simplicity and its reasonable amount of security (only password hashes are transmitted, not passwords proper). Its disadvantage is scalability, because it requires you to maintain a dedicated user name/password list. Besides the administrative overhead in this, it adds yet another user name/password pair your users are expected to remember and protect, which is always an exercise with diminishing returns (the greater the number of credentials users have, the less likely they'll avoid risky behaviors like writing them down, choosing easy-to-guess passwords and so forth).
Therefore, you're much better off using existing user credentials on an external LDAP server (via the ldap_auth helper) on an NT Domain or Active Directory server (via the msnt_auth helper) or the local Pluggable Authentication Modules (PAM) facility (via the pam_auth helper). See Resources for tutorials on how to set up Squid with these three helpers.
Note that Squid's helper programs are located conventionally under /usr/lib/squid. Checking this directory is a quick way to see which helpers are installed on your system, although some Linux distributions may use a different location.
Other Squid Defenses
Access Control Lists really are Squid's first line of defense—that is, Squid's primary mechanism for protecting your network, your users and the Squid server itself. There are a couple other things worth mentioning, however.
First, there's the matter of system privileges. Squid must run as root, at least while starting up, so that, among other things, it can bind to privileged TCP ports such as 80 or 443 (although by default it uses the nonprivileged port 3128). Like other mainstream server applications, however, Squid's child processes—the ones with which the outside world actually interacts—are run with lower privileges. This helps minimize the damage a compromised or hijacked Squid process can do.
By default, Squid uses the user proxy and group proxy for nonprivileged operations. If you want to change these values for effective UID and GID, they're controlled by squid.conf's cache_effective_user and cache_effective_group tags, respectively.
Squid usually keeps its parent process running as root, in case it needs to perform some privileged action after startup. Also, by default, Squid does not run in a chroot jail. To make Squid run chrooted, which also will cause it to kill the privileged parent process after startup (that is, also will cause it to run completely unprivileged after startup), you can set squid.conf's chroot tag to the path of a previously created Squid chroot jail.
If you're new to this concept, chrooting something (changing its root) confines it to a subset of your filesystem, with the effect that if the service is somehow hacked (for example, via some sort of buffer overflow), the attacker's processes and activities will be confined to an unprivileged “padded cell” environment. It's a useful hedge against losing the patch rat race.
Chrooting and running with nonroot privileges go hand in hand. If a process runs as root, it can trivially break out of the chroot jail. Conversely, if a nonprivileged process nonetheless has access to other (even nonprivileged) parts of your filesystem, it still may be abused in unintended and unwanted ways.
Somewhat to my surprise, there doesn't seem to be any how-to for creating a Squid chroot jail on the Internet. The world could really use one—maybe I'll tackle this myself at some point. In the meantime, see Resources for some mailing-list posts that may help. Suffice it to say for now that as with any other chroot jail, Squid's must contain not only its own working directories, but also copies of system files like /etc/nsswitch.conf and shared libraries it uses.
Common Squid practice is to forego the chroot experience and to settle for running Squid partially unprivileged per its default settings. If, however, you want to run a truly hardened Squid server, it's probably worth the effort to figure out how to build and use a Squid chroot jail.
Conclusion
Setting ACLs, running Squid with nonroot privileges most or all of the time and running Squid in a chroot jail constitute the bulk of Squid's built-in security features. But, these are not the only things you can do to use Squid to enhance your network and end-user systems' security.
Next time, I'll show you how to use add-on tools such as SquidGuard to increase Squid's intelligence in how it evaluates clients' requests and servers' replies. I'll also address (if not next time then in a subsequent column) some of the finer points of proxying TLS/SSL-encrypted sessions. Until then, be safe!
Resources
Wessels, Duane: Squid: The Definitive Guide. Sebastopol, CA: O'Reilly Media, 2004. Includes some tips on creating and using a Squid chroot jail.
The Squid home page, where you can obtain the latest source code and binaries for Squid: www.squid-cache.org.
The Ubuntu Server Guide's Squid chapter: https://help.ubuntu.com/8.10/serverguide/C/squid.html.
The Squid User's Guide: www.deckle.co.za/squid-users-guide/Main_Page.
ViSolve's Squid 2.6 Configuration Manual and Comprehensive squid.conf Reference: www.visolve.com/squid/squid26/contents.php.
“The Homeless Hacker v. The New York Times”, Jennifer Kahn's article in Wired about Adrian Lamos: www.wired.com/wired/archive/12.04/hacker_pr.html.
Chris Wichura's slideshow “The Squid Caching Proxy”: www.uniforum.chi.il.us/slides/squid/UniForum-Squid.ppt.
Vivek Gite's tutorial “Howto: Squid proxy authentication using ncsa_auth helper”: www.cyberciti.biz/tips/linux-unix-squid-proxy-server-authentication.html.
Vivek Gite's Tutorial “Configure squid for LDAP authentication using squid_ldap_auth helper”: www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html.
David Bolton's “Howto: Squid + msnt_auth + Active Directory”: www.davidbolton.com/?p=32.
Paul Matthews' HOWTO “Squid with PAM Authentication and Squish Download Manager”: www.opensourcehowto.org/how-to/squid/squid-with-pam-authentication--squish-download-manager.html.
Thread from the squid-users mailing list, on what should go into a Squid chroot jail: www.squid-cache.org/mail-archive/squid-users/200609/0782.html.
Thread from the squid-users mailing list, about some of the finer points of running Squid in a chroot jail: www.squid-cache.org/mail-archive/squid-users/200811/0411.html.
Mick Bauer (darth.elmo@wiremonkeys.org) is Network Security Architect for one of the US's largest banks. He is the author of the O'Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.
Many, if not most, Squid installations don't go much beyond a few src ACLs, along with perhaps a few simple dstdomain blacklist entries thrown in for good measure. Many of the other most useful ACL types, such as myip, time, port, proto, method, dst_mime_type and rep_mime_type, should be reasonably self-explanatory (or at least easy enough to understand from the examples shown in squid.conf's comments).
One category of less-intuitive ACL types is particularly powerful and useful: the ones that enable Squid to authenticate client users via external authentication authorities. Before we tackle authentication, however, we should give a little more attention to ACL operators, the tags that perform some action (most commonly, to allow or deny a request) based on a matched ACL.
By far, the most important ACL operator is http_access, which specifies whether Squid should allow the transaction matching the specified ACL to proceed. Going back to the example ACL/operator pair from the beginning of this section, after we defined the ACL mick_network as all transactions involving client/source IP addresses within 10.0.2.0/24, we operated on it with this line:
http_access allow mick_network
This is simple enough to understand: “allow HTTP requests matching the ACL named mick_network.”
The most common use of ACLs is to specify a list of ACLs and http_access statements, ending (as we've seen) with a “drop by default” line, like this:
http_access deny all
This has the effect of creating a “whitelist”— a list of types of transactions that are allowed, with all others being denied.
Squid recognizes a number of additional ACL operators besides http_allow, including no_cache, ident_lookup_access, always_direct, never_direct and snmp_access. Because most of these concern cache performance, HTTP redirects and communications with other Squid servers rather than security per se, I'll leave it to you to explore those (or not) as your particular needs dictate. The Squid User's Guide referenced in the Resources section is a good source of information about Squid's various ACL operators.
Squid Authentication
As I mentioned previously, one of Squid's most handy capabilities is its ability to authenticate proxy users by means of a variety of external helper mechanisms. One of the simplest and probably most commonly used helper applications is ncsa_auth, a simple user name/password scheme that uses a flat file consisting of rows of user name/password hash pairs. The HOWTO by Vivek Gite and, to a lesser extent, the Squid User's Guide, explain how to set this up (see Resources).
Briefly, you'll add something like this to /etc/squid/squid.conf:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squidpasswd
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server at Wiremonkeys.org
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
And, in the ACL section:
acl ncsa_auth_users proxy_auth REQUIRED
http_access allow ncsa_auth_users
The block of auth_param tags specifies settings for a “basic” authentication mechanism:
program is the helper executable ncsa_auth, using the file /etc/squid/squidpassd as the user name/password hash list (created previously).
children, the number of concurrent authentication processes, is five.
realm, part of the string that greets users, is “Squid proxy-caching Web server at Wiremonkeys.org”.
credentialsttl, the time after authentication that a successfully authenticated client may go before being re-authenticated, is two hours.
casesensitive, which determines whether user names are case-sensitive, is off.
In the ACL section, we defined an ACL called ncsa_auth_users that says the proxy_auth mechanism (as defined in the auth_param section) should be used to authenticate specified users. Actually in this case, instead of a list of user names to authenticate, we've got the wild card REQUIRED, which expands to “all valid users”. The net effect of this ACL and its subsequent http_access statement is that only successfully authenticated users may use the proxy.
The main advantages of the NCSA mechanism are its simplicity and its reasonable amount of security (only password hashes are transmitted, not passwords proper). Its disadvantage is scalability, because it requires you to maintain a dedicated user name/password list. Besides the administrative overhead in this, it adds yet another user name/password pair your users are expected to remember and protect, which is always an exercise with diminishing returns (the greater the number of credentials users have, the less likely they'll avoid risky behaviors like writing them down, choosing easy-to-guess passwords and so forth).
Therefore, you're much better off using existing user credentials on an external LDAP server (via the ldap_auth helper) on an NT Domain or Active Directory server (via the msnt_auth helper) or the local Pluggable Authentication Modules (PAM) facility (via the pam_auth helper). See Resources for tutorials on how to set up Squid with these three helpers.
Note that Squid's helper programs are located conventionally under /usr/lib/squid. Checking this directory is a quick way to see which helpers are installed on your system, although some Linux distributions may use a different location.
Other Squid Defenses
Access Control Lists really are Squid's first line of defense—that is, Squid's primary mechanism for protecting your network, your users and the Squid server itself. There are a couple other things worth mentioning, however.
First, there's the matter of system privileges. Squid must run as root, at least while starting up, so that, among other things, it can bind to privileged TCP ports such as 80 or 443 (although by default it uses the nonprivileged port 3128). Like other mainstream server applications, however, Squid's child processes—the ones with which the outside world actually interacts—are run with lower privileges. This helps minimize the damage a compromised or hijacked Squid process can do.
By default, Squid uses the user proxy and group proxy for nonprivileged operations. If you want to change these values for effective UID and GID, they're controlled by squid.conf's cache_effective_user and cache_effective_group tags, respectively.
Squid usually keeps its parent process running as root, in case it needs to perform some privileged action after startup. Also, by default, Squid does not run in a chroot jail. To make Squid run chrooted, which also will cause it to kill the privileged parent process after startup (that is, also will cause it to run completely unprivileged after startup), you can set squid.conf's chroot tag to the path of a previously created Squid chroot jail.
If you're new to this concept, chrooting something (changing its root) confines it to a subset of your filesystem, with the effect that if the service is somehow hacked (for example, via some sort of buffer overflow), the attacker's processes and activities will be confined to an unprivileged “padded cell” environment. It's a useful hedge against losing the patch rat race.
Chrooting and running with nonroot privileges go hand in hand. If a process runs as root, it can trivially break out of the chroot jail. Conversely, if a nonprivileged process nonetheless has access to other (even nonprivileged) parts of your filesystem, it still may be abused in unintended and unwanted ways.
Somewhat to my surprise, there doesn't seem to be any how-to for creating a Squid chroot jail on the Internet. The world could really use one—maybe I'll tackle this myself at some point. In the meantime, see Resources for some mailing-list posts that may help. Suffice it to say for now that as with any other chroot jail, Squid's must contain not only its own working directories, but also copies of system files like /etc/nsswitch.conf and shared libraries it uses.
Common Squid practice is to forego the chroot experience and to settle for running Squid partially unprivileged per its default settings. If, however, you want to run a truly hardened Squid server, it's probably worth the effort to figure out how to build and use a Squid chroot jail.
Conclusion
Setting ACLs, running Squid with nonroot privileges most or all of the time and running Squid in a chroot jail constitute the bulk of Squid's built-in security features. But, these are not the only things you can do to use Squid to enhance your network and end-user systems' security.
Next time, I'll show you how to use add-on tools such as SquidGuard to increase Squid's intelligence in how it evaluates clients' requests and servers' replies. I'll also address (if not next time then in a subsequent column) some of the finer points of proxying TLS/SSL-encrypted sessions. Until then, be safe!
Resources
Wessels, Duane: Squid: The Definitive Guide. Sebastopol, CA: O'Reilly Media, 2004. Includes some tips on creating and using a Squid chroot jail.
The Squid home page, where you can obtain the latest source code and binaries for Squid: www.squid-cache.org.
The Ubuntu Server Guide's Squid chapter: https://help.ubuntu.com/8.10/serverguide/C/squid.html.
The Squid User's Guide: www.deckle.co.za/squid-users-guide/Main_Page.
ViSolve's Squid 2.6 Configuration Manual and Comprehensive squid.conf Reference: www.visolve.com/squid/squid26/contents.php.
“The Homeless Hacker v. The New York Times”, Jennifer Kahn's article in Wired about Adrian Lamos: www.wired.com/wired/archive/12.04/hacker_pr.html.
Chris Wichura's slideshow “The Squid Caching Proxy”: www.uniforum.chi.il.us/slides/squid/UniForum-Squid.ppt.
Vivek Gite's tutorial “Howto: Squid proxy authentication using ncsa_auth helper”: www.cyberciti.biz/tips/linux-unix-squid-proxy-server-authentication.html.
Vivek Gite's Tutorial “Configure squid for LDAP authentication using squid_ldap_auth helper”: www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html.
David Bolton's “Howto: Squid + msnt_auth + Active Directory”: www.davidbolton.com/?p=32.
Paul Matthews' HOWTO “Squid with PAM Authentication and Squish Download Manager”: www.opensourcehowto.org/how-to/squid/squid-with-pam-authentication--squish-download-manager.html.
Thread from the squid-users mailing list, on what should go into a Squid chroot jail: www.squid-cache.org/mail-archive/squid-users/200609/0782.html.
Thread from the squid-users mailing list, about some of the finer points of running Squid in a chroot jail: www.squid-cache.org/mail-archive/squid-users/200811/0411.html.
Mick Bauer (darth.elmo@wiremonkeys.org) is Network Security Architect for one of the US's largest banks. He is the author of the O'Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.
Taken From: Linux Journal Contents #183, July 2009
