23 juli 2026 Netwerken en cyberbeveiliging 16 min. leestijd

Een DDoS-bescherming configureren op MikroTik zonder echte bezoekers te blokkeren

Pieken van nieuwe verbindingen detecteren, misbruikende bronnen tijdelijk in quarantaine plaatsen en ze vroegtijdig blokkeren in RAW, terwijl de limieten van de router gekend zijn.

Auteur: Jeremy Kraft
Publicatie: 23 juli 2026
Laatste controle: 23 juli 2026
Omgeving: RouterOS 7 · webserver achter dst-nat · IPv4 · TCP-poorten 80/443

DoS, DDoS en applicatieverzadiging

Een DoS-aanval komt van één bron of een kleine groep bronnen. Een DDoS-aanval verdeelt het verkeer over veel gecompromitteerde machines of verbonden objecten. Het onderscheid verandert het eerste doel niet : voorkomen dat abusieve pakketten een bron uitputten vóór de legitieme verzoeken.

Aanvalsvorm	Beoogde bron	Wat MikroTik kan doen
TCP-verbindingsstoot	Conntrack, firewall, webserver	Nieuwe verbindingen beperken en bronnen in quarantaine plaatsen
SYN-flood	Rij van onvolledige TCP-verbindingen	SYN-cookies activeren en stoten filteren
Realistische HTTP-flood	Applicatie, PHP, database	Aanwijzingen geven, maar een WAF of applicatiebeperking blijft noodzakelijk
UDP-amplificatie	Downstream-bandbreedte	Bepaalde pakketten lokaal blokkeren, zonder de reeds verzadigde verbinding vrij te maken
Volumetrische aanval	Capaciteit van de internetverbinding	Escaleren naar de operator of een mitigatiedienst stroomopwaarts

Het incident herkennen voordat de firewall wordt gewijzigd

Een serverprocessor die bijna op 100 % draait, een zeer actieve database en een brute stijging van de verbindingen bewijzen op zichzelf geen aanval. Een legitieme campagne, een indexeringsrobot, een applicatielus of een verkeerd geconfigureerde client kunnen vergelijkbare symptomen veroorzaken.

In RouterOS toont Torch in realtime de waargenomen stromen op een interface en laat toe ze te sorteren op bronadres, bestemmingsadres, poort en protocol. Het toont het verkeer vóór de filtering : een bron kan dus zichtbaar blijven, zelfs als de firewall deze al blokkeert.

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

Pas ether1 aan op de werkelijke WAN-verbinding. Vergelijk de resultaten met de logboeken van de reverse proxy of de webserver. Houd vooral dit in de gaten :

het aantal nieuwe verbindingen per bron en per bestemming ;
de daadwerkelijk beoogde poorten en protocollen ;
de doorvoer in bit/s en het aantal pakketten per seconde ;
de grootte van de verbindingstrackingstabel ;
het CPU-gebruik van de router en de server ;
de HTTP-codes, reactietijden en herhaalde verzoeken aan de applicatiekant.

Eén adres dat veel sessies opent, kan handmatig worden geblokkeerd, maar een statische lijst wordt snel onbruikbaar bij een gedistribueerde aanval. Het doel is dus om een dynamische, korte en meetbare quarantaine te creëren.

`dst-limit` correct begrijpen

De parameter dst-limit past een afzonderlijke limiet toe op elke stroom die door zijn modus is gedefinieerd. De syntaxis is :

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

In de volgende uitdrukking :

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

32 is het toegestane tarief, hier 32 pakketten per seconde aangezien geen andere periode is aangegeven ;
de tweede 32 is de toegestane initiële stoot ;
src-and-dst-addresses creëert een teller per bron-bestemmingspaar ;
10s is de verlooptijd van een inactieve teller, geen venster van tien seconden voor de 32 pakketten.

De regel met de actie return accepteert in de detectieketen de stromen die onder de limiet blijven. Wanneer de emmer leeg is, komt deze niet meer overeen : het pakket valt op de volgende regels, die de bron in een dynamische lijst plaatsen.

Waarom de ketens `input` en `forward` niet uitwisselbaar zijn

De keten input verwerkt de pakketten die bestemd zijn voor de router zelf. De keten forward verwerkt die welke de router passeren naar een andere machine. Een webserver die gepubliceerd is via dst-nat wordt dus beschermd in forward, zelfs als de client het openbare adres van de MikroTik contacteert.

Een detectieregel die enkel in input is geplaatst, kan zijn tellers verhogen voor WebFig of een VPN die op de router wordt gehost, maar zal het doorgestuurde verkeer naar de interne server niet correct zien.

Schema van de pakketroute tussen internet, RAW, verbindingstracking, forward-filter, dst-nat en de webserver — De detectie classificeert nieuwe verbindingen in `forward` ; de volgende pakketten van in quarantaine geplaatste bronnen kunnen eerder in RAW worden afgewezen.

Voor u begint: back-up maken en in veilige modus werken

Een fout in de volgorde of de keten kan de toegang tot de router blokkeren. Maak verbinding vanuit het LAN, activeer de Safe Mode in WinBox of met Ctrl+X, en exporteer vervolgens de configuratie.

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

Controleer of de interfacelijst WAN daadwerkelijk de internetverbinding bevat en of de server al achter een dst-nat-regel werkt. De poorten die in RAW worden gebruikt, moeten de openbare poorten vóór vertaling zijn. Als de externe poort 8443 wordt vertaald naar 443, geef dan 8443 op in de RAW-regel.

Gerichte configuratie voor een webserver achter `dst-nat`

De volgende reeks regels is opzettelijk beperkt tot nieuwe TCP-verbindingen die vanuit de WAN-lijst binnenkomen voor een dienst gepubliceerd op 80 of 443. Het vermijdt dat een webdetectie wordt omgezet in een globale blokkering van alle communicatie met het bronadres.

1. Een uitsluitingslijst voorbereiden

Voeg aan ddos-allow enkel de externe adressen toe die echt betrouwbaar zijn : monitoring, reverse proxy of officiële bereiken van uw CDN. Het onderstaande adres behoort tot een blok dat voor documentatie is gereserveerd en moet worden vervangen.

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

2. De nieuwe webverbindingen naar een specifieke keten sturen

/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: nieuwe webverbindingen inspecteren"

Plaats deze regel na de acceptatie van established,related-verbindingen en de afwijzing van invalid-pakketten, maar vóór de regel die nieuwe dstnat-verbindingen toestaat. Het vervangt de normale firewall niet.

3. De drempel en de quarantaine definiëren

/ip firewall filter
add chain=detect-ddos-web action=return \
    dst-limit=32,32,src-and-dst-addresses/10s \
    comment="DDoS: verkeer onder de drempel"

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: triggerpakket laten vallen"

De duur van tien minuten beperkt de kost van een fout-positief. Een week automatische blokkering is zelden te rechtvaardigen zonder bijkomende analyse : adressen veranderen, bezoekers delen een CGNAT-uitgang en relays van legitieme diensten kunnen veel verbindingen concentreren.

4. Vroeg blokkeren in RAW

/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 blokkeren voor conntrack"

RAW treedt op vóór de verbindingstracking. De router vermijdt zo voor elk nieuw pakket dat al als abusief is geïdentificeerd, een conntrack-item aan te maken. De regel blijft beperkt tot het WAN en de openbare webpoorten : het in quarantaine geplaatste adres wordt niet willekeurig geblokkeerd op alle andere diensten.

Officiële variant per bron-bestemmingspaar

De MikroTik-documentatie stelt een generieke logica voor die zowel de bron in ddos-attackers als de bestemming in ddos-targets plaatst, en vervolgens in RAW pas blokkeert wanneer beide lijsten overeenkomen. Deze methode is elegant voor een gerouteerde openbare bestemming zonder vertaling.

/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

Met dst-nat kan het filter forward het interne adres na vertaling zien, terwijl RAW nog steeds het openbare adres ziet. De bestemmingslijsten dreigen dus niet hetzelfde adres aan te wijzen in beide stappen. Dat is de reden waarom de vorige configuratie per bron blokkeert, maar enkel op het WAN en de expliciet beschermde openbare poorten.

SYN-cookies activeren

Voor SYN-floods beschikt RouterOS ook over SYN-cookies. Ze verminderen de hoeveelheid bewaarde status zolang de client niet heeft bewezen dat hij het TCP-antwoord daadwerkelijk ontvangt.

/ip settings set tcp-syncookies=yes

Deze optie vult de beperking aan, maar vervangt noch de firewallregels, noch de capaciteit van de server om volledige HTTP-verzoeken te verwerken. Een robot die TCP en TLS correct kan opzetten, kan nog steeds de applicatie belasten.

Testen zonder uzelf buitensloten te sluiten

Begin met een hoge drempel en observeer de tellers tijdens een normale periode en een piekperiode.
Controleer de volgorde van de regels met /ip firewall filter print stats en /ip firewall raw print stats.
Volg de dynamische lijst zonder elk afgewezen pakket te loggen.
Test vanaf een gecontroleerd extern adres, met een hulpmiddel voor beperkte belasting en uitsluitend tegen uw eigen dienst.
Bevestig dat een normale bezoeker bediend blijft, dat de server antwoordt en dat de belasting afneemt wanneer de quarantaine in werking treedt.
Verlaat de Safe Mode pas na validatie en bewaar de export buiten de router.

/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

Vermijd log=yes op een regel die kan overeenkomen met duizenden pakketten per seconde. Het schrijven en verwerken van berichten kan een tweede aanval tegen de router worden. Gebruik de regel tellers, de grootte van de lijsten en, indien nodig, Traffic Flow naar een externe collector.

Wanneer de lokale bescherming niet meer volstaat

Een MikroTik kan geen pakketten van de verbinding verwijderen die de operator al heeft geleverd. Op een 1 Gbit/s-verbinding maakt een inkomende aanval die groter is dan deze capaciteit de diensten onbeschikbaar, zelfs als de router elk pakket perfect afwijst.

Bereid dus een escalatieplan voor vóór het incident :

contactgegevens van het netwerkcentrum van de operator en noodprocedure ;
drempel vanaf wanneer een filtering, een tijdelijke blackhole of een cleaning van het verkeer wordt gevraagd ;
CDN en WAF voor de openbare HTTP-diensten ;
DNS met TTL en back-uptoegang aangepast aan het continuïteitsplan ;
externe metrieken om de zichtbaarheid te behouden wanneer de site niet meer bereikbaar is ;
beperkte captures, tijdstempels, serverlogboeken en geschiedenis van volumes voor de analyse.

Een serieuze bescherming combineert meerdere lagen : vroege filtering in de router, beperking in de reverse proxy, cache en WAF op HTTP-niveau, en dan mitigatiecapaciteit bij de hostingprovider of de operator.

Veelvoorkomende fouten om te vermijden

De serverdetectie in input plaatsen : het doorgestuurde verkeer passeert forward.
Een bron op alle poorten blokkeren gedurende een week : de fout-positief wordt duurzaam en globaal.
De drempel 32/32 kopiëren zonder te meten : het legitieme verkeer varieert sterk naargelang de architectuur.
De volgorde van de regels vergeten : een algemene acceptatie geplaatst vóór de detectie maakt deze onzichtbaar.
Elke afwijzing loggen : de logs kunnen CPU, geheugen en opslag verbruiken tijdens de aanval.
Filtering en capaciteit verwarren : een lokaal gedropt pakket heeft de internetverbinding al gepasseerd.
IPv6 negeren : de IPv4-regels beschermen geen dienst die ook in IPv6 is gepubliceerd.

Conclusie

RouterOS kan een matige aanval tegen een gepubliceerde server efficiënt opvangen : dst-limit detecteert een te actief bron-bestemmingspaar, een dynamische lijst plaatst de bron in quarantaine en RAW dropt de volgende pakketten vóór de verbindingstracking. De bescherming wordt efficiënter wanneer ze gericht is op de interface, het protocol en de poorten die daadwerkelijk blootgesteld zijn.

De juiste afstelling is nochtans niet degene die de langste zwarte lijst produceert. Het is degene die de belasting vermindert zonder legitieme bezoekers te straffen, snel verloopt, observeerbaar blijft en past in een escalatieplan stroomopwaarts wanneer het volume de capaciteit van de verbinding overschrijdt.

Technische referenties

Over de auteur

Jeremy Kraft beheert de infrastructuur en de zelfgehoste diensten van het IBCSC. Deze gidsen beschrijven configuraties die echt zijn uitgerold en voor publicatie opnieuw zijn nagekeken.

Een vraag stellen Alle gidsen

Discussie

Reacties

Nog geen reacties. U kunt de discussie openen met een vraag of uw eigen ervaring.