Every server connected to the public internet exposes network ports to receive traffic. While web servers intentionally listen on HTTP (port 80) and HTTPS (port 443), misconfigurations often leave database, administrative, and debugging ports exposed to automated scans and malicious actors.

Regular port auditing helps you maintain an accurate inventory of listening services, identify unintentional exposure, and verify that firewall rules are operating as intended.

This guide explains how port scanning works, which ports require immediate attention, and how to audit your attack surface using an Nmap security scan and an online port checker.

How port scanning works under the hood

When a client communicates with a server over TCP (Transmission Control Protocol), it initiates a three-way handshake:

1. SYN: The client sends a synchronize packet to a specific port.
2. SYN-ACK: If the port is open and listening, the server responds with a synchronize-acknowledgment packet.
3. ACK: The client sends an acknowledgment packet to establish the connection.

Port scanners use variations of this handshake to determine the state of remote ports:

• TCP Connect Scan: Completes the full three-way handshake. Highly reliable and works across all network environments without requiring privileged raw socket access.
• TCP SYN (Stealth) Scan: Sends a SYN packet and waits for SYN-ACK, but immediately responds with an RST (reset) packet instead of completing the handshake. This determines port status quickly while minimizing connection overhead.
• Service Version Detection: Once a port is identified as open, the scanner sends protocol-specific probes (such as HTTP GET, SSH identification strings, or SMTP HELO) to determine the exact software name, daemon version, and operating system banner.

Understanding port states

When you run a port scan, each audited port returns one of three fundamental states:

Port State	Technical Meaning	Security Implication
Open	An application is actively accepting TCP connections on this port.	Service is reachable from the internet. Verify authentication and patch level.
Closed	The host received the packet and replied with an RST packet; no application is listening.	No active service, but host is confirmed reachable.
Filtered	No response was received (packet dropped) or an ICMP unreachable error was returned.	A firewall or packet filter is actively blocking traffic.

A filtered state is the ideal posture for all administrative and internal services on the public internet.

High-risk ports to audit and protect

Below are the most common standard ports encountered during infrastructure audits, categorized by their exposure risk:

1. Web and application ports

• Port 80 (HTTP) & Port 443 (HTTPS): Intended for public access. Ensure port 80 automatically redirects to port 443 with HSTS (HTTP Strict Transport Security) enabled.
• Port 8080, 8443, 8000, 3000, 5000: Common alternate ports for development servers, staging environments, and admin dashboards (e.g., Jenkins, Grafana, Traefik). These should never remain exposed without reverse proxy authentication.

2. Remote management ports

• Port 22 (SSH): Essential for server administration, but targeted by relentless brute-force attacks. Disable password authentication in /etc/ssh/sshd_config (PasswordAuthentication no), use ED25519 SSH keys, configure fail2ban, and restrict access to trusted IP ranges or a VPN.
• Port 3389 (RDP - Remote Desktop): High-risk target for ransomware campaigns. Never expose RDP directly to the public internet; require an SSH tunnel, WireGuard, or Cloudflare Access tunnel.
• Port 21 (FTP) & Port 23 (Telnet): Legacy protocols that transmit credentials in cleartext. Replace completely with SFTP/SSH.

3. Database ports (Critical Risk)

Databases should never listen on public interfaces unless strict firewall IP allowlisting is enforced.

• Port 3306 (MySQL / MariaDB)
• Port 5432 (PostgreSQL)
• Port 27017 (MongoDB)
• Port 6379 (Redis)
• Port 9200 (Elasticsearch)

Unprotected Redis and MongoDB instances without authentication are frequently targeted by automated ransomware bots that wipe data within minutes of exposure.

# Verify which services are listening locally on your Linux server
sudo ss -tulpn

Ensure database configuration files bind exclusively to 127.0.0.1 or internal private network interfaces (e.g., bind-address = 127.0.0.1 in MySQL).

How to conduct a network security audit

Step 1: Check individual critical ports

For rapid checks on specific services (such as verifying whether your SSH port change took effect or whether your mail server is answering), use the PingXD Port Checker. Enter your domain or public IP and select the target port.

Step 2: Run a comprehensive Nmap scan

To discover all running services and their fingerprint versions, execute an Nmap security scan. You can choose between:

1. Quick Scan: Audits the top standard ports for rapid exposure detection.
2. Full Scan: Probes standard and extended ranges to identify obscure services and alternate HTTP ports.
3. Custom Scan: Focuses on specific port combinations relevant to your application architecture.

Step 3: Implement defense-in-depth

Once you identify exposed ports, apply a strict firewall baseline using UFW (Uncomplicated Firewall) on Ubuntu/Debian:

# Default policy: block all incoming, allow all outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow only standard web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Restrict SSH to a specific management IP (e.g. 203.0.113.50)
sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

# Enable firewall
sudo ufw enable

Monitoring your infrastructure regularly

Network configurations change frequently during software deployments, container port bindings (e.g., Docker published ports bypassing default firewall tables), and cloud security group modifications.

Incorporate periodic port scans and ping latency tests into your monthly maintenance routine to ensure your attack surface remains strictly locked down.