Exposed Ports and Network Exposure: What to Keep Off the Public Internet

What open ports are#

A port is a numbered endpoint on a server where a particular service listens for connections. When a web server answers requests on port 443, or a database listens on port 3306, that number is how the operating system knows which program a new connection belongs to. A port is described as open when a service is actively listening on it and accepting connections. Web traffic uses 80 and 443, secure shell uses 22, MySQL uses 3306, and so on through a long standardized list.

The security question is not whether a port is open, but who can reach it. A database listening on port 3306 is normal and necessary. The same database reachable on port 3306 from anywhere on the internet is a serious problem. An internet facing port is one that any of the billions of hosts on the public internet can attempt to connect to, and every such port is effectively a door into the machine that an attacker can knock on.

This is why the guiding principle is to expose as few ports as possible. The set of services reachable from the internet is your attack surface, and each additional open port adds something an attacker can probe, fingerprint, and attempt to exploit. A public web server genuinely needs 80 and 443 open. Almost everything else, from databases to caches to management interfaces, should be reachable only from a trusted network and never from the open internet.

Ports to keep off the internet#

Some ports are dangerous to expose because the services behind them were built to trust whoever can reach them. They assume the network itself is the security boundary, so putting them on the public internet removes the one thing they were counting on. Databases are the textbook case, and management interfaces are a close second.

Database ports

• MySQL and MariaDB on 3306, where an exposed instance gives an attacker a direct login prompt to brute force or, if credentials are weak or absent, a straight path to the data.
• PostgreSQL on 5432, with the same exposure profile and frequently a default database holding production records.
• MongoDB on 27017, which historically shipped with no authentication and a default bind address that listened on every interface, a combination that fueled mass ransom attacks.
• Redis on 6379, which has no authentication by default and was designed as an in-memory store for trusted networks, never for direct internet exposure.

Management interfaces and legacy protocols

• RDP on 3389, the Windows Remote Desktop protocol, which is one of the most common entry points for ransomware because it grants interactive control of the whole machine.
• Web admin panels and dashboards, such as database GUIs, container orchestrators, and monitoring consoles, which often sit behind weak or default credentials.
• Telnet on 23 and FTP on 21, older plaintext protocols that send credentials in the clear and have no place on the modern internet.

Secure shell on port 22 sits in a middle category. It is designed to be exposed and is far safer than the protocols above, but it still attracts constant brute force traffic, so it benefits from key-based authentication and ideally an IP allowlist or a bastion in front of it rather than being left open to everyone.

How attackers discover them#

Exposed ports do not stay hidden, because the entire internet is scanned continuously. A port scanner is a tool that connects to a range of ports on a target and records which ones respond, which reveals exactly what is listening. Attackers run these against blocks of IP addresses, and the public address space is small enough that the whole of it gets swept many times a day.

They rarely need to do the scanning themselves. Internet-wide scan services such as Shodan and Censys continuously index every reachable host on the internet along with the service banner behind each open port. A banner is the short identifying string a service sends when you connect, often including its software name and version. Searching one of these services for a product like MongoDB returns tens of thousands of live instances, each tagged with its version and whether authentication is enabled. Finding an exposed database is a search query, not a research project.

The speed is the part people underestimate. Expose RDP on a fresh server and automated tooling will typically find and begin probing it within minutes, long before you have finished configuring anything. There is no quiet period in which a misconfiguration sits unnoticed. The moment a risky port opens, the clock starts.

The real risks#

The worst outcomes need no exploit at all, just a service that trusts the connection. Many databases historically shipped with no authentication, so an exposed instance lets anyone who connects read, change, or delete everything in it. In late 2016 and through 2017, automated scripts swept the internet for open MongoDB instances, wiped tens of thousands of them, and left ransom notes demanding payment for the data's return. Researchers tracked well over twenty thousand affected databases, and the only thing the victims had in common was an open port 27017 with no password.

An exposed Redis can be worse than data loss. Because Redis exposes a CONFIG command that can change where it writes its data file, an attacker who reaches an unauthenticated instance can point it at a sensitive location and write a file the system will later execute, such as a cron job or an SSH key. That turns a database exposure into remote code execution on the host, which is how many exposed Redis servers end up mining cryptocurrency for someone else.

Where a service does require a login, exposure turns into a brute force problem instead. An open RDP or SSH port invites relentless automated guessing, and a single weak or reused password is enough. Exposed RDP in particular is a leading initial access vector for ransomware crews, precisely because it hands over an interactive desktop session on the machine once they are in. The pattern across all of these is the same. The network was supposed to keep untrusted parties out, and the open port let them in.

How to reduce exposure#

Reducing exposure is mostly about defaulting to closed and opening only what genuinely needs to be public. The first layer is a firewall or cloud security group that denies inbound traffic by default. A web server then allows 80 and 443, and your administrative access path, and nothing else. In a cloud environment, the database's security group should permit traffic only from the application tier rather than from 0.0.0.0/0.

# Default deny inbound, allow only what the public needs.

# Linux (ufw): allow web traffic and SSH, deny the rest
sudo ufw default deny incoming
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 22/tcp
sudo ufw enable

# AWS security group: HTTPS open to all, database open only
# to the app tier's security group, never to 0.0.0.0/0
#   Inbound  443  tcp  0.0.0.0/0          (public web)
#   Inbound 5432  tcp  sg-app-tier-xxxx   (app servers only)

The second layer is to stop internal services from listening on a public address at all. Binding a database to 127.0.0.1 or a private interface means it physically cannot accept a connection from the internet, no matter what a firewall rule says. This belt-and-braces approach protects you when a firewall is misconfigured or removed by mistake.

# Bind a service to localhost so it never listens on a public address.

# PostgreSQL (postgresql.conf)
listen_addresses = 'localhost'

# MySQL / MariaDB (my.cnf)
bind-address = 127.0.0.1

# Redis (redis.conf), bind to loopback and require a password
bind 127.0.0.1
requirepass a-long-random-secret

# MongoDB (mongod.conf)
net:
  bindIp: 127.0.0.1

The controls that matter most

• Reach administrative services through a VPN or a bastion host rather than exposing RDP, SSH, or admin panels directly to the internet.
• Put any management interface behind real authentication and an IP allowlist, so a leaked URL is not enough to reach it.
• Close ports for services you no longer run, since yesterday's test database is today's forgotten open port.
• Audit your exposure on a schedule, because a single console change or a new instance can reopen something you had locked down.

How to check your exposure#

Checking your own exposure works from two angles. From the inside, list what is actually listening on the host and on which interface. From the outside, scan the server the way an attacker would and confirm that only your intended ports answer. The two views should agree, and any gap between them is worth investigating.

# See which ports your own host actually exposes.

# What is listening locally, and on which interface
ss -tlnp
# 0.0.0.0:5432  means Postgres faces every interface, so fix it.
# 127.0.0.1:5432 means it is bound to localhost, which is good.

# Scan from an outside machine to confirm what is reachable
nmap -Pn -p- your-server-ip
# Anything other than your intended public ports needs closing.

The OWASP Foundation's guidance on attack surface management is a useful reference for thinking about exposure systematically rather than host by host. You can read more in the OWASP Attack Surface Analysis Cheat Sheet.

A one time scan tells you what is exposed today, but cloud environments change constantly and a new instance or a tweaked security group can reopen a port overnight. SiteSecurityScore looks at your internet facing exposure as part of a scan and can keep watching over time, so a port that opens after your last review surfaces as a finding rather than waiting to be discovered by someone scanning for victims.

FAQ#