How to Scan Open Ports and Audit Your Server's Network Security

The Open Port Attack Surface: Understanding the Risk

Every open port on a server represents a listening service — software actively waiting for incoming network connections. Each listening service is a potential attack vector. If that service has unpatched vulnerabilities, weak authentication, default credentials, or a misconfiguration, an attacker who discovers the open port can exploit it. The frightening reality of modern internet security: automated port scanning tools can scan the entire IPv4 address space — all 4 billion+ addresses — in under six minutes using tools like Masscan. Your server will be scanned, probably multiple times per day, regardless of how obscure you believe your IP address to be.

Security through obscurity — believing that attackers won't find your server — is not a security strategy. Every exposed port on a publicly routable IP address will be discovered, probed for known vulnerabilities, and subjected to brute-force authentication attempts. The only effective strategy is explicitly closing every port that isn't required, and securing every port that must remain open.

Critical High-Risk Ports: Audit These First

Certain ports represent such consistently high risk that they should be considered emergency-priority to review if found exposed:

• Port 22 (SSH): SSH is the most attacked port on the internet. Every exposed SSH server receives continuous automated brute-force attempts. SSH must never use password authentication — only key-based authentication. Additionally: change the default port (from 22 to a non-standard port) to reduce automated scanning noise, configure fail2ban to block IPs after repeated failed attempts, disable root login, and restrict access to specific source IP ranges where possible.
• Port 3306 (MySQL) / 5432 (PostgreSQL) / 27017 (MongoDB) / 6379 (Redis): Database ports should never be exposed to the public internet. Period. All database connections should go through the application layer running on the same server or within a private network. Redis, famously, has no authentication by default — exposed Redis instances have been used to install cryptocurrency miners and backdoors on thousands of servers. MongoDB's default configuration also lacks authentication. If you find any database port exposed publicly, treat it as a critical security incident requiring immediate remediation.
• Port 3389 (RDP — Windows Remote Desktop): Exposed RDP is one of the primary ransomware entry points globally. Attackers continuously scan for open RDP ports and brute-force credentials. RDP must be restricted to VPN-only access or specific IP ranges — never exposed directly to the internet without additional security controls.
• Port 21 (FTP): Unencrypted file transfer protocol — credentials and data transmitted in plaintext. Should be completely replaced with SFTP (runs over SSH on port 22) or FTPS (FTP with TLS encryption). No modern application should use plain FTP.
• Port 23 (Telnet): Unencrypted remote shell access — everything including passwords transmitted in plaintext. Should have been decommissioned decades ago. If you find Telnet running on a production server in 2026, that is an emergency requiring immediate remediation.
• Port 2375/2376 (Docker API): Exposed Docker API provides full control over the container environment — creating containers, mounting filesystems, executing arbitrary commands inside containers, and potentially escaping to the host. Must never be internet-facing. If you need remote Docker management, use SSH tunneling.
• Port 8080/8443/8888 (Development and Admin Interfaces): Development servers, admin dashboards, Jupyter notebooks, and similar tools frequently run on these ports. Often deployed for convenience without authentication in development environments and accidentally left exposed in production.
• Port 9200/9300 (Elasticsearch): Elasticsearch has no authentication by default (without X-Pack security). Hundreds of millions of records have been exposed and deleted by attackers targeting open Elasticsearch instances. Never expose Elasticsearch to the public internet without authentication.

Port Scanning Methodology: Seeing Your Server as an Attacker Does

The most useful security audit perspective is that of an external attacker with no prior knowledge of your infrastructure. A proper port scan from an external perspective reveals exactly what an attacker would discover:

1. Identify your public IP addresses. Include all IP addresses your domain resolves to, any additional IPs registered to your organization, and any IP addresses your subdomains resolve to. Use nslookup, dig, or an IP auditor tool to compile the complete list.
2. Scan the full port range. Port numbers run from 0 to 65535. While scanning all 65535 ports takes longer, it's essential — attackers routinely scan non-standard ports for services moved to avoid detection. At minimum, scan ports 1-10000 plus common high-number ports (27017, 50000, 54321, etc.).
3. Perform service version detection. An open port alone tells you little — you need to know what software is running and what version. Version information enables cross-referencing with CVE databases to identify unpatched vulnerabilities. Nmap's -sV flag performs version detection.
4. Cross-reference versions against CVE databases. Once you know the service name and version, check the National Vulnerability Database (nvd.nist.gov) and CVE databases for known vulnerabilities. Unpatched software with known CVEs is immediately exploitable using publicly available proof-of-concept code.
5. Document your findings as a baseline. The current state of your port exposure is your security baseline. Any new open port discovered in a future scan represents a change that needs to be explained and authorized.

Firewall Configuration: The Principle of Least Exposure

The foundational principle of network security is least exposure: expose the minimum set of ports necessary for your application to function, and restrict remaining ports to the minimum set of source IP addresses that legitimately need access. A properly configured firewall operates on a default-deny basis for inbound connections:

• Default policy: DROP all inbound traffic. Unless explicitly permitted by a firewall rule, all inbound connection attempts are silently dropped. Rejected packets (RST responses) are preferable to ignored packets for legitimate troubleshooting, but DROP is more secure as it doesn't confirm the host exists.
• Public internet access: Typically only ports 80 (HTTP) and 443 (HTTPS) should be accessible from any source IP. Everything else should be restricted.
• SSH restriction: Restrict SSH access to specific source IP addresses — your office IP range, your development machines, your VPN exit nodes. If you work from variable locations, require VPN connection before SSH is accessible.
• Database isolation: Database ports accessible only from the application server's specific private IP address. Not from 0.0.0.0/0, not from your office IP — only from the specific machine that runs your application server.
• Monitoring and alerting: Any new open port appearing in your infrastructure should trigger an immediate security alert. Automated weekly port scans compared against your approved baseline will catch unauthorized service exposure before attackers exploit it.

Service Version Management and Patch Strategy

Discovering an exposed port leads immediately to service version assessment. Services running software versions with known CVEs are priority-one security risks — exploit code for known CVEs is often publicly available and used by automated scanning tools within days of public disclosure. A practical vulnerability management workflow:

• Subscribe to security advisory mailing lists for all software you run (Apache, Nginx, OpenSSH, PostgreSQL, etc.)
• Enable automatic security updates for OS-level packages where your testing process supports it
• Implement a defined patch SLA based on severity: Critical CVEs patched within 24-48 hours, High within 7 days, Medium within 30 days
• Run regular automated vulnerability scans against your infrastructure that cross-reference service versions against CVE databases
• Include port scanning in your CI/CD pipeline to catch new service exposure introduced by deployment changes

Cloud Provider Security Group Configuration

For servers hosted on AWS, Google Cloud, Azure, or similar providers, network-level security is implemented through security groups or firewall rules at the cloud provider level — separate from and in addition to OS-level firewall configuration. Cloud security groups should be configured with the same least-exposure principle: only explicitly permitted traffic is allowed, and permitted traffic is restricted to the minimum necessary source IP ranges. Common misconfiguration: security groups configured with 0.0.0.0/0 (all IP addresses) for SSH during initial setup and never restricted afterwards. Regular security group audits should be part of standard cloud infrastructure maintenance.