If you've ever run a security checklist or read a breach post-mortem, you've seen the phrase "open port" get blamed for something. It's one of the most common — and most misunderstood — building blocks of network security. This guide explains what a port actually is, why an open one can matter so much, which ones are worth checking first, and exactly how to find and close them on your own network.
What is a port, actually?
Every device on a network has one IP address, but it can run many services at once — a web server, a file share, a remote-desktop session, a printer spooler. A port is simply a number (0–65535) that tells the operating system which of those services a piece of incoming traffic is meant for. When a web browser connects to a server, it connects to that server's IP address on port 443 (HTTPS) or port 80 (HTTP) — the port number is the "apartment number" on top of the "street address" that the IP provides.
A port is open when a program on that device is actively listening on it and will accept a connection. A port is closed when nothing is listening — the device will refuse or ignore the connection attempt. A port can also appear filtered, meaning a firewall is silently dropping the connection attempt before it even reaches the device, so the sender gets no response at all.
Why open ports matter for security
An open port by itself isn't a vulnerability — it's just a door. What matters is what's standing behind the door: an outdated FTP server with a known remote-code-execution bug is a very different risk from a fully patched, properly configured VPN endpoint, even though both show up as "open" in a scan.
The practical risk comes from three things happening together:
- A port is open that doesn't need to be. A printer with an unused Telnet management port, a NAS with SMBv1 still enabled, a dev server someone forgot to take down after a demo.
- The service behind it is exposed to more of the network (or the internet) than intended. A database that should only be reachable from one application server, but is actually reachable from the whole office Wi-Fi — or worse, from the internet via a misconfigured router.
- The software behind the port is outdated or misconfigured. Old firmware, default credentials, disabled authentication for "internal testing" that never got re-enabled.
Attackers — and the automated bots that do most initial network scanning — look for exactly this combination. A full network port scan is usually the very first step of both a professional penetration test and an opportunistic attack; the difference is only what happens after.
The ports attackers scan for first
Not all 65,536 ports are equally interesting to an attacker. In practice, a small set of well-known ports account for most opportunistic scanning and exploitation attempts, because they map to services that are frequently misconfigured, run outdated software, or allow direct remote access.
| Port | Service | Why it's a common target |
|---|---|---|
| 21 | FTP | Often allows anonymous login; credentials sent in plaintext. |
| 22 | SSH | Constantly brute-forced with default/weak credential lists. |
| 23 | Telnet | Unencrypted remote access — still common on routers, cameras, IoT. |
| 135, 139, 445 | RPC / NetBIOS / SMB | File-sharing protocol with a long history of critical remote-code-execution CVEs (EternalBlue, and others). |
| 161 | SNMP | Frequently left on the default "public" community string, exposing device configuration. |
| 1433, 3306, 5432 | MSSQL / MySQL / PostgreSQL | Databases exposed further than intended, sometimes with empty or default passwords. |
| 3389 | RDP | Direct remote desktop access to Windows — a top initial-access vector for ransomware when exposed to the internet. |
| 8080, 8443 | Alt HTTP(S) | Often admin panels for routers, NAS devices, printers and IoT gear, frequently left on default credentials. |
This isn't a list to panic over if you find one of these open — plenty of them are legitimately needed (RDP inside a locked-down office LAN, SSH for server administration). It's a list of what to check first: is this port supposed to be reachable from here, is the software behind it current, and is authentication actually enforced?
If you find port 3389 (RDP), 23 (Telnet) or a database port reachable from the public internet — not just your LAN — treat it as urgent. These are the ports most commonly abused for initial access in real-world ransomware incidents.
How to scan your own network for open ports
You don't need to guess which ports are open — you can scan for them directly. There are two situations worth distinguishing:
Scanning from inside your network (LAN)
This tells you what's reachable device-to-device on your own Wi-Fi or wired network — the view a compromised laptop, a malicious guest device, or an infected IoT gadget would have. A network scanner like LANsentry does this automatically: it discovers every device on the network, scans each one for open ports, and shows you a live inventory — no command line required.
Scanning from outside (WAN)
This tells you what's actually reachable from the public internet, which matters if your router forwards any ports (for remote access, gaming, self-hosted services, etc.). This is a fundamentally different — and often more urgent — question, since it defines your entire attack surface from strangers on the internet. LANsentry's WAN scan detects your public IP and checks exactly this.
A port can be closed on your LAN scan but wide open on your WAN scan (or vice versa) if your router has port forwarding configured. Always check both — they answer different questions.
How to close a port you don't need
Once a scan shows you an open port you don't recognize or don't need, there are three ways to deal with it, roughly in order of preference:
- Turn off the service. If nothing on that machine needs FTP, Telnet, or that old management interface running, disable it in the device's own settings (Windows Services, a router's admin panel, a NAS's application manager). This is the cleanest fix — the port disappears entirely.
- Restrict it with a firewall rule. If the service is needed but only for specific devices (e.g. RDP only from your own admin workstation), keep it running but block everyone else at the firewall — Windows Defender Firewall, a router's ACL, or a dedicated firewall appliance.
- Remove the port-forward on your router. If a WAN scan shows a port open that you forwarded months ago for something you no longer use, delete that forwarding rule.
After making a change, re-scan to confirm it actually took effect — a service that "should" be disabled sometimes restarts on reboot, and a firewall rule can be shadowed by a broader rule above it.
Open doesn't always mean vulnerable
It's worth saying clearly: an open port is a starting point for investigation, not a verdict. Port 443 is open on almost every web server on earth, and that's completely normal and necessary. What actually determines risk is the combination of port + software + version + configuration — which is exactly why raw port lists aren't enough on their own.
This is where CVE (vulnerability) data comes in: once you know a port is running, say, an old version of a specific FTP server, you can look up whether that exact version has known, exploitable vulnerabilities — and how likely those are to actually be used in the wild. We cover that in detail in our guide to CVE, CVSS, EPSS and KEV.
Scan every port on your network in one click
LANsentry discovers every device, scans open ports, identifies the software and version behind them, and flags known vulnerabilities — all locally on Windows, no cloud required.
Next steps
A one-time port scan is a good start, but networks change constantly — new devices join, software updates open new ports, someone plugs in a rogue access point. Two habits make the biggest difference long-term:
- Re-scan on a schedule, not just once. LANsentry can run scheduled scans automatically and alert you when a new port opens or a new device appears.
- Keep an inventory of what's supposed to be open. If you can't tell "expected" from "unexpected" at a glance, every scan turns into a full investigation. Labels and device groups (built into LANsentry) solve exactly this.