How many attacks your server fends off while you sleep

One machine under our watch fended off nearly three thousand login attempts over two and a half days. Not a spike, not an incident, not "we got breached" — just an ordinary Tuesday for a server that faces the internet. The unsettling part isn't the three thousand; it's how easily the whole thing could have gone unnoticed. Our monitoring was recording everything — but the alert channel was half-configured, one broken setting that had been quietly swallowing every warning for days. We found it during a routine review of our own fleet: fixed one line and saw what had been going on the entire time.

Here's that story in real numbers from our own hardware — anonymized, but with nothing dressed up. The best explanation of security isn't a textbook horror story; it's what's happening on your server right now, while you're not thinking about it.

What an RDP brute-force is, and who it touches

RDP is the remote-desktop protocol — the "connect to the server from home" button millions of people rely on. By default it listens on port 3389, a number every bot on the network knows by heart. The method is boringly simple: bots sweep the internet day and night for an open 3389, and once they find one, they grind through username-password pairs by the thousand until they guess right or get shut out.

The key thing: this is not a targeted attack on you. It's background noise that hits everyone equally — the bank, the bakery, and the test server someone spun up "for five minutes" three years ago. If you or your contractor ever exposed 3389 "to make remote access convenient," congratulations: you're already in the pool. The only question is whether the door is locked — and whether you'd know if someone walked through it.

We've written before about the readers of your site you never see — harmless AI bots quietly leafing through your pages. These visitors are just as invisible, only with the opposite intent.

What the live numbers show

Start with the firewall. Over a hundred-odd days of continuous uptime it blocked 218,211 packets hammering the RDP port on one server — around two thousand a day. On another of our servers, 61,436, another six hundred daily. Those aren't even login attempts; they're aggressive sources the firewall cut off on approach with one rule: five tries from one address in a minute, and the address goes onto the block list.

The interesting part starts past that barrier. A distributed attack deliberately sidesteps the per-address limit: many sources, each knocking just a little, so the block never trips. One machine's log over the same 2.5 days showed 2,893 failed logins that reached the authentication prompt. Of those, 2,890 — exactly 99.9% — went after a single account: the built-in administrator. There were 34 sources scattered across the globe — South Korea, Germany, the USA, a handful of Asian and Latin American ranges — a textbook global botnet that couldn't care less who you are. And it didn't let up, staying in the hundreds and thousands per day: 571, then 1,242, then 1,080.

Not one got in — because administrator on that machine is disabled. But here's the number worth reading this far for. Another server — much the same, except its RDP listens on a non-standard port instead of the bare 3389 — logged all of 634 blocks over the same period. Against 218,000. Same internet, same botnets, one config parameter, and roughly three hundred times less noise at the door.

"All green" is the most expensive lie in monitoring

Now the honest part. Every one of these machines was reporting "all fine" the whole time — and that's exactly where the danger hides. Here are three traps we walked into across our own fleet during that same review.

One. A nightly backup reported success for five nights running — exit code zero, green check — while actually failing every time. The cause is typical: it ran through an intermediate launcher in fire-and-forget mode, and the scheduler saw the launcher's exit code (always zero), not the real script's. The lesson: monitor the result — the freshness of a marker file, the contents of a log — not the task status. "Completed successfully" means nothing if you never check what it actually did.

Two — the same story from the opening. A security system dutifully recorded critical events for days, and for days it couldn't tell anyone: the alert channel wasn't configured. Every task glowed green the whole time. Silent monitoring is worse than none — it hands you a false sense of calm. So the first thing to test after setting up alerts is that they actually arrive.

Three. Another machine quietly piled up more than a thousand processes — hundreds of zombies from a task that left two behind on every run and never cleaned them up. Over fifty days it exhausted virtual memory, and backups began failing with "not enough memory" — again, under the scheduler's cheerful green status. The state of processes and resources is monitoring too, not just an exit code.

Yes, these are our own mistakes, and we're showing them not out of pride, but because if we stepped on them — people who do this for a living — then anyone still trusting a green status will step on them too.

How to defend — what actually works

The good news: nothing here is exotic or expensive. This is the stack we run for ourselves and set up for clients.

If you're not the one who manages this day to day, that's fine — show this block to whoever runs your IT. It's written for them.

1. A non-standard port instead of the bare 3389. The 218,000-versus-634 gap is clear evidence it works. Not the only defense, but the cheapest first filter, and it strips away the overwhelming majority of automated noise.
2. Rate-limiting at the firewall — that same "five tries a minute from one address → block" rule. It catches lone aggressive sources before they ever reach the login.
3. Disable the built-in accounts administrator and guest. When 99.9% of attacks aim at administrator, a disabled administrator makes the whole brute-force pointless.
4. A break-glass account for emergency access — a non-standard name and a strong password in a password manager, so disabling the default one doesn't lock you out.
5. Security-event monitoring with a live alert channel — for us, the event log rolled into a short digest in a messaging app. Always with a check that the alert lands: see trap number two.
6. Manage over a private mesh network (Tailscale and the like), and remove public RDP entirely if outside access isn't needed. The most reliable way to protect an open port is a closed one.

The door they knock on every night

Three thousand attempts in two and a half days isn't because your server is interesting to anyone. It's because the internet is never that quiet for anyone: bots try every door every night, yours included. The whole difference is who's ready — one door is locked and someone will see the knock; the other shows "all green," simply because nothing was set up to raise the alarm.

We show this layer live and sanitized — the security showcase of our own site: the provider and country of each attempt, without full addresses. It's the same approach behind our Sentinel — continuous monitoring that catches what matters and stays quiet about the small stuff. And if you're curious how loud your own night is, and whether that green status is lying to you, a free audit will show you — calmly, and in numbers.