Open ports: doors to your server that should be locked

The short version

Ports, explained with a building

Picture your server as an office building with numbered doors. Door 443 is the public entrance — that is HTTPS, where your website visitors come in. Door 80 is the old entrance (plain HTTP) that should just redirect people to 443. Those two doors are meant to be open.

Then there are the back doors. Door 3306 is MySQL — your database, holding customer records, orders and passwords. Door 22 is SSH, the remote-control room. Door 3389 is Windows Remote Desktop. Doors 5432, 27017 and 6379 are other kinds of databases. These exist so that *you* (or your developer, from a trusted location) can get in. They were never meant to be open to the entire internet.

An open port means: anyone, anywhere, can walk up to that door and start trying handles.

What goes wrong

The moment a database port is reachable from the internet, automated tools will find it within hours and start guessing passwords — thousands of attempts a minute, forever. Weak or default passwords fall quickly. Some database software (MongoDB and Redis in their default setups, historically) did not even require a password, and millions of records have been stolen from exactly that mistake.

Open remote-access ports (SSH, RDP) are the other big one. RDP in particular is the way into a huge share of ransomware incidents: the attacker brute-forces the login, gets a desktop on your server, and encrypts everything.

• Critical: database ports — MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379). Direct access to your data.
• High: Elasticsearch (9200), Remote Desktop (3389), Telnet (23 — unencrypted and should never be exposed).
• Medium: FTP (21) — usually sends passwords unencrypted.
• Low / check intent: development servers (3000, 8080) that may have been left running.

How to check

On verified domains, VigilScan scans the thousand most common ports and reports anything open beyond the web ports, highlighting databases and admin services. We use a polite connection scan — nothing destructive — and tell you the port, the service, and the risk.

On most shared hosting (cPanel plans), your hosting company controls the firewall and these ports are normally closed to the outside already. This check matters most if you have a VPS, cloud server or dedicated server that you or a developer manage.

How to fix it

The principle: only ports 80 and 443 should face the internet. Everything else should be closed at the firewall, or restricted to specific trusted addresses.

1. Close it at the firewall. On a Linux server, ufw makes this simple: ufw default deny incoming, then ufw allow 80, ufw allow 443, and ufw allow from <your-ip> to any port 22 for your own SSH access. Cloud providers (AWS, DigitalOcean, Hetzner) also have firewall settings in their control panels.
2. Bind services to localhost. A database only needs to talk to the website on the same machine. Configure MySQL (bind-address = 127.0.0.1), Redis and others to listen only on the local address, so they are unreachable from outside even if the firewall slips.
3. Use a VPN or SSH tunnel for remote database access instead of opening the port. Tools like TablePlus and MySQL Workbench support SSH tunnelling out of the box.
4. Never rely on a password alone for a port that is open to the world. Strong passwords help, but closing the door helps far more.

Common questions