From analyzing logs to writing firewall rules, fully automated — web and SSH detection ran on a production server in real use before they shipped.
Covers vulnerability scanning, sensitive-path probing (/.env, /wp-login.php…), 4xx error bursts, brute-force attempts and abnormal request patterns. Every verdict keeps the triggering log lines, so you can always verify why an IP was blocked.
Rules ship with every release and work out of the box. Every threshold and pattern list is editable on the host's own console.
Whether it can block something depends on whether it understands the log that program writes. These are the sources it actually reads:
| Source | What it reads | What that catches |
|---|---|---|
| Apache 2 | web access log | Scanning, sensitive paths, injection signatures, vhost sweeps |
| Apache 2 | web error log | Sources that keep trying after the server refused them |
| nginx | web access and error logs | The same — set the log directory only if nginx logs elsewhere or Apache shares the host |
| SSH (sshd) | /var/log/auth.log, /var/log/secure | SSH password brute force |
| FTP (ftpd) | the same login log | FTP login brute force, for PAM-based FTP servers |
| RDP (xrdp) | xrdp's login entries in the system log | RDP remote-desktop login brute force |
| macOS | the system log | SSH and Screen Sharing login brute force |
| Synology DSM | Web Station / reverse-proxy access logs | The web-layer attacks DSM's own auto-block cannot see |
The same rule applies to Apache and nginx alike — rules match behaviour, not a particular server. Reading the SSH auth log needs root; if it cannot, the console says so rather than skipping quietly.
Writes straight into nftables — no ipset, iptables or other tool to install; older systems fall back to ipset or iptables automatically. Native nftables blocking is tested down to kernel 4.4.
On a NAS the blocks go into DSM's own firewall (DEFAULT_INPUT) — no iptables or ipset to install.
Blocks expire by default and remove themselves — no graveyard of thousands of stale rules; repeat offenders on clear evidence escalate to a permanent block. A whitelist takes your own addresses and ranges; local NIC addresses, the private subnet each sits on, and 192.168.0.0/16 are included automatically.
GeoIP pins every attack source to a country and city; the dashboard shows block counts, event trends and firewall backend status in real time. Everything exports to CSV.
Alerts are entirely free — being able to tell you about a block is a protection tool's basic duty. There are three channels: email, syslog (collected by whatever you already run — rsyslog, syslog-ng, journald), and the console's notification log, which records every attempt, successful or not, so "did that alert actually go out?" is a question you can answer. Batching and daily digests are free too.
Every check also looks for traces an intruder commonly leaves: a backdoor set to run at boot, a program running from a temporary or hidden directory, a preload library setting with content in it (/etc/ld.so.preload); a successful password login after many failures; and this host itself connecting out to a common mining-pool port or to an address it is blocking. When it finds one, it sends you a notification and leaves the decision to you — it only notifies; it deletes nothing and cuts nothing off. It reads processes and configuration files, so it catches what an intruder leaves before hiding; a rootkit already inside the kernel is outside what it can see.
With multiple servers, each host runs a lightweight agent (local console can be fully disabled), bind to your account by confirming once in the browser, and report to a central dashboard:
Status, events and the attack map for every server on one page — version and 24-hour event count per host at a glance.
Hit "Bind to my account" in the agent console, sign in on the Hub confirmation page that opens — bound. Headless hosts use the device-code flow (svrguard pair -device). Reinstalling the same machine never needs another subscription.
Attack sources any host has confirmed (sensitive-file probes, injection, SSH brute force) are reviewed by hand and sent out daily as a signed list, and blocked in advance everywhere else. Only evidence ordinary use cannot produce is shared.
DSM's built-in auto-block counts failed logins. It stops someone guessing your DSM password, but it never sees the web-layer attacks — probes for /.env, attempts on /wp-login.php, sweeps across the sites behind your reverse proxy. To DSM those are ordinary HTTP connections.
SvrGuard analyzes the Web Station / reverse-proxy access logs, judges them with the same rules, and writes the source address into DSM's own firewall (rules go in DEFAULT_INPUT — no iptables or ipset to install). The photos and files on a NAS are worth more than a throwaway cloud box, and it is the one that sits exposed all day.
Package Center → Manual Install. Builds for x86_64, armv7 and arm64. Removing the package keeps your database and settings.
Updates come through a dedicated channel with an Ed25519 signature, and the channel always keeps the previous build — with no rollback target to fall back on, the agent declines to update rather than strand you on a bad version.
Your NAS binds to the same account as everything else, on one page. Binding needs no subscription.
CPU, memory and disk usage, with threshold alerts — server trouble reaches you through the same channel as attack events, no separate monitoring stack needed. Collection runs with or without a subscription, so the moment you subscribe you see the history rather than a blank page. What Pro buys is being told when a threshold is crossed, and the 24-hour / 7-day history curves in this machine's own console. The samples stay on the machine; nothing is uploaded.
