DNS ANY Request Cannon - Need More Packets
We have a report from our reader Tuukka, who observed a flood of DNS ANY requests from likely spoofed IP addresses. What we know so far is that it seems to be a DNS Reflective Amplification Attack. These usually use generic recursive DNS queries trolling for poorly configured DNS services. This event is different in that the reflection is more targeted. DNS 'ANY' record queries are only sent for domains for which the server is authoritative for, which the server will of course reply to regardless of available recursion. These events have been validated by a real time observation by one of our handlers. Here is what we know so far.
Hit List:
- Source IP is spoofed
- Flood lasts up to 60 seconds with 500 queries (as witnessed, but likely could be more)
- Flood comes from a designated IP and seem to target multiple domains on authoritative server
- All observed requests are similar thus far
- This appears to be similar to what others have seen [1]
Example DNS Log Entry:
- x.x.x.x is the spoofed/target server
- example.com/10.1.1.1 is the "reflecting" DNS server
21-May-2012 13:21:41.757 queries: info: client x.x.x.x#20475: view external: query: example.com IN ANY + (10.1.1.1)
21-May-2012 13:21:41.897 queries: info: client x.x.x.x#59247: view external: query: example.com IN ANY + (10.1.1.1)
21-May-2012 13:21:42.054 queries: info: client x.x.x.x#18676: view external: query: example.com IN ANY + (10.1.1.1)
21-May-2012 13:21:42.059 queries: info: client x.x.x.x#28530: view external: query: example.com IN ANY + (10.1.1.1)
21-May-2012 13:21:42.193 queries: info: client x.x.x.x#6489: view external: query: example.com IN ANY + (10.1.1.1)
We are interested in knowing if you have seen this and what you have done to mitigate any ill effects of such events. Please post a comment to let us know.
We also want your DNS logs and packet capture logs of the events described in this diary. There is still plenty to learn about this behavior.
If you see outbound ANY query floods from your own network: Try to identify the source machine. It would be interesting to see what tool causes these queries.
-Kevin
--
ISC Handler on Duty
×
![modal content]()
Diary Archives
Comments
2 IPTables rules on INPUT:
-p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|'
-m recent --set --name dnsanyquery
-p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|'
-m recent --name dnsanyquery --rcheck --seconds 60 --hitcount 5 -j DROP
The first rule looks on UDP 53 for DNS ANY queries (hex 0000FF0001 towards the end of the query) and sets a recent tag for that IP named dnsanyquery
The second rule looks to see if the first rule has been hit more than 4 times in the past minute by a particular IP. If so, drop the packet.
This way, valid ANY queries still work so long as they request fewer than 5 a minute, and the lockout does not affect other queries (A, NS, PTR, MX, etc) so standard traffic will not be affected. This also prevents an attacker from being able to stop others from getting to our nameservers because even if they lock out ANY queries for an IP address, all other normal queries always work fine. Very few things use ANY nowadays for normal lookups.
One interesting side effect of this is that the attacker uses more bandwidth to request the hits than we send back out, so by using us they are actually reducing their total DDoS bandwidth.
Network Mouse
May 21st 2012
1 decade ago
Kevin, where do you want me to send a packet capture?
Jerry
May 22nd 2012
1 decade ago
this topic comes up about every 6-8 weeks now... 'known issue', someone in China is upset at someone else in China, they send ~3k packets to your nameserver, for every domain you are authoritative for, you send back replies... go team.
Chris
May 23rd 2012
1 decade ago
We can confirm that most of the targets (i.e. spoofed source addresses) are from the China but we've seen some US IP addresses either.
Also we've been working with Sourcefire on the ways to mitigate this attack. The result is the rule 21817 that is in official rule-base since the middle of April.
By default the rule is disabled, but anyone who runs authoritative DNS servers and uses Snort to protect their assets should consider turning that rule on.
ArD
May 25th 2012
1 decade ago
I had to tune the iptables rule because our nameserver is very busy. The 'recent' module tracks by default only 100 ip addresses (see man iptables -> recent). For a busy nameserver a time window of 60 seconds may omits some bad guys because the list is too small. So either load the 'recent' kernel module (xt_recent) with a higher default or lower the time window (--seconds). I currently use --seconds 10 --hitcount 5
Daniel
May 25th 2012
1 decade ago
What I've seen is bursts of these queries, about 8-10/second for a set number of time before dropping again, and growing in frequency and number. The IPs may be spoofed but what I noticed was that it's adaptive, it would swap IP very shortly after blocking one in my bogons list. So the query results are fed back into the abusing system. Apart from causing traffic spikes and unneeded traffic, I'm a little at a loss about what the real purpose is behind these attacks.
What I've found out is that as a precursor to floods, there tends to be a few probing requests to see if the name server responds, usually from a limited set of IPs belonging to t-ipnet.de -- I gather this is done through proxies to mask the real source.
What I've done myself is write a reverse DNS proxy in python using dnslib that drops all Qtype=ANY requests coming in from the outside and forwards other query types to the DNS server. Considering there is no reason for any client on the outside to request these records from the server (it's atypical traffic for normal DNS resolution), this should be fine to do. It has slowed the abuse after a few days, and I gather the botnets will eventually realize that their attacks aren't working through the server anymore and whittle down.
Mark S.
Jun 2nd 2012
1 decade ago
188.165.195.128 11./24.2016
185.128.40.162
93.190.138.237
51.255.194.249
51.255.194.249
45.63.70.29
188.165.195.128
185.128.40.162
104.255.70.247 11/18/2016
Mark S.
Nov 24th 2016
7 years ago