[Dshield] DNS DOS and Bind
security at admin.fulgan.com
Fri Mar 3 08:44:01 GMT 2006
I've seen some odd DNS traffic about 24 month ago that could be a
cruder form of what you're seeing.
Basically, in my case if was a traffic amplification and bounce
attempt: Someone would hammer my DNS with root DNS queries spoofing
the IP address of the real DDOS target and my server would answer with
a much larger answer.
I have since fixed that problem although it took about 6 month for the
attacker to realize that their attack wasn't going through).
I'm wondering if the same couldn't be happening in your case. Even if
traffic amplification isn't the real goal here, bouncing DDOS attacks
on you (or other hosts) could be worth the trouble.
What you could do is check the packet's source and see if you can get
in touche with an admin in the same netblock. You might be able to
know who is really the intended target.
Friday, March 3, 2006, 12:43:30 AM, you wrote:
jtn> Greetings -
jtn> I began noticing some odd dns queries in my logs a few weeks ago.
jtn> **begin paste**
jtn> Mar 2 07:38:19 myhost named: client 184.108.40.206#32804: query:
jtn> i205249.upc-i.chello.nl.mydomain.net IN AAAA
jtn> Mar 2 07:40:31 myhost named: client 220.127.116.11#32804: query:
jtn> zg06-071.dialin.iskon.hr.mydomain.net IN AAAA
jtn> Mar 2 07:43:48 myhost named: client 18.104.22.168#32804: query:
jtn> ACCC7FD0.ipt.aol.com.mydomain.net IN AAAA
jtn> **end paste**
jtn> myhost and mydomain have replaced my hosts true info, but that is
jtn> essentially the format of these queries. When I dig the host with
jtn> mydomain.net omitted, it typically resolves to some real host on the
jtn> internet, but the same query dig'd against my server comes back empty as
jtn> These queries come a few at a time over a few minutes, as if someone is
jtn> testing their settings, and then after a short period of time they begin
jtn> to come in large quantities virtually non-stop for anywhere from several
jtn> hours to several days. Due to some troubleshooting I had turned on DNS
jtn> logging some time ago and due to the low load on my server didn't realize
jtn> I had forgot to turn it off.
jtn> Initially I was blacklisting the few offending hosts, as they only seemed
jtn> to gang up on me one or two at a time, and it seemed an otherwise easy
jtn> thing to do for some possibly virus-infected mass mailer system with a bad
jtn> dns lookup routine. Unfortunately, the offender seems to continue to come
jtn> back every few days or so from a different source host, so clearly, I'm
jtn> dealing with someone who is being a dedicated pain in the backside and has
jtn> some axe to grind with me. My initial thoughts were that someone was
jtn> spamming and attempting to possibly use an DNS proxy lookup exploit or
jtn> something of that nature, but the negative results confused me. Somewhere
jtn> along the line my system became lame for it's own domain too, which
jtn> confused me as to how it happened, but it might have been an RPM update
jtn> via yum that caused the conf to be saved out to .conf.rpmsave rather than
jtn> something malicious. Just thought I would throw that in, just in case it
jtn> is important.
jtn> It took me a while to fingure out what to query google for, since each DNS
jtn> query was different and the suffix was always my domain. I finally found
jtn> a few search phrases that yielded positive results.
jtn> I found this:
jtn> which referenced this:
>>From these it seems there is a problem in bind and it is illustrated by a
jtn> AAAA query returning NXDOMAIN instead of NOERROR and an empty return
jtn> record. The problem is that I'm seeing NXDOMAIN with an empty return
jtn> record, so I'm not entirely sure what to expect. Also from these two
jtn> articles, I'm guessing that a failed AAAA query should cause the
jtn> requesting client to fire back an A query or fatally die if the client
jtn> doesn't handle this condition properly. It seems that this isn't
jtn> something like a web browser that one would normally expect for a client,
jtn> and likely something custom due to the volume, so expecting it to die due
jtn> to these failed queries is pointless.
jtn> Is this some sort of exploit or known virus infected host(s)? Is this
jtn> something old or new? Is it likely a simple DOS? Anyone else seen this
jtn> sort of thing before?
jtn> Anyone know if I can configure Bind to ignore or drop AAAA queries since
jtn> I'm not running IPv6? (not terribly appropriate for this list, but it does
jtn> seem to be a DNS security related question...so maybe it's important to
jtn> ask. Yeah, I'm sure there's a more appropriate bind discussion list to
jtn> ask this of, but here it is...)
jtn> Is there another recommended defense?
jtn> Learn about Intrusion Detection in Depth from the comfort of your own couch:
jtn> send all posts to list at lists.dshield.org
jtn> To change your subscription options (or unsubscribe), see: http://www.dshield.org/mailman/listinfo/list
Stephane mailto:security at admin.fulgan.com
More information about the list