Mike wrote:
>
> I am using squidGuard via the SuSE 9.1 RPMS. SquidGuard has worked
> well for me for many years. But after many years of using the
> default installation, I need to allow a URL to be passed even
> though the overall domain is blocked elsewhere in the blacklists
> (blacklist/mail/domains, there is a line "geocities.com")
>
> I want to allow a specific site within geocities.com, so I create
> a new subdirectory of blacklist "ok" and within that subdirectory
> I have a file "urls" with contents of
> "www.geocities.com/pinball_jack". I create the .db files.
Leave off the 'www.'; squidGuard ignores those. Did you set the
ownership and permissions of the new directory and files?
> My squidGuard.conf file has:
>
> dest ok {
> domainlist blacklist/ok/domains
> urllist blacklist/ok/urls
> }
>
> acl {
> protect {
> pass ok !ads !aggressive !audio-video !drugs !gambling
> !hacking !mail !porn !proxy !violence !warez all
> redirect http://woot.com/blocked.html
> }
>
> default {
> pass none
> }
> }
Your default acl will not do what you have asked it to do because it
does not contain a redirect statement.
> To test it, I use the following command: echo
> "http://www.geocities.com/pinball_jack 192.168.0.25/- - GET"
> | /usr/sbin/squidGuard -c /etc/squidguard.conf -d
Did you use this method of testing (rather than firing up a browser)
because this is on a test system?
You only included a portion of your squidGuard.conf file; is ip
192.168.0.25 defined as a member of source group 'protect'?
> and get the output of all the databases that are loaded, followed
> by the redirect to woot.com/blocked.com.
>
> You may notice that the "ok" destination has a domain list. In
> that list, I allow access to the discovery.com domain (it is
> blocked elsewhere in the downloaded blacklists). That override
> works properly and discovery.com URLs are not blocked.
>
> I have been looking for information or a way to get squidGuard to
> output useful trace information to show me why it doesn't pass the
> geocities site, but have found nothing.
What information are you getting in your squidGuard.log file?
[Verify that you do have a squidGuard.log file that contains current
information. squidGuard will write 50+ lines to its log file every
time it is (re)started. If you do not find this to be true with
your squidGuard.log file it is because squidGuard cannot find and/or
write to the location you specified.]
The best tool that I have found for squidGuard debugging is the
addition of a blocked.log file. Create a 'blocked.log' file in the
same directory as your squidGuard.log file, and give it the same
ownership and permissions as squidGuard.log.
Copy your redirect into each of your destination groups, and add a
log statement:
dest porn {
domainlist blacklist/porn/domains
urllist blacklist/porn/urls
redirect http://woot.com/blocked.html
log blocked.log
}
Make these additions to every destination group. (For complete
coverage, you'll also need to add the log statement to your default
acl, along with the missing redirect statement.)
Bounce Squid, and squidGuard will start writing an entry to blocked.log
every time he redirects a transaction. Here's an example of the
blocked log file content (this is a one-line log entry expanded and
explained):
Fields:
date & time 2003-01-27 12:29:48
pid [23647]
action (?) Request
source/dest/rewr (gameroom/porn/-)
Requested url http://www.playboy.com
ip of requestor 192.168.44.4/
ident or '-' bryan
GET, CONNECT, etc. GET
Many times the content of this file is all that I need to determine
why squidGuard handled a transaction the way that it did. If more
information is needed you can look at squid's access.log to see what
squid is sending to squidGuard. (One exception, ident information
shown in squid's access.log will not be reliably sent to squidGuard
unless squid.conf contains ident REQUIRED. See the bottom of this
page: http://www.squid-cache.org/Doc/FAQ/FAQ-15.html )
Hope this helps!
Rick Matthews
