Rate this page del.icio.us  Digg slashdot StumbleUpon

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 http://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 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: 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:


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 http://www.microsoft.com that displays the text above.


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.

15 responses to “Using Access Control Lists in Squid (Part II)”

  1. Kelsey Hightower says:

    Good work. I have SQUID setup at home. I am using SQUID combined with IPtables to redirect all web request (port 80) to SQUID to provide web caching.

    I have now added content filtering and restrictions thanks to your tutorial.

    Thanks for the mini lesson.

  2. Joe says:

    You mentioned authentication but nothing here, what did you mean by it in your heading?

  3. Noah Gift says:

    Good catch Joe! Small error in the title. I pretty sure we can correct that. Later I might do another piece just on Squid Authentication.

  4. Noah Gift says:


    Glad I could help. Squid is FUN stuff isn’t it.

  5. Gescape says:

    Both parts are really good job and fantastic lessons.
    Thank you very much.

  6. Noah Gift says:

    Awesome. Glad you liked them. I would love to hear about cool things people are doing with Squid.

  7. joseguz says:

    I have a duda, i need to test with performance the disable access to page porn. What’s the instructions?

  8. Haakon says:

    Squid is a lot of fun. Text configuration files are too, because they can be scripted in nice and interesting ways. What might not be fun is working with several people editing the same configuration files on their watch, and forgetting to tell you what they’ve done. This is similar, and more importantly – this happens more often than forgetting what YOU changed. The answer to both problems is to NOT edit configuration files unless all of you use a revision control system. Changes are then tracked, and if something goes wrong, you will know who changed the files, when it happened, and what they did. Maybe you could write about this in part III?

  9. Noah Gift says:


    You must be reading my mind. That article is in the works…..

  10. Supriyo says:

    How can I deny browsing to a select number of client PCs based upon their IP addresses but at the same time allow other client PCs that are on the same IP network.

  11. winmyint says:

    Thanks you for your lesson..

  12. Sapanda Obinna says:

    I want to know the basic configurations in squid that will enable transparent proxy.

    I need the iptables the will redirect web access from port 80 to port 3128. My NIC connected to Internet is eth0, while my LAN is eth1 (

  13. Anil VOhra says:

    I need to cascade two proxies – each is having an independent internet feed – for load sharing. Is it possible? please elaborate.

  14. Mike Dargan says:


    I’d like to setup a squid to allow traffic only to my OPACs (library catalog stations) and a few other sites. I’m pretty sure that this can be done, but I’m stuck.

    How do I deny all access to the web, then allow access only to specific domains?



  15. red says:

    I’ve created the following but doen’t work???
    acl microsoft url_regex “/usr/share/squid/errors/English/ERR_MICROSOFT”
    deny_info ERR_MICROSOFT microsoft
    http_access deny microsoft

    Any idea please and Thanks :)