Hundreds of thousands of MikroTik routers have been compromised over the years — conscripted into botnets, turned into cryptomining proxies, used as pivots into the networks behind them. Almost none of those compromises were exotic. The overwhelming pattern: management services reachable from the internet, running old RouterOS versions with known vulnerabilities, or protected by passwords that were always going to fail. WinBox on 8291 open to the world plus CVE-2018-14847 alone built entire botnets — and boxes with that profile still answer scans today.
The first-boot article in this series closed the obvious doors. This one is the complete management-plane treatment: every path into the router’s brain, enumerated and restricted, because attackers only need the one you forgot.
The Inventory: Every Way In
A RouterOS box can be managed via: IP services (/ip service — ssh, winbox, www, www-ssl, api, api-ssl, ftp, telnet), MAC-layer services (/tool mac-server — MAC-telnet and MAC-WinBox that work without any IP configuration), neighbor discovery (/ip neighbor discovery-settings — MNDP/CDP/LLDP announcing the box to adjacent L2), the bandwidth-test server, RoMON (next article), and the console port. Hardening means making a deliberate decision about each — the dangerous ones are the ones you didn’t decide about.
IP Services: Fewer, Bound, Restricted
# Kill what should never run/ip service disable telnet,ftp,www,api# Restrict what remains to management sources/ip service set ssh address=10.99.0.0/24,172.16.255.0/24 port=22/ip service set winbox address=10.99.0.0/24/ip service set www-ssl address=10.99.0.0/24 certificate=mgmt-cert disabled=no/ip service set api-ssl address=10.99.0.10/32 # automation host only, if used at allThe address= field is the underrated half — a service that only answers to the management subnet is invisible to everything else even before the firewall. Defense in depth means the input-chain rules from the firewall article still exist; the day someone flushes the firewall during debugging, service binding is what’s left standing.
WinBox deserves its own paragraph. It’s the tool everyone keeps, so keep it honestly: never reachable from WAN (the scan-to-exploit interval for newly exposed 8291 is measured in hours), restricted by address=, and only from networks you’d let touch SSH. “But I need remote WinBox” has a correct answer and it’s WireGuard — the road-warrior tunnel from earlier in the series terminates in the management network, and WinBox rides it. Changing the port buys nothing against modern scanners; source restriction buys everything.
SSH: keys, not passwords.
/user ssh-keys import public-key-file=admin.pub user=admin# strong crypto only (drops old algorithms)/ip ssh set strong-crypto=yes always-allow-password-login=noWith key-only SSH, the entire online-password-guessing problem class disappears for CLI access. Pair with the RADIUS article’s model for who-can-log-in, and the emergency local account stays key-based too.
The L2 Ghosts: MAC-Server and Discovery
This is the section people actually need, because these services are invisible in every port scan you run from outside — they live below IP.
MAC-telnet and MAC-WinBox let anyone in the same broadcast domain manage the router with no IP reachability at all. Magnificent for recovering a box you mis-addressed; catastrophic when enabled toward untrusted segments (guest VLANs, WAN handoffs that are really shared L2, ISP access networks):
# Interface list discipline from the firewall article pays off again/interface list add name=MGMT/interface list member add list=MGMT interface=vlan-mgmt/tool mac-server set allowed-interface-list=MGMT/tool mac-server mac-winbox set allowed-interface-list=MGMT/tool mac-server ping set enabled=noNeighbor discovery (MNDP, plus CDP/LLDP) broadcasts your RouterOS version, identity and MAC to adjacent L2 — a free reconnaissance feed on any untrusted segment, and the data source for MAC-WinBox targeting:
/ip neighbor discovery-settings set discover-interface-list=MGMTBandwidth-test server (/tool bandwidth-server) authenticates as a router user and will happily saturate your links; disable it and use targeted tests when needed:
/tool bandwidth-server set enabled=noThe pattern across all three: an explicit MGMT interface list, and L2 management services allowed only there. Default-everything is how a hotel guest ends up MAC-WinBoxing the property’s core router.
Management VLAN + VRF: The Structural Answer
Everything above restricts services on shared networks. The stronger design separates the management network itself — a dedicated VLAN carrying only management, and on routers where the stakes justify it, a management VRF so no routing mistake in production tables can ever route packets to (or from) the management plane:
/interface vlan add name=vlan-mgmt vlan-id=99 interface=bridge-lan/ip vrf add name=mgmt interfaces=vlan-mgmt/ip address add address=10.99.0.1/24 interface=vlan-mgmt/ip service set ssh vrf=mgmt address=10.99.0.0/24/ip service set winbox vrf=mgmt address=10.99.0.0/24The VRF article covered the sharp edges — services bound to a VRF stop answering elsewhere, router-originated traffic (RADIUS, syslog, backups from the previous articles) needs to reach its servers, so those live in the management network too. Test the whole loop from the management side before flipping anything, and know your recovery path (RoMON, console — next article) before, not after. This is the architecture where “we fat-fingered a BGP filter” and “management access” become provably unrelated events.
Access to the management VLAN itself is then the only thing left to defend: WireGuard in for humans, jump host for automation, 802.1X or port security on the switch side to decide who gets on it physically.
The Habits That Do the Rest
Restriction without maintenance decays. The management plane stays closed because of three habits: updates — most MikroTik botnets ran on years-old RouterOS with public CVEs; the upgrade cadence from the backup/upgrade article (recent stable, changelog read, lab first) is a security control, not housekeeping. Audit — quarterly, list every service and its bindings (/ip service print detail, /tool mac-server print, /user print) against what you documented; deviations are findings. Detection — the logging article’s remote syslog plus login-failure alerting means the brute-force attempt on the one service you exposed gets seen the day it starts, not in the post-incident review.
And the uncomfortable one: assume any management credential used over an unencrypted or shared path is burned. That’s why telnet/ftp/www stay dead, why api (plaintext) lost to api-ssl/REST, and why the RADIUS secret rides the management VLAN only.
Verification
Prove the closure from the outside:
# From an untrusted segment / internet host:nmap -p 21,22,23,80,443,8291,8728,8729 <router-wan-ip> # expect: filtered everywhere# On the router — what is actually listening and where:/ip service print detail/tool mac-server print; /tool mac-server mac-winbox print/ip neighbor discovery-settings print# Who got in, lately, and from where:/user active print/log print where topics~"system" message~"login"The nmap from outside is the one that counts. Config says what you intended; the scan says what’s true.
Closing Thoughts
Management-plane compromise is the worst compromise — it’s not a breach, it’s the attacker becoming you. The full treatment is finite and fits in an afternoon: services disabled or bound to a management list and subnet, WinBox behind WireGuard, SSH on keys, MAC-server and discovery scoped to MGMT, the management network itself separated (VLAN always, VRF where it matters), and the update/audit/alert habits that keep it that way. Every article in this series that came before — firewall, VPN, VRF, AAA, logging — contributed a piece; this is where they assemble into a router that scans as a black hole and logs like a security camera.