Common Server Ports: Which Should Be Open and Which Must Be Firewalled
Every open port is a potential attack surface. Here's a practical reference of common ports — what they do, which should be publicly accessible, and which are commonly left dangerously exposed — with guidance on interpreting scan results.
By sadiqbd · June 9, 2026
Every open port is a potential entry point — knowing which ones should be open is half of server security
A freshly provisioned cloud server has default firewall rules that may be more permissive than you'd expect. Port 3306 (MySQL) open to the internet. Port 5432 (PostgreSQL) exposed. Redis on 6379 with no authentication. These aren't hypothetical risks — they're among the most commonly exploited attack vectors against servers, and they persist because administrators don't check.
Understanding which ports serve legitimate purposes, which need to be public, and which should be strictly firewalled is the foundation of server security configuration.
The well-known ports: a practical reference
Ports 0–1023 are "well-known" ports, assigned by IANA for standardised services. Beyond these, registered ports (1024–49151) and dynamic ports (49152–65535) cover a wide range of applications.
Infrastructure and management
Port 22 — SSH Secure Shell — remote command-line access and file transfer (SCP/SFTP). One of the most attacked ports on the internet; bots continuously attempt brute-force SSH logins.
Should be publicly accessible? Only to trusted IPs when possible. Restrict SSH access via firewall to known IP ranges (your office, VPN, specific management hosts). If public SSH is unavoidable, use key-based authentication only and disable password authentication.
Port 3389 — RDP (Remote Desktop Protocol) Windows remote desktop. Similarly under constant brute-force attack.
Should be publicly accessible? No — firewall to trusted IPs only, or access via VPN.
Web services
Port 80 — HTTP Unencrypted web traffic. Should typically be open publicly but redirect all traffic to HTTPS.
Port 443 — HTTPS Encrypted web traffic. Should be open publicly on web servers.
Port 8080 — Alternative HTTP Commonly used for development servers, reverse proxy upstreams, and application servers (Tomcat, Gunicorn). Should not be publicly accessible on production servers — proxy through port 80/443 via nginx/Apache.
Port 8443 — Alternative HTTPS Similar to 8080 but for HTTPS. Same principle: internal only.
Port 25 — SMTP Mail transfer between servers. Required open for incoming email delivery (mail servers must be reachable on port 25). Outbound connections on port 25 are blocked by most residential ISPs and many cloud providers to prevent spam from compromised servers.
Port 587 — SMTP Submission (STARTTLS) For email client submission with authentication and encryption. Your email client uses this to send mail through your mail server. Should be firewalled to authenticated connections.
Port 465 — SMTPS (implicit TLS) An older mail submission port now reinstated for implicit TLS submission.
Port 993 — IMAPS (IMAP over SSL) Encrypted incoming email retrieval. Open for mail users.
Port 995 — POP3S Encrypted POP3 email retrieval. Less common than IMAP.
DNS
Port 53 — DNS (UDP and TCP) DNS queries typically use UDP. TCP is used for large responses and zone transfers. Authoritative DNS servers need port 53 open publicly. Recursive resolvers used internally should not be publicly accessible.
Common misconfiguration: open recursive DNS resolvers (port 53 accepting queries from any IP) are abused for DNS amplification DDoS attacks. Recursive resolvers should only accept queries from trusted networks.
Databases
Port 3306 — MySQL/MariaDB Port 5432 — PostgreSQL Port 1433 — Microsoft SQL Server Port 1521 — Oracle Database
Should any be publicly accessible? Almost never. Databases should only be accessible from the application server (same network or VPC). Exposing database ports to the internet is one of the most common and consequential server misconfigurations. Shodan, a search engine for internet-connected devices, continuously indexes open database ports — and attackers actively exploit them.
If remote database access is necessary, tunnel over SSH rather than exposing the port directly.
Caching and message queues
Port 6379 — Redis Port 11211 — Memcached Port 5672 — RabbitMQ (AMQP) Port 9092 — Apache Kafka
Should any be publicly accessible? No. These services are internal infrastructure. Redis and Memcached in particular default to no authentication — an open port means unauthenticated access to all cached data.
Memcached on port 11211 open to the internet was the vector for one of the largest DDoS attacks ever recorded (GitHub attack, 2018) — UDP reflection amplification from open Memcached servers.
Monitoring and admin
Port 9090 — Prometheus Port 3000 — Grafana (default) Port 8161 — ActiveMQ admin console Port 15672 — RabbitMQ management UI Port 9200 / 9300 — Elasticsearch
Should be publicly accessible? No. Monitoring and admin interfaces should be behind VPN or IP restriction. Open Elasticsearch instances have caused numerous significant data breaches — the database accepts unauthenticated API requests by default.
Development and containers
Port 2375 / 2376 — Docker daemon Docker's unencrypted (2375) and TLS-encrypted (2376) API ports. Port 2375 open to the internet gives anyone full control over Docker on that host — one of the most dangerous misconfigurations possible.
Port 5000 — Docker registry (default) Port 6443 — Kubernetes API server
None of these should be publicly accessible without strict authentication and restriction.
How to interpret port scan results
Open
The port is listening and accepted the connection. A service is running.
Closed
The port responded with a TCP RST (reset). No service is listening, but the host is reachable and the firewall is allowing the probe to reach the host.
Filtered
No response (timeout). The firewall is silently dropping the probe. From a security standpoint, this is better than "closed" — it doesn't confirm the host exists or that the port number is relevant.
How to use the Port Scanner on sadiqbd.com
- Enter the hostname or IP address
- Select ports to scan — common ports scan, specific port, or a range
- Run the scan — the tool attempts TCP connections and reports open/closed/filtered status
- Review results — any open port that shouldn't be public warrants immediate investigation
Frequently Asked Questions
Is port scanning legal? Scanning your own systems: always legal. Scanning systems you have permission to test (pentesting engagements): legal with written authorisation. Scanning arbitrary third-party systems without permission: illegal in most jurisdictions and a violation of service terms for cloud providers. Always scan only systems you own or have explicit authorisation to test.
Should I run a port scan on my own server regularly? Yes — periodically, and after any configuration changes. It's easy to accidentally open a port during software installation or service configuration. Regular scans catch unintended exposures before attackers do.
What should I do if I find an unexpected open port?
Identify the service bound to it (ss -tlnp or netstat -tlnp on Linux), determine if it's intentional, and either restrict it via firewall rules or stop the service if it's not needed.
Is the Port Scanner free? Yes — completely free, no sign-up required.
The difference between a secure server and a compromised one often comes down to a single misconfigured firewall rule leaving a database or cache service exposed. Regular port scans are one of the most straightforward security checks available.
Try the Port Scanner free at sadiqbd.com — check which ports are open on any host and identify unexpected exposures instantly.
