amuck-landowner

NTP - the new DDOS amplifier

lbft

New Member
Fortunately there are not enough NTP servers out there and such an abuse WILL get noticed since most are run by professionals. There are far fewer than DNSes which are in each crappy hosting panel on the market as well as in many templates. 

It will certainly be easier to contain this outbreak.
Neah, DNS ampliffication attacks were 300 gbps and NTP "benefits" from having many servers publicly listed while the open  resolvers in every crappy hosting panel out there are hard to come by without scans.

It is also easy to solve, the NTP servers have listed contact addresses in many cases.

This will likely pass very fast, they will be fixed in a couple of weeks.

We are still fixing open recursive resolvers in our network, people put them up every day :(
It's a month later. Would you care to eat your words yet, Mao?
 

peterw

New Member
And the attacks are still there. Lots of server are running the vulernable version of ntp and they are not updated.
 
 

eva2000

Active Member
Thanks Fran !

I checked on CentOS 6.5 builds and ntp 4.2.6.p5 has the noquery added by default to block monlist it seems https://bugzilla.redhat.com/show_bug.cgi?id=1047854

 

Miroslav Lichvar 2014-01-02 07:23:04 EST

The default ntp.conf included in our ntp packages has noquery in the default restrict line, which blocks the monlist command.
 

Vincent Danen 2014-01-15 19:57:09 EST

Further to what Miroslav noted in comment #3, this can be verified by checking that the following are set in /etc/ntp.conf, which is the default in Red Hat Enterprise Linux and Fedora:

 

restrict default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery

 

 

External References:

 

https://www.us-cert.gov/ncas/alerts/TA14-013A
 

Tomas Hoger 2014-02-11 10:15:59 EST

The ntp packages as shipped with Red Hat Enterprise Linux are not affected by this issue in their default configuration.  The configuration defines the following default restrictions:

 

  restrict default kod nomodify notrap nopeer noquery

  restrict -6 default kod nomodify notrap nopeer noquery

 

These restrictions include 'noquery', which causes NTP daemon control command queries, including 'monlist' specifically pointed out by this CVE, to be rejected.  The query access is only allowed from localhost in the default configuration.

 

Users are discouraged from allowing query by default, query access can be granted to specific hosts if needed (using 'restrict' access control command).  Alternatively, users can disable monitor functionality using 'disable monitor' command in the /etc/ntp.conf.  Note that use of 'restrict' command with 'limited' flag also enables monitor functionality even when 'disable monitor' command is used.

 

Upstream fix implemented in version 4.2.7p26 is removal of support for 'monlist' ntpdc command, and introduction of replacement 'mrulist' ntpq command, for which additional verification is done to avoid request packet source address spoofing, and to limit the size of responses.  Note that version 4.2.7 is still the development version upstream.  The latest production release is 4.2.6 that does not include the above fix.

 

Additionally, the fix in 4.2.7p26 only addresses the 'monlist' command, which has the highest amplification ratio.  Other ntpdc (NTP mode 7) and ntpq (NTP mode 6) commands may be used in the future for amplification attacks with lower amplification ratio.  Users who do not disable these queries are encouraged to review their configuration and enable restrictions to reduce the risk of future attacks using other commands.

 

Red Hat currently does not plan to modify ntp packages in released versions of Red Hat Enterprise Linux to remove monlist support.  Future updates may change the default configuration to use 'disable monitor' in addition to 'restrict default noquery'.

 

For additional information on various ntp configuration commands, refer to the following manual pages: ntp_acc(5), ntp_misc(5), ntpdc(8) and ntpq(8).
 

KuJoe

Well-Known Member
Verified Provider
We had an 80Gbps attack for about an hour, I was expecting some packet loss but I didn't even notice it until I checked the logs later that day. I can't wait to get into our new data center and setup load balanced webservers again to load balance the attacks. :)
 

wlanboy

Content Contributer
We are secured by 480Gbps DDOS protection, Problem eh?


Gotta love OVH!
I thought that all OVH customers at all do have 480Gbps protection - or better said 3 x 160Gbps.

So if there are 10 x 40 Gbps attacks there is not much left of "your" protection.
 

Floris

New Member
I thought that all OVH customers at all do have 480Gbps protection - or better said 3 x 160Gbps.

So if there are 10 x 40 Gbps attacks there is not much left of "your" protection.
But to be honest, how big is that chance, that 10x40Gbps is sent out at once (on the same network)? Since only 4% of all the attacks launched untill september 2013 was "peaked" over 10Gbps
 
Last edited by a moderator:
Top
amuck-landowner