[nycbug-talk] dns abuse
max at neuropunks.org
Wed Jan 21 10:57:52 EST 2009
> Steve, what makes you say that Max's DNS servers were used for a DDoS
> attack against 22.214.171.124 and 126.96.36.199? It seems to me like it's
> the other way around.. But I haven't got my brain wrapped around this
> one yet so I'm just looking to get enlightened on the matter.
This dns attack is very similar to good ole smurf - only this time they
are spoofed dns requests for the root zone (~450 bytes) with sources set
as those ips. As a result, any server with enabled recursion or
apparently even with disabled recursion but . zone loaded as 'hint' type
in bind will return that result to the servers under attack. Multiply
450 bytes by several hundred K and you have a sizable ddos going.
For example, consider UDNS2.ULTRADNS.NET
nslookup www.yahoo.com UDNS2.ULTRADNS.NET
*** Can't find www.yahoo.com: No answer
^^ recursion disabled
dig @UDNS2.ULTRADNS.NET . in ns
^^ will still return the . zone -- oops
> I use djbdns with tinydns on the outward facing interface serving only
> authoritative responses. And dnscache on the localhost and/or LAN
> interfaces. That said I've been hit by this same sort of DDoS attack
> also starting around Jan 16th. I first noticed it on the morning of the
> The test of my DNS servers from http://isc1.sans.org/dnstest.html returns:
> "I am not able to connect to your server, and as a result can't tell if
> your server is configured right. However, if your server is not
> reachable, it is secure as far as this test is concerned"
> I guess that's good.
> My remedy has been to add each IP that I notice repeatedly querying for
> the root "." domain to the blacklist table in my pf rules. So far I've
> collected the following IPs:
> With the above blocked I get no "." queries in the tinydns log file.
> Otherwise pftop would show upto a 100 pf states on UDP 53 when my normal
> average tops out at around 30 states, but usually hovers around 10 or 15.
> Note that I added 188.8.131.52 and 184.108.40.206 just this morning.
> They have not previously hit my servers. Nor has 220.127.116.11 hit my
> servers, though 18.104.22.168 did.
More information about the talk