Paranoid Penguin - Building a Secure Squid Web Proxy, Part III
We've been building a secure Squid Web Proxy the past few months, and we'll continue to do so for a couple more. Last time [May 2009], we got Squid installed, running and restricted to serve only local clients (based on their IP addresses). This month, we delve deeper into Squid's Access Control List (ACL) capabilities and other built-in security features.
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.
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
|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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
9 hours 16 min ago
- BASH script to log IPs on public web server
13 hours 43 min ago
17 hours 19 min ago
- Reply to comment | Linux Journal
17 hours 51 min ago
- All the articles you talked
20 hours 15 min ago
- All the articles you talked
20 hours 18 min ago
- All the articles you talked
20 hours 19 min ago
1 day 44 min ago
- Keeping track of IP address
1 day 2 hours ago
- Roll your own dynamic dns
1 day 7 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?