This page has been robot translated, sorry for typos if any. Original content here.

Attack using your time server: NTP amplification attack (CVE-2013-5211)

Атака с помощью вашего сервера времени: NTP amplification attack (CVE-2013-5211)

On January 13, the US Computer Emergency Preparedness Team (US-CERT) issued a warning about a new method for DDoS attacks.

Infected computers send a monlist request with a fake sender IP address to the NTP server.

The monlist request returns a list of the last 600 ntpd clients.

Thus, with a small request, a large UDP stream is sent from the infected computer to the victim.

This is the essence of amplification.


An insecure NTP server becomes an involuntary intermediary for an attack.

Versions of ntpd up to 4.2.7p26 are vulnerable to attack (now stable 4.2.6p5).


You can check your server for vulnerability by running the command:

ntpdc -c monlist адрес_сервера

If the command displays a list of clients (rather than “timed out, nothing received”), then the system is vulnerable.

Elimination

Now there are at least 3 ways:

  • 1) Update ntpd to version 4.2.7p26. On FreeBSD, upgrade the ports and install ntpd from net / ntp-devel.

Without an update, you can:

  • 2) Disable monlist in ntp.conf by adding the line disable monitor
  • 3) Or disable any server status requests in restrict default restrict default kod nomodify notrap nopeer noquery
    restrict -6 default kod nomodify notrap nopeer noquery
    restrict default kod nomodify notrap nopeer noquery
    restrict -6 default kod nomodify notrap nopeer noquery


You may not have known at all that your NTP server is visible outside (- :.

Then disable access to it completely.


I ran into this problem back in November when the NTP traffic on my public NTP stratum1.net became 30GB per hour.

I noticed this not immediately, because even on the Atom processor, the load was less than 5%.

Then I wrote a bash script that looked at the statistics of the border firewall traffic over the past half hour (via netflow) and automatically added the deny rule for too active clients. And two months later it became clear what it was.

Sources:

support.ntp.org/bin/view/Main/SecurityNotice#DRDoS_Amplification_Attack_using

www.kb.cert.org/vuls/id/348126

www.opennet.ru/opennews/art.shtml?num=38855