Re: [squid-users] auto blacklist users

> 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
Received on Thu Dec 06 2007 - 15:31:11 MST