Input chain does not drop unsolicited traffic from the internet

What the audit found

Your configuration does have rules in the input chain of the IP firewall filter, but none of the active ones drops a new connection that arrives on the WAN interface. RouterOS accepts whatever no rule rejects, so the services running on the router — Winbox, SSH, the web interface, the API, DNS — remain reachable from the internet despite the firewall looking populated.

Rules that only drop "invalid" packets, and rules that exist but are disabled, do not count. The audit reports this as high on any device that routes traffic to the internet, because the effect is the same as having no input firewall at all.

Why it matters

This is the situation many people are in without knowing it. The router was set up with a couple of accept rules, perhaps a drop for invalid packets copied from a tutorial, and the final "drop everything else" line was never added — or it was added and later disabled while troubleshooting a VPN. Winbox shows a firewall with rules in it, so it feels protected.

It is not. Every port scanner on the internet sees the same set of open services as it would on a router with an empty firewall. Anyone can open a Winbox or SSH login prompt and start guessing passwords. If the router runs an older RouterOS version, a known bug such as CVE-2018-14847 works exactly as it did on the unfiltered devices that fed the 2018 botnets.

The problem also hides other findings. An audit of the individual services will show them as exposed, and that is correct — but the fix for all of them is the same single rule at the end of the input chain.

What it looks like in Winbox

Open IP → Firewall → Filter Rules and look only at rows where Chain is input. Read them top to bottom as the router does. You will typically see accept rules for established and related connections, perhaps an accept for ICMP, perhaps a drop for invalid — and then nothing. There is no final rule whose Action is drop and whose In. Interface or In. Interface List points at your WAN. If such a rule exists but is greyed out, it is disabled.

How to fix it

The fix is a single rule: one that drops every packet arriving on an interface that is not part of your LAN, placed last in the input chain. Everything the rules above it accepted — established sessions, ICMP, any service you deliberately opened — keeps working, and everything else is discarded instead of being accepted by default.

The rule refers to an interface list, conventionally named LAN, that holds your internal interfaces (usually the bridge, or your VLANs). Check under Interfaces → Interface List that it exists and actually contains them: if the list is empty or missing when the drop rule goes in, the router treats your own management traffic as foreign and drops it too. The accept rules for established/related connections and for ICMP must sit above the drop as well, otherwise replies and ping stop working. If some service genuinely has to be reachable from the internet — a WireGuard endpoint, for instance — give it its own accept rule for that exact protocol and port above the final drop, rather than leaving the chain open because one service needs a hole.

Do this with Safe Mode switched on in Winbox; if the change locks you out, the router reverts it when the session drops. Afterwards, try to open Winbox or SSH on your public IP from a network that is not your own — a phone on mobile data will do — and confirm it times out rather than showing a login prompt, while management from inside the LAN works as before. Then re-run the audit: this finding disappears and the exposed-service findings should drop to internal-only.

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 drop rule for invalid connections. Isn't that the same thing?

No. The invalid rule only discards packets that do not belong to any known connection state — malformed or out-of-sequence traffic. A brand-new, perfectly well-formed connection attempt to port 8291 is in state new, not invalid, and passes straight through. You need the final drop as well.

Will the drop rule block my port forwards?

No. Port forwards are handled in the forward chain after dst-nat; the input chain only concerns traffic addressed to the router itself. Your forwarded services keep working. The rule also does not affect traffic leaving the router or replies to connections the router opened, because the established/related accept comes first.

My rules match on a single WAN port instead of an interface list. Is that acceptable?

It works, but it is fragile: if the WAN moves to another port or a second uplink is added, the rule silently stops covering it. Matching on "any interface that is not in the LAN list" drops everything that is not explicitly internal, which fails safe rather than open.