                                 SquidGuard

   [1]HOME [2]Downloads [3]Documentation [4]Development [5]Blacklists
   [6]Contributions [7]Contact

  Extended Configuration of SquidGuard

   There are several more options to configure SquidGuard according to
   your needs.

   [8]Not allowing IP adresses               [9]Times
   [10]Rules based on source IP adresses     [11]Logging blocked access tries
   [12]Regular Expressions                   [13]Authentication
   [14]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
        }
 }

     Blocking against dns based blacklists
   Attention: This feature requires squidGuard 1.5 or later or the
   [15]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            # After work
  weekly   fridays 16:00-17:00      # On friday we close earlier
  date   *.01.01                    # New Year's Day
  date   *.12.24 12:00-24:00        # Christmas Eve
  date   2006.04.14-2006.04.17      # Easter 2006
  date   2006.05.01                 # 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
}

   [16]Documentation
     __________________________________________________________________

   [17]Installation
     __________________________________________________________________

   Configuration
    [18]Getting started
    Destination ACLs
    [19]Source ACLs
    [20]Redirect Rule
    [21]Time Constraints
    [22]Authentication
    [23]Regular Expressions
    [24]Examples
     __________________________________________________________________

   [25]Runtime Options
     __________________________________________________________________

   [26]About blocking
     __________________________________________________________________

   [27]Troubleshooting
     __________________________________________________________________

   [28]Known Issues
     __________________________________________________________________

   [29]Other Sources
     __________________________________________________________________
   _______________________________________________________________________

     (c) Powered by [30]Shalla Secure Services KG 2007-2010

References

   1. http://www.squidguard.org/index.html
   2. http://www.squidguard.org/download.html
   3. http://www.squidguard.org/Doc/
   4. http://www.squidguard.org/Devel/
   5. http://www.squidguard.org/blacklists.html
   6. http://www.squidguard.org/Contrib/
   7. http://www.squidguard.org/impressum.html
   8. http://www.squidguard.org/Doc/extended.html#notIP
   9. http://www.squidguard.org/Doc/extended.html#times
  10. http://www.squidguard.org/Doc/extended.html#sourceIP
  11. http://www.squidguard.org/Doc/extended.html#blocklog
  12. http://www.squidguard.org/Doc/expressionlist.html
  13. http://www.squidguard.org/Doc/authentication.html
  14. http://www.squidguard.org/Doc/extended.html#dnsbl
  15. http://www.squidguard.org/Downloads/Contrib/squidGuard-1.4-dnsbl.patch
  16. http://www.squidguard.org/Doc/index.html
  17. http://www.squidguard.org/Doc/install.html
  18. http://www.squidguard.org/Doc/configure.html
  19. http://www.squidguard.org/Doc/sourceacl.html
  20. http://www.squidguard.org/Doc/redirect.html
  21. http://www.squidguard.org/Doc/extended.html#times
  22. http://www.squidguard.org/Doc/authentication.html
  23. http://www.squidguard.org/Doc/expressionlist.html
  24. http://www.squidguard.org/Doc/examples.html
  25. http://www.squidguard.org/Doc/runtimeops.html
  26. http://www.squidguard.org/Doc/aboutblocking.html
  27. http://www.squidguard.org/Doc/troubleshoot.html
  28. http://www.squidguard.org/Doc/known_issues.html
  29. http://www.squidguard.org/Doc/other_sources.html
  30. http://www.shalla.de/
