Is there way to make the rule less sensitive? Yesterday I browse on my web server and my Firefox hangs and retry to many times and I flag as a ddoser.
Thanks!
dst-limit=32,32 is what you’re looking for. try to change it to dst-limit=32,256 for higher burst
sorry to hijack your post, can you give us some details about size of that attack(bandwidth) and what router(s) did you have? PC or appliance…
thank you…
PC routers, different attacks - sometimes upto 200 Mbps is blocked from customers to the internet 
Is this suitable for INPUT chain. Has any sense? I think the router can be the objetive too.
if you block forwarded traffic - you stop its propagation across the router.
if you block input - traffic is already here, it won’t go further, so you don’t decrease network load
that’s why you simply need to protect the router from accessing by unauthorized users (my means of management subnet or something)
But your rules are blocking the tcp syn flood attacks to the router too if input chain is objective???
kind of. but for router itself I’d rather do much more strict rules. and enable TCP SYN Cookies
Is it somehow possible to make these rules more efficient? Currently every new connection is counted, jumped into new chain and there again counted and if below the threshold returned to forwarding chain…
I’ve tried SYN cookies enabled attacking a Basebox2 directly with a tcp syn flood attack and the results in cpu resoruces where 10-15% higher compared with this rule woithout SYN cookies. I’ll block the same attack sanving that ammount of cpu:
/ip firewall filter add chain=forward protocol=tcp tcp-flags=syn connection-state=new \
action=jump jump-target=SYN-Protect comment="SYN Flood protect" disabled=yes
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn limit=400,5 connection-state=new \
action=accept comment="" disabled=no
/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn connection-state=new \
action=drop comment="" disabled=no
At this point I have that previous rule, yours and limitting the connections per user twice.
It seems excessive. ¿Can you tune up my setup? Have in mid this is a hotspot and must be secures for the use is intended for. We dont want massive connections from an IP and want maximal security from attacks to and throug the router. We have seen this hardware with cpu +90% without users and only with a synflood attack.
Thanks in advance for your replies master. You are being very helpful for us.
[juanvi@HotSpot1] /ip firewall> export
# jun/27/2014 08:05:59 by RouterOS 6.15
# software id = EJJG-9K3N
#
/ip firewall filter
add action=jump chain=input comment=\
"SYN Flood protect - http://wiki.mikrotik.com/wiki/DoS_attack_protection" \
connection-state=new jump-target=SYN-Protect protocol=tcp tcp-flags=syn
add chain=SYN-Protect connection-state=new limit=400,5 protocol=tcp tcp-flags=\
syn
add action=drop chain=SYN-Protect connection-state=new protocol=tcp tcp-flags=\
syn
add action=jump chain=input comment="CONTROL BIDIRECCIONAL DE SOLICITUDES MASIVA\
S - DDOS http://wiki.mikrotik.com/wiki/DDoS_Detection_and_Blocking - http://\
forum.mikrotik.com/viewtopic.php\?f=2&t=54607" connection-state=new \
jump-target=block-ddos-input
add action=return chain=block-ddos-input dst-limit=\
50,50,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddosed-input \
address-list-timeout=10m chain=block-ddos-input
add action=add-src-to-address-list address-list=ddoser-input \
address-list-timeout=10m chain=block-ddos-input
add action=drop chain=input connection-state=new dst-address-list=ddosed \
src-address-list=ddoser
add action=jump chain=forward comment="CONTROL BIDIRECCIONAL DE SOLICITUDES MASI\
VAS - DDOS http://wiki.mikrotik.com/wiki/DDoS_Detection_and_Blocking - http:\
//forum.mikrotik.com/viewtopic.php\?f=2&t=54607" connection-state=new \
jump-target=block-ddos
add action=return chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m \
chain=block-ddos
add action=add-src-to-address-list address-list=ddoser address-list-timeout=10m \
chain=block-ddos
add action=drop chain=forward connection-state=new dst-address-list=ddosed \
src-address-list=ddoser
add action=add-src-to-address-list address-list=blocked-addr \
address-list-timeout=1d chain=input comment=\
"LIMITE DE CONEXIONES POR IP - DDOS" connection-limit=75,32 protocol=tcp
add action=tarpit chain=input connection-limit=3,32 protocol=tcp \
src-address-list=blocked-addr
add action=add-src-to-address-list address-list=blocked-addr \
address-list-timeout=1d chain=forward comment=\
"LIMITE DE CONEXIONES POR IP - DDOS" connection-limit=75,32 protocol=tcp
add action=tarpit chain=forward connection-limit=3,32 protocol=tcp \
src-address-list=blocked-addr
add chain=input comment="GENERAL - PERMITE CONEXIONES ESTABLECIDAS" \
connection-state=established
add chain=input comment="PERMITE CONEXIONES RELACIONADAS" connection-state=\
related
add action=drop chain=input comment="DROP CONEXIONES INVALIDAS" \
connection-state=invalid
add chain=forward comment="GENERAL - PERMITE CONEXIONES ESTABLECIDAS" \
connection-state=established
add chain=forward comment="PERMITE CONEXIONES RELACIONADAS" connection-state=\
related
add action=drop chain=forward comment="DROP CONEXIONES INVALIDAS" \
connection-state=invalid
add action=passthrough chain=unused-hs-chain comment="place hotspot rules here" \
disabled=yes
/ip firewall nat
add action=passthrough chain=unused-hs-chain comment="place hotspot rules here" \
disabled=yes to-addresses=0.0.0.0
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
src-address=10.5.50.0/24 to-addresses=0.0.0.0
juanvi, do you really need ‘connection-limit’ in that case? I don’t think the limit of 75 connections is actually doing something valuable…
hi Chupaka
According to your 1st post. Will all people that use more than ex. 50 connection with web browser or torrent client get block for 10 minutes in or outside my nated lan?
pls confirm.
thx
not 50 connections, but 50 connections per second, and only exceeding connections will be blocked, but you can modify a rule to block all packets from the flooding source
Note: At least up to version 5.6, ‘dst-limit’ matcher has two bugs:
‘Expire’ value is 10 times lower than you set; so ‘10s’ is actually 1 second
‘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 set to 32 and Burst set to 0, and you start to flood packets, the rule will match 1 packet, and on 2nd packet it won’t match until 1sec passes - that’s why you need ‘Burst’ value at least as high as ‘Rate’ value
Does the first bug solved in v5.26 ?
sorry for the long delay
nope, v6.18 (x86), the bug is still here
also, when WinBox shows this:
(which means ‘30s’ in Terminal and is actually 3s in reality), one can look at it like 3000 ms (ignoring the point), which is truth
These rules leaves too many tcp connections established counting down.
If I use reject instead of drop, does it solve this problem?
instead of dropping, would tarpit work better in reducing CPU and bandwidth used for preventing DoS? I constantly get bombarded by adware botnets trying to route through my router but i find using tarpit frees up a lot of bandwidth and CPU.
Also i noticed that you cant set a rate limit in routerOS because than anything more than the rate limit would passthrough.
Thanks Chupaka.
Did you tried this rule on higher than V6? Is the bug you introduced in the wiki fixed?
Note: At least up to version 5.6, ‘dst-limit’ matcher has two bugs:
‘Expire’ value is 10 times lower than you set; so ‘10s’ is actually 1 second
‘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 set to 32 and Burst set to 0, and you start to flood packets, the rule will match 1 packet, and on 2nd packet it won’t match until 1sec passes - that’s why you need ‘Burst’ value at least as high as ‘Rate’ value
Is it good idea to have following rules in addition to action=drop ?
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address-list=ddosed new-routing-mark=ddoser-route-mark passthrough=no src-address-list=ddoser
/ip route
add distance=1 routing-mark=ddoser-route-mark type=blackhole
hm-m-m… the idea is interesting, but I’m not sure about packet flow with such route if packet won’t go to firewall filter after that, then it’s good addition. did you check the behaviour?