DDoS story, or WARNING: use 'conection-limit' with caution!

Chupaka · Tue Aug 30, 2011 12:05 pm

Sunday and Monday were horrible days...

It was the first time our network became the source of DDoS attack. TechSupport woke me up at about 13:00 - users were complaining about very slow Internet access with high packet drop rate. Guess what I did first? Yes, after a few minutes I rebooted the router

And guess what? After reboot, the picture stayed the same. Even pinging router's address (or 127.0.0.1) from the router itself was showing 200-500ms RTT with 50% of timeouts.

After about fifteen minutes of searching and trying I identified that the reason was my firewall filter fules for limiting the number of simultaneous TCP connections per user: they were showing high rate of dropped packets, and when I was disabling them, router was becoming stable again.

It appeared that some kind of virus or botnet on customers' computers was attacking single IP address (some Lineage II game server) by creating huge number of HTTP requests to the host (when I blocked any packets to that server, filter rule was dropping about 4000 new connections per second). So, when 'connection-limit' matcher was trying to count active user's connections a few thousand times per second, it was killing the router completely.

In Monday, attacked IP addresses changed, so this horror returned back

After a dozen of minutes I came to this solution:

/ip firewall filter
add chain=forward connection-state=new action=jump jump-target=block-ddos
add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m

It dynamically creates two address lists: attackers ('ddoser') and attacked hosts ('ddosed'), and blocks packets from the former to the latter. Works like a charm =)

Hope this will help somebody to protect his routers from flooding...

MRMISSY · Tue Aug 30, 2011 12:37 pm

that is nice
thanks for sheering

MCT · Tue Aug 30, 2011 5:53 pm

+1 for a detection based solution rather than just blocking ports.

mh76bih · Sat Dec 24, 2011 1:11 am

hi, i have same problem.,but those scripts des not help me.
all day i have problem from one ip have attack on whole subnet 512 ip addresses.
any idea how to resolve this problem.
attack comming from 50006 port tcp protocol
thanks

MCT · Sat Dec 24, 2011 9:27 am

You shouldn't bump really old threads, it's considered bad forum etiquette.

That aside since all of your issues are from a single address simply create a rule to drop all traffic from that IP.

I looked up the source IP in a security database and it's a frequent offender for attacking networks. I always prefer a detection based solution but in your situation I'd block that IP at the edge of my network.

mh76bih · Sat Dec 24, 2011 9:46 am

now its happen again, any solutions, pls

MCT · Sat Dec 24, 2011 10:14 am

No one will be able to help unless you post detailed information about the traffic. The most helpful thing would be to do a packet capture of the traffic and post it.

If the attack address shifted then the alternate approach would be to create a queue rule to throttle the traffic down to a trickle. Most automated attack tools won't shift if the connections are still open.

Chupaka · Sat Dec 24, 2011 3:00 pm

select 'Protocol' and 'Port', there's not so much info to help you. what port of 115.238.184.5 is attacked?

are you dropping invalid connections in firewall filter?

mh76bih · Sat Dec 24, 2011 7:05 pm

protocol is tcp source ip :115.238.184.5, source port 50006
when that happen i have traffic allmost on all public ip in subnet /23 around 360kbps per ip
and upload on my network is 90-150Mbps.

Chupaka · Sat Dec 24, 2011 8:27 pm

so the traffic is from 109.175.20.0/24 to 115.238.184.5:50006 - what are those addresses? is there some service at 115.238.184.5:50006?

mh76bih · Sun Dec 25, 2011 1:53 am

109.175.20.0/23 is my network, attack comming from 115.238.184.5 port 50006 protcol tcp

Chupaka · Mon Dec 26, 2011 2:27 pm

according to your screenshot, it's your network who attacks 115.238.184.5:50006 (without any response, btw)

dingsingo · Mon Dec 26, 2011 3:25 pm

@Chupaka

++1

THx's

THG · Mon Dec 26, 2011 5:53 pm

The Tech Support woke you up at 13:00, so cruel indeed!

Anyway, thanks for sharing your experience with us, Chupaka!

Chupaka · Mon Dec 26, 2011 11:34 pm

The Tech Support woke you up at 13:00, so cruel indeed!

well, maybe better English version would be "at 13:00 a.m."

spektrumzx · Sun Jan 22, 2012 10:53 am

I tested those setting and I get between 2000-5000 addresses in list as ddosed or ddoser.
I have about 600 users all connected PPPOE.
Is it a normal thing or something is wrong?

Thanks in advance,

Sunday and Monday were horrible days...

It was the first time our network became the source of DDoS attack. TechSupport woke me up at about 13:00 - users were complaining about very slow Internet access with high packet drop rate. Guess what I did first? Yes, after a few minutes I rebooted the router And guess what? After reboot, the picture stayed the same. Even pinging router's address (or 127.0.0.1) from the router itself was showing 200-500ms RTT with 50% of timeouts.

After about fifteen minutes of searching and trying I identified that the reason was my firewall filter fules for limiting the number of simultaneous TCP connections per user: they were showing high rate of dropped packets, and when I was disabling them, router was becoming stable again.

It appeared that some kind of virus or botnet on customers' computers was attacking single IP address (some Lineage II game server) by creating huge number of HTTP requests to the host (when I blocked any packets to that server, filter rule was dropping about 4000 new connections per second). So, when 'connection-limit' matcher was trying to count active user's connections a few thousand times per second, it was killing the router completely.

In Monday, attacked IP addresses changed, so this horror returned back After a dozen of minutes I came to this solution:
Code: Select all
/ip firewall filter
add chain=forward connection-state=new action=jump jump-target=block-ddos
add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m
It dynamically creates two address lists: attackers ('ddoser') and attacked hosts ('ddosed'), and blocks packets from the former to the latter. Works like a charm =)

Hope this will help somebody to protect his routers from flooding...

omidkosari · Sun Jan 22, 2012 6:39 pm

Thanks for sharing your knowledge and experience .

spektrumzx · Mon Jan 23, 2012 10:25 pm

I tested those settings and I get between 2000-5000 addresses in lists as ddosed or ddoser.
I have about 600 users all connected PPPOE.
Is it a normal thing or something is wrong?

Thanks in advance,

Chupaka · Fri Jan 27, 2012 11:55 am

I tested those settings and I get between 2000-5000 addresses in lists as ddosed or ddoser.
I have about 600 users all connected PPPOE.
Is it a normal thing or something is wrong?

Thanks in advance,

is everything else working normally? are 'ddoser's your addresses, or some Internet ones?

spektrumzx · Fri Jan 27, 2012 1:58 pm

I tested those settings and I get between 2000-5000 addresses in lists as ddosed or ddoser.
I have about 600 users all connected PPPOE.
Is it a normal thing or something is wrong?

Thanks in advance,
is everything else working normally? are 'ddoser's your addresses, or some Internet ones?

I hope that I have good feedback so everything else looks fine. Right now I have about 540 PPPoE connection and 1600 ddoser's in list all some internet addresses except two of them that my.
Also I have a rule before this, with limit the number of tcp connections on 150 per user.

guilhermeramires · Tue Apr 24, 2012 7:54 pm

I tested those settings and I get between 2000-5000 addresses in lists as ddosed or ddoser.
I have about 600 users all connected PPPOE.
Is it a normal thing or something is wrong?

Thanks in advance,

Probably you have some nat mascared rules in the LAN. So all ip address come from only one host natted. The solution is you
route your LAN and remove the NATs rules, ok?

Regards.

angboontiong · Fri Jun 22, 2012 3:28 pm

Dear Chupaka...
This cannot put in the Wireless link which before the EOIP...

else, it will drop the EOIP connection as we found today...
seem we should put another access rules in front of this to allow the peer EOIP ip address to skip on this check...

Chupaka · Fri Jun 22, 2012 10:54 pm

seem we should put another access rules in front of this to allow the peer EOIP ip address to skip on this check...

yep, check this: http://wiki.mikrotik.com/wiki/DDoS_Dete ... d_Blocking
there I added a note about exceptions

Dobby · Sat Jun 23, 2012 12:26 am

Deleted because not related.

spire2z · Sat Jun 23, 2012 5:03 am

One way to not be woken by tech support is to never sleep!

Chupaka · Sat Jun 23, 2012 2:37 pm

Dobby, the rules above will not match against the behaviour you described. actually, they detect DoS, so each game server will be examined separately. moreover, game server won't generate dozens of packets on initial connection

Dobby · Sat Jun 23, 2012 3:18 pm

Deleted because not related.

Chupaka · Sat Jun 23, 2012 7:49 pm

thanks for sharing your concern, but in my example I use 'forward' chain - there all addresses are de-NAT-ted, and router knows, which client should receive the packet - there's no 'address of the router' already

main problem I faced is 'bad' websites which block HTTP keep-alive connections, and for opening one page with many small pictures user creates about 30-60 TCP connections... but blocking such sites should be avoided by using 'burst' in 'dst-limit' matcher

p.s. no, at endpoint we use customers' PCs - we are Ethernet provider

Kiken · Fri Aug 10, 2012 4:59 pm

Hi man, i've just added this rule to my MK Router:

/ip firewall filter

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

and its showing as invalid, any ideas on what should be wrong??

Chupaka · Mon Aug 13, 2012 3:53 pm

it's because your 'block-ddos' chain is empty. add another rules - and everything will be okay

daived · Mon Jan 13, 2014 12:46 am

Hi, sorry for this post, the topic is very old, but:

add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m disabled=yes

What router will write in this list? My local ip what is ddosed now? If i currently have only one active IP, i need this rule?
So for me its working like 'ddoser' are blocked from 'ddosed' IP, this need only if i have many IPS, but if only one?
Thanks!

Chupaka · Mon Jan 13, 2014 3:07 am

daived, if you re-read the first post, you can see that 'ddosed' addresses can be not only your local users, but remote hosts (when some botnet is running on your customers' PCs). also, router's addresses won't be detected, as that traffic is in 'input' chain of firewall, and my rules catch 'forward' traffic

NumLock · Wed Feb 19, 2014 3:28 pm

This help a lot to prevent attackers eat my bandwidth fist attack was 100mbps on icmp and UDP (17) and hang my MK.
The rule works properly but after few hours to deploy customer was unable to browse or access to the internet I just add in-interface=ether1 (My ether1 is the wan interface) and problem solve my question is:

Is this is right to add the input interface?
Here is my complete rule:

/ip firewall filter
add action=jump chain=forward comment=Detect-Ddos connection-state=new \
disabled=no jump-target=detect-ddos
add action=return chain=detect-ddos comment=Detect-Ddos disabled=no \
dst-limit=32,32,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no
add action=add-src-to-address-list address-list=ddoser address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no
add action=drop chain=forward comment=Detect-Ddos connection-state=new \
disabled=no dst-address-list=ddosed in-interface=ether1 src-address-list=\
ddoser

Wed Feb 19, 2014 6:46 pm

Thanks Chupaca it is a usefull solution.
Karma +1

Chupaka · Wed Feb 19, 2014 9:57 pm

NumLock, you'd better add in-interface= matcher to the first rule. in your implementation, it blocks only incoming packets, but detects (D)DoS in both directions - probably, unnecessary additional work

NumLock · Wed Feb 19, 2014 10:19 pm

Like this: ?

/ip firewall filter

add action=jump chain=forward comment=Detect-Ddos connection-state=new \
disabled=no in-interface=ether1 jump-target=detect-ddos

add action=return chain=detect-ddos comment=Detect-Ddos disabled=no \
dst-limit=32,32,src-and-dst-addresses/10s

add action=add-dst-to-address-list address-list=ddosed address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no

add action=add-src-to-address-list address-list=ddoser address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no

add action=drop chain=forward comment=Detect-Ddos connection-state=new \
disabled=no dst-address-list=ddosed in-interface=ether1 src-address-list=\
ddoser

Chupaka · Wed Feb 19, 2014 10:26 pm

yep, and remove in-interface=ether1 from the last rule

NumLock · Fri Feb 21, 2014 5:46 pm

Thanks this help a lot. Over 20,000 IP has been ban. Last configuration work so far so good:

/ip firewall filter
add action=jump chain=forward comment=Detect-Ddos connection-state=new \
disabled=no in-interface=ether1 jump-target=detect-ddos
add action=return chain=detect-ddos comment=Detect-Ddos disabled=no \
dst-limit=32,32,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no
add action=add-src-to-address-list address-list=ddoser address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no
add action=drop chain=forward comment=Detect-Ddos connection-state=new \
disabled=no dst-address-list=ddosed src-address-list=ddoser

NumLock · Tue Feb 25, 2014 6:55 pm

/ip firewall filter
add action=jump chain=forward comment=Detect-Ddos connection-state=new \
disabled=no in-interface=ether1 jump-target=detect-ddos
add action=return chain=detect-ddos comment=Detect-Ddos disabled=no \
dst-limit=32,32,src-and-dst-addresses/10s
add action=return chain=detect-ddos comment=DOS-Exceptions disabled=no \
src-address-list=DOS-Exceptions
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no
add action=add-src-to-address-list address-list=ddoser address-list-timeout=\
1w chain=detect-ddos comment=Detect-Ddos disabled=no
add action=drop chain=forward comment=Detect-Ddos connection-state=new \
disabled=no dst-address-list=ddosed src-address-list=ddoser

With this rule in blue I can make exceptions?

Chupaka · Wed Feb 26, 2014 3:15 pm

yes, but you'd better place it as a second rule, not third, so that router doesn't need to check limits for the traffic that will never be added as a 'ddoser'

NumLock · Wed Feb 26, 2014 3:31 pm

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!

Chupaka · Wed Feb 26, 2014 4:04 pm

dst-limit=32,32 is what you're looking for. try to change it to dst-limit=32,256 for higher burst

dorijan · Sat Mar 29, 2014 4:39 pm

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...

Chupaka · Wed Apr 02, 2014 5:55 pm

PC routers, different attacks - sometimes upto 200 Mbps is blocked from customers to the internet

juanvi · Tue Jun 24, 2014 3:05 pm

Is this suitable for INPUT chain. Has any sense? I think the router can be the objetive too.

Sunday and Monday were horrible days...

It was the first time our network became the source of DDoS attack. TechSupport woke me up at about 13:00 - users were complaining about very slow Internet access with high packet drop rate. Guess what I did first? Yes, after a few minutes I rebooted the router And guess what? After reboot, the picture stayed the same. Even pinging router's address (or 127.0.0.1) from the router itself was showing 200-500ms RTT with 50% of timeouts.

After about fifteen minutes of searching and trying I identified that the reason was my firewall filter fules for limiting the number of simultaneous TCP connections per user: they were showing high rate of dropped packets, and when I was disabling them, router was becoming stable again.

It appeared that some kind of virus or botnet on customers' computers was attacking single IP address (some Lineage II game server) by creating huge number of HTTP requests to the host (when I blocked any packets to that server, filter rule was dropping about 4000 new connections per second). So, when 'connection-limit' matcher was trying to count active user's connections a few thousand times per second, it was killing the router completely.

In Monday, attacked IP addresses changed, so this horror returned back After a dozen of minutes I came to this solution:
Code: Select all
/ip firewall filter
add chain=forward connection-state=new action=jump jump-target=block-ddos
add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m
It dynamically creates two address lists: attackers ('ddoser') and attacked hosts ('ddosed'), and blocks packets from the former to the latter. Works like a charm =)

Hope this will help somebody to protect his routers from flooding...

Chupaka · Wed Jun 25, 2014 11:43 am

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)

juanvi · Thu Jun 26, 2014 4:53 pm

But your rules are blocking the tcp syn flood attacks to the router too if input chain is objective???

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)

Chupaka · Thu Jun 26, 2014 7:00 pm

kind of. but for router itself I'd rather do much more strict rules. and enable TCP SYN Cookies

dadaniel · Fri Jun 27, 2014 10:54 am

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...

juanvi · Fri Jun 27, 2014 11:17 am

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

Chupaka · Fri Jun 27, 2014 11:45 am

juanvi, do you really need 'connection-limit' in that case? I don't think the limit of 75 connections is actually doing something valuable...

tombee79 · Wed Jul 23, 2014 6:17 am

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

Chupaka · Thu Jul 24, 2014 1:40 pm

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

omidkosari · Thu Jul 24, 2014 2:08 pm

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 ?

Chupaka · Wed Aug 20, 2014 4:12 pm

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:

dst-limit.gif

(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

internetolog · Sun Nov 09, 2014 2:48 pm

These rules leaves too many tcp connections established counting down.
If I use reject instead of drop, does it solve this problem?

SystemErrorMessage · Sun Nov 09, 2014 3:59 pm

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.

otgooneo · Wed Dec 10, 2014 8:10 pm

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

omidkosari · Sat Jan 10, 2015 12:03 pm

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

Chupaka · Sat Jan 10, 2015 12:20 pm

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?

omidkosari · Sat Jan 10, 2015 1:10 pm

Yes i checked it .
When add these new rules , packets don't go to firewall filters and the drop rule does not count anymore . But i want to know which one is better ?

omidkosari · Tue Jan 27, 2015 8:41 am

Have you checked this rules in a BGP router ? I have a scenario which tx goes through ether1 and rx comes from different gre/eoip tunnels .

It seems the router confused and blocks popular websites .

Note: i just want to block ddos TO my customers .

As you can see i have used "connection-state=new in-interface=gre1" and normally websites don't create 8~16 NEW connection to my customers . so i think router could not correctly understand related or established connections and think it is new .

I have also tested dst-limit=8,16,src-and-dst-addresses/10s but no difference

/ip firewall filter
add action=jump chain=forward connection-state=new dst-address-list=customers in-interface=gre1 jump-target=detect-ddos-customers
add action=jump chain=forward connection-state=new dst-address-list=customers in-interface=gre2 jump-target=detect-ddos-customers
add action=jump chain=forward connection-state=new dst-address-list=customers in-interface=eoip1 jump-target=detect-ddos-customers
	
add action=jump chain=detect-ddos-customers connection-state=new dst-address-list=customers jump-target=attack-tcp-src-80 protocol=tcp src-port=80
add action=return chain=attack-tcp-src-80 connection-state=new dst-address-list=customers dst-limit=8,16,dst-address/10s protocol=tcp src-port=80
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m chain=attack-tcp-src-80 connection-state=new dst-address-list=customers protocol=tcp src-port=80
add action=add-src-to-address-list address-list=ddoser address-list-timeout=10m chain=attack-tcp-src-80 connection-state=new dst-address-list=customers protocol=tcp src-port=80

add action=jump chain=detect-ddos-customers connection-state=new dst-address-list=customers jump-target=attack-udp-src-80 protocol=udp src-port=80
add action=return chain=attack-udp-src-80 connection-state=new dst-address-list=customers dst-limit=8,16,src-address/10s protocol=udp src-port=80
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m chain=attack-udp-src-80 connection-state=new dst-address-list=customers protocol=udp src-port=80
add action=add-src-to-address-list address-list=ddoser address-list-timeout=10m chain=attack-udp-src-80 connection-state=new dst-address-list=customers protocol=udp src-port=80

Chupaka · Wed Feb 04, 2015 12:04 pm

sorry for the long delay

I think, routing to blackhole is better just because it drops packets earlier (on routing decision step), without checking filter rules. anyway, you still need filter rules for the first packet, which is detected after 'prerouting', and for dst-natted packets if any

on production routers (v6.7-6.10) we're currently using something like "dst-limit=16,96,src-and-dst-addresses/1m40s" - no complaints from customers so far, and gigabytes of dropped traffic

phendry · Thu Apr 02, 2015 6:38 am

we're currently using something like "dst-limit=16,96,src-and-dst-addresses/1m40s" - no complaints from customers so far, and gigabytes of dropped traffic

Hi Chupaka. This limit seems really low to me. Surely if you had asymmetric routing on your network it would only take 2 VoIP calls from a single customer site to exceed this limit?

Chupaka · Thu Apr 02, 2015 2:41 pm

Hi Chupaka. This limit seems really low to me. Surely if you had asymmetric routing on your network it would only take 2 VoIP calls from a single customer site to exceed this limit?

I put those rules on access routers, so there's no asymmetric routing

and yes, in case of asymmetric routing, if router sees constant UDP stream without replies - it looks suspicious anyway

phendry · Thu Apr 02, 2015 3:12 pm

DDoS prevention is needed at eBGP peering points to stop the flood hitting your infrastructure. Assuming you have multiple BGP peers in physically different locations it is very likely you'll get asymmetric routing. Nothing suspicious about that.

Chupaka · Thu Apr 02, 2015 5:51 pm

okay, that again confirms that one should not blindly copy any configs found in the Internet, as many things depend on the topology

dfariazo · Wed Apr 15, 2015 1:51 am

what you think about this http://wiki.mikrotik.com/wiki/DDoS_Dete ... d_Blocking, they redirect to this post but are different

Sunday and Monday were horrible days...

It was the first time our network became the source of DDoS attack. TechSupport woke me up at about 13:00 - users were complaining about very slow Internet access with high packet drop rate. Guess what I did first? Yes, after a few minutes I rebooted the router And guess what? After reboot, the picture stayed the same. Even pinging router's address (or 127.0.0.1) from the router itself was showing 200-500ms RTT with 50% of timeouts.

After about fifteen minutes of searching and trying I identified that the reason was my firewall filter fules for limiting the number of simultaneous TCP connections per user: they were showing high rate of dropped packets, and when I was disabling them, router was becoming stable again.

It appeared that some kind of virus or botnet on customers' computers was attacking single IP address (some Lineage II game server) by creating huge number of HTTP requests to the host (when I blocked any packets to that server, filter rule was dropping about 4000 new connections per second). So, when 'connection-limit' matcher was trying to count active user's connections a few thousand times per second, it was killing the router completely.

In Monday, attacked IP addresses changed, so this horror returned back After a dozen of minutes I came to this solution:
Code: Select all
/ip firewall filter
add chain=forward connection-state=new action=jump jump-target=block-ddos
add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m
It dynamically creates two address lists: attackers ('ddoser') and attacked hosts ('ddosed'), and blocks packets from the former to the latter. Works like a charm =)

Hope this will help somebody to protect his routers from flooding...

Chupaka · Thu Apr 16, 2015 5:34 pm

what you think about this http://wiki.mikrotik.com/wiki/DDoS_Dete ... d_Blocking, they redirect to this post but are different

as you can see in page history, that was me who created and edited that article

rextended · Thu Apr 30, 2015 11:30 pm

what you think about this http://wiki.mikrotik.com/wiki/DDoS_Dete ... d_Blocking, they redirect to this post but are different
as you can see in page history, that was me who created and edited that article

If you want, add this to your article:

ADD ONE HONEYPOT IP, like what I do with spamhouse with one real mail address, but any mail sended to that address causing the sender's IP to go directly on blacklist...... ;P

Any external IP trying to contact the non-active reapublic IP, go directly to SCANNER address list, and every packet coming from scanner address list are dropped, except the TCP are tarpitted

@SCANNER = address list of potential DDoS or DoS or SCANNER / SPAMMER

1.2.3.4 = One of YOUR REAL SURELY UNUSED IP ADDRESS
ether1 = your INTERNET interface
safe_address_list = IP whitelist containing all your subnet and IP of secure services

/ip firewall filter
add action=add-src-to-address-list address-list=@SCANNER chain=forward comment=HONEYPOT dst-address=1.2.3.4 in-interface=ether1 src-address-list=!safe_address_list
add action=tarpit chain=forward in-interface=ether1 protocol=tcp src-address-list=@SCANNER
add action=drop chain=forward in-interface=ether1 protocol=!tcp src-address-list=@SCANNER

netwpl · Thu Jul 23, 2015 10:13 pm

ive setup this DDos scenario to protect our internet-upstreams.

ive used 2physical interfaces:

eth1 connected to our upstream-provider
eth2 connected to our network-device

bridge1 with eth1 and eth2 so that the traffic can flow transparent through the ccr and the BGP session between our upstream-provider and our network-device gets established.

everything seems to work fine, except 1 customer is complaining about his IPSec tunnel.

- Customer has a site to site vpn tunnel between two checkpoint gateways that are managed by two different management stations.
- VPN is supposed to be certfiicate based but it was failing so customer changed the VPN to Preshared secret and it is working now.
- When converted back to Certificate based VPN, VPN tunnel again failed during Phase 1.
- VPN tunnel is between SIDE1 and SIDE2 sites.
- IKE Phase 1 is initiated by SIDE1 side. <-- from outside our network
- On SIDE1 side in ike.elg file we are able to see IKE Phase 1 first 5 packets and packet 6 is not recieved from SIDE2
- On SIDE2 in ike.elg file we see all 6 packets of Phase 1 and its trying to initiate the Phase 2.
- Using Tcpdump captures our findings are as follows:

could the DDos protection be the cause that the customer cant initialize his IPSec tunnel anymore, or could it be a MTU size problem with the CCR.


 9    ;;; jump-2-forward-queue!
      chain=forward action=jump jump-target=detect-ddos connection-state=new in-interface=DDos-bridge log=no log-prefix="" 

10    ;;; !!!!!! detect ddos aufgrund der Anzahl der connections
      chain=detect-ddos action=return dst-limit=64,128,src-and-dst-addresses/11s log=no log-prefix="" 

11    ;;; not_our-networks-BASIS-add.-LIST
      chain=detect-ddos action=return dst-address-list=!LIST log=no log-prefix="" 

12    chain=detect-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m log=no log-prefix="" 

13    ;;; ddoser_vergangenheit
      chain=detect-ddos action=add-src-to-address-list address-list=ddoser_vergangenheit address-list-timeout=0s log=no log-prefix="" 

14    chain=detect-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m log=no log-prefix="" 

15    ;;; ddosed_vergangenheit
      chain=detect-ddos action=add-dst-to-address-list address-list=ddosed_vergangenheit address-list-timeout=0s log=no log-prefix="" 

16 X  ;;; drop DDOSER und DDOSED hosts - REMINDER ev. TARPIT?
      chain=forward action=drop connection-state=new src-address-list=ddoser dst-address-list=ddosed log=no log-prefix=""

miq · Mon Oct 31, 2016 11:41 pm

@Chupaka, maybe it's good idea to move rule:

/ip firewall filter
add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop

before jump action? When this rule it's on the end all packets going through all anti-ddos chain chains even if ddoser and ddosed are already on proper lists.

Chupaka · Tue Nov 01, 2016 2:21 am

@Chupaka, maybe it's good idea to move rule:
Code: Select all
/ip firewall filter
add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop
before jump action? When this rule it's on the end all packets going through all anti-ddos chain chains even if ddoser and ddosed are already on proper lists.

but in that case 'dst-limit' matcher's tables won't be refreshed by packets from currently active 'ddos flows', so when address list entry timeouts, it will take another 'full detection cycle' to add them back. yes, that's theoretical difference, and I don't know exact practical impact of it, but I was thinking about this case while developing the rule set, and still did what you see in my post

miq · Tue Nov 01, 2016 1:50 pm

but in that case 'dst-limit' matcher's tables won't be refreshed by packets from currently active 'ddos flows', so when address list entry timeouts, it will take another 'full detection cycle' to add them back. yes, that's theoretical difference, and I don't know exact practical impact of it, but I was thinking about this case while developing the rule set, and still did what you see in my post

I'm trying to look closer to this rules, because I have problem with massive dos (shitty IoT) from my clients. And sometimes my CCR1036-8G-2S+ dying, (I write about this in this topic: http://forum.mikrotik.com/viewtopic.php ... 7&p=565972). And I'm think it may be a problem when really lot of connection from network (before queue, so it's really fast) going to you router.

I will try to move this rule at the beginning of antidos chains, and try my theory, because I already haven't idea what is wrong :/.

alexvicol · Thu Nov 03, 2016 10:54 pm

Hi,
I have:

 1   chain=forward action=jump jump-target=detect-ddos connection-state=new log=no log-prefix=""
 2   chain=detect-ddos action=return src-address-list=exceptions log=no log-prefix=""
 3   chain=detect-ddos action=return dst-limit=32,32,src-and-dst-addresses/10s log=no log-prefix=""
 4   chain=detect-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m log=no log-prefix=""
 5   chain=detect-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m log=no log-prefix=""
 6   chain=forward action=drop connection-state=new src-address-list=ddoser dst-address-list=ddosed log=no log-prefix=""

Where exceptions list contains 3 IP's with dns servers , but still those 3 ip's get added in ddosed list and my server ips in the ddoser list.
The counters for that exception rule is 0 this means it doesn't get hit.
What's wrong in these rules?

miq · Fri Nov 04, 2016 11:24 am

Hi,
I have:

 1   chain=forward action=jump jump-target=detect-ddos connection-state=new log=no log-prefix=""
 2   chain=detect-ddos action=return src-address-list=exceptions log=no log-prefix=""
 3   chain=detect-ddos action=return dst-limit=32,32,src-and-dst-addresses/10s log=no log-prefix=""
 4   chain=detect-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m log=no log-prefix=""
 5   chain=detect-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m log=no log-prefix=""
 6   chain=forward action=drop connection-state=new src-address-list=ddoser dst-address-list=ddosed log=no log-prefix=""

Where exceptions list contains 3 IP's with dns servers , but still those 3 ip's get added in ddosed list and my server ips in the ddoser list.
The counters for that exception rule is 0 this means it doesn't get hit.
What's wrong in these rules?

If you trying to connect to DNS servers you should use dst-address-list in rule #2

alexvicol · Fri Nov 04, 2016 11:41 am

Hi,
Already tried that.
Same thing:

1    chain=forward action=jump jump-target=detect-ddos connection-state=new log=no log-prefix=""
2    chain=detect-ddos action=return dst-address-list=exceptions log=no log-prefix=""
3    chain=detect-ddos action=return dst-limit=32,32,src-and-dst-addresses/10s log=no log-prefix=""
4    chain=detect-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m log=no log-prefix=""
5    chain=detect-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m log=no log-prefix=""
6    chain=forward action=drop connection-state=new src-address-list=ddoser dst-address-list=ddosed log=no log-prefix=""

miq · Fri Nov 04, 2016 12:10 pm

Hi,
Already tried that.
Same thing:

1    chain=forward action=jump jump-target=detect-ddos connection-state=new log=no log-prefix=""
2    chain=detect-ddos action=return dst-address-list=exceptions log=no log-prefix=""
3    chain=detect-ddos action=return dst-limit=32,32,src-and-dst-addresses/10s log=no log-prefix=""
4    chain=detect-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m log=no log-prefix=""
5    chain=detect-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m log=no log-prefix=""
6    chain=forward action=drop connection-state=new src-address-list=ddoser dst-address-list=ddosed log=no log-prefix=""

I don't know why this doesn't work. I set exceptions on my router and it works perfect. You should try use torch to check src and dst address, maybe it's different than you expect. And check your firewall rules, maybe this adresses are returned from forward before detect-dos chain.

alexvicol · Fri Nov 04, 2016 1:34 pm

In torch if I run with the Ip of the dns in src. address it displays the traffic.
I have no other firewall rules, just these ones.
How can I check if the adresses are returned from forward before detect-dos chain?

miq · Fri Nov 04, 2016 2:11 pm

In torch if I run with the Ip of the dns in src. address it displays the traffic.
I have no other firewall rules, just these ones.
How can I check if the adresses are returned from forward before detect-dos chain?

It's good idea to add log action in desired place.

SKYNET360 · Wed Nov 30, 2016 7:16 pm

Chupaka

Can you post the correct edited config that I lost you guys.

Thanks

Chupaka · Thu Dec 01, 2016 3:29 pm

the correct edited config that I lost you guys.

correct? what's incorrect in posts above?..

SKYNET360 · Thu Dec 01, 2016 7:11 pm

I want to build a super powerful router that can handle 30GIG of ddos attack using firewall rules without any problems what do you guys recommend

SKYNET360 · Thu Dec 01, 2016 7:12 pm

the correct edited config that I lost you guys.
correct? what's incorrect in posts above?..

I found it thanks

SKYNET360 · Fri Dec 02, 2016 9:30 pm

Need a little help with this rule

/ip firewall filter
add action=return chain=detect-ddos comment=DOS-Exceptions disabled=no \
src-address-list=DOS-Exceptions

I have this rule as 2nd

with DOS-Exceptions
8.8.8.8 and outer known IPs that I need to make sure they don't get hit with ddos rule.

SKYNET360 · Fri Dec 02, 2016 9:31 pm

Need a little help with this rule

/ip firewall filter
add action=return chain=detect-ddos comment=DOS-Exceptions disabled=no \
src-address-list=DOS-Exceptions

I have this rule as 2nd

with DOS-Exceptions
8.8.8.8 and outer known IPs that I need to make sure they don't get hit with ddos rule.

IP 8.8.8.8 still gets hit as ddosed

Murmaider · Sat Dec 03, 2016 6:40 am

I want to build a super powerful router that can handle 30GIG of ddos attack using firewall rules without any problems what do you guys recommend

You won't stop a 30Gb/sec DDoS with firewall rules. Firewalls are a access control technology designed to secure unauthorized entry or to limit / restrict the flow of traffic.

Firewall rules themselves are actually very inefficient in any large DDoS attack. A large attack you will easily exhaust your connection state table in a few seconds and you will start dropping packets. Firewall rules also have a massive impact on packets-per-second through a router as every single packet has to be inspected.

In order for the firewall to inspect traffic (and traffic based on state), it needs to accept the traffic on the routers incoming interface in order to make a decission (drop, forward, etc). Even if you have a drop rule, the traffic is still "accepted" on the interface, inspected and then dropped.

While this prevents the DDoS traffic from leaving your router on the outgoing interface, your router still has to do the job of accepting the traffic and inspecting it against the hierarchy of firewall rules.

You better off using RP Filter (loose) and Source-based blackholes for DDoS filtering. This is by far more efficient and can actually reduce the incoming traffic on the routers interface, as well as the CPU usage on the router during the attack.

I did a post on this here - http://forum.mikrotik.com/viewtopic.php?t=114664
In the youtube video you can see what I am referring to above with the traffic still hitting the incoming interface when the firewall drop rule is used. You will see how the traffic drops off when I use the source-based blackhole and how the CPU usage goes down to 0%.

If you want to automate this DDoS protection then look at Wanguard to detect ddos traffic and push the source-based blackholes via BGP to your mikrotik (which must have RP Filter set to Loose), or use it to trigger an GRE tunnel to a DDoS cloud provider.

zipvault · Sat Dec 24, 2016 8:38 pm

.

chupaka i just saw youtube video of you hitting 600mb on a speed test on mikrotik

nice

how can i do this

Chupaka · Mon Dec 26, 2016 2:19 am

youtube video of me?.. where?

zipvault · Thu Dec 29, 2016 12:05 pm

Has anyone seen cloudflare

They specialise in ddos protect

Looks like i good service they boast stopping 600gbps attack

How can i build something like this for myself at that scale with mikrotik

Thu Dec 29, 2016 12:07 pm

This is like saying "I saw youtube.com and it looks interesting. How can I build a webpage like that at home"

zipvault · Thu Dec 29, 2016 12:26 pm

Your funny normis you make me laugh i understand you believe it is a grandeur task, but anything is possible

_______
Dos approach forum = " i was just reading into layer 3 layer 4 and layer 7 ddos

Cloud based seems the best current option as it can implement multiple processing paths

Looking at options and how it works so i can build my understanding.

I see fortinet have a promising ddos hardware box

I wonder what it takes and what is involved maybe its possible for us to make one for mikrotik"

Jeanluck · Thu Mar 09, 2017 7:51 pm

Hi,
I check that:
add chain=SYN-Protect connection-state=new limit=400,5 protocol=tcp tcp-flags= syn

with a single user with less than 200 total connetions, skip this rule, and the netxt drop rule, drop several connections.
I check the point is "burst" parameter, 5 is too low, but in all examples I see, is set to 5.

So, I don't undertand. What do exactly the burst parameter in this rule? and, which must be the value for a correct work?
at least "burst = limit connection"?

Thanks!

R1CH · Thu Mar 09, 2017 11:52 pm

Your funny normis you make me laugh i understand you believe it is a grandeur task, but anything is possible

_______
Dos approach forum = " i was just reading into layer 3 layer 4 and layer 7 ddos

Cloud based seems the best current option as it can implement multiple processing paths

Looking at options and how it works so i can build my understanding.

I see fortinet have a promising ddos hardware box

I wonder what it takes and what is involved maybe its possible for us to make one for mikrotik"

The only way to beat a DDoS is to have more bandwidth than the attacker.

Jeanluck · Fri Mar 10, 2017 10:12 am

It's not right... Sometimes the atacker use a bit only, but cause a 100% CPU

Please someone can explain me, what make exactly the burst parameter. I think that 400,5 is not right.

Chupaka · Fri Mar 10, 2017 12:33 pm

add chain=SYN-Protect connection-state=new limit=400,5 protocol=tcp tcp-flags= syn

I don't like that there are both 'connection-state' and 'tcp-flags=syn'. Why not just use one of them?

Please someone can explain me, what make exactly the burst parameter. I think that 400,5 is not right.

it means 'first 5 packets are not checked by 'limit' parameter, then allow 400 packets per second'

Jeanluck · Fri Mar 10, 2017 1:52 pm

Thanks!

But, I check that 100,1 cause a lot of packets drop in the next drop rule, but 80,20 has no packet loss.
Then, if just "burst" packets are not checked, why 100,1 drop a lot, and 80,20 none? may be the same or similar

Chupaka · Fri Mar 10, 2017 2:44 pm

But, I check that 100,1 cause a lot of packets drop in the next drop rule, but 80,20 has no packet loss.
Then, if just "burst" packets are not checked, why 100,1 drop a lot, and 80,20 none? may be the same or similar

the reason is the way how the allowed rate is calculated

you can imagine it as a counter: "N allowed packets left"

when first packet arrives, the counter is initialized by 'burst' value. the packet is accepted, counter is decremented by 1. then each 'Time' (1 second by default) the counter is set to Rate, and each packet decrements it by 1. packet is accepted if counter is greater than or equal to zero

in case of '100,1' the problem is within the first second: first packet arrives, counter=1, packet is accepted, counter=0 - and for the rest of this second no more packets will be accepted. in 1s counter will become 100, and 100 more packets will be accepted

that's why I prefer to set burst=rate+some_starting_value, not just some_starting_value

Jeanluck · Sat Mar 11, 2017 3:09 pm

In "limit" wiki mikrotik is:
"burst - initial number of packets or bits to match: this number gets recharged every 10ms so burst should be at least 1/100 of rate per second "
(every 10ms, not every 1seg, so I don't understand well)

Can be then?
- Burst = packet limit every 10ms
- Rate = packet limit every 1000ms (== 1 seg.). In this point, I think that total rate is packets in 1 seg, minus burst number in every 10ms period

For example, this rates fro 20,5
[10ms - 4 packets] - pass all -> rate=0+4=4
[10ms - 8 packets] - pass 5, and burst drop 3 -> rate=rate+5=9
[10ms - 5 packets] - pass all -> rate = rate + 5 =14
[10ms - 15 packets] - pass 5 and burst drop 10 -> rate = rate+5=19
[10ms - 4 packets] - pass one packet, because rate has reached the 20 limit, and drop all packets until the next second start

works in this way?

My rule would be:
"add action=return chain=DDOS_TCP_SYN comment="DDOS Connection Limit TCP SYNs" connection-state=new limit=20,5 protocol=tcp tcp-flags=syn

Chupaka · Sun Mar 12, 2017 11:14 pm

Yep, looks like it can be the truth. I thought 'limit' should work like 'dst-limit'

But it appeared they have a bit different descriptions...

aarango · Wed Mar 22, 2017 9:20 am

Hi,

I added your lines on first post Chupaka and I see packets / bytes on jump and return on my firewall, but I want to know how could I see what packets are, what IP its and where could I see if that traffic is DDoS or simply traffic. Basic how I could monit that traffic to avoid DDoS attacks.

6 chain=forward action=jump jump-target=block-ddos connection-state=new
7 chain=forward action=drop connection-state=new src-address-list=ddoser dst-address-list=ddosed
8 chain=block-ddos action=return dst-limit=50,50,src-and-dst-addresses/10s log=no
9 chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
10 chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m

Note: I checked that its working, I see IP on "Address list", now I have another question. Are there way to add any whitelist? In "Address list" I have good IPs banned and I want or adjust values burst and rate (50, 50 now) or whitelist some IPs.
Now I changed burst and rate to 100, is it much?

Thanks.

Chupaka · Wed Mar 22, 2017 1:49 pm

Are there way to add any whitelist?

just add one more 'return' rule next to the current 'return' rule:

add chain=block-ddos src-address-list=whitelisted-from-ddos-checker action=return

and then use this address-list for whitelisting

aarango · Wed Mar 22, 2017 2:21 pm

Are there way to add any whitelist?
just add one more 'return' rule next to the current 'return' rule:
Code: Select all
add chain=block-ddos src-address-list=whitelisted-from-ddos-checker action=return
and then use this address-list for whitelisting

Thanks you, a stupid question. I normally use MK from interface web, how could I change the rule's order? I have some rules in middle (spamhaus rules) and I would like to keep ddos rules together.

Chupaka · Wed Mar 22, 2017 3:09 pm

I normally use MK from interface web, how could I change the rule's order?

just drag'n'drop the rule by your mouse

aarango · Thu Mar 23, 2017 8:13 am

I normally use MK from interface web, how could I change the rule's order?
just drag'n'drop the rule by your mouse

I feel stupid now! I tried a lot of things less that...

nichky · Fri Mar 24, 2017 10:28 am

From MikroTik wiki about your post.
i have no idea what's the mining of this part configuration

add chain=detect-ddos src-address=192.168.0.1 action=return

https://wiki.mikrotik.com/wiki/DDoS_Det ... d_Blocking

it's local address?

excellent rules, well done

Chupaka · Fri Mar 24, 2017 11:20 am

i have no idea what's the mining of this part configuration

add chain=detect-ddos src-address=192.168.0.1 action=return

It's about "One may want also add some exceptions (like DNS servers - it won't be good if they will be blocked)" - that's the server which needs unlimited access

nichky · Fri Mar 24, 2017 12:52 pm

got idea. Let us know more about your rules

Thanks

magnitude · Fri Apr 21, 2017 8:26 pm

protocol is tcp source ip :115.238.184.5, source port 50006
when that happen i have traffic allmost on all public ip in subnet /23 around 360kbps per ip
and upload on my network is 90-150Mbps.

How did u solve this problem,,,i am also facing similar problem,,,my all public ip in subnet is affected by unknown traffic.

nichky · Sun Sep 17, 2017 2:58 am

how you recommending to set up this rule,on the top or will be okay if i will apply at the end of the firewall list?

Thanks a lot

Chupaka · Mon Sep 18, 2017 10:06 am

I'd say, it depends on your current rules

but in general it's better to place them on the top: they are designed to block abnormal traffic and to pass the rest to the bottom rules, not to accept it

Rahl · Sun Nov 03, 2019 4:22 am

I own a few things from Mikrotik.
One is a CCR1009-8G-1S-1S+ router.
I have tried ti get thease rules to work with it but the return only returns back to the begining and afterthat there is no saving to address list of ddos attacks or other common attacks.
Is it the script that is to obselet or is it something i am missing.
I have added it in mangle without sucess and even in filter still without success.
I would be glade if some one could help me along the way because i have 2 web servers inside the my lan that works great but is geting picked on.
I hope some one has an answer for this.

Many Thanks Roberth (Sweden)

Chupaka · Mon Nov 04, 2019 11:02 pm

So, what exactly is not working for you? What do you expect and what actually happens?

Rahl · Sun Nov 10, 2019 4:40 am

I want it to stop attckers against port 80 and 443 when they are enough of the requests . Like 4 per IP or some thing like that ??

sindy · Sun Nov 10, 2019 1:57 pm

First, what is the context?

Do you want to restrict the number of newly established connections (or just connection attempts) coming from clients in your internal network towards any http/https servers in the internet over a short period of time, or do you want to protect one or just a few servers in your internal network from (D)DoS attacks coming from the internet?

The firewall rules will be almost the same in both cases, but the result may not be as good as you expect in the latter case, because even if you drop the incoming SYN packets on the router, its uplink will still get clogged with them. So the load to the protected server itself will be low, but if the DDoS bandwidth exceeds the available bandwidth on the uplink, the service will be limited for everyone anyway as many (maybe most) connection attempts will never make it to your network.

Rahl · Sun Nov 10, 2019 2:23 pm

@Sindy
The context is my two diffrent Project i have behind a nat firewall.
What i want is some how to stop to many Connections calls on port 80 and 443 within a specific time.
If im correct its only new package that is in this line or am i wrong ??
I would really like to learn both setttings to be able to test it for my self..
As of today i am not ddos affected but there are alot of attemps to hack the web servers.

I hope that makes it more clearer.

// Roberth

caspat · Sun Nov 10, 2019 3:05 pm

Hi, i have read in the changelog that the dst-limit bug have been fixed in version 6.32, can someone put this info on the wiki page and maybe change the example.
thanks!

sindy · Sun Nov 10, 2019 3:40 pm

I hope that makes it more clearer.

Partially, as my warning remains valid - if the bottleneck is the uplink bandwith and not the computing power of the server, no degree of magic on the firewall between the uplink and the server can prevent the service from becoming inaccessible for well-behaving users if most of the bandwidth capacity gets exhausted by connection attempts from rogue "users".

As of today i am not ddos affected but there are alot of attemps to hack the web servers.

So you want to limit the amount of brute-force password guessing attempts by rate-limiting them. OK, just bear in mind that passwords with a good entrophy (randomness) are a better protection against this particular type of attack, and that rate limiting provides no protection against attacks deploying some stack vulnerabilities (where just one or two connections are enough to get in).

What i want is some how to stop to many Connections calls on port 80 and 443 within a specific time.
If im correct its only new package that is in this line or am i wrong ??

Seems there will be a bit of a language barrier here

By connection call, you mean an attempt to establish a new connection, correct? So want you limit how many new connections a particular client*) remote IP address may establish per unit of time, not how many connections in total a client can have ongoing at the same time.

If so, then yes, the dst-limit match condition is what you need, with the mode value set to one of (addresses-and-dst-port | src-address | src-and-dst-addresses) according to the granularity you will provide manually (i.e. if you use a dedicated rule like this for each destination address and port, setting mode to src-address will be sufficient).

This match condition is actually an entry point to a process which maintains an associative array of counters and timers indexed by the parameters, so you may get some surprises on a device with a limited amount of RAM.

And yes, you need to let only packets attributed with connection-state=new be handled by rules with the dst-limit match condition, as otherwise you would rate-limit (or break) the individual connections themselves, not the new connection attempts. But if you build on the firewall rules from the default configuration, this happens automatically, because in the default firewall configuration, the first few rules in each filter chain deal with all the other connection-state values, and whatever gets past those first few rules is attributed with connection-state=new so there is no need to repeat this match condition in every rule.

*) I believe you do realize that connections attempts from many individual human users may come from the same public IP if their PCs are in a private network NATed behind that public IP. So for a serious public service, especially visited by mobile users, a limitation of connection attempt rate would be too restrictive.

Chupaka · Mon Nov 11, 2019 8:50 am

Hi, i have read in the changelog that the dst-limit bug have been fixed in version 6.32, can someone put this info on the wiki page and maybe change the example.
thanks!

Hi. Are you sure it's the same bug? IIRC, I checked this about a year ago — it was still here...

rodolfo · Mon Nov 11, 2019 10:34 am

Ok, this post is ultra-old but the argument is always hot.
I have a question.
Your initial code of this post, coud be written as follows?
(to avoid the use of connection tracking)

/ip firewall raw
add chain=prerouting  action=jump  jump-target=block-ddos protocol=tcp tcp-flags=syn
add chain=prerouting src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m

The true question is: in TCP, a filter over syn flag, coud replace the filter connection=new?

Thanks

caspat · Mon Nov 11, 2019 1:02 pm

Hi, i have read in the changelog that the dst-limit bug have been fixed in version 6.32, can someone put this info on the wiki page and maybe change the example.
thanks!
Hi. Are you sure it's the same bug? IIRC, I checked this about a year ago — it was still here...

I'm not sure, i just read it in changelog...

What's new in 6.32.1 (2015-Sep-07 13:03):

*) RB911/912 - fixed lock-up;
*) RB493G - fixed reboot loop;
*) firewall - do not lose firewall mangle rules on start-up;
*) defconf - fix default configuration for routers without wireless package.

What's new in 6.32 (2015-Aug-31 14:47):

*) trafflow - added support for IPv6 targets;
*) switch - fixed port flapping on switch ports of RB750, RB750UP, RB751U-2HnD and RB951-2N (introduced in 6.31)
*) ipsec - added compatibility option skip-peer-id-check;
*) flash - fix kernel failure (exposed by 6.31);
*) bridge firewall - add ipv6 src/dst addr, ip protocol, src/dst port matching to bridge firewall;
*) RB911/RB912 - fix SPI bus lock after fast led blink;
*) ipsec - fix potential memory leak;
*) bridge firewall - vlan matchers support service tag - 0x88a8;
*) ippool6 - try to acquire the same prefix if info matches recently freed;
*) crs switch - allow to unset port learn-limit, new default is unset to allow more than 1023 hosts per port;
*) x86 - fixed 32bit multi-cpu kernel support;
*) chr - add hotspot,btest,traffgen support;
*) revised change that caused reboot by watchdog problems introduced in v6.31;
*) ipsec - use local-address for phase 1 matching and initiation;
*) ipsec - fix transport mode ph2 ID ports when policy selects specific ip protocol on initiator;
*) certificates -fixed bug where crl stopped working after a while;
*) ip accounting - fixed kernel crash;
*) snmp - fix system scripts get;
*) hotspot - ignore PoD remote requests if no HotSpot configured;
*) hotspot - fix kernel failure when www plugin aborts on broken html source;
*) torch - add invert filter for src/dst/src6/dst6 addresses ;
*) bonding - add min_links property for 802.3ad mode;
*) snmp - get vlan speed from master interface;
*) hotspot - fix html-directory path on small flash devices;
*) mipsbe - make system shutdown work again;
*) lcd - fixed parallel port LCD display support on multi-cpu x86;
*) bridge - fixed use-ip-firewall-for-vlan in setups with multiple bridges;
*) ipv6 - fixed DHCP-PD client skips some steps when renewing lease;
*) upnp - fixed protocol port selection for upnp protocol comunications;

*) firewall - fixed limit and dst-limit options.

*) winbox - fixed wireless interface l2mtu (VirtualAP and WDS interface creation in winbox)
*) winbox - fixed multiple firewall rule moving in Winbox 2
*) simple queues - restrict all changes in dynamic simple queues

Chupaka · Tue Nov 12, 2019 12:38 pm

The true question is: in TCP, a filter over syn flag, coud replace the filter connection=new?

Generally - yes, I believe. It works only for TCP, and only for full connection cycle (i.e. invalid data frames without SYN packets should be dropped somewhere else), but for simple case it works the same way.

mistyrhythm · Thu Jul 23, 2020 7:36 pm

Ok, this post is ultra-old but the argument is always hot.
I have a question.
Your initial code of this post, coud be written as follows?
(to avoid the use of connection tracking)
Code: Select all
/ip firewall raw
add chain=prerouting  action=jump  jump-target=block-ddos protocol=tcp tcp-flags=syn
add chain=prerouting src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m
The true question is: in TCP, a filter over syn flag, coud replace the filter connection=new?

Thanks

Any body send latest ddos protection filter rule.

Chupaka · Fri Jul 24, 2020 1:30 pm

What do you call "latest"?

fbslim · Sun Jul 26, 2020 1:46 pm

Hope this will help somebody to protect his routers from flooding...

Спасибо тебе снова, хороший человек!

mistyrhythm · Mon Jul 27, 2020 8:35 pm

What do you call "latest"?

Thanks for your reply @Chupaka. I am new in MikroTik. I want to know this filter rule is OK ?
Advanced thanks.
/ip firewall raw
add chain=prerouting action=jump jump-target=block-ddos protocol=tcp tcp-flags=syn
add chain=prerouting src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m

Chupaka · Thu Jul 30, 2020 9:00 am

Again, you may start with those rules and see if it fits your needs. Watch your 'ddoser' and 'ddosed' lists and recheck that info manually - probably you'll need to adjust some thresholds. Probably not

Nadir16 · Sun Aug 09, 2020 7:48 pm

hello, I have a problem with dns, I installed this protection, after an enable dns stops working
After disable protection, DNS works again, we created rules to accept port 53 but still the same problem
https://i.postimg.cc/x1cyyhwy/dns.png
currently I have 2 connections with 2 providers, I have created rules but I can't apply them to those providers
https://i.postimg.cc/76mfRY7C/dn2.png

how can i solve this problem?

Chupaka · Wed Aug 12, 2020 7:45 pm

Your screenshots are useless, please check what address list contains DNS addresses and then show your firewall rules in "/ip firewall filter export" form.

Nadir16 · Sat Sep 05, 2020 1:51 pm

Your screenshots are useless, please check what address list contains DNS addresses and then show your firewall rules in "/ip firewall filter export" form.

hello, these are all the rules I have, I put this protection on the whole ip class 185.248.139.0/24, how can i solve with dns area?

[admin@BGP] > /ip firewall filter export
# sep/05/2020 13:47:42 by RouterOS 6.44.5
# software id = 8AKB-GBYV
#
# model = CCR1009-7G-1C-1S+
# serial number = 914F0BFD51BB
/ip firewall filter

add action=accept chain=input connection-state=established,new dst-port=53 protocol=udp
add action=accept chain=input connection-state=established,new dst-port=53 protocol=tcp
add action=return chain=detect-ddos comment="Protectie 2" disabled=yes protocol=udp src-address=185.248.139.0/24
add action=jump chain=forward connection-state=established,new disabled=yes jump-target=detect-ddos protocol=udp
add action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m chain=detect-ddos disabled=yes protocol=\
    udp
add action=drop chain=forward connection-state=established,new disabled=yes dst-address-list=ddosed protocol=udp \
    src-address-list=ddoser
add action=return chain=detect-ddos connection-limit=100,32 disabled=yes dst-limit=10,10,src-and-dst-addresses/10s \
    protocol=udp time=0s-1d,sun,mon,tue,wed,thu,fri,sat
add action=add-src-to-address-list address-list=ddoser address-list-timeout=1d chain=detect-ddos disabled=yes protocol=\
    udp

Chupaka · Mon Sep 07, 2020 5:39 pm

please check what address list contains DNS addresses

Nadir16 · Tue Sep 08, 2020 11:23 am

please check what address list contains DNS addresses

Hello sir, most ip addresses contain dns, exemple 185.248.139.20 it has dns, how can i fix the problem so that it doesn't block the dns connection anymore?

sindy · Tue Sep 08, 2020 11:40 am

The question was which IP address list contains the address of a DNS server used by the Mikrotik itself and thus blocks the responses of this DNS server as they come "too often". It seems to me that your answer states which IP addresses have got some fqdn which can be resolved to them, which is not relevant.

Nadir16 · Tue Sep 08, 2020 12:22 pm

The question was which IP address list contains the address of a DNS server used by the Mikrotik itself and thus blocks the responses of this DNS server as they come "too often". It seems to me that your answer states which IP addresses have got some fqdn which can be resolved to them, which is not relevant.

hello sir, mikrotik does not use any ip to use dns, I do not use the mikrotik router as a dns server, related to mikrotik and other switches I have a dedicated server that I installed cpanel and I use it as web hosting, on the router I set an ip from another ip class (5.183.170.x), when I turn on this protection no dns works anymore, if i access ip it is functional but the dns area is not functional, regardless of whether I install a dedicated server and install cpanel for dns is the same problem

zentavr · Tue Dec 08, 2020 1:42 am

If someone has a BGP session with the peer - you can try to set up BGP blackholes and ban the IPs at the upstreams.
I wrote a helper to do that: viewtopic.php?f=9&p=833482#p833482

Martin4 · Wed Dec 09, 2020 1:47 am

Hi Chupaka, thanks for the solution.
Question...
Where can i put your rules about ddos?
At top?
At bottom?
I've 54 rules now:
- first accept input rules
- then drop input
- forward rules of accept ipsec, port dstnatted, queue etc...
- fasttrack/accept/drop rules
- forward drop rules

Thanks so much!

Chupaka · Thu Dec 10, 2020 12:03 pm

At top is good. It works for "connection-state=new", so doesn't add much load for CPU during normal work. And it passes all "good" packets for further processing by other rules.

Martin4 · Thu Dec 10, 2020 1:49 pm

OK, Thank you so much!!

One question, could is mayor efficient to put the drop rule in the RAW firewall section?
Obviously only this line:

add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop

Chupaka · Thu Dec 10, 2020 4:24 pm

There's no connection-state=new in RAW, so I'm not sure what is more efficient: checking each and every packet by two address lists or involving Connection Tracking in 'forward' chain to detect connection state...

More testing is needed :)

iukatech · Wed Jan 13, 2021 7:07 pm

01/13/2021 Still works like a charm on the newer firm as we just went through the same issue

Sunday and Monday were horrible days...

It was the first time our network became the source of DDoS attack. TechSupport woke me up at about 13:00 - users were complaining about very slow Internet access with high packet drop rate. Guess what I did first? Yes, after a few minutes I rebooted the router :) And guess what? After reboot, the picture stayed the same. Even pinging router's address (or 127.0.0.1) from the router itself was showing 200-500ms RTT with 50% of timeouts.

After about fifteen minutes of searching and trying I identified that the reason was my firewall filter fules for limiting the number of simultaneous TCP connections per user: they were showing high rate of dropped packets, and when I was disabling them, router was becoming stable again.

It appeared that some kind of virus or botnet on customers' computers was attacking single IP address (some Lineage II game server) by creating huge number of HTTP requests to the host (when I blocked any packets to that server, filter rule was dropping about 4000 new connections per second). So, when 'connection-limit' matcher was trying to count active user's connections a few thousand times per second, it was killing the router completely.

In Monday, attacked IP addresses changed, so this horror returned back :) After a dozen of minutes I came to this solution:
Code: Select all
/ip firewall filter
add chain=forward connection-state=new action=jump jump-target=block-ddos
add chain=forward connection-state=new src-address-list=ddoser dst-address-list=ddosed action=drop
add chain=block-ddos dst-limit=50,50,src-and-dst-addresses/10s action=return
add chain=block-ddos action=add-dst-to-address-list address-list=ddosed address-list-timeout=10m
add chain=block-ddos action=add-src-to-address-list address-list=ddoser address-list-timeout=10m
It dynamically creates two address lists: attackers ('ddoser') and attacked hosts ('ddosed'), and blocks packets from the former to the latter. Works like a charm =)

Hope this will help somebody to protect his routers from flooding...

erlinden · Thu Jan 21, 2021 2:17 pm

01/13/2021 Still works like a charm on the newer firm as we just went through the same issue

Do these rules have to be at the top of the firewall?

Chupaka · Thu Jan 21, 2021 2:34 pm

Yep, they are designed to pass good traffic for further processing by firewall

erlinden · Thu Jan 21, 2021 2:43 pm

Yep, they are designed to pass good traffic for further processing by firewall

Thank you very much Chupaka, all I had to do is add the internal DNS server to the list that iukatech quoted. It is now working!

DarkNate · Fri Apr 23, 2021 11:52 am

You can improve by moving the drop rule from filter table to raw table in the pre-routing chain, which will significantly save CPU cycles and bandwidth.

Was testing it out on my 75Mbps FTTH connection as the target with source DoS as a 1Gbps dedicated cloud VM and guess what? With RAW dropping it right on the edge, bandwidth consumption never crosses an average of 8Mbps Rx and CPU usage stayed below 5%. Hardware: RB450Gx4. RAW drops are prowerful.

Jotne · Thu Apr 29, 2021 7:04 pm

I do have a problem with this filter. Often my syslog sending servers gets blocked by the filter rules.
To fix this I Split the rules in two.
1. Jump all TCP
2. Jump all UDP except Syslog port

Chupaka · Sat May 01, 2021 1:43 am

Or you may to add "return" rule for your syslog port or syslog server

DarkNate · Wed May 05, 2021 3:05 pm

@Chupaka

Is there a way to drop UDP flooding source IPs in the RAW table on MikroTik without breaking legitimate UDP traffic?

The scenario is this:
10,000 attackers, each sending approx 512Kbps of random UDP flood like DNS amplification to the router's NIC/Public IP addresses.
Since each source IP is sending ultra-low bandwidth, our rules will also end up marking legitimate low bandwidth traffic that's UDP from the outside.

Basically I tried this:

/ip firewall filter
###Send new state from input chain to jump###
add action=jump chain=input comment="Jump to DDoS detection" connection-state=new in-interface-list=WAN jump-target=detect-ddos

###Now we detect any connections exceeding these limits by src IPs###
add action=return chain=detect-ddos dst-limit=32,32,src-addresses/10s
add action=return chain=detect-ddos dst-limit=32,32,src-addresses/10s protocol=tcp tcp-flags=syn,ack

###Now we add src attackers to address list###
add action=add-src-to-address-list address-list=ddos-attackers address-list-timeout=10m chain=detect-ddos

###Drop attacker in RAW table to keep CPU usage small###
/ip firewall raw
add action=drop chain=prerouting src-address-list=ddos-attackers

End Result: I was able to drop 10,000 source IPs while CPU usage is kept below 15-20% on RB450Gx4. However, the problem is now even legitimate new state UDP connections are dropped as well like for instance me connecting to my internal WireGuard server from random src IPs.

Chupaka · Sat May 15, 2021 7:08 pm

Sorry for late response...

Well, if you're securing the router itself, not clients behind the router - shouldn't you just drop everything except what you need? Like, allow WireGuard (and probably ping?) and simply drop everything else.

DarkNate · Sun May 16, 2021 2:45 pm

shouldn't you just drop everything except what you need? Like, allow WireGuard (and probably ping?) and simply drop everything else.

That's exactly what I'm trying to do, which works fine with filter input, but I'm trying to find a way to add src attackers to address lists and drop them in RAW table prerouting. For whatever reason, it ends up dropping already established connections or even new ones like WireGuard.

Chupaka · Sun May 16, 2021 3:33 pm

There can be some changes in UDP Connection tracking in v7, but I can't check it in near future...

Jotne · Mon May 17, 2021 8:45 am

Should not these rules contain Wan as in interface?
I did get my internal PC blocked due to wrongly logged as d-dos

Chupaka · Mon May 17, 2021 3:43 pm

Well, those rules work in any direction: for me, they were protecting remote (Internet) resources from internal users with viruses :) Just like you described :D

Jotne · Mon May 17, 2021 5:23 pm

But I have for sure not done anything remotely connected to DDoS, mostly surfing :)

DarkNate · Wed May 26, 2021 2:29 pm

There can be some changes in UDP Connection tracking in v7, but I can't check it in near future...

This is on RouterOS v6 stable.

Bergante · Wed May 26, 2021 4:09 pm

Some suggestions:

First, make sure your recursive DNS servers or NTP, for instance, don't answer queries from unauthorized sources.

If some infected customer of yours is being one of the attacking sources, I mean, either sending TCP SYN packets or queries to a DNS or NTP amplifier, you can avoid IP address spoofing with a simple configuration.

Something like:

/ip route
add distance=1 dst-address=10.0.0.0/8 type=blackhole
add distance=1 dst-address=169.254.0.0/16 type=blackhole
add distance=1 dst-address=172.16.0.0/12 type=blackhole
add distance=1 dst-address=192.168.0.0/16 type=blackhole

Of course private IP addresses will still work as long as you use smaller chunks of the address space. I mean, I use 192.168.1.0/24 inside. No problem. And these rules will also reject packets from an outside miscreant spoofing any of your internal addresses.

/ip settings
set rp-filter=strict send-redirects=no

This configuration is, unless Mikrotik says the opposite, very cheap. I will not consume firewall resources. If one of your internal users sends a packet with a spoofed source address it will just be dropped.

verdolaga123 · Sat Oct 30, 2021 2:14 pm

Hi to all.
I having some connections established and i want to drop that, but i need my clients can use the ovpn connection.
I know established dont means accepted, but i dont like to see connections from outside which are not expected
Anyone know if this rules helps to me or maybe anyone know a better one for this case.
Thanks for sharing.

07:20:18 ovpn,info TCP connection established from 81.171.9.209 
07:21:29 ovpn,info TCP connection established from 81.171.9.209 
07:22:40 ovpn,info TCP connection established from 81.171.9.209 
07:23:51 ovpn,info TCP connection established from 81.171.9.209 
07:25:02 ovpn,info TCP connection established from 81.171.9.209 
07:26:13 ovpn,info TCP connection established from 81.171.9.209 
07:27:24 ovpn,info TCP connection established from 81.171.9.209 
07:28:35 ovpn,info TCP connection established from 81.171.9.209 
07:29:46 ovpn,info TCP connection established from 81.171.9.209 
07:30:57 ovpn,info TCP connection established from 81.171.9.209 
07:32:08 ovpn,info TCP connection established from 81.171.9.209 
07:33:19 ovpn,info TCP connection established from 81.171.9.209 
07:34:30 ovpn,info TCP connection established from 81.171.9.209 
07:35:41 ovpn,info TCP connection established from 81.171.9.209 
07:36:52 ovpn,info TCP connection established from 81.171.9.209 
07:38:03 ovpn,info TCP connection established from 81.171.9.209 
07:39:14 ovpn,info TCP connection established from 81.171.9.209 
07:40:25 ovpn,info TCP connection established from 81.171.9.209 
07:41:36 ovpn,info TCP connection established from 81.171.9.209 
07:42:47 ovpn,info TCP connection established from 81.171.9.209 
07:43:58 ovpn,info TCP connection established from 81.171.9.209 
07:45:09 ovpn,info TCP connection established from 81.171.9.209 
07:46:20 ovpn,info TCP connection established from 81.171.9.209 
07:47:31 ovpn,info TCP connection established from 81.171.9.209 
07:48:42 ovpn,info TCP connection established from 81.171.9.209 
07:49:53 ovpn,info TCP connection established from 81.171.9.209 
07:51:04 ovpn,info TCP connection established from 81.171.9.209 
07:52:15 ovpn,info TCP connection established from 81.171.9.209 
07:53:26 ovpn,info TCP connection established from 81.171.9.209 
07:54:37 ovpn,info TCP connection established from 81.171.9.209 
07:55:48 ovpn,info TCP connection established from 81.171.9.209 
07:56:59 ovpn,info TCP connection established from 81.171.9.209 
07:58:10 ovpn,info TCP connection established from 81.171.9.209 
07:59:21 ovpn,info TCP connection established from 81.171.9.209 
08:00:32 ovpn,info TCP connection established from 81.171.9.209 
08:01:43 ovpn,info TCP connection established from 81.171.9.209 
08:02:54 ovpn,info TCP connection established from 81.171.9.209 
08:04:05 ovpn,info TCP connection established from 81.171.9.209 
08:05:17 ovpn,info TCP connection established from 81.171.9.209 
08:06:27 ovpn,info TCP connection established from 81.171.9.209 
08:07:39 ovpn,info TCP connection established from 81.171.9.209 
08:08:50 ovpn,info TCP connection established from 81.171.9.209 
08:10:01 ovpn,info TCP connection established from 81.171.9.209 
08:11:12 ovpn,info TCP connection established from 81.171.9.209

sindy · Mon Nov 01, 2021 11:03 pm

You can use connection-limit for SYN packets towards the OVPN listening port to ban source addresses of these brute force attempts, assuming that legal clients will authenticate properly so they won't need to establish the TCP session more than once to successfully connect.

But this only works against brute force password guessing. If an illegal client knows the password, has the certificate, or knows a vulnerability of the OpenVPN stack of RouterOS allowing it to bypass authentication, it will connect successfully at first attempt. Vice versa, if a legal client keeps connecting automatically (like a Mikrotik one) and has wrong credentials, it will get banned too.

So think twice whether just having less messages like above in the log is worth the effort.

Simonej · Wed Jun 01, 2022 10:22 pm

Dear MT fans,
following the great advice from @Chupaka and MikroTik help, (https://help.mikrotik.com/docs/pages/vi ... d=28606504), I added to the firewall some protections,
here as example:

/ip firewall filter / mangle

add action=jump chain=input comment="Jump Input to Chain" connection-state=new jump-target=INPT-MANG
1) add action=return chain=INPT-MANG comment="DDoS protection" dst-limit=32,64,src-and-dst-addresses/10s
2) add action=return chain=INPT-MANG comment="UDP Flood" dst-limit=32,64,src-and-dst-addresses/10s protocol=udp
3) add action=return chain=INPT-MANG comment="DNS protection" dst-limit=32,32,src-and-dst-addresses/10s dst-port=53 protocol=udp
4) add action=return chain=INPT-MANG comment="SYN Flood" dst-limit=32,32,src-and-dst-addresses/10s protocol=tcp tcp-flags=syn
5) add action=return chain=INPT-MANG comment="SYN-ACK Flood" dst-limit=32,32,src-and-dst-addresses/10s protocol=tcp tcp-flags=syn,ack
X) add action=return chain=INPT-MANG comment="ICMP Flood" icmp-options=8:0 limit=2,5:packet protocol=icmp
add action=add-src-to-address-list address-list...

add action=jump chain=forward comment="Jump Forward to Chain" connection-state=new jump-target=FWRD-MANG
1) add action=return chain=FWRD-MANG comment="DDoS protection" dst-limit=32,64,src-and-dst-addresses/10s
2) add action=return chain=FWRD-MANG comment="UDP Flood" dst-limit=32,64,src-and-dst-addresses/10s protocol=udp
3) add action=return chain=FWRD-MANG comment="DNS protection" dst-limit=32,32,src-and-dst-addresses/10s dst-port=53 protocol=udp
4) add action=return chain=FWRD-MANG comment="SYN Flood" dst-limit=32,32,src-and-dst-addresses/10s protocol=tcp tcp-flags=syn
5) add action=return chain=FWRD-MANG comment="SYN-ACK Flood" dst-limit=32,32,src-and-dst-addresses/10s protocol=tcp tcp-flags=syn,ack
X) add action=return chain=FWRD-MANG comment="ICMP Flood" icmp-options=8:0 limit=2,5:packet protocol=icmp
add action=add-src-to-address-list address-list...

some questions;
- Because I noticed some CPU spykes, is Mangle more intensive than Filter?
- Now testing in Filter and Mangle with a different order; 1) DDoS, 2) UDP, 3) DNS, 4) SYN, 5) SYN-ACK, X) ICMP and X), 5), 4), 3), 2), 1), what is the best and correct position? In the Mangle order all the "load" will be processed by the first rule, DDoS, in inverted Filter order is more "distributed".
- Should be OK to add from Mangle and drop in RAW or better to use those rules in Filter?

Thanks!

rextended · Wed Jun 01, 2022 11:02 pm

ICMP flood is useless, on kernel is already locked.
And about DDoS, you can not do anything if you are the end user.
DNS protection is already useless, because all new incoming from WAN must be already blocked (At the end of input chain with already present drop all...), and not processed again on mangle....

BrateloSlava · Mon Mar 06, 2023 8:04 pm

It is possible, that this service is already known to the users of this forum. I found it by accident. Free and paid check of your DDOS protection.

With free checks, my home router (hAP ax3) coped well. But, after several checks in a row, my ISP disconnected me for 20 minutes. "Protected" me from these attacks.

My firewall rules look like this:

/ip firewall filter add action=jump chain=input comment="Drop user that has tried ports that are not open and has bin added to block list- Send to TARPIT to prevent DDOS CPU problems" in-interface-list=WAN jump-target=TARPIT protocol=tcp src-address-list=Banned-IP
/ip firewall filter add action=tarpit chain=TARPIT limit=10,5:packet protocol=tcp
/ip firewall filter add action=drop chain=TARPIT protocol=tcp
/ip firewall filter add action=add-src-to-address-list address-list=Banned-IP address-list-timeout=12m chain=input comment="Add IP of user to access list if they have tried port that is not open" in-interface-list=WAN log-prefix=Bruteforce src-address-list=!Allow_ALL

/ip firewall filter add action=drop chain=input comment="Drop everything else"
/ip firewall filter add action=drop chain=forward
/ip firewall filter add action=drop chain=output

/ip firewall raw add action=drop chain=prerouting comment="Honeypot for Bruteforce" in-interface-list=WAN protocol=!tcp src-address-list=Banned-IP
/ip firewall raw add action=drop chain=prerouting comment="DNS DDoS drop" dst-port=53 in-interface-list=WAN log-prefix=Attack protocol=udp src-address-list=!Allow_ALL
/ip firewall raw add action=drop chain=prerouting dst-port=53 in-interface-list=WAN log-prefix=Attack protocol=tcp src-address-list=!Allow_ALL

anav · Mon Mar 06, 2023 8:19 pm

Remove the link, its detected as a threat and shuts the browser down cold.

BrateloSlava · Mon Mar 06, 2023 8:29 pm

Remove the link, its detected as a threat and shuts the browser down cold.

Link 2 - original source

aTOMico · Sun May 21, 2023 5:58 pm

Should not these rules contain Wan as in interface?
I did get my internal PC blocked due to wrongly logged as d-dos

Hi,
I had similar problems.
After I set the RP filter to "none" in IP/Settings, everything worked fine. I had the RP filter set to "loose". Targets and attackers are now set correctly.
If I also set the jump rule in the input chain, even fast port scans to the router IP are recognized and blocked.
I tested this with online port scanners.
I use ROS 6.49.7 on a RB4011.

PackElend · Fri Jun 09, 2023 3:42 pm

"burst - initial number of packets or bits to match: this number gets recharged every 10ms so burst should be at least 1/100 of rate per second "

where does this information come from?
In Reference Manual v2.9 - NAT I find

Count - maximum average packet rate, measured in packets per second (pps), unless followed by Time option
Time - specifies the time interval over which the packet rate is measured
Burst - number of packets to match in a burst

If I read Linux 2.4 Packet Filtering HOWTO: Using iptables it is recharged when the connection expires.

In RAW - RouterOS - MikroTik Documentation I find

burst - initial number of packets per flow to match: this number gets recharged by one every time/count, up to this number

but how to interpreted

time/count

?

Chupaka · Sun Jun 11, 2023 5:48 pm

In RAW - RouterOS - MikroTik Documentation I find

It's about "dst-limit", scroll down to "limit", they are different

PackElend · Sun Jun 11, 2023 6:11 pm

In RAW - RouterOS - MikroTik Documentation I find
It's about "dst-limit", scroll down to "limit", they are different

thx for the clarification

do you know how to read: time/count in dst-limit?

optio · Sun Jun 11, 2023 8:26 pm

do you know how to read: time/count in dst-limit?

Imho rule is matched when in time period (until expire if set) threshold reaches burst. Threshold is summed by +1 when number of packets arrives in time per mode.
Eg. if you set dst-limit=2/2s,32,dst-address-and-port/10s then if in 2s 2 packets arrives for same dst-address and port then threshold is summed by +1, when threshold reaches burst - 32 in expire time - 10s then rule is matched, when expire time reaches its value threshold resets.

PackElend · Sun Jun 11, 2023 9:14 pm

Thx for the quick response. If it is like you explained, the burst explanation in dst-limit in the Wiki could be improved

optio · Sun Jun 11, 2023 9:44 pm

Thx for the quick response. If it is like you explained, the burst explanation in dst-limit in the Wiki could be improved

Yes, explanation of bust is a bit confusing, maybe if is written: burst - initial number of packets in time per flow to match: this threshold number gets recharged summed by one every

time/count

, up to this number
Or maybe just: burst - number of occurrences of packets count in time until expiration time (if set).