How to Scan for Open Ports Online

Checking for open ports is one of the first steps in any security assessment. An open port means a service is listening for connections -- and if that service should not be publicly accessible, you have a problem. Whether you are verifying that a firewall rule took effect, checking that a database port is not exposed after a deployment, or running a full network audit, the process starts with knowing what is open.

This guide covers practical methods for scanning ports: from quick browser-based checks to comprehensive command-line scans using Nmap, including how to interpret results and act on what you find.

Quick Check: Using an Online Port Scanner

If you need to check a few specific ports quickly -- for example, verifying that port 3306 is not exposed on your production database server -- a browser-based tool is the fastest path.

Metric Tower's online port checker lets you enter a hostname or IP address and one or more port numbers. It performs a TCP connection test from Metric Tower's servers and reports whether each port is open, closed, or filtered. No installation, no command line, no account required.

Online port scanners are useful for quick, targeted checks. They answer the question "is port X reachable from the internet?" in seconds. But they have limitations:

• They scan from their own IP, not yours -- useful for testing external exposure but not internal network access.
• They typically support a limited number of ports per request (Metric Tower's tool checks up to 20 at once).
• They do not perform service detection or version identification.

For anything beyond a quick spot-check, you need a proper scanning tool.

Scanning with Nmap: The Complete Guide

Nmap (Network Mapper) is the most widely used port scanning tool in the world. It is free, open-source, and available on every major operating system. If you do any kind of security work, you should know how to use it.

Installing Nmap

# macOS (Homebrew)
brew install nmap

# Debian/Ubuntu
sudo apt install nmap

# CentOS/RHEL
sudo yum install nmap

# Windows - download from nmap.org/download

Basic Port Scan

The simplest Nmap scan checks the 1,000 most common ports on a target:

# Scan common ports
nmap example.com

# Scan specific ports
nmap -p 22,80,443,3306,5432 example.com

# Scan a port range
nmap -p 1-1000 example.com

# Scan ALL ports (1-65535)
nmap -p- example.com

The -p- flag scans all 65,535 ports. This is thorough but slow -- a full scan can take 5-15 minutes depending on the target and network conditions. For a first pass, the default 1,000 ports usually covers the important services.

Service and Version Detection

Knowing that port 8080 is open is useful. Knowing that port 8080 is running Apache Tomcat 9.0.46 is actionable -- you can immediately check whether that version has known vulnerabilities.

# Service detection
nmap -sV example.com

# Service detection with OS fingerprinting
nmap -sV -O example.com

# Aggressive scan (service detection + OS + scripts + traceroute)
nmap -A example.com

The -sV flag probes open ports to determine what service and version are running. This works by sending specific probe strings and matching responses against Nmap's service fingerprint database.

Vulnerability Detection Scripts

Nmap's Scripting Engine (NSE) extends port scanning into vulnerability detection. With the --script flag, you can run scripts that check for specific vulnerabilities, default credentials, SSL/TLS misconfigurations, and more.

# Run vulnerability detection scripts
nmap --script=vuln example.com

# Check SSL/TLS configuration
nmap --script=ssl-enum-ciphers -p 443 example.com

# Check for specific CVEs
nmap --script=http-vuln-* example.com

# Combine service detection with vulnerability scripts
nmap -sV --script=vuln example.com

Saving Scan Results

Always save scan results for comparison and documentation:

# Save as XML (machine-readable)
nmap -sV -oX scan-results.xml example.com

# Save as "greppable" format
nmap -sV -oG scan-results.gnmap example.com

# Save in all formats simultaneously
nmap -sV -oA scan-results example.com

Interpreting Scan Results

A typical Nmap output looks something like this:

PORT     STATE    SERVICE   VERSION
22/tcp   open     ssh       OpenSSH 9.6 (protocol 2.0)
80/tcp   open     http      nginx 1.25.3
443/tcp  open     ssl/http  nginx 1.25.3
3306/tcp filtered mysql
8080/tcp open     http      Apache Tomcat 9.0.85

Interpreting this result:

• Port 22 (SSH) -- Open and running OpenSSH 9.6. Verify that password authentication is disabled and only key-based auth is permitted.
• Ports 80 and 443 (HTTP/HTTPS) -- Open with Nginx 1.25.3. Verify that port 80 redirects to 443 (HTTPS). Check that the TLS configuration is strong.
• Port 3306 (MySQL) -- Filtered, meaning a firewall is blocking access. This is the correct behavior -- databases should never be publicly accessible.
• Port 8080 (Tomcat) -- Open and running Apache Tomcat 9.0.85. This is a potential concern. Is this intentional? Is the Tomcat Manager interface exposed? Is this version current?

Common Misconfigurations Found by Port Scanning

Port scans reliably catch several categories of misconfiguration that lead to real-world breaches:

Exposed Database Ports

Databases should never be accessible from the public internet. MySQL (3306), PostgreSQL (5432), MongoDB (27017), and Redis (6379) are frequently found exposed. Redis, in particular, has no authentication by default -- an exposed Redis instance is effectively an open door into your infrastructure.

MongoDB has been the source of thousands of data breaches due to exposed instances running with default configurations.

Management Interfaces

Administrative panels (port 8080, 8443, 9090), management consoles (phpMyAdmin, Adminer, Grafana without auth), and development tools (debug ports, profilers) are frequently left exposed after deployment. These often have weaker authentication than the primary application and provide privileged access.

Legacy Services

FTP (port 21), Telnet (port 23), and unencrypted SMTP (port 25 without STARTTLS) transmit data -- including credentials -- in cleartext. These services should be replaced with their encrypted counterparts (SFTP/SSH, SMTPS) or disabled entirely.

Unnecessary Services

Services that were installed by default or enabled for testing but never removed: SNMP (161), NFS (2049), VNC (5900), and others. Each unnecessary service increases the attack surface without providing value.

Hardening Based on Port Scan Results

Once you know what is open, take action:

1. Close unnecessary ports -- Disable services that are not needed. Remove packages that are not in use. A service that is not running cannot be exploited.
2. Restrict access with firewalls -- Use firewall rules (iptables, security groups, network ACLs) to limit which IPs can reach each port. SSH should only be accessible from your office or VPN. Database ports should only accept connections from application servers.
3. Upgrade outdated services -- If your scan reveals Apache 2.4.49 or OpenSSH 8.2, update them. Version detection maps directly to known CVEs.
4. Enable encryption -- Replace unencrypted services with their TLS equivalents. HTTP should redirect to HTTPS. FTP should be replaced with SFTP.
5. Add authentication -- Services like Redis and MongoDB must have authentication enabled before exposure. Even internal services benefit from authentication in a defense-in-depth model.
6. Monitor continuously -- A port that is closed today might be opened tomorrow by a configuration change or new deployment. Set up recurring scans or use a platform like Metric Tower's integrated Nmap scanner to check regularly.

Scanning Multiple Hosts

Scanning a single host is straightforward. Scanning your entire infrastructure requires planning.

# Scan a subnet
nmap -sV 192.168.1.0/24

# Scan from a target list file
nmap -sV -iL targets.txt

# Scan multiple specific hosts
nmap -sV host1.example.com host2.example.com host3.example.com

# Fast scan: top 100 ports only, skip host discovery
nmap -F -Pn 10.0.0.0/24

When scanning large networks, start with a fast sweep (-F for top 100 ports) to identify live hosts, then run deeper scans on hosts with unexpected open ports. This staged approach saves time and focuses effort where it matters.

Automating Port Scans

Manual port scanning is a good starting point, but for ongoing security, automate it:

• Scheduled scans -- Run weekly or daily scans against your external IP ranges. Compare results against a known-good baseline to detect changes.
• CI/CD integration -- Scan staging environments before promoting to production. Flag builds that expose unexpected ports.
• Alert on changes -- Set up notifications when a new port opens or a known port closes unexpectedly. A port that closes during business hours could indicate a service crash.

Platforms like Metric Tower integrate Nmap and other port scanners (Naabu for fast SYN scanning) into an automated pipeline. You define targets and schedules; the platform runs scans, compares results, and alerts you to changes.

For a foundational understanding of the concepts behind port scanning, read our beginner's guide to port scanning. And to compare the tools available, see our top port scanning tools roundup.