Problem RouterOS 6.38.5 - Denial of Service

DmitryAVET · Sat Apr 01, 2017 2:44 pm

A vulnerability in the network stack of MikroTik Version 6.38.5 released 2017-03-09 could allow an unauthenticated remote attacker to exhaust all available CPU via a flood of TCP RST packets, preventing the affected router from accepting new TCP connections.

More info:

https://cve.mitre.org/cgi-bin/cvename.c ... -2017-7285
https://cxsecurity.com/issue/WLB-2017030242
https://www.exploit-db.com/exploits/41752/

francisconeto · Sat Apr 01, 2017 3:24 pm

Just implement good firewall rules and all will work well.

pe1chl · Sat Apr 01, 2017 3:25 pm

Sigh... some people seem to be only on the planet to destroy other people's work and fun.
How pathetic.

Sob · Sat Apr 01, 2017 3:30 pm

Maybe, but in the end it's good, because once a problem is found and fixed, whole product gets better.

DmitryAVET · Sat Apr 01, 2017 3:33 pm

Just implement good firewall rules and all will work well.

Or change winbox port and waiting for security update.

pe1chl · Sat Apr 01, 2017 4:05 pm

Maybe, but in the end it's good, because once a problem is found and fixed, whole product gets better.

I think not the product must be fixed, but those people must be fixed.
I agree when there is a security problem something has to be done, but those idiots that just destroy other people's work and fun
deserve no place on this planet.

Mon Apr 03, 2017 8:06 am

Even worse. It could be their job...

DmitryAVET · Mon Apr 03, 2017 10:57 am

For personal use as home router is not problem. But if you have big network? Temporaily shoul use firewall rules

ip firewall filter add chain=input action=accept protocol=tcp src-address=[allowed IP] dst-port=8291 comment=Winbox

where need to change "allowed IP"

Mon Apr 03, 2017 11:05 am

Any device should have a firewall from the ports where unauthenticated users have access.

un1x0d · Tue Apr 04, 2017 9:43 am

We tested several devices (751, hEX lite, CHR - 8x Xeon) and found that they were 100% CPU and down any services on devices (and transit traffic) with this vulnerability. And it does not matter which destination port is specified and what rules are in the firewall. The result is one - device full down.

We waiting update ....

McSlash · Tue Apr 04, 2017 9:48 am

Any device should have a firewall from the ports where unauthenticated users have access.

This wouldn't help. Such attack on my ROS sill consume all available CPU. Checked on RB951, 2011, hAp Lite and CCR1036.
RST packets didn't create connection, so firewall rules will just help attackers consume CPU.

Tue Apr 04, 2017 9:57 am

Have you enabled "SYN COOKIE" option in the RouterOS settings? You should. This will help.

McSlash · Tue Apr 04, 2017 10:44 am

Have you enabled "SYN COOKIE" option in the RouterOS settings? You should. This will help.

Even with syn cookies, the attack is still successfull: we have not yet connection with attacker and suddenly receive RST package from him.

DmitryAVET · Tue Apr 04, 2017 11:28 am

Have you enabled "SYN COOKIE" option in the RouterOS settings? You should. This will help.

Just try to test this exploit on some devices.

hedele · Tue Apr 04, 2017 12:15 pm

Is this 6.38.5 and above only? Or does this also work on 6.37.5?

Tue Apr 04, 2017 12:42 pm

We just tested it. Simple firewall rule reduces load by at least 90%. Maybe there is something wrong with your rules? Please post them, so we can check.

hedele · Tue Apr 04, 2017 1:28 pm

The problem is that a firewall rule will knock our CCRs out of fastpath forwarding, thereby severely reducing throughput. Please fix this in software, and preferably offer an update for the current bugfix branch (6.37.x) as well.

Tue Apr 04, 2017 1:33 pm

Disable these services in "ip services" menu, change ports and use access-from setting. No firewall then. Only the enabled services in "ip services" menu suffer from this load issue.

hedele · Tue Apr 04, 2017 2:15 pm

So using the access-from lists mitigates the problem? That would be awesome because we're already using that in lieu of firewall rules to keep the devices in fastpath.

Tue Apr 04, 2017 2:26 pm

Access list does not help much, we tested it.

Basically you have these choices:

A) disable these services and change ports, configure some OOBM access from a special port that has no access to the public networks
B) use firewall
C) Get a more powerful router

If there is an open service, the router will take requests and send answers. There is no way around that. If you have ideas how to "eat the cake and have it" at the same time, let us know

hedele · Tue Apr 04, 2017 3:12 pm

Hm... i just did some testing myself, and at 200000 packets per second a CCR1009 running 6.37.5 barely breaks a sweat (like 10% cpu load max). I'm not sure this is really a problem other than "if you throw lots of packets at something it will eventually die".

DmitryAVET · Tue Apr 04, 2017 4:01 pm

If there is an open service, the router will take requests and send answers. There is no way around that. If you have ideas how to "eat the cake and have it" at the same time, let us know

Services like winbox, www, telnet and ssh typical use less than 1 Mbit per second. What, if create limit for traffic and packets per second? Like 5 Mbits and 1000 p/s.
When service use more than X Mbits or Y p/s - not reply, not ansver, and not handle packets, just ignore packets.
One time on start attack, and one on end - just write to log "Warning! Flood attack on service Z from IP...".
Its way to care CPU time. Why not? (as advanced option)

pe1chl · Tue Apr 04, 2017 4:13 pm

Basically you have these choices:

I think you forgot: for management from internet, use a VPN.

Tue Apr 04, 2017 4:35 pm

Basically you have these choices:
I think you forgot: for management from internet, use a VPN.

that still is one open service. unless you make a VPN to some other machine, then console into the CCR ... or something like that, when I mentioned OOBM

un1x0d · Tue Apr 04, 2017 5:01 pm

Start attack on RB3011. Lost ping. Traffic lost.

pe1chl · Tue Apr 04, 2017 5:58 pm

Basically you have these choices:
I think you forgot: for management from internet, use a VPN.
that still is one open service. unless you make a VPN to some other machine, then console into the CCR ... or something like that, when I mentioned OOBM

Of course, but in this case you can avoid this particular vulnerability because you can use a VPN that does not use TCP and thus you do not need an accessible TCP service.

avn · Tue Apr 04, 2017 6:40 pm

No need for open ports. Exploit works even in case of transit (forwarding) packets. Just tested it on my RB751G-2HnD.

UPD. The problem exists on many soho routers, tested on Dlink+Openwrt and Huawei with same result as Mikrotik.

kiler129 · Wed Apr 05, 2017 7:26 am

@normis: Could you post more information about affected versions? Is the problem specific to 6.38.5 or whole branch of 6.38 or is the situation even worse and affects more versions?

Wed Apr 05, 2017 9:44 am

No need for open ports. Exploit works even in case of transit (forwarding) packets. Just tested it on my RB751G-2HnD.

UPD. The problem exists on many soho routers, tested on Dlink+Openwrt and Huawei with same result as Mikrotik.

Please post details. We cannot repeat this. Also post your config.

Wed Apr 05, 2017 9:45 am

@normis: Could you post more information about affected versions? Is the problem specific to 6.38.5 or whole branch of 6.38 or is the situation even worse and affects more versions?

So far there is nothing that is affected. There is no exploit. The people are complaining that router CPU gets busy when working. This is normal. Either stop bad traffic with firewall, or disable services from public access.

Wed Apr 05, 2017 10:20 am

if you send any traffic to software based network device (one that runs with central CPU, not hardware based dumb device) you will generate load, live with it that is set in stone, you can't change that.

Thing you can do is configure your software based network device in a way load is minimized. in RouterOS devices, best way to do it is don't let DDoS traffic get to Connection tracking (that is most resource demanding service), on Internet Routers it is usually disabled, but on end-user devices it is usually enabled because of NAT , this is why Internet routers are not so affected.

In latest RouterOS versions there was added special feature - /ip firewall raw. special filter that can specify what traffic get to connection tracking, what traffic bypass it, what traffic are dropped before getting to connection tracking. Together with suggesting that was already mentioned, you can minimize this load.

avn · Wed Apr 05, 2017 10:34 am

Please post details. We cannot repeat this. Also post your config.

RB2011UAS-IN. Config reset to default, see attachment. Software: 6.37.5 (bugfix). Firmware: 3.33 (latest).
Exploit: https://cxsecurity.com/issue/WLB-2017030242
Ether1 of the router connected to the internet, ether2 - computer with Ubuntu 16.10, ip address 192.168.88.247.
Executing the exploit:

sudo perl exploit.pl 192.168.88.247 11111 1.1.1.1 11111

IP address of target host don't matter as long as packets go through the router. Ports also don't matter.
Effect of the exploit: packet loss 85%, cpu load 100%:

[admin@MikroTik] > system resource monitor 
          cpu-used: 100%
  cpu-used-per-cpu: 100%
       free-memory: 107064KiB

[admin@MikroTik] > tool profile 
NAME                    CPU        USAGE
ethernet                all        15.5%
console                 all         0.5%
dns                     all           0%
firewall                all          58%
networking              all        13.5%
management              all         0.5%
routing                 all           0%
profiling               all           1%
bridging                all        17.5%
unclassified            all           2%

avn · Wed Apr 05, 2017 10:44 am

In latest RouterOS versions there was added special feature - /ip firewall raw. special filter that can specify what traffic get to connection tracking, what traffic bypass it, what traffic are dropped before getting to connection tracking. Together with suggesting that was already mentioned, you can minimize this load.

Firewall raw don't help in this case, I tried it. No matter what you do with configuration.
Other devices (maybe based on linux kernel) also affected: Avaya IP phones, Cisco ASA 5515.
I think the problem in linux kernel, maybe tcp/ip stack.

Wed Apr 05, 2017 10:50 am

avn. Any traffic in such amounts will load the router, even if it is going to the internet.

This is your LAN. Go and unplug this user. If you are an ISP, call the police. There are other methods to solve sabotage in your LAN.

Still. It is not an exploit. Such things affect any internet router or internet connected device.

avn · Wed Apr 05, 2017 11:00 am

avn. Any traffic in such amounts will load the router, even if it is going to the internet.

This is your LAN. Go and unplug this user. If you are an ISP, call the police. There are other methods to solve sabotage in your LAN.

Still. It is not an exploit. Such things affect any internet router or internet connected device.

No. Not any traffic. Any traffic don't produce this effect. Only traffic, generated by the exploit. And not ony from LAN, but from WAN also, no matter the firewall. Anyone in the Internet can generate DoS from one PC - I think it's a problem.

Wed Apr 05, 2017 11:03 am

No. Not any traffic. Any traffic don't produce this effect.

There is nothing special in this traffic, look at the code. It just makes new TCP RES connections. If you download 100 torrents with 100 peer each, you will get same effect. The trick is to make NEW connections, so that the fasttrack doesn't come into play.

avn · Wed Apr 05, 2017 1:06 pm

There is nothing special in this traffic, look at the code. It just makes new TCP RES connections. If you download 100 torrents with 100 peer each, you will get same effect. The trick is to make NEW connections, so that the fasttrack doesn't come into play.

Agree. Although it will be nice to have capability to block unusual amount of tcp rst. Like unicast storm control or something. At the moment I don't know what to do if some guy in my network decided to test this exploit on my VPN server, for example.

hedele · Wed Apr 05, 2017 1:52 pm

I think it's important to remember that a substantial amount of traffic is needed to have any sort of effect on your devices. You won't be able to bring down a CCR using a residential xDSL line that only has a couple Mbit/s upload speed, or have one of your WiFi customers kill your network because they won't be able to get the appropriate amount of packets going. Also, i think using raw firewall tables to "notrack" connections to tcp/8291 is maybe a sound idea (be careful - using notrack will make "related" firewall filter matching impossible for those connections).

Wed Apr 05, 2017 2:08 pm

I think it's important to remember that a substantial amount of traffic is needed to have any sort of effect on your devices. You won't be able to bring down a CCR using a residential xDSL line that only has a couple Mbit/s upload speed, or have one of your WiFi customers kill your network because they won't be able to get the appropriate amount of packets going. Also, i think using raw firewall tables to "notrack" connections to tcp/8291 is maybe a sound idea (be careful - using notrack will make "related" firewall filter matching impossible for those connections).

there is no connection-state=untracked, so accept it in the very beginning of firewall;, together with established and related.

avn · Wed Apr 05, 2017 2:47 pm

I've tested exploit on RB750GL with various speed. Traffic was sent from LAN to inside interface of the router.
40 Mbit/s is enough to cause 100% cpu and 100% packet loss. It not happens instantaneously, need some time (2-3 minutes) for 100% packet loss.
Firewall raw rule (add action=accept chain=prerouting dst-address=<lan address> in-interface=<lan interface>) doesn't help, effect the same.

mrz · Wed Apr 05, 2017 3:03 pm

40Mbps of small packets is around 70kpps. With firewall rules it is the max that CPU can handle.
https://routerboard.com/RB750GL#perf

Of course it will max out the CPU, what do you expect? Get the router with faster CPU that can handle the load.

toxicfusion · Wed Apr 05, 2017 6:01 pm

Is this 6.38.5 and above only? Or does this also work on 6.37.5?

I'd also like to know this as well.....

Does this explicitly effect devices running 6.38.5 and above. Or would it apply to all devices running 6.38.5 and below?

avn · Wed Apr 05, 2017 7:34 pm

Is this 6.38.5 and above only? Or does this also work on 6.37.5?
I'd also like to know this as well.....

Does this explicitly effect devices running 6.38.5 and above. Or would it apply to all devices running 6.38.5 and below?

6.38.5 and 6.37.5 both are affected. Tested it myself.
I think all versions are affected, above and below.

aidan · Thu Apr 06, 2017 2:45 am

Resource exhaustion has the potential to affect any device or service, especially those with less processing power, and isn't a "vulnerability" or "exploit". Recently we saw the Mirai botnet cause a Dyn outage and they're certainly using bigger hardware than a hEX. Or "Black Nurse" which relied upon ICMP Unreachables instead of a TCP RST. But it's essentially the same problem and even Cisco doesn't consider it an issue as discussed at https://isc.sans.edu/forums/diary/ICMP+ ... rse/21699/.

The issue can be partially alleviated by implementing appropriate firewall rules, disabling unneeded services, or installing faster hardware. It's the end user's responsibility to implement what's appropriate for their environment and recognize that there may be times where it's not enough.

blajah · Thu Apr 06, 2017 11:46 am

I'm not getting why such heat about this "issue". From my point of view DoS and DDoS attacks are mainly directed, and if you do not have dedicated appliance for mitigation, any router based firewall is simply work-around. Even in work around context, creating dynamic firewall matchers, you can detect and drop such traffic, therefore reducing CPU load like Normis said 90%. In my case, load was high for 5-6 seconds while dynamic ACL's kicked in, and RAW firewall started to drop traffic. It's not exploit, its DoS, It's not Mikrotik. Its usable on many platforms.

Also, Pe1chi said

Sigh... some people seem to be only on the planet to destroy other people's work and fun.
How pathetic.

Actually not. If Stuxnet was not detected on time, would you be happy with XX dead people in Iranian nuclear facility? There are bad guys, but there are also good guys who published this info ( and many more). Second part of this story is network security. Its different then network implementation and administration. It is science for itself. You may like it or not, but there are alot of people ( including myself) who are enjoying playing with firewalls and overall IT security. More than anything else.

dzikis · Fri Apr 07, 2017 12:03 pm

What is soloution ?

pe1chl · Fri Apr 07, 2017 2:08 pm

What is soloution ?

There is no solution. But normally, there is no problem either.
When it becomes more of a problem, it has to be solved in the judicial way.

virus007 · Mon Apr 17, 2017 5:35 am

Works

/ip firewall raw
add action=drop chain=prerouting in-interface=ether1 ttl=equal:106

pe1chl · Tue Apr 18, 2017 3:06 pm

Works

/ip firewall raw
add action=drop chain=prerouting in-interface=ether1 ttl=equal:106

Unplugging your internet works best!

virus007 · Tue Apr 18, 2017 5:45 pm

Works

/ip firewall raw
add action=drop chain=prerouting in-interface=ether1 ttl=equal:106
Unplugging your internet works best!

Lol

SolarW · Tue Apr 18, 2017 6:18 pm

I can confirm - transit traffic from comp with exploit cause 100% CPU usage on transite mikrotik routers too, not only on exploit target.

Simple scheme:
Linux PC with exploit -> transite CCR1009 -> target RB2011UiAS-2HnD
After run exploit have 100% CPU usage on all mikrotiks.

P.S. Anybody with this exploit can block any network with mikrotik - this is not good

pe1chl · Tue Apr 18, 2017 8:58 pm

P.S. Anybody with this exploit can block any network with mikrotik - this is not good

Please understand that anyone with enough resources can block any network with or without MikroTik.
This is how the internet works. Some improvement can be made by implementing BCP38 everywhere, but botnet attacks remain possible.
That is why defense of these things must be done judicially not technically.

SolarW · Wed Apr 19, 2017 10:10 am

Please understand that anyone with enough resources can block any network with or without MikroTik.

If my resource home internet connection/linux PC with exploit and i can block large corporate network builded on mikrotik devices - this is vulnerability, not normaly situation.
Harrdware router (without linux inside) not vulnerable my this exploit?

P.S. Sorry for my bad English - this is not my native language.

Wed Apr 19, 2017 10:33 am

Please understand that anyone with enough resources can block any network with or without MikroTik.
If my resource home internet connection/linux PC with exploit and i can block large corporate network builded on mikrotik devices - this is vulnerability, not normaly situation.
Harrdware router (without linux inside) not vulnerable my this exploit?

P.S. Sorry for my bad English - this is not my native language.

1. Your PC will not have enough resources
2. Large corportate network has firewall and other protection
3. Any other network is just as vulnerable if you send lots of traffic to an open port

svserg · Wed Apr 19, 2017 1:36 pm

1. Your PC will not have enough resources
2. Large corportate network has firewall and other protection
3. Any other network is just as vulnerable if you send lots of traffic to an open port

1. Resources enough to stop the work of the router. We tested it experimentally.
2. Mikrotik are not a firewall?!
3. We need a solution to the problem, not an excuse, Normis

soulflyhigh · Wed Apr 19, 2017 2:29 pm

1. Your PC will not have enough resources
2. Large corportate network has firewall and other protection
3. Any other network is just as vulnerable if you send lots of traffic to an open port
1. Resources enough to stop the work of the router. We tested it experimentally.
2. Mikrotik are not a firewall?!
3. We need a solution to the problem, not an excuse, Normis

@svserg
Your PC has a lot more CPU power than most of today's routers and if you test this on LAN (over 100 or 1000mbps connection) it is true that you can overload almost any router's CPU.
But in real-life scenarios the attacker is usually on a separate remote network with much less available throughput between his PC and the target router. So, it is much more likely he will first congest that connection between the two than overload target's router CPU.

Regards,
M.

svserg · Wed Apr 19, 2017 3:45 pm

@svserg
Your PC has a lot more CPU power than most of today's routers and if you test this on LAN (over 100 or 1000mbps connection) it is true that you can overload almost any router's CPU.
But in real-life scenarios the attacker is usually on a separate remote network with much less available throughput between his PC and the target router. So, it is much more likely he will first congest that connection between the two than overload target's router CPU.

Regards,
M.

Are you trying to convince me of what I saw with my own eyes?
We conducted tests yesterday and made sure that a script running on a single-processor machine can stop the 4-core router from running on any of the available ports.We received a refusal yesterday to service the VoIP and other services.

soulflyhigh · Wed Apr 19, 2017 4:59 pm

@svserg
I have no doubt that you were under attack and that you had a problem but how big was that attack?
Many of those attacks are bigger than 1gbps and they simply saturate/congest internet uplinks to the end user.
How big is your internet uplink and was it congested during the attack?

So, lets assume that your internet uplink was big enough to handle the attack and that the problem was indeed the CPU on your routerboard.
What was the pps (packets per second) rate during that attack at the target routerboard?
Compare that pps with official Mikrotik test result at routerboard.com for your specific routerboard model (target routerboard model).
Now, there are two possibilities:
1) if these two numbers are roughly the same then I don't see it as a Mikrotik problem because routerboard has performed as good as Mikrotik said it would.
2) if pps during the attack was significantly lower than Mikrotik specified in their official test results (AND your internet uplink wasn't congested during the attack) - then that is a problem with Mikrotik hardware or software and you have all rights to complain about that directly to Mikrotik support.

Regards,
M.

Wed Apr 19, 2017 5:01 pm

Please post your rules. We can't load RouterOS to 100% with a regular PC if proper protection is configured.

svserg · Thu Apr 20, 2017 10:10 am

Please post your rules. We can't load RouterOS to 100% with a regular PC if proper protection is configured.

/ip firewall filter add action=add-src-to-address-list address-list=port_DDoS address-list-timeout=1d \
chain=input connection-state=invalid limit=50k,5:packet log=yes protocol=tcp src-address-list=!port_DDoS tcp-flags=rst

/ip firewall raw add action=drop log=yes chain=prerouting comment=DDoS log-prefix=BANN: protocol=tcp src-address-list=port_DDoS tcp-flags=rst

idlemind · Thu Apr 20, 2017 11:55 pm

For what it's worth a PC connected directly to my RouterBOARD 750G r3 and I was unable to break 30% with essentially the default configuration of rules, with fasttrack turned on. While I did see occasional CPU spikes I simply did not see anything that added up to a loss of service from a single PC. Either I'm doing it wrong or the stronger hardware in the 750G r3 just handles this better.

I'm running 3.35 firmware with 6.38.5

aidan · Fri Apr 21, 2017 3:49 am

Please post your rules. We can't load RouterOS to 100% with a regular PC if proper protection is configured.

Can you please provide an example of "proper protection"? As a Mikrotik best practice?

/ip firewall filter add action=add-src-to-address-list address-list=port_DDoS address-list-timeout=1d \
chain=input connection-state=invalid limit=50k,5:packet log=yes protocol=tcp src-address-list=!port_DDoS tcp-flags=rst

/ip firewall raw add action=drop log=yes chain=prerouting comment=DDoS log-prefix=BANN: protocol=tcp src-address-list=port_DDoS tcp-flags=rst

I'm not an expert but I believe these rules contribute to the problem you're seeing.

(a) Why not action=drop all connection-state=invalid traffic? If it's a concern then there's no reason to burden the RouterBOARD with it. Even Mikrotik suggests that you drop all invalid packets. Side note: I don't drop connection-state=invalid on chain=forward as it blocks RST/ACKs generated by modern versions of Windows.
(b) It will require more memory and more CPU power to maintain the address-list for 1d. I'd be concerned about it causing resource exhaustion with a DDoS of hundreds or even thousands of IPs. My suggestion would be to maintain the list for a shorter amount of time, perhaps 30s, as frequently attacking IPs will still be flagged for the action=drop rule, but IPs that stop attacking will be removed from the list sooner and free up resources.
(c) A limit of 50,000 packets is probably much higher than the RouterBOARD will ever see during normal operation. I'd suggest experimenting with a lower limit of perhaps 250 packets, 500 packets, or whatever is an appropriate baseline for your environment.
(d) log=yes is resource intensive and I don't suggest enabling it for large volumes of traffic. In addition, the factory default logging configuration will only retain 100 lines in the local memory buffer. If you want to log I'd highly suggest sending everything to a syslog server.
(e) tcp-flags=rst is unnecessary considering connection-state=invalid. Removing it will lower CPU consumption on the RouterBOARD.

pe1chl · Fri Apr 21, 2017 11:15 am

Side note: I don't drop connection-state=invalid on chain=forward as it blocks RST/ACKs generated by modern versions of Windows.

I notice that too, and it is actually a bug because those are "related" to the closed session. The connection tracking entry is deleted
too soon: after the FIN/FIN ACK it is immediately deleted but it should be kept for a couple of seconds to make sure that such RST ACK
or another FIN ACK is allowed.
It also affects NAT: when the connection is NATted, the RST ACK is not translated as the active connection has already been deleted, and
it goes out with the local (RFC1918) source address when it is not otherwise filtered. Not good.
However, this is not a MicroTik-specific bug, it is a Linux kernel bug. So it is not likely it is going to be solved, it probably requires major kernel work.

svserg · Fri Apr 21, 2017 1:01 pm

I notice that too, and it is actually a bug because those are "related" to the closed session. The connection tracking entry is deleted
too soon: after the FIN/FIN ACK it is immediately deleted but it should be kept for a couple of seconds to make sure that such RST ACK
or another FIN ACK is allowed.
It also affects NAT: when the connection is NATted, the RST ACK is not translated as the active connection has already been deleted, and
it goes out with the local (RFC1918) source address when it is not otherwise filtered. Not good.
However, this is not a MicroTik-specific bug, it is a Linux kernel bug. So it is not likely it is going to be solved, it probably requires major kernel work.

Yes. You are right, there is such error of the session closing, according to the protocol standard, at the end of the session there are flags <ACK> <FIN> and <RST>, but Mikrotik does not remember these connections. As a result, huge traffic is generated in a large network. If the IP with invalid the packages added to the list, which then drop - all the services will stop working, because MikroTik forgets about these sessions

These packages MikroTik considered as invalid. This is a typical end of the session according to the standard protocol tcp/ip.

firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,PSH), 192.168.1.245:443->10.24.0.26:53171, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN), 192.168.1.245:443->10.24.0.26:53171, len 52
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.26:53171, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.26:53171, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.26:53171, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.26:53171, len 153

svserg · Fri Apr 21, 2017 1:12 pm

I'm not an expert but I believe these rules contribute to the problem you're seeing.

(a) Why not action=drop all connection-state=invalid traffic? If it's a concern then there's no reason to burden the RouterBOARD with it. Even Mikrotik suggests that you drop all invalid packets. Side note: I don't drop connection-state=invalid on chain=forward as it blocks RST/ACKs generated by modern versions of Windows.
(b) It will require more memory and more CPU power to maintain the address-list for 1d. I'd be concerned about it causing resource exhaustion with a DDoS of hundreds or even thousands of IPs. My suggestion would be to maintain the list for a shorter amount of time, perhaps 30s, as frequently attacking IPs will still be flagged for the action=drop rule, but IPs that stop attacking will be removed from the list sooner and free up resources.
(c) A limit of 50,000 packets is probably much higher than the RouterBOARD will ever see during normal operation. I'd suggest experimenting with a lower limit of perhaps 250 packets, 500 packets, or whatever is an appropriate baseline for your environment.
(d) log=yes is resource intensive and I don't suggest enabling it for large volumes of traffic. In addition, the factory default logging configuration will only retain 100 lines in the local memory buffer. If you want to log I'd highly suggest sending everything to a syslog server.
(e) tcp-flags=rst is unnecessary considering connection-state=invalid. Removing it will lower CPU consumption on the RouterBOARD.

a) If the IP with invalid the packages added to the list, which then drop - all the services will stop working
b) may be.
с) If the limit is less than 50,000 then a huge number of "white" IP addresses are included in the list, which leads to the disabling of services

firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52740, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52746, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52741, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52732, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52748, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52747, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52751, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52749, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52758, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52766, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52767, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52775, len 40
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,RST), 192.168.1.245:443->10.24.0.118:52772, len 40

d) The administrator must see what is happening on the equipment.
e) Then all connections will be dropped, including those that go according to the protocol standard, which MikroTik "forgot" (See previous messages)

P.S. My English is bad, I translate Google. Sorry

pe1chl · Fri Apr 21, 2017 1:21 pm

[quote="svserg"
Yes. You are right, there is such error of the session closing, according to the protocol standard, at the end of the session there are flags <ACK> <FIN> and <RST>
[/quote]
No. RST is not part of the standard session closedown, it is a "rude close". Microsoft does this,

, but Mikrotik does not remember these connections. As a result, huge traffic is generated in a large network. If you just drop it, then some services stop working.

No, it should not have that effect.

svserg · Fri Apr 21, 2017 1:38 pm

No. RST is not part of the standard session closedown, it is a "rude close". Microsoft does this,

RFC 793

ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender

The TCP RST flag is meant to indicate that the connection should be immediately terminated if not terminated already, mostly because of a fatal error. Most commonly, the RST flag is seen in these situations:

A clients connects to a TCP server port on which no process is listening (i.e. a closed port)
Either client or server receives a TCP segment that carries an unacceptable value in the ACKSeq field while in non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED) - this is most often an indication of a delayed/duplicated/outdated segment
Either client or server has closed the connection but either this host has not yet processed all data received in the TCP queue for the process, or the peering host is sending data after this host has already asked to close the connection. This is to inform the other party that some data may have been lost.

Regarding session timeouts, a RST flag is actually sent if the connection has already been closed after a period of inactivity from one side, and the other side suddently comes back and wishes to continue the session as if nothing has happened. There is nothing wrong with this usage.

Invalid package from my MikroTik. For this IP accepted all connection and any protocol. This end connection from timeout client.

firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,PSH), 192.168.1.245:443->10.24.0.80:36203, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN), 192.168.1.245:443->10.24.0.80:36203, len 52
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.80:36203, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.80:36203, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.80:36203, len 153
firewall,info DROP: WiFi: in:3_Inside out:Bridge_WiFI, src-mac 00:50:56:80:67:0b, proto TCP (ACK,FIN,PSH), 192.168.1.245:443->10.24.0.80:36203, len 153

mrz · Fri Apr 21, 2017 3:58 pm

Firewall rule sets in case when CPU cannot handle amount of incoming traffic does not matter.
Look at performance tests for boards with 64byte packets.
For example if you have RB951 and some firewall rules
106.6kpps or 54.6Mbps with 64byte packets is maximum that CPU can handle.
If you have lets say 30Mbit uplink you will be fine, because attack will just congest the uplink, but if you have 100Mbit then CPU will be too busy processing incoming traffic.

Solution is to buy router that can handle uplink traffic without hitting CPU limit.
If you look at CCR1009-7G-1C-1S+ test results, it can handle 1Gbit uplink without hitting max CPU.

So pick the router with sufficient processing power.

As for low end bards with switch chips it is possible to set interface limit directly. That way packets will be dropped by switch chip, not even reaching CPU. For example 400Mbps attack with 60byte packets on RB951G with limit on interface 50000k/50000k results just in 90% CPU load allowing you at least to connect to the router and acknowledge that there is a DOS attack.

Who is online