Low severity Finding USR002 4 min read

Full-access users can log in from any address

Accounts in the full group on your router have no address restriction, so a leaked password works from anywhere. Limiting admin logins to your management subnet adds a second barrier that costs nothing to maintain.

Where in the configuration: /user

What the audit found

One or more user accounts in the full group — accounts that can do anything on the router — have an empty Allowed Address field. RouterOS lets you tie each user to one or more source networks; when the field is empty, the account can log in from any address that reaches a management service.

The audit rates this low. It is a defence-in-depth measure rather than a hole: if your services are already restricted and the firewall drops WAN traffic, the setting adds a further layer, and if they are not, the exposed services are the finding to fix first. Note that the user list appears in an export only in some cases, so the audit can check this only when the accounts are present in the file.

Why it matters

Passwords leak. They get reused on a site that is later breached, typed into a phishing page, saved in a browser on a laptop that is stolen, or pasted into a chat by accident. When that happens to a router admin password, the question is what else stands between the attacker and the device.

Service restrictions and firewall rules are the first layer. The per-user address restriction is a second one that works differently: it is checked at login, on every service, and it follows the account rather than the port. Suppose Winbox is correctly limited to your LAN, but someone opens a temporary port forward or a new VPN, or the interface list is changed during troubleshooting. The exposed door is now open, but an account restricted to your management subnet still refuses a login from the internet. The attacker with the leaked password gets "invalid user name or password" and nothing else.

It also narrows the damage of an insider or a compromised device: an account restricted to the admin workstation cannot be used from a guest's laptop even if the password is known.

Because this is a low-severity finding, be honest about scale: on a well-firewalled router this is tidy rather than urgent. But it is a one-line change that never needs revisiting, and it is the kind of habit that turns a bad day into a non-event.

What it looks like in Winbox

Open System → Users. Each account shows its Group and Allowed Address. For accounts in the full group, an empty Allowed Address means no restriction. Double-click an account to edit it; the field accepts one or more networks in CIDR notation.

How to fix it

The fix is to fill the Allowed Address field of every full-access account under System → Users with the network you manage the router from — your LAN, your VPN range, or the admin workstation alone; several networks can be listed. The restriction is checked at login on every service (Winbox, WebFig, SSH, API, FTP, Telnet), so it does not need repeating per service. If different administrators work from different networks, give each account its own list rather than one broad range that covers everyone.

This is the one change in this category that can lock you out, so switch on Safe Mode in Winbox first and check the address you are connected from — it is shown in the Winbox title bar and under System → Users → Active. If you restrict your own account to a network that does not include your current address, the session ends and the router reverts the change with Safe Mode on. Without it, you would need another account or physical access to undo the mistake.

Include the VPN subnet if you administer the router remotely, and think about emergency access: it is reasonable to leave one rarely used account restricted to a directly connected management port or a link-local range, so that a console-style recovery is possible without a full reset.

Afterwards, log in from your management network to make sure you still can, and if you have a device on a different network — a phone on mobile data, or a guest VLAN — attempt a login from there; it should be refused even with the correct password. 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 manage the router from changing addresses (mobile, home, office). What do I set?

Give yourself a VPN and restrict the account to the VPN subnet. That way the address is always predictable, the connection is encrypted, and the management services can be restricted the same way. Listing every home and mobile range is brittle and quickly becomes unrestricted in practice.

Is this the same as the address field under IP → Services?

No, and they complement each other. The service address limits who can reach a particular service (Winbox, SSH). The user address limits from where a particular account may log in, on any service. Set both: the service restriction keeps scanners away, the user restriction stops a leaked password from working through any door that is later opened.

Will this affect the accounts used by monitoring or scripts?

Only if you restrict them to the wrong network. Accounts used by automation are ideal candidates for a tight restriction — a single-host entry for the monitoring server — because their source never changes. Give them a read group as well, if they only need to read.

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.