Process chains D1
A web server or database spawning a shell. Downloads that get executed. Programs running from /tmp or straight from memory.
A small security daemon for Linux servers. It watches processes, logins and network activity, and only speaks up when something looks like a real compromise: in your logs, Telegram, email or a webhook. No dashboard, no central server.
A web server or database spawning a shell. Downloads that get executed. Programs running from /tmp or straight from memory.
A login right after a brute-force burst. Root and first-time sources, SSH config and account changes.
Cron, systemd, SSH keys. Shell profiles, PAM, udev and the other ways back in.
New setuid files, ptrace, LD_PRELOAD and sudoers changes.
Connections from a flagged chain. New destinations and new listening ports.
Five groups, one goal. Catch a real compromise, not everyday admin work.
$ sudo hermian alerts -s high HER-2026-1015-210 HIGH Root login from a new source HER-2026-1006-415 CRITICAL Web server chain ran downloaded code journald has the rest · --json for scripts
$ sudo hermian show HER-2026-1006-415 ■■■■ HERMIAN - CRITICAL Host : web-01 Web server chain ran downloaded code Chain nginx → sh → curl → /tmp/.x Also Isolate the host unless this is expected.
$ sudo hermian collect HER-2026-0921-001 ✓ local context gathered for this alert nothing is uploaded · it stays on the host
$ sudo hermian blocked $ sudo hermian unblock <ip> Telegram buttons block a source or disconnect a session
$ sudo hermian isolate # needs management CIDRs configured first # auto-isolation is opt-in and reverts on a timer
curl -fsSL https://github.com/hermian-security/hermian/releases/download/v0.1.0-beta.7/install.sh | sudo shThe script comes from the release it installs. It uses the .deb on Debian and Ubuntu and the tarball everywhere else, always checks SHA256SUMS, and verifies where the release came from with cosign or gh if you have either. Without them it tells you, and relies on the checksum. Rather read it first? Download install.sh from the release, check it, then run it.
VER=v0.1.0-beta.7
BASE=https://github.com/hermian-security/hermian/releases/download/$VER
curl -fsSLO "$BASE/SHA256SUMS" "$BASE/SHA256SUMS.sigstore"
cosign verify-blob SHA256SUMS \
--bundle SHA256SUMS.sigstore \
--certificate-identity \
"https://github.com/hermian-security/hermian/.github/workflows/release.yml@refs/tags/$VER" \
--certificate-oidc-issuer \
https://token.actions.githubusercontent.comVER=v0.1.0-beta.7 BASE=https://github.com/hermian-security/hermian/releases/download/$VER curl -fsSLO "$BASE/SHA256SUMS" DEB=$(grep -o "hermian_.*_$(dpkg --print-architecture)\.deb" SHA256SUMS) curl -fsSLO "$BASE/$DEB" && sha256sum -c SHA256SUMS --ignore-missing gh attestation verify "$DEB" --repo hermian-security/hermian # optional sudo apt install "./$DEB" # any systemd distro: untar hermian-*-linux-*.tar.gz, then: sudo sh install.sh sudo hermian status sudo hermian test
Upgrade: rerun the installer for the new tag. Uninstall: sudo hermian uninstall.
Alerts in your chat, with optional buttons on login alerts.
Through SMTP or the local sendmail.
Slack, Discord, ntfy, or plain JSON.
Always on, even with nothing else set up.
■■■■ HERMIAN - CRITICAL Host : web-01 - Web server chain ran downloaded code : nginx started a shell that downloaded a file and is now running it as www-data. Chain nginx → sh → curl → /tmp/.x File /tmp/.x ━━━━━━━━━━━━━━━━ Web servers don't normally spawn shells. The chain then downloaded a file from the internet, which is the shape of a web shell dropped on a vulnerable app. Also 1. Isolate the host unless this is expected. ━━━━━━━━━━━━━━━━ hermian show HER-2026-1006-415
Chat gets the short version. The CLI keeps the full evidence.
Telegram buttons are optional and only appear on SSH login alerts and the brute-force digest: Block, Ignore, Disconnect session, Disconnect and block. Only the Telegram users you list can press them; anyone else is refused and logged.
Fired at the expected severity on the burn-in host.
Across 26 admin and unattended operations.
About 80k events over 3 hours.
One measured run, not a percentile.
Every figure comes from docs/EVIDENCE.md. If a number isn't there, it's unproven. See also the false-positive log and the burn-in matrix.
| HERMIAN | Wazuh | Falco | auditd | |
|---|---|---|---|---|
| Where Hermian is simpler | ||||
| Setup | One command | Manager, indexer, dashboard, agents | Driver, rules, output wiring | Write rules, parse logs yourself |
| Central server required | No | Yes | No | No |
| Ready for one host, out of the box | Five detection groups, on by default | Large ruleset you tune | Container-first defaults | None, logging only |
| Plain-language alert, in chat | Chain, why it matters, next step | Via integrations | Via Falcosidekick | — |
| Context-aware severity | Knows operator sessions | Per-rule levels | Per-rule priorities | — |
| Response from the alert | Opt-in Telegram buttons | Server-driven active response | Via add-ons | — |
| Where the others lead | ||||
| Containers and Kubernetes | — | Yes | Core strength | Host only |
| Fleet management and compliance | — | Yes | Partial | — |
| Maturity | Beta, one host validated | Mature | CNCF graduated | Linux kernel standard |
Default setups compared; each of these can be extended. Wazuh and Falco are the better fit for fleets and containers. Hermian is for hosts you look after yourself.
It's a beta with one maintainer, validated on one host so far. Parts of the code, tests and docs are written with AI help; every merge and release is done by hand (AGENTS.md).