Lockstep works with a number of organizations that require filtering of inappropriate web based content (esp. our K12 customers). While many solutions existing in marketplace today, our engineering group prefers the Palo Alto Networks solution. Their BrightCloud and PanDB subscriptions do an excellent job of
filtering by categorization. However they don’t do much when users know
they can use search engine results to get around them. Using Google and Bing image search
specifically has become a very common way for users and students to find inappropriate
content.
Solving the problem
In the case of Microsoft Bing, they make it fairly easy to block this
content by just adding *.explicit.bing.net to a custom URL blacklist. Not so easy with Google. Some firewalls and proxies include a URL
rewrite function that allows you to modify a user’s URL before sending it out
to the internet, so you can through in the flags to enable SafeSearch. This has been a highly requested feature on
the Palo Alto forums, so fingers crossed that this is coming in the next major
release. In the meantime, here’s how we
do it.
Palo Alto Firewalls includes a core-compent known as App-ID. App-ID is a patent-pending traffic classification system that instantly applies multiple
classification mechanisms to accurately identify applications.
The basic idea is to use App-ID to identify google searches
that DO NOT have the safe search flags in them, and block those requests. If you’ve never written a custom App-ID, it’s
pretty simple, you just need to use WireShark to watch the traffic you’re
targeting and use the data you find there to build up the App-ID. In our case, we’re going to use the following
criteria to ID Google searches that DO NOT have safe search enabled (this
includes, SafeSearch moderate as well, which I’m not 100% sure exists anymore,
I think it may if you’ve never set a preference).
The first 2 conditions just identify a Google search in
general. The last (AND 3), is what spots
your SafeSearch setting. Any of those
patterns are found in the http-req-headers, then SafeSearch is not enabled (or
set to strict). The full XML is attached
at the bottom of this post.
Now to use this, we simply add a Security Policy that keys
on that application and has an action of Deny.
Voila, non-safe Google searches are now denied. The problem, however, is that this will
probably generate a lot of new helpdesk tickets for you to grumble about. The default response page from the PA is not
likely to satisfy a lot of your users.
So, with a little bit of javascript (thanks to Josh Sanders), we alter
the response page to not only tell them why there request was blocked, but also
tell them how to fix it.
<script type="text/javascript">
var cat = "<appname/>";
switch(cat)
{
case 'google-safesearch-off':
document.getElementById("warningText").innerHTML = "Google SafeSearch is not enabled. To enable it, go to your <a href='http://www.google.com/preferences?hl=en&prev=http://www.google.com/search%3Fhl%3Den%26output%3Dsearch%26sclient%3Dpsy-ab%26q%3D%26oq%3D%26gs_l%3Dhp.3..0l4.590.788.0.1297.4.3.0.0.0.0.210.406.1j1j1.3.0...0.0...1c.1.14.psy-ab.Il_dIJF1Z_I%26pbx%3D1%26bav%3Don.2,or.r_qf.%26bvm%3Dbv.47008514,d.dmQ%26biw%3D1680%26bih%3D933%26wrapid%3Dtlif136976922897710'>
Google Preferences</a> and check <strong>Filter explicit
results</strong>, the click <strong>Save</strong>.";
break;
}
</script>
You can upload the custom response page from Device > Reponse
Pages (full code at the bottom). Just
make sure the case statement matches whatever name you gave the custom App-ID.
The link provided will take them straight to their
preferences so they can correct their settings and move on with their day. So far, this has tested pretty well,
definitely drop a comment of you run into any use cases it doesn’t
support. One big thing to remember, a
lot of modern browsers will force google traffic to https, in that case, you’ll
need to have a decryption policy in place to use this. Check back here shortly for an article on how
to do just that!
