Archive

Kategorien

DDos auf NTP monlist „abwehren“

In letzter Zeit grassieren DDos Attacken auf NTP via dem monlist Kommando. Das ist nur ein einziges Paket in der Anfrage, aber die Antwort ist u.U. sehr sehr gross. Ein Angreifer kann mit nur 1 Mbps und 10 „Helfern“, die mit jeweils einem Gbps angebunden sind mit 400 NTP Servern welche nach monlist gefragt werden ein Zielnetz mit bis zu 500Gbps plattlegen. Das ist eine klassische Verstärkerattacke mit dem Faktor 50!! Da ntp auf UDP basiert lädt dies geradezu ein mit gefälschten Absender-IPs des Opfernetzes dieses mit Antworten schlicht unerreichbar zu machen. Ich konnte bei mir zu Hause wo dummerweise ein Server noch auf monlist geantwortet hat, Traffic im Bereich von 30Mbps sehen!

Als erste Massnahme sollte man auf allen eigenen NTP Servern das monlist Kommando am öffentlichen Interface verbieten. Das geht mit noquery in der ntp.conf. Oder gleich den ganzen Monitor abstellen mittels disable monitor. @ alle Centos User: scheinbar ist bei Centos der noquery nicht per default gesetzt. Bei Debian hingegen schon.
Damit sind die Server fein raus. Doch das Problem sind die Firewalls bzw ihre STATE Tabellen. Gerade bei Homeroutern können die schnell volllaufen auch wenn der NTP Server auf monlist nicht antwortet. Letztlich führt das zu recht hohen Lasten und auch lahmem Internet. Zudem schickt man ja trotzdem noch ein ntp Paket (query denied) an die Absender-IP

Also muss ein Weg her diese Pakete direkt auf der Ebene der Gateway-Firewall zu verwerfen, damit die STATE Tabellen überhaupt nicht befüllt werden mit diesem Schrott. Wer iptables und das u32 Modul auf dem Gateway hat ist mit folgenden zwei Regeln fein raus

-A INPUT -p 17 -m multiport --ports 123 -m u32 --u32 "0>>22&0x3C@8&0xFF=42" -j DROP
-A OUTPUT -p 17 -m multiport --ports 123 -m u32 --u32 "0>>22&0x3C@8&0xFF=42" -j DROP

Diese Regeln untersuchen jedes NTP Paket und ermitteln den Request Code des Pakets. Ist dieser 42 (monlist) dann wird gedroppt. Wer mehr zum Thema u32 Modul wissen will, dem kann ich dieses Tutorial nur empfehlen
Man könnte das noch etwas effizienter machen indem man beim INPUT nur NEW Pakete anschaut und beim OUTPUT nur RELATED,ESTABLISHED. Ohne NEW resp RELATED,ESTABLISHED hat es jedoch einen entscheidenden Vorteil: man kann nur eine Regel im FORWARD machen und hat alle solchen Pakete erschlagen

-A FORWARD -p 17 -m multiport --ports 123 -m u32 --u32 "0>>22&0x3C@8&0xFF=42" -j DROP

Ausser natürlich man hat den NTP Server auf dem Gateway, dann braucht man INPUT und OUTPUT 🙂
Der Einsatz im FORWARD hat gerade auch für Anbieter von virtuellen Servern den Vorteil, dass es nur eine Regel im iptables des physikalischen Servers braucht und alle virtuellen Maschinen können keinen Schindluder mehr treiben 🙂

5 comments to DDos auf NTP monlist „abwehren“

  • Aktuell schaut der Status von iptables (direkt auf dem Centos-NTP-Server) bei mir so aus

    1
    2
    3
    iptables -L INPUT 1 -nv
     468K   19M DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0 \
      multiport ports 123 u32 0x0>>0x16&0x3c@0x8&0xff=0x2a

    also 468’000 Pakete mit 19MB Volumen verworfen. Und dies obwohl ich am Gateway schon sehr grosse Listen mit etlichen Netzen verwende. Habe beim Gateway von diesem Server ein pfsense am Start und noch keinen Weg gefunden die iptables Regeln in pfsense abzubilden. Drum habe ich grosse Listen und sperre ganze Länder auf Port 123 v.a. russische und ukrainische SRC-IPs kann ich sehen. Die tragen wohl ihren Krimkrieg jetzt auch im Internet aus 😉

  • tobi

    Kleine Ergänzung: noquery führt nicht dazu, dass ein query denied Paket an die SRC zurückgeht. Habe mir das gerade eben genauer angeschaut.
    Trotzdem sollte man auch die iptables Regel an den Perimetern einbauen, damit diese Pakete, die eh nur Schrott sind, schonmal gar keinen Eintrag in den STATE Tabellen bekommen. Sonst schiesst man sich irgendwann – je nachdem wie heftig die Attacke ist – die Sessions auf dem Gateway aus und ist dann sozusagen selber das Opfer des DDOS geworden 🙂

  • Die letzten Tag hat es deutlich nachgelassen, trotzdem kommen in knapp 24 Stunden immer noch einige Requests durch die Blocklisten am pfsense bis an den ntp-Server

    1
    2
    3
    iptables -L INPUT 3 -nv
     7441  298K DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0 \
     multiport ports 123 u32 0x0>>0x16&0x3c@0x8&0xff=0x2a
  • tobi

    Heute Nachmittag hat es hier wieder gewaltig angezogen mit den Requests
    Kurz vor 13:45 sah es noch so aus

    1
    2
    47390 1896K DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0    \
    multiport ports 123 u32 0x0>>0x16&0x3c@0x8&0xff=0x2a

    also schon deutlich mehr als die 7441 innert 24h von gestern
    Jetzt aktuell (17:00) schaut es noch heftiger aus

    1
    2
     189K 7547K DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0 \
     multiport ports 123 u32 0x0>>0x16&0x3c@0x8&0xff=0x2a
  • Tobi

    Hier noch ein guter Link zu einer Beschreibung wie man ein rate-limit für NTP mittels iptables hinbekommt.
    Ich denke eine Kombination aus noquery im NTP Server, dem Droppen der monlist Pakete an den Gateways und einem rate-limit auf NTP helfen am besten sich dieses Problem vom Hals zu schaffen

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

  

  

  

2 × 2 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.