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

Attack mit deinem Zeitserver: NTP-Amplifikationsangriff (CVE-2013-5211)

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

Am 13. Januar warnte der US-amerikanische Emergency Command Computer (US-CERT) vor einer neuen DDoS-Angriffsmethode.

Infizierte Computer senden eine Monlist-Anfrage 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.

So sendet eine kleine Anfrage vom infizierten Computer an das Opfer einen großen UDP-Stream.

Dies ist die Essenz der Verstärkung.


Ein ungeschützter NTP-Server wird zu einem unwissenden Vermittler des Angriffs.

Angriffe unterliegen Versionen von ntpd bis 4.2.7p26 (jetzt stabil 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 "abgelaufen, 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) Deaktivieren Sie die Monlist in ntp.conf, indem Sie den disable monitor die Zeilensperre hinzufügen
  • 3) Oder deaktivieren Sie alle Serverstatusabfragen, indem Sie 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 haben Sie gar nicht gewusst, dass Ihr NTP - Server außerhalb sichtbar ist (-:.

Deaktivieren Sie dann den Zugriff darauf vollständig.


Ich bin auf dieses Problem im November gestoßen, als NTP-Verkehr auf meinem öffentlichen NTP stratum1.net 30GB pro Stunde wurde.

Das habe ich nicht sofort bemerkt, tk. Sogar auf dem Atom-Prozessor betrug die Last weniger als 5%.

Dann schrieb ich ein Bash-Skript, das in der letzten halben Stunde die Traffic-Statistik der Boundary-Firewall untersuchte (via netflow) 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_use

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

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