OpenClaw Security Guide

OpenClaw's power comes from deep access to your digital life - your files, your messages, your calendars, your email. This same access, improperly secured, makes an exposed OpenClaw instance an attractive target.

Security researchers scanning the internet for exposed services found more than 42,000 OpenClaw instances accessible without proper authentication. These weren't hidden deep-web servers - they were regular users' self-hosted setups, accessible by anyone who knew the right port and URL. Some exposed web management interfaces. Some exposed raw API endpoints. Some ran with no Telegram pairing requirement, meaning any Telegram user who found the bot could issue commands.

Most of these users didn't configure their instances insecurely on purpose. They followed basic setup guides, got OpenClaw working, and didn't know what else to lock down. The default OpenClaw installation prioritizes getting started quickly over comprehensive security hardening. That's a reasonable trade-off for experienced sysadmins who know to follow up with their own hardening - it's a serious problem for everyone else.

The risks aren't theoretical. An attacker with access to your OpenClaw instance can read your memory files and extract personal information. They can use your AI credits. They can execute commands on your server. They can access any service your server can reach. In worst cases, they can move laterally to other systems.

Understanding specific attack vectors helps you evaluate whether your setup is vulnerable and what to prioritize.

Exposed ports are the most common issue. OpenClaw runs a local web server, typically on port 3000. If your firewall allows public access to port 3000, anyone can reach your OpenClaw API directly. Some attack tools automatically scan for and probe these endpoints. The fix is a firewall rule blocking all ports except the ones you explicitly need.

Weak Telegram authentication creates a different exposure vector. If dmPolicy is set to 'open' instead of 'pairing', any Telegram user who discovers your bot can interact with your assistant. Since OpenClaw bots are often discoverable via Telegram search, this can happen quickly. The fix is setting dmPolicy to 'pairing' and only completing the pairing process with your own Telegram account.

Password-based SSH is a persistent vulnerability. Brute-force attacks against SSH are automated and constant - bots continuously try common username/password combinations against every IP address on the internet. Key-only SSH authentication eliminates this attack vector entirely. With only key-based auth enabled, brute-force attacks have nothing to try.

Malicious skills represent a supply-chain risk. A skill is code that runs with your server's permissions. A compromised or malicious skill could exfiltrate your memory files, make unauthorized API calls, or install persistence mechanisms. Always review skill source code before installing, and be especially cautious with community skills that have few downloads or sparse documentation.

Unencrypted data at rest means that if someone accesses your server's storage - whether through a vulnerability or physical access - they can read everything. Without disk encryption, your MEMORY.md, your configuration files, and your AI conversation logs are readable as plain text.

PlugAndClaw applies a layered security approach to every server it provisions. These aren't optional add-ons - they're the baseline that every customer gets from minute one.

LUKS2 full-disk encryption protects your data at rest. LUKS2 is the standard Linux disk encryption system used by enterprises, governments, and security-conscious organizations worldwide. Your entire data volume is encrypted with a strong key that unlocks on boot. Even physical access to the server hardware doesn't expose your data without the encryption key.

UFW (Uncomplicated Firewall) is configured with a default-deny policy. All inbound ports are blocked except for two: port 443 (HTTPS, for Telegram webhooks) and port 22 (SSH, for your admin access). Any service that OpenClaw or any other process might open on another port is invisible from the internet. This eliminates the exposed-port attack class entirely.

Key-only SSH authentication is enforced at the configuration level. PlugAndClaw disables password authentication in `/etc/ssh/sshd_config` and installs your SSH public key during provisioning. Password brute-force attacks cannot succeed because the server won't accept passwords at all.

Caddy with automatic TLS handles all inbound HTTPS traffic. Caddy automatically obtains and renews Let's Encrypt certificates, ensuring your connections are always encrypted. It acts as a reverse proxy, terminating TLS and forwarding requests to OpenClaw internally. No unencrypted communication reaches your assistant from the outside.

Telegram pairing is enforced by default. Every PlugAndClaw instance is configured with dmPolicy set to 'pairing', meaning only your paired Telegram account can interact with your assistant. The pairing process is completed during setup, so your bot is never accessible to the general public.

If you're self-hosting OpenClaw and not using a managed service, here's the security checklist you should complete before considering your instance production-ready.

First, set up a firewall immediately after VPS provisioning - before running OpenClaw. On Ubuntu/Debian: `ufw default deny incoming && ufw allow 22/tcp && ufw allow 443/tcp && ufw enable`. Do this before exposing anything else.

Second, configure SSH key-only authentication. Generate an SSH key pair if you don't have one, add the public key to `~/.ssh/authorized_keys`, then set `PasswordAuthentication no` and `PubkeyAuthentication yes` in `/etc/ssh/sshd_config`. Restart SSH and verify key auth works before closing your current session.

Third, configure Caddy or nginx as a TLS-terminating reverse proxy. Never expose OpenClaw's application port directly to the internet. The proxy handles HTTPS; OpenClaw listens only on localhost.

Fourth, set dmPolicy to 'pairing' in your openclaw.json before starting OpenClaw for the first time. If you started with 'open', change it immediately and restart.

Fifth, enable disk encryption. This is harder to add after initial setup - it's best done when provisioning the server. Most VPS providers have a mechanism for this during OS installation.

Sixth, review any skills before installing. Read the source code, check the repository for recent activity, and verify the skill's stated functionality matches its actual code. When in doubt, don't install.

This checklist takes 2-4 hours for someone familiar with Linux. PlugAndClaw does all of it automatically during provisioning, which takes under 60 seconds.

Security isn't a one-time configuration - it's an ongoing practice. Packages get vulnerabilities. Configurations drift. New attack vectors emerge. Managed hosting handles the ongoing work so you don't have to.

PlugAndClaw monitors server operating system packages and applies security updates automatically. The Hetzner infrastructure undergoes regular security audits. TLS certificates renew automatically before expiry. You're notified if anything requires your attention.

Your dedicated VPS isolation means that other customers' activity doesn't affect your security posture. You're not sharing a container or a server - your instance is isolated at the hardware level. A security issue affecting another customer's server doesn't create a path to yours.

The OpenClaw software itself receives regular updates from the OpenClaw team. PlugAndClaw tracks these releases and applies updates to your server during maintenance windows, ensuring you benefit from security patches without having to monitor the OpenClaw changelog yourself.

For users who want to verify security themselves, every PlugAndClaw plan includes SSH access. Connect to your server, run the healthcheck skill, inspect your UFW rules, review running processes. The security configuration is transparent and auditable. You're not trusting PlugAndClaw blindly - you can verify every claim we make about your server's configuration.

With the $39.50/month plan, you get a security baseline that would take an experienced sysadmin hours to configure correctly, maintained ongoing without any effort on your part.