SANS ISC: DNS queries for "."

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

brief experimentation with my own nameservers seems to indicate that if you don't allow recursion for queries from external hosts, this theory falls over... or am i missing something?

Seems to be a fixed length query. After putting both feet in my mouth and reporting it to an abuse@ without thinking about UDP spoofs (and got a really good reply, I might add), filtering on UDP dest port 53 with packet length 45 seems to stop it dead. For now, until whoever is pulling this DDoS stunt changes the query...

I take it that DJB would love seeing mentioned that tinydns - unless explicitly set up to do so - does not answer such requests.

So far, I've been getting these queries from 76.9.31.42, 76.9.16.171, 69.50.142.110, and 69.50.142.11. It started on Jan 16 with 69.50.142.11.

It started with a few probes from 63.217.28.226 on the 6th of Januar, then I see a lot of requests from 216.201.82.19 on the 8th of January before the real flooding for the mentioned IPs hit my server at 15th of January at 12:26:37 UTC.

I am also being hit by this.

I have blocked port 53 for packets for size 45, but named is still not working.

any other ways to block this ?

My firewall rule :
iptables -I INPUT 2 -p udp --dport 53 -m length --length 45:45 -j DROP

Getting hit by most of the listed ips too. \"Solved\" the issue by a new regex for fail2ban (bans after 10 failures of regex \"Not authoritative for(.*), sending servfail to <HOST>(.*)\" - this regex works for powerdns.
Its a dynamic solution, so you dont need to update iptables rules by hand on any new ip involved.

We had an misconfigured Windows 2008 DNS server serving the queries from spoofed addresses. I did by the instructions from Microsoft and set the option "Disable recursion" (as was set on our other servers). I used "Clear Cache" from DNS managment console, restarted the service (not the server).

After doing this I found out that the server was still happily serving the spoofed queries with root hints.

After spending an hour between banging my head to a wall, trying to figure out what I was doing wrong and restarting services ... I found out that there was a windowssystem32dnscache.dns file which contained nothing but the root hints. After uncommenting the lines, the server stopped serving the root hints and started to work as it should.

I do not know if restarting the physical server would have helped, but I didn't have this luxury of an option available..

Just to let others know that if they stumble into the same problem.. uncomment the lines or maybe rename the file..

EmergingThreats now has a snort sig to alert on this, sid:2009030. That was added to my ruleset at 7:00 UTC today. Although no servers here are responding, I have seen ~100 queries per hour from the four addresses mentioned by Dshield. As of 12:35 UTC, all have ceased.

It was only temporary... As of about an hour later, 13:32 UTC, I'm seeing alerts on these again.

On Jan 20, 2009 I'm seeing that the targets tailed off and the new spoofed IP addresses are:

66.230.160.1
66.230.128.15

which also are IP addresses related to a porn site.

Looking for a quick fix. Using BIND9; have disabled all recursion and it now (correctly) won't resolve non-authoritative hosts - instead it returns the root hints and I don't know how to stop this!

Thanks

for an authoritative (only) name server, replying with the list of root name servers when asked for a domain it is not authoritative for, is the normal reaction. So, I would say the name server replies to the query "NS .", but rather, the name server says to "ask them (the root name servers)".

This being said, the problem remains that there is a multiplication factor of *10 ... *15 (45 bytes in - I didn't count them, 500+ bytes out).
To reduce that multiplication factor, one could consider using a dedicated view (Bind 9) to hold authoritative data, and within that view use a different (short) list of root name servers : namely with only that authoritative name server itself. That would probably reduce the amplification factor to max 2. "innocent" name servers that accidentily ask there question, should ignore that list of root name servers anyway ...

Kind regards,

Marc Lampo
author and teacher of
"DNS Explained" at John Cordier Academy, Belgium

Thanks

There isn't a quick fix yet. I posted the above length 45, which is the datagram length. The packet length was, originally, 60 and the payload length is 17. It all depends on which bit of the UDP packet your firewall matches against. All of this can be had from tcpdump and the man pages for your firewall. <br> The easiest "fix" is to use something like snort_inline and the rule Ken posted earlier in block or sblock mode. You may want to increase the logging frequency in the rule if you use block or newsyslog is going to be busy. snort_inline is ideal if you're running iptables or ipfw. You can also use allow-recursive and allow-query-cache in BIND with IP ranges to limit recursive queries to a known subset of hosts, but in this case the target is still having to deal with your recursive refusal reply which, ironically, is the same length as the query. You can also try snortsam with Ken's rule, which works with a wider range of firewall packages, but has the disadvantage that it installs permanent block rules and is a possible DoS vector against your own network. The snort solutions are about the best you're going to get. <br> Be aware that the targets are changing (I have about six in my logs now) so simply blocking on source address is not sufficient. I can confirm that the snort rule SID: 20090030 from Emerging Threats works without hindering legitimate traffic.

If your Bind 9 is authoritative-only, globally deny queries and recursion (in the options section), and then allow queries in each zone definition. Queries for the \".\" hint zone are implicitly denied.

new target is 63.217.28.226 which is listed within SpamHaus as SBL Ref: SBL68873 netblock 63.217.28.128/25 as a Russian & Polish pharmacy spam operation

Started receiving queries from 206.71.158.30 around 18:26 UTC (01/24/2009).

Have been seeing this for several weeks from all the mentioned IP's. If you are using the Cisco IPS sensors, the 4003/0 sig fires. The "quick" fix for us has been to simply block inbound traffic at the firewall from the IP address being spoofed until the attack stops.

Checked my logs this morning and 3 more addresses show up: 67.192.144.0 (rackspace); 64.57.246.146 (4T Networks); 208.69.32.12 (OpenDNS). Looks like the Denial of Service attack is spreading/migrating.