A MikroTik straight out of the box, or one that's had its default configuration removed, has little to nothing stopping traffic from the WAN side from reaching the router itself. You need a filter chain that blocks that, without accidentally blocking the management traffic you use to reach the router in the first place — which is exactly what goes wrong when the rules are written in the wrong order.
Accept established and related connections first
This has to be the first rule, or close to it: it lets replies to connections your network initiated back in, without which almost nothing works.
/ip firewall filter add chain=input connection-state=established,related action=acceptDrop invalid connections
Packets RouterOS can't associate with any known connection — often malformed or spoofed — get dropped here, before they reach any rule that might accidentally match them.
/ip firewall filter add chain=input connection-state=invalid action=dropExplicitly allow the management access you actually use
Add accept rules for WinBox/API/SSH from your admin IP ranges before anything that drops traffic — see our address lists guide for keeping this maintainable as the list of trusted IPs grows.
/ip firewall filter add chain=input protocol=tcp dst-port=8291 src-address=203.0.113.0/28 action=acceptDrop everything else coming from the WAN
This is the rule that actually locks down the router — and it has to go last, after every accept rule above it, or it'll shadow them.
/ip firewall filter add chain=input in-interface=ether1 action=drop(Replace ether1 with whatever your actual WAN interface is named.)
Why do it this way
RouterOS evaluates filter rules top to bottom and stops at the first match — so rule order isn't a style preference, it's the entire logic of the firewall. A "drop everything from the WAN" rule placed above your management-access rule doesn't coexist with it; it wins every time, and you lose WinBox access the moment you apply it. Building the chain in the order above — allow what's already trusted, drop what's clearly bad, allow what you explicitly need, then drop the rest — is what keeps every rule doing exactly the job it was written for, instead of silently overriding the one above or below it.
How MoniTik helps
If a firewall change does go wrong and a device drops off the network, MoniTik alerts you the moment connectivity changes — often before a customer notices, and definitely before you'd find out by someone calling to complain. And because MoniTik's remote WinBox access doesn't depend on the router's own management rules being open to the internet, you can safely lock the input chain down as tight as the guide above and still reach the router if something needs fixing.