A day in the life of a small business server under attack

Last reviewed: 18 July 2026

You've rented a server for your website or email, opened the logs for the first time, and found page after page of failed login attempts from countries you've never done business with. It looks like someone has singled you out. Almost certainly, nobody has. This page walks through what those logs actually show on an ordinary day, why the noise is normal, and the short list of things that genuinely keep a small server safe.

Minute one: the door handles get rattled

Put a fresh server on the internet and the first login attempts arrive before you've finished setting it up — often within minutes. They're not aimed at you. Automated scanners sweep the entire public internet around the clock, knocking on every address they find. When your server comes online, it simply joins the list.

The first wave goes for SSH, the remote-admin door on most Linux servers. The log fills with failed logins for usernames like "admin", "root", "test" and "user", each trying passwords from lists of millions harvested in old breaches. A different address every few tries, all day, every day. It reads like a siege. It's closer to weather.

Mid-morning: the WordPress prodding

The web logs tell a second story. Bots request the WordPress login page whether or not you run WordPress. They ask for old plugin files with known holes, forgotten backup archives, database admin panels, configuration files someone might have left in a public folder. Each request takes a fraction of a second, costs the attacker nothing, and gets logged. Multiply by every bot fleet on the internet and you get the steady background hum of any web server's access log.

The logic is brutally simple: the bots aren't looking for you, they're looking for anyone who hasn't patched. A thousand misses and one hit still pays.

Afternoon: the mail server gets the same treatment

Run your own mail and a third pattern appears: connection after connection trying to log in to email accounts with breached username-and-password pairs — credential stuffing. Others probe whether your server will forward mail for strangers, hunting for an open relay to pump spam through. A correctly configured mail server refuses all of it and writes each refusal to the log, which is exactly the pile of entries you're staring at.

Why this is normal, not personal

All of this is untargeted. Nobody chose your business; software chose your address, along with millions of others, because it exists. That distinction matters because it tells you what actually protects you. Against automated background noise you don't need to out-think an adversary — you need to not be the unpatched, password-guessable server the bots are sifting for. The noise never stops, and chasing individual entries in the log is wasted effort. What you want is a doorman.

What fail2ban does

fail2ban is a small free tool that does one job well: it watches your logs, and when one address keeps failing — wrong SSH passwords, hammering the login page, failed mail logins — it tells the firewall to drop that address for a while. Bans expire on their own; persistent offenders get banned again.

The effect on the logs is dramatic. The endless retry chains collapse: an address gets its handful of failures, gets banned, and disappears. Password guessing only works at thousands of attempts; cut each attacker to a few tries and the maths stops working. fail2ban won't stop a determined human, and it doesn't patch anything — it's noise-cancelling, not armour. But it removes the brute-force route entirely and leaves your logs quiet enough that a genuine problem stands out.

The short list that actually keeps a server safe

Four habits do more than any product you can buy:

• Keys, not passwords. Switch SSH to key-based login and turn password login off. Every password-guessing attempt in the log becomes impossible, not just unlikely. This single change retires the largest slab of the noise.
• Updates, applied. The web bots are searching for known, already-fixed holes. A server that installs security updates promptly isn't the one they're looking for. Automate it or diarise it — either way it has to actually happen.
• Minimal open ports. Every service listening on the internet is a door. Close everything the world doesn't need: databases and admin panels shouldn't face the internet at all. What isn't reachable can't be attacked.
• Backups, tested. If something does get through, a recent backup stored away from the server turns a disaster into a bad afternoon. Untested backups are a hope, not a plan — restore one occasionally to prove it works.

fail2ban sits alongside those four as the noise filter. It's not a substitute for any of them.

When the noise is worth a second look

Two things justify escalating: failed logins using real staff names rather than generic ones, which suggests someone researched you; and any successful login you can't account for. The first means it may be targeted; the second means assume compromise and get help immediately, starting with changing credentials from a machine you trust. Everything else in the log — the endless generic guessing — is just the internet being the internet.

The short version: Every internet-facing server logs a constant stream of automated break-in attempts within minutes of going online — SSH password guessing, WordPress and vulnerability probes, mail credential stuffing. It's untargeted background noise, not a campaign against you. fail2ban watches the logs and firewall-bans repeat offenders, which kills brute-force attempts and makes real anomalies visible. Actual safety comes from four habits: key-based logins, prompt updates, minimal open ports, and tested backups.

General guidance only — server security depends on your specific setup, so have yours reviewed by someone who manages servers for a living.