On Friday 07 December 2007 00:41:30 Amos Jeffries wrote:
> > 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 ****.
bypass over zealous filters!
>
> Okay, well in that case, and after a little more thought. I think the best
> option for you might be to code up an external helper.
> And configure like this:
>
> acl XblockACL dstdomain X
> acl XlogACL external ...
> http_access deny XblockACL XlogACL
>
> The XlogACL accepts %LOGIN and %ACL, and the 'acl' marks that user against
> the name it gets given and replies 'OK' to not override the deny/allow
> results from XblockACL.
>
> I'm not certain if the %ACL received by the helper is "XlogACL" or
> "XblockACL".
> - if its the latter you will only need one logACL
> - if its the formar you will need one XlogACL, YlogACL for each level.
>
> HTH
> Amos
>
> > I don't want to modify the access log format as that might break the
> > analysis
> > software I'm using.
>
> Amos
You're making my head hurt again. This is still way too complex at this stage.
Let me try and explain. One of the things teachers have to do is to keep
pupils "on task". Naturally some pupils would rather be playing games/on
facebook/WHY.
Managers tend to think that technology is the silver bullet, so here I am.
Even if we had a perfect filtering system, visiting a set of access denied
pages is not "on task". I've watched a pupil try a list of denied sites one
after the other - they can be focused when they want to be.
So, we need to _convince_ pupils to "behave".
And we don't need perfect filtering for this. It just needs to be sufficiently
dangerous to discourage random browsing, like minesweeper.
What I need to know is; Is a "two strikes and you're out" type threat
sufficient to ensure good behavior (in the majority at least)?
There's no point in spending six months coding something up only to find out
it doesn't work. So it's more about the psychology than the coding at this
stage.
Thanks for your ideas tho'. If I get past the POC stage I'll certainly revisit
them.
--
ian j hart
