Using Access Control Lists in Squid (Part II)

Now that everyone has mastered the basics of Squid, we are ready to have a little more fun. In case you missed it, we published Part I of this series recently.

Access Control Lists (ACLs) allow Squid to do many interesting things in addition to just providing a caching proxy server. A properly configured set of ACLs can do things like:

• restrict access to websites by IP address,
• limit or block websites by name, such as www.badsite4kids.com2,
• restrict web access by time and day, or
• regular expression matches, such as .exe files or “porn” in URL names.

You can additionally add custom html error messages that let your users or children know why they have been blocked from the web.

I neglected to mention the cost for these services, as many commercial software programs provide these features too. It is free, you just need to configure it yourself. How’s that for some motivation to learn a little more advanced Squid?

Edit and test (iterative work style)

Now that you’re an old hand at Squid, we can move into a more advanced style of working. Most seasoned systems administrators will tell you, “make one small change, test it, then make another small change…” This is great advice, as large systematic changes to configuration files are a surefire way to forget what you did, cause problems and generally cause you to pull your hair out.

Here is the sequence of events you will use for this project:

1. Edit squid configuration file.
2. Make one configuration change and save.
3. Restart the squid service.
4. Refresh the web browser to test the changes.
5. Look at your running tail -f of the squid log file.

Preparing your workspace

To get started, open three shells and one browser to make interactive work much easier. Do as follows:

in shell A: Edit /etc/squid/squid.conf (Use your favorite text editor. Remember to back up your original configuration file!)

in shell B: Tail the squid log:
tail -f /var/log/squid/access.log

in shell C: Prepare a squid restart command:
service squid restart

in the browser window: Open up a browser that you will refresh after each change.

All four windows should fit neatly in on one screen or virtual desktop in a square pattern.

Adding time ACLs

If you are continuing from part 1 of this series, then please go to the open squid configuration file in shell A (remember you opened a shell just for editing /etc/squid/squid.conf) and go to lines

acl intranet 192.168.0.0/24rnhttp_access allow intranet

[Reminder: http_access deny all should always be placed at the very bottom of any http_access statements. ACLs are matched in a descending order, so multiple layers of ACLs can cascade downward.]

Let’s block all Internet access during the school week after 8:00 p.m. by adding this line right underneath acl intranet and then appending schoolweek after intranet

#allow web access during the school week only between 3PM and 4PMrnacl schoolweek time MTWHF 16:00-9:00

When you done the section should look like this:

#allow web access during the school week only between 3PM and 4PMrnacl schoolweek time MTWHF 15:00-16:00rnhttp_access allow intranet schoolweekrnhttp_access deny all

Remember the iterative testing style described above? Let’s use it to test this new configuration.

1. In shell C (The shell with the squid restart command ready), execute:
   service squid restart
2. Then, in shell B (The shell with the tail -f running) watch the log file closely.
3. In the browser, attempt to navigate to a new website like this one after squid has restarted.
4. Watch the log for shell B. You should see something like this:

192.168.0.108 TCP_DENIED/403 1341 GET http://www.redhatmagazine.com/ - NONE/- text/html

As you can see, this is very powerful. If one of these steps did not work, it is probably because of a typo. Go back to the configuration file take out the section you added and repeat the steps again. You should get back to the normal configuration you started with. This is why an iterative work style is so important.

Sophisticated pattern-matching ACLs

From now on, I will assume you will follow the iterative testing style, as you can see the benefits. It also saves room in the article for more fun stuff. Let’s block websites by pattern matching! In order to do this, we will use a regular expression syntax within the configuration file. Understanding regular expressions can require several books and years of practice, but we will use a very simple syntax and save you that trouble for a later time.

Go to same section of the configuration file again and add this line and a deny statement as show below, making sure you remove the previous ACL unless it is exactly between 3:00 and 4:00 p.m. where you are, as the web will be blocked:

#blocking all URLs from Microsoft until they publish patent allegationsrnurl_regex microsoft url regex -i microsoftrnhttp_access deny microsoftrnhttp_access allow intranet rnhttp_access deny all

If you go through the iterative testing steps, you should see that you just blocked all URL traffic to URLs that match “microsoft.” Doesn’t that feel great! I doubt they will buckle under the pressure of one squid proxy configuration, but every bit counts against the bogus patent violations. Do your part the Linux way; block them with squid ACLs!

Now you can create custom ACLs, as hopefully I have explained things well enough that you understand how to mix and match cascading rules, such as regular expression matches and time restrictions, etc. Let’s move to the last section now, for our last neat trick.

Creating a custom error message

Now that you have mastered ACLs, let’s focus on the error messages that squid gives when a website is blocked. It would be very handy if you could associate custom error messages for each ACL. Well you can. All that is needed is to create an HTML file with custom text, place it in squid’s error directory, and make sure that the squid configuration file knows about it:

cd /usr/share/squid/errors/English or your native language

Inside this directory you will see quite a few files starting with ERR_

Let’s create another one called ERR_MICROSOFT by opening up your favorite text editor and pasting this in:

<title>RESTRICTED</title>
<div>
<big><big><big><big>YOU HAVE BEEN BLOCKED!  YOUR PATENTS ARE BOGUS!</big></big></big></big>
</div>

Save it. And edit your configuration file to tell it about the new error message. Do a keyword search for this line:

Usage:   deny_info err_page_name acl

This should get you to the custom error section. Put this line into that section:

deny_info ERR_MICROSOFT microsoft

Now do all of the normal things again; restart the service, etc. You should see a bright red page when you attempt to go to www.microsoft.com that displays the text above.

Summary

You’re now a Squid master-in-training. I also hope you continue to use the iterative configuration testing technique in the future for other projects. Let me know of any fancy configuration options that you have come up with, as I hope I have shown you enough to really do something interesting.

This entry was posted by Noah Gift on Tuesday, June 19th, 2007 at 2:03 pm and is filed under technical. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.