What open ports say about a server
A port scan returns a short list — a handful of numbers and three possible states — and it is tempting to read it as a verdict: open is bad, closed is good. Real servers refuse that reading. Some open ports are the entire job of the machine; some closed-looking ports hide a service behind a firewall; and the most dangerous finding is often a port that cannot explain why it is reachable. Here is how to read a scan the way an operator reads it: port by port, audience by audience.
A scan is a list of answers, not a verdict
The port scanner probes about twenty well-known ports with plain TCP connects and reports each as open, closed or filtered. Open means something accepted the connection. Closed means the host actively refused it. Filtered means silence for a full second — usually a firewall dropping packets, which is a statement about the network path, not about the port. The first skill in reading a scan is resisting the urge to collapse those three states into two. Filtered is not a softer closed: a filtered database port might have a database behind the firewall, reachable from your office network and invisible from here — exactly the correct setup, and exactly what a two-state scanner would misreport. Judge each port against what the server is for, not against a universal rule that open is bad.
That judgement starts with one question the scan cannot answer: who is this server for? A web server's job is to be reachable by strangers, so open 80 and 443 are not findings — they are the job description. A database server's job is to be reachable by a handful of application servers, so the same openness is an emergency there. Before reacting to any open port, write down the server's intended audience in one sentence: ports that serve that audience are working as designed, and ports that serve a wider audience are the work list. Note too that the scanner sees what the internet sees — the view attackers get for free — while your internal network may legitimately see more.
The ports that should be open
On a web server, expect 80 and 443 and little else. Port 443 open with a valid certificate is the whole point of the machine, and once you know it is open, the next question is whether the TLS setup behind it is current — which is what the SSL grader answers. On a mail server, expect the mail ports: 25 for server-to-server delivery, and 110, 143, 993 or 995 if it serves mailboxes directly. On a DNS resolver, expect 53. A port is normal when it matches the server's stated job; a short open list that matches the job description is a good scan, even if it is not empty — an empty scan on a web server would mean the site is down, not that it is secure.
The ports that should make you stop
Some open ports are emergencies regardless of the server's job. Database ports head that list: MySQL on 3306, PostgreSQL on 5432, MongoDB on 27017. Databases are meant to be reached by applications, usually over a private network or through an application tier, and a database port open to the internet means anyone can knock on the door of your data store — and automated scanners knock constantly, trying default credentials and known vulnerabilities. If a scan finds one open, restrict it to the addresses that need it immediately, then ask how it got exposed: a default installation, a firewall rule added during a migration and never reverted, a cloud security group set to allow all sources. The same urgency applies to file sharing on 445, which has carried some of the worst worms in internet history and has no business facing the internet, and to Telnet on 23, which sends everything including passwords in clear text. An open VNC port on 5900 is the same story in miniature: remote desktop access reachable by anyone is a credential-guessing contest you did not agree to enter.
Remote access: the judgement call
SSH on 22 and RDP on 3389 sit in a different category, because remote administration is a legitimate need and these are the standard ways to meet it. An open 22 on a server you administer is not a finding by itself; it is how you do your job. But it is a judgement call with a price: every open remote-access port is an invitation to automated login attempts, and the internet accepts that invitation millions of times a day. The question is not whether to close it but how to narrow its audience. Key-only authentication instead of passwords removes the credential-guessing contest entirely for SSH, and restricting the port to your office addresses or a VPN removes it from the internet's view altogether — the strongest answer. RDP deserves even more caution: its history includes remotely exploitable flaws and it is a favourite target of ransomware operators, so if RDP must be reachable, it should be reachable only through a VPN, never directly. When a scan shows 22 or 3389 open, the right response is rarely panic and never indifference — it is a check that the access controls around that port match the value of what lies behind it.
Filtered is a sentence, not a shrug
Filtered results are the ones people misread most, usually by ignoring them. Silence from a port is information, just not the information a two-state scanner pretends it is. Most often it means a firewall is dropping packets — a deliberate, healthy configuration: the service behind it may be running fine and reachable from the networks that need it, invisible to everyone else. But silence has other causes. A service bound only to localhost will look filtered from outside while working perfectly for local clients. A service that crashed will also look filtered if a firewall stands in front of it, which is why a filtered result for a port you expect to be open should trigger a check on the host itself, not a shrug. Filtered means "go and look", not "nothing there" and not "all clear".
What a clean scan does not prove
A scan with no unexpected open ports is a good result, and it is not a security proof — stating that plainly matters, because the alternative is false confidence. This scanner reads no banners, so it cannot tell you whether the service on an open port is patched or ancient; an open 443 running a five-year-old web server looks identical to one running yesterday's release. It probes TCP only, so UDP services are outside its view. It covers twenty ports, so a service on an unusual port — a web application on 3000, a database moved to a non-standard port for obscurity — is invisible to it, and obscurity is not security anyway: a full scan finds non-standard ports in seconds. And it says nothing about the application layer, where most breaches actually happen. Use the scan for what it is — a fast, honest map of the usual doors — and pair it with deeper checks: the TLS audit for port 443, the health check for reachability and records, patch status and application review for the rest. A clean scan means the obvious doors are shut. It does not mean the windows are locked.
Start with your own infrastructure: run the port scanner against a server you run, read the open list against the server's one-sentence job description, and fix the ports that cannot explain themselves — databases and file sharing first, remote access narrowed second, filtered results investigated rather than ignored. Then scan again after each change, and once a quarter as routine: servers accumulate open ports one temporary service, one migration rule, one default at a time.
Frequently asked questions
I scanned my server and a port I expected is filtered. Is the service down?
Not necessarily — filtered means silence, and silence has several causes. The service may be running but bound to localhost or a private interface, so it never answers the internet at all. A firewall may be dropping packets before they reach it. Or the service may genuinely be down. The scan cannot distinguish those cases; check the service on the host itself (is it running, what address is it listening on) and read the firewall rules for that port. Run the <a href="/tools/port-scanner/">port scanner</a> again after each change and watch the state move.
Should I close every port the scan finds open?
No — close the ones that cannot explain themselves. Port 80 and 443 open on a web server is the job, not a problem. A database port open to the whole internet is a problem on any server. The question for each open port is not "is it open?" but "who is it open for, and does that audience need it?" A port open to the internet that only your application servers need should be restricted to those addresses, not closed outright — the service still has to be reachable by something.
How often should I scan?
After every change to a server's network setup — a new service installed, a firewall rule edited, a migration finished — and once a quarter as routine. Servers accumulate open ports the way desks accumulate cables: a temporary test service that was never removed, a default that came with a package, a rule added for a migration and never reverted. A quarterly scan plus continuous uptime monitoring through <a href="https://myeventwatch.com/register?utm_source=sysosx&utm_medium=tool&utm_campaign=ports-article">myeventwatch</a> catches both the slow drift and the sudden outage.