Fresh public IP gets first unsolicited packet 3.77 seconds after listener starts

A developer writing on dev.to reports that a never-before-used public IPv4 address drew its first unsolicited packet just 3.77 seconds after a listener started — a TLS probe aimed at port 8443 from a host in a Linode range, arriving while the machine was still under two minutes old.

The setup was a six-dollar droplet in Frankfurt running Ubuntu 24.04, paired with an IPv4 address that reportedly nobody had used before. A collector of roughly 170 lines of Python, built on the standard library alone, came online 99 seconds after the box was created and listened on 26 ports: classic service ports such as SSH, SMB, MySQL, Postgres, MongoDB and Redis, plus a spread of web ports including 80, 443, 8080 and 8443. The collector never authenticated anyone and never executed anything — it replied with plausible banners, logged what arrived as JSON, and hung up. The author's real SSH daemon was moved to a high port and excluded from every count, so the numbers measure only outside traffic.

What showed up, and how fast

Over 75 minutes the address logged 1,212 events from 84 distinct addresses across 15 ports. HTTPS traffic began about 38 seconds in, HTTP at four minutes 36 seconds, SSH at just under seven minutes, and the first password guess — username admin over telnet — at eight minutes 27 seconds. According to the post, the very first HTTP request was not for the root path but for /.env, the file where database credentials and API keys are commonly stored. Across the window, root was attempted five times and admin four.

The sources were broadly distributed: 84 addresses across 31 networks in 16 countries, with the United Kingdom leading at 31 addresses — all of them one company — followed by Iran with 14 and the United States with 13. Cloud provider ranges and consumer mobile networks appeared in the same hour against the same box.

Three ways to count, three different winners

The most consequential finding was methodological. Ranking ports by raw event count put SMB on port 445 far ahead with 890 of the 1,212 events — 73% of everything — but that figure came from just two hosts, one of which simply never stopped. Counting distinct source addresses instead made Postgres on 5432 the clear leader with 31 IPs, yet all 31 belonged to a single UK company, Driftnet Ltd, which touched exactly one port: one operator with an address pool, not 31 independent parties. Only when the author aggregated to distinct networks did the ranking stabilize, giving HTTPS 13, HTTP 7 and SSH 6 — the unremarkable but durable conclusion that web ports attract the most separate actors.

What the scanners were after

Of 165 HTTP requests carrying a path, the most common was the root path. The second most common was not a URL at all but CONNECT icanhazip.com:443, sent 53 times from four addresses — an open-proxy test that checks whether the box will relay traffic outward to a service echoing the requester's IP. /.env was fetched 16 times, and /SDK/webLanguage appeared as a probe for a specific brand of IP camera. Every single SSH client announced itself as SSH-2.0-Go, with no OpenSSH, libssh or Paramiko banners in the window. Three visitors identified themselves by user agent — Censys, zgrab, and Palo Alto Networks' Cortex Xpanse, which links to documentation of its scans — while 108 requests carried no user agent at all.

A parser that failed by succeeding

The author also documented a self-inflicted error. The collector parsed Postgres startup messages to capture guessed usernames, and reported 21 successful parses out of 43 connections. On inspection, almost all were garbage: scanners had aimed RDP and SMB payloads at port 5432, and the parser cheerfully split those non-Postgres bytes into plausible-looking dictionaries — one extracted a string containing an RDP cookie, another SMB protocol markers. Only one of the 43 connections looks like a real Postgres client. The code never raised an error; the output merely had the right shape and meaningless content.

Why it matters

The post is a compact, quantified reminder that exposure on the public internet begins at boot, not at launch. There is no grace period while you finish configuring: something probed TLS on this box within four seconds, and something asked for its /.env within five minutes. A server that is "only up for a minute while I test something" has already been indexed. For anyone running cloud infrastructure, it argues for hardening before or at provisioning — restrictive firewalls, no default credentials, nothing listening that does not need to be. It is also a caution for anyone analysing scan data: count actors, not packets, and aggregate to networks before concluding who is interested in you, because one noisy host or one company with an address pool can dominate naive metrics. None of this was targeted; it is the generic sweep every public address receives, and replicating the measurement costs less than a penny.