Since the dawn of Network Address Translation (NAT), we’ve needed to have a way to reach services from the public side to the private side. The answer came via Port Forwarding functionality where the NAT gateway would look for incoming protocol/port pairs and send it off to the internal IP behind NAT. That works just fine.
Along come search engines like shodan.io which will likely discover public-facing services in a short period of time, which means threat actors can also find such public-facing service(s).
There are many legitimate needs for port-forwarding, and we would suggest that for a typical business, they break into a few categories:
Safe to expose to the public Internet:
This would be services such as inbound SMTP mail servers that handle legitimate business email, web servers that offer a required portal, UDP-based VPN services, ideally on a non-standard port (OpenVPN on port other than 1194, for example). The key is that these services are all running code that is actively maintained and updated, with no risk of unpatched vulnerability, and very low risk of zero-day vulnerability.
Unsafe to expose to the public Internet:
This would be anything that does not fall into the “safe” category above, including IoT devices, security cameras, PLCs, and any controller at all that a vendor or third party or business users themselves need to be able to access remotely.
The good news is that there are two ways to make unsafe devices publicly-reachable in a safe manner.
- Apply a port-forward but constrain the source by specifying public IPs or ranges that can access the port forward. This way, the service availability isn’t available from up to 4 Billion unique IP addresses, but only from sources that are legitimate.
- Host a back-to-base VPN and distribute a VPN client to users that might need remote access. In this case, the VPN service itself is publicly exposed to anywhere in the world, giving greater flexibility in who can access the resource and from where.