Active Defense
Cut off attackers in a second. Never a customer.
Demerzel already reads your web and SSH logs to explain incidents. Active Defense acts on
them: a scanner looking for your .env is blocked about a second after asking —
with guardrails you can verify, one rule at a time.
/.env probe to a block, measured end to endWhy it exists
One scanner, 26 sites, a server on its knees.
It took one automated scanner sweeping every site on a shared server to push its load from 1 to 107. Every request was a PHP render the cache could not help with. Demerzel rebuilt the whole incident from the logs — cause, impact, timeline — without anyone opening a log file. Active Defense is what makes the next one a non-event.
- +0 min A scanner starts probing 26 sites on this server/.env, wp-login.php, vendor/phpunit…
- +6 min Hundreds of dynamic requests a minute from one addressevery page a PHP render, none cached
- +11 min Database connections climb, pages slow downimpact on 4 services
- +14 min Load reaches 107 on 8 vCPUserver metrics
- +25 min Traffic back to normal
- With Active Defense on: banned at +0S1-secret-probe fires on the first /.env, in about a second
The rules
Six rules, each one explainable.
No black box and no scoring model: every block names the rule that fired and the requests that fired it.
| Rule | Does | When an address… |
|---|---|---|
S1-secret-probe | Ban | Asks, even once, for a secret no site ever serves: .env, .git/, cloud credentials, a config backup, phpunit’s eval-stdin. |
S2-cms-probe | Ban | Fails three times to find software the server does not run: WordPress login or admin on a non-WordPress site, phpinfo, xmlrpc, actuator. What the server serves never counts. |
spread-vhosts | Ban | Hits more than 8 of the server’s sites within 10 minutes. A real visitor stays on one. |
rate-dynamic | Throttle | Sends over 300 dynamic requests in 2 minutes across your sites. Static assets do not count. |
error-ratio | Throttle | Gets a 4xx on more than 60% of at least 50 requests in 10 minutes: the shape of a fuzzer. |
ssh-bruteforce | Ban | Fails 10 SSH logins within 10 minutes. |
Bans climb a ladder: a first offence is short, a repeat is longer. Throttles slow an address down instead of shutting it out.
Guardrails
Built by people afraid of blocking their own customers.
Shadow by default
A fresh install blocks nothing. Every decision is checked and recorded, so you see what would have happened first.
Replay before you enforce
Run a rule against your own logs — at least a day and a thousand requests. It is enforced only if it would not have touched a legitimate visitor, and only in the exact version you replayed.
You are never blocked
Addresses logged in over SSH are protected automatically, and an allow list with notes covers the rest: your office, your monitoring, your partners.
Hard caps
At most 30 new blocks a minute, a bounded set size, a maximum ban length — and no address carrying over 10% of the hour’s traffic, however it behaves.
A rule that errs demotes itself
If a rule starts blocking what it shouldn’t, it falls back to shadow on its own until a new replay clears it.
One-command kill switch
demerzel-warden kill-switch on stops everything at once. And if blocks ever pile up past the caps, the warden freezes itself rather than keep going.
How it runs
The agent decides. The warden acts. Root sets the limits.
- The agent reads the logs and writes its decisions to a local spool. It still opens no port and changes nothing.
- The warden — separate binary, no network, standard library only — checks each decision against the policy and applies it to its own nftables table.
- The policy is a file only root can write. The warden refuses anything outside it, and says why.
- Demerzel shows every block in the address’s dossier, next to the evidence — and lets you lift it everywhere in one click.
# 1. install, in shadow mode $ curl -fsSL https://get.demerzel.cloud/warden.sh | sudo sh # 2. replay a rule against your own logs $ sudo demerzel-agent replay --from 2026-09-15 --to 2026-09-29 # 3. enforce what passed $ sudo demerzel-warden enable S1-secret-probe # and if you ever need to $ sudo demerzel-warden kill-switch on
FAQ
The questions a careful sysadmin asks.
Does the agent get root, or a way to run commands?
No. The agent stays read-only and outbound-only. Blocking is done by the warden — a separate, small program with no network access, which reads a policy only root can write and whose only tool is nft, on its own table. You can audit it in one sitting.
Do I need nftables?
The warden needs the nft command. Debian and Ubuntu servers running iptables-nft already have the kernel side; if only the command is missing, the installer adds it. It never enables the nftables service or touches your existing rules.
What about fail2ban?
Keep it. If you grant it, Demerzel reads fail2ban’s bans as evidence too, so an address’s dossier shows everything that was done about it, whoever did it.
What are fleet decisions?
Early access. When a server bans an attacker, your other servers can ban it too — and an unban from the dossier lifts it everywhere. Each decision is signed with your organization’s key, and a warden applies only what is signed by a key root explicitly trusted on that host.
Let it watch in shadow for a week.
Install the agent, add the warden, and read what it would have blocked. Enforce when you are convinced — not before.
14-day free trial · No credit card required