The 8 Security Layers Every OpenClaw Server Needs

SSH is the front door to your server. If an attacker can log in via SSH, every other security measure becomes irrelevant—they have shell access and can do anything the logged-in user can do. The default SSH configuration on most Linux distributions is designed for convenience, not security. That means root login is often enabled, password authentication is allowed, and the daemon listens on the standard port 22.

A hardened SSH configuration applies four changes. First, it disables root login entirely by setting PermitRootLogin no in sshd_config. Even if an attacker guesses the root password, the daemon will refuse the connection. Second, it disables password authentication with PasswordAuthentication no, requiring SSH key-based authentication instead. This eliminates the entire category of brute-force password attacks. Third, it moves SSH to a non-standard port (for example, 2222 instead of 22). This does not stop a determined attacker, but it eliminates the vast majority of automated scanning bots that only probe port 22. Fourth, it sets MaxAuthTries 3 to disconnect clients after three failed authentication attempts per session, making even targeted brute-force attempts impractical.

Together, these four changes reduce SSH attack surface by an order of magnitude. An attacker would need to discover the non-standard port, possess a valid private key, and target a non-root user account—all before the connection gets dropped after three failures.

A firewall is the most fundamental network security control. UFW (Uncomplicated Firewall) is a front-end for iptables that makes it straightforward to define which ports accept inbound traffic. The principle is simple: deny everything by default, then explicitly allow only the ports your application needs.

For an OpenClaw server, the allow list is short. Port 80 and port 443 are open for HTTP and HTTPS traffic—these are the ports your reverse proxy listens on. Your SSH port (whatever non-standard port you chose in Layer 1) is open so you can administer the server. Everything else is denied.

The critical detail here is the OpenClaw gateway port. By default, the OpenClaw gateway listens on port 18789. If this port is reachable from the public internet, anyone can send HTTP requests directly to your agents, bypassing any authentication or rate limiting you have configured at the application layer. The gateway port must never be exposed in UFW. It should only be accessible via localhost, reached through the reverse proxy (Layer 7). This single rule—never opening port 18789 in UFW—prevents an entire class of direct agent manipulation attacks.

Even with key-based SSH and a non-standard port, automated bots will eventually find your server and attempt to authenticate. This is where Fail2Ban comes in. Fail2Ban monitors log files in real time—specifically the SSH authentication log—and automatically bans IP addresses that show signs of brute-force attacks.

The configuration we recommend uses a threshold of 5 failed authentication attempts within a 10-minute window. When an IP address exceeds this threshold, Fail2Ban adds a firewall rule that blocks all traffic from that IP for 1 hour. After the ban expires, the IP is unbanned and can try again—but if it triggers the threshold a second time, it gets banned again. This creates a strong disincentive for automated scanning: a bot that could normally attempt thousands of passwords per minute is now limited to 5 attempts per hour.

Fail2Ban also protects against distributed brute-force attacks to some extent. While a sophisticated attacker using thousands of source IPs can work around it, the vast majority of credential stuffing campaigns operate from a relatively small pool of IP addresses. In practice, Fail2Ban eliminates over 99% of SSH brute-force noise on a typical public-facing server.

Software vulnerabilities are discovered constantly. The Linux kernel, OpenSSH, Docker, and every other package on your server receives security patches on a regular basis. If you are not applying these patches, you are running software with known, publicly documented vulnerabilities—vulnerabilities that attackers actively scan for.

The unattended-upgrades package on Debian and Ubuntu systems automates this process. When properly configured, it checks for security updates daily, downloads them, and installs them automatically. It can be configured to reboot the server when a kernel update requires it (during a maintenance window, of course). It sends email notifications when updates are applied, so you have an audit trail.

The reason this layer matters so much for OpenClaw specifically is the attack surface. An OpenClaw server runs Docker, a web server, a Node.js runtime, and the OpenClaw gateway itself. That is a large surface. A single unpatched CVE in any of these components can be the entry point. Automated updates ensure that the window between a vulnerability disclosure and the patch being applied on your server is measured in hours, not weeks or months.

OpenClaw runs inside a Docker container, which already provides a degree of isolation from the host system. But the default Docker configuration is not particularly restrictive. Containers run as root by default, have access to a wide range of Linux capabilities, and can potentially escalate privileges if a vulnerability in the container runtime is exploited.

A hardened Docker configuration applies three constraints. First, the OpenClaw process runs as a non-root user inside the container. This means that even if an attacker gains code execution inside the container, they land as an unprivileged user with limited ability to modify the filesystem or interact with system resources. Second, all Linux capabilities are dropped using --cap-drop=ALL. Capabilities like CAP_NET_RAW, CAP_SYS_ADMIN, and CAP_DAC_OVERRIDE are commonly abused in container escape exploits; dropping them all makes these exploits much harder. Third, --security-opt=no-new-privileges prevents any process inside the container from gaining additional privileges via setuid binaries or other escalation mechanisms.

These three settings transform the Docker container from a convenient packaging mechanism into a genuine security boundary. An attacker who compromises the OpenClaw process is confined to an unprivileged, capability-stripped sandbox with no path to the host system.

OpenClaw agents need API keys to function—your OpenAI key, Anthropic key, or other provider credentials. How you store and deliver these keys determines whether a minor server compromise becomes a catastrophic credential leak.

The first principle is to never store API keys directly in openclaw.json. Instead, reference them as environment variables (for example, $OPENAI_API_KEY) and inject them through Docker’s --env-file flag or a .env file that is not checked into version control. This ensures that your config file can be shared, backed up, or visualized in ClawChart without exposing sensitive credentials.

The second principle is restrictive file permissions. The .env file and any key material should have permissions set to 600 (readable only by the file owner). Directories containing secrets should be 700. This prevents other users on the system—including compromised service accounts—from reading your keys.

The third principle is encryption at rest. For deployments that handle high-value credentials, secrets should be encrypted using AES-256-GCM and only decrypted into memory at runtime. This protects against scenarios where an attacker gains filesystem access (for example, through a backup leak or a compromised adjacent service) but does not have access to the decryption key. The decryption key itself should be delivered through a secure channel, such as a cloud provider’s metadata service or a secrets manager like HashiCorp Vault.

The OpenClaw gateway should never be directly exposed to the internet. Instead, a reverse proxy sits between the public internet and the gateway, handling TLS termination, HTTP header injection, and request routing. Caddy is the reverse proxy we use because it obtains and renews TLS certificates automatically from Let’s Encrypt with zero configuration.

The key architectural decision is binding the OpenClaw gateway to 127.0.0.1:18789 (localhost only) rather than 0.0.0.0:18789 (all interfaces). When the gateway only listens on localhost, it is physically impossible for external traffic to reach it directly—even if the firewall is misconfigured. Caddy then proxies requests from the public HTTPS endpoint to the local gateway, adding several security headers in the process.

The most important header is Strict-Transport-Security (HSTS), which instructs browsers to only connect over HTTPS for a specified duration. Combined with a max-age of at least one year and the includeSubDomains directive, this prevents SSL stripping attacks where an attacker downgrades the connection to unencrypted HTTP. Caddy also automatically adds X-Content-Type-Options: nosniff and X-Frame-Options: DENY, preventing content type sniffing and clickjacking attacks respectively.

The auto-SSL capability is particularly important for long-running OpenClaw deployments. TLS certificates expire every 90 days, and a surprising number of self-hosted services go down or fall back to HTTP because someone forgot to renew the certificate. Caddy eliminates this risk entirely by handling renewal automatically, typically 30 days before expiration.

The first seven layers secure the infrastructure. This final layer secures the OpenClaw application itself—the configuration inside openclaw.json that determines what your agents are allowed to do. Even on a perfectly hardened server, a permissive agent configuration can lead to data leakage, unauthorized actions, or abuse.

The first setting is the DM (direct message) policy. OpenClaw supports several DM policies: open, pairing, and disabled. The recommended setting is pairing, which requires users to pair with the agent through an established channel before they can send direct messages. The open policy allows anyone to DM your agents, which can be exploited for prompt injection attacks or simply to run up your API costs by sending a high volume of messages.

The second setting is the filesystem policy. OpenClaw agents can be granted filesystem access for reading and writing files. The recommended configuration restricts this to workspace-only, which confines file operations to the agent’s designated workspace directory. This prevents an agent (or an attacker who has gained control of an agent via prompt injection) from reading sensitive files like /etc/passwd, .env files, or SSH keys.

The third setting is the exec policy. OpenClaw supports giving agents the ability to execute shell commands. For production deployments, this should be set to denied unless you have a very specific, well-sandboxed use case. An agent with exec access is essentially a remote shell—if an attacker can manipulate the agent’s instructions through prompt injection, they can execute arbitrary commands on the server. Even with Docker isolation (Layer 5), the blast radius of arbitrary command execution inside the container is significant.

These three application-level settings—pairing-only DMs, workspace-only filesystem, exec denied—form the last line of defense. They ensure that even if every other layer is somehow bypassed, the agent itself operates within tightly defined boundaries.