Documentation inconsistency

Site Feedback
1

In the documentation for “DDoS Protection”, there are two blocks of code.

The “Configuration lines”, containing the following:

/ip firewall address-list
  add list=ddos-attackers
  add list=ddos-targets
/ip firewall filter
  add action=return chain=detect-ddos dst-limit=32,32,src-and-dst-addresses/10s
  add action=add-dst-to-address-list address-list=ddos-targets address-list-timeout=10m chain=detect-ddos
  add action=add-src-to-address-list address-list=ddos-attackers address-list-timeout=10m chain=detect-ddos
/ip firewall raw
  add action=drop chain=prerouting dst-address-list=ddos-targets src-address-list=ddos-attackers

And the “Configuration explained”, which (after some small re-organization) read as such:

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

The keen eyed under us may have noticed that the “Configuration lines” miss the “add chain=forward” line.
As a result, the firewall rules do not work (unless the user notices this error) as there is no jump happening.
Of course, people should always read instead of just blindly copy-pasting, however a fix would still be appreciated.

2

Good catch !

Best to create support ticket.
This is a user forum. MT staff doesn't follow all threads here.

1 Like
3

Ticket has been created.

4

Good catch, but unless I am mistaken, from "First, we will send every new connection to the specific firewall chain where we will detect DDoS", the:

add chain=forward connection-state=new action=jump jump-target=detect-ddos

should go before the:

add action=return chain=detect-ddos dst-limit=32,32,src-and-dst-addresses/10s
5

Would read better but to my knowledge the order for those 2 doesn’t quite matter.
I could be wrong of course.

6

Yep, I also believe that in this case order doesn't functionally matter, but the text should then be changed to something to the effect of:
First we write this as second rule, then (second) we write this other rule and we place it before the former (thus the latter will be the first one)...
or:
First we have this rule, but we write before it, in the chain we haven't yet created ...

Not very linear ...

7

What's really important to note is that these rules fill up the home router's memory with IP addresses until it overflows and reboots or lock.

It's best not to have them and explain not to leave WAN services open.

8

I think this is a whole other issue that goes beyond the scope of this post. :stuck_out_tongue:

9

They have fixed it. \o/

10

The other consideration to make is that if the packet is sent to you, only the ISP can block it BEFORE it clogs up your line,
otherwise, whether you block them or not, they will always take up your bandwidth...

11

To @rextended's point, could add a commentary that no DDoS solution is complete. And perhaps have short explaination that script does in fact short-circuit more expensive processing on router... Perhaps note on the use of jump/return since it's also a good example of "optimizing" firewall rules and the perils therein.

1 Like