6

I believe the root cause for DNS tunneling is because the internal hosts are allowed to do recursive queries of external domains. For DNS tunneling to work, an internal host should be able to send queries to attacker controlled domain dnstunnel.xyz.com.

I was wondering if we limit DNS queries to known/authoritative DNS servers alone, will it prevent this attack? To make it clear, when we run nslookup for an external domain from within the organization using a third party DNS server, it wouldn't resolve.

C:\Users\bAdb0y>nslookup cisco.com 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
Server:  UnKnown
Address:  8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

I tried setting up a DNS tunnel using Iodine with and without the above setting. It failed to establish the tunnel when recursive queries were limited to internal DNS servers. The tunnel worked like charm otherwise. So is this fix effective? Or do I need to disallow recursive query by internal machines completely?

bAd bOy
  • 61
  • 3
  • If DNS lookup for external domains does not work any longer a DNS tunnel using external domains will not work too. But, other software which needs to resolve external domains (like browsers w/o explicit proxy) will not work any longer too. If you can live with this side effect this setup might be useful. – Steffen Ullrich Feb 01 '17 at 06:17
  • Well, we do not have a web proxy here. The perimeter firewall is configured to handle external domains' queries and it is also configured to block querying any unknown DNS servers. It works without issues. So I assume this is indeed an effective way to mitigate DNS tunneling. – bAd bOy Feb 01 '17 at 06:55
  • 1
    If the firewalls is configured to only query known DNS servers you can resolve a limited set of external domains but not any new ones using different servers nor any of the existing ones if they start using a different DNS. Or what exactly considers you firewall an "unknown DNS server"? – Steffen Ullrich Feb 01 '17 at 07:01
  • Let's say I have configured the firewall to use the Google DNS servers. Will not the Google DNS servers get dynamically updated for new domains introduced or maybe forward queries to their corresponding DNS servers in case of unknown domains? Please enlighten! – bAd bOy Feb 01 '17 at 07:29
  • If you use Google DNS as nameserver they will also resolve queries to the attackers domain which will make DNS tunneling work again. It might be that they have some intelligence inside to detect strange lookups or have a rate limiting for target domains but this is not a general feature of all nameservers. – Steffen Ullrich Feb 01 '17 at 07:40
  • Thank you! That makes a lot of sense! I suspect the same. Google should have their DNS servers monitored for abnormal traffic. – bAd bOy Feb 01 '17 at 08:17
  • 1
    I would not count on Google monitoring their traffic for abnormal things as long as they never promised it. Also one might construct less obvious DNS tunnels which bypass the behavior analysis. To summarize: Your idea does not protect against DNS tunnels in general but it might protect in some specific cases if the upstream DNS does some behavior analysis. – Steffen Ullrich Feb 01 '17 at 09:03
  • wasn't trying to spam. I read up on some other blogs as well that Splunk can be helpful in preventing DNS tunneling. [WhitePaper](https://www.sans.org/reading-room/whitepapers/malicious/paper/37022) [Splunk Blog](https://www.splunk.com/blog/2018/03/20/hunting-your-dns-dragons.html) Do let me know if you've any more concerns. – MichaelF823 Jul 01 '19 at 11:59

1 Answers1

1

First of all, DNS tunneling typically leverages the fact that DNS traffic is not usually monitored.

So, to (give or take) effectively handle DNS tunneling these are required:

  • Payload analysis (high-level view at a DNS query itself)
  • Traffic analysis (stateful analysis i.e. keeping a track of multiple request/response of DNS queries)

There are a bunch of other things to add to that (entropy measurement in a DNS query, et cetera) as well. You can refer to the SANS documentation.

The idea is to stop a machine from being compromised at all in the first place. An unaccounted/unknown compromised machine in a network is a big problem.

As it will be off-topic, I will skip what organizations typically do to avoid getting into this situation in the first place.

For what it is worth, due to the same reason, a definite protection against a reverse shell is very difficult. Pattern/Traffic analysis (with or without SSL stripping) is the way to go for this, again.

Avineshwar
  • 11
  • 1