Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 31.10.2012 02:52, Dobbins, Roland wrote: On Oct 31, 2012, at 4:37 AM, Florian Weimer wrote: Reflection attacks do not use totally random source addresses, so the typically state exhaustion vector does not necessarily apply. There are many more types of attacks other than reflection/amplification attacks, though, and it's those to which I was referring - sorry for being unclear. Agreed. That's why I mentioned that our iptables based rate limiting only mitigates the current ANY amplification attacks, not all kind of attacks. regards 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Klaus Darilion wrote: Agreed. That's why I mentioned that our iptables based rate limiting only mitigates the current ANY amplification attacks, not all kind of attacks. I did see some attacks with repeated DNSKEY queries. Dampening catched them. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Roland Dobbins: If the rate-limiting is based upon source IPs, then there's potentially a lot of state there. If the rate-limiting is based upon the destination IP, then it guarantees that programmatically-generated attack traffic will 'crowd out' legitimate requests. Reflection attacks do not use totally random source addresses, so the typically state exhaustion vector does not necessarily apply. (With IPv6, there more bits which could be abused for randomness, but then, a contradiction between the specification and deployed stacks make it impossible to serve IPv6 traffic in a stateless fashion, so the entire discussion is pointless.) ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 29, 2012, at 4:28 PM, Klaus Darilion wrote: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall is that it makes it susceptible to trivial state-exhaustion attacks. This is not a good idea. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Mon, Oct 29, 2012 at 10:13:55AM +, Dobbins, Roland rdobb...@arbor.net wrote a message of 20 lines which said: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall ? iptables != stateful firewalling. Some people are careless enough to use iptables modules with connection tracking (very bad idea for the DNS, for the reasons you explain) but others are more careful (rate-limiting requires only a small amount of state). ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 29, 2012, at 5:16 PM, Stephane Bortzmeyer wrote: ? iptables != stateful firewalling. I've only ever seen it deployed with connection tracking - i.e., statefully. You're right, though, that isn't a requirement. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Mon, Oct 29, 2012 at 10:21:46AM +,
Dobbins, Roland rdobb...@arbor.net wrote
a message of 20 lines which said:
I've only ever seen it deployed with connection tracking - i.e.,
statefully.
Several TLD use iptables for rate-limiting ANY amplification
attacks. They typically use the hashlimit module, which does not
activate connection tracking (which is mostly useless for DNS, anyway).
iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP
Or, if you want to rate-limit only some patterns (ANY ripe.net...):
wget http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py
then:
domain=ripe.net
action=RATELIMITER
action=LOG --log-prefix DNS-ANY-query-$domain
rule=$(python generate-netfilter-u32-dns-rule.py --qname $domain --qtype ANY)
iptables --append INPUT --destination ${MYSERVICEIPADDRESS} --protocol udp
--destination-port 53 \
--match u32 --u32 $rule \
--jump ${action}
iptables -A ${action} -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP
___
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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 29.10.2012 11:13, Dobbins, Roland wrote: On Oct 29, 2012, at 4:28 PM, Klaus Darilion wrote: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall is that it makes it susceptible to trivial state-exhaustion attacks. This is not a good idea. It depends on the implementation of the firewall. For example most iptables modules which saves states have a limited number of resources to keep state. If the max. number of entries is reached, it usually deletes an old one. So, the result may not be perfect, but it is better then no rules at all. And as I said, it is not a general solution but works fine for us. Sometimes it is simpler to wait and watch what the attackers do, and if the attacks are getting to noisy, do something effective against it. Thinking of all possible scenarios that an attacker could do and then finding an solution which handles all of these scenarios is sometimes not worth the effort, especially as we see amplification attacks not as a real serious problem for our name servers, but just annoying. regards 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 2012-10-29, at 06:16, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Oct 29, 2012 at 10:13:55AM +, Dobbins, Roland rdobb...@arbor.net wrote a message of 20 lines which said: We apply iptables based rate-limiting on ANY queries with RD bit set. The problem with fronting your DNS servers with a stateful firewall ? iptables != stateful firewalling. no, rate-limiting == stateful firewalling. (I appreciate that there are techniques available to keep the state manageable, but state is required to rate-limit and retaining state in front of DNS servers in general ought indeed to prompt some careful thinking before implementation.) Joe ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 30, 2012, at 12:54 AM, Joe Abley wrote: (I appreciate that there are techniques available to keep the state manageable, but state is required to rate-limit and retaining state in front of DNS servers in general ought indeed to prompt some careful thinking before implementation.) Concur. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Paul Vixie wrote: until cisco makes source address validation the default, we have no tools available to thwart ddos, other than clever hacks. While we may not have any tools to fight DDoS per se, we do have one to combat _amplification_ attacks: it's called TCP. Yes, it does come at a cost, but no one said we could cut corners forever, be it by using UDP DNS outside LANs or by rate-limiting unvalidated source addresses. (Now why does this remind me of the DNSSEC debate?) There's no easy way out, there's no shortcut home ... ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Roland, On Friday, 2012-10-26 01:48:44 +, Dobbins, Roland rdobb...@arbor.net wrote: On Oct 26, 2012, at 8:33 AM, Mark Andrews wrote: We essentially have the infrastructure to do this today. Not all (not even most) network infrastructure is connected to or even has connectivity to the public Internet. Yeah, that's not the infrastructure we care about, since that is not spoofing source addresses on the public Internet. -- Shane ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 26, 2012, at 6:04 PM, Shane Kerr wrote: Yeah, that's not the infrastructure we care about, since that is not spoofing source addresses on the public Internet. The point is that the network infrastructure vendors will not invest a lot of time and resources, at least not given the current state of affairs, in trying to tie their network infrastructure gear into any kind of delegation certification PKI infrastructure, as most of the gear they sell isn't connected to the Internet and hasn't any way to connect to the putative delegation PKI system. Another point is that, given the various controversies in the 'classic' DNS space with regards to various domain takedowns for reasons other than straightforward abuse, the benefits of such a system vs. its potential susceptibility to legislative and regulatory incursions isn't a settled issue (the same concerns apply in the routing space, as well as with regards to DNSSEC). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 26, 2012, at 7:24 PM, wbr...@e1b.org wrote: If so, why can't they block anything outside that range. This is the perpetual refrain questioning why BCP84 hasn't been universally implemented. Lack of clue, lack of perceived economic incentive, lack of infrastructure capability (though the natural cycle of equipment upgrades has largely eliminated this issue on networks running even semi-modern gear), apathy, sloth, venality. In the main, it isn't a question of 'can't' - it's a question of 'won't'. Which is why Paul was saying that network infrastructure vendors should by default enable various anti-spoofing mechanisms on the gear they well. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
From: Dobbins, Roland rdobb...@arbor.net this sounds like a new application of 'the chemical polluter business model'. There's more to it than that, though. It's important to understand that those who are purchasing and deploying network gear often are nonspecialists, and so frustrations, project delays, etc. would crop up in the customer organizations - who would then complain... but that *IS* 'the chemical polluter business model' which is also the spam problem which is also the tragedy of too many sheep on the commons. It's cheaper and easier in the short term to pollute, ignore spammers, and over graze the commons. The bosses of the shepherds, abuse desks, and refinery engineers hear only about the costs and problems of not overgrazing, terminating profitable accounts, and not polluting. Vernon Schryverv...@rhyolite.com ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
paul vixie p...@redbarn.org wrote on 10/26/2012 10:32:57 AM: i just don't see it. there isn't more to it than that. from the point of view of everyone on the connected internet, it is a bad idea to let some new person connect some new router that forwards packets, if that person is unaware of the s.a.v. issue. if a vendor won't make s.a.v. the default because they need the new business and they don't want the training burden of making sure they understand the issues of s.a.v., then they are following the 'chemical polluter business model' where the money is made here and the impact is only felt over there. I'm not an internet routing guru, so I must not be seeing something. When my organization connects to an upstream provider, they know we have a block of addresses assigned (Actually, we have more than one). They know that we connect to their switch in rack X, switch Y, port Z. If they see a packet with a source address of 8.8.8.8 appearing on that port, what possible reason could they have for allowing it through? Obviously, that's a Google address, and possibly forged a lot. I just don't see why a packet claiming to be from an address we do not own should be coming from our net. Can anyone explain why that would happen (other than forgery)? I looked at BCP84/RFC3704, but as a non-networking person, it was brushing the bald-spot. I know this is drifting from the list topic, so thank you for the indulgence. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Original Message- From: paul vixie p...@redbarn.org Date: Friday, October 26, 2012 10:32 AM To: Dobbins, Roland rdobb...@arbor.net Cc: DNS Operations List dns-operati...@mail.dns-oarc.net Subject: Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks On 10/26/2012 7:11 AM, Dobbins, Roland wrote: On Oct 26, 2012, at 11:19 AM, paul vixie wrote: this sounds like a new application of 'the chemical polluter business model'. There's more to it than that, though. It's important to understand that those who are purchasing and deploying network gear often are nonspecialists, and so frustrations, project delays, etc. would crop up in the customer organizations - who would then complain vociferously to the network infrastructure vendors and/or simply switch to a vendor which didn't enable anti-spoofing as a default. i just don't see it. there isn't more to it than that. from the point of view of everyone on the connected internet, it is a bad idea to let some new person connect some new router that forwards packets, if that person is unaware of the s.a.v. issue. if a vendor won't make s.a.v. the default because they need the new business and they don't want the training burden of making sure they understand the issues of s.a.v., then they are following the 'chemical polluter business model' where the money is made here and the impact is only felt over there. i kinda see both sides, but then i'm not in the argument. :-) i think there's a reason OSS (let's forget commercial interests for a moment) distributions ship with firewalls that have been standard for years either disabled or running entirely open... despite many documented best practices you don't want to keep most systems running that way for long. some might even argue narrow windows of time with open firewall rules allow the determined attacker (or botnet worms) to access available attack vectors, such that locking down hosts as an afterthought doesn't add much value. to further the analogy, new users are the ones who would be most confused by a freshly installed OSS distribution that won't connect to anything...but it doesn't at all negate the necessity of a properly configured firewall -- especially for new users who might do things like connect their shiny new laptop to a insert_favorte_coffee_shop access point full of evil hackers and then carry it inside the shroud of corporate security (this of course isn't limited to OSS, with BYOD and iWhatzits and droids). so i appreciate both sides, but i think there's something larger afoot...human psychology perhaps. i do plan to raise this (to the best of my ability) through engineering management and at least start a discussion. challenging current norms is always a healthy exercise that at least gets people thinking. as mentioned, i came to cisco through acquisition (like so many others), and am positioned in the security BU...so i can at least present both sides to folks higher up the food chain (and smarter than me) then let them make an informed decision. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 26, 2012, at 9:32 PM, paul vixie wrote: i just don't see it. Ah, but I *did* see it when I worked for a major vendor of telecommunications equipment. I agree with you - I wish anti-spoofing were enabled by default. I'm not defending the status quo, just trying to explain why it isn't enabled by default, as well as why it isn't likely to be enabled by default anytime soon, absent some significant technical innovation (which I don't see happening due to the nature of TCP/IP) or major catastrophe which changes the perceived economics of the current situation both for network infrastructure vendors as well as for customer organizations. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 10/26/2012 3:15 PM, wbr...@e1b.org wrote: paul vixie p...@redbarn.org wrote on 10/26/2012 10:32:57 AM: ... they are following the 'chemical polluter business model' where the money is made here and the impact is only felt over there. I'm not an internet routing guru, so I must not be seeing something. When my organization connects to an upstream provider, they know we have a block of addresses assigned (Actually, we have more than one). They know that we connect to their switch in rack X, switch Y, port Z. If they see a packet with a source address of 8.8.8.8 appearing on that port, what possible reason could they have for allowing it through? the cost of finding out from you which source ip address ranges are valid for your interface, programming their routing equipment, dealing with the error rate inevitable in all human-related systems, and auditing all of this is measurably non-zero. this is what experienced providers call a 'one-off'. to the extent that they can make your interface with what many providers call a 'cookie cutter' -- that is, all alike -- they will spend measurably less money delivering their service to you. ... I looked at BCP84/RFC3704, but as a non-networking person, it was brushing the bald-spot. the non-networking person version (sometimes called the 'pointy haired boss version') is called 'SAC004' and was written by me ten years ago (october 2002): http://archive.icann.org/en/committees/security/sac004.txt. I know this is drifting from the list topic, so thank you for the indulgence. source address validation is very important to dns operations; i don't consider this thread off-topic. 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Lutz Donnerhacke wrote: If they are optimal or not is still an open question. But the patch is useable now. Far from perfect or finished, but used in practice. I was able to collect some statistics and keep an eye on the attacks itself. Interestingly the attackers seem to honor the RRL defaults and apply their attacks in a way to render this patch useless. http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening-under-the-microscope ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 10/25/2012 5:08 PM, Michael Hoskins (michoski) wrote: ... Seems to show clever hacks can be useful (looks good for roots), but don't generally work against real hackers who typically read lists (and source code). :-) until cisco makes source address validation the default, we have no tools available to thwart ddos, other than clever hacks. all of which will have serious limitations in the face of a determined attacker. however, there are not very many determined attackers. michael, please send diffs to http://ss.vix.com/~vixie/isc-tn-2012-1.txt section 5, which currently reads: 5 - Attacker Behaviour 5.1. A forged-source reflective amplifying attacker who wants to be successful will either have to select authority servers who do not practice rate limiting yet, or will have to select a large number of authority servers and use round robin to distribute the attack flows. Each authority server will have to be asked a question within one of that server's zones chosen at random in order to get an amplification effect. An attacker would do well to select DNSSEC-signed zones and to use DNSSEC signalling in their forged queries to maximize response size. This will be more effective than QTYPE ANY queries which are often blocked altogether due to their diagnostic rather than operational purpose. thanks, 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
-Original Message- From: paul vixie p...@redbarn.org Date: Thursday, October 25, 2012 1:48 PM To: Mike Hoskins micho...@cisco.com Cc: Lutz Donnerhacke l...@iks-jena.de, dns-operati...@mail.dns-oarc.net dns-operati...@mail.dns-oarc.net Subject: Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks On 10/25/2012 5:08 PM, Michael Hoskins (michoski) wrote: ... Seems to show clever hacks can be useful (looks good for roots), but don't generally work against real hackers who typically read lists (and source code). :-) until cisco makes source address validation the default, we have no tools available to thwart ddos, other than clever hacks. all of which will have serious limitations in the face of a determined attacker. however, there are not very many determined attackers. Fair enough. I got sucked into the mother ship via acquisition, but come from a past ISP/NSP background and truly appreciate this nudge. The wheels of big enterprise often turn slowly (some times for good reason), and I'm a lowly peon, but I will see if I can escalate this internally considering the source. We used to ship PIX/ASA fixups that broke EDNS by default, and the latest ASA policy maps don't...so I'm cautiously optimistic we can do our part. https://supportforums.cisco.com/thread/2013390 http://www.cisco.com/web/about/security/intelligence/dnssec.html (The latter points directly to the OARC response size test, great tool.) ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 10/25/2012 1:48 PM, paul vixie wrote: On 10/25/2012 5:08 PM, Michael Hoskins (michoski) wrote: ... Seems to show clever hacks can be useful (looks good for roots), but don't generally work against real hackers who typically read lists (and source code). :-) until cisco makes source address validation the default, we have no tools available to thwart ddos, other than clever hacks. all of which will have serious limitations in the face of a determined attacker. however, there are not very many determined attackers. michael, please send diffs to http://ss.vix.com/~vixie/isc-tn-2012-1.txt section 5, which currently reads: 5 - Attacker Behaviour 5.1. A forged-source reflective amplifying attacker who wants to be successful will either have to select authority servers who do not practice rate limiting yet, or will have to select a large number of authority servers and use round robin to distribute the attack flows. Each authority server will have to be asked a question within one of that server's zones chosen at random in order to get an amplification effect. An attacker would do well to select DNSSEC-signed zones and to use DNSSEC signalling in their forged queries to maximize response size. This will be more effective than QTYPE ANY queries which are often blocked altogether due to their diagnostic rather than operational purpose. Is it actually the case that QTYPE ANY queries are often blocked altogether? thanks, 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 ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
In message 97cf47cd-7815-489e-bd6b-bc14fb2b3...@arbor.net, Dobbins, Roland writes: On Oct 26, 2012, at 12:48 AM, paul vixie wrote: until cisco makes source address validation the default Unfortunately, neither Cisco nor any other network infrastructure vendor will do this absent some fundamental breakthrough in anti-spoofing mechanisms, be cause there are too many topological situations in which the primary existing mechanism (uRPF, ACLs) can induce overblocking. We essentially have the infrastructure to do this today. We have certs for address delegations. They can be used to sign server certs which can then sign I will be sourcing from these prefixes anouncements which can in turn let correct authenticated source address filters be produced. This would cover most end site requirements. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 26, 2012, at 8:33 AM, Mark Andrews wrote: We essentially have the infrastructure to do this today. Not all (not even most) network infrastructure is connected to or even has connectivity to the public Internet. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Roland, I'm not asking that source address validation be hardwired. Merely the default. I don't think any of us want new operators forwarding packets even in disconnected networks if they don't understand these issues. Let the default for new routers be s.a.v. and I don't expect much trouble. Leave the default as is and I'll expect linear trouble with growth. Paul Dobbins, Roland rdobb...@arbor.net wrote: On Oct 26, 2012, at 12:48 AM, paul vixie wrote: until cisco makes source address validation the default Unfortunately, neither Cisco nor any other network infrastructure vendor will do this absent some fundamental breakthrough in anti-spoofing mechanisms, because there are too many topological situations in which the primary existing mechanism (uRPF, ACLs) can induce overblocking. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ 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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 10/26/2012 3:33 AM, Dobbins, Roland wrote: On Oct 26, 2012, at 9:38 AM, P Vixie wrote: Let the default for new routers be s.a.v. and I don't expect much trouble. The problem is that the increase in helpdesk call volume and trouble-tickets will have a negative economic impact on the infrastructure vendors. Believe me, this has been a source of contentious debate within major network infrastructure vendors. Like you, I wish it could be the default; but, absent some mechanism which doesn't cause problems in some non-isignificant fractions of deployment scenarios, it isn't going to happen. this sounds like a new application of 'the chemical polluter business model'. 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Lutz Donnerhacke wrote:
The defaults are not optimal yet.
If they are optimal or not is still an open question. But the patch is
useable now. Far from perfect or finished, but used in practice.
http://altlasten.lutz.donnerhacke.de/mitarb/lutz/bind-9.9.2-dampening.patch
Unfortunly I do have a serious problem: The attack volume decreased that
drastically on my servers, that I can't test the patch in real
environments anymore. I do have one or two amplification attackes per hour
left ... #firstworldproblems
So if anybody is willing to try it out: Please do. Please report to me.
Minimal configuration is dampening {}; in options or view. I do
recommend at least dampening { exempt-clients { local_AS; resolvers; };};.
If you want to help, please add report-interval secs;. The number of
seconds should be less than the overrun of a 32bit counter under your query
rate. Reports can be found in the dampening category.
There are two implemtations activated in the patch: The (old) heap and a
(new) hash/queue. I do not know which of them performs better so I run both
in parallel to gather information. If you do not like such a play, please
remove the approbiate init function from implementations in dampening.c.
Personally I do think, the heap implementation is more stable to variable
load, but I do not have hard evidence for it yet.
Please let me thank the developers of the RRL patch, which point me to the
right files. I'm still unsure, if the RRL patch and my idea came to the same
results at the current type of attacks. I'm still wonder, if the patch
really survives a higher query rate than those I have access to.
Cut from the changed ARM
Dampening
Spoofed UDP queries are a major security threat especially when
reflected and possibly amplified by DNS servers. Dampening is a
dynamically adapting method for dealing with such kinds of misuse.
So dampening a about spoofing, hence TCP connections are not
affected at all.
Every piece of a query and its response is associated with
specific penalty points. Those points aggregate over all queries
from netblocks defined by |IPv6-prefix-length| and
|IPv4-prefix-length|. Over the time, the penalty
decreases exponentially (determined by |halflife|).
So each netblock gains a penalty over time characteristics.
In order to allow local clients, which should be protected by
anti-spoof techniques at the edge of the operated network, to
send any amount of queries without fear the risks of being blocked,
push them into a seperate view with other or no dampening rules or
add them to |exempt-clients|.
If the penalty exeeds |limit-enable-dampening|, the netblock gets
dampened. No further query processing will occur.
Every further query is dropped silently before inspecting the
content of the query itself. So the penalty value can decrease
slowly, if the sender collect not quickly enough further
|score-per-query| points. Please note, that
penalty values can't exceed |limit-maximum|.
If the penalty drops below |limit-disable-dampening|,
query processing for the netblock switchs back to normal. If
the penalty drops as low as |limit-irrelevant|,
the netblock is removed ..from the statistics. The next query
gains |score-first-query| for this netblock
and reenteres the collection.
Comment current attacks gain a huge amplification from ANY query
to DNSSEC signed zones. So each ANY query is charged with
additional |score-qtype-any| points. Furthermore
current attackers repeat the same packet over and over again, so
keeping the same id in each query. Such repetitions are recognised
and give |score-duplicates| points times the
repetition of this id.
Amplification attacks aims to huge answers, so the next penalty
comes from the response size. The penalty increased lineary from
zero for responses up to |minimum-score-size|
bytes. The maximum penalty of |score-size| is
reached when the response reaches or exceeds
|maximum-score-size| bytes.
In order to minimize expensive calulations for each query, the
penalty decay is delayed by at least
|update-delay| seconds. The statistics table
has space for |min-table-size| elements but
might increase to |max-table-size| elements if
necessary.
In order to compare various storage models, which are activated
at compile time, regular statistics can by extracted by setting
|report-interval| to the seconds between reports.
Those statistic lines contain the numerical index of the
implementation |Stats for #...|, the number of
queries processed, dampened, and exempted |queries ././.|,
and aggregated time spend in the various functions.
End of Cut
___
dns-operations mailing list
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Jim Reid wrote: Besides, a genuine resolver will also have a non rate-limiting server to query unless all the name servers for some domain are under attack. ... which seems to be the case, at least for the name servers I have access to: all servers for a particular domain are attacked concurrently. New name servers won't be picked up by the attacker(s) in real time, but eventually, they do get added to their list. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Hi evereyone, On Mon, 2012-10-01 at 17:24 +, Vernon Schryver wrote: After you have rate limiting, why bother with the costs of the synthetic CNAMES? What I suggested was a method for legitimate clients to remove themselves from the rate-limiting blacklist. They get onto the list when an attacker sends spoofed queries using the legitimate client's (e.g. a resolving DNS server of an ISP) IP address as source address. Thus an attacker could disable zones for specific ISPs by attacking the rate-limiting authoritative name server of the zone. Despite my suggestion earlier in this thread, I agree with Paul when it comes to handing out data that are obviously not zone data. Cookies seem more appropriate now. Best regards Dan -- Dan Luedtke http://www.danrl.de ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 1 Oct 2012, at 08:33, Paul Vixie wrote: i'm ready to accept that rate limiting (as specified by DNS RRL) hurts non-spoofing clients who ask similar enough questions during the attack. but so far this has not been demonstrated or even described. a real recursive-service initiator may be forced to retry by UDP or even by TCP. +1. Besides, a genuine resolver will also have a non rate-limiting server to query unless all the name servers for some domain are under attack. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Fri, 28 Sep 2012 09:44:39 +0200 bert hubert bert.hub...@netherlabs.nl wrote: This allows us to test for two-way communications without using truncated packets or TCP. We could encode the encrypt the correct destination in the CNAME, for A and this is trivial. If you come back to resolve encoded-12.32.43.43.attackeddomain.com, you get 12.32.43.43 etc. For extra resilience encrypt it. I did not think this through too deeply, but what do people think? Why would this, or other similar proposals, be more preferable than just sending back truncated packets to signal for TCP? This latter approach has been widely used in network gear over the years with a fair amount of success, and now thanks to Paul and Vern's work, seems to be a promising feature in the application itself. John ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 2012-10-01 4:00 PM, John Kristoff wrote: ... We could encode the encrypt the correct destination in the CNAME, for A and this is trivial. If you come back to resolve encoded-12.32.43.43.attackeddomain.com, you get 12.32.43.43 etc. For extra resilience encrypt it. I did not think this through too deeply, but what do people think? as before, i think this could be done for a recursive talking to a stub, but that an authority server should only speak zone truth. since the stub/recursive relationship can be kept spoof-free using ACL's and network perimeters, what we primarily need is solutions in the recursive/authority relationship. and i would not be comfortable seeing synthetic CNAME's added to those transactions. moreover: Why would this, or other similar proposals, be more preferable than just sending back truncated packets to signal for TCP? This latter approach has been widely used in network gear over the years with a fair amount of success, and now thanks to Paul and Vern's work, seems to be a promising feature in the application itself. noting that other network equipment has been doing this, i want to make sure everyone knows the distinction of DNS RRL's approach: packet attenuation. we only insert TC=1 slip frames periodically, not on a 1:1 basis with potentially fake queries. slip frames are the same size as queries, so there is no bit-level amplification. and the packet level replication is attenuated. this makes a DNS RRL server less attractive than a directed attack, which is literally the best we can hope to accomplish here -- the attacks will go on but our authority servers don't have to be involved. 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Lutz Donnerhacke wrote: Exactly that's the result, I do observe. Details: http://lutz.donnerhacke.de/eng/Blog/Two-weeks-of-DNS-Dampening ___ 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] First experiments with DNS dampening to fight amplification attacks
Hi everyone, I recently read about Lutz' attempt to implement dampening in bind. Some people pointed at the flaws and possible DoS of dampening. I'd like to contribute to the discussion. Lutz wanted to be as compatible with current DNS as possible, and therefore he introduced no new protocols or other techniques. I like this very much, but let me allow to think of an _optional_ addition at protocol-level (read: misusing TXT records once again). At first all works the same as Lutz suggested. Then we reach the point when a legitimate address gets blocked. One part of the problem is, that spoofed addresses won't lead back to where their packets came from. If we are able to detect a packet going the wrong way, we can be sure the previous blocking was OK and continue to block. Otherwise we have to remove the address (or even whitelist it for a while), because we are blocking legitimate queries. When an IP address is blocked, we still answer to it, but only once[1]. Regardless of what the query is, we answer: TXT temporary_blocked challenge_1 challenge_2 The legitimate packet will travel to the destination resolver, the resolver XORs (or any other kind of magic happens) the two challenges and queries again: XOR-result.removal-request.whatever.arpa Then we remove the address, because it proofed to be able to traverse the net as supposed. Even better: Use DNS-Cookies once the IP has so many bad points that it will be block soon.[2] Thus we can dampening DNS-amplifying attacks but still provide a method for legitimate servers to remove themselfs from the blocklist once they are on it. challenge_1 and challenge_2 may be computed by a private key and the blocked IP address, so similar to SYN-Cookies we don't have to allocate memory for it. Private Key must be the same on all Anycast instances :/ Please review this and make suggestions. I am working on another idea regarding IPv6, something I call gradient-prefix-blocking for the moment, but I haven't done the math yet. It may explode in memory. Regards Dan [1] Maybe more, e.g. three times, but then we have to allocate memory for the counter then. [2] http://www.ietf.org/proceedings/67/slides/dnsext-0/dnsext-0.ppt PS: I wasn't able to hijack the thread because I did not find the correct message-id on gmane and other archives. Sorry! -- Dan Luedtke http://www.danrl.de ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 9/28/2012 7:44 AM, bert hubert wrote: I did not think this through too deeply, but what do people think? Bert i think authority responses have to be zone data. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Fri, Sep 28, 2012 at 1:44 AM, bert hubert bert.hub...@netherlabs.nl wrote: On Fri, Sep 28, 2012 at 09:17:42AM +0200, Dan Luedtke wrote: When an IP address is blocked, we still answer to it, but only once[1]. Regardless of what the query is, we answer: TXT temporary_blocked challenge_1 challenge_2 Hmmm for authoritative servers, we might also emit a CNAME challenge. This would be a needless and semantically null transition, but only a bona fide resolver will come back to follow the CNAME trail. Arbor has something very similar to this in their DDOS products. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Server cookies are the way to go though I would add timestamps so that server secrets don't need to be changed. The time stamp would have to be within X seconds of the servers current concept of time or it will be treated as a bad cookie. The time would be concatenated to the rest of the data to be hashed. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Mark Andrews ma...@isc.org wrote: Server cookies are the way to go though I would add timestamps so that server secrets don't need to be changed. The time stamp would have to be within X seconds of the servers current concept of time or it will be treated as a bad cookie. The time would be concatenated to the rest of the data to be hashed. Are you referring to this? http://tools.ietf.org/html/draft-eastlake-dnsext-cookies Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
In message alpine.lsu.2.00.1209281541070.1...@hermes-1.csi.cam.ac.uk, Tony Finch writes: Mark Andrews ma...@isc.org wrote: Server cookies are the way to go though I would add timestamps so that server secrets don't need to be changed. The time stamp would have to be within X seconds of the servers current concept of time or it will be treated as a bad cookie. The time would be concatenated to the rest of the data to be hashed. Are you referring to this? http://tools.ietf.org/html/draft-eastlake-dnsext-cookies Yes. It's a reasonable way to identify non-spoofed traffic which means you can apply filtering techiques to the rest of the traffic which will be a mix of spoofed and non-spoofed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 9/28/2012 2:48 PM, Mark Andrews wrote: In message alpine.lsu.2.00.1209281541070.1...@hermes-1.csi.cam.ac.uk, Tony Finch writes: Mark Andrews ma...@isc.org wrote: Server cookies are the way to go though I would add timestamps so that server secrets don't need to be changed. The time stamp would have to be within X seconds of the servers current concept of time or it will be treated as a bad cookie. The time would be concatenated to the rest of the data to be hashed. Are you referring to this? http://tools.ietf.org/html/draft-eastlake-dnsext-cookies Yes. It's a reasonable way to identify non-spoofed traffic which means you can apply filtering techiques to the rest of the traffic which will be a mix of spoofed and non-spoofed. i don't agree. there's no way to tell the difference between a client who hasn't upgraded, vs. a client who has downgraded or is behind a NAT box, vs. a spoofer. therefore we will not be able to drop non-cookied queries even while under attacks which spoof the same netblock as we get a non-cookied query from. see RFC 6013, as earlier summarized in ;login: (http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf), for another approach to fixing not just DNS but HTTP state management. paul -- I suspect I'm not known as a font of optimism. (VJS, 2012) ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* bert hubert [2012-09-28 09:44]: Hmmm for authoritative servers, we might also emit a CNAME challenge. This would be a needless and semantically null transition, but only a bona fide resolver will come back to follow the CNAME trail. This allows us to test for two-way communications without using truncated packets or TCP. We could encode the encrypt the correct destination in the CNAME, for A and this is trivial. If you come back to resolve encoded-12.32.43.43.attackeddomain.com, you get 12.32.43.43 etc. For extra resilience encrypt it. There has been recently a patent granted with this method: http://www.freepatentsonline.com/8261351.html Though they don't use it do decide about blocking, but use the CNAME challenge on every query, still providing a small amplification. This comes at the risk of running into resolver issues with NS or MX records... Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
From: =?ISO-8859-1?Q?Matth=E4us_Wander?= matthaeus.wan...@uni-due.de Hmmm for authoritative servers, we might also emit a CNAME challenge.= We could encode the encrypt the correct destination in the CNAME, for A= and this is trivial. If you come back to resolve encoded-12.32.43.43.attackeddomain.com, you get 12.32.43.43 etc. There has been recently a patent granted with this method: http://www.freepatentsonline.com/8261351.html Though they don't use it do decide about blocking, Is that because converting a reflected flood of DNSSEC signed responses to a reflected flood of DNSSEC signed challenge CNAMEs is not an impressive defense for DNS reflection attacks? Never mind that packet losses during an attack can increase and so doubling the number of packets that must succeed for a legitimate DNS/UDP transaction is unlikely to be helpful. but use the CNAME challenge on every query, still providing a small amplification. This comes at the risk of running into resolver issues with NS or MX records..= and resolver CPU loads for DNSSEC signatures for all of those synthetic challenge CNAMES during an attack. Vernon Schryverv...@rhyolite.com ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
In message 5065bd2c.7030...@redbarn.org, paul vixie writes: On 9/28/2012 2:48 PM, Mark Andrews wrote: In message alpine.lsu.2.00.1209281541070.1...@hermes-1.csi.cam.ac.uk, Ton y Finch writes: Mark Andrews ma...@isc.org wrote: Server cookies are the way to go though I would add timestamps so that server secrets don't need to be changed. The time stamp would have to be within X seconds of the servers current concept of time or it will be treated as a bad cookie. The time would be concatenated to the rest of the data to be hashed. Are you referring to this? http://tools.ietf.org/html/draft-eastlake-dnsext-cookies Yes. It's a reasonable way to identify non-spoofed traffic which means you can apply filtering techiques to the rest of the traffic which will be a mix of spoofed and non-spoofed. i don't agree. there's no way to tell the difference between a client who hasn't upgraded, vs. a client who has downgraded or is behind a NAT box, vs. a spoofer. therefore we will not be able to drop non-cookied queries even while under attacks which spoof the same netblock as we get a non-cookied query from. It's about identifying non spoofed returning clients. It does a good job of identifying that set of clients. Those clients arn't using the server a reflector. Those clients don't need to be penalised. It also does a good job of protecting clients from off path spoofed replies. For the server queries that present no cookie or a bad cookie go into the potentially rate limited pile. For clients the benefits come in less need to use multiple ports and knowing they are not going to be rate limited other than on initial queries when talking to servers that support cookies. This is about pulling out good traffic from the undifferentiated traffic we have today. see RFC 6013, as earlier summarized in ;login: (http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf), for another approach to fixing not just DNS but HTTP state management. paul -- I suspect I'm not known as a font of optimism. (VJS, 2012) ___ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Mon, Sep 24, 2012 at 02:48:38PM +, Lutz Donnerhacke l...@iks-jena.de wrote a message of 16 lines which said: Please have a look at http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening The basic security issue of DNS-based DoS is that the IP address of the attacker is forged. There are therefore two classes of solutions: 1) Trying to authenticate the source address (TSIG, EDNS-ping, DNS cookies, force TCP, etc). Then you can apply reputation-based systems. 2) Trying to filter/ratelimit/harass based on the contents of the packets, not on the source address. This is what ANY bigdomain.example filters do, for instance. You use a 3rd method, applying a reputation (this IP did bad things) on a forged address. This is bad, for the reasons explained by Vernon Schryver (with dampening, you can kill any DNS client by pretending to be it and attacking a server). [As you can see, I agree with most Paul Vixie's remarks.] ___ 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] First experiments with DNS dampening to fight amplification attacks
Hi everybody, after serveral heavy misuse of my authoritive servers, I was urged to *solve* the problem. This is obviously not possible, but I'd like to share my results with you. I managed to drop the outgoing bandwith from a saturated 100Mbps to 80% of the incoming attack data rate in a first step. Now I so stop each attack within 40 packets. I do only respond to 30 out of 1 queries. Most production traffic is untouched. There are some collateral damage, which needs to be investigated, i.e. recursive resolvers of IPv6 tunnel providers with qmail customers are overblocked from time to time: The defaults are not optimal yet. Please have a look at http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
[ Quoting l...@iks-jena.de in [dns-operations] First experiments ... ] Please have a look at http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening Nice. Two questions: 1. Why didn't you use: http://www.redbarn.org/dns/ratelimits ? 2. Will this scale to TLD sized DNS servers? Regards, -- Miek Gieben http://miek.nl signature.asc Description: Digital 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
lutz, in looking at your patch, it appears that your dns dampening has two bad side effects and one misfeature. first, since it does not take the query or response into account, all queries from a given source will share fate. this means your authority server will go completely silent on some recursive name server if it sends too many of any kind of query no matter how diverse those queries are. second, you go completely silent when in dampening mode. there are no slip responses by which an actual recursive name server might be able to get real answers by retrying with UDP or escalating to TCP during times that its IP address is being spoofed by an attacker. third, you're giving each end-host address its own fate, so that a spoofed-source attacker could cause you to flood a distant network simply by iterating through that network's address space. your solution seems to be optimized for overly busy recursive servers who you want to deny excess service to, and does not deal at all with the case of spoofed-IP reflected amplified attacks. i also note that you have misunderstood (and therefore mischaracterized) DNS RRL, according to this text from your web site: They can rate limit http://ss.vix.com/%7Evixie/isc-tn-2012-1.txt the queries per client. Unfortunly this generates only a constant data stream of attack packets. DDoS works well with limited data rates per server, if you misuse enough servers. On the other hand the implementation required a lot of ressources. this text contains two factual errors: (1) that DNS RRL generates a constant stream of attack packets: we attenuate the attacks in two ways, first by dropping most (or at worse half) of the responses, second by responding with TC=1 packets that are no larger than the requests; and (2) that DNS RRL uses a lot of resources: we use about a megabyte of storage to keep unique state for 5 queries per second for five seconds, which is trivial. i urge a closer reading and deeper testing of DNS RRL (http://www.redbarn.org/dns/ratelimits/). 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* Miek Gieben wrote: 1. Why didn't you use: http://www.redbarn.org/dns/ratelimits ? Because the remaining rate of attack is still high enough to cause problems. We had a serious query from a lawyer of an small company which can't work anymore because their 2Mbps line is saturated. 2. Will this scale to TLD sized DNS servers? It's in a very early state of development. Currently I'm trying to collect real world data to find a reasonable set of defaults. With much conservative values, it might work for a TLD. But I do not understand the problem space to claim anything. Please feel free to try it out at you site and tell me about the results. Paul, yes it drops all the responses in dampening state. It does it for a very good reason: Even REFUSED messages are enough to run the attack. ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
From: paul vixie p...@redbarn.org first, since it does not take the query or response into account, all queries from a given source will share fate. this means your authority server will go completely silent on some recursive name server if it sends too many of any kind of query no matter how diverse those queries are. I would emphasize a different aspect of that issue. DNS Damping, like the firewall based schemes, allows a bad guy to silence a DNS server as far as a block of IP addresses is concerned. Silencing DNS has long been an important part of various security attacks. second, you go completely silent when in dampening mode. there are no slip responses by which an actual recursive name server might be able to get real answers by retrying with UDP or escalating to TCP during times that its IP address is being spoofed by an attacker. I think that is a feature of DNS Damping intended to answer the complaint about DNS RRL sending a constant data stream of attack packets. In my biased view that is a misfeature based on failing to apply the same DDoS scenario to DNS Damping. (See below.) third, you're giving each end-host address its own fate, so that a spoofed-source attacker could cause you to flood a distant network simply by iterating through that network's address space. There are references to dealing with blocks instead of individual addresses. Perhaps that is intended for a future version. your solution seems to be optimized for overly busy recursive servers who you want to deny excess service to, and does not deal at all with the case of spoofed-IP reflected amplified attacks. How so? i also note that you have misunderstood (and therefore mischaracterized) DNS RRL, according to this text from your web site: http://lutz.donnerhacke.de/eng/Blog/DNS-Dampening They can rate limit http://ss.vix.com/%7Evixie/isc-tn-2012-1.txt the queries per client. DNS Damping *is* rate limiting. It differs from DNS RRL only in details about counting and limiting rates. (One detail that I think is important but that Lutz Donnerhacke evidently does not is that RRL does not count *queries*; RRL counts *responses*.) Unfortunly this generates only a constant data stream of attack packets. DDoS works well with limited data rates per server, if you misuse enough servers. On the other hand the implementation required a lot of ressources. this text contains two factual errors: (1) that DNS RRL generates a constant stream of attack packets: we attenuate the attacks in two ways, first by dropping most (or at worse half) of the responses, second by responding with TC=1 packets that are no larger than the requests; and I think the complaint is that DNS RRL with slip 0 and the recommended responses-per-second 10 could send 10 DNS response/second to the victim. If the responses were DNSSEC ANY or NXDOMAIN results, they could be more than 1500 Bytes or 1.2 Kbits each. If you stop there, it sounds bad, because a bad guy could use 833 DNS servers using RRL to reflect 120 Mbit/sec to the victim. But don't stop there. Ask what happens if those 833 DNS servers use Damping instead of RRL. I think the same 120 Mbit/sec would be sent to the victim because no rate limiting including Damping should trigger on a busy server at much less than 10 requests/second. (2) that DNS RRL uses a lot of resources: we use about a megabyte of storage to keep unique state for 5 queries per second for five seconds, which is trivial. I also wonder about that claim that DNS RRL requires a lot of resources. From my superfical reading, appears to me that DNS Damping uses more resources than DNS RRL. What kind of resources are we talking about, memory or CPU cycles? How was resource utilization measured in the two implementations and what are the numbers? Vernon Schryverv...@rhyolite.com ___ 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
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 9/24/2012 3:24 PM, Lutz Donnerhacke wrote: Paul, yes it drops all the responses in dampening state. It does it for a very good reason: Even REFUSED messages are enough to run the attack. lutz, that's a huge false positive denial of service vulnerability given that ip source addresses are trivially forged. see SAC004 (http://www.icann.org/en/committees/security/sac004.txt) for details. also, we do not generate REFUSED. the meaning of REFUSED is there is an ACL on the name server and your ip address is not in it. that signal would be completely inappropriate in this circumstance. 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
