Summary

When OpenClaw is deployed with Docker on a VPS, users often rely on UFW and assume host firewall rules fully control published container ports. In practice, Docker port publishing is handled via forwarding chains, so INPUT-focused assumptions can be wrong without explicit DOCKER-USER policy. The docs currently explain bind/auth/firewall basics but do not include this Docker-specific hardening step.

Actual behavior

• Users can think a host firewall policy is enough while a Docker-published port remains reachable.
• There is no concrete guidance in current docs for enforcing allowlist/drop behavior in DOCKER-USER (IPv4/IPv6).
• Sanitized example from a hardened host validation flow:

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

This is the expected final state, but docs do not explain the missing Docker firewall step required to keep it that way when containers publish ports.

Expected behavior

Security docs should explicitly document Docker + UFW hardening with DOCKER-USER, including:

• why it matters
• minimal allowlist/drop policy example
• IPv6 note (after6.rules)
• validation commands (iptables -S DOCKER-USER, nmap, etc.)

Repro notes

• Environment: Ubuntu VPS + Docker Engine + UFW + OpenClaw Docker deployment
• Typical risk path:
  1. UFW is enabled and looks correct for host ports.
  2. A container is started with a published port (ports: or -p).
  3. Without explicit DOCKER-USER policy, exposure assumptions can drift.

Proposed fix

Add a focused docs section under gateway security network exposure, and add a short cross-link from Docker install docs.

I am preparing a docs PR for this issue.