At 22:40 19/09/02 -0500, you wrote: >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!
We have been using SG for 2 years with good results and squid for 4 years. I don't have a great deal of time to play with it so it's usually when there is a problem. >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. Looked like it was a strange anomaly in the list file for the DB. >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 Sysops - Have full access across campus regardless of workstation Netmgrall - Our two management workstations that sometimes don't have ident server running baneuser - All the little muppits that have got them selfs baned from using the internet. >Source r103tl will be handled by the default acl, since it is not >specifically listed in an acl of its own. That's an out of date src that will be removed. >Are you *regularly* checking the content of squidGuard.log? Reasonably considering it's general stability. Check it often when changes are made. >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 That is so that I can change the access just by replacing none with all, and maintaining the general blocking. >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. Some of the expression lists are quite small, most of them a tailored so that the logging and blocking is related to the particular type of offence. >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. Sussex, essex, wessex, cumbria etc would all get blocked by oursites expression sex and cum if we did not allow them through first. It's not ideal but otherwise a search for cumbrian lakeland walks would be blocked. >- 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. How do I log the default? >Finally, don't overlook the possibility that squidGuard may have >assigned a user to a different source group than you expected. The user name is only used in the sysops src group, if a user has no ident then they get blocked. ... Thanks for the ideas, Once time allows I will have to get back to getting it more streamlined. At least it seems to be fixed, and it was not a fault with my logic. Can't understand why the file was corrupt though. Regards Robin.
