I agree 100% BCP38 should be standard operating procedure for providers. But I think getting providers to implement BCP38 is about as successful as getting DNS Admins to stop setting up their servers as Open Resolvers. All 32,000,000/million of them and counting just waiting to be used in a DNSAmp DDoS attack.
http://www.openresolverproject.org/breakdown.cgi On Tue, Nov 5, 2013 at 8:03 AM, Tim Bray <[email protected]> wrote: > On 05/11/13 03:54, Justin wrote: > > I have two machines that participate in the ntp pool project, and I > > received an abuse email today. Basically, my server was DDOS someone > > else, ntp reflection attack. Obviously that is not something I want to > > do. By default my ntp server allows any that connect to port 123. > > These ddos were sending the responses back to someone's port 80, which > > is causing me the headache. My first step will be to lock the ntp down > > to port 123 and ports above 1024 for people behind a nat. I was also > > going to place iptables rate limit. Is there anything else I should be > > doing? I have read about the restrict limited and discard statement in > > ntp.conf, but I'm not sure if that will help here. All my solutions have > > been outside ntp.conf, so I know I have to be overlooking something. I > > have never had problems with aggressive clients or ntp reflection dos > > before. I also really do not care about aggressive clients even now. > > The system particulars, Ubuntu 13.10/x86, which uses ntp > > 4.2.6.p5+dfsg-3ubuntu2. Any assistance is welcomed. > > > The long term answer is for all network operators worldworld to > implement BCP38 > > http://tools.ietf.org/html/bcp38 > > This limits the outflow of spoofed packets. > > > Tim > _______________________________________________ > pool mailing list > [email protected] > http://lists.ntp.org/listinfo/pool >
_______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
