Name: Inner Warden
Author: Inner Warden

The starting point

You just spun up a fresh Ubuntu 24.04 or Debian 12 VPS. Maybe Hetzner, maybe DigitalOcean, maybe Oracle Cloud free tier. SSH works on port 22, root login is enabled, and the firewall is open. According to our own honeypot data, the first SSH brute force attempt arrives within 60 seconds of the IP becoming routable.

The plan: install Inner Warden, run a scan, apply hardening, wire up phone alerts. Total wall clock time on a 1 vCPU box with a decent connection is around 8 to 12 minutes.

Open an SSH session and stay there. We will not reboot.

Minute 1 to 3: install

One command. The installer pulls the static binary, drops it in /usr/local/bin, creates a systemd unit, and starts the sensor and agent.

curl -fsSL https://www.innerwarden.com/install | sudo bash

On a 1 vCPU box this finishes in roughly 90 seconds. The binary is around 38 MB. The sensor loads its eBPF programs into the kernel, the agent opens its dashboard on127.0.0.1:8443, and the watchdog starts. No external accounts, no API keys required to start.

Sanity check:

sudo systemctl status innerwarden-sensor innerwarden-agent

Minute 3 to 5: scan first, then decide

Before changing anything on the box, get an honest picture of where it stands.

sudo innerwarden scan

You will get a score from 0 to 100 and a list of findings. On a fresh Ubuntu install, expect somewhere between 45 and 60. Common findings: SSH root login on, password authentication on, no firewall, no automatic security updates, default sysctl values for network hardening.

The scan is read-only. It writes nothing, changes nothing, touches no service. Run it as many times as you want.

Minute 5 to 7: dry run the harden, then apply

The harden command is the part that actually changes the system. Always preview it first:

sudo innerwarden harden --dry-run

You will see exactly which sysctl flags will be set, which SSH options will change, which UFW rules will be added. Read it. If anything looks wrong for your setup, skip the category with a flag like--skip ssh.

One important note: the SSH hardening will keep your current session alive but will require key-based auth on the next login. Have your SSH key already in~/.ssh/authorized_keysbefore you apply.

sudo innerwarden harden --apply

Open a second SSH session in another terminal to confirm you can still log in before you close the first one. This is a habit worth keeping for any change to sshd.

Minute 7 to 9: phone alerts

Detection without notification is just an expensive log file. Telegram is the path of least friction. Talk to@BotFatheron Telegram, create a bot, copy the token. Send a message to your bot and grab your chat id fromhttps://api.telegram.org/bot<TOKEN>/getUpdates.

Drop them into the agent config:

sudo tee -a /etc/innerwarden/agent.toml <<EOF

[notifications.telegram]
enabled = true
bot_token = "123:ABC..."
chat_id = "123456789"
min_severity = "high"
EOF

sudo systemctl restart innerwarden-agent

Test it withsudo innerwarden test notify. You should get a message on your phone in under five seconds. Setting min_severity = "high"keeps low-noise events out of your pocket. Read why false positives are a feature problem for the reasoning.

Minute 9 to 10: enable a couple of detectors

The defaults are conservative. For a public VPS, two detectors are worth turning on by hand: SSH brute force auto-block and outbound C2 detection.

sudo innerwarden detector enable ssh_brute_force \
  --auto-block --threshold 5 --window 60s

sudo innerwarden detector enable c2_beacon \
  --notify-only

Five failed SSH logins in 60 seconds and the source IP gets a 24 hour ipset block. The C2 detector watches for periodic outbound connections that look like beaconing, but only notifies, never blocks, because outbound rules tend to bite back.

What you have now

A box with key-only SSH, a sane firewall, hardened sysctl, eBPF-level visibility into syscalls, network connections, and process tree, an AI triage layer scoring incidents before they page you, and Telegram alerts on your phone.

Re-run the scan and you should land somewhere between 85 and 92 out of 100. The remaining points are usually workload-specific: TLS certs, application user segmentation, log shipping, things only you know about.

What this does not cover

Honest list of things still on you. Inner Warden does not patch your OS, you still needunattended-upgradesor equivalent. It does not handle application-level authentication, your web app still needs proper auth and rate limits. It does not back up your data. It does not replace TLS. It does not stop a zero-day in your kernel from happening, only helps you notice the aftermath.

For deeper context on what hardening actually buys you, see the Linux hardening checklist.

When to walk away

You have a single binary running with about 60 to 90 MB RSS, a dashboard athttps://your-vps:8443you can SSH-tunnel to when curious, and Telegram will tap you on the shoulder when something matters. That is the point. The whole exercise should fade into the background within an hour and stay there.

Secure Your VPS in 10 Minutes