RouterOS v7 Hardening: What Config Generators Get Right (and Miss)
RouterOS config generators are useful — but they have blind spots
Tools that turn plain-language descriptions into RouterOS scripts save real time on repetitive ISP work: PPPoE server setups, per-customer VLAN configs, RADIUS client entries. The problem is that most automated generators, and most hardening checklists, cluster around the same well-known IP-layer controls while leaving quieter attack surfaces untouched.
This post walks through what a solid RouterOS v7 hardening baseline looks like, where generated configs commonly fall short, and what a good review mode should check.
The IP service layer: necessary but not sufficient
RouterOS ships with several administrative services enabled by default. The standard hardening move is to disable everything unused and restrict the rest to a defined management subnet.
/ip service disable [find name~"telnet|ftp|www|api"]
/ip service set ssh address=10.0.0.0/8
/ip service set winbox address=10.0.0.0/8Any competent generator should produce these. Restricting services to an address list is the right baseline. But stopping here misses a whole other layer.
The layer-2 attack surface most checklists skip
MAC-Telnet and MAC-Winbox are RouterOS management protocols that operate at layer 2, below IP entirely. Enabled by default, they let any device on the same Ethernet segment reach the router’s terminal — even if every IP service is locked down tight.
/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=noneThis is the single most commonly missed item in RouterOS hardening. A router sitting on a shared VLAN with customer equipment, or behind a misconfigured trunk port, is fully reachable via MAC-Telnet regardless of what your firewall INPUT chain says. Disable it unless you actively use it for out-of-band access on a controlled internal segment.
The neighbor discovery protocol (MNDP/CDP) also leaks device and version information to anyone on the local segment:
/ip neighbor discovery-settings set discover-interface-list=noneNeither of these are in the IP services menu. That is exactly why they get missed.
Firewall INPUT chain: order matters
The INPUT chain governs traffic destined for the router itself. A common generator mistake is placing the established,related accept rule before the invalid drop rule. The correct order:
/ip firewall filter
add chain=input connection-state=invalid action=drop
add chain=input connection-state=established,related action=accept
add chain=input src-address-list=mgmt-hosts action=accept
add chain=input action=dropRouterOS processes firewall rules top to bottom. If established,related comes first, certain packets with a forged conntrack state can slip through before the invalid-drop rule catches them. The difference is subtle on quiet home setups. On an ISP router under DDoS conditions it matters.
The FORWARD chain needs the same treatment. Drop invalids first, accept established traffic next, then apply your customer-facing rules.
PPPoE and VLAN configuration for FTTH ISPs
FTTH deployments typically route multiple customer VLANs over a single physical OLT uplink. A few non-obvious pitfalls come up repeatedly.
- Do not assign an IP to the PPPoE-facing interface. The PPPoE server runs on the VLAN interface directly; the parent physical interface should stay unaddressed.
- MTU is 1492, not 1500. PPPoE frames add 8 bytes of overhead. A generator that hardcodes 1500 on PPPoE profiles causes silent fragmentation for customers running large-packet protocols like SMB or iSCSI. The misconfiguration often goes unnoticed until a specific application breaks.
- Use RADIUS rate-limit overrides instead of per-tier profiles. Maintaining separate PPPoE profiles for each bandwidth tier does not scale past a handful of plans. One base profile with per-user rate limits pushed via RADIUS attributes is much cleaner as your plan matrix grows.
/ppp profile add name=ftth-base local-address=100.64.0.1 remote-address=pool-ftth use-encryption=no only-one=yes
/interface pppoe-server server add interface=vlan100 service-name=isp default-profile=ftth-baseRADIUS client configuration
RouterOS’s RADIUS client is straightforward to set up but easy to misconfigure silently. The shared secret must match exactly on both sides — a single trailing space breaks authentication with no useful log entry. Set a timeout value that accounts for your RADIUS server’s response time under load; the default is often too aggressive for geographically distributed setups.
/radius add address=10.1.0.10 secret=your-shared-secret service=ppp timeout=3000
/ppp aaa set use-radius=yes accounting=yesGenerators that output RADIUS config without accounting=yes leave you without session data. That is a problem for any ISP that needs to handle billing disputes or satisfy data retention requirements.
RouterOS v6 vs v7 syntax differences
A generator that specifically targets v7 needs to handle some real syntax changes from v6. The most impactful ones for ISP configs:
- Routing filter rules now use an
if/thenscript-like syntax instead of the flat v6 rule format. Old-style filter configs will import but behave unexpectedly. - Bridge VLAN filtering mode — strongly preferred over older transparent bridging for multi-tenant setups — requires explicit
vlan-filtering=yeson the bridge object, plus tagged and untagged member assignments for each port. - Some
[find]query behaviors changed between versions. Scripts that ran correctly in v6 can silently return wrong results in v7, particularly when filtering on boolean properties.
A generated script that mixes v6 idioms into a v7 target config will often apply without errors but behave incorrectly. That is worse than failing loudly, because the misconfiguration sits there quietly.
What a useful review mode actually checks
For a config review tool to be genuinely useful at ISP scale, it should cover at minimum:
- MAC-Telnet and MAC-Winbox status
- Neighbor discovery exposure on external interfaces
- Firewall INPUT and FORWARD rule ordering — invalid before established
- Whether the default admin account still exists
- IP service address restrictions, not just enabled/disabled status
- RADIUS accounting enabled when RADIUS auth is configured
- PPPoE MTU settings on server profiles
- Whether
/ip proxy,/ip socks, and/ip upnpare disabled
Outputting corrected commands alongside each flag is the right format. A finding with no remediation step is half the job done.