I wish half my customers were proficient enough to plug their own network cables
configuring and managing their intranet, reading the changelogs before updating , and engaging in the beta thread? --unheard of–
Btest is not likely be able to be abused when device is compromised because it needs other endpoint to connecto to. Traffic-gen should be the one to be disabled…
7.17beta5 appears to have fixed this symptom.
I’ve successfully upgraded a hAP ax³, a CRS328-24P, and an RB4011 (wired-only) to beta5.
when compromised at least one device on at least 2 different networks (meaning 2+ devices), you can establish a btest between these devices.
If we redteam all possible scenarios of misuse, then mikrotik will have to rename, and become air-gapped-tik
There has to be a ballance between a deployable, diagnosable, mantainable/remotelly manageable piece of equimnent, and the possible avenues for abuse of such tools
i still believe that 7.17b5 is still heavy-handedly restricting legitimate and necessary tools and functionality
Ain’t we gasping at straws here? I mean, it’s true - but You are still limited to the processing capabilities of the (supposed) compromised Miktorik ate the attacked network. Really, really niche - and quite convoluted.
Functions shouldn’t be disabled in this way. A worldwide opened DNS/NTP server is more dangerous than btest or trafficgen! Should MTik disable these functions too? I think no.
Just a tip, maybe somehow these dangerous(?) functions needs multifactor authorization? A regular home user wont use trafficgen. btest has authentication. DNS/NTP server, hmmm, I ain’t a beginner but once I had left an innocent router with publicly accessible DNS server, and it was actively used in amplification attack, but I realized my mistake and fixed it fast.
Regards,
oreggin
In that case, we should definitelly hide this dangerous functionality behind device-mode
/s
or maybe fix DNS VRF-support, still broken in 7.17
or maye still, bind to interface-list, so we can direct the local DNS server to listen only on selected interfaces
DNS was just an example. It is a basic functionality of internet. In HTTPS/TLS world NTP too. You can’t just simply disable them without harm.
In device mode section, DNS and NTP are not mentioned, btest and traffic-gen does. We should handle this two category separated.
Let’s imagine what Mikrotik is trying to implement this for.
-
If the device is hacked, will the attacker update the software to limit himself?
No. -
If the device is not updated, will the Mikrotik solution help in the fight against hacking of these devices?
No. -
If someone updates the device, he will be warned in the update that the ability to disable potentially dangerous options has been added to establish increased security. Will this break the device?
No. Because the user himself takes measures to protect his device.
Accordingly, I suggest not to forcibly disable the capabilities of devices, but only indicate this in the update, as it was when switching to new Wi-Fi drivers.
As far as I understand MTik tries to mitigate unauhorized atterkers to using MTik devices for attacks.
In a perfect world, yes, In a real world, unfortunately not in every single case.
As far as I understand, MTik is trying to discourage unauthorized attackers from using MTk devices for attacks.
In a perfect world, yes, In a real world, unfortunately not in every single case.
The ISP serving one of my business clients has an entire network in bridge mode. As a result, if I enable the ISP’s interface discovery in the neighbors’ settings, I can see several of their clients who have Mikrotik routers, many of them with versions older than 6.45, and some even without passwords, where it was possible to log in using just the admin user. So, I agree with the Mikrotik team about finding a solution for the situation, but being radical doesn’t seem like the best approach. They should listen carefully to their clients so that they can come up with a solution that doesn’t harm those who are trying to work properly.
Why is BGP not getting any love?
There are several known problems in BGP yet no release notes about improvements…
What’s new in 7.17beta6 (2024-Nov-20 09:58):
!) device-mode - after upgrade, mode “enterprise” is renamed to “advanced” and traffic-gen, partition (command “repartition”), routerboard and install-any-version features will be disabled (additional fixes);
!) webfig - redesigned HTML, styling and functionality (additional fixes);
*) bridge - fixed bridge packet transmit if dhcp-snooping is enabled (introduced in v7.17beta5);
*) disk - added mount-read-only and mount-filesystem options to allow read-only mounts and prevent mounting device at all (CLI only);
*) firewall - improved matching from deeply nested interface-lists (additional fixes);
*) ipv6 - added support for manual link-local address configuration;
*) lte - improved recovery after unexpected modem reboot for Chateau’s 5G and 5G R16 series devices;
*) port - display a warning when using invalid log-file with the “remote-access” feature;
*) ptp - fixed DSCP values for IPv4 packets;
*) ptp - fixed synchronization on QSFP28 interfaces (additional fixes);
*) qos-hw - allow to disable/enable profiles, disabled or removed profile gets replaced with the default (additional fixes);
*) routerboot - improved stability for IPQ8072 and IPQ6010 when flash-boot is used (“/system routerboard upgrade” required);
*) smb - stability improvements for client/server (additional fixes);
*) supout - do not create autosupout.rif for second time after system reboot;
*) tftp - improved stability;
*) winbox - improved stability;
P.S: we have listened to the community and have walked back the device mode defaults. Btest is now allowed on the advanced mode template which is the same template that will be used after upgrade from previous versions if you did not change it manually. Also, to those who missed the previous betas, downgrade is also allowed to certain versions.
Great job, keep up the solid work. Looks like an RC release is nearby!
Thanks MikroTik 
Thank you for Btest 
Thanks