Port Scanning Explained: Find Open Ports on Your Network

Every server connected to the internet communicates through ports. Think of ports like numbered doors on a building. Port 80 is the door for web traffic (HTTP). Port 443 is the door for encrypted web traffic (HTTPS). Port 22 is the door for SSH connections. Port 3306 is the door for MySQL database connections.

A port scanner checks which of these doors are open, closed, or filtered. When you scan your own server, you see exactly which services are exposed to the internet. This is the foundation of network security: you cannot protect what you do not know is exposed.

A port scanner lets you check the status of common ports on any server. Enter an IP address or domain, and it shows you which ports are responding. If you see a port open that you did not expect, that is either a misconfiguration or a service you forgot about. Both deserve your attention. The IP Address Lookup tool helps you confirm which server you are about to scan.

What Open, Closed, and Filtered Ports Actually Mean

Port scanners report three states for each port they check:

Open: A service is actively listening on this port and accepting connections. This is expected for services you intentionally run (web server on port 443, SSH on port 22). It is a concern for services you did not intend to expose (database on port 3306, admin panel on port 8080).

Closed: No service is listening on this port. The port responds to connection attempts with a rejection. This is the default state for unused ports and is generally fine. The server is reachable, but nothing is running on that specific port.

Filtered: The port does not respond at all. A firewall or packet filter is silently dropping the connection attempt. This is the most secure state for ports you do not use, because the scanner cannot even confirm whether the port exists. Many security professionals configure firewalls to filter rather than close unused ports, because filtered ports give attackers less information.

When you scan your own server, you want to see: the ports you intentionally use as "open," everything else as "filtered" (firewall dropping the packets), and ideally nothing as "closed" (because that confirms the server is there). Use the IP Address Lookup to confirm you are scanning the right server before interpreting results.

Common Ports and What They Run

Knowing which services use which ports helps you interpret scan results:

Port 22 (SSH): Secure Shell, used for remote command-line access to servers. If this is open, someone can attempt to log in to your server. Protect it with key-based authentication, disable password login, and consider moving it to a non-standard port to reduce automated attack traffic.

Port 80 (HTTP) and 443 (HTTPS): Web traffic. Port 80 should redirect to 443 for encrypted connections. Both should be open if you are running a web server. If you are not running a web server and these are open, something unexpected is listening.

Port 3306 (MySQL) and 5432 (PostgreSQL): Database ports. These should almost never be open to the internet. Databases should only accept connections from your application server, not from the public internet. If a port scanner shows these as open on a public IP, you have a critical security issue.

Port 6379 (Redis): In-memory data store. Exposed Redis instances are one of the most common security breaches on the internet. Redis has no authentication by default, so an open port 6379 is an invitation for anyone to read and write your cached data.

Port 8080 and 8443: Common alternative ports for web applications, admin panels, and development servers. These are frequently left open accidentally when developers deploy staging environments.

Run a WHOIS Lookup alongside your port scan to verify that the domain resolves to the IP you expect. Scanning the wrong server gives you irrelevant results.

How Attackers Use Port Scanning

Port scanning is the first step in most targeted attacks. Before an attacker tries to exploit a vulnerability, they need to know what services are running and on which ports. This is called reconnaissance.

The process typically looks like this:

1. The attacker identifies a target IP range (a company's server block, a cloud provider's subnet).
2. They run a fast scan across common ports to find live servers.
3. For each live server, they do a deeper scan to identify all open ports.
4. For each open port, they probe the service to identify the software and version (this is called banner grabbing or service fingerprinting).
5. They look up known vulnerabilities for the identified software versions.
6. They attempt to exploit those vulnerabilities.

The key insight is that every open port is an attack surface. A web server running Nginx on port 443 is an attack surface. SSH on port 22 is an attack surface. A forgotten Jenkins instance on port 8080 is an attack surface that is much easier to exploit because Jenkins has had numerous severe vulnerabilities over the years.

This is why regular port scanning of your own infrastructure matters. You want to see what an attacker would see. If you find services you did not know were running, shut them down or firewall them before someone else finds them.

Securing Your Server: Practical Steps

After running a port scan, here is how to act on the results:

Close unnecessary ports. If a service does not need to be accessible from the internet, stop the service or block the port with a firewall. On Linux, use ufw (Uncomplicated Firewall) or iptables. On cloud providers, use security groups (AWS), firewall rules (GCP), or network security groups (Azure).

Use a firewall whitelist approach. Instead of blocking individual ports, block everything by default and only allow the specific ports you need. This is safer because new services you install will not accidentally be exposed.

Move SSH to a non-standard port. Changing SSH from port 22 to something like 2222 or 4822 does not improve security against targeted attacks, but it sharply reduces automated brute-force attempts from bots that scan port 22 across the entire internet.

Restrict database access. Your database should only accept connections from your application server's IP address. Configure this in both the database configuration and the firewall. There is no legitimate reason for a database to accept connections from the public internet.

Monitor for changes. Run a port scan weekly or after any infrastructure changes. Set up alerts if a new port opens unexpectedly. Services like Shodan and Censys continuously scan the internet and can notify you if your server's exposure changes.

Keep software updated. An open port running patched software is dramatically safer than an open port running software with known vulnerabilities. Automated security updates for OS packages and timely application updates are your first line of defense.

Legal and Ethical Considerations

Port scanning your own servers is legal and routine. Port scanning someone else's servers without permission is a legal gray area that varies by jurisdiction.

In most countries, a simple port scan (checking which ports are open) is not illegal by itself. However, aggressive scanning patterns (scanning thousands of ports rapidly, attempting service exploitation after scanning) can be considered unauthorized access attempts under laws like the US Computer Fraud and Abuse Act (CFAA) or the UK Computer Misuse Act.

Practical guidelines:

Always get permission. If you are scanning a client's server, get written authorization first. A simple email confirming the scope and timing of the scan protects both parties.

Scan only what you own or have authorization for. Your servers, your cloud instances, your network. Not your competitor's, not your neighbor's, not random IPs on the internet.

Use responsible scan rates. Sending millions of packets per second can trigger DDoS protection systems and may disrupt the target's services. Even on your own servers, pace your scans reasonably.

Document your scans. Keep records of what you scanned, when, and why. If your ISP or cloud provider asks about the traffic, you can explain it was authorized security testing.

Bug bounty programs are the exception. Many companies (Google, Facebook, HackerOne clients) explicitly invite external security testing within defined scopes. If a company has a bug bounty program, their scope document tells you what you are allowed to scan.

FAQ

Is it normal for some ports to be open on my server?

Yes. Any server running web services will have ports 80 and 443 open. If you use SSH for remote access, port 22 will be open. The concern is not that ports are open, but that unexpected or unnecessary ports are open. Audit your open ports against the services you intentionally run.

Can a port scanner detect all services running on my server?

A standard port scan checks the most common ports (typically the top 1,000 or all 65,535 ports). Services running on non-standard ports may be missed by a quick scan. A comprehensive scan checks all ports but takes longer. Services using non-TCP protocols (UDP) require a separate scan type.

Will port scanning my own server trigger any alerts?

It might. If you use a cloud provider like AWS or GCP, their monitoring systems may flag port scanning activity from your IP. Your ISP might also notice. This is usually not a problem if you are scanning your own infrastructure, but having documentation of your authorization avoids potential account issues.

How often should I scan my servers?

At minimum, scan after every infrastructure change (new server, new service, firewall rule change). Ideally, run automated weekly scans and compare results against a known baseline. Any deviation from the baseline triggers an investigation.