Configuring DDoS Protection on MikroTik Without Blocking Legitimate Visitors
Detect bursts of new connections, temporarily quarantine abusive sources and block them early in RAW, while understanding the router's limitations.
A denial-of-service attack does not always start with hundreds of gigabits. It can take the form of a few hundred new connections per second, enough to saturate the web server, the database, or the router's connection tracking table. In this scenario, MikroTik can detect abnormally active sources and drop their packets before they consume more resources.
This protection remains local. It can preserve the server and router CPU as long as the Internet link still has capacity. If hostile traffic already fills the link provided by the operator, the router receives the packets too late: upstream action is then required, such as a CDN with DDoS protection, a WAF, a scrubbing service, or operator filtering.
DoS, DDoS, and application saturation
A DoS attack originates from a single source or a small group of sources. A DDoS attack distributes traffic across many compromised machines or connected devices. The distinction does not change the primary objective: prevent abusive packets from exhausting a resource before legitimate requests do.
| Attack form | Targeted resource | What MikroTik can do |
|---|---|---|
| TCP connection burst | Conntrack, firewall, web server | Limit new connections and quarantine sources |
| SYN flood | Queue of incomplete TCP connections | Enable SYN cookies and filter bursts |
| Realistic HTTP flood | Application, PHP, database | Provide clues, but a WAF or application-level rate limiting remains necessary |
| UDP amplification | Downstream bandwidth | Block certain packets locally, without freeing the already saturated link |
| Volumetric attack | Internet link capacity | Escalate to the operator or an upstream mitigation service |
Recognize the incident before modifying the firewall
A server CPU close to 100 %, a highly active database, and a sudden spike in connections do not by themselves prove an attack. A legitimate campaign, a crawling bot, an application loop, or a misconfigured client can produce similar symptoms.
In RouterOS, Torch displays in real time the flows observed on an interface and allows sorting them by source address, destination address, port, and protocol. It shows traffic before filtering: a source can therefore remain visible even if the firewall already blocks it.
/tool/torch interface=ether1
/interface monitor-traffic ether1Adapt ether1 to your actual WAN link. Compare the results with the logs from the reverse proxy or web server. Monitor especially:
- the number of new connections per source and per destination;
- the ports and protocols actually targeted;
- the throughput in bit/s and the number of packets per second;
- the size of the connection tracking table;
- the CPU usage of the router and the server;
- HTTP codes, response times, and repeated requests on the application side.
A single address opening many sessions can be blocked manually, but a static list quickly becomes unmanageable during a distributed attack. The objective is therefore to create a dynamic, short, and measurable quarantine.
Understanding dst-limit correctly
The dst-limit parameter applies a distinct limit to each flow defined by its mode. Its syntax is:
dst-limit=taux[/période],rafale,mode[/expiration]In the following expression:
dst-limit=32,32,src-and-dst-addresses/10s32is the allowed rate, here 32 packets per second since no different period is specified;- the second
32is the allowed initial burst; src-and-dst-addressescreates a counter per source-destination pair;10sis the timeout for an inactive counter, not a ten-second window for the 32 packets.
The rule with the return action accepts in the detection chain the flows that remain under the limit. When the bucket is exhausted, it no longer matches: the packet falls through to the following rules, which place the source in a dynamic list.
Why the input and forward chains are not interchangeable
The input chain processes packets destined for the router itself. The forward chain processes those passing through the router to another machine. A web server published via dst-nat is therefore protected in forward, even if the client contacts the MikroTik's public address.
A detection rule placed only in input might increment its counters for WebFig or a VPN hosted on the router, but it will not correctly see the traffic redirected to the internal server.
forward; subsequent packets from quarantined sources can be dropped earlier in RAW.Before starting: back up and work in safe mode
An ordering or chain error can cut off access to the router. Connect from the LAN, enable Safe Mode in WinBox or with Ctrl+X, then export the configuration.
/export file=avant-protection-ddos
/system backup save name=avant-protection-ddosVerify that the WAN interface list actually contains the Internet link and that the server already operates behind a dst-nat rule. The ports used in RAW must be the public ports before translation. If external port 8443 is translated to 443, specify 8443 in the RAW rule.
Targeted configuration for a web server behind dst-nat
The following rule set is intentionally limited to new TCP connections arriving from the WAN list to a service published on 80 or 443. It avoids turning web detection into a global ban on all communication with the source address.
1. Prepare an exclusion list
Add to ddos-allow only the external addresses that are truly trusted: monitoring, reverse proxy, or official CDN ranges. The address below belongs to a block reserved for documentation and must be replaced.
/ip firewall address-list
add list=ddos-allow address=198.51.100.10 \
comment="RFC 5737 EXAMPLE - replace"2. Send new web connections to a dedicated chain
/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: inspect new Web connections"Place this rule after accepting established,related connections and dropping invalid packets, but before the rule that allows new dstnat connections. It does not replace the normal firewall.
3. Define the threshold and quarantine
/ip firewall filter
add chain=detect-ddos-web action=return \
dst-limit=32,32,src-and-dst-addresses/10s \
comment="DDoS: traffic below threshold"
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: drop triggering packet"The ten-minute duration limits the cost of a false positive. A week of automatic blocking is rarely justifiable without further analysis: addresses change, visitors share a CGNAT egress, and legitimate service relays can concentrate many connections.
4. Block early 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: block Web before conntrack"RAW intervenes before connection tracking. The router thus avoids creating a conntrack entry for each new packet already identified as abusive. The rule remains limited to the WAN and public web ports: the quarantined address is not arbitrarily blocked on all other services.
Official variant by source-destination pair
The MikroTik documentation proposes a generic logic that places both the source in ddos-attackers and the destination in ddos-targets, then blocks in RAW only when both lists match. This method is elegant for a routed public destination without translation.
/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-targetsWith dst-nat, the forward filter might see the internal address after translation while RAW still sees the public address. The destination lists might therefore not designate the same address at both stages. This is why the previous configuration blocks by source, but only on the WAN and the explicitly protected public ports.
Enable SYN cookies
For SYN floods, RouterOS also features SYN cookies. They reduce the amount of state kept until the client proves it actually receives the TCP response.
/ip settings set tcp-syncookies=yesThis option complements rate limiting but does not replace firewall rules or the server's capacity to handle complete HTTP requests. A bot capable of correctly establishing TCP and TLS can still stress the application.
Test without locking yourself out
- Start with a high threshold and observe the counters during a normal period and a peak period.
- Verify the rule order with
/ip firewall filter print statsand/ip firewall raw print stats. - Monitor the dynamic list without logging every dropped packet.
- Test from a controlled external address, with a limited load tool and only against your own service.
- Confirm that a normal visitor remains served, that the server responds, and that the load decreases when the quarantine triggers.
- Exit Safe Mode only after validation and keep the export outside the 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-onlyAvoid log=yes on a rule that might match thousands of packets per second. Writing and processing messages can become a second attack against the router. Use rule counters, list sizes, and, if necessary, Traffic Flow to an external collector.
When local protection is no longer enough
A MikroTik cannot remove packets from the link that the operator has already delivered to it. On a 1 Gbit/s connection, an incoming attack exceeding this capacity makes services unavailable even if the router perfectly drops every packet.
Therefore, prepare an escalation plan before the incident:
- operator's network center contact details and emergency procedure;
- threshold at which to request filtering, temporary blackhole, or traffic scrubbing;
- CDN and WAF in front of public HTTP services;
- DNS with TTL and fallback access adapted to the continuity plan;
- external metrics to maintain visibility when the site is no longer reachable;
- limited captures, timestamps, server logs, and volume history for analysis.
Serious protection combines multiple layers: early filtering in the router, rate limiting in the reverse proxy, caching and WAF at the HTTP level, and mitigation capacity at the host or operator level.
Common mistakes to avoid
- Placing server detection in
input: redirected traffic traversesforward. - Blocking a source on all ports for a week: the false positive becomes durable and global.
- Copying the 32/32 threshold without measuring: legitimate traffic varies greatly depending on the architecture.
- Forgetting rule order: a general acceptance placed before detection makes it invisible.
- Logging every drop: logs can consume CPU, memory, and storage during the attack.
- Confusing filtering and capacity: a locally dropped packet has already crossed the Internet link.
- Ignoring IPv6: IPv4 rules do not protect a service also published in IPv6.
Conclusion
RouterOS can effectively mitigate a moderate attack against a published server: dst-limit spots an overly active source-destination pair, a dynamic list quarantines the source, and RAW drops subsequent packets before connection tracking. The protection becomes more efficient when targeted to the interface, protocol, and ports actually exposed.
However, the right tuning is not the one that produces the longest blacklist. It is the one that reduces load without punishing legitimate visitors, expires quickly, remains observable, and integrates into an upstream escalation plan when the volume exceeds the link capacity.
Technical references
Read next
About the author
Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.