extra hardware-specific script(s) (e.g. target hardware might be "hEX" or "RB450G")
Requirements:
going for a full and complete lockdown, as in a state that is completely unusable for networking
drop all packets on all interfaces
disable all services that might transmit or receive on any protocol/interface or unnecessarily use CPU cycles
exception for configuration-access only:
serial-console on RS232 port only, if available, or
MAC Telnet on, e.g. interface ether5 only
specifically no WinBox (unless user modifies the script to enable it)
Perhaps the generic script uses variables that need setting, e.g. the number of interfaces on the board.
The specific hardware script could be the one that contains those variable assignments e.g. the number of interfaces on the board, or e.g. whether there is a switch chip and if if can be disabled by one method or another.
Reasoning:
for the beginning user that is more concerned about the security of the router than the many services that it might provide.
for the beginning user that just wants it to be easy to enable "one thing" and not have to educate themselves about all the features of ROS, their specific board, and the associated risks/vulnerabilities that are outside the scope of their "one thing"
Note:
This doesn't have to get done in one post. Even if you have ideas about the best strategy for accomplishing the goal, or if you know of generic or hardware-specific settings that should not be left out, please contribute what you can. All comments welcome.
I think I get where you're coming from, but I think you might be going about it in a slightly different way than I do.
I have a couple of configs that are hardened. I'm willing to post parts of them, sanitized from their actual purpose, if you're interested, and I find the time to prepare them. I use "run after reset/netinstall, no default config" scripts, which already does a lot around not enabling unneeded services.
I find normal IP connectivity easier to reason about, so I usually just turn off MAC-based access (or if it's left on, only for select ports that are normally disconnected.) Normal IP based access is then restricted by port. If such restrictions are in place, I see nothing intrinsically wrong with using Winbox/Webfig or whatever one might find the most convenient.
As for the "drop all packets" requirement, that's really easy to do with having a "drop all" rule for the input and forward chains.
It actually took me quite some time to collect all the things that have to be configured for such a state. (Such as auto time and time zone synchronization, disabling ipv6 or adding drop rules for input/forward/output or MAC ping and telnet, discovery, etc.)
Yes, I've been there with you before as well. When your work-day don't revolve around firewalls and when a good config lasts a long time, that seems to make for the opportunity to forget all the things that were learned and also to miss learning about new things need to be taken care of.
So if you have a list of lines from your config that you could share, that would help. I'm sure that I have saved configs or written notes along these lines, but the question is where? and also "when" were they valid?
So, for our purpose, it looks like this is a better starting point than the factory-default.
A first observation might be that all the pertinent firewall "drop" rules should be included in the setup script from here. It might be good also to include a variable in the script that could disable one or the other of IPV4/IPV6 or both if the user will not be doing dual-stack in the initial setup. (keeping the associated firewall rules though, so if enabled, the packets for the new protocol don't start flowing immediately)
And, regarding management-connectivity, I notice that since the default bridge is now gone, you can now mactelnet to the "Internet"/ether1 port, and that the mactelnet MAC address must now match the MAC of the port being used
whereas before, with factory-defaults, mactelnet did not work on ether1 and the client had to connect to the MAC of ether2, regardless of which LAN port the cable was connected to (ether2 to ether5)
Going to close that chit-chat topic as "I noticed" that for "our purposes" it has no additional value.
MTCNA or any "beginners" course is needed for OP whoever is/whatever it is.
"The first OBSERVATION" is that there is no need for more than suggestin that: https://mikrotik.com/consultants?category=consultants
Default configuration does take care of certain security settings, such as locking management access via WAN interface (usually ether1) ... as you already mentioned by you. And that configuration is not "baked in", it's part of configuration visible to admin and is thus changeable.
Reset to no defaults gives you ... no default config ... so it's then up to you to configure everything. There is possibility to construct a script which does your own default config and can be run right after configuration reset with run-after-reset= property. And it's also possible to set the same script as device's new default (e.g. when device gets reset by button press).
All of the above is admin's responsibility ... so admin better knows what he's doing. It is a consensus around this forum that ROS default config is pretty decent (I'd say better than many other vendors' default) so unless admin knows better, it's pretty safe to build custom config in top of default, not instead of default.
It is a fair enough comment. Not a normal use-case? True.
Also, I admit that I am capable of implementing this myself (given enough time). However, due to lack of recent experience, and the assumption that there may be others with similar desires, and that others may have this kind of thing implemented already, I tried to make the request as generic as possible, and open to different hardware.
No need to do anything except pulling the plug if you want to obey your own constraints. If there would be no access to a device then you have to reset replace it in person.
It is an universal solution that needs no "per model", "per interface" or any other "per .." tweaks.
It should work like this IMO:
You show what has been done by you already
You ask for comment
You enchance yor solution and go to #2
Now it looks like waiting for full answer/solution for an assigment you got.
I agree. Default is a good place to start if you have an office with a bunch of Windows laptops or something like that.
It may not be wise to feed the negative responses coming in, but for example: What if the whole purpose of your ISP connection is for one IPcam or for one envronmental sensor? and it is only polled from your server in the DC? Not going to spring for a special point-to-point connection plan from your ISP? Then maybe just plunk the device behind a locked-down router and only open the one hole that's needed. Not having to worry about dealing with the rest of the config. That's about as narrow of a scope I can come up with to back up the motivation here.
When there are special requirements ... and device admin is capable of configuring device according to those requirements (and do it in a safe manner), then ... well ... he's not surprised by the state after "/system/reset-configuration no-defaults=yes keep-users=yes" ... This is the crucial point of my previous post. If device admin is capable of creating such a special configuration, then I assume he is also capable of adding a few configuration commands which effectively drop any traffic not wanted (to, from and through device). Since underlying configuration will be pretty specific, it's hard to create a general "traffic shutdown" rule. As @BartoszP already mentioned, you probably want to still allow management traffic ... and this part is pretty specific in each individual case.
I appreciate the viewpoint of all the comments. Constructive ones the most.
That's just it. Why should it be special to have a locked-down config, ready to poke a hole or two into? Should be easy. We (including me) could all be writing it right now!
Mikrotik's default config is basically what people who buy a router expect out of the box. It's completely decent, and with it the router is arguably more secure than the generic brands, simply because Mikrotik has not been caught with hard-coded debug credentials and other really nasty stuff.
It's also sort of clear that a setup that e.g. only allows management connections from a single port that's only used for this purpose is more secure. It may be more tedious to use it, but it is protected against a lot of attacks.
A no-default router of course has to be configured. The wariness of the forum members comes from the observation that most people who try "lock down" to make them more secure make a mess out of it, and end up with less security and in many cases gaping holes.
If you want to make a brick from your router, then, as a next step, you need to "unbrick" it somehow.
How, with no network access to it, you want to achieve this except full reset with manual reset procedure?
The idea would be to start locked-down and then begin by opening maybe 1 thing. Can you think of a practical use-case for 1 thing? (port or destination or protocol)
Stop asking, act.
You have the default, or any other configuration, and what next? What is your proposal?
No access to a router "typical" way so you need another router/device to be used as a "trampoline" to get to RS port or to "special" dedicated for "I'm in troubles" interface.
Do you want and expect to get a working solution for any problematic situation just in front of your nose? MT consultants wait for the job to do for you.
I still have one unit that was a dedicated trampoline. You know it. But the mactelnet client started working some time ago, and so it's not needed anymore (for my setup). ...but my particular setup is not really on-topic:
We're looking generate a fully locked-down router script that leaves access for configuration only, and one which can be paired with a hardware-specific config. And we still need the critics to let us know if there are any gaping holes, as @lurker888 mentioned.
Gaping holes in what? You have "the chicken and the egg" situation. No config, no device but an artificial request to criticise something that does not exist.