Random header image... Refresh for more!

Three Ways to Beat Bandwidth Thiefs

November 16th, 2007 · No Comments

I want to shift over to the web content filtering world for a minute.

I’m working with a tech college, couple of thousand part-time students, and their bandwidth use is huge. Since the government pays for this excessive bandwidth use that’s not their problem. But the congestion caused by all that use makes their network pretty much unusable. Like minutes to reach a login screen, and forget about trying to log in remotely.

So the challenge is to eliminate all the crap from their network. The usual stuff should be easy – streaming media, ftp and p2p downloads, and so on. However some smart students have discovered cgi proxy sites and these bypass the currently-installed, government-sanctioned piece of list-driven crap that passes for a web filter there.

Well ContentKeeper eats these for breakfast. It does this in two ways.

First technique, normal web content via a CGI Proxy Server

ContentKeeper’s local AI component is smart enough to recognise prohibited content regardless of the page’s URL (which of course changes when it’s accessed via a cgi proxy). And once a page is recognised as suspect, anything else coming from the same root URL gets special attention. What this means is that little Johnny, getting his daily dose of gay porn, only gets to see the first page before the filter kicks in.

Second technique, non-HTTP protocols via a CGI Proxy Server

ContentKeeper can recognise just over 100 different protocols and apply blocking policies to them based on that protocol. Most of these are benign and you wouldn’t worry about them But others, especially the chat and p2p ones, can hide behind different ports (even the standard ones, like 80 and 23) and they are really hard to block. Others, like binary newsgroups, share ports with text-based newsgroup traffic.

So protocol ‘signatures’ are the best way to go.

Bonus technique, hiding behind an SSL session

Some file download applications now allow SSL sessions to be setup, with the explicit goal of bypassing web filters. Because the stream is encrypted, they reason, a web filter can’t see what’s in there and it won’t get blocked.

Well, they are almost 100% right. ContentKeeper can terminate and re-establish SSL sessions, and it does this so the unencrypted packet header can be analysed on the fly. Not everyone wants this – there is a performance hit and there’s always the legitimate use of SSL to think about – but the option’s there is you want it. Of course, anyone transferring GB’s of data under SSL has to be a little suspect.

I apologise for the ContentKeeper rant. But no one else does this shit quite so well.

Tags: Web filtering

0 responses so far ↓

  • There are no comments yet...Kick things off by filling out the form below.

Leave a Comment