An open port is not the same as an open vulnerability — but the specific ports a server exposes reveal its attack surface, its software stack, and sometimes its configuration quality, and scanning your own systems periodically is one of the most revealing security audits you can run
The previous articles on this site covered which ports should be open, cloud security group misconfigurations, NAT and port forwarding, and IPv6 scanning resistance. This article addresses what attackers do with port scan results — the attacker's perspective on port information, how automated scanning works at internet scale, and what your port exposure reveals that you might not intend.
Automated scanning of the entire internet: Shodan and Censys
The entire internet-facing IPv4 address space (approximately 3.7 billion addresses) can be scanned in under an hour using tools like Masscan that send millions of packets per second. Services like Shodan and Censys do this continuously, maintaining real-time databases of open ports and service banners for every routable IP address.
Shodan specifically: queries Shodan for any IP address and sees: which ports are open, what service is responding, what the service's banner says (software name and version), TLS certificate details, and any exposed configuration or interface information.
The implication: any internet-facing server you operate is almost certainly already in Shodan's database, with its open ports and service banners catalogued. Port scanning is not something you do to a target; it's something that has already been done to your infrastructure continuously.
What this means practically: security through obscurity (using non-standard ports to "hide" services) provides minimal protection — Shodan scans all 65,535 ports. Moving SSH from port 22 to port 2222 reduces automated SSH brute-force attempts from bots that only scan port 22, but a targeted attacker using Shodan will find it immediately.
Banner grabbing: what services announce about themselves
When a client connects to most services, the service sends a banner — a text response identifying itself:
- SSH:
SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.4 - FTP:
220 ProFTPD 1.3.6c Server (Debian) [::ffff:93.184.216.34] - SMTP:
220 mail.example.com ESMTP Postfix (Ubuntu) - HTTP:
Server: Apache/2.4.41 (Ubuntu)(in the response header)
What an attacker learns from banners:
- Software name and exact version → known CVEs for that version
- Operating system and distribution → OS-level vulnerabilities
- Configuration details → sometimes configuration errors revealed in banners
Suppressing or falsifying banners reduces this information leakage: Apache can be configured to report Server: Apache without the version; nginx can be similarly configured. This doesn't prevent vulnerability exploitation if a version is fingerprinted through other means, but it removes the easiest reconnaissance avenue.
Port state nuances: open, closed, filtered
A port scanner can return three distinct states, each with different security implications:
Open: a process is actively listening on this port. Connections will be accepted and a service banner may be sent.
Closed: the host responded, but no process is listening on this port. The host sent a TCP RST (reset) packet. This proves the host is reachable and the firewall passes traffic to this port, but nothing is running there.
Filtered: no response received at all. The firewall dropped the packet without responding. The scanner can't determine whether the port is open or closed — it's hidden behind a firewall.
The security preference: ports that aren't in use should be filtered, not closed. A closed port reveals that the host is reachable on that port (and that the firewall passes traffic). A filtered port reveals less. Stateful firewalls that drop packets by default, with explicit allow rules only for needed services, produce the "filtered" state for all non-explicitly-allowed ports — this is the preferred posture.
The TCP SYN scan: why most port scans don't complete connections
Traditional TCP port scanning sends a full connection (SYN → SYN-ACK → ACK). Modern port scanners use TCP SYN scanning (also called "half-open scanning"):
- Send SYN packet (initiate connection)
- If port is open: receive SYN-ACK (connection accepted) → immediately send RST (reset, abandoning the connection)
- If port is closed: receive RST from the server
- If port is filtered: no response (timeout)
Why this matters: SYN scanning is faster (doesn't wait for full connection), less detectable by some systems (the connection is never fully established), and reveals port state without completing a logged connection.
Application logs typically don't record SYN scan attempts — only full TCP connections appear in most application logs. Network-level intrusion detection systems (IDS) do detect SYN scan patterns from the packet-level behavior.
Port scanning your own systems: what to look for
Regular port scans of your own internet-facing infrastructure are a security best practice — they reveal:
Unexpected open ports: a service that was started for testing and never shut down; a deployment that opened a port not in the approved configuration; a cloud security group rule that's more permissive than intended.
Service version exposure: banners that reveal exact software versions, allowing you to cross-reference against known CVE databases.
Services on non-standard ports: a database (MySQL/Postgres) accidentally exposed on the internet; a management interface (phpMyAdmin, Redis) exposed without authentication.
Comparison against expected configuration: using the port scanner output as a diff against your intended open-port policy. Anything open that shouldn't be, or anything not open that should be, is a discrepancy worth investigating.
How to use the Port Scanner on sadiqbd.com
- Scan your own domains and IP addresses to see what you're exposing — the results show what external scanners (Shodan, potential attackers) already know about your infrastructure
- Focus on unexpected findings: known-necessary ports (80/443 for web, 25/587 for mail) are expected; unexpected open ports on non-standard numbers warrant investigation
- Cross-reference service banners with CVE databases: if a banner reveals an outdated software version, search that version in the National Vulnerability Database (nvd.nist.gov) to find known vulnerabilities
Frequently Asked Questions
Is it legal to port scan a server that doesn't belong to me? This depends on jurisdiction and context, and the answer is generally no without authorization. In the UK, unauthorized port scanning may violate the Computer Misuse Act. In the US, the Computer Fraud and Abuse Act has been interpreted to cover unauthorized scanning in some cases. In most jurisdictions, actively probing a system without the owner's consent is at minimum in a grey area and at worst a criminal offence. Only scan systems you own or have explicit written permission to test. This tool is designed for legitimate use: scanning your own infrastructure, verifying your own server's security configuration, and educational purposes on systems you control.
Is the Port Scanner free? Yes — completely free, no sign-up required.
Try the Port Scanner free at sadiqbd.com — check which ports are open on any host you have permission to scan.
