Numbuk wrote:
When you send data to the glade, your PC actually receives the web page. It's just that Websense spams your computer with TCP resets and hopes that the resets hit your machine before the actual data is returned. Your browser sees the resets, and so assumes the data doesn't ever arrive.
But it does.
Actually, this isn't quite the case. For FTP, HTTP, and HTTPS, Websense acts as a simple in-line proxy server. When it encounters something it doesn't like, it simply refuses to proxy it, offering up its Websense error page in place. The data never reaches the proxy client's network interface unless the client is in the same Ethernet collision domain as the Websense server (i.e. connected by a non-switching hub/repeater).
With respect to other protocols (ex. IRC), Websense does use TCP RST forging in a "sideline" configuration to kill the connection rather than acting as an in-line SOCKS5 proxy. This is the same trick used by Comcast to kill its users' BitTorrent sessions. Detecting a forged TCP reset is not exactly trivial unless you're on the same Ethernet broadcast domain as the Websense server, and thus can differentiate between forged TCP resets coming from Websense vs. *real* TCP resets coming in via the network's gateway. If you aren't in the same Ethernet broadcast domain as Websense, you can still use the IP packet's TTL value to make an intelligent guess about forgeries. Forged resets from nearby Websense server will have a larger TTL than non-forged resets from a distant internet host. However, this is merely heuristic.
In any case, detection is rather moot. Websense forges the TCP RST in
both directions. Once the sender is squelched by Websense, it doesn't matter if you continue to listen for data past the forged RST.
Numbuk wrote:
Websense is interesting. It doesn't sit inline, which is it's biggest flaw.
Topologically speaking, this is still correct:
Code:
[gateway]-------[non-switching hub]-------[switch]------[PC]
| |
| |
[WebSense] [PC]
WebSense operates in promiscuous mode, rather than being in-line with the gateway. WebSense itself can't really do anything to prevent a PC from initiating a non-proxied FTP/HTTP(S) session directly with a remote host. To enforce the use of WebSense as a proxy server, you generally have two options:
1) rely on a client-side "governor" of some kind on the PC (ex. Group Policy can enforce the use of a proxy for IE, but that won't help with non-IE browsers)
2) Place a firewall directly in front of/behind the gateway which can drop web traffic not originating from the WebSense server. Something like:
Code:
[gateway]------[firewall]-------[non-switching hub]-------[switch]------[PC]
| |
| |
[WebSense] [PC]
There's an amusing DoS attack on WebSense that exploits its TCP forgery behavior, but I'll leave that as an exercise for the reader.