MikroTik Router Setup: Securing a New RouterOS Box

A new MikroTik router is not an appliance that finishes configuring itself. It is a general-purpose routing operating system with a starter configuration applied at the factory, and the gap between that starter configuration and something you should expose to an untrusted network is the part nobody tells you about. This is the order the work should happen in, and why each step matters.

What is actually on the box when it arrives

Almost every MikroTik device ships with a default configuration already applied. The main exception is the CCR line, where professional models can arrive configured differently or with no configuration at all, so the first thing worth doing is checking rather than assuming.

On a typical home or small-office board the defaults look like this: ether1 is treated as the WAN port and runs a DHCP client, the remaining ports are bridged together as the LAN, the bridge carries 192.168.88.1/24, a DHCP server hands out addresses on that subnet, source NAT masquerades LAN traffic out of ether1, and a small firewall filter set protects the router itself. When no specific default applies to a model, RouterOS falls back to putting 192.168.88.1/24 on ether1, combo1, or sfp1.

Rather than guessing which variant your model has, RouterOS will print the exact commands that were applied:

/system default-configuration print

That output is the ground truth for your specific board. Read it before changing anything, because every later decision, including whether to keep the default config at all, depends on what is already in place.

Getting in the first time

Connect a computer to any port except ether1, because ether1 is the WAN side and the router will not offer DHCP or management there under the default rules. WinBox is the usual entry point. Its neighbor discovery panel lists MikroTik devices found on the local broadcast domain, and you can connect either by IP address or by MAC address.

The MAC option is the one to understand. MAC WinBox and MAC Telnet exist specifically so a device with no usable IP address is still reachable on the same Layer 2 segment. That is what saves you after a mistake, and it is also why those services should not stay enabled forever on a production network. The default credentials are the admin user with an empty password on older releases; recent RouterOS versions force you to set a password on first login instead.

If discovery shows nothing at all, the cause is almost always physical or Layer 2 rather than software: the wrong port, a managed switch in between that is filtering the discovery protocol, or a laptop firewall dropping the broadcast.

Set the password before anything else

Set a real password, then create a named administrative user and disable or remove the stock admin account. RouterOS user groups are granular, so a monitoring account that only needs read access should get exactly that and nothing more.

Upgrade twice, not once

This step is skipped constantly and it is two separate upgrades on RouterBOARD hardware.

The first is the RouterOS package itself. The second is RouterBOOT, the bootloader firmware, which is upgraded from the /system routerboard menu and only takes effect after another reboot. A device can happily run a current RouterOS release on years-old bootloader firmware, which is a source of odd behaviour that no amount of configuration review will explain.

Pick a release channel deliberately. The stable channel is the right default for a device you rely on. Reading the changelog before an upgrade is worth the two minutes, particularly across major versions where defaults and feature behaviour change.

Keep the default configuration, or wipe it cleanly

There are two defensible approaches and one bad one.

Keeping the default configuration and building on top of it is reasonable for a straightforward edge router. The stock firewall rules are a sensible starting point and the NAT rule is already correct.

Wiping and building from scratch is the better choice when the device has a job the defaults do not anticipate, such as a VLAN-segmented network or a router that sits behind another firewall. Reset with the no-defaults option so RouterOS does not immediately reapply the starter config, and be aware that this leaves the device with no IP address at all, which is exactly the situation MAC WinBox exists for.

The bad approach is half-deleting the default configuration by hand. That is how routers end up with a masquerade rule pointing at an interface that no longer carries the WAN, or a DHCP server bound to a bridge that has been rebuilt.

Close the management surface

MikroTik’s own hardening guidance is blunt about this, and the /ip service menu is where most of it happens. Every service listed there is a listening port on the router. Telnet, FTP, the unencrypted API, and the plain HTTP interface are all disabled rather than merely ignored on a router that faces the internet. What remains should be restricted with the available-from address list so that management is only reachable from the networks you actually manage from.

Two more surfaces sit outside /ip service. The MAC server controls MAC Telnet, MAC WinBox, and MAC Ping, and MikroTik recommends shutting these down on production networks or at minimum restricting them to a management interface list rather than all. Neighbor discovery, which advertises the device over MNDP, CDP, and LLDP, should likewise be scoped to internal interfaces instead of every interface including the WAN.

The firewall input chain is the backstop for all of it. The default rule set accepts established and related connections, drops invalid ones, and drops everything else arriving from the WAN interface list. If you rebuilt the configuration from scratch, that structure is the one to recreate.

Back up before you need to

Two artefacts, not one. A binary backup restores the whole device state including passwords and keys, but it is tied to the device and the RouterOS version. A configuration export is a readable script that can be diffed, version-controlled, and partially reapplied to different hardware. Take both, and take them before the change rather than after.

RouterOS also has a safety net for remote changes: safe mode holds your edits and rolls them back automatically if the session drops without confirmation. On any change that could cut your own access, particularly firewall and bridge work, that is the difference between a mistake and a site visit.

Plan the Layer 2 design before you touch the bridge

If the network has more than one broadcast domain, decide the VLAN layout on paper first. Enabling bridge VLAN filtering with an incomplete VLAN table is the single most common way to lock yourself out of a MikroTik device, and the failure is instant. The mechanics, including where the management address has to live, are covered in VLAN filtering on RouterOS bridges.

Confirm the hardware suits the job

The last step is a sanity check rather than a configuration change. RouterOS will run the same feature set on a $60 board and a $600 one, but the throughput ceiling is set by the silicon and by whether traffic can take the fast path. If the device is going to carry more than its published routing figures allow, no amount of tuning will fix it. The model tiers and MikroTik’s own published throughput numbers are compared in the MikroTik router buying guide, and the RouterOS FastPath and switch-chip sizer turns those tiers into an expected packet-per-second ceiling for a given configuration.

If throughput is already disappointing on hardware that should be fast enough, the cause is usually a configuration choice that pushed traffic off the fast path. That diagnosis is a separate exercise, walked through in why RouterOS throughput drops when CPU load climbs.

The short version

Print the default configuration and read it. Set a password. Upgrade RouterOS and RouterBOOT separately. Decide deliberately whether to keep or wipe the defaults. Disable the services you do not use and restrict the ones you do. Scope the MAC server and neighbor discovery to internal interfaces. Export the configuration. Then, and only then, plug ether1 into the internet.