I have on my gateway router mikrotik version 3.30. It's most stable on a current hardware.

I would like to block tcp syn flood attempts from clients inside my network to clients in the internet. I tried this:

/ip firewall filter
add action=jump chain=forward comment="SYN Flood protect" disabled=no jump-target=SYN-floodcheck protocol=tcp src-address-list=LOKAL tcp-flags=syn
add action=accept chain=SYN-floodcheck comment="" disabled=no dst-limit=1000,0,addresses-and-dst-port/10s protocol=tcp src-address-list=LOKAL tcp-flags=syn
add action=drop chain=SYN-Protect comment="" disabled=no

First rule should direct tcp packets with syn flag from LAN to SYN-floodcheck chain. Second rule should allow all packets (if there is less than 1000 packets each seconds). Third rule should drop all overlimit packets.

But this doesn't work. Third rule is used even though packet rate at second rule is around 40 pps which shouldn't happen.

Could this be a bug in dst-limit matcher?

Thanks

Your second rule works properly, if there is less than 1000 pps, they are accepted and third rule drop them.
Change second rule to: Up to 1000 pps rule returns from 'SYN-floodcheck' chain and third rule is not triggered.
Over 1000 pps there is no return and third rule drops packets.

HTH,

Your second rule works properly, if there is less than 1000 pps, they are accepted and third rule drop them.
Change second rule to:

Code: Select all

action=return

Up to 1000 pps rule returns from 'SYN-floodcheck' chain and third rule is not triggered.
Over 1000 pps there is no return and third rule drops packets.

HTH,

Thank you for reply. Return is better than accept in this situation. But it's not the main problem. Now even if there is less than 1000pps third rule (drop) is used. I can see packet statistics for second rule and it is around 45 pps. Even if all 45 pps are syn flood packets (highly unprobable) than it shouldn't pass the packet to third rule (it's much less than 1000 pps).

It seems like second rule (dst-limit) is leaking some packets without reason.

Third rule chain name should be the same as second.
Now name is:

chain=SYN-Protect

Change it to:

chain=SYN-floodcheck

HTH,

Third rule chain name should be the same as second.
Now name is:

chain=SYN-Protect

Change it to:

chain=SYN-floodcheck

HTH,

Thanks again. I've noticed that typo today morning. But it doesn't help. Even though i can see low packet rate first and second rules packet counts are different which means that second rule is leaking some packets to third rule.

I tried packet sniffer (wireshark) and there are just couple syn packets each second and second rule doesn't catch them all. Strange.

Sum of packet counts of second and third rules should be equal to packet count of first rule.
I have similar configuration and packet counters shows results as described above.

Regards,

I have opened support ticket a few weeks ago ([Ticket#2011090366000021] 'dst-limit' matcher):

Hello.

From my observations, RouterOS upto v5.6 is still confused with 'Expire' value of 'dst-limit' matcher in firewall.

When using default value of "100.00" in WinBox, it's shown as "1m40s" in Terminal, and is actually ten seconds. It follows from iptables manual that expire value is in hundreds of milliseconds, so WinBox's "100.00" means actually "100.00 x 100ms", i.e. 10s. Please fix =)

Also, 'dst-limit' matches first 'Burst' packets (as it should be) plus one, and then skips packets for the first second. So if you have Rate=10 and Burst=50, and you start to flood packets, the rule will match 51 packets, and on 52nd packet it won't match until 1sec passes. Then it will match 10 more packets. Could you please change ths behaviour so that it will be more obvious: in first second rule should match 'Burst + Rate' packets, and then stop matching until one second passes.

Thanks =)

--
Trying to make RouterOS even better =)

I still have only automatic reply...

so, try to change your "dst-limit=1000,0," to "dst-limit=1000,1000,"

actually, 1000 is way too much, look at my topic http://forum.mikrotik.com/viewtopic.php?f=2&t=54607

Is this still not fixed? It's actually listed in the wiki at https://wiki.mikrotik.com/wiki/DDoS_Det ... d_Blocking (Expire' value is 10 times lower than you set; so '10s' is actually 1 second)

Please, do not send tickets to old versions - there is no point and it just waste support time.
Staff will either ignore it or respond with "please update to maintained (bugfix or current) version.

You cannot possibly think that anyone will investigate or fix bug from 8 years old version. Even legacy 5.6 was released around 2013. These things are long forgotten.

Please, do not send tickets to old versions - there is no point and it just waste support time.
Staff will either ignore it or respond with "please update to maintained (bugfix or current) version.

You cannot possibly think that anyone will investigate or fix bug from 8 years old version. Even legacy 5.6 was released around 2013. These things are long forgotten.

Looking at my results I think this "cosmetic bug" is still in current 6.42.x
I'm just asking if anyone can confirm!