An open port on its own is not a vulnerability. It means a program is listening for connections on that number. Whether it matters comes down to two things: what service sits behind it, and who can reach it. Open only inside your LAN, most ports are harmless. Exposed to the internet on an outdated or unauthenticated service, they become the way in.
What an open port actually is
When a device offers a service, such as file sharing, a web admin panel, or remote desktop, it binds to a TCP or UDP port and waits for connections. Port 443 serves HTTPS, 22 is SSH, 445 is Windows file sharing. A scanner reports a port as "open" when something answers on it; "closed" or "filtered" means nothing responded. The number itself is just a label. The software behind it is what can be attacked.
Which open ports are genuinely risky
Not every open port carries equal weight. A short watchlist worth checking first:
- Telnet (23) sends everything, passwords included, in cleartext. There is no safe reason to run it. Replace it with SSH.
- RDP (3389) is remote desktop, a constant brute-force and ransomware target. Never expose it directly to the internet; put it behind a VPN.
- SMB (445) is Windows file sharing, the vector behind WannaCry. Fine on a trusted LAN, dangerous on the open internet.
- Unauthenticated web panels on routers, cameras, NAS boxes and printers, still running default or blank admin passwords.
- Exposed databases like MongoDB (27017), Redis (6379) or Elasticsearch (9200) bound to
0.0.0.0with no authentication. Entire breaches have started here.
How to check what's really listening
Knowing a port is open is half the picture. You want the service and version behind it. nmap does this with the -sV flag:
nmap -sV 192.168.1.0/24This scans the subnet and probes each open port to name the service and, often, its version. A result like 445/tcp open microsoft-ds Samba smbd 4.15 tells you far more than "445 open," and an old version is your cue to check for known CVEs.
Running nmap across a whole network and reading the raw output takes patience. DeviceShelf does the same enumeration in one pass and adds a plain-language risk report per device: it flags exposed services like Telnet and RDP, runs default-credential checks, and hints at relevant CVEs. It works locally, with no account. If you're weighing it against other tools, the scanner comparison lays out where each one stops, and the Fing alternative writeup covers that switch in particular.
LAN-only or internet-exposed? That's the real question
For most home and small-office ports, the honest answer to "is this dangerous" is: only if something outside can reach it. Check two things. First, is the service bound to 127.0.0.1 (localhost only), your LAN IP, or 0.0.0.0 (everything)? Second, does your router forward that port? Open the port-forwarding page and look for manual rules as well as any UPnP entries you never created. A database on 0.0.0.0 behind a router with no forward is exposed to your LAN, not the internet. Still worth fixing, but not a fire drill.
How to close or firewall a port
Three levers, roughly in order of preference:
- Stop the service if you don't use it. A disabled Telnet or SMB service closes the port outright.
- Rebind it to localhost or the LAN instead of
0.0.0.0in the application's config. - Firewall it. Block the port at the host (Windows Firewall,
ufw,pf) or at the router, and delete any port-forward or UPnP rule you didn't add on purpose.
Then re-scan and confirm the port now reads closed or filtered.
Keeping an eye on it after the fix
Auditing ports once is worth doing, but the exposure that actually bites is usually the one that appears later, when a new device joins or a service quietly auto-enables itself. DeviceShelf watches for that in the background and alerts you when a new listening service shows up. There's a free 7-day trial, no account needed.