[Dshield] DNS DOS and Bind

josh@theoubliette.net josh at theoubliette.net
Fri Mar 3 19:49:18 GMT 2006


last one...
more googling led me this excellent paper by Dan Kaminsky which, in part,
was talked about in a few earlier articles on various sites around april -
august of 2005:

http://www.doxpara.com/slides/Black%20Ops%20of%20TCP2005_Japan.ppt

Using this info, I was able to clean up my act and identified some
deficiencies in my named configs.

Hope this helps someone else too...

J-

> Here's the answer to my question...
>
> Ref: http://www.isc.org/sw/bind/
> ***begin paste***
> BIND4/BIND8
> Unsuitable for Forwarder Use
> If a nameserver -- any nameserver, whether BIND or otherwise -- is
> configured to use ``forwarders'', then none of the the target forwarders
> can be running BIND4 or BIND8. Upgrade all nameservers used as
> ``forwarders'' to BIND9 . There is a current, wide scale Kashpureff-style
> DNS cache corruption attack which depends on BIND4 and BIND8 as
> ``forwarders'' targets.
> ***end paste***
>
>> Greetings -
>>
>> I began noticing some odd dns queries in my logs a few weeks ago.
>>
>> **begin paste**
>> Mar  2 07:38:19 myhost named[22178]: client 216.98.159.202#32804: query:
>> i205249.upc-i.chello.nl.mydomain.net IN AAAA
>> Mar  2 07:40:31 myhost named[22178]: client 216.98.159.202#32804: query:
>> zg06-071.dialin.iskon.hr.mydomain.net IN AAAA
>> Mar  2 07:43:48 myhost named[22178]: client 216.98.159.202#32804: query:
>> ACCC7FD0.ipt.aol.com.mydomain.net IN AAAA
>> **end paste**
>>
>> myhost and mydomain have replaced my hosts true info, but that is
>> essentially the format of these queries.  When I dig the host with
>> mydomain.net omitted, it typically resolves to some real host on the
>> internet, but the same query dig'd against my server comes back empty as
>> expected.
>>
>> These queries come a few at a time over a few minutes, as if someone is
>> testing their settings, and then after a short period of time they begin
>> to come in large quantities virtually non-stop for anywhere from several
>> hours to several days.  Due to some troubleshooting I had turned on DNS
>> logging some time ago and due to the low load on my server didn't
>> realize
>> I had forgot to turn it off.
>>
>> Initially I was blacklisting the few offending hosts, as they only
>> seemed
>> to gang up on me one or two at a time, and it seemed an otherwise easy
>> thing to do for some possibly virus-infected mass mailer system with a
>> bad
>> dns lookup routine.  Unfortunately, the offender seems to continue to
>> come
>> back every few days or so from a different source host, so clearly, I'm
>> dealing with someone who is being a dedicated pain in the backside and
>> has
>> some axe to grind with me.  My initial thoughts were that someone was
>> spamming and attempting to possibly use an DNS proxy lookup exploit or
>> something of that nature, but the negative results confused me.
>> Somewhere
>> along the line my system became lame for it's own domain too, which
>> confused me as to how it happened, but it might have been an RPM update
>> via yum that caused the conf to be saved out to .conf.rpmsave rather
>> than
>> something malicious.  Just thought I would throw that in, just in case
>> it
>> is important.
>>
>> It took me a while to fingure out what to query google for, since each
>> DNS
>> query was different and the suffix was always my domain.  I finally
>> found
>> a few search phrases that yielded positive results.
>>
>> I found this:
>> http://www.ietf.org/rfc/rfc4074.txt
>>
>> which referenced this:
>> http://www.kb.cert.org/vuls/id/714121
>>
>>>From these it seems there is a problem in bind and it is illustrated by
>>> a
>> AAAA query returning NXDOMAIN instead of NOERROR and an empty return
>> record.  The problem is that I'm seeing NXDOMAIN with an empty return
>> record, so I'm not entirely sure what to expect.  Also from these two
>> articles, I'm guessing that a failed AAAA query should cause the
>> requesting client to fire back an A query or fatally die if the client
>> doesn't handle this condition properly.  It seems that this isn't
>> something like a web browser that one would normally expect for a
>> client,
>> and likely something custom due to the volume, so expecting it to die
>> due
>> to these failed queries is pointless.
>>
>> Is this some sort of exploit or known virus infected host(s)?  Is this
>> something old or new?  Is it likely a simple DOS?  Anyone else seen this
>> sort of thing before?
>>
>> Anyone know if I can configure Bind to ignore or drop AAAA queries since
>> I'm not running IPv6? (not terribly appropriate for this list, but it
>> does
>> seem to be a DNS security related question...so maybe it's important to
>> ask.  Yeah, I'm sure there's a more appropriate bind discussion list to
>> ask this of, but here it is...)
>>
>> Is there another recommended defense?
>>
>> TIA,
>> josh
>> _________________________________________
>> Learn about Intrusion Detection in Depth from the comfort of your own
>> couch:
>> https://www.sans.org/athome/details.php?id=1341&d=1
>>
>> _______________________________________________
>> send all posts to list at lists.dshield.org
>> To change your subscription options (or unsubscribe), see:
>> http://www.dshield.org/mailman/listinfo/list
>>
>>
>
> _________________________________________
> Learn about Intrusion Detection in Depth from the comfort of your own
> couch:
> https://www.sans.org/athome/details.php?id=1341&d=1
>
> _______________________________________________
> send all posts to list at lists.dshield.org
> To change your subscription options (or unsubscribe), see:
> http://www.dshield.org/mailman/listinfo/list
>
>



More information about the list mailing list