Semi-urgent: Disable NTP replies?

[Adam Vande More]

On Tue, Feb 18, 2014 at 6:47 PM, Polytropon <freebsd at edvax.de> wrote:

> On Wed, 19 Feb 2014 00:37:18 +0000, Matthew Seaman wrote:
> > On 18/02/2014 22:53, Ronald F. Guilmette wrote:
> > > So, um, I've had to put in a new stopgap ipfw rule, just to stop these
> > > bloody &^%$#@ NTP reply packets from leaving my server, but what is
> > > that Right Way to solve this problem?  I'm guessing that there's
> > > something I need to add to my /etc/ntp.conf file in order to tell
> > > my local ntpd to simply not accept incoming _query_ packets unlees
> > > they are coming from my own LAN, yes?  But obviously, I still need it
> > > to accept incoming ntp _reply_ packets or else my machine will never
> > > know the correct time.
> > >
> > > Sorry.  The answer I'm looking for is undoubtedly listed in an FAQ
> > > someplace, but I am very much on edge right at the moment... because
> > > I was basiaclly being DDoS'd by all of this stupid NTP traffic... and
> > > thus I'm seeking a quick answer.
> >
> > Yep.  This is the latest scumbag trick: sending spoofed packets to ntpd
> > and using it as an amplifier to do a DDoS against some victim.
>
> For those interested in learning more about how this attack
> is being used by scumbags, here are a two links to read:
>
>
> http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack
>
>
> http://krebsonsecurity.com/2014/02/the-new-normal-200-400-gbps-ddos-attacks/
>
> In this case, CloudFlare has been declared the victim.
>

Aside from the Adam Walsh hyperbole, this was a very vulnerable "feature"
included in NTP to begin with and also one that lack apparent real world
value.   It's been removed from NTP sources for quite awhile, something
like 4 years.  As such I consider this to be a problem of whoever is
distributing NTP.


-- 
Adam