OpenClaw VPS Server Hardening

Harden a Hostinger VPS running OpenClaw agents against unauthorized access, brute force, and exposure. Use when securing a publicly-deployed OpenClaw instanc...

Security Scan

The skill's instructions and script are coherent with a VPS hardening purpose: it requires root to make system changes, does not request unrelated credentials, and contains no hidden network exfiltration — but there are a few implementation/operational caveats you should review before running it on production systems.

Purpose & Capability

Name/description match the included artifacts: the SKILL.md documents a Cloudflare-based hardening workflow and the repository contains a harden.sh script that implements UFW, SSH, Fail2Ban, OpenClaw binding, unattended upgrades, and file-permission changes. All requested actions are consistent with server hardening.

Instruction Scope

Instructions are focused on hardening and explicitly warn about lockout risk and the need to verify Cloudflare Tunnel before closing ports. The script runs as root and modifies system services and config files (expected). Minor issues: some configuration templates (Fail2Ban heredoc) include an unexpanded ${SSH_PORT} token (so the generated jail file may not contain the numeric port), and the sshd_config backup/revert logic uses the same date expression which can make automated revert brittle. These are operational bugs rather than evidence of malicious behavior, but they increase lockout risk if not tested.

Install Mechanism

No install spec; this is instruction-only with an included script. The script uses apt-get to install packages (ufw, fail2ban, unattended-upgrades) which is appropriate for the stated task. There are no downloads from untrusted URLs or archive extraction steps.

Credentials

The skill declares no environment variables or credentials. The SKILL.md and script do reference local files (OpenClaw config, cloudflared credentials) which is appropriate for a hardening tool. No external secrets or unrelated service credentials are requested.

Persistence & Privilege

always is false and the skill does not request persistent platform-level privileges or modify other skills' configurations. It makes system-level changes on the host when run as root (normal for a hardening script).

Assessment

This skill appears to be what it says: a system hardening workflow plus a script that should be run as root on the target VPS. Before installing/running: 1) Test in a snapshot or staging VM first (hardening changes, especially SSH port and firewall rules, can lock you out). 2) Always run the script with --dry-run first and verify Cloudflare Tunnel is active; the script itself warns and asks for confirmation if cloudflared is not running. 3) Manually verify SSH key presence and test SSH on the new port from a new terminal before closing the old session. 4) Review the script for small implementation issues (Fail2Ban config uses a literal ${SSH_PORT} which may not expand; backup/revert of sshd_config depends on date-based file names and can be brittle) and adjust if necessary. 5) Confirm OpenClaw's actual config directory and service name on your system (defaults point to /root/.openclaw and systemd unit openclaw) and pass --openclaw-dir / --openclaw-user if different. 6) Review Cloudflare Access/service-token guidance and ensure you rotate/revoke any service tokens and secure the Cloudflare account with MFA. If you are not comfortable with root-level changes, have an experienced sysadmin review and run these steps.

Seven-layer defense-in-depth strategy for OpenClaw agents on Hostinger VPS. Built around Cloudflare Tunnel + Access as the primary access layer — port 18789 is never exposed to the internet.

The Strategy (Cloudflare-Based)

Internet → Cloudflare Edge
             ├── Cloudflare Access (identity check — blocked if unauthenticated)
             └── Cloudflare Tunnel (outbound-only from VPS)
                   └── localhost:18789 (OpenClaw — loopback only)
                         └── OpenClaw token auth (second factor)

Internet → port 2222 (SSH — key-only, fail2ban)
Internet → port 18789 ✗ (denied by UFW — invisible to port scan)

With Cloudflare active: the VPS has one open port (SSH). Everything else is invisible.

---

Quick Start

Step 1 — Deploy OpenClaw first

Use the openclaw-vps-deploy skill. Get the agent running before hardening.

Step 2 — Set up Cloudflare Tunnel + Access

Use the cloudflare-agent-tunnel skill. Verify the agent is accessible at https://agent.yourdomain.com before closing port 18789.

Step 3 — Run the hardening script

# Copy script to VPS
scp scripts/harden.sh root@SERVER_IP:/tmp/harden.sh

# Dry run first — see what will change
ssh root@SERVER_IP "bash /tmp/harden.sh --dry-run"

# Apply (opens new terminal first to test SSH on new port)
ssh root@SERVER_IP "bash /tmp/harden.sh --ssh-port 2222"

Step 4 — Test before closing old session

# In a NEW terminal — verify SSH works on new port BEFORE closing old session
ssh -p 2222 root@SERVER_IP "echo OK"

# If that works, close old session. If it fails, revert:
# ssh root@SERVER_IP "cp /etc/ssh/sshd_config.bak.YYYYMMDD /etc/ssh/sshd_config && systemctl reload sshd"

---

The Seven Layers

Layer 1 — UFW Firewall

• Default deny all inbound
• Allow only SSH on custom port (default: 2222)
• Deny 18789 explicitly (served via Cloudflare Tunnel — never public)
• Port 18789 invisible to internet port scans

Layer 2 — SSH Hardening

• Move SSH off port 22 (eliminates automated scanner noise)
• Disable root login (PermitRootLogin no)
• Key-only auth (PasswordAuthentication no)
• Max 3 auth attempts, 30s login grace period
• Auto-disconnect idle sessions after 10 minutes

Layer 3 — Fail2Ban

• Protects SSH: 3 failures = 24-hour ban
• DDoS variant: 10 attempts in 60s = 1-hour ban
• With Cloudflare handling app layer, no custom OpenClaw filter needed

Layer 4 — OpenClaw Loopback Binding

• Change gateway.bind from "lan" to "loopback"
• OpenClaw listens only on 127.0.0.1 — unreachable from outside VPS
• Even if UFW rules are wrong, direct access is impossible

Layer 5 — Unattended Security Upgrades

• Auto-applies Ubuntu security patches
• No automatic reboots (manual reboot control)
• Patches CVEs without manual intervention

Layer 6 — File Permissions

• ~/.openclaw/ → mode 700
• openclaw.json, secrets.json → mode 600
• ~/.cloudflared/ → mode 700, credentials → mode 600
• SSH authorized_keys → mode 600

Layer 7 — Cloudflare Access (Identity Gate)

• Every request requires authentication before reaching VPS
• Supports Google SSO, email OTP, GitHub
• Per-agent policies (each subdomain has its own allowlist)
• Service tokens for native phone app connections (no browser flow required)
• Free up to 50 users; $3/user/month Access-only beyond that

See references/cloudflare-access.md for full setup walkthrough including phone app service token configuration.

---

Cloudflare Access for Native Phone Apps

For a native mobile app connecting directly to agents without browser-based login:

1. Create a Service Token in Zero Trust → Access → Service Auth
2. App sends two headers on every request:

   CF-Access-Client-Id: <id>.access
   CF-Access-Client-Secret: <secret>
   

3. No browser redirect, no JWT expiry — token is permanent until rotated
4. One service token per app, revoke if compromised

See references/cloudflare-access.md → Phone App Integration for full details.

---

Script Options

bash harden.sh [options]

--ssh-port 2222        SSH port to open (default: 2222)
--openclaw-user koda   Service user for OpenClaw (default: koda)
--openclaw-dir /path   OpenClaw config directory (default: /root/.openclaw)
--dry-run              Print changes without applying
--skip-ufw             Skip UFW configuration
--skip-ssh             Skip SSH hardening
--skip-fail2ban        Skip Fail2Ban installation
--skip-upgrades        Skip unattended upgrades

---

Order of Operations (Critical)

Wrong order = lockout. Always:

1. ✅ Deploy OpenClaw (openclaw-vps-deploy)
2. ✅ Set up Cloudflare Tunnel + verify HTTPS access works
3. ✅ Dry-run harden.sh
4. ✅ Apply harden.sh
5. ✅ Test SSH on new port in new terminal
6. ✅ Verify agent still accessible via Cloudflare URL
7. ✅ Close old terminal

---

Threat Model

See references/threat-model.md for full attack surface analysis, what each layer defends against, and residual risks.

Security posture after hardening: A- One open port (SSH). Agents invisible to port scan. Identity gate on every connection. TLS everywhere. Brute-force protection. Auto-patched OS.