A TCP SYN response shows a reachable port, not a confirmed application or a vulnerable device. This historical analysis records IPv4 responses across 16 conventional service ports in June–September 2019. The largest reported row is port 22, with 24,372,250 responding addresses in its latest snapshot.
Method and evidence limits
The original analysis attributed these observations to Rapid7 Project Sonar TCP snapshots, with four to eight snapshots per port. The original input manifests, exclusions and extraction outputs have not been reproduced for this update. The figures below are retained as historical reported observations, not a fresh census or independently revalidated totals.
Nmap's SYN-scan documentation explains the transport-level response being measured. Identifying an application requires separate service-detection probes. No such handshake, authentication test or vulnerability test is documented for these counts. A port number cannot establish Redis access, a BGP router, a Telnet backdoor or an IoT device.
Counts are unique responding IPv4 addresses within each port dataset. Adding rows counts IP-port observations and can count one address repeatedly. NAT, proxies, filtering and changes in scan coverage complicate device and trend interpretation. IPv6 is outside this dataset; see the separate historical AAAA-record study.
Historical port observations
Service labels in this table identify conventional port associations only. They do not confirm the software listening there. The latest snapshot date and sampling interval can differ by row.
| Service | Port | Latest IPs | Trend |
|---|---|---|---|
| SSH | 22 | 24,372,250 | +20.7% |
| FTP | 21 | 15,393,692 | -1.5% |
| DNS | 53 | 11,209,778 | -4.1% |
| RDP | 3389 | 8,919,051 | -2.1% |
| Telnet | 23 | 7,788,320 | +3.7% |
| BGP | 179 | 6,794,106 | +5.1% |
| MQTT | 1883 | 4,648,376 | -18.4% |
| Redis | 6379 | 4,408,406 | -3.2% |
| SSH (alt) | 2222 | 4,137,527 | +10.2% |
| MQTT/TLS | 8883 | 3,887,681 | -21.7% |
| Telnet (IoT) | 9527 | 3,478,730 | -23.0% |
| Telnet (alt) | 2323 | 3,469,284 | -5.6% |
| LDAP | 389 | 3,317,067 | -16.2% |
| SMB | 445 | 3,318,009 | -2.2% |
| DNS-over-TLS | 853 | 3,265,260 | -7.6% |
| Memcached | 11211 | 2,966,132 | -2.2% |
The trend column compares available snapshots within the 2019 window. Port 22 grew 20.7%, while alternate port 2222 grew 10.2%, a slower relative increase. The largest four rows include DNS, so they are not all remote-access protocols. These counts do not establish a total number of distinct exposed devices.
What the categories can tell an operator
Remote access: Ports 22, 21, 3389, 23 and their alternatives are useful inventory starting points. Verify the actual service, intended audience, authentication and supported software version on systems you own. An open management port is not itself proof that credentials can be bypassed.
Databases and directories: Ports 6379, 11211 and 389 warrant owner-side investigation. Restrict internal services to intended clients and verify authentication. These rows do not demonstrate millions of unauthenticated databases. A TCP observation also cannot establish a UDP amplification condition.
DNS and routing: Public authoritative DNS has a legitimate reason to be reachable. A response on port 53 does not distinguish authoritative service from open recursion. Likewise, port 179 does not identify a router or show that arbitrary BGP peers can establish a session. Validate the protocol and its access rules separately.
IoT-associated ports: Ports 1883, 8883, 2323 and 9527 merit review in an owned-device inventory. See the IoT port-exposure analysis for its narrower task and the same measurement limits.
Changes are observations, not explanations
The decline in several port counts could reflect filtering, address churn, scan coverage, decommissioning or other causes. This dataset does not distinguish them. It also cannot attribute growth to cloud defaults or containerization. Later security regulations cannot explain an earlier observation without a documented chronology and causal analysis.
Recovering source manifests, per-port snapshot dates, scan exclusions and extraction scripts would allow the historical comparisons to be audited. Until then, use the table as a qualified historical record rather than evidence of current service prevalence or improving security.
Audit an owned perimeter
- Build an inventory from hosting accounts, network assignments and deployed services. Include IPv6 separately.
- Check approved addresses and ports using the port scanner or an authorized internal scanning process.
- Confirm the actual application and access controls on the host. Review configurations and logs rather than inferring them from the port number.
- Restrict management, database and device services to their intended clients. Verify the effective host and network firewall rules.
- Repeat checks after infrastructure changes and investigate unexpected new listeners.
A smaller observed port count does not establish fewer vulnerabilities. The useful outcome is an inventory in which every reachable service has an owner, an intended audience and verified controls.