DNS query spam

[Piotr Kamisiski]

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--827350393-698970637-1133130621=:14403
Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE


Hi all,

Recently my DNS servers get jammed with bogus queries. The attacks come in=
=20
series, taking a few minutes each, sometimes from different IPs at the=20
same time, at least twice a day.

<snap>
23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53: 38545+ [1au] ANY A=
NY? e.mpisi.com. (40)
23:05:41.600902 IP 204.92.73.10.16561 > xx.xx.xx.xx.53: 22242+ [1au] ANY A=
NY? e.mpisi.com. (40)
23:05:42.091743 IP 204.92.73.10.37547 > xx.xx.xx.xx.53: 64644+ [1au] ANY A=
NY? e.mpisi.com. (40)
23:05:43.433539 IP 204.92.73.10.32370 > xx.xx.xx.xx.53: 31772+ [1au] ANY A=
NY? e.mpisi.com. (40)
23:05:43.854481 IP 204.92.73.10.12913 > xx.xx.xx.xx.53: 33470+ [1au] ANY A=
NY? e.mpisi.com. (40)
23:05:44.378640 IP 204.92.73.10.62484 > xx.xx.xx.xx.53: 8726+ [1au] ANY AN=
Y? e.mpisi.com. (40)
23:05:45.368970 IP 204.92.73.10.57384 > xx.xx.xx.xx.53: 1073+ [1au] ANY AN=
Y? e.mpisi.com. (40)
23:05:45.379251 IP 204.92.73.10.36997 > xx.xx.xx.xx.53: 22257+ [1au] ANY A=
NY? e.mpisi.com. (40)
<snap>

Has anyone noticed a similar activity?


Best regards,
Piotr Kamisi=F1ski
--827350393-698970637-1133130621=:14403--

[Spammeanddie]

YEah dude nice shit...!! :) I could poisoning rpc with this... :) 0day

[Alexander Lourier]

--nextPart5783433.nMLYZzqYj9
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 28 November 2005 01:30, Piotr Kamisiski wrote:

> Recently my DNS servers get jammed with bogus queries. The attacks come in
> series, taking a few minutes each, sometimes from different IPs at the
> same time, at least twice a day.

My DNS servers were attacked the similar way in the beginning of this year.=
=20
All queries were originated from a lot of sources. Senders of these packets=
=20
were not bogus obviously, because after firewalling incoming requests from=
=20
any of them, the rate of flooding became lower. All requests were made to o=
ne=20
of my domains.

Daily DNS traffic was about 400-500 Mb.

To automate the firewalling process I wrote a program, that sniffed DNS=20
traffic and automatically added to firewall DROP rules.

=2D-=20
Best regards. Alexander Lourier. http://aml.rulezz.ru

--nextPart5783433.nMLYZzqYj9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDi/qkN3YSiWvz6qMRAqemAKC8u/YkJ3GcW1z1E/FbpPsWSk4GowCgvTSE
1mxugZUEF1MfCV6D677yfLY=
=p6M0
-----END PGP SIGNATURE-----

--nextPart5783433.nMLYZzqYj9--

[Josep Ma Castells]

I have the same problem, now I'm blocking this attempts with iptables and
the Recent module when a number of tries is reached.

This is the content of the packet:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+=+=+=+=+=+=+=+=+=+=+

11/20/05-19:17:37.177173 168.143.XXX.XX:11752 -> YYY.YYY.Y.YY:53
UDP TTL:233 TOS:0x0 ID:34960 IpLen:20 DgmLen:68 DF
Len: 48
0x0000: 00 07 95 C2 6A 32 00 04 76 DA CB 14 08 00 45 00 ....j2..v.....E.
0x0010: 00 44 88 90 40 00 E9 11 2A D5 A8 8F 71 0A C0 A8 .D..@...*...q...
0x0020: 04 01 2D E8 00 35 00 30 00 00 20 9E 01 00 00 01 ..-..5.0.. .....
0x0030: 00 00 00 00 00 01 01 65 05 6D 70 69 73 69 03 63 .......e.mpisi.c
0x0040: 6F 6D 00 00 FF 00 FF 00 00 29 27 10 00 00 00 00 om.......)'.....
0x0050: 00 00 ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+=+=+=+=+=+=+=+=+=+=+

Regards,


Josep Ma Castells



----- Original Message -----
From: "Piotr Kamisiski" <rotunda@ktd.krakow.pl>
To: <bugtraq@securityfocus.com>
Sent: Sunday, November 27, 2005 11:30 PM
Subject: DNS query spam



Hi all,

Recently my DNS servers get jammed with bogus queries. The attacks come in
series, taking a few minutes each, sometimes from different IPs at the
same time, at least twice a day.

<snap>
23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53: 38545+ [1au] ANY
ANY? e.mpisi.com. (40)
23:05:41.600902 IP 204.92.73.10.16561 > xx.xx.xx.xx.53: 22242+ [1au] ANY
ANY? e.mpisi.com. (40)
23:05:42.091743 IP 204.92.73.10.37547 > xx.xx.xx.xx.53: 64644+ [1au] ANY
ANY? e.mpisi.com. (40)
23:05:43.433539 IP 204.92.73.10.32370 > xx.xx.xx.xx.53: 31772+ [1au] ANY
ANY? e.mpisi.com. (40)
23:05:43.854481 IP 204.92.73.10.12913 > xx.xx.xx.xx.53: 33470+ [1au] ANY
ANY? e.mpisi.com. (40)
23:05:44.378640 IP 204.92.73.10.62484 > xx.xx.xx.xx.53: 8726+ [1au] ANY
ANY? e.mpisi.com. (40)
23:05:45.368970 IP 204.92.73.10.57384 > xx.xx.xx.xx.53: 1073+ [1au] ANY
ANY? e.mpisi.com. (40)
23:05:45.379251 IP 204.92.73.10.36997 > xx.xx.xx.xx.53: 22257+ [1au] ANY
ANY? e.mpisi.com. (40)
<snap>

Has anyone noticed a similar activity?


Best regards,
Piotr Kamisiñski

[Antone Roundy]

On Nov 27, 2005, at 3:30 PM, Piotr Kamisiski wrote:
> Recently my DNS servers get jammed with bogus queries. The attacks
> come in series, taking a few minutes each, sometimes from different
> IPs at the same time, at least twice a day.
>
> <snap>
> 23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53: 38545+
> [1au] ANY ANY? e.mpisi.com. (40)
> 23:05:41.600902 IP 204.92.73.10.16561 > xx.xx.xx.xx.53: 22242+
> [1au] ANY ANY? e.mpisi.com. (40)
> 23:05:42.091743 IP 204.92.73.10.37547 > xx.xx.xx.xx.53: 64644+
> [1au] ANY ANY? e.mpisi.com. (40)
> 23:05:43.433539 IP 204.92.73.10.32370 > xx.xx.xx.xx.53: 31772+
> [1au] ANY ANY? e.mpisi.com. (40)
> 23:05:43.854481 IP 204.92.73.10.12913 > xx.xx.xx.xx.53: 33470+
> [1au] ANY ANY? e.mpisi.com. (40)
> 23:05:44.378640 IP 204.92.73.10.62484 > xx.xx.xx.xx.53: 8726+
> [1au] ANY ANY? e.mpisi.com. (40)
> 23:05:45.368970 IP 204.92.73.10.57384 > xx.xx.xx.xx.53: 1073+
> [1au] ANY ANY? e.mpisi.com. (40)
> 23:05:45.379251 IP 204.92.73.10.36997 > xx.xx.xx.xx.53: 22257+
> [1au] ANY ANY? e.mpisi.com. (40)
> <snap>
>
> Has anyone noticed a similar activity?

I was seeing this kind of thing last month. I suspect that it's part
of a DDoS attack on the IP address that the queries claim to come
from, but it could also be an attack on your DNS server. The idea is
that the attacker sends a small bogus DNS query on UDP port 53 with a
bogus IP address. Your server then sends a much larger response to
that IP address, greatly multiplying the amount of traffic that the
attacker can direct at the target site. This occurs via UDP since
that makes it easy to spoof the source address.

Assuming you use Bind, can edit your named.conf file, only wish to
provide recursive DNS services (ie. handle queries for domains that
you are not authoritative for) to a known range of IP addresses, and
the query is for a domain that you're not authoritative for, you can
solve the problem by adding something like this to named.conf:

options {
allow-recursion { 127.0.0.1/32; };
};

That particular setting would cause Bind to ignore recursive queries
from all IP addresses except 127.0.0.1 (localhost). My DNS server
only provides recursive queries for itself, so the setting was easy
for me. After I started blocking recursive queries, it took a week
or so for the bogus traffic to stop. But in the mean time, since I
wasn't sending responses, the amount of my bandwidth that was wasted
decreased dramatically.

[Piotr Kamisiski]

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--827350393-1324645494-1133283461=:17489
Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE


Hello

Thanks for your response.

The requests don't contain OPT records, but the data I've analysed doesn't=
=20
cover the most intense attacks. Today has been particularly quiet. I'll=20
wait to accumulate more data.

On Tue, 29 Nov 2005, Florian Weimer wrote:

> * Piotr Kamisiski:
>
>> 23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53: 38545+ [1au] AN=
Y 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.
>
> 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.
>
> Yet another reason to restrict access to your recursive resolvers to
> customers only.
>


Best regards,
Piotr Kamisi=F1ski
--827350393-1324645494-1133283461=:17489--

[Florian Weimer]

* 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.

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.

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

[Jim Pingle]

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.

[Florian Weimer]

* Josep Ma Castells:

> I have the same problem, now I'm blocking this attempts with iptables and
> the Recent module when a number of tries is reached.
>
> This is the content of the packet:
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+=+=+=+=+=+=+=+=+=+=+
>
> 11/20/05-19:17:37.177173 168.143.XXX.XX:11752 -> YYY.YYY.Y.YY:53
> UDP TTL:233 TOS:0x0 ID:34960 IpLen:20 DgmLen:68 DF
> Len: 48
> 0x0000: 00 07 95 C2 6A 32 00 04 76 DA CB 14 08 00 45 00 ....j2..v.....E.
> 0x0010: 00 44 88 90 40 00 E9 11 2A D5 A8 8F 71 0A C0 A8 .D..@...*...q...
> 0x0020: 04 01 2D E8 00 35 00 30 00 00 20 9E 01 00 00 01 ..-..5.0.. .....
> 0x0030: 00 00 00 00 00 01 01 65 05 6D 70 69 73 69 03 63 .......e.mpisi.c
> 0x0040: 6F 6D 00 00 FF 00 FF 00 00 29 27 10 00 00 00 00 om.......)'.....
> 0x0050: 00 00 ..
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+=+=+=+=+=+=+=+=+=+=+

Interesting. This packet allegedly came from www.anonymizer.com
(168.143.113.10). It apparently has undergone NAT, so its contents
might have been garbled, but: In contrast to Piotr's packets, this one
does contain an OPT RR (type 0x29). The sender buffer length (encoded
in the class field of the RR) is set to 10000.

[Stephen Stuart]

> Assuming you use Bind, can edit your named.conf file, only wish to
> provide recursive DNS services (ie. handle queries for domains that
> you are not authoritative for) to a known range of IP addresses, and
> the query is for a domain that you're not authoritative for, you can
> solve the problem by adding something like this to named.conf:
>
> options {
> allow-recursion { 127.0.0.1/32; };
> };
>
> That particular setting would cause Bind to ignore recursive queries
> from all IP addresses except 127.0.0.1 (localhost). My DNS server
> only provides recursive queries for itself, so the setting was easy
> for me. After I started blocking recursive queries, it took a week
> or so for the bogus traffic to stop. But in the mean time, since I
> wasn't sending responses, the amount of my bandwidth that was wasted
> decreased dramatically.

Small correction: that will cause BIND to not perform recursive
queries from any IP address except 127.0.0.1. You will still answer
queries from cache for all comers, unless you also restrict queries in
general to 127.0.0.1/32:

options {
allow-query { 127.0.0.1/32; };
};

Stephen

[Joe]

Would you be able to share the iptables rules you're using to combat this?

Thanks


Josep Ma Castells wrote:
> I have the same problem, now I'm blocking this attempts with iptables
> and the Recent module when a number of tries is reached.
>
> This is the content of the packet:
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+=+=+=+=+=+=+=+=+=+=+
>
> 11/20/05-19:17:37.177173 168.143.XXX.XX:11752 -> YYY.YYY.Y.YY:53
> UDP TTL:233 TOS:0x0 ID:34960 IpLen:20 DgmLen:68 DF
> Len: 48
> 0x0000: 00 07 95 C2 6A 32 00 04 76 DA CB 14 08 00 45 00 ....j2..v.....E.
> 0x0010: 00 44 88 90 40 00 E9 11 2A D5 A8 8F 71 0A C0 A8 .D..@...*...q...
> 0x0020: 04 01 2D E8 00 35 00 30 00 00 20 9E 01 00 00 01 ..-..5.0.. .....
> 0x0030: 00 00 00 00 00 01 01 65 05 6D 70 69 73 69 03 63 .......e.mpisi.c
> 0x0040: 6F 6D 00 00 FF 00 FF 00 00 29 27 10 00 00 00 00 om.......)'.....
> 0x0050: 00 00 ..
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+=+=+=+=+=+=+=+=+=+=+=+
>
> Regards,
>
>
> Josep Ma Castells
>
>
>
> ----- Original Message ----- From: "Piotr Kamisiski"
> <rotunda@ktd.krakow.pl>
> To: <bugtraq@securityfocus.com>
> Sent: Sunday, November 27, 2005 11:30 PM
> Subject: DNS query spam
>
>
>
> Hi all,
>
> Recently my DNS servers get jammed with bogus queries. The attacks come in
> series, taking a few minutes each, sometimes from different IPs at the
> same time, at least twice a day.
>
> <snap>
> 23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53: 38545+ [1au]
> ANY ANY? e.mpisi.com. (40)
> 23:05:41.600902 IP 204.92.73.10.16561 > xx.xx.xx.xx.53: 22242+ [1au]
> ANY ANY? e.mpisi.com. (40)
> 23:05:42.091743 IP 204.92.73.10.37547 > xx.xx.xx.xx.53: 64644+ [1au]
> ANY ANY? e.mpisi.com. (40)
> 23:05:43.433539 IP 204.92.73.10.32370 > xx.xx.xx.xx.53: 31772+ [1au]
> ANY ANY? e.mpisi.com. (40)
> 23:05:43.854481 IP 204.92.73.10.12913 > xx.xx.xx.xx.53: 33470+ [1au]
> ANY ANY? e.mpisi.com. (40)
> 23:05:44.378640 IP 204.92.73.10.62484 > xx.xx.xx.xx.53: 8726+ [1au] ANY
> ANY? e.mpisi.com. (40)
> 23:05:45.368970 IP 204.92.73.10.57384 > xx.xx.xx.xx.53: 1073+ [1au] ANY
> ANY? e.mpisi.com. (40)
> 23:05:45.379251 IP 204.92.73.10.36997 > xx.xx.xx.xx.53: 22257+ [1au]
> ANY ANY? e.mpisi.com. (40)
> <snap>
>
> Has anyone noticed a similar activity?
>
>
> Best regards,
> Piotr Kamisiñski
>
>

[fugi@bl.org]

DNS traffic is UDP, source is spoofed, you setup a large record and request it from the victim's IP to a list of nameservers.

http://packetstormsecurity.org/DoS/ihateperl.pl

nothing new

[Piotr Kamisiski]

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--827350393-1507159068-1133467202=:24322
Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE


Ok, nice that this has been clarified. I'm still wondering why this kind=20
of attack reached me just recently, considering the method has been known=
=20
for a long time.

On Tue, 29 Nov 2005, fugi@bl.org wrote:

> DNS traffic is UDP, source is spoofed, you setup a large record and reque=
st it from the victim's IP to a list of nameservers.
>
> http://packetstormsecurity.org/DoS/ihateperl.pl
>
> nothing new
>


Best regards,
Piotr Kamisi=F1ski
--827350393-1507159068-1133467202=:24322--