A Beginner's Guide to Port Scanning: Audit What Your Server Exposes

Server bought, services deployed — the most important closing move isn't celebrating, it's auditing: are the ports exposed to the public internet the ones you think they are?

Ports: Different Windows on the Same Machine

An IP locates a machine; a port locates a specific service on it. Web runs on 80, SSH on 22, MySQL on 3306 — every network service listens on some port.

"Port scanning" means knocking on each of those doors from the outside to see which ones answer. It isn't hacker-only technology; it's a basic skill for every operator — at minimum, you should know which doors your server opens to the world.

Three Results, Three Meanings

TCP connection probes return one of three states; understanding them is the foundation of reading any scan result:

Open — someone answers the knock; a service really is listening on that port. 80/443 open is normal for a web server; 3306/6379 open is almost always a misconfiguration.

Closed — the machine explicitly replies "no service here" (TCP RST). The machine is up; nothing is using this port.

Filtered — the knock vanishes without a sound. A firewall is usually silently dropping the packets, so you can't tell whether anything is behind the door. On a hardened server, the vast majority of ports should look exactly like this.

Why Database Ports Are Dangerous

A familiar accident pattern: a developer installs Redis on a server, it listens on 0.0.0.0:6379 by default, and no password is set. Mass scanners find the opening within minutes — unauthorized Redis access can write files directly and plant SSH keys to take over the entire machine. MongoDB ransom-and-wipe incidents happen every year.

What to do when your self-check finds a database port open:

# Check which address the service is listening on
ss -tlnp | grep 6379

# Change the config file to listen on localhost only
bind 127.0.0.1

Either switch to bind 127.0.0.1 (local access only) or restrict source IPs with a firewall. On cloud servers, also check the security group in the provider console — it and the in-OS firewall (ufw/iptables) are two independent walls; missing either one means no protection.

Where Legal Meets Illegal

Port scanning tools are neutral, but scanning other people's assets without authorization sits on the edge of legality — or clearly across it — in many jurisdictions. There's exactly one legitimate use: scan what's yours — your own servers, assets within your company's authorized scope, pentest targets covered by signed authorization.

This is why reputable tools impose limits: IPchase's port check probes only common service port groups (no full-range sweeps), protects residential addresses, and requires that you only probe targets you own or are authorized to test.

The Complete Self-Audit Workflow

Run this full audit on a new server:

1. Scan from outside: run the port check tool across the web / database / mail port groups
2. Compare against expectations: if only 80/443/22 should be open, every extra port needs an explanation
3. Verify inside the OS: ss -tlnp lists every listening service; confirm there are no unexpected bindings
4. Check both firewall layers: the cloud console's security group plus the in-OS firewall rules
5. Re-check regularly: rescan after every new deployment; configuration drift is the norm

Common Misreadings of Results

Before drawing conclusions from a scan, note that each of these can make things look wrong when they aren't:

• A CDN sits in front: if the target domain is proxied through Cloudflare or the like, you're scanning CDN edge nodes, not the origin. The origin's real port state must be tested against the origin IP (assuming you have access rights)
• DROP vs. REJECT: a firewall REJECT sends back an RST and the scanner reports "closed"; DROP silently discards and reports "filtered." For hardening, prefer DROP — it doesn't advertise the firewall's existence
• Security group open but service down: a "closed" result means the path is clear and nothing is listening — the cloud security group allows 3306 but MySQL isn't running. That's luck, not security: restart the service and it's directly exposed to the internet, so tighten the security group rules while you're at it
• IPv6 out of sync with IPv4: many servers have solid IPv4 protection and run IPv6 wide open. Scan both protocol families in every audit

Reading Service Fingerprints From Scan Results

Beyond open ports, response characteristics reveal even more: after completing the TCP handshake on an open port, the banner can be read (SMTP announces its software name and version, SSH shows SSH-2.0-OpenSSH_8.9), and attackers match that against known vulnerabilities. The admin's countermeasures are hiding or masking banners, upgrading promptly, and following the "closed by default" principle — every extra exposed port is one more surface that needs continuous security maintenance.

Summary

• Port scanning is basic self-audit hygiene for operators, not a hacker specialty
• Three states: open (a service is there), closed (explicitly refused), filtered (blocked by a firewall)
• A database port open to the internet = a critical misconfiguration; change the bind address or add a firewall
• The legal line: scan only what you own or are authorized to test

Give your server an audit: the port check, paired with the Ping latency probe to confirm the network layer is sound.