Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 4 subscribers
  • Views 23846 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Neal Harder

Sophos SG135 running UTM9.4

If I do an nslookup of dot.tk using 8.8.8.8 as the server from inside my LAN I get timeouts.  From another workstation that is connected directly to the ISP it works fine.  All other DNS lookups from inside the LAN work fine, it is only .tk domains that timeout. 

Using wireshark I can see the request go out of my workstation, but no response ever comes back.  When looking up other domains I do see the responses coming back.  To be sure, I have tried turning off the workstation's firewall, but it made no difference.

So the only apparent difference between the working workstation and the timing out workstation is the UTM9 firewall.

On the UTM9 I have allowed port 53 from LAN to WAN (and it appears to be working because DNS lookups to all non-.tk domains work fine).  I have country blocking turned off, although that shouldn't matter since the interaction is purely between me and google's 8.8.8.8 DNS server.  I tried allowing all traffic from the LAN out to the WAN just to be sure but it made no difference.

I have looked at the firewall logs but I can't see any blocked packets from 8.8.8.8 or anything port 53 related.

There appears to be a DNS proxy running on the UTM9, although under Network Services->DNS I have tried both with Allowed Networks empty and with "Internal Networks" added, and with the request routing rules turned on and turned off... none of that makes any difference in the behavior.  In the DNS proxy log I don't see anything at all related to my dot.tk queries.

So questions...

1. Has anybody seen this, or have any idea what might be blocking the requests?

2. How can I debug this?  Is there any way to have the logs show me specific UDP packets so I can verify the request is making it out and that a response is in fact being received?  It's a Sophos SG135 and I have to this point done everything using WebAdmin, and have not tried to log in directly to a shell on the device.

Thanks for any help that anyone can offer.  If there are any logs or settings that I can post that would help please let me know.  I should note that folks want to access wiki.tcl.tk which I think is a legitimate use, and if they use the IP address directly they can access the pages just fine- it is only the DNS lookup that is broken.

 

 

 



This thread was automatically locked due to age.
Parents
  • +1

    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.

  • 0 in reply to Neal Harder

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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!

  • 0 in reply to Neal Harder

    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.

  • 0 in reply to DouglasFoster

    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

Reply
  • 0 in reply to DouglasFoster

    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

Children
No Data
Unfiltered HTML