API-SSL is enabled but nothing uses it

What the audit found

The api-ssl service under IP → Services is enabled on your router. This is the encrypted version of the RouterOS API on TCP port 8729, used by external programs — billing systems, provisioning tools, monitoring dashboards — to read and change the configuration with a user name and password. It is enabled by default on a new router, and the audit has no indication that anything is using it.

The audit rates this medium when the service is reachable from the internet and low when it is reachable only from selected external addresses. When it can be reached from the LAN alone, it is not reported.

Why it matters

The API gives the same power as Winbox or SSH: anyone who logs in can read and change everything on the router. The only difference is that it is meant for programs rather than people, which makes it an attractive target for automated attacks — a script can try thousands of passwords against it faster than against a human interface, and there is no visible session to notice.

Because it is encrypted, API-SSL is not the same problem as the plain API on port 8728, which sends credentials in the clear. The issue here is simpler: exposure without purpose. Every service listening on the WAN is an entry point that has to be defended, patched and watched. A service you do not use gives an attacker one more place to try a stolen or guessed password, and one more piece of software whose next vulnerability applies to you. Winbox's history (CVE-2018-14847) is the reminder that management services are where RouterOS has been hurt most.

If you do run software that talks to the router's API — a hotspot billing system, an automation tool, a custom dashboard — this finding is a prompt to restrict the service to that one source, not to switch it off.

What it looks like in Winbox

Open IP → Services. Find the row api-ssl: enabled, Port 8729, and typically an empty Available From column. Just above it, api is the unencrypted version, which the audit reports separately. The Certificate column shows whether a certificate is attached; the service still accepts connections without one.

How to fix it

If nothing uses the API — and on most routers nothing does — disable the api-ssl service under IP → Services. Disabling the API cannot affect Winbox, SSH or WebFig, so this is safe to do without Safe Mode. If an application later fails to connect, you will know exactly why and can re-enable it with a restriction.

If an application does use it, keep the service but limit it to that application's address in the Available From field — the real server address, or the subnet the application lives on. Give the application its own RouterOS user in a group with only the permissions it needs (System → Users → Groups lets you define one with read access alone, for example) rather than the full admin account. And make sure the input chain drops WAN traffic that you did not explicitly allow, so that the API is never reachable from the internet even if the address restriction is later removed by mistake.

If you are not sure whether anything uses the API, check the log for API login entries (Log, filter by topic) over a week, or disable the service for a few days and see whether anything breaks.

Afterwards, from outside your network, try to open a TCP connection to port 8729 on your public address with a port checker; it should fail. Confirm in IP → Services that api-ssl is disabled or carries an address, then re-run the audit; the finding should be gone.

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 a monitoring tool that reads the router over the API. Will this break it?

Only if you disable the service rather than restricting it. Set Available From to the monitoring server's address and the tool keeps working, while the internet no longer sees the port. Also consider giving the tool a read-only user.

API-SSL is encrypted. Why does the audit care at all?

Encryption protects the session from eavesdropping; it does nothing against password guessing or against a bug in the service itself. An encrypted door that nobody uses is still a door. The audit rates this lower than the unencrypted API precisely because the transport is fine — the objection is exposure without need.

Should I disable the plain api service too?

Yes, unless a legacy application needs it — and if one does, switch it to api-ssl and restrict that instead. The plain API is covered by its own finding.