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

Angriff mit Ihrem Zeitserver: NTP-Verstärkungsangriff (CVE-2013-5211)

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

Am 13. Januar gab der US-amerikanische Notfallkommando (US-CERT) eine Warnung über eine neue Methode der DDoS-Angriffe heraus.

Infizierte Computer senden eine Monlisteanforderung mit einer gefälschten IP-Adresse des Absenders an den NTP-Server.

Die Abfrage monlist gibt eine Liste der letzten 600 ntpd Clients zurück.

Somit sendet eine kleine Anfrage vom infizierten Computer an das Opfer einen großen Strom von UDP.

Dies ist die Essenz der Verstärkung.


Ein ungeschützter NTP-Server wird ein unwissender Vermittler des Angriffs.

Angriffe unterliegen Versionen von ntpd bis 4.2.7p26 (stable jetzt 4.2.6p5).


Überprüfen Sie Ihren Server auf die Sicherheitsanfälligkeit, indem Sie den folgenden Befehl ausführen:

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

Wenn der Befehl die Clients auflistet (und nicht "Zeitüberschreitung, nichts empfangen"), ist das System anfällig.

Beseitigung

Jetzt gibt es mindestens 3 Möglichkeiten:

  • 1) Aktualisieren Sie ntpd auf Version 4.2.7p26. Aktualisieren Sie in FreeBSD die Ports und installieren Sie ntpd von net / ntp-devel.

Ohne ein Upgrade können Sie:

  • 2) Deaktiviere die Monlist in der ntp.conf durch Hinzufügen des Line Disable disable monitor
  • 3) Oder deaktivieren Sie alle Serverstatusabfragen, indem Sie die 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


Vielleicht wussten Sie gar nicht, dass Ihr NTP-Server außerhalb sichtbar ist (-:.

Deaktiviere dann den Zugriff darauf vollständig.


Ich habe dieses Problem bereits im November gelöst, als NTP-Traffic auf meinem öffentlichen NTP stratum1.net 30 GB pro Stunde erreichte.

Das habe ich nicht sofort bemerkt. selbst auf dem Atom-Prozessor lag die Last unter 5%.

Dann schrieb ich ein Bash-Skript, das in der letzten halben Stunde (via netflow) die Traffic-Statistiken der Boundary-Firewall betrachtete und automatisch eine Deny-Regel für zu aktive Clients hinzufügte. Und in zwei Monaten wurde klar, was es war.

Quellen:

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