Mitigation of SAD DNS using Unbound

Installing and Using OpenWrt Network and Wireless Configuration
1

Here we go again, another DNS attack: SAD DNS

I'm looking to implement the recommended mitigation measures:

The simplest mitigation, though, is to disallow outgoing ICMP replies altogether.
At the moment, I have the following rules, mostly untouched from a default firewall config:

  • Allow-Ping
  • Allow-MLD
  • Allow-ICMPv6-Input
  • Allow-ICMPv6-Forward

I'd say "Allow-Ping" has to go... am I correct?

Another easy fix is to set the timeout of DNS queries more aggressively.

Are we talking about the "delay-close" keyword?

1 Like
2

Bump. What about the built in dns server?

I’d imagine when the packages are updated with the patch you will be fine too.

3

You only have to change the default firewall rule for WAN from REJECT to DROP (for both INPUT and FORWARD) or update to newer Linux kernel. Those four rules are fine. More a protocol issue rather than a DNS server issue though there are some mitigations like cookies which dnsmasq unfortunately doesn't implement.

From the openwrt-devel mailing list; SAD DNS cache poisoning attack

3 Likes
4

So once we get an updated kernel for 19.07 with the ICMP rate-limit randomization in place, we can go back to REJECT on WAN INPUT/FORWARD?

Bump. What about the built in dns server?

I’d imagine when the packages are updated with the patch you will be fine too.

Vulnerable as well. Someone on the mailing list mentioned that dnsmasq doesn't implement DNS cookies at all to prevent spoofing.

5

How about resolving the root cause of the issue by setting up DoT?
https://openwrt.org/docs/guide-user/services/dns/dot_unbound

6

If I understand correctly, DoT has terrible performance costs and works best when using a single upstream server, such as CloudFlare or Google. I moved to Unbound precisely to run a recursive server on my own and be done with ISP filtering, so I am not too keen on going back to a single chokepoint.

Does it make sense to run DoT in this scenario?

1 Like
7

You can try to optimize performance to a certain extent:
https://openwrt.org/docs/guide-user/services/rng

And the main Google and Cloudflare resolvers are listed as non-filtered:
https://en.wikipedia.org/wiki/Public_recursive_name_server

So typically DoT is enough to solve the issues of DNS hijacking/filtering/leaks by the ISP.
At the very least, it shouldn't be that bad unless your router is very old.

Moreover just using recursive DNS cannot protect you against DNS hijacking.
Check tcpdump and see for yourself.

2 Likes
8

If you don't want to make that change shouldn't it also work if you add two traffic rules which drop packets with source port 53?

config rule
option name 'Drop-SAD-DNS-Forward'
option src 'wan'
option src_port '53'
option dest '*'
option target 'DROP'

config rule
option name 'Drop-SAD-DNS-Input'
option src 'wan'
option src_port '53'
option target 'DROP'
9

Yeah. Unfortunately not enough of the DNS system has DNSSEC and your ISP can intercept and change entries. Also raw recursion has no point-to-point security so your local ISP can snoop your traffic and use it for profiling. Cloudflare and Mozilla are both keen to bust ISP exploitation of customer data, so 1.1.1.1 will be seen by most with a desireable behavior and privacy policy in print. Quad9 has similar privacy policy for their main server 9.9.9.9, but they also have a malware-site blocker. This may interfere with research or developing your own adblock/malware-block tools. 9.9.9.11 is wide open, but then it has more privacy leaks because it forwards original query IP or at least subnet. And Google is Google ...

1 Like