Every fresh VPS is already under attack before you finish reading the welcome email

A customer deploys a server. It boots, gets a public IPv4, and does nothing else. No domain points at it, nobody has been told the address, there is no website and no service beyond the SSH daemon that ships with the base image. By any reasonable story it should be invisible. We tailed the auth log anyway, and the first failed root login attempt arrived about ninety seconds after the instance came up, from an address in a country the customer had never been to.

That number is the whole point of this post. Ninety seconds is not enough time for anyone to have learned the machine exists through any channel a human would use. Nobody learned it existed. The address was found the way every address is found now: by a program that walks the entire IPv4 space continuously, connecting to port 22 on everything, and trying a short list of common credentials on whatever answers. The customer was not targeted. The customer was enumerated.

The threat is not what people picture

Ask someone why they should secure a server and they imagine an attacker who wants their box in particular, studying it, looking for a way in. That attacker exists and is rare, and almost nobody reading this will meet one. The traffic that actually hits a fresh VPS is the opposite of that in every dimension. It is automated, indiscriminate, and running against millions of hosts in parallel. It does not know what is on your machine and does not care. It is testing a hypothesis that costs nothing to test: maybe this one has root with a guessable password, or a service with a known unpatched hole.

The economics are why it never stops. A scan of the whole address space is cheap, and the payoff for finding one weak host is real: a box to send spam from, to mine on someone else’s electricity bill, or to stage the next scan from. The attacker needs a hit rate far below one percent to profit. That math is fixed and impersonal, and it means the interesting question is never “am I a target.” Everything with an IP is a target. The only question is whether you are in the small pool of hosts weak enough to convert.

What actually gets a box owned

The successful break-ins we have seen, and the ones the whole industry keeps writing up, are almost never clever. They are three failures, over and over:

A password on SSH that a dictionary contains. root login left enabled so the attacker only has to guess one half of the pair, and the username half is a constant on every Linux box in the world. And software that was installed once and never updated, sitting on a hole that was patched upstream months ago and is now in every scanner’s playbook.

None of those is an attack in any impressive sense. They are open doors. The scanner’s entire job is to walk down the street trying handles, and it converts the ones that turn. This is good news disguised as a warning, because it means the defense is not an arms race against a smart adversary. It is closing the doors, and closed doors defeat the overwhelming majority of what will ever knock.

Five closures that end the automated threat

None of these require security expertise, and together they move a host out of the convertible pool entirely.

Authenticate SSH with a key, not a password. A key is a secret long enough that guessing it is not a strategy anyone can run. Once password authentication is disabled, the entire category of credential-guessing traffic — the ninety-second knock and everything after it — is trying to open a lock that no longer accepts the kind of thing they are sending. The attempts keep coming and keep failing by construction.

Disable direct root login. root exists on every Linux machine, so leaving it loginable hands the attacker the username for free. Create an ordinary account, give it the ability to escalate when needed, and turn off root’s own remote login. Now an attacker has to guess two unknowns instead of one, and the first unknown was the only one they previously knew.

Run a firewall that denies by default. A host exposes a port for every service, plus leftovers from things installed and forgotten. The correct posture is deny-everything, then open only what you actually serve — usually SSH, plus web ports if a site is running. A port that is closed cannot be probed, and a service you forgot you were running cannot be exploited if nothing outside can reach it.

Put a lockout in front of SSH. A tool like Fail2ban watches the auth log and bans any address that fails to authenticate several times in a row. It turns thousands of brute-force attempts into a handful before the source is dropped. It runs unattended and needs no supervision, which matters because the traffic it defends against also runs unattended and never sleeps.

Take unattended security updates. Most holes that get weaponized already have a patch; the vulnerable machines are simply the ones nobody updated. Stale software is the karst the scanners drill into. Turning on automatic security updates closes most holes before anyone on your box has to think about them, and it is the single measure most consistently skipped.

Those five are not a security program. They are the baseline that makes a host boring to a scanner, and boring is the entire goal. The tenant next to you who skips them is the hit; you are the miss the scanner moves past.

The exposure that no firewall on your box can close

Everything above assumes the machine is yours to harden. On a lot of cheap infrastructure it is not, and that is a security property people rarely price in. The common budget design packs many customers onto one large host, separated by containers. It is cheaper to run, and it means your process, your secrets, and your files share a kernel with strangers. If the isolation between tenants has a flaw — and container escapes are a recurring category, not a hypothetical — the blast radius includes your data, and none of the five closures above touches that surface. You locked your doors; the building’s interior walls were the exposure.

This is the reason Serverloka does not run that design, and we have written before about giving every agent its own kernel. Each machine is a dedicated instance, isolated at the hypervisor boundary, with root held by the customer and nobody else’s workload sharing the kernel. It costs us more to run than stacking tenants would, and we are direct about that tradeoff. For anything that holds a credential for hours — which is most of what people deploy — isolation is not a premium tier. It is the floor.

The shape of it

A fresh server is under automated fire from the moment it has an address, and that fire never lets up, because the internet is a continuous scan and your IP is one of the entries it iterates. You cannot stop the knocking; it is not aimed at you and it does not respond to anything you do. What you can do is make sure that everything knocking is trying doors that were closed before the first packet arrived. Do that, and the traffic does not go away — it just stops meaning anything. The log fills with failures you scroll past, and the machine keeps doing the one job you deployed it for.