I have to say up front that it is obvious that you've put a lot of
time and effort into configuring squidGuard; nice work!
I'll also tell you up front that I don't know why ac.uk is being
blocked. I will, however, make a few observations and ask a few
questions and the process may ultimately lead you to an answer.
You are using both users and ips to identify your source groups. I
just want to remind you that squidGuard will assign the source group
based on the first match. Let's look at the first 3 source groups as
an example (some formatting removed):
src sysops userlist /etc/squid/allaccess
src netmgrall iplist /usr/squidGuard/db/list/adminip
src banuser userlist /etc/squid/banedusers
- The users listed in /etc/squid/allaccess will be treated as source
'sysops', without regard to which workstation they are using.
- Anyone (other than user 'sysops') that is using a workstation whose
ip is listed in /usr/squidGuard/db/list/adminip will be treated as
source 'netmgrall', without regard to their userid, including those
listed in /etc/squid/banedusers.
Source r103tl will be handled by the default acl, since it is not
specifically listed in an acl of its own.
Are you *regularly* checking the content of squidGuard.log?
You have 4 acls that end with 'none'. Three of those acls (r66arsc,
curric, and sxfms) resemble this one (some formatting removed):
sxfms pass
!expres
local
sxfmd
goodsites
!gamenexe
!reroute
!mails
!oursites
!porn
!warez
!violence
!gambling
!hacking
!drugs
!aggressive
!ads
none
I would normally suggest this be rewritten as simply:
sxfms pass
local
sxfmd
goodsites
none
I don't think the long version is a problem (other than taking longer
to process), but it is a lot easier to understand the intent of the
short version.
You have 11 destination groups that contain expressionlists, and I
think you are going to give yourself nightmares with those. I can't
understand how you could need all of those expressions? Take the
destination group 'oursites' - do you really need an expression list
for that group? Are all of 'oursites' known? If so, put them in
domains and urls files. Much faster to process and less room for
error.
Expressionlists are used as wildcards, built to match certain
patterns that always mean the same thing every time you see them. For
example, you can feel comfortable about an expressionlist that
matches '/ads/' and redirects the request to a transparent 1x1.gif.
There is an expressionlist in your 'goodsites' destination group.
I can't think of a single pattern that would always mean 'goodsite',
no matter where it shows up. (Any pattern that would qualify as a
domain or a url would of course be placed in the domains or urls
file.) And since squidGuard only looks for the first match, as soon
as the request matches 'goodsites', the approval is returned to
squid.
I'd also like to suggest a structured approach to your squidGuard
config file. The situation that you find yourself in today does not
have to happen; it should be relatively easy to determine the exact
reason a site was blocked. It may be possible to wing it without
structure on a small configuration, but not on a large one like yours:
39 source groups
19 Destination groups
17 domain lists
12 url lists
11 expression lists
18 destination groups w/log stmts
6 destination groups w/redirection stmts
39 acl stmts (including default)
38 acl stmts w/ redirection stmts
0 acl stmts w/ log stmts
Here's the structure that I propose:
- Include a unique redirect and log statement in every destination
group (you're almost there with the log statements). If you can't
redirect to the squidGuard.cgi page, you can at least build a
different html page for each redirect. The pages can look the same,
if you'd like, but they would have a different name and title (so
you can ask the user what it says in the title bar). With a redirect
and log statement in each destination group, all blocks made in that
group will be in the same log file, and the redirect page indicates
which group caused the redirection. (An exception is the ads dest
group, which should be redirected to 1X1.gif.)
- Remove the redirects from all of the acls that end in 'all'
(or 'any'). Any blocks that occur in those acls will have been caused
by a destination group, and the logging and redirection is specified
within the destination group.
- Ignoring the default acl for a moment, the acls that end in 'none'
(or '!any') should contain both redirect and log statements. These
acls add the possibility of blocking due to the absence of an
approval, and require the additional redirect and log to maintain
the structure. To say that another way: If you are blocked while
trying to visit a domain that is listed in the porn group, it stands
to reason that you will be redirected and logged out of the porn
group. But if you are blocked because you are only allowed access
to 'goodsites' (and you're trying to go somewhere else), you'll be
redirected and logged in this acl.
- I like the default acl with pass none, and a special redirect,
I'd just add a log statement there so that everyone that gets
redirected there gets logged there.
Finally, don't overlook the possibility that squidGuard may have
assigned a user to a different source group than you expected. That's
easy enough to trace, however. You mentioned earlier that requests
were being logged to the proxy log. If you'll look at Squid's
access.log you'll see the ip address and user ident that squid sent
to squidGuard with the request. If it was blocked by squidGuard you'll
find the ip, ident, source group and destination group that squidGuard
used in deciding to block.
I hope you find this information useful.
Rick Matthews
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Thursday, September 19, 2002 9:21 AM
> To: [EMAIL PROTECTED]
> Subject: RE: two letter domains???
>
>
> the src group is called
>
> sxfms
>
> and the destinations that should pass normaly are
>
> 6fmd and goodsites
>
> the ac.uk is in both of these, and the other domains in them work fine.
>
> the first !expres blocks some stuff but would be log them and no logs are
> being generated for calls to ac.uk although they do show in the proxy log.
>
> Rob
>
>
>
>
>
> At 09:13 19/09/02 -0500, you wrote:
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > Sent: Thursday, September 19, 2002 7:27 AM
> > >
> > > I have just noticed this but if I have a domain in a domain list
> > > of ac.uk ( UK academic ) it does not seem to work.
> > >
> > > We are using it to allow restricted users access to university web
> > > sites, but it is not working.
> > >
> > > Anyone have any Ideas?
> >
> >I have xx.tf in my porn list and it works just fine.
> >
> >Perhaps you could send up your squidGuard.conf file and let us have
> >a look?
> >
> >Rick
>
