[sclug] Personalised web content filtering

[Neil Haughton]

Thanks to evertyone for the comprehensive replies. I hasten to add that
although I am not entirely comfortable with the HR issues at stake, I can
see that allowing 'untrusted' people access to the source code is a big risk
to the business, and yet unavoidable (we have to have developers working on
the code, and from time to time have to recruit new developers). So my
employers have to mitigate the risks as best they can, although everyone is
aware that absolute prevention is impossible - they can only (hopefully)
make it sufficiently hard to be not worth it, and remain vigilant.

So far it looks like Squid sounds a good way to go, so I'll be looking at at
that. The 'prior approval' approach probably won't be practical. I shall
push for people not to have administrator rights by default, as we hardly
need them, so that should mean that lock down can be a  bit more secure (and
there will be other benefits as well!)

I have long ago suggested the open source business model (a substantial part
of the revenue is support anyway), and I am only now beginning to thaw from
the frozen looks I got - so I can't see that happening. :-)

Neil.


On 16 June 2011 12:09, Tom Allen <tom at randominter.net> wrote:

> 1) Force all web traffic through squid proxy (via firewalling etc) as the
> only route out and put rules in there, it supports all sorts of matching
> schemes and external filtering scripts. You can also use it to log all urls
> per user, or even log all traffic (given suitable storage space) I have seen
> this used before in sensitive areas (warning people all there packets are
> recorded is a very good deterant, especially when coupled with CCTV to prove
> it was them at the terminal)
>
> 2) Lots of security companies have two machines and two networks. To
> transfer from the secure net to the normal net, or visa-versa, files have to
> go in a que which is approved by a manager. There are many open source ways
> of doing this with varying degree's of setup time vs automation. This can
> slow down progress though and creates a boring job for approvals.
>
> 3) open source all your code and build a new business model!
>
> oh forgot the FTP requirement, that is a bit harder. Filtering what FTP's
> they connect to can be done in any decent proxy, but filtering what is sent
> is not easy. Again I would introduce a drop box where transfers are approved
> before they can be sent.
>
> The drop box approval method has legal advantages as well as being a
> deterrent. I believe that by hiding the data to get it past the boss and out
> the door they are committing a more serious offence than just leaking.
>
> also be aware though that you will never stop a determined person. even
> with body scanners and bag x ray on entry to the secure room.... you can
> hide data in anything, simple script can hide binary data in anything,
> images, text, log file etc which will never be spotted by someone approving
> files from being transferred on and off the secure network. I remember
> hiding a chat program in an image in my homework to get it onto my school
> network (including the exploit to run it with admin privilege from word)
> back in '97. Techniques like that are still used to this day with little new
> tech and also little new systems to stop it (well apart from less gaping
> exploits..... well hang on you said your desktops were running Windows, so
> maybe not less exploits ;-)
>
> I once saw a demo at Bristol Uni of a guy leaking data from an office by
> writing a script which sat in memory and displayed a fake carrot on the
> terminal which flashed at slightly different intervals which was not obvious
> to a human, on the roof top of the building opposite was a telescope and
> webcam pointing at his screen capturing the flash's and decoding it. Proper
> holywood stuff, but if you think about it, any competent Linux guru could
> have that up and running in an afternoon with the free webcam processing
> libraries available these days.
>
> Tom
>
>
>
>
> On 16/06/11 11:29, Neil Haughton wrote:
>
>> Hi
>>
>> Tech problem here: My employers' main asset is the IP in their source
>> code,
>> and consequently they are very concerned about the risk of staff
>> (especially
>> new recruits, or disaffected staff) being able to walk off with it all and
>> sell it in other markets where it would be impossible catch or stop.
>>
>> Other safeguards aside, they want to be able to stop certain individuals
>> from being able to get the stuff out via the internet, specifically email,
>> ftp, etc. At the same time those individuals need access to some websites
>> such as msdn and so on, in order to do their job.
>>
>> So far they have been able to lock people down to a personal PC (they can
>> only log in on their own PC) and remove or block the ability to move data
>> out except over the ethernet connection (ie no DVD writer, blocked USB
>> sockets, etc), and restrict the size of outgoing emails to limit what can
>> be
>> sent by attachment, but that still leaves a gap, and of course everyone
>> needs some internet access to do their job.
>>
>> The first solution considered was to use the Windows 7 Firewall, set up
>> appropriately on individual machines, but this doesn't allow web content
>> filtering AFAIK, and anyway can all too easily be circumvented.
>>
>> Can anyone suggest an open source solution that would allow the company to
>> limit outward internet traffic on a person by person (or machine by
>> machine)
>> basis, such that *certain individuals* can access specific websites only,
>> and cannot send stuff out by ftp?  I thought maybe IPCOP with the web
>> content filtering addon, but that's as far as my knowledge goes and that
>> doesn't appear to permit user-specific filtering. I've also
>> considered hacking the local etc/HOSTS file to map restricted domains to
>> 127.0.0.1, but even with a very long list of domains it's to open to
>> unexpected holes and what we really need is a 'deny all allow the
>> following'
>> approach.
>>
>> (BTW I am already familar with the 'this is an HR issue not a technical
>> one
>> and you shouldn't employ staff you don't trust' argument, but I need to
>> treat it as a technical issue and find a technical solution, if I can.
>> The
>> idea is to be safe rather than sorry, to shut the stable door before the
>> horse bolts, and quietly open the door when the company is confident that
>> the horse is not the bolting type. And then keep the horse happy enough
>> not
>> to want to bolt in future.)
>>
>> TIA
>>
>> Neil
>>
>
>