Escaping packets renders filtering useless
Published in Archived articles on June 16, 2009 by Administrator
We often come accross customers who want to deploy CensorNet Pro in a similar way to SurfControl/WebSense and the answer is no we don't do it the same way and there are two perfectly good reasons why - security and performance.
The aforementioned products use a technique called a "mirror port". On some of the better quality switches there is a mirror port which replicates all the traffic from all the other ports, so anything plugged into the mirror port can effectively see all the packets buzzing through the switch. The server running the software also has two NIC's, a dedicated one for the mirror port and a separate NIC for issuing blocked messages if required.
The fundamental problem with this scenario is that it relies on the SurfControl/WebSense software intercepting, scanning and blocking a web request faster than it takes for the web page to get back to the workstation that requested it via its normal route. On a slightly congested network or on an overloaded proxy server, there is a good chance that the requested page will not be blocked in time. This was confirmed to me in a meeting on Monday whereby one of our resellers with experience of SurfControl, told me that quite often the first request for a pornographic web site would be allowed but the second visit would be blocked. This unreliability is surely not acceptable - what if that happened in a school, or if the web site contained malware which on the first visit infected the machine?
With CensorNet Pro, there are two deployment options - both of which ensure that no request goes unfiltered, if that is your chosen policy.
Sideways mode - this is the traditional and default mode, whereby browser proxy settings point to the CensorNet server. The browser settings can be configured automatically using Active Directory group policy or WPAD (Web Proxy Auto Detection). By using the browser proxy settings you are ensuring that all web requests get handled by CensorNet before they are displayed in the web browser.
Inline mode - this mode requires two NIC's in the CensorNet server. The two NIC's will form a bridge between your corporate switch and your gateway/router/firewall. All packets will be transparently intercepted if they are destined for port 80 or 443, in either direction. You do not have to configure browser proxy settings, however, if you want to report on usernames then you will need to install a small client on each computer (using Group Policy updates). Once again, in this mode, no web requests will get back to the browser until they have been inspected by CensorNet.
So if complete security is one of your tick boxes when implementing a web security device, then it may be worth giving some thought to how it is deployed and even if the "mirror port" sounds like the quickest and easiest it might just cause you a whole heap of problems further down the line.
