[dns-operations] Effectivity of filter lists against DNS amplification attacks

[David Miller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/17/2012 6:22 AM, Daniel Stirnimann wrote:
> Hi Klaus
> 
> On one of our name server which is secondary for a little over one 
> thousand second level domains has been abused for DNS
> Amplification Attacks since November 2011.
> 
> There has not been a single week without such traffic. So, it is
> not decreasing at all. Since May 2012 we are rate-limiting outgoing
> ANY queries but this has not resulted in a decrease of such
> traffic.
> 
> The most common DNS Amplification Attack traffic we are seeing is
> what is described in this ISC Diary post: 
> https://isc.sans.edu/diary/DNS+ANY+Request+Cannon+-+Need+More+Packets/13261

We
> 
have seen this exact same traffic since December 2011 to our
networks.  We have been rate limiting this traffic on our networks
since the beginning and the traffic occurrence and volume have not
changed.

We see most of this traffic between 02:00 and 18:00 UTC.  This matches
a diurnal cycle for parts of Asia.  Our original assumption was that
this traffic was being driven by a person (or people) who were taking
time off to sleep.

Everyone seeing this traffic, that I have heard from, is either
blocking or rate limiting this traffic.  So, this attack is wasting
the vast majority of their attack bandwidth for no downstream effect.

Either this is the most persistent attacker that I have EVER seen -or-
this traffic is being generated by an automated system that someone
fired and forgot.

I could provide many different theories as to the possible reasons for
an automated system that generates this traffic, but until the source
is found and examined it would all be wild conjecture.

One thing that I can say with great certainty is that all of this
traffic that is hitting our networks is emanating from China Unicom
(AS4837).  Not some of the traffic, or most of the traffic, or almost
all of the traffic - ALL of the traffic.  I know this with certainty
because:
1. I can easily and with complete repeatability bounce this traffic
between our providers and locations by using BGP no-announce
communities on our announcements specifying AS4837.

2. I have herded all this traffic entering our network on one provider
to a particular location and had our provider pull netflows from their
peering router at that location and all of this traffic came in the
AS4837 (China Unicom) port.

We have contacted China Unicom multiple times.  They were unresponsive.

We have had our upstream that collected netflows for us (so, they have
actual data) contact China Unicom.  They were unresponsive.

We have contacted CNCERT.  They have been very responsive, but all
they can do is pass messages to China Unicom (who has remained
unresponsive).

Most (but not all) of the spoofed sources that we see are from China
Telecom space.  We have contacted China Telecom multiple times.  They
were unresponsive.

I have considered other actions that we could take, but they would be
irresponsible, so I haven't taken them yet.

The traffic levels that we see are only an annoyance to us and they
don't appear to be large enough to get the actual attention of any of
the providers involved on any side.  Perhaps public naming and shaming
will draw their attention.

- -DMM

> Regards, Daniel
> 
> On 17.08.12 10:03, Klaus Darilion wrote:
>> Hi!
>> 
>> Lately, there was much discussion and examples on how to block
>> the DNS requests of DNS Amplification Attacks. Such filters
>> prevent the name server seeing the request, thus of course
>> massively reducing the outgoing traffic. But such filters can not
>> reduce the incoming traffic - the attacker will still send the
>> DNS requests.
>> 
>> Thus, I would be interested in the results of such filters. Do
>> you see, maybe not in short-term but in long-term, that the
>> incoming attack traffic also decreases?
>> 
>> Thanks Klaus _______________________________________________ 
>> dns-operations mailing list dns-operations at lists.dns-oarc.net 
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations 
>> dns-jobs mailing list 
>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>> 
> _______________________________________________ dns-operations
> mailing list dns-operations at lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs
> mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQLpUfAAoJECp6zT7OFmGayYcH/2mlExuw5K3S9v8SYC0HTrw4
seOZ4cOuvCwPyKWTTZ18b1KKuYJKRQAfaR00hOvbSoPhG3jXoCWAYvhFpACChL+e
rKIGS1uKoxSm+irDVkmJOUtIhRc3lQjtGn+bE2W259rcfWvLOT6OmQK9TjsGuCUB
9l7JAWPek6K4wHfiFNZVP5e7N3CbuLVuXgWDoLL1MP/GpGsy40P5BLXX2KR1ScH1
+tzfq+yop/SFSc+QxANtu++bLP6dx0lvVglyWPVSVH/19G8xlZfrCZf0ufTmqbWA
2OO0Wlk/t1FLyfD45Rz5kwsBy6iXNdl9TDW08IcwQJ8Bhkmi+MAe6fGmPZpoBYM=
=uWIx
-----END PGP SIGNATURE-----