[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [fw-wiz] Firewalling at the domain users level instead of network level



Oh yeah, and calamaris for parsing the resulting squid logfiles :)


On Wed, 2004-07-21 at 16:34, charlie wrote:
> Hi,
> 
> Have you looked into using iptables + squid + squidguard for transparent
> proxying, content filtering and access control?
> This combination is very effective and extremely flexible. You can limit
> access by time, source ip, destination url/ip etc.
> 
> Check out www.squidguard.org
> 
> Hope this helps..
> 
> regards
> charlie
> 
> On Wed, 2004-07-21 at 14:34, Daniel Pittman wrote:
> > On 21 Jul 2004, Santos wrote:
> > > Chuck Swiger wrote:
> > >> On Jul 18, 2004, at 2:41 AM, Santos wrote:
> > 
> > [...]
> > 
> > >> The second concern is a matter of policy: why do you want your
> > >> firewall to treat users differently?  If it's a bad idea for person A
> > >> to do some type of network connection, why should it be OK for person
> > >> B to do so?  If you restrict things so that only the services which
> > >> you trust all users to do are permitted, your security is likely to be
> > >> much improved compared to a policy based on an ever-growing pile of
> > >> per-user rules and exceptions.
> > >
> > > Because the people that contracted me wanted so :)  
> > 
> > That was my presumption when I read this thread; it isn't a techies
> > idea, generally.
> > 
> > > Some people should be working on other stuff instead of traveling on
> > > the web.
> > 
> > >From my years of experience, I would advise that you go back to your
> > client and suggest to them, gently but firmly, that trying to apply a
> > technical solution to a social problem is seldom effective.
> > 
> > 
> > Before I go into detail there, though, do you actually need the
> > 'hotseat' functionality that you are looking for, or would it be enough
> > to put the "unprivileged" users in a fixed IP range with DHCP, and then
> > firewall that more strongly?
> > 
> > 
> > Anyway, back to the reasons why solving the abuse problem through
> > firewall restrictions is a poor idea:
> > 
> > The biggest reason is that drawing this distinction between users is a
> > great way to encourage resentment and unhappiness among staff.
> > 
> > By drawing that line your clients are saying "these people are important
> > enough to flout the rules, those people are not" -- because having some
> > staff able to surf the web at leisure implies precisely that.
> > 
> > 
> > The other big reason is that the analysis that reaches the conclusion
> > that some staff are abusing the Internet access is often flawed[1] in my
> > experience.
> > 
> > When I have been asked to implement this, which has happened at a number
> > of places, it usually turns out that access to the Internet is a
> > critical part of the day to day operation of that part of the
> > organization.
> > 
> > The most common requirements are data verification and queries about
> > addressing, phone numbers and postage data -- and these are not things
> > that the management are usually aware are required as part of the job.
> > 
> > 
> > Finally, once you start telling people that they are going to do the
> > wrong thing -- which this technical rules does tell them -- they are
> > less likely to want to do the right thing in other areas.
> > 
> > 
> > A more concrete and effective way of curbing the abuse of Internet
> > access is to announce, *very* publicly, that Internet use will be
> > monitored, and randomly sampled for compliance to policy.
> > 
> > Then, give it two weeks and implement that: pick a half hour chunk of
> > Squid logs *outside* of lunch breaks, and find out which of the staff
> > are silly enough to still abuse their access.
> > 
> > That requires minimal technical input, does not lead to any "unfair"
> > rules at a technical level[2], and gives people the feeling that
> > management and the technical staff expect them to do the right thing,
> > not the wrong thing.
> > 
> > 
> > So, in summary: there are probably much better ways of doing this.
> > 
> >     Daniel
> > 
> > 
> > Footnotes: 
> > [1]  Well, actually, uniformly incorrect, and reflective of a poor
> >      understanding of what is actually done by staff, but I still
> >      hesitate to make it an absolute statement.
> > 
> > [2]  This is extremely important if you don't want to find that all the
> >      staff hate you for implementing (or colluding with) this unfair
> >      system.[3]
> > 
> > [3]  ...and, yes, the "random sample" thing is the same technical
> >      effect, but perceived quite differently as a general rule -- not
> >      least of which is because it can be checked by a more clever
> >      human, not a blind and uncaring machine.
> > -- 
> > Any attempt to curb user abuse will only result in more expensive abuse.
> >         -- Garret Boer
> -- 
> ============================
> Charles Kidson
> Systems Administrator
> General Pants Group
> charlesk@generalpants.com.au
> ph 02 9290 0813
> fx 02 9299 6485
> mb 0428 61 7766
> ============================
-- 
============================
Charles Kidson
Systems Administrator
General Pants Group
charlesk@generalpants.com.au
ph 02 9290 0813
fx 02 9299 6485
mb 0428 61 7766
============================




Reply to: