[nycbug-talk] dns abuse
skreuzer at exit2shell.com
Wed Jan 21 11:08:04 EST 2009
On Jan 21, 2009, at 10:50 AM, Yarema wrote:
> Steven Kreuzer wrote:
>> On Jan 19, 2009, at 2:23 PM, Max Gribov wrote:
>>> Hi all,
>>> saw a huge spike in root zone ns queries on my servers starting this
>>> friday 16th
>>> Heres a sample log:
>>> 19-Jan-2009 14:19:14.565 client 69.50.x.x#63328: query: . IN NS +
>>> 19-Jan-2009 14:19:15.689 client 76.9.x.x#35549: query: . IN NS +
>>> 19-Jan-2009 14:19:21.257 client 76.9.x.x#9389: query: . IN NS +
>>> some machines query as often as 20-30 times a minute. No idea why
>>> would be happening, doesnt look like legitimate traffic to me..
>>> Is anyone else experiencing this?
>>> If you're having same issue, you can do this in pf to throttle it a
>>> pass in quick on $ext inet proto udp from any to <server> port 53
>>> state (max-src-states 1)
>> Your DNS servers are/were being used for a DoS attack against
>> 188.8.131.52 and 184.108.40.206
> Steve, what makes you say that Max's DNS servers were used for a DDoS
> attack against 220.127.116.11 and 18.104.22.168? 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.
Remember the good ol days (1998) when you would send a single ICMP
to the broadcast address of a network and hundreds of machines on the
send back an echo reply.
If you changed the source address to address of some other host, you
a single packet that would result in a huge amount of traffic being
sent to your victim.
If you found a large enough network, you could successfully take your
victim offline from
your home machine connected to AOL at 9600 Bps.
This is pretty much the same concept, just applied in a new and
creative way. Someone makes
a request for a root name server which is a small query that generates
a large response. You change
the source address to the IPs you want to DDoS and eventually their
pipes are so clogged with DNS
traffic they eventually become unreachable.
More information about the talk