Use Cases — SvrGuard

I didn't want to hand-maintain block rules anymore

I look after a few public-facing sites for the company. People kept saying "the site feels slow" or "something's off". I pulled up the Apache access log and it was full of attack traces — someone hammering /.env, trying /wp-login.php, poking at every admin path.

I started with Apache's own way: a block module, bad addresses into a deny list. It worked, but it was a chore: I had to maintain the rules myself, and the moment an attacker changed a path or a technique my hard-coded rules missed it; what I'd blocked and why was impossible to reconstruct later, let alone hand over; and every host needed its own set, with nowhere to see them all at once.

Switching to SvrGuard took all of that off my plate:

It analyzes this host's access logs directly, judging by behavior — not one fixed signature — so morphing scans get caught too.
When it decides something is an attack, the source IP goes straight into the kernel firewall, automatically — I don't add rules by hand.
Every block leaves evidence (which address, which rule, when), so I can review it and hand it over.
Many hosts, one place to look, and a confirmed attacking source is blocked across them.

The result: I'm not babysitting logs and writing rules by hand. Morphing attacks go to behavior detection, and what I get back is the time it used to nibble away every day.

The host spiked CPU at night — it was mining for someone else

The host had felt sluggish lately, and now and then the CPU pinned at full. After a long hunt I found it: it had been breached — someone guessed an SSH password, got in, and turned my host into a crypto miner. That was the CPU.

After cleaning it up I started thinking: next time, I want to stop it before they get in, not find out afterward.

That is exactly what SvrGuard does:

SSH brute-force is blocked at the door: an address that keeps failing to log in has its IP written into the firewall at the threshold — cut off before it guesses right.
Suspicious outbound connections notify you: if the host reaches out to a common mining-pool port, SvrGuard sends a notice (often a sign a miner is already in).
Suspicious program checks: when ld.so.preload, a suspicious executable in a temp directory, or an odd cron / systemd entry changes, it points you at it.
It tells you when it can't: an attack in progress or a failed block both send a notice — nothing fails silently.

⚠️ Honestly: SvrGuard is not antivirus and will not clean out a miner that is already planted — that part is still on you. What it does is keep attacking sources out and tell you the moment something looks wrong, turning "found out after the breach" into "stopped before it."

SSH detection and blocking, and the notices for suspicious outbound connections and integrity checks, are all free. For the full list of what it stops, see the tested coverage.

Real situations: what it does for you

I didn't want to hand-maintain block rules anymore

The host spiked CPU at night — it was mining for someone else