You open a firewall rule on a Friday afternoon so a contractor can reach a server. By Monday you assume nobody knows about it. The uncomfortable part of this question is that nobody has to know about it. Finding it is automated, cheap, and done to every address range whether or not anyone has a reason to care about yours.
What a port scan is
Every internet-facing service listens on a numbered port. SSH on 22, RDP on 3389, PostgreSQL on 5432. A port scan sends a probe to a port and reads what comes back: an answer, a refusal, or silence. MITRE ATT&CK groups this under reconnaissance and describes active scanning as the adversary probing “victim infrastructure via network traffic, as opposed to other forms of reconnaissance that do not involve direct interaction.”
The first step is usually a sweep of address ranges. MITRE’s technique for scanning IP blocks says adversaries “scan victim IP blocks to gather information that can be used during targeting”, from simple pings to banner grabbing. The goal is a list of hosts that are alive and, on each, a list of ports that reply.
The three ways attackers find your open ports
1. They scan you directly. They pick your IP block, or a whole range that happens to contain it, and probe. Your public addresses are not secret: they sit in DNS records, certificates and your own email headers.
2. They read someone else’s scan. MITRE lists searching “within public scan databases for information about victims” as its own technique, and names services such as Shodan and Censys. These services scan the internet continuously and publish what they find. The attacker never touches your server. They run a search, and your open ports are in the results.
3. They look from the inside. Once they have a foothold somewhere, MITRE’s Network Service Discovery technique applies: adversaries “get a listing of services running on remote hosts and local network infrastructure devices, including those that may be vulnerable to remote software exploitation.” This is the step that turns one compromised laptop into a map of your internal servers.
What the scan actually learns
A probe of a port gives one of a few answers. An open port answers and, usually, announces what is behind it. A closed port refuses. A filtered port says nothing. Only the first is useful to an attacker, and not only because it exists: the reply often identifies the software and its version, which they can then compare against known flaws.
CISA states the risk in plain terms: “Threat actors can use internet-based search and discovery platforms to identify publicly accessible systems with misconfigurations, default credentials, and outdated software.” The scan does not break in. It builds a shortlist for whoever does.
- 1Pick a rangeYours, or one containing it
- 2Probe the portsOr search a scan database
- 3Read the repliesOpen ports, software, versions
- 4Shortlist targetsFlaws, weak or default logins
Can you stop it?
Mostly not, and MITRE says so directly. For scanning IP blocks it states: “This technique cannot be easily mitigated with preventive controls since it is based on behaviors performed outside of the scope of enterprise defenses and controls.” You do not get to veto packets arriving at your public address.
That changes the question. The thing you control is what the scan finds. MITRE’s mitigation for Network Service Discovery is to “ensure that unnecessary ports and services are closed to prevent risk of discovery and potential exploitation.” It also suggests network intrusion detection or prevention to spot remote service scans, which tells you someone is looking. It does not stop them from looking.
What helps, and what it does to the scan
| What you do | What the scan sees | Residual risk |
|---|---|---|
| Nothing | Every listening port | Full exposure |
| Change default port numbers | The same services, found a little later | The service is still reachable |
| Firewall rules and allow-lists | Filtered or silent ports for outsiders | Rules drift, and allowed addresses change |
| Close ports with no documented need | Fewer open ports | Remaining ones still need patching |
| No inbound listener at all | Silence | Nothing to find |
Moving a service to a non-standard port is covered in does changing the SSH port improve security. The short version: it trims noise, not exposure, because a scanner checks every port.
A short checklist to run this week
- Scan yourself first. CISA says organisations “should routinely scan their public IP address ranges to identify ports and services that are accessible from the internet.” Do it from outside your network.
- Close what has no documented reason. CISA’s wording: “Close or restrict access to ports that do not have a documented operational need.”
- Look up your own addresses in public scan databases. If you can find them there, so can everyone else.
- Check the old rules. Contractor access from last year is the classic survivor.
- Patch whatever must stay open, because it is the part the scan will find.
- Watch for scan traffic. It will not stop it, but it tells you how interesting your address range is.
Where SSHepherd fits
If the aim is for a scan to find nothing, the cleanest answer is a server with no inbound listener. SSHepherd® closes the externally exposed listening port on the server. The server and your administrators each connect outward to a broker, which joins them only for authorised identities, so a scan finds no SSH or RDP port to probe. It works across SSH, RDP, databases and file transfer, and takes about ten minutes to deploy and protect a server without re-architecting the network. See the SSHepherd page and the Linux SSH use case.
The bottom line
Attackers find open ports by scanning your ranges or by reading scans that others have already published, and you cannot prevent either. You can control the result. Scan yourself, close every port with no documented need, and where possible leave no inbound port at all.