DNS... WTF?
Jan 17 13:53:34 [named] client 69.50.142.11#62054: query (cache) './NS/IN' denied
Jan 17 13:53:34 [named] client 69.50.142.11#50405: query (cache) './NS/IN' denied
Jan 17 13:53:37 [named] client 69.50.142.11#38682: query (cache) './NS/IN' denied
Jan 17 13:53:39 [named] client 69.50.142.11#47266: query (cache) './NS/IN' denied
# bzgrep -l "client 69.50.142.11#" log-2009-*.bz2
log-2009-01-08-14:01:54.bz2
log-2009-01-16-20:01:54.bz2
log-2009-01-16-23:01:42.bz2
log-2009-01-17-02:01:49.bz2
log-2009-01-17-05:01:55.bz2
log-2009-01-17-08:01:50.bz2
log-2009-01-17-11:01:04.bz2
# bzgrep "client 69.50.142.11#" log-2009-*.bz2 | wc -l
33464
#
Update
I got a quick answer from their hosting company. According to them, the source IP is fake and this is a DOS.
Rather lame, IMHO: a DNS answer is small. If the cracker can fake the source IP, he can directly flood the victim with more data than my DNS server...
Labels: cyberspace, En
posted by M.A. at 14:00
8 Comments:
I have the same crap. It started with 69.50.137.175 then after I blocked it, it moved on to 69.50.142.11
more talk of it here: http://www.linuxquestions.org/questions/linux-security-4/dns-poisoning-attempts-i-think-629574/
Here's the response from the abuse dept. It's just a ddos technique I wasn't aware of:
This actually is not one of our clients. This client is having a traditional
DDOS attack on PORT 53 UDP.
As you are aware there is no three way handshake with UDP traffic, poor
design perhaps, hence forth there are two steps to this attack.
A) Flood the server as listed below IE: 69.50.137.175
B) Modify the header and send the request to thousands of unexpected Name
Servers to make them think they need to respond.
This leads to two things.
A) Causing the server to be flooded in hopes to shut it down. This was
prevented by placing DDOS filters in place and setting an ACL to deny any
and all UDP traffic to and from this server.
B) Service providers such as you to make contact with the hosting company to
say there being attacked.
I got the same answer.
I doubt that this DoS is efficient.
I got caught up in this, too.
The attack is targetting ladyboydolls.com; this was previously hosted at 69.50.137.175, and I was seeing a flood of spoofed DNS queries from that IP. According to http://yougetsignal.com/ there were a number of transgender-related websites hosted there.
My server was responding with 17-byte responses, which are the same size as the requests. This is quite inefficient; if the attacker sent valid queries instead, it could trigger larger responses and then use DNS servers for 'bandwidth amplification'.
Around 2:30am (UTC+00:00) this morning, the A record of that domain was changed to 69.50.142.11 which is being routed to Prolexic (a DDoS mitigation company).
The most obvious thing to do is to drop these packets in the firewall, but that will only work until the next attack, against a different victim. I'm receiving only 5 packets a second now so it doesn't cause a problem for me.
To trace the attacker (probably a botnet) it might help if we report this to our ISPs or transit providers; they may be able to trace the spoofed packets back to their source.
Regards,
steven@pyro.eu.org
http://isc.sans.org/diary.html?storyid=5713
Interesting...
But why do they still query DNS servers which send back short answers. They could check before.
They request the root.hints file's contents by making a ns lookup on the root zone. This is typically a rather large response that is about 150x the length of the request.
Agreed Anonymous. It is a large response, +- 150x as you state.
Tom Hayward has worked out a nice iptables block rule for this, along with his explanation of how he got there.
http://blog.tomh.us/post/72857274/blocking-recursive-root-dns-queries-with-iptables
I verified with a number of different queries, and it does block the invalid "." query only, as stated.
Kudos to Tom. Saved me having to work it all out myself.
Regards,
Ian Macintosh
Post a Comment
<< Home