Open Ports and Security Risks: Which Ports Should Never Be Public
Every open port is a service listening for connections. Some, like HTTPS on 443, are meant to be public. Many others end up exposed by accident, and automated scanners across the internet find them within hours.
Ports that should rarely be public
| Port | Service | Risk if exposed |
|---|---|---|
| 22 | SSH | Brute force, exploitation of outdated servers |
| 3389 | RDP | Brute force, ransomware entry point |
| 3306 | MySQL | Data theft, credential attacks |
| 5432 | PostgreSQL | Data theft, credential attacks |
| 27017 | MongoDB | Historically exposed without authentication |
| 6379 | Redis | Often no authentication, can lead to code execution |
| 9200 | Elasticsearch | Data exposure if unauthenticated |
| 2375 | Docker API | Full host control |
| 6443, 10250 | Kubernetes API, kubelet | Cluster compromise if misconfigured |
| 11211 | Memcached | Data exposure, amplification attacks |
| 5900 | VNC | Remote desktop access |
| 445 | SMB | Exploits and data access |
| 8080, 8000, 9000 | Dev servers and admin UIs | Debug interfaces, dashboards |
Why accidental exposure happens
- A developer opens a database to their home IP and uses
0.0.0.0/0instead. - A container publishes a port on all interfaces by default.
- A test server is launched with a default security group.
- A managed service is created with public access enabled.
- A firewall change during an incident is never reverted.
How attackers find open ports
Attackers do not need to target you specifically. Internet-wide scanning tools sweep every IPv4 address regularly, and search engines index exposed services by software and version. An exposed database can be found and attacked within hours of going live.
Reducing exposure
- Default deny inbound. Only open what must be public, typically 80 and 443.
- Use private networking for databases, caches and internal services.
- Use bastion alternatives, such as cloud session managers or identity-aware proxies, instead of public SSH and RDP.
- Bind services to localhost or private interfaces, not
0.0.0.0. - Require authentication on every service, even internal ones.
- Manage firewall rules as code, with review.
- Monitor continuously for new exposures.
Checking your own exposure
You can scan your own IP addresses and domains with standard tools, or use continuous external monitoring. Make sure to include all cloud accounts and regions, IPv6 addresses, and domains pointing to third-party hosting.
SecurityInfinity's network agent continuously discovers open ports across your domains and IPs, identifies services and versions, matches them to known CVEs and flags services that should not be public. Start free.
Frequently asked questions
Is it safe to expose SSH with key authentication?
Key-only authentication is much safer than passwords, but exposing SSH still invites attacks on the service itself. Restrict access by IP or use a session manager where possible.
Are non-standard ports safer?
Moving a service to an unusual port reduces noise from basic scans, but internet-wide scanners check all ports. It is not a security control.
What should I do if I find an exposed database?
Restrict access immediately, rotate its credentials, and review logs for unauthorised access, assuming data may have been accessed.