FIREWALL / L2 HARDENING
Layer-2 hardening.
The L3 firewall doesn't see anything that happens at the bridge. A four-layer baseline closes the link-layer surfaces RouterOS exposes by default — MAC-layer management (MAC-Winbox / MAC-Telnet), neighbor discovery (MNDP / LLDP / CDP), DHCP spoofing, and STP root-bridge hijacking. Same posture every L2 hardening guide converges on (notably the Caster RouterOS lockdown writeup we cross-referenced for this page).
⚠ Test from console first
Three of these — MAC-server restriction, DHCP snooping, BPDU Guard — can cut LAN connectivity if applied to the wrong interface. Keep serial-console fallback ready, and apply on a lab device or single port before rolling out.
1. Restrict MAC-Winbox / MAC-Telnet / MAC-Ping
RouterOS's MAC-server lets Winbox + Telnet reach the router by MAC address — no IP needed. Useful when you've locked yourself out via an IP misconfiguration, dangerous when reachable from anywhere on the broadcast domain. Same goes for MAC-Ping (an L2 ICMP-equivalent). Restrict each one to a named interface list containing only your trusted LAN bridges, and disable MAC-Ping entirely if you don't use it.
# (1) restrict MAC-Telnet / MAC-Winbox / MAC-Ping to a LAN interface list (v6)
/interface list
add name=LAN comment="mtkf: LAN bridges + trusted ports"
/interface list member
add list=LAN interface=bridge-lan
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool mac-server ping
set enabled=no # (1) restrict MAC-Telnet / MAC-Winbox / MAC-Ping to a LAN interface list (v7)
/interface/list
add name=LAN comment="mtkf: LAN bridges + trusted ports"
/interface/list/member
add list=LAN interface=bridge-lan
/tool/mac-server
set allowed-interface-list=LAN
/tool/mac-server/mac-winbox
set allowed-interface-list=LAN
/tool/mac-server/ping
set enabled=no
The LAN interface list created above is reused by every
other rule on this page — single source of truth for "trusted
L2 surface."
2. Limit neighbor discovery (MNDP / LLDP / CDP)
MNDP is MikroTik's equivalent of CDP / LLDP — a UDP broadcast on port 5678 announcing the router's identity, RouterOS version, interface, and platform to anything on the same broadcast domain. Useful inside the rack, free reconnaissance to anyone on the wire. Default is "all interfaces." Restrict to LAN-only.
# (2) limit MNDP / LLDP / CDP to trusted interfaces (v6)
# MNDP = MikroTik's neighbor discovery — same role as CDP/LLDP.
# Default is "all interfaces" which leaks RouterOS version + identity
# to anything on the wire. Set to LAN-only.
/ip neighbor discovery-settings
set discover-interface-list=LAN # (2) limit MNDP / LLDP / CDP to trusted interfaces (v7)
# MNDP = MikroTik's neighbor discovery — same role as CDP/LLDP.
# Default is "all interfaces" which leaks RouterOS version + identity
# to anything on the wire. Set to LAN-only.
/ip/neighbor/discovery-settings
set discover-interface-list=LAN
The same setting controls LLDP and CDP advertisements when those
protocols are enabled — RouterOS treats all three as one switch
in this command. If you only want neighbor info on inter-switch
trunks, make a dedicated TRUNKS interface list and
point discover-interface-list at it.
3. DHCP snooping on the LAN bridge
DHCP snooping lets the bridge distinguish "trusted ports that host a DHCP server" from "ports that shouldn't be sending DHCPOFFER / DHCPACK." Anything from an untrusted port carrying those messages gets dropped at the bridge — kills rogue-DHCP attacks and most simple MITM setups on the LAN.
# (3) DHCP snooping on the LAN bridge (v6)
# Mark uplinks to known DHCP servers as trusted; everything else is
# untrusted by default. DHCPOFFER/DHCPACK from untrusted ports gets
# dropped — kills rogue-DHCP and most simple MITM setups on the LAN.
/interface bridge
set bridge-lan dhcp-snooping=yes
/interface bridge port
# trust the WAN uplink (if your ISP provides DHCP) AND any port that
# legitimately hosts a DHCP server. Everything else stays untrusted.
set [find interface=ether1] trusted=yes # (3) DHCP snooping on the LAN bridge (v7)
# Mark uplinks to known DHCP servers as trusted; everything else is
# untrusted by default. DHCPOFFER/DHCPACK from untrusted ports gets
# dropped — kills rogue-DHCP and most simple MITM setups on the LAN.
/interface/bridge
set bridge-lan dhcp-snooping=yes
/interface/bridge/port
# trust the WAN uplink (if your ISP provides DHCP) AND any port that
# legitimately hosts a DHCP server. Everything else stays untrusted.
set [find interface=ether1] trusted=yes Caveats: RouterOS doesn't have Dynamic ARP Inspection (DAI), so DHCP snooping doesn't get you ARP-spoofing protection the way a dedicated managed switch does. For small networks where you trust every connected device, this is acceptable — for production deployments where untrusted endpoints plug into the LAN, terminate users on a switch that supports DAI.
4. BPDU Guard on access-only ports
STP elects a root bridge using BPDU messages. An attacker can send BPDUs claiming a priority lower than your actual root, hijack the root role, and start receiving every cross-segment frame on the LAN. BPDU Guard disables a port the moment it receives a BPDU — appropriate for ports that connect endpoints (laptops, printers, IoT) which should never speak STP. Don't enable it on inter-switch trunks — those legitimately exchange BPDUs.
# (4) BPDU Guard on access-only bridge ports (v6)
# Endpoint ports (laptops, printers, IoT) should never send STP
# bridge-PDUs. If they do, an attacker is trying to claim the root
# bridge role — bpdu-guard disables the port the moment a BPDU is
# observed. Apply ONLY to leaf ports, not inter-switch trunks.
/interface bridge port
set [find interface=ether2] bpdu-guard=yes # (4) BPDU Guard on access-only bridge ports (v7)
# Endpoint ports (laptops, printers, IoT) should never send STP
# bridge-PDUs. If they do, an attacker is trying to claim the root
# bridge role — bpdu-guard disables the port the moment a BPDU is
# observed. Apply ONLY to leaf ports, not inter-switch trunks.
/interface/bridge/port
set [find interface=ether2] bpdu-guard=yes Re-enable a guarded port after it fires by clearing the disabled flag on the port's bridge-port entry. The trigger and clearing show up in the system log; consider piping to a syslog server if you're running this in a multi-tenant environment.
Related
- Services hardening — the L3/IP-services equivalent of this page.
- Winbox / SSH hardening — MAC-Winbox restriction here pairs with IP-Winbox restriction there. Both surfaces.
- Input chain — the final defense for anything that bypasses L2 controls.