Re: [squid-users] auto blacklist users

On Thursday 06 December 2007 22:31:06 Amos Jeffries wrote:
> > 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.

Okay. I don't meet the criterion to join (ENOTIME) but I could post as a
guest.

>
> 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.

You lost me at transaction points...

OTOH something like this...

debug(33,1) ("GREPMESTRING %s %s\n", ACLNAMEMACRO, USERNAMEMACRO);

...I can cope with.

I'm sure I could do this with the existing debug statements, but parsing a
single line is much easier than parsing multiple lines.

Like I said, I'm after a proof of concept. Way too many hats to devote the
time it would need for a good implementation.

Except for the logging the whole thing will be done 'offline'. No need then to
be fast/efficient/well written ;)

>
> 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.

That sounds useful

> 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.

Already have this. I'm logging all Internet access.

I really want access to the aclname. That way I can have differing penalty
levels. e.g. games not as serious as porn.

I don't want to modify the access log format as that might break the analysis
software I'm using.

>
> Amos

Thanks for replying

-- 
ian j hart