DDoS-Schutz auf MikroTik ohne echte Besucher zu blockieren

Ein Denial-of-Service-Angriff beginnt nicht immer mit Hunderten von Gigabit. Er kann die Form von einigen hundert neuen Verbindungen pro Sekunde annehmen, die ausreichen, um den Webserver, die Datenbank oder die Connection-Tracking-Tabelle des Routers zu sättigen. In diesem Szenario kann MikroTik ungewöhnlich aktive Quellen erkennen und deren Pakete verwerfen, bevor sie weitere Ressourcen verbrauchen.

Dieser Schutz bleibt lokal. Er kann die CPU des Servers und des Routers schonen, solange die Internetverbindung noch Kapazitäten aufweist. Wenn feindlicher Datenverkehr die vom Anbieter bereitgestellte Verbindung bereits füllt, empfängt der Router die Pakete zu spät : Dann sind vorgelagerte Maßnahmen, ein CDN mit DDoS-Schutz, eine WAF, ein Cleaning-Dienst oder das Filtering des Anbieters erforderlich.

DoS, DDoS und Anwendungssättigung

Ein DoS-Angriff stammt von einer Quelle oder einer kleinen Gruppe von Quellen. Ein DDoS-Angriff verteilt den Datenverkehr auf viele kompromittierte Maschinen oder vernetzte Objekte. Diese Unterscheidung ändert nichts am ersten Ziel : zu verhindern, dass missbräuchliche Pakete eine Ressource vor legitimen Anfragen erschöpfen.

Vor der Änderung der Firewall den Vorfall erkennen

Eine Server-CPU nahe 100 %, eine sehr aktive Datenbank und ein plötzlicher Anstieg der Verbindungen allein beweisen noch keinen Angriff. Eine legitime Kampagne, ein Indexierungs-Bot, eine Anwendungsschleife oder ein falsch konfigurierter Client können ähnliche Symptome hervorrufen.

In RouterOS zeigt Torch in Echtzeit die auf einer Schnittstelle beobachteten Datenströme an und ermöglicht deren Sortierung nach Quelladresse, Zieladresse, Port und Protokoll. Es zeigt den Datenverkehr vor seiner Filterung : Eine Quelle kann also sichtbar bleiben, selbst wenn die Firewall sie bereits blockiert.

/tool/torch interface=ether1
/interface monitor-traffic ether1

Passen Sie ether1 an die tatsächliche WAN-Verbindung an. Vergleichen Sie die Ergebnisse mit den Protokollen des Reverse-Proxys oder des Webservers. Überwachen Sie insbesondere :

• die Anzahl neuer Verbindungen pro Quelle und pro Ziel ;
• die tatsächlich ins Visier genommenen Ports und Protokolle ;
• den Durchsatz in Bit/s und die Anzahl der Pakete pro Sekunde ;
• die Größe der Connection-Tracking-Tabelle ;
• die CPU-Auslastung des Routers und des Servers ;
• die HTTP-Codes, Antwortzeiten und wiederholten Anfragen auf Anwendungsseite.

Eine einzelne Adresse, die viele Sitzungen öffnet, kann manuell blockiert werden, aber eine statische Liste wird bei einem verteilten Angriff schnell unbrauchbar. Das Ziel ist es daher, eine dynamische, kurze und messbare Quarantäne zu erstellen.

dst-limit richtig verstehen

Der Parameter dst-limit wendet eine separate Grenze auf jeden Datenstrom an, der durch seinen Modus definiert ist. Seine Syntax lautet :

dst-limit=taux[/période],rafale,mode[/expiration]

In folgendem Ausdruck :

dst-limit=32,32,src-and-dst-addresses/10s

• 32 ist die erlaubte Rate, hier 32 Pakete pro Sekunde, da keine andere Periode angegeben ist ;
• das zweite 32 ist der erlaubte anfängliche Burst ;
• src-and-dst-addresses erstellt einen Zähler pro Quell-Ziel-Paar ;
• 10s ist die Timeout-Dauer eines inaktiven Zählers, kein Zehn-Sekunden-Fenster für die 32 Pakete.

Die Regel mit der Aktion return akzeptiert in der Erkennungskette die Datenströme, die unter der Grenze bleiben. Wenn der Eimer geleert ist, stimmt sie nicht mehr überein : Das Paket fällt auf die folgenden Regeln, die die Quelle in eine dynamische Liste aufnehmen.

Warum die Ketten input und forward nicht austauschbar sind

Die Kette input verarbeitet Pakete, die für den Router selbst bestimmt sind. Die Kette forward verarbeitet diejenigen, die den Router zu einer anderen Maschine durchqueren. Ein über dst-nat veröffentlichter Webserver wird also in forward geschützt, selbst wenn der Client die öffentliche Adresse des MikroTik kontaktiert.

Eine Erkennungsregel, die nur in input platziert ist, kann ihre Zähler für WebFig oder ein auf dem Router gehostetes VPN erhöhen, aber sie wird den an den internen Server weitergeleiteten Datenverkehr nicht korrekt sehen.

Vergrößern ↗

Vor dem Start: Sichern und im abgesicherten Modus arbeiten

Ein Reihenfolgen- oder Kettenfehler kann den Zugriff auf den Router unterbrechen. Verbinden Sie sich aus dem LAN, aktivieren Sie den Safe Mode in WinBox oder mit Ctrl+X, und exportieren Sie dann die Konfiguration.

/export file=avant-protection-ddos
/system backup save name=avant-protection-ddos

Stellen Sie sicher, dass die Schnittstellenliste WAN tatsächlich die Internetverbindung enthält und dass der Server bereits hinter einer dst-nat-Regel funktioniert. Die in RAW verwendeten Ports müssen die öffentlichen Ports vor der Übersetzung sein. Wenn der externe Port 8443 auf 443 übersetzt wird, geben Sie 8443 in der RAW-Regel an.

Gezielte Konfiguration für einen Webserver hinter dst-nat

Der folgende Regelsatz ist absichtlich auf neue TCP-Verbindungen beschränkt, die aus der WAN-Liste zu einem auf 80 oder 443 veröffentlichten Dienst kommen. Er vermeidet es, eine Weberkennung in ein globales Verbot jeglicher Kommunikation mit der Quelladresse zu verwandeln.

1. Eine Ausschlussliste vorbereiten

Fügen Sie zu ddos-allow nur die wirklich vertrauenswürdigen externen Adressen hinzu : Überwachung, Reverse-Proxy oder offizielle Bereiche Ihres CDN. Die untenstehende Adresse gehört zu einem für Dokumentationszwecke reservierten Block und muss ersetzt werden.

/ip firewall address-list
add list=ddos-allow address=198.51.100.10 \
    comment="BEISPIEL RFC 5737 - ersetzen"

2. Neue Webverbindungen an eine dedizierte Kette senden

/ip firewall filter
add chain=forward action=jump jump-target=detect-ddos-web \
    connection-state=new connection-nat-state=dstnat \
    in-interface-list=WAN protocol=tcp dst-port=80,443 \
    src-address-list=!ddos-allow \
    comment="DDoS: neue Web-Verbindungen pruefen"

Platzieren Sie diese Regel nach der Akzeptanz von established,related-Verbindungen und der Zurückweisung von invalid-Paketen, aber vor der Regel, die neue dstnat-Verbindungen autorisiert. Sie ersetzt nicht die normale Firewall.

3. Schwellenwert und Quarantäne festlegen

/ip firewall filter
add chain=detect-ddos-web action=return \
    dst-limit=32,32,src-and-dst-addresses/10s \
    comment="DDoS: Verkehr unter Schwellenwert"

add chain=detect-ddos-web action=add-src-to-address-list \
    address-list=web-ddos-attackers address-list-timeout=10m \
    comment="DDoS: quarantaine temporaire"

add chain=detect-ddos-web action=drop \
    comment="DDoS: ausloesendes Paket verwerfen"

Die Dauer von zehn Minuten begrenzt die Kosten eines Fehlalarms. Eine Woche automatischer Blockierung ist ohne weitere Analyse selten gerechtfertigt : Adressen ändern sich, Besucher teilen sich einen CGNAT-Ausgang und Relais legitimer Dienste können viele Verbindungen bündeln.

4. Frühzeitig in RAW blockieren

/ip firewall raw
add chain=prerouting action=drop place-before=0 \
    in-interface-list=WAN protocol=tcp dst-port=80,443 \
    src-address-list=web-ddos-attackers \
    comment="DDoS: Web vor conntrack blockieren"

RAW greift vor dem Connection Tracking ein. So vermeidet der Router, für jedes neue Paket, das bereits als missbräuchlich identifiziert wurde, einen conntrack-Eintrag zu erstellen. Die Regel bleibt auf das WAN und die öffentlichen Web-Ports beschränkt : Die unter Quarantäne gestellte Adresse wird nicht willkürlich auf allen anderen Diensten blockiert.

Offizielle Variante nach Quell-Ziel-Paar

Die MikroTik-Dokumentation schlägt eine generische Logik vor, die sowohl die Quelle in ddos-attackers als auch das Ziel in ddos-targets aufnimmt und dann in RAW nur blockiert, wenn beide Listen übereinstimmen. Diese Methode ist elegant für ein geroutetes öffentliches Ziel ohne Übersetzung.

/ip firewall filter
add chain=forward connection-state=new \
    action=jump jump-target=detect-ddos
add chain=detect-ddos action=return \
    dst-limit=32,32,src-and-dst-addresses/10s
add chain=detect-ddos action=add-dst-to-address-list \
    address-list=ddos-targets address-list-timeout=10m
add chain=detect-ddos action=add-src-to-address-list \
    address-list=ddos-attackers address-list-timeout=10m

/ip firewall raw
add chain=prerouting action=drop \
    src-address-list=ddos-attackers \
    dst-address-list=ddos-targets

Mit dst-nat kann der Filter forward die interne Adresse nach der Übersetzung sehen, während RAW noch die öffentliche Adresse sieht. Die Ziellisten bezeichnen daher möglicherweise nicht in beiden Schritten dieselbe Adresse. Aus diesem Grund blockiert die vorherige Konfiguration nach Quelle, aber nur auf dem WAN und den explizit geschützten öffentlichen Ports.

SYN-Cookies aktivieren

Für SYN-Floods verfügt RouterOS ebenfalls über SYN-Cookies. Sie reduzieren die Menge an gespeicherten Zuständen, solange der Client nicht bewiesen hat, dass er die TCP-Antwort tatsächlich empfängt.

/ip settings set tcp-syncookies=yes

Diese Option ergänzt die Ratenbegrenzung, ersetzt aber weder die Firewall-Regeln noch die Fähigkeit des Servers, vollständige HTTP-Anfragen zu verarbeiten. Ein Bot, der TCP und TLS korrekt aufbauen kann, kann die Anwendung weiterhin belasten.

Testen, ohne sich selbst auszusperren

1. Beginnen Sie mit einem hohen Schwellenwert und beobachten Sie die Zähler während einer normalen Periode und einer Spitzenlastzeit.
2. Überprüfen Sie die Reihenfolge der Regeln mit /ip firewall filter print stats und /ip firewall raw print stats.
3. Überwachen Sie die dynamische Liste, ohne jedes zurückgewiesene Paket zu protokollieren.
4. Testen Sie von einer kontrollierten externen Adresse aus, mit einem begrenzten Lastwerkzeug und nur gegen Ihren eigenen Dienst.
5. Bestätigen Sie, dass ein normaler Besucher weiterhin bedient wird, dass der Server antwortet und dass die Last abnimmt, wenn die Quarantäne ausgelöst wird.
6. Verlassen Sie den Safe Mode erst nach der Validierung und bewahren Sie den Export außerhalb des Routers auf.

/ip firewall filter print stats
/ip firewall raw print stats
/ip firewall address-list print where list=web-ddos-attackers
/ip firewall connection print count-only

Vermeiden Sie log=yes auf einer Regel, die auf Tausende von Paketen pro Sekunde zutreffen kann. Die Schreibvorgänge und die Nachrichtenverarbeitung können zu einem zweiten Angriff auf den Router werden. Verwenden Sie die Regelzähler, die Listengrößen und, falls erforderlich, Traffic Flow zu einem externen Collector.

Wenn der lokale Schutz nicht mehr ausreicht

Ein MikroTik kann keine Pakete aus der Verbindung entfernen, die der Anbieter ihm bereits zugestellt hat. Bei einer 1 Gbit/s-Verbindung macht ein eingehender Angriff, der diese Kapazität übersteigt, die Dienste unbrauchbar, selbst wenn der Router jedes Paket einwandfrei zurückweist.

Bereiten Sie daher vor dem Vorfall einen Eskalationsplan vor :

• Kontaktdaten des Netzwerkszentrums des Anbieters und Notfallverfahren ;
• Schwellenwert, ab dem eine Filterung, ein temporäres Blackhole oder ein Traffic-Cleaning angefordert wird ;
• CDN und WAF vor den öffentlichen HTTP-Diensten ;
• DNS mit TTL und Notfallzugängen, die zum Kontinuitätsplan passen ;
• externe Metriken, um die Sichtbarkeit zu erhalten, wenn die Website nicht mehr erreichbar ist ;
• begrenzte Captures, Zeitstempel, Serverprotokolle und Volumenhistorie für die Analyse.

Ein ernsthafter Schutz kombiniert mehrere Schichten : frühes Filtering im Router, Ratenbegrenzung im Reverse-Proxy, Cache und WAF auf HTTP-Ebene und dann Mitigationskapazitäten beim Hoster oder Anbieter.

Häufige Fehler, die es zu vermeiden gilt

• Die Erkennung des Servers in input platzieren : Der weitergeleitete Datenverkehr durchquert forward.
• Eine Quelle auf allen Ports für eine Woche blockieren : Der Fehlalarm wird dauerhaft und global.
• Den Schwellenwert 32/32 ohne Messung kopieren : Der legitime Datenverkehr variiert stark je nach Architektur.
• Die Reihenfolge der Regeln vergessen : Eine allgemeine Akzeptanz, die vor der Erkennung platziert ist, macht diese unsichtbar.
• Jede Zurückweisung protokollieren : Die Logs können während des Angriffs CPU, Speicher und Speicherplatz verbrauchen.
• Filterung und Kapazität verwechseln : Ein lokal verworfenes Paket hat die Internetverbindung bereits durchquert.
• IPv6 ignorieren : IPv4-Regeln schützen keinen Dienst, der auch in IPv6 veröffentlicht ist.

Fazit

RouterOS kann einen moderaten Angriff gegen einen veröffentlichten Server effektiv abfedern : dst-limit erkennt ein zu aktives Quell-Ziel-Paar, eine dynamische Liste stellt die Quelle unter Quarantäne und RAW verwirft die nachfolgenden Pakete vor dem Connection Tracking. Der Schutz wird effizienter, wenn er auf die tatsächlich exponierte Schnittstelle, das Protokoll und die Ports abzielt.

Die richtige Einstellung ist jedoch nicht die, die die längste Sperrliste erzeugt. Sie ist die, die die Last reduziert, ohne legitime Besucher zu bestrafen, schnell abläuft, beobachtbar bleibt und in einen Eskalationsplan vorgelagert wird, wenn das Volumen die Kapazität der Verbindung überschreitet.

Technische Referenzen

• MikroTik : DDoS-Schutz und SYN-Cookies in RouterOS
• MikroTik : Syntax von dst-limit und Firewall-Aktionen
• MikroTik : Filterketten und RAW-Tabelle
• MikroTik : Datenverkehr mit Torch analysieren
• Zentrum für Cybersicherheit Belgien : Vorbereitung und DDoS-Schutz von Online-Diensten

Als Nächstes lesen

• DNS-over-HTTPS auf MikroTik RouterOS konfigurieren Netzwerke und Cybersicherheit · 15 Min.
• MikroTik: asymmetrisches Routing zwischen dem ISP und dem VPN vermeiden Netzwerke und Cybersicherheit · 17 Min.
• Zuverlässige GeoIP-Filterung auf MikroTik RouterOS konfigurieren Netzwerke und Cybersicherheit · 17 Min.

Über den Autor

Jeremy Kraft betreut die Infrastruktur und die selbst gehosteten Dienste des IBCSC. Diese Anleitungen beschreiben Konfigurationen, die tatsächlich im Einsatz waren und vor der Veröffentlichung erneut geprüft wurden.

Eine Frage stellen Alle Anleitungen

Diskussion

Kommentare

0

Noch kein Kommentar. Eröffnen Sie die Diskussion gern mit einer Frage oder Ihrem eigenen Erfahrungsbericht.

Website

Ihr Name Sie haben ein Konto? Anmelden

Ihr Kommentar

Reiner Text, höchstens 2 000 Zeichen. Neue Kommentare werden moderiert. Ihr Name wird mit dem Kommentar angezeigt. Es wird keine E-Mail-Adresse abgefragt; gegen Spam wird nur ein nicht umkehrbarer Fingerabdruck Ihrer IP-Adresse gespeichert.

Kommentar senden