WebFig over HTTPS reachable from the whole internet
WebFig on port 443 is encrypted, which is the right choice, but nothing limits who can open the login page. An internet-facing web login on a router invites password guessing and puts you one browser-side bug away from a takeover.
/ip service
What the audit found
The www-ssl service is enabled under IP → Services with no address restriction, and no firewall rule stops traffic on its port (443 by default) from arriving at the WAN interface. WebFig — the browser-based management interface — is therefore reachable from anywhere on the internet.
The audit rates this medium. Using HTTPS rather than plain HTTP already solves the eavesdropping problem, which is why the plain www service is rated higher. What remains is that a full management interface is exposed to everyone, and the audit does not report the same setting at all when WebFig is reachable only from the internal network.
Why it matters
WebFig gives whoever logs in complete control of the router, just like Winbox. Exposing it to the internet means the login page is available to every scanner and bot that finds your address, and they do find it: web login pages are among the most commonly probed things online, and the RouterOS page identifies itself clearly.
The first consequence is password guessing. A browser login is easy to automate, and a router with a weak or reused password on any account will eventually be opened. RouterOS logs the failures, but on an exposed router there are so many that the log stops being useful.
The second is that web interfaces are complicated pieces of software. The RouterOS web interface has been the entry point for several past exploits, including the chain that led to CVE-2023-30799, where an ordinary admin login could be escalated to full control of the underlying system. HTTPS protects the connection, not the code behind it. Anyone on the internet can send requests to that code; only your management network should be able to.
There is also a quieter issue. The certificate that WebFig presents — whether self-signed or issued for your domain — tells an attacker the router's identity and sometimes your organisation's name, which helps them target it.
The fix does not mean giving up remote management. It means reaching the router through a VPN or from known addresses, so the web interface is never the first line of defence.
What it looks like in Winbox
Open IP → Services. The row www-ssl (port 443) is enabled and its Available From column is empty. The Certificate column shows which certificate it presents; if it says none, the audit reports that separately.
Then open IP → Firewall → Filter Rules and check whether the input chain drops traffic from the WAN interface. If it does not, the service is exposed.
How to fix it
The fix has two layers, and a well-configured router uses both. The first is to restrict the service itself: fill the Available From field of the www-ssl row under IP → Services with the networks you manage the router from — your LAN, your VPN range, an office address; several can be listed. The router then refuses WebFig connections from any other address before the firewall is even consulted. Switch on Safe Mode in Winbox before you apply it if WebFig is your only management path and you are unsure of your own address — if the change cuts you off, the router reverts it when the session drops.
The second layer is the firewall: the input chain should end with a rule that drops anything arriving on the WAN interface that an earlier rule did not explicitly allow, placed after the accept rules for established and related connections and ICMP. That protects not only WebFig but every other service on the router, including the ones you forgot were enabled.
If you need to manage the router from outside, set up a VPN (WireGuard on RouterOS 7 is the quickest) and include the VPN subnet in the Available From list. Moving WebFig to a non-standard port is not a substitute; scanners check every port.
Afterwards, open the router's public address over HTTPS from a network other than your LAN — a phone on mobile data is enough — and confirm it times out, while from inside your management network the login page still loads. Then re-run the audit: the finding should disappear.
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 use HTTPS with a proper certificate. Isn't that secure enough?
The certificate secures the connection so nobody can read or alter it in transit. It does nothing against password guessing or against bugs in the web interface itself. Both of those need the interface to be reachable, and restricting reachability is the fix.
I need WebFig for a colleague who works from home. What do I give them?
A VPN account. WireGuard or L2TP/IPsec with a strong pre-shared key gets them an address inside your management range, and WebFig then works for them exactly as it does in the office. Adding their home IP address to the Available From list is a workable fallback if it is static.
Should I just disable www-ssl and use Winbox?
If nobody uses WebFig, disabling the www-ssl row removes the exposure entirely. Winbox is not inherently safer, though — it needs the same address restriction and firewall protection. Keep whichever interface you use, and restrict it.
This article explains the finding in general terms. Test any configuration change with Safe Mode enabled in Winbox. MKRouterKit analyses configuration exports only; it does not replace an external port scan or a professional penetration test.