Re: DNS Amplification Attacks... and a trivial proposal
On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote: 1) If everyone on the planet were to somehow magically and immediately be converted over to DNSSEC tomorrow, then would DNS amplification attacks become a thing of the past, starting tomorrow? Does DNSSEC solve the DNS amplification attack problem? Or does it have no direct bearing on No, quite the opposite in fact. By increasing the size of responses, DNSSEC arguably makes the amplification problem (slightly) worse. DNSSEC is a good thing and necessary for other reasons, but it does not help amplification attacks. 2) Has anyone ever proposed adding to the DNS protocol something vaguely reminicent of the old ICMP Source Quench? If so, what became of that proposal? snip Basically, the whole idea is just simply to allow a victim to switch to safe TCP only mode with all of the intermediaries that are participating The problem with that idea is that it needs software updates on both the reflecting DNS server and the victim. It also seems to require keeping a lot of soft state in the endpoints. Altogether, it seems easier for everyone to just apply RRL patches, do BCP38 and de-peer with people who don't do BCP38. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
On 06/13/2013 05:33 AM, Phil Mayers wrote: On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote: 1) If everyone on the planet were to somehow magically and immediately be converted over to DNSSEC tomorrow, then would DNS amplification attacks become a thing of the past, starting tomorrow? Does DNSSEC solve the DNS amplification attack problem? Or does it have no direct bearing on No, quite the opposite in fact. By increasing the size of responses, DNSSEC arguably makes the amplification problem (slightly) worse. slightly is generous. I would say dramatically. $ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +nodnssec ; DiG 9.9.2-P1 mx isc.org @ord.sns-pb.isc.org +noall +stats +nodnssec ;; global options: +cmd ;; Query time: 223 msec ;; SERVER: 199.6.0.30#53(199.6.0.30) ;; WHEN: Thu Jun 13 11:28:49 2013 ;; MSG SIZE rcvd: 403 $ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +dnssec ; DiG 9.9.2-P1 mx isc.org @ord.sns-pb.isc.org +noall +stats +dnssec ;; global options: +cmd ;; Query time: 242 msec ;; SERVER: 199.6.0.30#53(199.6.0.30) ;; WHEN: Thu Jun 13 11:28:54 2013 ;; MSG SIZE rcvd: 2427 DNS reflection attacks are all about amplification (a small request resulting in a response larger than the request). A 6 times greater response size is a large jump in amplification. DNSSEC is a good thing and necessary for other reasons, but it does not help amplification attacks. +1 2) Has anyone ever proposed adding to the DNS protocol something vaguely reminicent of the old ICMP Source Quench? If so, what became of that proposal? snip Basically, the whole idea is just simply to allow a victim to switch to safe TCP only mode with all of the intermediaries that are participating The problem with that idea is that it needs software updates on both the reflecting DNS server and the victim. It also seems to require keeping a lot of soft state in the endpoints. This would require both software updates and an update to the DNS protocol. This idea does require state at the endpoints. We seem to have already lost that battle - example RRL. Would this require more state at the endpoints than RRL? I think that this probably would require more state. One concern I have is that it turns the problem on its head and now the network that is the target of the attack is required to get packets out through their loaded equipment to stop the attack. This could lead to wrong headed statements like, Yes, we sent X GB of traffic at your network. You didn't implement DNS source quench? You should have. The chain of responsibility for these attacks is: 1. The person(s) originating the spoofed traffic. 2. The network(s) allowing the origination of spoofed traffic. 3. The network(s) transmitting the spoofed traffic. 4. The operators of nodes amplifying the traffic towards the victim. 5. The victim. A system that requires the victim to take action to stop attacks might be misconstrued by some to be abdicating the responsibility of the upper four levels. Altogether, it seems easier for everyone to just apply RRL patches, do BCP38 and de-peer with people who don't do BCP38. Agreed. Close all open resolvers as well. Using this strategy, however, you will have to do an awful lot of de-peering. -DMM ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
From: David Miller dmil...@tiggee.com Basically, the whole idea is just simply to allow a victim to switch to safe TCP only mode with all of the intermediaries that are participating The problem with that idea is that it needs software updates on both the reflecting DNS server and the victim. It also seems to require keeping a lot of soft state in the endpoints. This would require both software updates and an update to the DNS protocol. This idea does require state at the endpoints. We seem to have already lost that battle - example RRL. Would this require more state at the endpoints than RRL? I think that this probably would require more state. I think that the use of RRL on some roots shows that keeping state is not a problem if the state keeping is not utterly stupid. DNS cookies could do something similar but better than that safe TCP only mode idea. Unfamiliar (no cookie) DNS clients that show some (or no) sign of badness could be sent to TCP, could be given lower rate limits, ignored entirely (dropped), or whatever makes sense at the server. The state could be kept only on DNS clients and could be fewer and smaller than the state needed for RRL. See https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 DNS cookies suffer less from the update-the-world problem, because they are optional. Altogether, it seems easier for everyone to just apply RRL patches, do BCP38 and de-peer with people who don't do BCP38. Agreed. Close all open resolvers as well. me too. Sufficiently distributed or disbursed DNS reflection attacks (e.g. qps1 at reflectors) are hard even to detect except at the victim. I hope eventually to release BIND patches that add RPZ client IP address triggers and drop and TCP-only policies. See https://www.google.com/search?q=dns+rpz An RPZ zone of client IP address triggers of victim IP addresses and TCP-only policies, maintained by victim requests and certain other mechanisms could let participating DNS servers mitigate even extremely distributed reflection attacks. If there were an RPZ zone of client IP address triggers of open resolvers used in attacks and if that zone were used at many authoritative DNS servers, then users of those open resolvers would be inconvenienced and might pressure open resolver operators to act. The problem with those RPZ ideas is recruiting DNS server participants. That is similar to the problem of recruitng SMTP servers to use anti-spam DNSBLs, but worse because these ideas help victims instead of participants. It might be helped by including anti-reflection rules in other RPZ products. The RPZ TCP-only policy might be used in private kludges. Consider these rules in the external view on an open resolver: *. CNAME tpc-only-rpz. *.mydomain CNAME passthru.rpz. Like RRL, such ideas not as good as closing the resolver, but less bad than leaving it unprotected. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What happens when one out of three NSs are down?
- Original Message - Any comments and best practice solution info very welcome. Folks with significant requirements with regard to high availability are likely to put a hardware loadbalancer running a VIP which receives DNS requests and balances it onto a pool of reals (aka the boxes running nameservers), including liveness checks so the LB will transparently migrate around a nameserver which is down. Speaking of using a load balancerI have wondered about putting our BigIP in front of our authoritative only nameservers, hadn't thought about doing it for HA. But whether it would help against DDos? I know there's a DNSFloodProtection iRule, and wonder if the BigIP does any protection of its own (or is it just the SYN flood DDoS that it does). Though I recall that they had published that GTM v11 has DNS DDoS protections, but our current platform is limited to 10.2.4 and we only have LTM. Though if I did put the BigIP in front, would the DDoS traffic towards the nameserver VIPs, impact other services on the BigIP? -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 51b991f7.9070...@imperial.ac.uk, Phil Mayers p.may...@imperial.ac.uk wrote: On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote: 2) Has anyone ever proposed adding to the DNS protocol something vaguely reminicent of the old ICMP Source Quench? If so, what became of that proposal? ... Basically, the whole idea is just simply to allow a victim to switch to safe TCP only mode with all of the intermediaries that are participating The problem with that idea is that it needs software updates on both the reflecting DNS server and the victim. Yes. Is there _any_ even remotely viable proposal for ridding the world of these damn DDoS amplification attacks that _doesn't_ require either software updates or worse, hardware updates? The entire problem is fundamentally a result of the introduction of EDNS0. Wwouldn't you agree? The introduction of that change also needed software updates on both the sending and receiving side. (That was accomplished it seems.) Should anyone be in the lest bit surprised to learn that a widespread software update might be necessary in order to counteract the clear (and for some people/sites/companies, catastrophic) effect of an earilier software update? It also seems to require keeping a lot of soft state in the endpoints. Please define a lot. You and I apparently have differing definitions of that term. Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
On 06/13/2013 02:01 PM, Ronald F. Guilmette wrote: The entire problem is fundamentally a result of the introduction of EDNS0. Wwouldn't you agree? No. You can still get pretty good amplification with 512 byte responses. There are 2 causes of this problem, lack of BCP 38, and improperly secured (read, open) resolvers. The first requires operator education, and in a non-trivial number of cases requires operators to act against their own interests. Thus, the problem remains unsolved 13 years later. The latter problem also requires operator education, but is more likely to be solvable. There is no quick fix. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 51b9fb6a.1090...@tiggee.com, David Miller dmil...@tiggee.com wrote: This could lead to wrong headed statements like, Yes, we sent X GB of traffic at your network. Yes. Last night I reconsidered at some length the scheme I put forward yesterday. (Please note that I am very deliberately calling it merely a scheme rather than a proposal, because I do not think that it rises to the level of that honorable title yet.) Basically, please ignore everything I put forward yesterday and substitute instead the following in place of all that... 1) A new DNS/UDP packet/message type is defined. This new message when sent from from machine A to machine B informs B that A would really really appreciate it if B would cease and desist from sending anything other than HIGHLY ABBREVIATED (12 byte) UDP DNS response packets to the IP address of A for a period of 30 seconds. (Said highly abbreviated DNS/UDP response packets would all have the TC bit set.) In a hypothetical revised future DNS RFC it would be said that all DNS servers attached to the public internet MUST be capable of properly receiving, decoding and obeying any and all such client requests. 2) A new DNS/TCP packet/message/interaction is defined. A given machine at IP address `A' (which may or may not even be a DNS server or client) may connect to a DNS server at IP address `B' and may execute a transaction with `B' which requests that the DNS server running on `B' should refrain from sending any DNS/UDP response packets to `A' for a period of time encoded within the interaction. Again, hypothetically, in future this would be a MUST. In its response to A's request, B would include the number of seconds since the last time that B received a DNS query *via UDP* that was ostensibly from A. The first provision above is the fast-reaction emergency stop-gap. It can be sent out even when the DDoS target is already undergoing/experiencing a massive packet inflow. (It _is_ only one small _outgoing_ packet after all, so the DDoS victim should, be able to squeeze that out, I think. After all is is only the inbound side of the connection that is getting DDoS'd.) The second provision above is what you do after you have sent the emergency stop-gap panic button UDP Stop killing me! packet/request. By this time, things will have hopefully settled down a bit, at least enough for the victim to be able to complete a three-step TCP handshake _and_ get a single small additional payload packet out via the TCP connection. As mentioned in my previous scheme, the information that comes back from B (i.e. one of the unwitting DNS servers that are participating as amplifying intermediaries in the attack) regarding the amount of time that has elapsed since _it_ last received an attack packet (i.e. any spoofed DNS query appearing to have come from A) will help A decide when the time is ripe for it,the victim, machine, to come out of the bunker and crawl back into the sunlight. Note that _by definition_ exactly and only any *UDP* DNS query packet that B has received since A told it... via secure TCP connection... that it would stop sending any DNS queries to B via UDP for awhile... and that thus, B should stop sending any DNS/UDP _responses_ to A for that same awhile... are, by definition, forged/spoofed DNS queries. So each time any participating intermediary DNS server `B' receives a DNS/UDP query, it should merely look to see if the apparent source IP `A' is currently present in the (hopefully VERY small) list of IPs that B is currently in safe interaction mode with, and if B finds A's IP in that VERY small list, then it merely grabs the current system second-since-epoch clock value an then uses that to update the most_recent_spoof_time field of the trivially simple two-word (64 bit) record corresponding to that specific current safe mode client, `A'. Only two 32-bit words should be needed for each (IPv4) safe mode client that has properly requested a switch to safe mode from B, i.e. (1) A's 32-bit IPv4 address and (2) the 32-bit most_recent_spoof_time field. Trivial, no? Yea, yea. OK... so yes, those records have to be bigger than 64-bits in cases where the specific safe-mode client is speaking IPv6. No biggie. Let's not get bogged down in quibbling about minor and inconsequential trivialities. Regards, rfg P.S. I envision the new packet types for (1) above could be defined as simply as possible, so that even things other than (and simpler than) full-blown DNS servers could send them... maybe even... um... routers. Twelve bytes of all zeros ought to do it. (Can't get much simpler than that!) Unless I am mistaken, that ought to be entire orthogonal to any and all actual/ordinary DNS packets, at least at present. P.P.S. Yes, yes, I _am_ aware... as someone will surely point out... that
Re: DNS Amplification Attacks... and a trivial proposal
The entire problem is fundamentally a result of the introduction of EDNS0. Wwouldn't you agree? No, that just makes it a little easier. You pound the patoot out of someone with 512 byte packets just as much as you can with 4K packets, just by making your attacking botnet bigger. The real solution is BCP 38, to keep spoofed packets out of the network in the first place. With widely implemented BCP 38, open resolvers wouldn't matter since you could only DoS yourself, or at worst someone else on your own network segment. R's, John ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
Just a thought, below: On 14/06/13 2:41, Ronald F. Guilmette wrote: In message 51b9fb6a.1090...@tiggee.com, David Miller dmil...@tiggee.com wrote: This could lead to wrong headed statements like, Yes, we sent X GB of traffic at your network. Yes. Last night I reconsidered at some length the scheme I put forward yesterday. (Please note that I am very deliberately calling it merely a scheme rather than a proposal, because I do not think that it rises to the level of that honorable title yet.) Basically, please ignore everything I put forward yesterday and substitute instead the following in place of all that... 1) A new DNS/UDP packet/message type is defined. This new message when sent from from machine A to machine B informs B that A would really really appreciate it if B would cease and desist from sending anything other than HIGHLY ABBREVIATED (12 byte) UDP DNS response packets to the IP address of A for a period of 30 seconds. (Said highly abbreviated DNS/UDP response packets would all have the TC bit set.) In a hypothetical revised future DNS RFC it would be said that all DNS servers attached to the public internet MUST be capable of properly receiving, decoding and obeying any and all such client requests. I wonder what DNS-servers running older versions of the SW will respond to that? If they silently discard the packet, no problem. If however they respond with refused or anything else, you create your own storm. -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 201306131753.r5dhrwon093...@calcite.rhyolite.com, Vernon Schryver v...@rhyolite.com wrote: I think that the use of RRL on some roots shows that keeping state is not a problem if the state keeping is not utterly stupid. (I'm not sure what, if anything, I should be reading into that last bit of a phraseology. Oh well. No matter.) DNS cookies could do something similar but better than that safe TCP only mode idea. I will definitely need to bone up on that. Unfamiliar (no cookie) DNS clients that show some (or no) sign of badness could be sent to TCP, could be given lower rate limits, ignored entirely (dropped), or whatever makes sense at the server. At which server? The numerous DDoS-participating individual intermediaries? Or the (singular) DDoS victim? Assuming you are referring to the former, allow me just to offer the observation that if history teaches us anything it is that anything that needs to be... or that is even allowed to be... individually configured by innumerable individual server administrators will inevitably never work, in practice, to solve any actual real-world problem, because as surely as night follows day, at least 33% of all of the world's sever administrators, if given a knob or a dial to twist, will fuck it up in some way that makes it ineffective for its original or intended purpose. If the world's population of server administrators can be counted on to Do The Right Thing (when given some simple and straightforward configuration choice), then why are there still in excess of 27 million open resolvers on the Internet? (In short there is only one question you need to ask yourself... Do I feel lucky? :-) The advantage of the scheme I put forward is that there is -zero- con- figuration either required or allowed. Over time, people installing the latest version of BIND or their favorite DNS server... just as a matter of standard procedure, and just to stay current on security fixes... would get built-in support for the new anti-DDoS quench protocol and would _not_ be offered any ludicrous (and to most, confusing) con- figuration choices like: Do you want to enable to the new anti-DDoS protocol? Or would you prefer to continue to be an anti-social asshole? (I think most here would be surprised to learn how many server admini- strators, worldwide, would choose option B, if offered that exact choice, even if phrased in that exact way. Or as P.T. Barnum is alleged to have once said Nobody ever lost a dime underestimating the intelligence of the public at large.) Sufficiently distributed or disbursed DNS reflection attacks (e.g. qps1 at reflectors) are hard even to detect except at the victim. Bingo. The problem with those RPZ ideas is recruiting DNS server participants. That is similar to the problem of recruitng SMTP servers to use anti-spam DNSBLs, but worse because these ideas help victims instead of participants. Yes. See above regarding configuration choices. Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
From: John Levine jo...@iecc.com The real solution is BCP 38, to keep spoofed packets out of the network in the first place. Indeed. As many have mentioned, DNS reflection attacks are merely the current fad, driven partly by 10X or higher amplification (50 byte queries, 500 byte responses) and partly by the lemming syndrome of any fad. There are have been, are, and will be many other protocols used in reflection attacks until BCP 38 is the de facto standard. Smurf was an old example https://www.google.com/search?q=smurf+reflection+attack See also ntp https://www.google.com/search?q=ntp+reflection+attack Chargen is another one from the ancient suite of of the small services https://www.google.com/search?q=small+udp+service+reflection+attack that is reportedly popular again. https://www.google.com/search?q=chargen+attacktbs=qdr:m See also NTP, timed, and others. The standard reaction to a list like that from experts who invent Final Ultimate Solutions to the Spam Problem is incoherent nonsense about TCP and/or authentication. They neither know nor care TCP has long been and still is a very popular in reflection DoS attacks. https://www.google.com/search?q=tcp+syn+attack Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 51ba355b.10...@dougbarton.us, Doug Barton do...@dougbarton.us wrote: No. You can still get pretty good amplification with 512 byte responses. That is an interesting contention. Is there any evidence of, or even any reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE using strictly 512 byte packets? If that's actually a real problem, then I am forced to assume that there must have been numerous reliable reports of successful and devastating DNS reflection DDoS attacks which pre-dated the widespread adoption of EDNS0. I am not sure where or how I would be able to unearth archived but contemporaneous news accounts of such incidents, so if you could send me some links to archived copies of a few such pre-EDNS0 DDoS reports, I sure would appreciate it. There is no quick fix. I will settle for a slow one. All I am asking of the Internet community is that we at least *begin* the process of implmenting something that will really solve the problem once and for all... including even the part of the problems that can arise from non-open DNS servers. I am not persuaded that we have even really begun in ernest a process that is likely to lead to that result. Almost everybody, even 13 years later, is still hoping for, and praying for, some utterly cost-free and pain-free solution to drop down out of the sky like mana from heaven. My question is really a simple one: Where are the adults? This problem has gone on long enough. Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
Well the process has started. BCP 38. If you want hurry it along complain to your local politician that they need to consider drafting legislation that requires ISP's to implement BCP 38 in their networks. Require BCP 38 implementation by all parties as part of trade negotiation. Doing anything else just shifts the problem around. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 20130614004155.72013.qm...@joyce.lan, John Levine jo...@iecc.com wrote: The real solution is BCP 38... I agree completely John. I cannot do otherwise. But I have to ask the obvious elephant-in-the-room question... How is that comming along so far? Maybe we could find worse ways to spend our time than developing a Plan B and/or acquiring another basket to put a few of our eggs into. Regards, rfg P.S. The idea I had was that a reasonably simple anti-DDoS protocol ex- tension could be codified and rolled out along with regular software updates, and could thus eventually be in place even without the conscious cooperation of those system and network administrators who have, by their actions, already proven themselves to be largely if not entirely un- cooperative, even with common sense steps to foster and protect the public good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
The real solution is BCP 38... I agree completely John. I cannot do otherwise. But I have to ask the obvious elephant-in-the-room question... How is that comming along so far? Based on discussions I've had with people who work at large networks and in policy positions in various governments (not all in the US), a lot faster than it it was even a few months ago. If we're going to ask people to update their networks, I'd rather concentrate on an update that will really work, rather than some plan B that sorta kinda helps, and gives people the excuse that since they did that they don't have to do BCP 38. Also, a fair amount is just education. I ran a spoofer test on my server and found the network wide open. I talked to the guy who runs the hosting center today and he said oops, he thought it was set to do ingress filtering. So it will in a few days when he gets his router configs updated. R's, John ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 14768.1371175...@server1.tristatelogic.com, Ronald F. Guilmette writes: In message 20130614004155.72013.qm...@joyce.lan, John Levine jo...@iecc.com wrote: The real solution is BCP 38... I agree completely John. I cannot do otherwise. But I have to ask the obvious elephant-in-the-room question... How is that comming along so far? * Router manufactures have code to support BCP 38 though it defaults to off. * Large numbers of ISPs claim they implement BCP 38. * NAT boxes tend to reduce the number of viable sources. As more networks rather than hosts connect the IPv4 problem space will reduce. CGN's will have a similar impact. Future: * SIDR will make it easier for multi-homed nets to automatically configure border acls. * Adding defaults to home CPE devices to default to only allow out source addresses learnt through PD or configured RAs will help. Maybe we could find worse ways to spend our time than developing a Plan B and/or acquiring another basket to put a few of our eggs into. Regards, rfg P.S. The idea I had was that a reasonably simple anti-DDoS protocol ex- tension could be codified and rolled out along with regular software updates, and could thus eventually be in place even without the conscious cooperation of those system and network administrators who have, by their actions, already proven themselves to be largely if not entirely un- cooperative, even with common sense steps to foster and protect the public good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 20130614020930.c1c1c35e2...@drugs.dv.isc.org, Mark Andrews ma...@isc.org wrote: Well the process has started. BCP 38. If you want hurry it along complain to your local politician that they need to consider drafting legislation that requires ISP's to implement BCP 38 in their networks. See! Now _that's_ all I was asking for! A perfectly sensible, useful, and sure-fire solution to the problem! Thanks so much. I just don't know why this simple idea/solution to the whole worldwide problem did not occur to me before now. The world is forever in your debt. Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 20130614022305.72272.qm...@joyce.lan, John Levine jo...@iecc.com wrote: The real solution is BCP 38... I agree completely John. I cannot do otherwise. But I have to ask the obvious elephant-in-the-room question... How is that comming along so far? Based on discussions I've had with people who work at large networks and in policy positions in various governments (not all in the US), a lot faster than it it was even a few months ago. Great! That is very encouraging news John. So, may I infer that rather than being put off until the end of the century, which seemed to be the previous implementation timeline, pervasive implementation of BCP 38 may now be expected at around the time that 32-bit UNIX clocks are anticipated to wrap-around to negative? Gee. I can't wait! (And I mean that literally. I personally do not anticipate that I will still have a functioning curculatory system to call my own as of that time.) Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 20130614023140.7735d35e2...@drugs.dv.isc.org, Mark Andrews ma...@isc.org wrote: * Router manufactures have code to support BCP 38 though it defaults to off. Well then, THAT is going to be a great help in solving the problem, isn't it? * Large numbers of ISPs claim they implement BCP 38. I claimed that I was Charlie Chaplin once. Unfortunately, Robert Downey Jr. beat me to it. (My claim also did not help any of the organizations who were DDoS'd last week in any material way.) * NAT boxes tend to reduce the number of viable sources. As more networks rather than hosts connect the IPv4 problem space will reduce. At the risk of stating the obvious, putting a bunch of machines behind a NAT box does not make the routed IPv4 addresses that those boxes were formerly connected to disappear. Do you believe that everybody who puts a box behind a NAT then immediately takes pains to insure that _nothing_ will ever represent itself to the public Internet as occupying that box's previous routed address ever again? Or is it just as likely, if not moreso, that some new box will be put in the old box's place... a new box which is even less likely than the old one to be a mere end- luser client machine, incapable of reflecting anything, and vastly more likly to be a brand new *server* of some sort... probably of a kind that will suddenly make that IP address useful as a packet reflector, where the prior box would not have been useful at all in that respect? Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
From: Ronald F. Guilmette r...@tristatelogic.com } That is an interesting contention. Is there any evidence of, or even any } reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE } using strictly 512 byte packets? } } If that's actually a real problem, then I am forced to assume that there } must have been numerous reliable reports of successful and devastating } DNS reflection DDoS attacks which pre-dated the widespread adoption of } EDNS0. I am not sure where or how I would be able to unearth archived } but contemporaneous news accounts of such incidents, so if you could } send me some links to archived copies of a few such pre-EDNS0 DDoS } reports, I sure would appreciate it. Expecting to get detailed (e.g. packet dumps, packet sizes, IP addresses, ASNs) reports of DDoS attacks is like expecting samples of spam from anti-spam operators. Even the general outlines of reports tend to be private. At which server? The numerous DDoS-participating individual intermediaries? Or the (singular) DDoS victim? It wouldn't hurt to learn about the DNS protocol in general and DNS reflection attacks in particular before parachuting in with the Final Ultimate DNS Reflection DoS Attack Solution. Besides the facts that DNSSEC makes the problem worse and that EDNS0 was not the genesis of DNS reflection attacks, intermediary is a poor fit for a recursive DNS resolver (but might fit a stubb resolver). A recursive server answers from its cache. After it has recursed and until TTLs expire, a recursive server acts like an authority. That is why the query handling code in a DNS server implementation tends to treat its cache like a zone file. Intermediary simply does not fit the problem of open resolvers in DNS reflection attacks, because a DNS referral can give plenty of amplification. For example, I get more than 500 bytes of UDP payload from `dig +norecurs example.com` and almost 900 bytes from `dig +dnssec +norecurs example.com`. (If a recursive answering with a referral is an intermediary, then so is every non-leaf authority.) Singular DDoS victim is off the mark compared to DDoS victim. For obvious reasons, multi-Gbit/sec attacks often affect entire networks. (Multi-Gbit/sec attacks are more common than one might understand from some press releases.) In addition, there can be multiple IP addresses in an attack, and none of the target IP address need be in use by any hosts. Any host that is at a targeted address is not expecting the DoS packets and is be sending send as many ICMP Port-Unreachable error messages as its ICMP rate limits and firewalls allow (often none)--not to mention what the incoming flood might have done to BGP sessions and so forth and so on. Consider the implications of those facts, as well as the general meaning of denial of service attack on any Final Ultimate Solution that requires DDoS victims to send packets to DNS servers. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
So, may I infer that rather than being put off until the end of the century, which seemed to be the previous implementation timeline, pervasive implementation of BCP 38 may now be expected at around the time that 32-bit UNIX clocks are anticipated to wrap-around to negative? Perhaps, but I think that's still a lot sooner than a yet-to-be-designed hack to DNS servers will be widely used. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 20130614032434.72450.qm...@joyce.lan, John Levine jo...@iecc.com wrote: So, may I infer that rather than being put off until the end of the century, which seemed to be the previous implementation timeline, pervasive implementation of BCP 38 may now be expected at around the time that 32-bit UNIX clocks are anticipated to wrap-around to negative? Perhaps, but I think that's still a lot sooner than a yet-to-be-designed hack to DNS servers will be widely used. This is a point upon which reasonable men may reasonably disagree. (I am looking at BCP 38. It is dated May, 2000. This does not fill me with sanguine hopefulness regarding imminent implementation, sufficient to make any real difference in the magnitude of the problem.) Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
In message 15120.1371179...@server1.tristatelogic.com, Ronald F. Guilmette writes: In message 20130614023140.7735d35e2...@drugs.dv.isc.org, Mark Andrews ma...@isc.org wrote: * Router manufactures have code to support BCP 38 though it defaults to off. Well then, THAT is going to be a great help in solving the problem, isn't it? Actually it is because it provides ISPs with a tools they can use in appropriate places. * Large numbers of ISPs claim they implement BCP 38. I claimed that I was Charlie Chaplin once. Unfortunately, Robert Downey Jr. beat me to it. (My claim also did not help any of the organizations who were DDoS'd last week in any material way.) But it does if the claims are valid reduce the number of machines that can be used to launch attacks from and it also applies peer presure on other ISPs. It also invalidates claims from ISP's that say they can't implement BCP 38 when push comes to shove. * NAT boxes tend to reduce the number of viable sources. As more networks rather than hosts connect the IPv4 problem space will reduce. At the risk of stating the obvious, putting a bunch of machines behind a NAT box does not make the routed IPv4 addresses that those boxes were formerly connected to disappear. But it does stop machines behind the NAT boxes from being able reflect packets off machines elsewhere on the net. Everything coming from the NAT has the NAT's address as its source. This turns the attack from a amplified, reflected, DDoS attack into a staight out DDoS attack (no amplification, no reflection). Attempts to lauch attacks from behind the NAT impact the user of the NAT and the would be reflector not third parties. Do you believe that everybody who puts a box behind a NAT then immediately takes pains to insure that _nothing_ will ever represent itself to the public Internet as occupying that box's previous routed address ever again? Or is it just as likely, if not moreso, that some new box will be put in the old box's place... a new box which is even less likely than the old one to be a mere end- luser client machine, incapable of reflecting anything, and vastly more likly to be a brand new *server* of some sort... probably of a kind that will suddenly make that IP address useful as a packet reflector, where the prior box would not have been useful at all in that respect? I'd rather have another reflector than a spoofed traffic source. There will always be reflectors. There doesn't have to be any sources of spoofed traffic. CPE vendors have been informed of the broken defaults in their boxes and new equipment will ship which is not broken. ISP's can filter inbound traffic directed at port 53 by default but allow a end user to remove the filter. They do this sort of thing for SMTP. Sensible defaults are making their way though the IETF so that CPE vendors have some guidance on how to configure their boxes for IPv6 so that are not reflector or other sources of badness. As more ISP's deploy IPv6 the number of bad IPv4 only CPE boxes will decrease. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
Ronald, It's obvious you're frustrated (understandable), and enthusiastic (commendable), but you might want to consider dialing down your rhetoric a bit. You've had responses from people here who have been working on this problem for years, and have a deep understanding of it.* Trying to understand what they're telling you, and its implications, would really help your situation. More below. * Note, I'm not including myself in that category. I know a bit more than the average person, but I'm not an expert. On 06/13/2013 06:57 PM, Ronald F. Guilmette wrote: In message 51ba355b.10...@dougbarton.us, Doug Barton do...@dougbarton.us wrote: No. You can still get pretty good amplification with 512 byte responses. That is an interesting contention. Is there any evidence of, or even any reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE using strictly 512 byte packets? You're asking the wrong question. Attackers don't go out of their way to find open resolvers that they are sure will return 4k packets. They blast out to all the ones that they know, and take the amplification that they can get. 50 - 500 is still a pretty good amplification rate. The important point being (as others have made to you) that this is not an EDNS0 issue. It's also worth noting that I realize this wasn't the main point you were trying to make, but it will probably be helpful for you to get your facts straight. If that's actually a real problem, then I am forced to assume that there must have been numerous reliable reports of successful and devastating DNS reflection DDoS attacks which pre-dated the widespread adoption of EDNS0. Again, you're making the wrong argument. As others have pointed out to you, DNS amplification is just the attack du jour. There is evidence at the moment that the kiddies are already moving to chargen since we seem to be making some progress on open resolvers, and they want to keep their options open. There is no quick fix. I will settle for a slow one. Then you really want to learn more about response rate limiting, which already exists, and is in the process of being adopted into the major flavors of authoritative DNS software. That will help a lot with DNS amplification, but the real answer is still going to be BCP 38, with all of its attendant thorns. I am not persuaded that we have even really begun in ernest a process that is likely to lead to that result. Almost everybody, even 13 years later, is still hoping for, and praying for, some utterly cost-free and pain-free solution to drop down out of the sky like mana from heaven. Again, you need to become more familiar with the efforts that have been ongoing for years. Mark also made an excellent point about legislation for BCP 38 being an unfortunate necessity at this point. For a variety of reasons there are costs associated with implementing BCP 38, costs which a non-zero number of operators have chosen not to pay. Adding legislative penalties/incentives that will make implementing it less costly than not is pretty much the only untried tool we have left. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [users@httpd] webservers not responding properly after hardware change
Hello, I posted this to httpd.apache.org but have not had any response, so I think it may be more related to BIND than DNS. Apologies for the cross-post. I have setup two webservers on my network, one connected directly to the ISP with an ethernet card installed to bring it to the router where, it was give an internal ip address and ports opened for ftp, smtp and pop. It is ns1. ns2 is behind the router and handles http, dns and ssh. Mail is currently being properly delivered although my smtp server going out is no longer working for obvious reasons. I can't ping ns1 from ns2. apachectl say my configuration is correct. The only change I made that I can see is the ethernet card in ns1 died. How would this impact my DNS? None of the domains on ns2 are available on the web although the websites on ns1 are. The attached diagram shows before and after. Any help would be greatly appreciated. http://www.normanfournier.com/nf-network-diagram-v9.jpg The ns2 webserver is serving plone instances via a Zope webserver behind Apache. It appears that the apache webserver is already loaded and that might be the problem, although it is not serving any pages. The following is my terminal output. ns2:~ norman$ apachectl -t Syntax OK ns2:~ norman$ apachectl restart launchctl: CFURLWriteDataAndPropertiesToResource(/System/Library/LaunchDaemons/org.apache.httpd.plist) failed: -10 ns2:~ norman$ apachectl start launchctl: CFURLWriteDataAndPropertiesToResource(/System/Library/LaunchDaemons/org.apache.httpd.plist) failed: -10 org.apache.httpd: Already loaded ns2:~ norman$ Norman___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
