RouterOS 7 First Boot Done Right: From Default Config to Hardened Baseline

The Mēris botnet of 2021 was built almost entirely out of MikroTik routers. Not because RouterOS is uniquely insecure — because hundreds of thousands of devices were deployed once, never updated, and left with management services listening on the WAN. The vulnerability that fed the botnet had been patched years earlier. The routers just never got the patch, and nobody had turned off the services that exposed it.

That’s the thing about MikroTik hardware: it’s cheap enough that people treat it like a disposable appliance, but it ships with the attack surface of a full router OS. Telnet, FTP, an HTTP API, MAC-layer management protocols — all on by default in some form. A RouterBOARD taken out of the box and plugged straight into a modem is a liability within hours.

The fix costs you about thirty minutes on first boot. This article is that thirty minutes, in order: understand what the default configuration gives you, take ownership of the admin plane, close every service you don’t use, update, and set the boring-but-critical basics — identity, clock, NTP. Everything here targets RouterOS 7.x current stable.

What the Default Configuration Actually Does

Most RouterBOARD models boot with a default configuration (the defconf script) that turns the device into a basic home router. Before you change anything, know what it contains — because half of it is worth keeping:

• ether1 is the WAN port, running a DHCP client.
• All other Ethernet ports (and WiFi, where present) are bridged into a single bridge with the address 192.168.88.1/24.
• A DHCP server hands out leases on that bridge.
• A srcnat masquerade rule NATs LAN traffic out of ether1.
• Two interface lists exist — WAN and LAN — and the firewall rules reference the lists, not the physical ports.
• A default firewall: input chain accepts established/related, drops everything from WAN; forward chain fasttracks established connections and drops WAN-originated traffic that wasn’t dst-natted.

You can read the exact script your device shipped with:

/system default-configuration print

My opinion: the default firewall is genuinely good and most people should build on it rather than delete it. The Mēris victims weren’t running the default firewall — they were running configs where someone had wiped it and never rebuilt. I’ll dissect those rules in the next article in this series; for now, leave them in place.

If you’re configuring a CCR or a device that boots empty, note that there is no firewall at all until you create one. Don’t put that device on a public network until you’ve finished this checklist.

Pick Your Management Plane: WinBox, SSH, or Web

RouterOS gives you three practical ways in, and they’re not equivalent:

WinBox is MikroTik’s native management client (TCP 8291). It’s excellent for discovery and for browsing an unfamiliar config — and it has one unique trick: MAC connectivity. WinBox can connect to a router by MAC address on the same L2 segment, with no IP configured at all. That’s your rescue path when you break IP connectivity, which is exactly why it must be restricted (more below).

SSH (TCP 22) is where real work should happen. RouterOS CLI commands are plain text you can keep in files, diff, and paste. Everything in this series is written as CLI for that reason. If you manage more than one router, CLI-in-version-control is the only sane workflow.

Web (www, TCP 80) is WebFig. It works, it’s unencrypted by default, and I disable it. If you want a browser UI, use www-ssl with a proper certificate or just use WinBox.

Use WinBox to look, SSH to change. And keep a serial console cable in the drawer for the devices that have a serial port — it’s the one management plane no firewall mistake can take away from you.

Users: Kill the admin Account

Every RouterOS box on the internet gets a constant drizzle of login attempts against the user admin. Take that username off the table entirely. Create your own full-rights user, verify it works, then disable the built-in one:

# Create a named admin user with a strong password
/user add name=ops group=full password="use-a-long-generated-passphrase"

# Log in as the new user in a SECOND session before proceeding,
# then disable the default account
/user disable admin

Newer RouterOS 7 releases ship without a default admin password and force you to set one on first login — good, but not sufficient. A renamed account plus a strong password removes you from every credential-stuffing list that assumes admin.

For SSH, load a public key and stop typing passwords:

# Upload your key first (drag into WinBox Files, or scp to the router)
/user ssh-keys import public-key-file=ops.pub user=ops

Then harden the SSH service itself:

/ip ssh set strong-crypto=yes

strong-crypto=yes disables the legacy ciphers and small DH groups that RouterOS otherwise still offers for compatibility.

Services: Close What You Don’t Use

The /ip service table is the front door list. Print it:

/ip service print

You’ll find eight entries: ftp (21), ssh (22), telnet (23), www (80), www-ssl (443), winbox (8291), api (8728), api-ssl (8729). You cannot add services here, only configure the existing ones — which makes this a rare finite checklist in networking.

My baseline for a production router:

# Disable everything that isn't SSH and WinBox
/ip service disable telnet,ftp,www,api,api-ssl

# Restrict the survivors to management networks only
/ip service set ssh address=10.10.99.0/24
/ip service set winbox address=10.10.99.0/24

The address parameter is a service-level ACL: connections from other sources are refused even before your firewall rules are considered. It’s defense in depth, not a firewall replacement — you still want input-chain rules, because address doesn’t stop a SYN flood from reaching the TCP stack.

Telnet and FTP deserve a special mention: there is no scenario in 2026 where either belongs on a router. Telnet is plaintext credentials; RouterOS FTP is mostly used by attackers to pull .backup files off compromised boxes. Kill both, always.

If you keep api-ssl for automation (Ansible’s RouterOS modules, for example), lock its source addresses to your automation hosts specifically, not the whole management subnet.

The Invisible Attack Surface: MAC and Discovery Services

Here’s what most first-boot guides miss: RouterOS listens on more than TCP ports. There’s a whole layer of MAC-based and discovery services that operate below IP, and they default to being available on far too many interfaces.

# MAC-telnet and MAC-WinBox: allow on no interfaces...
/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=none
/tool mac-server ping set enabled=no

# Neighbor discovery (CDP/LLDP/MNDP): don't advertise yourself on WAN
/ip neighbor discovery-settings set discover-interface-list=LAN

# The bandwidth test server: a free DoS amplifier if left on
/tool bandwidth-server set enabled=no

# If this router isn't your DNS resolver, don't answer DNS at all
/ip dns set allow-remote-requests=no

# Nobody needs these on a router
/ip proxy set enabled=no
/ip socks set enabled=no
/ip upnp set enabled=no

# MikroTik's cloud DDNS — off unless you deliberately use it
/ip cloud set ddns-enabled=no update-time=no

A note on the MAC server: setting it to none is the strict answer, and it means losing the WinBox-by-MAC rescue path. The pragmatic middle ground is allowed-interface-list=LAN, which keeps L2 rescue access from inside while denying it on WAN. Pick based on how much you trust your LAN; on a router I can reach physically, I set none and rely on serial.

SOCKS gets a special callout: a classic sign of a compromised MikroTik is /ip socks silently enabled with an unfamiliar port. It should be off, and if you ever find it on, treat the box as owned.

Packages and Updates

RouterOS 7 consolidated most functionality into the single routeros package, with optional extras (container, wifi-qcom, zerotier, gps, and friends). Check what’s installed:

/system package print

Don’t install optional packages speculatively — each one is code that can have CVEs. Add them when you need the feature.

Updating is two steps, and people chronically forget the second:

# Update RouterOS itself
/system package update set channel=stable
/system package update check-for-updates
/system package update install

After the reboot, upgrade the RouterBOOT firmware (the bootloader), which does not update automatically with the OS:

/system routerboard print
# If upgrade-firmware differs from current-firmware:
/system routerboard upgrade
# Takes effect on next reboot
/system reboot

Stay on the stable channel for anything that matters. The testing channel is for your lab. And check /system package update print a few times a year — unattended MikroTiks running years-old code is exactly how Mēris happened.

Identity, Clock, and NTP

Boring settings that pay for themselves at 3 a.m. during an incident:

# Name the box — this shows in WinBox, neighbor discovery, and your prompt
/system identity set name=edge-fra-01

# Time zone
/system clock set time-zone-name=Europe/Berlin

# NTP client — RouterOS 7 configures servers as list entries
/system ntp client set enabled=yes
/system ntp client servers add address=0.pool.ntp.org
/system ntp client servers add address=1.pool.ntp.org

Correct time is not cosmetic. Certificate validation, DoH, log correlation across devices, and scheduled scripts all silently misbehave when the clock is wrong — RouterBOARDs have no battery-backed RTC, so without NTP every reboot starts the clock in the past.

If you want the router to serve time to the LAN, /system ntp server set enabled=yes — but then make sure your firewall only permits UDP 123 from inside.

The First-Hour Hardening Checklist

The condensed version, in execution order:

That last row matters: /export file=baseline writes a plaintext config export you can copy off the router and put in version control. From here on, every change you make should be reproducible from that file plus a diff.

Verification

Trust nothing you haven’t tested from the outside. From a host on the WAN side (or a VPS on the internet if this is an edge router):

# You should see ZERO open ports from the WAN
nmap -p 21,22,23,80,443,8291,8728,8729 203.0.113.10

And on the router itself:

# Confirm the service table matches intent
/ip service print

# Watch who's knocking — failed logins show up here
/log print where topics~"system"

# Confirm time synced
/system ntp client print

If the nmap scan shows filtered or closed on everything, your service restrictions and default firewall are doing their job. If anything shows open, stop and fix it before this router carries traffic.

Closing Thoughts

None of this is clever. That’s the point — first-boot hardening is a rote procedure, and rote procedures belong in a paste-ready file you apply to every new device before it sees a hostile packet. Build that file once from this article, adjust the management subnet, and every future MikroTik you deploy starts life defensible.

What this article deliberately didn’t touch is the firewall itself — the default rules are fine to start, but “fine to start” isn’t where a production router should stay. The next article in this series takes the input and forward chains apart and rebuilds them drop-by-default, including what fasttrack actually does to your carefully planned QoS. If you run VyOS alongside MikroTik, the same first-boot philosophy appears in my VyOS Guide — the commands differ, the checklist doesn’t.