A port forward exposes RDP, SMB or a camera to the internet

What the audit found

Your configuration contains a dst-nat rule under IP → Firewall → NAT that forwards a port from your public address to a device on the internal network, and the rule does not limit which source addresses may use it. The forwarded service is one that is heavily scanned and attacked when reachable from the internet — Remote Desktop (RDP), SMB file sharing, VNC, a database, Telnet, Winbox on another device, or the web and RTSP interface of a camera recorder.

The audit reports this finding for each such forward, and rates it high for services with a long history of remote takeover, medium for the rest.

Why it matters

A port forward makes the router step aside: whatever arrives on that port goes straight to the internal device, and the router's own firewall no longer protects it. The device behind the forward is then exactly as exposed as if it were plugged directly into the internet.

Picture a small office that forwards port 3389 so the owner can reach the accounting PC from home. Within hours, automated scanners have found the open RDP login and are trying user names and passwords around the clock. Eventually one works — or a known bug in an unpatched service is used instead — and the attacker has a Windows session inside the office network. The usual next step is file encryption and a ransom note. Exposed RDP and SMB are among the most common first footholds for ransomware groups, and CVE-2018-7445 showed that even the router's own SMB service could be exploited remotely.

Cameras and recorders are a different flavour of the same problem: old firmware, default passwords, and either a botnet recruit or a live view of your premises for a stranger.

What it looks like in Winbox

Open IP → Firewall → NAT. Look for rules with Chain set to dstnat and Action set to dst-nat. The Dst. Port column shows the published port and To Addresses shows the internal device. If the Src. Address and Src. Address List fields are empty, anyone on the internet can use the forward.

The same list, filtered to the dstnat chain, is what the audit reads from your export.

How to fix it

The safest option is to remove the forward and reach the service through a VPN instead. WireGuard on RouterOS 7 takes a few minutes to set up, gives you the same access from anywhere, and leaves nothing published. Disable the NAT rule rather than deleting it, so you can put it back if something unexpected depended on it.

If the forward genuinely has to stay, restrict it to the addresses that need it. The principle is an address list under IP → Firewall → Address Lists holding your remote locations and the Src. Address List field of the dst-nat rule pointing at that list. The forward then accepts only those sources and ignores everyone else. Repeat for each published port. Note that a source restriction only helps if the remote side has a fixed address; people on mobile networks or dynamic ISP addresses will need the VPN route.

Whichever you choose, also patch and set a strong password on the device behind the forward. Use Safe Mode in Winbox if you are editing the rules from the same connection you are testing, so a wrong rule reverts itself instead of cutting you off.

Afterwards, from outside your network — a phone on mobile data will do — try to connect to your public address on the forwarded port; it should time out or be refused, while from a trusted address or over the VPN the service should still respond. 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 changed the external port to something random. Is that enough?

No. Scanners walk through the whole port range and recognise RDP, SMB or VNC by how the service answers, not by the port number. An unusual port cuts down the noise in your logs, but the first scanner that finds it will start guessing passwords just the same. Restrict the source or move to a VPN.

The forward is for my IP camera. Does that really matter?

Yes, for two reasons. Cameras and recorders are rarely updated and often ship with default credentials, so they are a favourite target for botnets. And a camera that anyone can reach is a privacy problem in its own right. Most camera vendors offer a cloud relay or app; otherwise, a VPN to the router is the safe way to watch the feed remotely.

Can I keep the forward but add a firewall rule instead?

You can — a rule in the forward chain that drops new connections to that internal address and port unless the source is on your trusted list has the same effect. The source address list on the NAT rule itself is simpler and harder to get wrong, which is why the audit suggests it.