Sophos UTM9 Firewall appears to be blocking all dot tk DNS lookups from the LAN

UPDATE:
I found the culprit: Intrusion Prevention System (IPS).  Somehow I missed that log file when I was going through all the logs before.  Apparently part of the default ruleset is to block all .tk domain name lookups.  Sorry wiki.tcl.tk, you really shouldn't have used a .tk domain!!!

I should be able to research this on my own from here, and add an appropriate exception to allow at least wiki.tcl.tk lookups.

Apologies if I wasted anyone's time...  maybe my post will help someone else that runs into this though.

Thanks.

This is tricky, guys.  The trail of the blocking action was seen in the Intrusion Prevention log, but an Exception in Intrusion Prevention won't solve this for you. Add an Exception for wiki.tcl.tk in 'Advanced Protection >> Advanced Threat Protection'.

ATP blocks are also recorded in the Web Filtering log when the traffic is handled by httpproxy.

Cheers - Bob

Bob,
The exception in IPS "seems" to be working; as in DNS lookups of .tk domains are not blocked anymore and LAN users can browse .tk domain websites.  So when you say an exception in Intrusion Prevention won't solve this, do you mean "the way to create an exception specifically for one host (like wiki.tcl.tk) is to add it in Advanced Threat Protection"?  Or are you saying that turning off IPS for DNS from internal addresses is a really bad idea?  Or something else?

Thanks!

This is complicated.

I understand why Sophos decided to block *.tk (Tokelau) as untrusted.  It is an exotic arrangement with a tiny island in the South Pacific, which gives the islanders internet access for the first time, in exchange for allowing an entrepreneur to use their country code to provide free name registrations.  When a site becomes unused, he takes over the DNS and displays advertising in its place.  This link is press coverage about the arrangement.

  www.cnn.com/.../

Obviously, this service also becomes useful to bad guys who want to churn their DNS identity on a frequent basis.  It is easier for Sophos to block the country code than it is to evaluate every IP address that might be referenced by any host entry in that name space.   

The challenge is that this block, by design, occurs on the DNS lookup.  If the customer organization has followed "DNS Best Practices", the source PC will do a DNS lookup on its Active Directory DNS, which will then relay the request to UTM.   Then UTM throws an alarm suggesting that the Active Directory machine is possibly infected.  This is both alarming and misleading to the system manger, because the internal DNS server is not infected at all, and the DNS request generator, which is not necessarily infected, cannot be identified.  (One customer has already posted a request in Ideas for Sophos to invent some method to trace the request back to its originator, which seems impossible.)  

Since the alarm occurs on the DNS query, I don't expect that anything will appear in the web proxy logs, because I would think that the web request will never be released.  

The WebAdmin console indicates that IPS monitors using more than 1000 rules.  It does not seem to provide any way to review the list and turn an individual rule on or off.  Turning off all DNS-related IPS rules, without knowing what they do, seems excessive and risky.   Disabling all defenses related to a single host also seems excessive, if the goal is simply to allow the DNS lookup.

My tests seem to confirm what Bob reported, that an IPS exception for service=DNS and sourceip=internal does not permit the DNS query to complete.  Creating an ATP Exception for the target host, as he suggests, says to trust it for every ATP rule, which may also be excessive.

Even if we were able to create a perfect exception to allow these DNS lookups to complete, the result would be that we would now have a pointer to a host that has not been effectively screened for safety.   Even if a scan is performed, it could become irrelevant at a moment's notice because of a change in host behavior or a change in DNS-to-IP name translation.  The scoring services are based around the principle that corporate systems will have relatively persistent DNS names, IP Addresses, and risk profiles.  When this is true, and a host has been evaluated, the evaluation can be assumed to remain valid for an extended period of time.  None of this can be assumed true for .TK names.

Since there is no good reason why a legitimate business would be too poor to afford a few dollars per year for a name registration, one has to wonder why one would want to communicate with any of these sites.   I think we should conclude that Sophos has made the right choice.

The one downside to the current design is that if you have IPS alarms enabled for DNS rules, then you might get an unpleasantly high volume of emails when users try to follow a link to a .TK site.   This can be solved by disabling IPS-DNS notifications, but then you better have a system in place to review IPS logs.

This is complicated.

I understand why Sophos decided to block *.tk (Tokelau) as untrusted.  It is an exotic arrangement with a tiny island in the South Pacific, which gives the islanders internet access for the first time, in exchange for allowing an entrepreneur to use their country code to provide free name registrations.  When a site becomes unused, he takes over the DNS and displays advertising in its place.  This link is press coverage about the arrangement.

  www.cnn.com/.../

Obviously, this service also becomes useful to bad guys who want to churn their DNS identity on a frequent basis.  It is easier for Sophos to block the country code than it is to evaluate every IP address that might be referenced by any host entry in that name space.   

The challenge is that this block, by design, occurs on the DNS lookup.  If the customer organization has followed "DNS Best Practices", the source PC will do a DNS lookup on its Active Directory DNS, which will then relay the request to UTM.   Then UTM throws an alarm suggesting that the Active Directory machine is possibly infected.  This is both alarming and misleading to the system manger, because the internal DNS server is not infected at all, and the DNS request generator, which is not necessarily infected, cannot be identified.  (One customer has already posted a request in Ideas for Sophos to invent some method to trace the request back to its originator, which seems impossible.)  

Since the alarm occurs on the DNS query, I don't expect that anything will appear in the web proxy logs, because I would think that the web request will never be released.  

The WebAdmin console indicates that IPS monitors using more than 1000 rules.  It does not seem to provide any way to review the list and turn an individual rule on or off.  Turning off all DNS-related IPS rules, without knowing what they do, seems excessive and risky.   Disabling all defenses related to a single host also seems excessive, if the goal is simply to allow the DNS lookup.

My tests seem to confirm what Bob reported, that an IPS exception for service=DNS and sourceip=internal does not permit the DNS query to complete.  Creating an ATP Exception for the target host, as he suggests, says to trust it for every ATP rule, which may also be excessive.

Even if we were able to create a perfect exception to allow these DNS lookups to complete, the result would be that we would now have a pointer to a host that has not been effectively screened for safety.   Even if a scan is performed, it could become irrelevant at a moment's notice because of a change in host behavior or a change in DNS-to-IP name translation.  The scoring services are based around the principle that corporate systems will have relatively persistent DNS names, IP Addresses, and risk profiles.  When this is true, and a host has been evaluated, the evaluation can be assumed to remain valid for an extended period of time.  None of this can be assumed true for .TK names.

Since there is no good reason why a legitimate business would be too poor to afford a few dollars per year for a name registration, one has to wonder why one would want to communicate with any of these sites.   I think we should conclude that Sophos has made the right choice.

The one downside to the current design is that if you have IPS alarms enabled for DNS rules, then you might get an unpleasantly high volume of emails when users try to follow a link to a .TK site.   This can be solved by disabling IPS-DNS notifications, but then you better have a system in place to review IPS logs.

DouglasFoster,

I whole heartedly agree with all that, except for the part about the IPS exception not working.  I found that it does work, but if the DNS request is directed at the firewall itself then a second exception rule is needed that explicitly gives the destination as the internal address of the firewall.  So I have:

Skipping: Intrusion Protection
coming from these source networks: Internal (Network)
and using these services: DNS

AND

Skipping: Intrusion Protection
coming from these source networks: Internal (Network)
and going to these networks: Internal (Address)  [ie 192.168.0.1 or whatever your firewall's LAN IP is]
and using these services: DNS

The first exception makes requests to an external name server like 8.8.8.8 work.  The second exception makes requests to the firewall's DNS work.  I don't know why the second rule is needed, as it appears to be a subset of the first rule, but this is the behavior that I am seeing.

And again, I agree that this very well may not be the best policy, but it does do what you'd expect it to do.

-Neal

Great contribution, guys!

Neal, you said:

So when you say an exception in Intrusion Prevention won't solve this, do you mean "the way to create an exception specifically for one host (like wiki.tcl.tk) is to add it in Advanced Threat Protection"?  Or are you saying that turning off IPS for DNS from internal addresses is a really bad idea?

Actually, I've never tried to make an Exception for an ATP alert in Intrusion Prevention.  The best pace is indeed in Advanced Threat Protection. And, yes, turning off IPS for for traffic from internal devices isn't desirable and shouldn't be necessary.

Doug, you said "the DNS request generator, which is not necessarily infected, cannot be identified."  I suggest to folks that they turn on logging in their DNS server.

You're right that there's nothing in the Web Filtering log if the Proxy is in a Transparent mode since the client browser asks for name resolution.  In Standard mode, the Proxy asks for name resolution.

If you get a warning from IPS, it will list the rule #, but those from ATP do not.

Cheers - Bob