The Shrinking Perimeter: Common Service Exposure Across IPv4

More than 24 million IP addresses respond to SSH connection attempts on port 22. That is not a theoretical estimate or a projection from a small sample — it is a direct measurement from TCP SYN scans across the entire IPv4 address space. I processed historical scan data from Rapid7's Project Sonar covering 16 common services to build a picture of what the internet's attack surface actually looks like, how it is changing, and what it means for anyone responsible for keeping systems secure.

The results are sobering. Millions of database instances sit exposed to the open internet. IoT devices answer on backdoor telnet ports. Legacy protocols that should have been retired decades ago still respond on millions of hosts. But the data also shows real improvement in some areas — MQTT exposure dropped by over 18%, and IoT-specific telnet backdoors fell by 23%. The perimeter is shrinking in places. Just not fast enough.

Methodology

The data comes from Rapid7 Project Sonar, which conducts regular internet-wide scans of the entire IPv4 address space. Project Sonar sends TCP SYN packets to specific ports on all routable IPv4 addresses and records which hosts respond with a SYN-ACK (indicating an open, listening service). This is the same technique that tools like Nmap and Masscan use, scaled to cover all 3.7 billion routable addresses.

I processed TCP scan snapshots from mid-2019 covering 16 services across ports commonly associated with remote access, databases, infrastructure, and IoT. Each service had between 4 and 8 snapshots taken over a June through September window, allowing me to track short-term trends and validate that the numbers were stable rather than reflecting one-off anomalies.

A few important caveats about this data:

• SYN-ACK does not mean vulnerable. A host responding on port 22 might be running a hardened OpenSSH server behind a firewall rule that only accepts key-based authentication. Responding to a SYN scan means the port is open, not that the service is exploitable.
• NAT and carrier-grade NAT obscure the picture. One responding IP might represent a single server or thousands of devices behind a NAT gateway. The counts represent unique IPv4 addresses, not unique devices.
• Geolocation and attribution are separate questions. This analysis focuses on what services are exposed and how those numbers are changing, not on who is running them or where they are located.
• The data is from 2019. Some services have likely shifted since then, but the structural patterns — what gets exposed and why — remain relevant. If anything, the shift to cloud infrastructure has likely increased exposure of some services while reducing others.

With those caveats stated, let me walk through what the scans found.

The Numbers at a Glance

Here is the full dataset, sorted by the number of unique IPv4 addresses responding to each service in the latest available snapshot:

The trend column shows the percentage change across the available snapshots within the scanning window. Positive means the number of responding hosts increased; negative means it decreased.

Several things jumped out at me immediately. SSH dominates by a wide margin and is growing fast. FTP still has 15 million hosts despite being a fundamentally insecure protocol. And the sheer number of exposed database services — over 10 million combined across Redis, Memcached, and LDAP — represents an enormous attack surface that should not exist.

Remote Access: The Largest Attack Surface

The top four services by exposure are all remote access protocols, and together they account for over 56 million responding IPs. This makes sense — remote access is, by definition, a service you expose to the network. But the scale and composition tell a more nuanced story.

SSH (24.3 million IPs, +20.7%) is the single most exposed service on the internet by a wide margin. The 20.7% growth rate across the scanning window is striking. Some of this reflects the continuing migration from legacy protocols to SSH — every FTP or Telnet server that gets replaced by an SSH-based alternative adds to this count. Cloud providers also contribute significantly: every EC2 instance, Droplet, or VPS that launches with a default SSH configuration adds another IP to the total.

SSH on port 2222 (4.1 million IPs, +10.2%) is growing even faster in relative terms. Port 2222 is commonly used by containerized environments (Docker, Kubernetes), Git hosting platforms, and administrators who move SSH off the default port as a basic hardening step. The growth here likely reflects the explosion of container deployments.

FTP (15.4 million IPs, -1.5%) remains stubbornly persistent despite being a protocol that transmits credentials in plaintext. FTP's slow decline suggests that while new deployments are rare, existing FTP servers are not being decommissioned. Many of these are likely embedded devices, legacy hosting control panels, and industrial systems where "it still works" trumps security concerns.

RDP (8.9 million IPs, -2.1%) is the most concerning entry on this list from a practical attack perspective. RDP has been the primary initial access vector for ransomware operations for years. Every one of those 8.9 million exposed RDP endpoints is a potential entry point for credential stuffing, brute force attacks, or exploitation of RDP protocol vulnerabilities like BlueKeep. The slight decline is encouraging but far too slow given the threat landscape.

Telnet (7.8 million on port 23, +3.7%) should be zero. There is no legitimate reason to expose Telnet to the internet in any era, let alone today. The fact that it is growing — up 3.7% — is entirely explained by IoT devices. Consumer routers, IP cameras, and industrial controllers ship with Telnet enabled by default and no mechanism for the owner to easily disable it. The alternative Telnet ports tell the same story: port 2323 (3.5 million IPs) and the IoT-specific port 9527 (3.5 million IPs) together add another 7 million exposed Telnet endpoints.

The one piece of good news is that IoT Telnet on port 9527 is declining sharply (-23.0%). This port is associated with specific Chinese IP camera firmware, and the decline likely reflects a combination of device retirement, ISP-level filtering, and firmware updates after the Mirai botnet demonstrated how devastating mass IoT exploitation could be.

Database Exposure: When Internal Services Face the Internet

If remote access protocols are the front door, exposed databases are the vault left wide open. These services were never designed to face the internet, have minimal or no authentication by default, and contain the data that attackers actually want.

Redis (4.4 million IPs, -3.2%) is the most alarming entry in this category. Redis ships with no authentication enabled by default. Until version 6.0 (released in 2020, after this scan data was collected), there was no ACL system at all — if you could connect, you had full read/write access. An exposed Redis instance is not a theoretical risk; it is a data breach waiting to happen. Attackers routinely scan for open Redis instances to steal cached data, inject malicious scripts, or use the CONFIG SET command to write SSH keys to the server's authorized_keys file, gaining shell access.

The -3.2% decline is encouraging but insufficient. 4.4 million exposed Redis instances is 4.4 million too many. No legitimate use case requires Redis to be reachable from the open internet.

Memcached (3.0 million IPs, -2.2%) presents a different but equally serious risk. While Memcached is a caching layer that typically holds transient data rather than persistent records, exposed Memcached instances were weaponized in the massive DDoS amplification attacks of 2018. A single spoofed UDP packet to a Memcached server can generate a response 50,000 times larger, making it one of the most powerful amplification vectors ever discovered. The fact that 3 million instances remain exposed years after those attacks made global headlines shows how slowly the internet cleans up after itself.

LDAP (3.3 million IPs, -16.2%) is declining faster than any other database-adjacent service, which is the right direction. Exposed LDAP directories can leak organizational structure, email addresses, usernames, and in the worst case, password hashes. The 16.2% decline likely reflects enterprises moving to cloud identity providers (Azure AD, Okta) and closing legacy LDAP ports in the process.

Services not covered in this particular scan dataset but worth mentioning include MongoDB (which has been responsible for some of the largest data breaches in history due to default-open configurations), Elasticsearch (frequently exposed with no authentication), and CouchDB. The pattern is consistent: database services designed for internal use get deployed to cloud instances with public IPs, and nobody configures a firewall.

Infrastructure Services

The remaining services in the dataset are infrastructure protocols — the plumbing that makes the internet work. Their exposure is expected in some cases and dangerous in others.

DNS (11.2 million on port 53, -4.1%) includes both authoritative name servers (which must be publicly accessible) and recursive resolvers (which generally should not be). Open recursive resolvers are a well-known amplification vector for DDoS attacks, and the overall decline suggests that operators are gradually locking them down. The 3.3 million IPs responding on DNS-over-TLS port 853 (-7.6%) represent a newer generation of encrypted DNS services; the decline there is harder to interpret and may reflect scan methodology changes rather than actual service reduction.

BGP (6.8 million IPs, +5.1%) is the most surprising entry on the list by absolute count. BGP is the routing protocol that holds the internet together, and BGP sessions are supposed to be established between specific, known peers — not open to the entire internet. 6.8 million hosts responding to BGP connection attempts suggests a massive number of misconfigured routers. While an open BGP port does not necessarily mean the router will accept route announcements from arbitrary peers, it does expose the router to resource exhaustion attacks and information disclosure.

SMB (3.3 million IPs, -2.2%) should never be exposed to the internet. SMB is the Windows file sharing protocol, and its long history of critical vulnerabilities — EternalBlue, WannaCry, NotPetya — makes every exposed SMB port a potential catastrophe. The slow decline is frustrating given how high-profile SMB exploits have been. Many of these exposed hosts are likely running older Windows versions that will never be patched.

What Is Improving and What Is Getting Worse

The trend data reveals two clear narratives.

Getting better: IoT-specific services are declining significantly. MQTT dropped 18-22% across both cleartext and TLS ports. The IoT Telnet backdoor on port 9527 fell 23%. LDAP is down 16.2%. These declines suggest that the wave of carelessly deployed IoT devices that peaked around 2016-2018 is receding as devices age out and manufacturers face increasing regulatory pressure (like the EU Cyber Resilience Act and the US Cyber Trust Mark program).

Getting worse: SSH exposure grew 20.7%, driven by cloud adoption and containerization. BGP exposure grew 5.1%, likely reflecting the deployment of new routing infrastructure without adequate hardening. Standard Telnet on port 23 grew 3.7%, indicating that new IoT devices with Telnet enabled are still being deployed faster than old ones are being retired.

The overall pattern is that legacy mistakes are slowly being cleaned up while new deployments create fresh exposure at a faster rate. The net effect is an attack surface that is shifting rather than shrinking.

Why These Services Stay Exposed

After working with this data, I see five recurring reasons why services remain exposed to the internet long after everyone agrees they should not be.

1. Default configurations favor convenience over security. Redis ships with no password. Docker exposes its API on all interfaces. SSH accepts password authentication. FTP does not encrypt anything. The defaults assume a trusted network, and the internet is not a trusted network.

2. Cloud providers assign public IPs automatically. When you launch a VPS, it gets a public IPv4 address. Every port you open on the host is immediately reachable from the entire internet. This is a fundamentally different security model from a traditional data center where a firewall sits in front of everything, but many administrators treat cloud instances like internal servers.

3. Embedded devices cannot be updated. The IP camera running Telnet on port 9527 probably cannot be firmware-updated over the network. The router exposing BGP was deployed by an ISP technician who configured it once and moved on. These devices will remain exposed until they physically fail.

4. Visibility is poor. Most organizations do not know what services they are exposing. Asset inventories are incomplete, shadow IT is ubiquitous, and scanning your own perimeter requires tools and expertise that many teams lack. You can use our port scanner to check specific hosts, but internet-wide visibility requires dedicated infrastructure.

5. There is no immediate consequence. An exposed Redis instance will work perfectly for months or years before someone exploits it. The feedback loop between misconfiguration and compromise is too slow to drive behavioral change. By the time the breach happens, the person who deployed the service has often moved on.

Recommendations

Based on what this data shows, here is what I would prioritize.

Audit your perimeter regularly. Scan your own IP ranges for exposed services monthly at minimum. Open source tools like Masscan can sweep a /16 in minutes. If you find services that should not be public — Redis, Memcached, LDAP, SMB, Telnet — close them immediately. There is no grace period for these protocols. Tools like our port scanner can verify individual hosts, but perimeter-wide scanning needs to be automated and continuous.

Use private networks for internal services. Every cloud provider offers VPCs, private subnets, and internal load balancers. Database services, caching layers, and directory services should never have public IP addresses. If a service needs to be accessed remotely, put it behind a VPN or a zero-trust proxy, not directly on the internet.

Replace legacy protocols. FTP should be replaced with SFTP or SCP. Telnet should be replaced with SSH. Unencrypted LDAP should be moved behind a VPN or replaced with a cloud identity provider. Every legacy protocol in this dataset has a more secure alternative that has been available for at least a decade.

Harden defaults at deployment time. Use infrastructure-as-code templates that include firewall rules, disable password authentication for SSH, require TLS for database connections, and restrict management interfaces to specific source IPs. The moment between "service starts" and "administrator configures firewall" is when most exposure begins.

Monitor for new exposure continuously. Services that are locked down today can be re-exposed by a configuration change, a new deployment, or an infrastructure migration. Continuous monitoring services like Shodan Monitor, CensysASM, or self-hosted alternatives should be part of your security stack. Check the security dashboard for DNS-specific exposure patterns across the TLD landscape.

The internet's attack surface is not going to disappear. As long as services need to be reachable, there will be mistakes. But the data shows that the services declining fastest are the ones where vendors changed defaults, regulators applied pressure, or high-profile breaches forced action. The path to a smaller attack surface runs through better defaults, automated hardening, and making the secure configuration the easy configuration.