A single binary with zero external dependencies. One command, five minutes.
This is the shortest path, and you do not need to know which package your host wants — the script works it out: a .deb where apt is present, an .rpm where dnf / yum / zypper is, and the tarball when there is neither.
# Run as root; installs the service and starts it
curl -fsSL https://svrguard.ofuyuan.com/install.sh | sudo sh
It asks nothing — log paths are detected, and the service is registered and started for you.
Choose your platform; everything below narrows to that one.
sudo apt-get install -y ./svrguard_latest_amd64.deb
You get exactly what the one-line command installs, binary at /usr/bin/svrguard. Use apt-get, not dpkg -i: the former resolves the ca-certificates dependency, the latter leaves the package unconfigured.
Ubuntu 20.04 / 22.04 / 24.04 and Debian all take the same file — we do not build per distribution release. What actually has to hold is in "system requirements" below.
sudo dnf install -y ./svrguard_latest_x86_64.rpm
# without dnf: yum install -y ./…rpm or zypper install --allow-unsigned-rpm ./…rpm
Binary at /usr/bin/svrguard, the same result as the one-line install.
tar -xzf svrguard_latest_linux_amd64.tar.gz sudo sh svrguard/install.sh
⚠️ This one is not like the other two: it installs under /opt/svrguard, outside any package manager, so dependencies are not resolved for you.
It is also the only path that asks anything — take it if you want to name the log paths and settings yourself.
⛔ Do not use the curl … | sudo sh line above: it refuses to run on a NAS. DSM records the installed version in the package's own INFO file, and a binary put there behind Package Center's back no longer matches it — while every step still succeeds.
Control Panel → Info Center tells you the CPU; download the matching package:
.spk. DSM will warn that the publisher is not certified by Synology — Settings → Trust Level has to allow "Any publisher" to continue.⚠️ The DSM 6 package will not install here — DSM refuses it outright. The two generations are different packages, not variants of one.
⛔ Do not use the curl … | sudo sh line above: it refuses to run on a NAS, for the same reason as DSM 7 — the version of record lives in the package's INFO file.
Control Panel → Info Center tells you the CPU; download the matching package:
.spk; Settings → Trust Level has to allow "Any publisher".⚠️ The DSM 7 package will not install here, and the reverse is true too.
| Item | Requirement |
|---|---|
| Architecture | x86_64. ⛔ ARM machines running ordinary Linux are not published (Raspberry Pi, ARM cloud instances); ARM exists only as a Synology NAS package |
| Kernel | 3.13+. Native nftables blocking is tested down to kernel 4.4; older systems fall back to ipset / iptables automatically |
| Logs | Apache access / error logs (nginx needs its log directory named); SSH brute-force detection needs read access to /var/log/auth.log |
| Prerequisites | None. SvrGuard drives nftables straight through the kernel's netlink interface |
| Item | Requirement |
|---|---|
| DSM | DSM 6 and DSM 7 (tested on 6.2.4, 7.2.2 and 7.3). The two generations are different packages |
| Model | x86_64 / armv7 / arm64, one set per DSM generation |
| Prerequisites | None — no SSH, no iptables or ipset to install: blocks are written into DSM's own firewall |
Detection and blocking need no subscription and no account binding; they start as soon as the install completes. Depending on exposure, the first automatic block usually arrives within hours.
svrguard blockcheck compares the database against the kernel entry by entry and names any that did not actually take — that is the reliable one.
⭐ Its first line names the backend this host is using (Backend : …) and it prints that backend's own inspection command for you. So the table below is reference material — you do not have to work out which one you are first.
To ask the kernel yourself, the three backends are asked differently:
| Backend | How to look |
|---|---|
| nftables | nft list table ip svrguard (the rules live in the input chain) |
| ipset | ipset list -n | grep svrguard to find what the set is called, then ipset list <that name>.Also check that a rule uses it: iptables -S INPUT | grep match-set |
| iptables | iptables -S SVRGUARD_BLOCK (the chain name is upper case) |
| Synology DSM 7 | ⚠️ None of the three work here — that platform has no ipset command, and blocks reach the kernel through a small privileged helper instead. Use svrguard blockcheck. |
⚠️ There is more than one ipset set name — it varies by set type and by IPv4 / IPv6 (svrguard_block, svrguard_block_ip, …), which is why you grep for the name rather than guessing one.
⚠️ On the ipset row both halves have to hold: addresses in the set, and a rule that references that set. Either one alone blocks nothing.
Creating an account, binding this host to it and watching it from the Hub are the same on every platform, so they have a page of their own.
Pro: OTA auto-update — the agent upgrades itself when a release ships, with nothing for you to do. What separates the two is on the pricing page.
curl -fsSL https://svrguard.ofuyuan.com/upgrade.sh | sudo sh
It works out how this host was installed (deb / rpm / tarball) and upgrades the way that method needs. Already current means it does nothing, so a nightly cron entry will not reinstall anything.
Configuration and data are preserved, and it confirms the new build actually came up — if it did not, it says so, and on a tarball install it puts the previous binary back.
⚠️ Do not re-run install.sh to update. That one installs; it refuses when it finds an existing install and points you back here.
This path is verified by HTTPS alone — the packages under /dl publish no hash. OTA (Pro) goes through a signed channel; that is one real difference between the two.
Download the current package and install it with exactly the command you used the first time:
sudo apt-get install -y ./svrguard_latest_amd64.deb
# RHEL family: sudo dnf install -y ./svrguard_latest_x86_64.rpm
The package's install step stops the old service, keeps your config and database, replaces the binary, starts it and checks that it is really running.
⚠️ Do not re-run install.sh. It registers the service again, and the service is already registered — that step fails, and it fails after the binary has already been replaced. By hand, do this:
INI=/etc/svrguard/svrguard.ini # if that file does not exist, use /opt/svrguard/svrguard.ini sudo /opt/svrguard/svrguard service -config "$INI" stop tar -xzf svrguard_latest_linux_amd64.tar.gz sudo cp svrguard/svrguard /opt/svrguard/svrguard sudo /opt/svrguard/svrguard service -config "$INI" start /opt/svrguard/svrguard version # should be the new build sudo /opt/svrguard/svrguard service -config "$INI" status # must show it running
The last two lines are not optional. Replacing a file rarely fails; starting is what fails — and a stopped agent looks exactly like a healthy one, because the firewall rules stay in the kernel and go on blocking. Only the watching stops.
Your configuration and data are untouched: these four steps replace one file, /opt/svrguard/svrguard.
Pro: OTA auto-update, handled by the package itself — updates come through a signed channel that always keeps the previous build, and with no rollback target available the agent declines to update rather than strand you on a broken version.
A host with no subscription receives no supply, so it stays on the version it has until you move it. Do that from the command line over SSH — not from Package Center. Manual Install treats an existing package as a new one and asks you to remove it first, and removing it releases the host's binding to your Hub along with the package.
ARCH=armv7 # or arm64 / x86_64 — the one you installed GEN=-dsm7 # -dsm7 on DSM 7; leave this empty on DSM 6 BASE=https://svrguard.ofuyuan.com/update/agent/synology curl -fsSL "$BASE/latest-$ARCH$GEN.json" # read "url" and "sha256" from this curl -fsSL -o /tmp/svrguard.spk "$BASE/<the url from the manifest>" sha256sum /tmp/svrguard.spk # must equal the manifest's "sha256" /usr/syno/bin/synopkg install /tmp/svrguard.spk /usr/syno/bin/synopkg start SvrGuard /usr/syno/bin/synopkg status SvrGuard # must say "is started"
Read the version and hash out of the manifest rather than trusting a filename: the /dl links above always keep the same name, whatever version is behind them.
The last two lines are not optional. synopkg install exits 0 with the service stopped. Everything else still looks right — the version is new, the host is still bound, and the firewall rules stay in the kernel and go on blocking — so the only thing that changed is that nothing is watching for new attacks any more, and nothing says so. Confirm with status before you walk away.