Open ports: databases and remote desktop exposed to the internet
Which services should never answer the whole internet, how attackers find them in minutes, how to see your own exposure without a scan, and how to close each one.
Your website needs ports 80 and 443 open to everyone. Almost nothing else does. Yet the most common first step of a ransomware attack on a small company is not a clever exploit: it is a remote desktop server, a database or an old firewall management page that answers anyone on the internet, found by a search engine that scans the whole internet every few days.
The ports that should not be public
| Port | Service | Why it is dangerous when public |
|---|---|---|
| 3389 | Remote Desktop (RDP) | Password guessing all day long, and a long history of critical flaws. A favourite entry point of ransomware groups. |
| 22 | SSH | Safe with keys only and a recent version; with passwords, guessed. |
| 445 | Windows file sharing (SMB) | Never meant for the internet; the route of WannaCry. |
| 3306, 5432, 1433 | MySQL, PostgreSQL, SQL Server | A database answering the internet invites password guessing and data theft. |
| 27017, 6379, 9200 | MongoDB, Redis, Elasticsearch | Often installed without any password at all; whole databases have been copied and ransomed this way. |
| 21, 23 | FTP, Telnet | Passwords travel in clear text. |
| 5900 | VNC | Remote screen control, often weakly protected. |
| 8080, 8443, 10000 | Admin panels | Router, firewall, hosting or appliance management pages. |
How attackers find them
They do not need to scan you. Services such as Shodan and Censys scan every public IPv4 address continuously and index what answers, with the software version. An attacker searches for “RDP in France” or “MongoDB without authentication” and gets a list. When a new flaw is published in a VPN or firewall product, the exploitation starts within days against every address that search engine lists.
See your own exposure without scanning
The same public indexes show your exposure, and looking at them is not a scan: you are reading data that already exists. Shodan’s InternetDB, for example, answers for a single address which ports were seen open and which known vulnerabilities match the versions it saw. List the addresses of your domain and subdomains first (the free DNS and surface map does it), then look each one up.
Pay attention to:
- hosts that bypass your CDN or firewall and answer directly on their real address;
- old servers nobody remembers, still running in a corner of a cloud account;
- the management interface of your firewall or VPN, which should only answer the internal network.
One caveat: if your site goes through Cloudflare or another CDN, its public address is the CDN’s, shared by thousands of sites. What the indexes say about that address (ports, versions, end-of-life software) is about the CDN, not your server.
Closing each one
- Remote access (RDP, VNC, SSH with passwords): put it behind a VPN or a zero-trust access service with multi-factor authentication, then close the port. If SSH must stay public, allow keys only and keep it updated.
- Databases and caches: bind them to the private network or
localhost, and firewall the port. A database that needs to be reached from outside should be reached through a tunnel, not directly. - Admin panels: restrict them to your office or VPN addresses.
- Anything you do not recognise: find out who set it up before you close it, then close it.
- Vulnerable versions: patch first the ones on CISA’s list of exploited vulnerabilities; they are being used against others right now.
After each change, check again: an exposure only counts as fixed when the public index stops showing it, which can take a few days.
How Perimetry watches it
Every Perimetry audit reads the public indexes for the addresses of your domains, reports the risky services they show, and ranks known vulnerabilities with CISA’s list of exploited vulnerabilities and the EPSS probability of exploitation. Shared CDN addresses are recognised and not blamed on you. A new port that appears between two audits is in the next report’s changes and, if it is serious, in an alert. Perimetry never scans your servers itself unless you subscribe to the verified active scan.