The Guide to Open Ports: Common Port Numbers, Security Risks, and Firewall Auditing

Every computer or virtual machine connected to the internet communicates through network ports. Think of an IP address as a large office building's street address, and network ports as individual numbered office suites inside that building. Mail arrives at the building, but it must be delivered to a specific suite number to reach the correct recipient.

While web services must expose port 80 (HTTP) and port 443 (HTTPS) so visitors can load web pages, exposing other ports—especially database, caching, or remote administration interfaces—creates dangerous entry points for automated vulnerability scanners, brute-force bots, and ransomware operators.

According to cybersecurity threat intelligence telemetry, malicious scanners can detect an exposed port on an IPv4 address within minutes of a server going live.

This guide provides an exhaustive reference to standard network ports, explains the security risks of exposing sensitive services, and details how to audit your perimeter using an online port checker and Nmap security scan.

How network ports work: Ranges and protocols

Network ports are 16-bit unsigned integers ranging from 0 to 65,535. The Internet Assigned Numbers Authority (IANA) divides this number space into three distinct categories:

1. Well-Known Ports (0 – 1023): Reserved for foundational system-level services and standard internet protocols (e.g., HTTP, HTTPS, SSH, DNS, SMTP). On Unix-like systems, binding to a well-known port historically requires root or administrative privileges (CAP_NET_BIND_SERVICE).
2. Registered Ports (1024 – 49151): Assigned to specific user processes, third-party databases, application servers, and microservices (e.g., MySQL on 3306, PostgreSQL on 5432, Redis on 6379).
3. Dynamic / Private / Ephemeral Ports (49152 – 65535): Allocated dynamically by the operating system kernel for outbound client connections. When your browser opens a socket to load a website, the OS assigns a temporary ephemeral port as the source port.

TCP vs. UDP ports

Services communicate over either TCP (Transmission Control Protocol) or UDP (User Datagram Protocol):

• TCP ports require a reliable, connection-oriented three-way handshake (SYN, SYN-ACK, ACK). Most application protocols (HTTP, SSH, MySQL, TLS) run over TCP.
• UDP ports are connectionless and stateless. Packets are dispatched without acknowledgment or sequence tracking. DNS (port 53), DHCP (ports 67/68), NTP (port 123), and modern HTTP/3 over QUIC (port 443) use UDP.

Essential reference table: 20 common ports and their exposure rules

Use this reference table to evaluate which ports are safe to expose on public-facing internet interfaces:

Port	Protocol	Default Service	Intended Use Case	Internet Exposure Recommendation
21	TCP	FTP	File Transfer Protocol (unencrypted)	Prohibited. Plaintext credentials. Use SFTP (port 22) instead.
22	TCP	SSH / SFTP	Secure Shell administration	Restricted. Never expose with password auth; use keys, fail2ban, or VPN.
23	TCP	Telnet	Unencrypted remote command line	Prohibited. Transmits passwords in cleartext over the wire.
25	TCP	SMTP	Simple Mail Transfer Protocol	Restricted. Mail servers only; prone to open-relay exploitation.
53	TCP/UDP	DNS	Domain Name System queries	Public (if running authoritative DNS); Restricted for recursors.
80	TCP	HTTP	Unencrypted web traffic	Public. Redirect immediately to HTTPS via 301.
110	TCP	POP3	Post Office Protocol email retrieval	Prohibited. Plaintext. Use POP3S (port 995) instead.
143	TCP	IMAP	Internet Message Access Protocol	Prohibited. Plaintext. Use IMAPS (port 993) instead.
443	TCP/UDP	HTTPS / HTTP/3	Encrypted web traffic (TLS / QUIC)	Public Required. The universal standard for web security.
445	TCP	SMB	Windows Server Message Block file share	Strictly Prohibited. Primary vector for WannaCry/EternalBlue ransomware.
993	TCP	IMAPS	IMAP over TLS	Restricted to mail clients.
995	TCP	POP3S	POP3 over TLS	Restricted to mail clients.
1433	TCP	MS SQL Server	Microsoft SQL Server database	Prohibited. Internal VPC or VPN access only.
3306	TCP	MySQL / MariaDB	Relational database engine	Prohibited. Should bind to 127.0.0.1 or private subnet.
3389	TCP/UDP	RDP	Windows Remote Desktop Protocol	Strictly Prohibited. Major target for automated ransomware brute-forcing.
5432	TCP	PostgreSQL	Relational database engine	Prohibited. Never expose directly to 0.0.0.0.
6379	TCP	Redis	In-memory key-value data store	Strictly Prohibited. Default configuration has no authentication.
8080	TCP	HTTP-Alt	Development web servers / proxies	Restricted. Avoid leaving test environments accessible online.
9200	TCP	Elasticsearch	Search and analytics engine	Strictly Prohibited. Massively targeted for automated data wiping.
27017	TCP	MongoDB	Document database	Strictly Prohibited. Frequently compromised by ransom botnets.

Top 4 critical port exposure vulnerabilities

1. The exposed in-memory cache disaster (Redis & Memcached)

By default, Redis (port 6379) and Memcached (port 11211) were historically engineered for trusted private LANs and shipped with authentication disabled.

When developers deploy Redis to a public cloud instance and bind the service to 0.0.0.0, any internet user can connect without a password, flush the entire dataset, read sensitive API keys, or even exploit Redis configuration commands to overwrite SSH authorized_keys files on the host OS to gain root remote code execution.

Remediation: Ensure /etc/redis/redis.conf contains:

bind 127.0.0.1 ::1
protected-mode yes
requirepass "SuperStrongGeneratedSecretPassphraseHere"

2. Publicly accessible database ports (MySQL, PostgreSQL, MongoDB)

Exposing database ports (3306, 5432, 27017) to the public internet invites continuous dictionary attacks against administrative accounts (e.g., root or postgres). Furthermore, unpatched buffer overflows or SQL injection vulnerabilities in older database daemons can be triggered without requiring network perimeter traversal.

Remediation: Application servers and database instances should communicate exclusively across a private Virtual Private Cloud (VPC) subnet or over encrypted overlay networks like WireGuard or Tailscale.

3. Exposed remote desktop (RDP 3389)

Remote Desktop Protocol (port 3389) is the #1 vector cited by incident response firms for enterprise ransomware infections. Threat actors continuously scan public IP ranges for open 3389 ports and execute automated password spraying attacks against Active Directory user accounts.

Remediation: Disable public RDP immediately. Access Windows servers via Azure Bastion, AWS Systems Manager Session Manager, or behind an authenticated VPN.

4. Development and staging ports left open on production hosts

During debugging, developers frequently start Node.js, Next.js, or Vite dev servers on ports 3000, 5173, or 8080. When bound to 0.0.0.0 instead of localhost, internal debugging routes, database seeds, and environment variables become visible to the outside world.

Understanding port states: Open vs. Closed vs. Filtered

When scanning a target with an online port check or Nmap scan, each inspected port returns one of three states:

1. Open

The target server received the connection packet (TCP SYN) and an application daemon actively listening on that port responded with a TCP SYN-ACK packet. The port is actively accepting connections.

2. Closed

The target server received the TCP SYN packet, but no software application is listening on that port. The operating system kernel responded with an immediate TCP RST (Reset) packet. The host is online and reachable, but the specific port is inactive.

3. Filtered (The Ideal Security State)

The probe packet was dropped silently by an intermediary firewall, security group, or packet filter, or the firewall returned an ICMP type 3 code (Destination Unreachable). The scanner cannot determine whether an application is listening because the packet never reached the OS network stack.

Security Rule: All administrative and internal ports (SSH, RDP, databases, metrics endpoints) should show as Filtered from the public internet.

How to audit your servers with PingXD

Auditing your infrastructure from an external vantage point is the only way to see what an attacker or automated scanner sees.

1. Verify specific critical ports: Use the PingXD Port Checker to quickly verify whether high-risk ports (such as 22, 3306, 5432, 6379, or 8080) are open, closed, or properly filtered on your domain or IP.
2. Perform deep reconnaissance: Run an Nmap security scan to identify running daemon versions, banner disclosures, and service signatures.
3. Inspect your IP and ASN perimeter: Use the IP info tool to verify your server's autonomous system, ISP transit provider, and public geolocation.

Firewall hardening: The "Default Deny" posture

The cornerstone of modern network defense is adopting a Default Deny inbound posture.

Hardening with UFW (Uncomplicated Firewall on Ubuntu/Debian)

# 1. Reset rules and enforce default deny
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. Allow only essential web traffic
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# 3. Restrict SSH to a specific trusted office or VPN IP
sudo ufw allow from 203.0.113.50 to any port 22 proto tcp comment 'Trusted SSH'

# 4. Enable the firewall
sudo ufw enable
sudo ufw status verbose

AWS / Cloud Security Group Best Practices

1. Never create an inbound rule allowing 0.0.0.0/0 on any port other than 80 (HTTP) and 443 (HTTPS).
2. For database security groups, set the Source to the security group ID of your application servers (sg-xxxxxx), never an IP address range.
3. Implement a Cloudflare Tunnel or AWS ALB in front of web instances so your origin VM's public IP does not need to expose any ports directly to the wild.