Since RouterOS is based on older Linux kernel, if you have any open TCP ports then you are likely vulnerable. Note that RouterOS default config firewall will protect you from this, only if you have open ports are you at risk from internet-based attacks.
Workaround is to add this to the top of your input rules. Adjust MSS as needed if you have some weird clients:
Surely it’s more cpu efficient to detect and add users to a dynamic address list which you then drop in raw?
I can’t imagine you’d want to accept traffic from someone trying to kill your systems?
Dropping the initial SYN is enough to stop the connection, other packets and fragments will just be ignored by the kernel. Adding to address lists and checking all inbound packets would use more CPU, plus since this isn’t a confirmed connection (SYN can be spoofed), you risk adding legitimate hosts to the list if you’re hit by an IP spoofing attack.
None of these CVE-s are noted in the MT Security Blog and thus they are not real!
On the other hand Rich1 is not a Trump kinda guy and thus the concerns are probably on the up and up.
Is the thinking that its not MT config that is vulnerable but the linux kernel and thus not their problem???
Just to confirm, evoking the simple one liner rule will have no detrimental affects on ‘normal’ home traffic???
/ip firewall filter add action=drop chain=input protocol=tcp tcp-flags=syn tcp-mss=0-500
Yes, I do have some ports forwarded but not in the 0-500 range
Let’s hope they have taken note and will issue an official comment and a patch. It’s already in upstream.
The TCP MSS is a TCP/IP specific parameter, unrelated to port numbers. It should not affect normal traffic at all. Maybe older modem-based services can be affected.
Chain input is a good step if you look at Mikrotik awn kernel. Also there are forwards and not all linux systems are already updated for this. Having also a main filter in the RAW looking at traffic coming in through the WAN is wise.
You are vulnerable if you are using a current Linux system, have selective acknowledgments enabled (a common default) and are using a network card with > TCP Segment Offload > (again, a common default in modern servers). A patch has been made available. Alternatively, you can disable SACK.
So, what is the state of TCP Segment Offload on Mikrotik network devices? Can we see the setting via RouterOS? Can the setting be changed?
Is a RAW rule like this sufficient? It drops any initial TCP packet advertising below 536 TCP MSS as per RFC 879 (untested):
I do not see any particular rule, similar to the ones posted in this thread, referenced in the blog (standard IPV4 or input chain traffic) that would specifically target the CVEs?
( I mean as an interim mod, until new vers’ are out).
To me just dropping seems better to me. The fixes are on the way and my DECT phone blinked red today to indicate that needed attention. That was the RSS notification of this and the security log was containing new information.
