How Squid ACL works

Squid ACL Basics

Let's now dwell on how exactly ACLs work.

The Squid web proxy access control scheme consists of two different components:

• ACL entries are directive strings that begin with the word “acl” and represent the types of tests that are performed on any request transaction.
• Access list rules consist of an allow or deny action followed by a series of ACL entries and are used to specify which action or restriction should be applied to a given request. They are checked in order, and the list search stops as soon as one of the rules matches. If a rule has multiple ACL entries, it is implemented as a logical AND operation (all ACL entries of the rule must be met for the rule to be considered a match).

Acl syntax:

acl NAME TYPE DEFINITION1 DEFINITION2 DEFINITION3 ...

Examples:

acl localnet src 192.168.0.102
acl Safe_ports port 80
acl accesses_to_google dstdomain .google.com
acl accesses_to_search_engines dstdomain .yahoo.com .google.com .vivisimo.com
acl accesses_from_marketing_department src 10.52.0.0/16
acl need_to_authenticate proxy_auth

You can also use definition lists, which are stored in files on your hard drive. Let's say you have a list of search engine URLs that you want to allow:

cat /etc/squid/search-engines-urls.txt:
.google.com
.bing.com
.yandex.ru
.duckduckgo.com
.yahoo.com

Then the ACL for this file will look like this:

acl accessess_to_search_engines dstdomain "/etc/squid/search-engines-urls.txt"

The quotes are needed here to tell Squid to look for definitions in this file.

In addition to the already mentioned types src, port, dstdomain, proxy_auth, there are dozens of other types, for example:

• localip
• localport
• proto
• method
• url_regex
• arp
• browser
• http_status
• req_header
• rep_mime_type
• time
• referer_regex

For a complete list, see the squid documentation.

By themselves, acl elements do not change anything in the behavior of the proxy server, they are only lists for further use with Access List Rules. As the documentation quirky says, these tests themselves do nothing, for example, the word “Sunday” corresponds to the day of the week, but does not indicate what day of the week you are reading it.

Using ACL: http_access

If you only wrote down ACLs, then nothing is actually blocked – these are just definitions. ACLs can be used in various places in your squid.conf. The most useful function they can be paired with is the http_access instruction. It works in a similar way to how a firewall handles rules. For every request that Squid receives, it will look through all http_access statements in order until it finds a matching string. It then either accepts or rejects the request depending on your settings. The rest of the rules following the triggered one are ignored.

The general syntax for http_access is as follows:

http_access (allow|deny) acl1 acl2 acl3 ...

Examples:

http_access allow localnet
http_access allow localhost
http_access deny !Safe_ports
http_access deny all
http_access allow auth_users
http_access allow all

The next set will allow admin access (no matter what this ACL looks like; the src ACL probably points to the subnet on which the administrator workstations are located). For everyone else, it will deny access to porn urls. The third rule will allow everyone to access the websites at lunchtime (except for porn sites). And finally, in all other cases, there will be a ban on connecting to the Internet.

http_access allow accesses_from_admins
http_access deny accesses_to_porn_urls
http_access allow accesses_during_lunchtime
http_access deny all

That is, administrators have access to all sites (even porn) at any time, while other users have access to the network only during lunchtime.

Combining ACLs (AND/OR)

You often need to combine ACLs. Let's say you want to allow only back office access to google.com. To do this, you need to combine two ACLs using a logical AND. It would look like this:

http_access allow accesses_to_google.com accesses_from_back_office

If you want to use OR and say that either access from back office or access to google.com is allowed, the rule would look like this:

http_access allow accesses_to_google.com
http_access allow accesses_from_back_office

To summarize: for AND, you need to place conditions on one line. OR requires separate lines.

The following set of rules is wrong, it will never work:

acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME YOU

To allow access through a proxy to IP addresses 10.0.0.1 and 10.0.0.2, the rule must be written as follows:

acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME
http_access allow YOU

Other access list rules

Besides http_access, there are a couple of dozen other types, for example:

• http_reply_access
• icp_access
• miss_access
• cache
• url_rewrite_access

Full list in the documentation: http://www.squid-cache.org/Doc/config/

Default http_access rule

If there are no lines with “http_access” in the entire configuration file, the request is rejected by default.

If none of the “http_access” lines match, the default is the opposite of the last line in the list. If the last line was deny, the default is allow. Conversely, if the last line is allow, deny will be applied by default. Tricky, right? For these reasons, it is recommended that you have a “deny all” entry at the end of your access lists to avoid possible confusion. That is, after all the rules, just add the line:

http_access deny all

So, back to our combination of rules “blocking sites + authorization on a proxy server”, why is the following set incorrect?

http_port 4080
via off

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid Basic Authentication
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive on
auth_param basic realm Squid proxy for HackWare.ru
acl auth_users proxy_auth REQUIRED
http_access allow auth_users

acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"
http_access deny bad_urls

The fact is that first the rule that requires authorization on the server is triggered, namely “http_access allow auth_users”. All subsequent http_access directives are simply skipped, so sites are not blocked.

http_access usage mistakes

Consider the following example:

http_port 4080
via off

# Site blocking here
acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"
http_access deny bad_urls

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid Basic Authentication
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive on
auth_param basic realm Squid proxy for HackWare.ru
acl auth_users proxy_auth REQUIRED
http_access allow auth_users

The site-blocking directive moved up is the first to fire. Moreover, this happens even before authorization on the proxy.

Another variant:

http_port 4080
via off

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid Basic Authentication
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive on
auth_param basic realm Squid proxy for HackWare.ru
acl auth_users proxy_auth REQUIRED

acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"

http_access allow auth_users !bad_urls

In this case, the rule is triggered if two conditions are met: authentication and the site is not included in the blocked list. An exclamation point means logical NOT. The last option is the best, it is logically more understandable and it performs any actions (blocking the site) only after the user has entered the proxy server login and password.

See also the Squid setup guide: How to create and configure a Squid proxy server