-----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@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@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----- _______________________________________________ dns-operations mailing list dns-operations@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
