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
