> On Wednesday 05 December 2007 17:04:09 ian j hart wrote: >> Hello. >> >> [sorry, slightly off topic] >> >> I'm the ICT technician of a school. I have squid running to make the >> most >> of our bandwidth. Our ISP provides some content blocking but this is >> proving ineffective against the proliferation of proxy sites. >> >> I've started to monitor and block sites with squid ACLs. This is also >> not >> so effective as there are 1200 users looking for new sites and only 1 >> user >> trying to block them. >> >> Since there is no punishment for hitting any DENY ACL there's no reason >> for them to stop. >> >> What I need is to apply some back pressure, i.e. automatically block >> persistant offenders. >> >> Does anyone have anything like this? >> >> N.B. This has to be user based. Host/IP based will not work due to the >> hot seating. >> >> Thanks > > Okay, plan B it is then. > > I'll try and run up a proof of concept implementation so I can see if it > has > the desired affect on the users. > > The minimum info I need is the aclname and user for each deny match. Other > stuff may be useful later (e.g. url). > > Debug statements should be okay. I'll just parse the cache.log. > > What I need help with is where to put the code. > > clientAccessCheckDone looked promising but seems to be called several > times > i.e. proxy auth, blocked url, error page > > Somewhere near the error page generation should be about right. > > Can someone who knows the code lend me their clue stick. If you want to code it. Woudl be better to take it to squid-dev mailinig list. There are more dev helpers there than here. In general: each of those calls to check ACL are done at the transaction points wherehttp_access, http2_access, https_access, deny_info, http_reply_access if configure to be checked. On a one-*_acess to one-call basis. It's just a matter to figuring which *_access is best to use and finding its ACL test. That said. I don't think you should need to code it into squid. The external_acl mechanism can handle real-time blocking based on some external database lookup. From 2.6s17 the logdaemon now allows an external script to get access_log data piped to it for parsing the HIT/MISS/DENIED. Based on that all you have to do is an auth ACL 'required' which will add the username to the access log lines. Amos
