Enforcing Google SafeSearch with Palo Alto Networks Firewalls - Lockstep Technology Group Blogs
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%3Dsearc...'> 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!
