Basic Configuration of squidGuard

Once SquidGuard is successfully installed, you want to configure the software according to your needs. A sample configuration has been installed in the default directory /usr/local/squidGuard (or whatever directory you pointed your installation to). Below you find three examples for the basic configuration of SquidGuard. 1. Most simple configuration
Most simple config uration: one category, one rule for all # # CONFIG FILE FOR SQUIDGUARD # dbhome /usr/local/squidGuard/db logdir /usr/local/squidGuard/logs dest porn { domainlist porn/domains urllist porn/urls } acl { default { pass !porn all redirect http://localhost/block.html } }

2. Make always sure that the very first line of your squidGuard.conf is not empty! The entries have the following meaning:
dbhome logdir dest

Location of the blacklists Location of the logfiles Definition of a category to block. You can enter the domain and url file along with a regular expression list (talk about regular expressions later on). The actual blocking defintion. In our example only the default is displayed. You can have more than one acl in place. The category porn you defined in dest is blocked by the expression !porn. You have to add the identifier all after the blocklist or your users will not be able to surf anyway. The redirect directive is madatory! You must tell SquidGuard which page to display instead of the blocked one.

acl

3. 4. Choosing more than one category to block First you define your categories. Just like you did above for porn. For example:
Defining three categories for blocking dest adv { domainlist adv/domains urllist adv/urls } dest porn { domainlist porn/domains urllist porn/urls } dest warez { domainlist warez/domains urllist warez/urls }

5. Now your acl looks like that:

acl { default { pass !adv !porn !warez all redirect http://localhost/block.html } }

6. 7. Whitelisting Sometimes there is a demand to allow specific URLs and domains although they are part of the blocklists for a good reason. In this case you want to whitelist these domains and URLs.
Defining a whitelist

dest white { domainlist urllist } acl {

white/domains white/urls

default { pass white !adv !porn !warez all redirect http://localhost/block.html } }

8. In this example we assumed that your whitelists are located in a directory called white whithin the blacklist directory you specified with dbhome. Make sure that your white identifier is the first in the row of the pass directive. It must not have an exclamation mark in front (otherwise all entries belonging to white will be blocked, too). 9. Initializing the blacklists Before you start up your squidGuard you should initialize the blacklists i.e. convert them from the textfiles to db files. Using the db format will speed up the checking and blocking. The initialization is performed by the following command:
Initializing the b lacklists squidGuard -C all chown -R <squiduser> /usr/local/squidGuard/db/*

10. The second command ensures that your squid is able to access the blacklists. Please for <squiduser> the uid of your squid. Depending on the size of your blacklists and the power of your computer this may take a while. If anything is running fine you should see something like the following output in your logfile:
2006-01-29 12:16:14 [31977] squidGuard 1.2.0p2 started (1138533256.959) 2006-01-29 12:16:14 [31977] db update done 2006-01-29 12:16:14 [31977] squidGuard stopped (1138533374.571)

11. If you look into the directories holding the files domains and urls you see that additional files have been created: domains.db and urls.db. These new files must

not be empty! Only those files are converted you specified to block or whitelist in your squidGuard.conf file.

Verification of your squidGuard Configuration

Now that you have installed and configured your squidGuard you just check a couple of things before going online. 1. Permissions Ensure that the blacklist and db files belong to your squid user. If squid cannot access (or modify) them blocking will not work.

2. SquidGuard dry-run To verify that your configuration is working run the following command (changed to reflect your configuration):
Dry-run squidGuard echo "http://www.example.com 10.0.0.1/ - - GET" | squidGuard -c /tmp/test.cfg -d

3. If the redirector works properly you should see the redirection URL for the blocked site. For sites not being part of your blacklists the output should end with:
2007-03-25 16:18:05 [30042] squidGuard ready for requests (1174832285.085) 2007-03-25 16:18:05 [30042] squidGuard stopped (1174832285.089)

4. Some remarks about the different entries of the echoed line:

o o

The first entry is the URL you want to test. The second entry is the client IP address. If you configured access control based on IP addresses make sure to test allowed and not allowed IP addresses to ensure proper working. In the third entry (the first - ) you can specify a username. This is only of

importance if you have access control based on user names. Make sure to check different names with different access to verify your configuration.

Finalizing the installation by configuring squid If everything is working properly add the following line to your squid.conf (assuming that your squidGuard is installed in /usr/local; make sure to change the paths to match your installation accordingly):
url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf

Extended Configuration of SquidGuard

There are several more options to configure SquidGuard according to your needs. Not allowing IP adresses Rules based on source IP adresses Regular Expressions Blocking against dns based blacklists Not allowing IP adresses To make sure that people don't bypass the URL filter by simply using the IP addresses instead of the fully qualified domain names, you can add the !in-addr following to your acl:
Disallowing access to IP addresses acl { default { pass !in-addr all redirect http://localhost/block.html } }

Times Logging blocked access tries Authentication

Blocking against dns based blacklists Attention: This feature requires squidGuard 1.5 or later or the dnsbl patch for squidGuard 1.4 provided by INL - http://www.inl.fr/. If you want to use external dns based blacklists such as black.uribl.com for blocking you can use !dnsbl to dynamically check domain names against such services:

Using external dns based blacklists acl { default { pass !dnsbl:your.preferred.blacklist.domain.com all redirect http://localhost/block.html } }

If you use !dnsbl without specifying a domain, black.uribl.com is used as default. Be aware that this will raise several DNS requests every time squidGuard receives a request to filter. SquidGuard will not cache any DNS result, so make sure your DNS server does, and measure the performance impact before using this feature in production. Blocking based on times There are two ways to define times and dates where access to websites are allowed or disallowed. The weekly directive is used for reoccuring access time, f.e. allowing web access to blocked sites after work. Using the date directive you can additionally define special days where access may be granted. Wildcards can be used.
Defining access times time afterwork { weekly * 17:00-24:00 weekly fridays 16:00-17:00 earlier date *.01.01 date *.12.24 12:00-24:00 date 2006.04.14-2006.04.17 date 2006.05.01 }

# After work # On friday we close # # # # New Year's Day Christmas Eve Easter 2006 Maifeiertag

To apply the defined times you can use the qualifiers within and outside , respectively. Now your acl looks like that:
acl { all within afterwork { pass all } else { pass !adv !porn !warez all } default { pass none redirect http://localhost/block.html } }

This means that for everyone free access to web sites is possible during the times defines in afterwork. Outsite these times people cannot access whatever is defined in adv, porn and warez. Rules based on source IP adresses If you have policies in place granting some people access to more sites than others you have different options how to implement this policy. One way is to define source IP acls. This can only work if your user groups are well separated within your network. Assuming that this is the case you can now define the source IP ranges in your squidGuard.conf the following way:
Defining source IP addresses src admins { ip 192.168.2.0-192.168.2.255 ip 172.16.12.0/255.255.255.0 ip 10.5.3.1/28 }

You can secify IP addresses directly as well as defining IP ranges using a from-to notation, defining the netmask or use the netmask prefix abbreviation. Annotation: If you have many network definitions for a user group you can put that info into a separate file and just tell your squidGuard.conf about the location of the file. In this case you write in your squidGuard.conf:
src admins { iplist } adminlist

SquidGuard will look for a file called adminlist located wherever you pointed your dbhome directive to. Alternatively you can specify an absolute path with your filename. The file itself holds the information in the following style:
192.168.2.0-192.168.2.255 172.16.12.0/255.255.255.0 10.5.3.1/28

Logging blocked access tries It may be of interest who is accessing blocked sites. To track that down you can add a log directive to your src or dest definitions in your squidGuard.conf. If only a file name is given, the file is search in the directory specified in the logdir directive.

Logging blocked access tries dest porn { domainlist porn/domains urllist porn/urls log pornaccesses }