Port Scanning Explained: What Open Ports Actually Reveal About a Server

Somebody scanned your server last night. They scanned it the night before too. And the night before that. Right now, while you are reading this, automated bots are knocking on every port of every IP on the public internet looking for things they can break into.

This is not paranoia. It is just how the internet works. Your server is one of about four billion routable IPv4 addresses, and there are a lot of bored teenagers, security researchers, and full time criminals running scans 24/7. Some are looking for SSH on port 22 with weak passwords. Some are looking for outdated MongoDB instances on port 27017 with no auth. Some are just mapping the internet for fun.

So you should probably understand what a port scan actually is, what the results mean, and how to read them without panicking. Here is the full picture.

What Ports Even Are

A port is a number. That is the whole concept.

When data arrives at your server, the IP address gets the packet to the right machine. But the machine is running multiple programs. Apache is serving a website. SSH is waiting for someone to log in. PostgreSQL is handling database queries. They all share one IP address. So how does the operating system know which program to hand the packet to?

It looks at the port number.

Each TCP and UDP packet has a destination port baked into its header. That number is between 0 and 65535. Apache binds to port 80 and 443. SSH binds to 22. PostgreSQL grabs 5432. When a packet arrives addressed to port 80, the OS routes it to Apache. Done.

Both TCP and UDP have their own separate set of 65,535 ports. So technically your machine has 131,070 possible endpoints if you count both protocols. In practice almost everyone uses only a handful of well known ones plus some random high numbered ones for outgoing connections.

The standardization people at IANA split the port range into three buckets:

When you open a tab in your browser to load a website, your computer assigns a random ephemeral port (say 51234) for the outgoing connection, and the server at the other end is listening on 443. The two endpoints stay paired for the duration of that connection.

How a Port Scan Actually Works

A port scan is just a series of small packets sent to a target machine, one per port, asking "anyone home?" The way the scanner asks and the way the target answers (or does not answer) tells you whether something is running on that port.

Different scan types use different question styles. Each one has tradeoffs in speed, stealth, and accuracy.

TCP SYN scan (the default)

This is the one you probably think of when someone says port scan. The scanner sends a TCP SYN packet, which is the first step of opening a normal TCP connection. Three things can happen:

The target responds with SYN-ACK. That means the port is open. The scanner immediately sends RST to abort the connection before it fully establishes. The target's application layer never sees the connection because it never completed.

The target responds with RST. That means the port is closed. Nothing is listening, but the host itself is reachable.

Nothing happens. The scanner waits, hits a timeout, and reports the port as filtered. Something dropped the packet. Probably a firewall.

SYN scanning is fast because it never completes the handshake. It is also slightly stealthier because the connection never gets logged at the application layer. Apache will not write anything to access.log if you SYN scan port 80. Security teams can still detect it via packet captures or stateful firewall logs.

TCP connect scan

This one completes the full handshake (SYN, then SYN-ACK from target, then ACK from scanner). It is what happens when any normal program connects to a port.

The advantage: it does not need root privileges to run. Any user on any machine can do this, even from a regular shell with bash.

The disadvantage: every successful connection lands in the target's logs as a real connection from your IP. If you are doing a stealth assessment this is bad. If you are debugging your own server it does not matter.

UDP scan

UDP is connectionless, so there is no handshake to abuse. The scanner just sends a UDP packet and waits.

Open UDP ports usually do not respond at all. Closed ones return an ICMP "port unreachable" message. The problem is that ICMP rate limiting on most modern systems means the scanner cannot tell open from filtered for many ports. UDP scanning is slow and produces a lot of false negatives.

This is why most quick port scans only check TCP. If you actually need to find UDP services like DNS (port 53) or DHCP (67/68), you need a slower, more careful UDP scan.

Stealth flag scans (FIN, NULL, XMAS)

These exploit a quirk of the TCP RFC. If you send a packet with weird flags set (or no flags at all) to a closed port, the spec says the system must respond with RST. If you send the same packet to an open port, the system should silently drop it.

The result: closed ports answer back, open ports stay quiet. Inverted from a normal scan.

Why use these? Some old firewalls only block packets with the SYN flag. Sending FIN or NULL packets can sneak past primitive filters. On modern systems with proper stateful firewalls, these scans rarely work and just look weird in logs.

Idle scan (zombie scan)

The most paranoid scan. Instead of sending packets directly from your IP, you spoof packets to make them appear from a third party "zombie" machine that does not know it is helping you. By watching how the zombie's IP ID counter changes, you can infer whether the target's port is open without the target ever seeing your real address.

This requires a zombie host with a predictable IP ID counter, which is increasingly rare in 2026. Most operating systems have randomized IP IDs for years now. Idle scanning is a niche technique mostly seen in CTF challenges and old textbooks.

What "Open" Really Means

Scan tools report results as one of five states. Knowing the difference is the whole point.

A common mistake: people see "open" and freak out. But a port being open is not automatically a vulnerability. SSH on port 22 is open on basically every Linux server in the world. That is fine. The question is whether the service behind the port is configured securely, patched, and authenticated properly.

A port being filtered is interesting too. It means a firewall is doing its job. The attacker cannot tell whether something is running there or not. That is good for you, frustrating for them.

A port being closed with the host up is the most boring result. Nothing there. Move along.

The Ports You Actually Care About

Out of 65,535 possible TCP ports, only a few dozen matter in day to day work. These are the ones you will see most often:

If you scan a server and find ports 22, 80, and 443 open, that is a totally normal web server. If you find 3306 or 27017 open to the internet, you have a serious problem. Database ports should never be reachable from outside your private network.

You can quickly check any specific port on any host using our free port scanner at whatismyip.technology/tools/port-scanner. It does a single TCP connect test, which is enough to tell you if a service is listening or not.

Is Port Scanning Even Legal

Short answer: scanning your own stuff is legal. Scanning random strangers' stuff is murky.

The Computer Fraud and Abuse Act in the US prohibits unauthorized access to a computer system. The grey area is whether sending a SYN packet to someone's port and getting RST back constitutes "access." Most courts have ruled it does not, by itself. But aggressive, sustained scanning that crosses into vulnerability probing has been prosecuted.

Some practical rules:

You can scan your own infrastructure all day. Internal network audits, dev environments, your home router, fine.

You can scan with written authorization. Penetration testing engagements, bug bounty programs with explicit scope, security audits of clients.

You should not scan systems you do not own without permission. Even if it is "just a quick check." Even if it seems harmless. Some courts treat unauthorized scans as access attempts. Some bug bounty programs explicitly forbid out of scope scanning.

GDPR has been argued to apply to port scanning of EU systems because IP addresses can be personal data. Few cases have actually tested this, but it is a real risk for anyone running mass scans across borders.

The boring, sensible default: only scan things you control or have written permission to scan. Document your scope. Keep audit trails. If you are doing security research at scale, get a lawyer involved before, not after.

How to Defend Against Scans

You cannot stop people from scanning your server. The internet does not work that way. What you can do is make scans return less useful information and make exploits harder.

Close ports you do not need. This is the boring obvious one. If you are not running a database service, do not have 5432 open to the world. Audit your own server periodically and shut down anything you do not actively use.

Put a firewall in front of services. A stateful firewall will silently drop packets to ports that should not be reachable. From the outside, those ports look filtered, not closed. The attacker cannot even tell whether something is there.

Restrict by source IP. Things like SSH and database ports should be reachable from a small set of known IPs (your office, your VPN, your bastion host). Use iptables, ufw, AWS security groups, or your cloud provider's equivalent.

Use fail2ban for what you must expose. SSH on port 22 will get hammered. Fail2ban watches your auth log and blocks IPs that fail too many logins in a short time. A simple config:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600

That blocks any IP that fails 3 SSH logins within 10 minutes for the next hour. It costs you nothing and stops the dumber bots cold.

Run on non-standard ports if it makes sense. Moving SSH from 22 to 2222 (or anything random above 1024) does not actually make you secure. But it does cut down on the volume of automated noise hitting your logs by something like 99 percent. The rare attacker who actually scans every port will still find it, but most bots only check the well known number.

Disable banner information. Many services advertise their version in plain text on connection. SSH says "OpenSSH_8.9." Apache says "Apache/2.4.41 (Ubuntu)." That information helps attackers pick the right exploit. Most services have a config option to hide or shorten the banner.

Network segmentation. Database servers should not be on the same flat network as your web servers. If a web server gets popped, the attacker should not have a direct path to your data. Put internal services on private subnets that are unreachable from the internet at all.

How to Run a Quick Scan Yourself

You do not need fancy tools to test your own server. A bash one liner will do it for casual checking:

for port in 22 80 443 3306 5432 6379 27017; do
  timeout 1 bash -c "echo >/dev/tcp/your-server.com/$port" 2>/dev/null && echo "Port $port: open" || echo "Port $port: closed or filtered"
done

That uses bash's built in /dev/tcp pseudo-device to attempt TCP connections to each port. No external dependencies.

For real audits, install nmap. It is the canonical port scanner and has been for 20 years. A normal SYN scan of a host:

sudo nmap -sS -p- your-server.com

The -p- means scan all 65535 ports. Add -sV to also try service version detection. Add -A for aggressive (OS detection, version detection, script scanning). Be aware: aggressive scans take time and look noisy in logs.

If you just want a single port checked from outside your own network, our port scanner tool does a fast TCP connect test from our edge servers. No sign up.

What Open Ports Actually Reveal

Beyond the binary "is anything listening," open ports leak surprising amounts of context.

The set of open ports tells you what kind of system this probably is. Ports 25, 110, 143, 465, 587, 993 open? That is a mail server. Ports 80, 443, plus maybe 8080? Web server. Ports 22, 53, plus a few internal ones? Probably a DNS server with management access.

Service banners give away versions. If port 22 is open and the SSH banner says "OpenSSH 7.4," an attacker can immediately look up which CVEs apply to that version.

Some ports correlate with specific platforms. Port 3389 means Windows. Port 1433 means SQL Server. Port 22 plus 5432 plus a Linux user-agent on 80 strongly suggests a Linux web server stack.

Combined with reverse DNS lookups and WHOIS data, an attacker can build a pretty complete picture of your infrastructure from a port scan and some passive reconnaissance. This is why defense in depth matters. Blocking ports is one layer. Authentication, encryption, patching, and monitoring are the others.

What This Has to Do With Your IP

If you run a server, your public IP is the front door. The whole internet can knock on every port on it. If you understand which ones are open, you understand your exposure.

If you only run a workstation, you are mostly on the receiving end of NAT. Your ISP gives you one public IP that all your devices share. From the outside, scanning your IP usually returns nothing because your home router blocks unsolicited inbound traffic by default. That is a good thing.

But if you run port forwarding (a common config for game servers, home cameras, or self-hosted services), you have intentionally exposed specific ports on your home internet. Those ports are scannable. Worth checking what you have actually opened.

You can find your current public IP at whatismyip.technology and run a scan from there if you want to see what the internet sees. Combined with a VPN leak test you can confirm whether your privacy tools are actually doing what you think they are.

The Big Picture

Port scanning is one of those topics that sounds scary if you have never done it and feels boring once you have. It is a flashlight. You shine it on a network and see what is there.

For attackers, it is the very first step in mapping a target. For defenders, it is a sanity check on your own configuration. For developers, it is the tool you reach for when "the service is not responding" turns out to be "the service is bound to the wrong interface" or "the firewall has been quietly dropping packets for two months."

The fundamentals do not change. Send a packet, see what comes back. Do that 65,535 times and you have mapped a host. The countermeasures evolve, the tooling gets faster, and the attack surface keeps shifting, but the basic mechanic has been the same since the early 1990s.

Now that you know what a port scan is doing under the hood, the results you see in our port scanner tool should make a lot more sense. And if you want to round out your understanding of how a server's identity gets exposed, the HTTP headers explained and what your IP reveals posts cover the rest of the puzzle.