Router management reachable from an open WiFi

What the audit found

One of your access points runs an open (unencrypted) network, and the interface its clients land on — typically a bridge shared with the LAN — is allowed by the input firewall to reach one or more of the router's management services: Winbox, SSH, the web interface, the API, Telnet or FTP.

In plain terms: anyone who connects to the open WiFi and opens Winbox or a browser is looking at your router's login prompt. The audit reports this as high and lists which services are reachable.

Why it matters

An open WiFi is usually meant as a guest network: internet access and nothing else. That only holds if the firewall enforces it, and on many routers it does not — the wireless interface sits on the same bridge as the office PCs, and the input chain accepts everything from that bridge because it is "the LAN".

The result is that the router's login prompt is exposed to whoever is within radio range: the café next door, a car in the street, a guest in the lobby. They do not need to break any encryption because there is none. They can run a password-guessing attack against Winbox or SSH from a laptop, and RouterOS will not stop them unless a strong password does.

A captive portal does not help. The portal controls whether a client may reach the internet; it does not stop packets addressed to the router itself, and the services answer before the portal is involved.

There is a second issue. Telnet, FTP and the plain API send passwords unencrypted. If another administrator logs in over one of them while on the open network, anyone nearby with a wireless sniffer captures the credentials.

What it looks like in Winbox

Open IP → Firewall → Filter Rules and look at the input chain. You will find an accept rule for your LAN that also covers the interface the open WiFi is bridged to, with no earlier rule dropping traffic from that interface. IP → Services shows which services are enabled and whether Available From is empty. Bridge → Ports shows which bridge the wireless interface belongs to.

How to fix it

Add two rules to the input chain under IP → Firewall → Filter Rules that allow guests only what they need from the router and drop everything else from their interface. The first matches the interface the open WiFi clients arrive on (the finding names it) with UDP destination ports 53 and 67 and accepts — that is DNS and DHCP, so guest devices can get an address and resolve names. The second matches the same interface with no further conditions and drops, which blocks every other connection to the router from that network.

Both rules must sit above the rule that accepts LAN traffic — drag them up in Winbox — otherwise the LAN rule matches first and nothing changes. If you run a hotspot, keep its dynamic rules; they do not conflict with these.

Do this in Safe Mode. If the open WiFi shares a bridge with your wired LAN, the drop rule also cuts your access from that bridge. In that case move the guest network onto its own bridge or VLAN first, then apply the rules to that interface only. If the network does not need to be open, adding WPA2 encryption is the other half of the solution.

Afterwards, connect a phone or laptop to the open WiFi and try to open Winbox, SSH or the router's web page on its LAN address; all should time out, while the device still gets an address and browses the internet. From your wired management network, Winbox should work as before. Then re-run the audit.

The full MKRouterKit report gives the exact commands for your configuration — with your interface names and subnets filled in, in the order that will not lock you out.

FAQ

I have a captive portal. Doesn't that already block guests?

No. The portal decides whether a client may pass through the router to the internet. Traffic addressed to the router — its login services — goes through the input chain and reaches the services before the portal has any say.

Will the drop rule break the hotspot itself?

Not if the DNS and DHCP accept rule sits above it and the hotspot's dynamic rules remain. Clients need DNS to be redirected to the portal, and the hotspot adds its own rules for the portal port. Test with a fresh client after the change.

My guest WiFi is on the same bridge as the office. What now?

Then guests can also reach office PCs, not just the router. Create a separate bridge or VLAN for the guest SSID with its own DHCP server and address range, and apply these rules to that interface. It is more work, but it is the only arrangement that actually isolates guests.