The mechanism behind this tool has been known for a while, but we haven't seen any published tool yet. So here you go.

Evading URL Filtering software configured in Transparent (or Sniffing) mode, without using a remote proxy.

Last update: August 14th 2005.
This tool has been coded in December 2002.
Vendor is Informed:
I don't know about SurfControl, but Websense has been informed in December 2002 when we found this. They also had a copy of this proxy script for over a year.

System Affected:
Any environment not using a proxy (Check Point Firewall-1, Cisco Pix, Whatever...)
URL filtering softwares that don't reconstruct HTTP packets before allowing them through
  Websense in Sniffing mode
  Websense with Check Point FW-1 in UFP (transparent non proxy)
  Websense with Cisco Pix
  SurfControl in transparent mode (but not personnaly tested)
Reference:
SurfControl SuperScout can be Bypassed Using Split Packets
 http://www.securiteam.com/securitynews/5MP0L004KO.html
 Archived : 20/06/2001 by ndesai01 at tampabay.rr.com
 (I didn't know at the moment of my research...)

  Maybe others, but this is what we have been able to try..

Disclaimers
This is a proof of concept. If you do stupid things using this tool, it's your fault. We are publishing this because we want the sysadmins to be aware that some of their knowledgable users might be able to evade their surveillance.

The following perl script is a proof of concept that allow a user to bypass Websense (and possibly any other similar products) when this one is installed in UFP mode or in Sniffing mode (ie.: Transparent non proxy).

THE CONCEPT
The concept behind the weakness is simple: Everytime time a user asks a web page, the browser generates a request that pass through the firewall. Websense (and other products) looks at this request and answers yes or no depending if the requested url is in the database. In transparent mode, Websense counts on the fact that the firewall will forward the whole request in one packet. If not, Websense will simply let the packet pass, since this packet doesn't not look like a http request.

THE CONSEQUENCE
If a malicious employee wants to use the Internet without being traced, using this technique will allow him to bypass the filtering and the authentication. Since this has been know for over 4 years, there are great chances that they might do it already.

THE PROOF
How to test if you are vulnerable?
Use the Windows telnet client to connect to a remote http site. Be careful to type the request by hand and not simply cut and paste the request because each character needs to be sent one at a time.
So:
telnet www.google.com 80
GET / HTTP/1.0[enter][enter]

You should see the page being displayed at the screen. This can be done even if you are not authenticated on the filtering engine.

If you get a Redirect page, then the filtering software have catched your request... too bad, it will not work.

HOW TO PATCH THE PRODUCT
There is no patch (at least, no simple on). The behavior is a direct result of how the url filtering in transparent mode or the integration with a firewall is done. Check Point Smart Defence could be a good way to detect this and PIX already detects manual request for SMTP...

IS THERE A WAY AROUND?
Yes: Use the filtering software with a Proxy (or with the Security Server of Check Point). The way around consist of being sure that the whole packet is analysed at the same time.

IS THERE A WAY TO TRACE USERS THAT BYPASS THE WEBSENSE?
Long way:  See if all request in the firewall-1 logs match an entry in the Websense logs.
Short way: Code something that will parse a tcpdump output and look for this kind of patern.

KNOWN BUGS
DOWNLOAD THE SCRIPT:  Sakeru.pl (perl script, tested on Windows and Linux)

INSTALLATION
Under Windows: you will need Perl for windows (like ActivePerl from ActiveState)
Under Linux: you should already have everything you need.
Run the script:
perl -x sakeru.pl
Configure your browser to use a proxy on localhost port 5050
Surf the tide!!