On 8/17/2012 8:03 AM, Klaus Darilion wrote: > 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.
noting: there is no way to confidently know that an incoming request is junk unless your decision-making process is inside of the name server itself. no load balancer or firewall or similar technology operating upstream of the name server can achieve the same low level of false-positive or false-negative as can be had when the "drop or not?" logic has direct access to a dns cache. one such inside-the-server solution, available without fee, crafted for use with BIND9, is DNS RRL. see <http://www.redbarn.org/dns/ratelimits> for details on that. > 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? as to the question of filtering attacks when your infrastructure is the target not the midspan reflecting amplifier, the fundamental problem is the attacker's ability to forge your IP addresses on queries sent to distant reflectors. this makes it nearly impossible to find the injection point, and the midspan reflectors in this case are usually just authoritative name servers "doing their job". the most effective way to get an attack like this to stop is to visit or contact the operators of the reflecting amplifying authority name servers and tell them how they can "rate limit" their responses to queries they think came from your network, as in DNS RRL above or anything similar you can find. or, in the rare case where the amplifier is a recursive not an authority server, you can ask its operator to add an "ACL" so that they only serve client-IP addresses within their own network (see RFC 5358.) that's problematic, but filtering it on your end is even more problematic. assuming you can establish filters far enough away from your network that your internet connection isn't already crushed by the point at which you can drop packets, and that you can drop packets at line rate with complex filtering rules at that faraway location, you will find that the best you can do is drop by source IP address rather than by some kind of DPI. you can renumber your own name servers so that the attacker will be spoofing a source-IP that you're no longer using, but that's whack-a-mole (the attacker can rotate weapons frequencies faster than you can rotate shield frequencies, to throw in a ST:TNG "Borg" reference.) this is an embarrassing botch in the internet infrastructure. the necessary invariants for "wide area UDP" were violated starting in 1994 with commercialization and privatization of the internet, and we've been running bare ass naked through the woods, covered in honey, ever since then. paul _______________________________________________ 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
