Re: DNS query spam

[Jim Pingle <jim () hpcisp com>]

Florian Weimer wrote:
> * Piotr Kamisiski:
>
>
> > 23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53:  38545+ [1au] ANY ANY? e.mpisi.com. (40)
>
>
>
> 204.92.73.10 is one of the IP addresses for irc.efnet.ca.  Someone is
> spoofing the source addresses, in the hope that DNS servers will
> return a large record set.

I have seen many queries supposedly originating from various IRC related
servers and hosts (a lot of what looked to be shell servers and vhosts and
such) Though for whatever reason the majority of the traffic appears to have
been attacking spoofed hosts on our own network as well as those hosts,
perhaps somehow amplifying off them as well.

The attacks seem to be targeted, too. For example, one instance was almost
exclusively attacking hosts in Finland, and in another case, it was almost
all Australia. In each case the attacks lasted 10-15 minutes.

> Could you check if the packets contain OPT records (e.g. using
> "tcpdump -s 0 -v")?  This protocol extension is described in the RFC
> for ENDS0 (RFC 2671).  EDNS0-capable DNS resolvers can send fragmented
> UDP packets, exceeding the traditional 512 byte limit of DNS UDP
> replies.  The BIND 9 default maximum response size is 4096, for
> example.
>
> If the spoofed requests contain OPT records , you typically get an
> amplification factor of about 60 in terms of bandwidth, and 5 in terms
> of packet rate, but actual numbers may vary.

The packets I captured appear to have that set, and with a UDP size of 10000.

Here's an example from my captures (Sorry if these get wrapped/munged):

21:34:33.343475 IP (tos 0x0, ttl 59, id 22963, offset 0, flags [none],
length: 68) spoofed.host.com.domain > ns2.ourdomain.com.domain: [udp sum ok]
15767+ [1au] ANY ANY? e.mpisi.com. ar: . OPT UDPsize=10000 (40)

21:34:33.344322 IP (tos 0x0, ttl 64, id 17347, offset 0, flags [+], length:
1500) ns2.ourdomain.com.domain > spoofed.host.com.domain: 15767 q: ANY ANY?
e.mpisi.com. 1/2/2 e.mpisi.com. TXT[|domain]


> Yet another reason to restrict access to your recursive resolvers to
> customers only.

We have since done so, but we had one attack happen after we had already
locked it down. As a precaution, I flushed the caches after that to make
sure it wouldn't keep participating just because it had cached the query.