Several folks are reporting odd queries hitting their DNS servers at a steady rate of about two per second. The queries invariably ask for the name server of the domain "." (NS query for a single dot). Since "." is a query for the root name servers, it has a very short query packet but a pretty long answer. Our current theory therefore is that this is a denial of service (DoS) attack in progress, where the DNS servers are used as "amplifiers" and unwittingly flood the (spoofed) source by providing a long answer to a system which never asked. If you are also seeing these queries and have a better explanation (or a good guess :) what is going on, please let us know. Update 0118 UTC: Correlations of logs and captures submitted by readers suggests that 69.50.142.11 and 76.9.16.171 are the two IPs from which most queries appear to originate... which would mean that these two sites are under a DoS attack. ISC reader Chris used reverse DNS/passive DNS to determine that both IP addresses seem to be associated with porn sites. |
Daniel 385 Posts ISC Handler Jan 18th 2009 |
Thread locked Subscribe |
Jan 18th 2009 1 decade ago |
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?
|
Ken 40 Posts |
Quote |
Jan 18th 2009 1 decade ago |
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...
|
Matt 7 Posts |
Quote |
Jan 19th 2009 1 decade ago |
I take it that DJB would love seeing mentioned that tinydns - unless explicitly set up to do so - does not answer such requests.
|
rpdenid 3 Posts |
Quote |
Jan 19th 2009 1 decade ago |
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.
|
Dshield 10 Posts |
Quote |
Jan 19th 2009 1 decade ago |
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.
|
tyldis 5 Posts |
Quote |
Jan 19th 2009 1 decade ago |
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 |
Anonymous |
Quote |
Jan 20th 2009 1 decade ago |
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. |
Torsten 3 Posts |
Quote |
Jan 20th 2009 1 decade ago |
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.. |
Paul 13 Posts |
Quote |
Jan 20th 2009 1 decade ago |
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.
|
Ken 40 Posts |
Quote |
Jan 20th 2009 1 decade ago |
It was only temporary... As of about an hour later, 13:32 UTC, I'm seeing alerts on these again.
|
Ken 40 Posts |
Quote |
Jan 20th 2009 1 decade ago |
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. |
Andrew 41 Posts |
Quote |
Jan 20th 2009 1 decade ago |
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 |
Anonymous |
Quote |
Jan 20th 2009 1 decade ago |
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 |
Anonymous |
Quote |
Jan 20th 2009 1 decade ago |
Thanks
|
Anonymous |
Quote |
Jan 20th 2009 1 decade ago |
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.
|
Matt 7 Posts |
Quote |
Jan 20th 2009 1 decade ago |
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.
|
Alex2k 4 Posts |
Quote |
Jan 21st 2009 1 decade ago |
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
|
Andrew 41 Posts |
Quote |
Jan 23rd 2009 1 decade ago |
Started receiving queries from 206.71.158.30 around 18:26 UTC (01/24/2009).
|
Dshield 10 Posts |
Quote |
Jan 24th 2009 1 decade ago |
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.
|
Dshield 6 Posts |
Quote |
Jan 27th 2009 1 decade ago |
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.
|
Dshield 2 Posts |
Quote |
Jan 27th 2009 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!