0

Debugging a DNSmasq server using it's logs, I find a LOT of:

dnsmasq: query[ANY] . from RANDOM-IP
dnsmasq: query[ANY] . from RANDOM-IP
dnsmasq: query[ANY] . from RANDOM-IP
dnsmasq: query[ANY] . from RANDOM-IP

All legitimate queries seem to be more specific, like:

dnsmasq: query[A] specificdomain.com from KNOWN-IP

EDIT: This is NOT intended as a public DNS service

We want to create a white-list DNS filter, it should ONLY answer to a list of specified domains. Typical amplification attacks would only affect our server, nobody else. We just want a cleaner log to be able to operate better.

The intended operation is:

  • Client uses this DNS for their internet connection.
  • Client requests domain resolution
  • If the domain is in the white-list, we resolve, if not, we don't reply.

How can we achieve this? Only process request that match our white-list, discard anything else.

mencargo
  • 1

2 Answers2

1

. ANY is a well-known query that requests all record types in cache that are associated with the root node (AKA .) of DNS. In high volume this assuredly an indicator of malicious behavior. Unfortunately, these queries are almost certainly UDP, and the source IP is the spoofed source address of the victim.

This problem needs to be addressed by identifying why malicious entities are able to make these requests against your server, and not by blocking the query itself. The attackers can just as easily leverage any number of requests known to return large result sets, some of which do not use the record type ANY at all.

In most cases, this is an indicator that you are running an open resolver. Your first priority should be to confirm this and close the security vulnerability. If you are not an open resolver, there is an infected device on your network. This becomes harder to track as you need to trace the MAC address one hop at a time back to the origin device.

Andrew B
  • 33,098
  • thanks for the info, since it is a public cache DNS (for filtering), how can the server protect itself from it? – mencargo Apr 05 '17 at 20:13
  • You should not be running a public cache if your infrastructure was not designed with abuse in mind. We have a summary of the challenges involved here. – Andrew B Apr 05 '17 at 20:21
  • It's not the case mate (explained in edit), please remove the duplicate mark. – mencargo Apr 06 '17 at 22:22
  • I'm getting mixed messages here. If that was indeed the setup, asking how to protect yourself from ANY queries directed at the root zone doesn't make much sense. I'll remove the dupe flag, but it sounds like you need to provide as much detail as possible in regards to your atypical setup. – Andrew B Apr 06 '17 at 22:29
  • More details provided, glad to respond any question about it – mencargo Apr 07 '17 at 00:47
0

Although, as pointed out by Andrew, there are many security concerns about a DNS service in a public IP, the solution was the following iptables rule:

iptables -A INPUT -i eth0 -p udp --dport 53 -m string --hex-string "|0000ff|" --algo bm -j DROP

That specifically drops that query.

mencargo
  • 1