From https://www.exploit-db.com/exploits/43317/

EDB-ID: 43317 Author: FarazPajohan Published: 2017-12-11
CVE: CVE-2017-17538 Type: Dos Platform: Hardware
E-DB Verified:  Exploit:  Download / View Raw Vulnerable App: N/A

This is not an exploit. Somebody is opening many connections and watching how the CPU rises.
All devices will use the CPU when answering requests, this is not unusual.

Just make a firewall to block such connections, or limit number of connections per second.

Description:
This could allow attacker(in your lan) to exhaust all available CPU and crash the kernel via a flood of ICMP packets with forged source IP addresses associated with the public Internet without fast connection. If you launch the exploit with local IP addresses, the router can handle the connections.

Please run the exploit and watch how your device will be crashed in less than 3 seconds and after that please run it on another router or firewall with default security configurations that exist in the market such as cisco or etc and watch how they can handle this situation.
Blocking the protocol or buying another router with more resources are not a solution, you should change the kernel's parameters such as other linux kernel or devices for this security situations.
Any devices need a basic security configuration before introducing to the market or you should block any protocol by default and let the admins open them if it's necessary.

You said "Somebody is opening many connections and watching how the CPU rises". Please check this link for understanding the ICMP Flood attack.
https://www.juniper.net/documentation/e ... nding.html

This is another exploit that an unathenticated remote attacker can exhaust all your available CPU for a long time by sending a simple carfted request(less than 300KB) to your router:
https://www.exploit-db.com/exploits/43200/
I sent the video of this attack to you and you answered you should have a firewall but as you know it is not depends on the firewall and it's about parsing the request because the router can handle the huge request and you saw this on that video.

I will not continue this conversation because anything that I have reported to you by the email during the recent year are answered like this comment that you wrote here.
Your company is one of the best and many organizations are using your products. If I reported anything to you, it was about improving the security. These simple attacks could be a big problem for the organizations that using your products.

This is not an exploit.

Yes - that's precisely why the topic says Denial of Service, and not Exploit

Funny how most devices have things like control plane policing, to limit things like this.

Yes - that's precisely why the topic says Denial of Service, and not Exploit
Funny how most devices have things like control plane policing, to limit things like this.

No it didn't. From the post and from the link:

DB Verified:  Exploit

Standard firewall prevents this. Even if you need to keep an open interface to the internet, just enable firewall to control connections per second. This is basic stuff.

The DNS thing is separate. I was talking about ICMP now.

Testing the DNS script is also not doing anything. No reboot and no crash. I tested a basic home AP device, not even very powerful. If your device rebooted, tell me what was written in the Log file. If this is "rebooted by watchdog", turn off watchdog and see what happens then.

Yes - that's precisely why the topic says Denial of Service, and not Exploit
Funny how most devices have things like control plane policing, to limit things like this.

No it didn't. From the post and from the link:

DB Verified:  Exploit

Standard firewall prevents this. Even if you need to keep an open interface to the internet, just enable firewall to control connections per second. This is basic stuff.

Normis,

If I'm understanding you right, your solution is disable Fastpath and go onto slow path with firewall rules?

If so, that seems more like a plaster on a festering wound rather than an actual solution to the issue?

You can choose, secure router or fast throughput. You are choosing to disable router security?
Fastpath is not for all situations.

What specifically would you like us to resolve, load of the device when it is doing something? All devices are loaded by all tasks that they perform.

....
Normis,

If I'm understanding you right, your solution is disable Fastpath and go onto slow path with firewall rules?

If so, that seems more like a plaster on a festering wound rather than an actual solution to the issue?

What is your proposition? You can't have an apple and eat an apple.
To firewall, or not to firewall, that is the question.

You can choose, secure router or fast throughput. You are choosing to disable router security?
Fastpath is not for all situations.

What specifically would you like us to resolve, load of the device when it is doing something? All devices are loaded by all tasks that they perform.

Then I would highly recommend adding large red text on your product page and inside winbox that states. "Using fastpath makes our devices insecure, with fastpath enabled, our devices can be taken offline in seconds with a simple icmp flood."

What is your proposition? You can't have an apple and eat an apple.
To firewall, or not to firewall, that is the question.

oh I don't know, maybe like expecting their "flagship router (CCR-1072)" to actually act as a secure router with fast throughput. Seems like this should be standard to be honest.
We don't firewall on our BGP peering routers, we firewall where firewalls are suppose to be, like right near the subnets / servers they are design to protect.

CCR1072 is quite fast with firewall enabled. If you have performance issues or need help with configuration, please make a new topic about it.
The above DNS flood script did not manage to kill even the RB2011 that I tried. Barely reached 90% CPU.

I'm sorry, for jumping in, but there are few points i would like to contribute.

1) There are 2 kinds of routers out there -
a) hardware accelerated - limited number of features, but @ wire speed
b) regular processing - many features, limited CPU and RAM processing resoursces
Fasttrack is software feature that allow to free up some of the limited CPU and RAM processing resources, giving up some of the functionalities.
So if you are using CCR1072 - you are not limited CPU and RAM, so there are no point of fasttrack there at all. You use one only when your CPU can't handle the load.

2) connection tracking IS the most expensive facility in RouterOS, it should be disabled for most of the traffic that doesn't need tracking (for example for NAT), as fasttrack only leaves connection tracking facility active, all load must be originating from there.
So in case of any kind of DoS attack, it is important to ensure that that traffic doesn't get to connection tracking, if your connection tracking is enabled, you can filter out what gets to in in /ip firewall raw" using action "notrack" for example on all ICMP traffic.

So in short:

1) using connection tracking on high capacity core network devices (CCR, PC) is dumb (if not used with strict RAW filter)
2) using fasttrack-connection on high capacity core network devices (CCR, PC) is dumb^2 (cause it needs connection tracking, so see Nr1)

Well.. downplaying these long going issues are no good.
In any dDOS attack scenario, even the simplest ones, if your attacked router has Connection Tracking enabled, you will go down.
Whether you have RAW rules or not, or 72CPUs or GBs of RAM etc.. it just doesnt matter. Your CPUs will be fully utilized.
You cant handle any type of attack with CT enabled, unless you have a Juniper or a Cisco in front of that device.

Description:
This could allow attacker(in your lan) to exhaust all available CPU and crash the kernel via a flood of ICMP packets with forged source IP addresses associated with the public Internet without fast connection. If you launch the exploit with local IP addresses, the router can handle the connections.

On a "guest type network" (where you can expect attackers) you should not allow forged source IP addresses in your firewall!
Only allow source addresses in your local subnet. You can make that even more strict by maintaining an address list from your DHCP leases and
only allowing traffic from addresses with a valid lease.

Description:
This could allow attacker(in your lan) to exhaust all available CPU and crash the kernel via a flood of ICMP packets with forged source IP addresses associated with the public Internet without fast connection. If you launch the exploit with local IP addresses, the router can handle the connections.

On a "guest type network" (where you can expect attackers) you should not allow forged source IP addresses in your firewall!
Only allow source addresses in your local subnet. You can make that even more strict by maintaining an address list from your DHCP leases and
only allowing traffic from addresses with a valid lease.

Or just use ip uprf strict. /ip/setting rp-filter:strict
The your router will not handle packets from adressess that are not have routes that are active back on ingress interface. Take care with vrf and routing protocols there are other settings and designs in that case.
You should not spec firewall cpu resources on something that can be deemed bad earlier in the process..

For a simple router between some local networks and a single internet interface, that is good enough.
I think it is a bit unfortunate that there is no "rpfilter" match in the mangle table of the firewall, as that
allows the easy use of rpfilter on some interfaces and more relaxed handling of traffic on link networks.
(e.g. in the presence of asymmetric routing)