We recently did some work for a county council who wanted to enable Google SafeSearch for all the schools under their jurisdiction. Initially they were trying to use internal versions of google.com and google.co.uk with a CNAME record for www that redirected to forcesafesearch.google.com, but this is not an ideal solution for various reasons:
- Other “google.com” services stop working, e.g. mail, docs, groups, maps etc. requiring a plethora of additional DNS records
- Creating a zone called “www.google.com” helps catch just the www record, but you have to hard code a domain apex A record as you can’t use an apex CNAME (contravenes the DNS RFC’s)
- Users can bypass the www record anyway by querying the apex “google.com”
- There are many TLD’s that google uses, configuring DNS to catch every single one is an onerous task
- DNAME records can be used to alias the various different google TLD’s, but there’s a lot to configure and it still does not solve all the other problems
An easier way to do this is to use the RPZ (Response Policy Zone) feature in BIND to re-write the query so that it always resolves to “forcesafesearch.google.com”. There are many articles about how to configure RPZ in BIND, but we are primarily interested in how to do this on Infoblox using the DNS Firewall feature. Unfortunately the Infoblox admin guide is not particularly clear about how to implement it, hence the reason for this article!
First make sure you have an RPZ license installed on every Infoblox member that is going to be re-writing the queries. You can use the “set temp_license” command from the command line and select option 13 to get a 60 day license if you want to try it. We are going to run through an example using some Infoblox systems in our lab.
The first thing to do is define the RPZ zone – click on Data Management->DNS->Response Policy Zone and click the “+” button:
This initiates the Add Response Policy Zone Wizard. Infoblox DNS Firewall has the ability to take a feed of suspicious domains and block them for security purposes, but in this example we are not going to use that feature, we just need to add a local response policy zone, so for step 1 of the wizard we just select “Add Local Response Policy Zone”.
For step 2 of the wizard we give the RPZ a name that identifies the zone as a local one, the name does have to comply with DNS naming conventions as it forms part of the FQDN that DNS uses to load the zone – just think of it as a zone file containing various entries, like any other zone. So in our example we call it “rpz.local”. We are not going to do anything with the queries at this level so we set Policy Override to None. The severity is used for logging, this is the level used by syslog so we set this to “Informational” as the log entries are not critical in our opinion.
In step 3 we identify the name servers that are going to host the RPZ. In our example we have a primary name server and two secondary name servers that are configured in a default name server group to use grid replication. This is perfectly normal and may echo what you use to replicate your internal DNS zones. However this is where the Infoblox documentation is not very clear. Steps 4 and 5 of the wizard can be skipped, so if we just use our default name server group and select “Save & Close”, we get an error:
What is happening is that the RPZ is being configured to use grid replication, but RPZ does not support it. It makes sense when you think about it – RPZ would normally be used to obtain a feed of malicious domains from the Infoblox threatstop service, and it does this using the standard DNS zone transfer mechanism (because threatstop is used by many people, not just Infoblox customers). So RPZ by its very nature uses standard zone transfers rather than the proprietary grid replication mechanism that Infoblox supports.
Whether you modify your existing name server group to use standard zone transfers is up to you, but I prefer to create a second name server group and use that for the RPZ – this is so that any changes do not affect any other zones hosted on the servers.
So, if you abort adding the RPZ zone, you can create a new name server group and configure the secondary servers to use zone transfers. This can be done via Data Management->DNS->Name Server Groups and then clicking on the “+” button:
Go through the process of adding your grid primary server to the group, and when you start adding the grid secondary servers, ensure you select “DNS Zone Transfers” for the “Update Zones Using” option:
Now that we have a suitable name server group, we can go back and use this for the RPZ zone we were trying to create:
Now the zone has been created you will be prompted to restart services, this gets the zone loaded up onto the DNS servers. However once it has been loaded, you can start adding entries to it without having to do a restart every time (just like any other zone in Infoblox).
To test it, we can add a single entry into the RPZ as follows. First click on the name, rpz.local to open the zone, then click on the arrow next to “+” to see a list of options, for this example we are going to choose “Substitute Domain Name (Domain Name) Rule”:
For our example we are going to redirect “www.google.com” to “forcesafesearch.google.com”, so populate the query and substituted name fields:
Because the zone is already loaded, this will take immediate effect. To test it we can use nslookup. If we send a query to a DNS server that doesn’t have RPZ configured for www.google.com, this is what we get back:
C:\>nslookup www.google.com 192.168.0.1
Server: router.cn.corp
Address: 192.168.0.1
Non-authoritative answer:
Name: www.google.com
Addresses: 2a00:1450:4009:80d::2004
212.56.71.59
212.56.71.20
212.56.71.40
212.56.71.34
212.56.71.54
212.56.71.25
212.56.71.49
212.56.71.35
212.56.71.45
212.56.71.55
212.56.71.24
212.56.71.30
212.56.71.44
212.56.71.39
212.56.71.50
212.56.71.29Now if we send the same query to the Infoblox server we just configured, this is the result:
C:\>nslookup www.google.com 192.168.0.61
Server: te820-1.cn.corp
Address: 192.168.0.61
Non-authoritative answer:
Name: forcesafesearch.google.com
Address: 216.239.38.120
Aliases: www.google.comSo the name www.google.com was intercepted and changed to forcesafesearch.google.com by the RPZ rule.
What happens if we query the Infoblox server for google.com?
C:\>nslookup google.com 192.168.0.61
Server: te820-1.cn.corp
Address: 192.168.0.61
Non-authoritative answer:
Name: google.com
Addresses: 2a00:1450:4009:80c::200e
212.56.71.118
212.56.71.114
212.56.71.88
212.56.71.99
212.56.71.89
212.56.71.103
212.56.71.93
212.56.71.94
212.56.71.113
212.56.71.119
212.56.71.108
212.56.71.109
212.56.71.84
212.56.71.98
212.56.71.104
212.56.71.123So, people can still bypass the safesearch by omitting “www”, this means we also need a rule for the domain apex too:
Now let’s try it:
C:\>nslookup google.com 192.168.0.61
Server: te820-1.cn.corp
Address: 192.168.0.61
Non-authoritative answer:
Name: forcesafesearch.google.com
Address: 216.239.38.120
Aliases: google.comWe can successfully redirect queries for the apex domain to safesearch, but now the issue is with all the TLD’s that google operate in. If you look at this link you will find that google operate 193 domains! So to add both “www” and the domain apex RPZ rule means we have to add 386 rules!
It’s actually worse than this because there are other records inside the google domains that will resolve to the search engine page, e.g. “w”, “ww” and “m” are three that we found, and there are probably others. Instead of trying to catch just “www” it seems that we are going to have to use a wildcard, but again we have to be careful not to clobber other services like maps, docs, mail etc. The solution appears to be to use wildcards for everything apart from google.com.
Fortunately, Infoblox supports the mass creation of RPZ rules via CSV import, we just need to get the CSV file into the correct format. The easiest way to do this is to export the rules we have just created in “Infoblox CSV Import format”, modify the file to include all the google TLD’s, then import it:
The google domains list will need to be re-formatted one per line so that we can get them into a useful format. The easiest way is to use a decent text editor like notepad++ that supports regular expressions – we want to substitute all spaces (\s) with a newline (\n) character. Additionally we need to append “.rpz.local” to the end of each domain name, we can do it by replacing \s with .rpz.local\n as follows:
Hit “Replace All” and you should end up with a list of domains, one per line. Check the last line of the list has got “.rpz.local” appended as the last line may not get modified (because there’s no space character for the search operation to find).
Using the find and replace facility we can now create two lists of domains, one for *.<google domain name> and the other for the apex domains. Open a new tab and copy all the domains into it so we have two copies to utilise.
For the first one, simply replace “.google” with “*.google”, for the second one, replace “.google” with “google”.
Now open up the CSV you exported earlier and copy each list of domains into the “fqdn” column. You can skip .com as we’ve added that one manually. Copy the other values down the rows to match. You may also want to add entries for “w.google.com” and “ww.google.com” to specifically catch these queries. You can always add new ones in through the GUI as you discover them.
To import the CSV file, use the “CSV Import” option in the toolbar.
After you have imported the CSV file, you should now be redirecting every google search domain to forcesafesearch – a quick random check (google.cn and w.google.ae in these cases):
C:\>nslookup google.cn 192.168.0.61
Server: te820-1.cn.corp
Address: 192.168.0.61
Non-authoritative answer:
Name: forcesafesearch.google.com
Address: 216.239.38.120
Aliases: google.cn
C:\>nslookup w.google.ae 192.168.0.61
Server: te820-1.cn.corp
Address: 192.168.0.61
Non-authoritative answer:
Name: forcesafesearch.google.com
Address: 216.239.38.120
Aliases: w.google.aeOne issue is that this is a static list, when google add new domains you will not know about it so may have to do a manual check every now and then to detect new domains and add them into the ruleset.
To see how many times the RPZ rules are being fired, you can enable RPZ logging in the Grid DNS Properties:
You can view the RPZ logs by going to Administration->Logs->Syslog and selecting the “RPZ Incident Logs” quick filter:
The logs show you the source IP address of the query and the name that was queried. The data is in CEF (Common Event Format) format, which means you can redirect the syslog output to a SIEM product like ArcSight or Splunk and process the data with complex search algorithms. Additionally Infoblox have a reporting solution that can also provide comprehensive reports.
Something else you will also need to do is check for google DNS queries that do not fire an RPZ rule – kids are clever and if there is a google FQDN that still gets them to the unfiltered search page, they will find it! Unfortunately turning on querylogging can have a big impact on performance so you need to find a solution that either sniffs DNS packets at wire level or you could try the Infoblox Reporting solution.
If you have made it this far, here is a little treat for you! You can download the CSV file containing all the google RPZ rules I created earlier here: rpz-for-googlesafesearch-20151104.csv. Import this into your RPZ ruleset and it will save you doing all the manipulation mentioned in this post. At the time of writing (4th Nov 2015) it contains 193 google domains, it will be interesting to see how big the list of domains grows over the coming years.
About Paul Roberts
