Network Exposure & Access Control - Introduction to OpenClaw

Introduction

How you expose your OpenClaw instance to the network determines your largest attack surface. A misconfigured binding or overly permissive firewall can undo every other security measure. This lesson covers network binding options, the Tailscale integration for secure private and public access, file permission requirements, and the built-in security audit tool.

Key Concepts

Loopback binding -- binding the gateway to 127.0.0.1 so it only accepts connections from the local machine
Tailscale Serve -- exposing the gateway privately within your Tailscale network (tailnet) without opening ports to the public internet
Tailscale Funnel -- exposing the gateway to the public internet through Tailscale's edge network, with automatic HTTPS
File permissions -- Unix permission modes that protect sensitive OpenClaw configuration and credential files
Security audit -- the built-in openclaw security audit command that checks configuration, permissions, and network exposure

Real World Context

Imagine your OpenClaw instance is a house. Loopback binding is like having no doors to the outside -- only people already inside can interact. Tailscale Serve adds a locked door that only family members (your tailnet) can open. Tailscale Funnel installs a door to the street with a good lock, but anyone walking by can try it. Binding to 0.0.0.0 without authentication is leaving your front door wide open with a neon sign.

Deep Dive

Network Binding Options

The gateway binding address controls which network interfaces accept connections:

yaml
gateway:
  bind: 127.0.0.1    # loopback only (default, safest)
  port: 3100

Loopback binding (127.0.0.1) is the default and the safest option. Only processes on the same machine can connect. This is ideal for local development and for deployments where you access OpenClaw through SSH tunneling or a local client.

Never bind to 0.0.0.0 without authentication:

yaml
# DANGEROUS -- do not do this in production
gateway:
  bind: 0.0.0.0
  auth:
    mode: none       # anyone on the network can connect

This combination exposes the gateway to every device on the network (and potentially the internet) with no authentication. It is the single most dangerous misconfiguration possible.

Tailscale Serve (Private Access)

When you need to access OpenClaw from other machines but want to stay private, Tailscale Serve exposes the gateway only within your tailnet:

yaml
gateway:
  bind: 127.0.0.1
  port: 3100
  tailscale:
    serve: true       # expose via Tailscale Serve
    funnel: false     # do NOT expose publicly

With this configuration, the gateway binds to loopback locally but Tailscale creates a private HTTPS endpoint accessible only to devices on your tailnet. This gives you remote access without opening any ports on your firewall.

Tailscale Serve is the recommended approach for team deployments where all members are on the same tailnet.

Tailscale Funnel (Public Access)

Funnel extends Serve by making the endpoint publicly accessible through Tailscale's edge network:

yaml
gateway:
  bind: 127.0.0.1
  port: 3100
  tailscale:
    serve: true
    funnel: true      # public HTTPS endpoint
  auth:
    mode: token       # MANDATORY with Funnel

Funnel provides automatic HTTPS and DDoS protection through Tailscale's infrastructure, but it exposes your gateway to the entire internet. When using Funnel, token authentication is absolutely mandatory. You should also combine it with restrictive pairing, mention-gating, and tight tool profiles.

Funnel is inherently riskier than Serve. Use it only when you genuinely need public access, such as for a webhook endpoint or a public-facing bot.

File Permissions

OpenClaw stores sensitive data in the ~/.openclaw/ directory. Correct file permissions prevent other users on the system from reading credentials or session data:

bash
# Required permissions
chmod 700 ~/.openclaw/              # directory: owner only
chmod 600 ~/.openclaw/openclaw.json  # config: owner read/write
chmod 600 ~/.openclaw/credentials/*  # creds: owner read/write
chmod 600 ~/.openclaw/sessions/*     # sessions: owner read/write

The permissions break down as follows:

700 on the directory means only the owner can list, read, or write files inside it. Other users cannot even see what files exist.
600 on individual files means only the owner can read or write them. No group or world access.

If these permissions are wrong, the security audit will flag them.

The Security Audit Tool

OpenClaw includes a built-in audit command that checks your entire configuration:

bash
# Basic audit
openclaw security audit

# Deep audit with additional checks
openclaw security audit --deep

# Auto-fix simple issues (like file permissions)
openclaw security audit --fix

# Machine-readable output
openclaw security audit --deep --json

The audit checks include:

Gateway authentication mode and strength
Network binding address and exposure
DM pairing configuration
Session isolation settings
Tool profiles and deny lists
File and directory permissions
Sandbox configuration
Known vulnerability patterns

The --deep flag adds additional checks like testing whether ports are actually accessible from outside and verifying Tailscale configuration. The --fix flag automatically corrects simple issues like file permissions but will not change configuration settings -- it only reports those.

The --json flag outputs structured JSON, which is useful for integrating the audit into CI/CD pipelines or monitoring systems.

Common Pitfalls

Binding to 0.0.0.0 for convenience during development and forgetting to change it -- this is the most common production security incident; always use loopback and Tailscale Serve instead
Using Tailscale Funnel without token authentication -- Funnel makes the endpoint public, so without auth anyone on the internet can send messages to your agents
Ignoring file permission warnings from the audit tool -- world-readable credentials mean any user on the system can impersonate the owner

Best Practices

Default to loopback binding and only escalate when needed -- local development uses loopback, team access uses Tailscale Serve, public access uses Funnel with full hardening
Run openclaw security audit --deep before every deployment -- catch misconfigurations before they reach production
Automate permission checks in CI/CD -- use openclaw security audit --deep --json and fail the pipeline if any critical issues are found

Summary

Loopback binding (127.0.0.1) is the default and safest network configuration; never bind to 0.0.0.0 without authentication
Tailscale Serve provides private remote access within your tailnet without opening firewall ports
Tailscale Funnel enables public access with automatic HTTPS but requires mandatory token auth and full hardening
File permissions must be 700 for ~/.openclaw/ and 600 for all files inside it
The openclaw security audit tool with --deep, --fix, and --json flags is the primary tool for verifying your security posture