Sidestepping inline URL content filters – Update

A while ago, I bemoaned the ease with which Cisco’s inline URL filtering can be bypassed. There were two main gripes:

  • Only HTTP GETs were processed – POSTs etc were not inspected
  • You have to manually nominate the ports that the inspection will take place on (although this point can be mitigated with egress filtering)

I have since discovered a third bypass, whereby HTTPS traffic is not inspected at all, even if you manually alter the port-map settings so that port 443 is listed as plain HTTP.

I’m pleased to report that I’ve successfully raised a product enhancement request to remedy some of this (big thanks to Herbert at Cisco TAC for getting the ball rolling here!) – the inspection of POSTs and of HTTPS is on the development roadmap for a future version of IOS.

Timescales? I have no idea. Best estimate is a one-year timeframe, but better late than never!


Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk

Advertisements

2 Responses to “Sidestepping inline URL content filters – Update”

  1. ouch.

    Bluecoat boxes don’t do everything in the world, but they do give you a great deal of flexibility in inspecting traffic, and in applying policy to 443 – if you want to, you can use them to MitM all 443 traffic, or you can simply tell them to look at the hosts they are connecting to, and apply policy based on those.

    In addition to that, there is pointing all DNS traffic to open DNS. I use a bluecoat on my network for content filtering, and point DNS to openDNS as well, but only for malware – I prefer on-site and fine-grained control of browsing (so, for example, I can give the IT staff the ability to download software, and no one else in the shop can.) If there’s a way to do that with open DNS behind NAT it hasn’t occurred to me.

    OpenDNS is helpful because it will act on any request for data which is resolved by hostname, so it is totally port-agnostic. In principle, the bluecoat is port-agnostic also; in practice, I would love to see a few test servers set to offer content over arbitrary oddball ports for all of us to be able to test various strategies against – and indeed, there may be such servers which I don’t know of.

    As I understand it, the Websense research team is VERY strong. Unfortunately, they cost an arm and a leg to set up and are spendy spendy. I do not know how well they do with oddball ports, either. One relatively inexpensive way to implement Websense is, I kid you not, to install their database on a Bluecoat system after the system is amortized. When I eval’ed the bluecoat, I also eval’ed a Cisco + Websense offering, which would have cost far, far, more. I didn’t invite that vendor out, to avoid wasting time. I could now add a Websense subscription if I wanted to – and down the road, I may recommend that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: