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.
