At my current gig, I have been tasked to investigate web content filtering – cue groans from anyone who has ever had to answer the help desk phones and deal with false positives, performance issues, and just the plain old bitter users who can’t get to Facebook any more as the organization’s policy deems it to be a productivity destroyer. Where I am working, content filtering is a requirement for a couple of reasons. First, the organization has residential care facilities where minors are housed, and the organization has legal obligations similar to any organization dealing with under-18s. Secondly, some of the organization’s government funding stipulates certain conditions in order to receive the money, and that includes content filtering.
After doing an evaluation of a couple of solutions, I have decided to trial the Scansafe product. Scansafe provides Software-as-a-Service web filtering, including content filtering, anti-malware and anti-virus services. Put more simply, Scansafe provides proxies out in the cloud and tries to block the nasty stuff. Since 2009, Scansafe has been a business unit of Cisco, and consequently being part of a Cisco ecosystem had some benefits which were attractive in choosing Scansafe to trial. In particular, being able to put the configuration on the perimeter router where everything is transparent to the user was a major plus.
Of course with any content filtering, there are limitations. In general, the SaaS solutions I looked at were purely for HTTP/HTTPS – ports 80 and 443. So in order to close down the most obvious methods of circumvention, you will need to use ACLs or firewall features to block torrent traffic, instant message file transfer or the simple change-the-HTTP-port methods. I’ve often heard the complaint that content filtering is only for web traffic; what about X, Y, or Z? I’ve made those comments myself. You have to remember what content filtering is and what it isn’t. I’ve come around to the view that content filtering is like a bike lock – it is a first layer of protection, but it won’t stop the determined attacker or user who really wants to get to that torrent site; you need other tools in conjuction with content filtering to be fully effective. Content filtering is what it is; don’t expect it to be something else.
Initial Considerations
All of the SaaS solutions I looked at boasted about their effectiveness and how comprehensive their classifcation of web sites was. In my opinion, this was the least of the considerations. Short of doing a comprehensive testing regime (and how one would go about that, I really don’t know), the effectiveness of one versus the other really just smacked of PR. All of them had dashboards for configuration (i.e. choosing categories to block, etc) and reporting. All of them had time-based rules (so one might allow Facebook access during lunch hours, for example) and the ability to warn users with a click-through page or have a hard block. All had the ability to set up groups based on authentication, such as Active Directory integration. So where did the differentiation come in?
The new network I am designing for my employer will have a managed WAN for our main offices, but the 20 or so residential facilities will be using IPsec tunnels to connect to the corporate services. We only have a team of three IT staff, and that will go down to two after I complete the network implementation. So a primary consideration is that solution needs to be simple and manageable. So this means
- the organization does not want the overhead of managing its own proxy servers
- it does not want to have to manage .pac files (for example) to bypass proxies for internal or explicitly defined sites
A couple of the solutions I investigated (such as Symantec’s cloud offering) required both of these, so we didn’t consider them viable based on the organizational constraints. Scansafe did not require these.
In addition, Symantec was only able to differentiate users and groups by authentication, such as Active Directory integration. As we have clients who are in residential facilities, sometimes only for a few days, and are given access without being in the Active Directory structure, this did not seem optimal. Scansafe can do AD integration too, but as it is integrated with the Cisco router at your perimeter and can add the internal IP address of the client into the header of the HTTP sessions, this allows the use of VLANs and an addressing schema to define groups without the management overhead of short-term user creation or the use of “generic” accounts.
Basic Implementation
So how do we set up Scansafe? Note that I am going to focus on the configuration of the router here; I am not going to go through the management dashboard here in detail. Essentially, you create rules that match groups and perform actions such as block, warn or permit traffic. These rules are as you would expect; select various categories of web sites, IP addresses or explicit URLs, and decide what the groups are that you want to apply these to. I may go into this in more detail down the track as we start doing more in the trial.
Firstly, the caveats. Scansafe as a transparent function on the Cisco router requires that the router be in the ISR G2 family – various 800, 1900, 2900 and 3900 series routers – and must be the SEC K9 licence bundle. In addition, the functions are only available using IOS 15.2MT or later.
Below is the network diagram for the different traffic flows. I can use a regex to allow direct, nonproxy access to Google, an ACL to allow nonproxy to internal servers over the IPsec tunnel, with all other traffic going to the Scansafe proxies.
First, we set up the basics. The router is identified to the proxy servers by a key. You can set up group keys (per router) or a single global key for all of your routers. By setting up group keys, you can use this as one identifier to create groups. You then need to set up the proxies, the addresses of which are provided to you. The interface on which to apply the redirect is defined (usually a dialler for a DSL service) and finally you decide what to do if the proxies go away – fail open or fail closed.
parameter-map type content-scan global
server scansafe primary name proxy1xxx.scansafe.net port http 8080 https 8080
server scansafe secondary name proxy2yy.scansafe.net port http 8080 https 8080
license 0 <key redacted>
source interface Dialer0
timeout session-inactivity 60
server scansafe on-failure block-all
To activate the content filter, enter the content-scan command on the outbound interface:
interface Dialer0
description WAN ADSL
content-scan out
At this point, content scanning is enabled for all HTTP and HTTPS. You can check this out using the following commands:
show content-scan summary ! shows whether connections to the proxies are active
show content-scan statistics ! stats
show content-scan sessions history|active ! shows the URLs and sessions
However, you may want to allow users direct access to a web site. You can achieve this using a regex parameter-map. The following will allow access to anything containing the string “google”.
parameter-map type regex DIRECT
pattern google
Most importantly, though is to not intercept and send internal sites to the proxies. The content-scan kicks in before your IPsec tunnel, firing RFC1918 traffic off towards the proxies. So, to stop this happening, create an ACL for your internal destinations, then add the regex parameter map and your ACL to a whitelist.
ip access-list extended INTRANET-WHITELIST
permit ip any 192.168.0.0 0.0.0.255content-scan whitelisting
whitelist acl name INTRANET-WHITELIST
whitelist header host regex DIRECT
And we’re done. Content filtering is now in effect, and you just need to make sure your policies and rules are correct ont the SaaS console.
A couple of things you may note. The whitelisting needs to be done on the router. This potentially could be a management overhead in a large network of sites, however you need to weigh that against deployment and management of .pac files to individual PCs, and in reality, decent planning and some deployment scripting should be able to overcome that limitation. Also, if you have a larger campus network with only one internet connection point, you obviously don’t need to deploy this on each router – only on your egress point – simplifying management quite a bit.
Conclusion
So far, I’ve been running a trial for a few weeks at one larger site and a couple of residential places. The only issues I’ve had so far have been the treatment on sites which are listed as unclassified, which I initially was blocking. However, this was a policy issue, not a technical one. Latency has not been an issue as far as I can tell. I’ve traced out the paths to the proxies on various occasions (assuming they are anycast and may move around). One seems to be in Australia where I am located, while the secondary is in Singapore.
The service is priced on a per-user, per-year basis, and seems quite reasonable. While we still have some time to go in the trial, and will be looking at user authentication and the mobile client option for people on the move or at home, I am definitely leaning towards using the service. If you have Cisco ISR G2 kit or are considering installing it in the near future and you have a content filtering requirement, then leveraging your investment in Cisco gear may be worth investigating. You can find more info and the solution guide on the Cisco web site.
About Matthew Mengel
