More annoying DNS queries

22 Jan, 2009 in Tech Stuff by chrome

Here’s some more queries, similar to the previous post, but DDoSing a different IP now.

Jan 22 09:31:57 mars named[1478]: client 66.230.128.15#34555: query (cache) './NS/IN' denied
Jan 22 09:31:58 mars named[1478]: client 66.230.160.1#29839: query (cache) './NS/IN' denied
Jan 22 09:31:59 mars named[1478]: client 66.230.160.1#32642: query (cache) './NS/IN' denied
Jan 22 09:31:59 mars named[1478]: client 66.230.160.1#61945: query (cache) './NS/IN' denied
Jan 22 09:31:59 mars named[1478]: client 66.230.128.15#20469: query (cache) './NS/IN' denied
Jan 22 09:32:00 mars named[1478]: client 66.230.160.1#50838: query (cache) './NS/IN' denied
Jan 22 09:32:01 mars named[1478]: client 66.230.128.15#25874: query (cache) './NS/IN' denied
Jan 22 09:32:03 mars named[1478]: client 66.230.128.15#41950: query (cache) './NS/IN' denied
Jan 22 09:32:04 mars named[1478]: client 66.230.160.1#49472: query (cache) './NS/IN' denied
Jan 22 09:32:04 mars named[1478]: client 66.230.160.1#29840: query (cache) './NS/IN' denied
Jan 22 09:32:05 mars named[1478]: client 66.230.160.1#63240: query (cache) './NS/IN' denied

Just a note here; I’m running BIND 9.5.0-P2. It is configured to refuse recursive queries, so any requests for ./IN/NS return this:

; <<>> DiG 9.4.2-P2 <<>> @mars.stupendous.net . NS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24302
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;.              IN  NS

;; Query time: 56 msec
;; SERVER: 202.60.77.116#53(202.60.77.116)
;; WHEN: Thu Jan 22 09:31:45 2009
;; MSG SIZE  rcvd: 17

It doesn’t return the root hints.

There are no relevant fixes to bind over the version that I have that I can see that would be relevant in resolving this issue, unless someone can see something I can’t.

Really not sure what the fix is here.

Update 24/1 4:47am: Need to be clear here; the DNS queries are SPOOFED. They’re not actually coming from those IPs. I’m not sure if I was clear enough in this post about that; the previous post was however.

Patrik’s solution works well.

6 Comments
tagged ,

6 Comments

  1. Reply
    Patrick
    22 January, 2009

    I’m affected too. Since a couple of hours my logs are flooded by this. I added two simple iptables rules to get rid of it.

    iptables -A INPUT -p udp –dport 53 -s 66.230.128.15 -j DROP
    iptables -A INPUT -p udp –dport 53 -s 66.230.160.1 -j DROP

  2. Reply
    chrome
    22 January, 2009

    The other solution is to add a blackhole to your Bind9 config; but this is just temporary. They’ve been doing this for weeks, using different IPs as they see fit.

  3. Reply
    Tim
    23 January, 2009

    Their response:

    Begin forwarded message:

    From: ISPrime Support support@isprime.com
    Date: January 22, 2009 9:06:34 AM CST
    To: tim@timsnet.com
    Cc: support@isprime.com
    Subject: Re: ISPrime being blackholed by DNS server due to DDOS from ISPRIME:

    Hello,

    These are the result of a spoofed dns recursion attack against our servers. The actual packets in question (the ones reaching your servers) do NOT originate from our network as such there is no way for us to filter things from our end.

    If you are receiving queries from 76.9.31.42/76.9.16.171 neither of these machines make legitimate outbound dns requests so an inbound filter of packets to udp/53 from either of these two sources is perfect.

    If you are receiving queries from 66.230.128.15/66.230.160.1 these servers are authoritative nameservers. Please do not blackhole either of these IPs as they host many domains. However, these IPs do not make outbound DNS requests so filtering requests to your IPs from these ips with a destination port of 53 should block any illegitimate requests.

    An ACL similar to:
    access-list 110 deny udp host 66.230.160.1 neq 53 any eq 53
    access-list 110 deny udp host 66.230.128.15 neq 53 any eq 53
    Is what you want.

    I would also suggest taking a look at the excellent CYMRU secure bind template (assuming you are running bind), to help you configure your nameservers so that you do not participate in this attack: http://www.cymru.com/Documents/secure-bind-template.html.

    Thanks for your help in mitigating this attack against us.

    Please let me know if I can be of further assistance.

    ISPrime Support
    support@isprime.com
    ICQ: 136633378

  4. Reply
    Adam Jacob Muller
    23 January, 2009

    Hi,
    I work at ISPrime in the network abuse / security department, unfortunately we are not actually sending these queries to you (if we were, we would be able to fix things very easily).
    CYMRU provides an excellent well-commented bind template which can help you with reconfiguring your dns servers to mitigate this: http://www.cymru.com/Documents/secure-bind-template.html
    If you have any other questions i’m personally reachable at adam@isprime.com, and our abuse department is 24/7 at abuse@isprime.com.

  5. Reply
    chrome
    23 January, 2009

    yep, we know Adam. Thanks. Configuring the DNS to reject recursive queries isn’t the problem here, rather it is the fact that we are still replying to your spoofed addresses at all.

    It’s my opinion that bind needs an option for dropping recursive queries completely.

  6. Reply
    Patrik Rak
    24 January, 2009

    Here is my rule to stop the ./NS/IN queries:

    iptables -A INPUT -j DROP -p udp --dport domain -m u32 --u32 \
    "0>>22&0x3C@12>>16=1&&0>>22&0x3C@20>>24=0&&0>>22&0x3C@21=0x00020001"

    Specifically, it tests that the packet contains one query, the query is for empty name, NS type and IN class.

    Hope it helps.

    Patrik

Leave a Reply

Using Gravatars in the comments - get your own and be recognized!

XHTML: These are some of the tags you can use: <a href=""> <b> <blockquote> <code> <em> <i> <strike> <strong>