Desplegar OpenClaw de forma segura en un VPS

OpenClaw es un asistente de IA open-source y autoalojado que se conecta a aplicaciones de mensajeria (WhatsApp, Telegram, Discord, Slack, Signal) y proveedores de modelos de IA. Ejecuta un proceso Gateway en tu servidor, recibe mensajes, ejecuta acciones de agentes usando herramientas y envia respuestas. Todos los datos permanecen en tu infraestructura.

Esta guia cubre un despliegue con enfoque en seguridad en un VPS con Ubuntu 24.04. Vas a fortalecer el sistema operativo, instalar OpenClaw, configurar la autenticacion del gateway, configurar Nginx con TLS como proxy inverso, corregir el bypass del firewall Docker/UFW, activar el sandboxing de Docker, restringir la politica de herramientas y ejecutar el gateway como un servicio systemd protegido.

Por que importa la seguridad de OpenClaw en un VPS?

OpenClaw ejecuta agentes de IA que pueden ejecutar comandos de shell, leer archivos y navegar por la web en tu servidor. Una instancia mal configurada le da a los atacantes esas mismas capacidades. Esto no es teoria.

A principios de 2026, investigadores encontraron mas de 42.000 instancias de OpenClaw expuestas en internet. El 63% eran vulnerables a explotacion remota. CVE-2026-25253 (CVSS 8.8) permitia ejecucion remota de codigo con un solo clic mediante la exfiltracion del token de autenticacion a traves de un enlace malicioso. El atacante podia robar el token del gateway, conectarse via WebSocket, desactivar las confirmaciones, escapar del sandboxing de Docker y ejecutar comandos arbitrarios.

La correccion llego en la version 2026.1.29, pero parchear no es suficiente. La seguridad requiere capas: aislamiento de red, autenticacion, TLS, sandboxing y restricciones de herramientas trabajando juntas. Una sola capa faltante (por ejemplo, autenticacion del gateway sin firewall) deja un camino directo al compromiso.

Que necesitas antes de empezar?

Requisito	Detalles
VPS	Ubuntu 24.04, 4+ vCPU, 8 GB RAM minimo
Nombre de dominio	Registro A apuntando a la IP de tu VPS (ej. openclaw.example.com)
Acceso SSH	Autenticacion por clave configurada
API key del proveedor de IA	Anthropic, OpenAI o Google Gemini
Node.js	Version 22 o superior
Docker	Engine 20+ con plugin Compose

Si necesitas ayuda para aprovisionar un VPS o configurar claves SSH, consulta Secure a Linux VPS.

Como se fortalece el VPS antes de instalar OpenClaw?

Antes de instalar nada, asegura el sistema operativo. Si ya seguiste Secure a Linux VPS y SSH Security Configuration, salta a la siguiente seccion.

Crear un usuario dedicado

Ejecutar servicios como root es un riesgo innecesario. Crea un usuario de sistema openclaw:

sudo useradd -r -m -s /bin/bash openclaw

Esto crea una cuenta de sistema con directorio home. OpenClaw almacena su configuracion en ~/.openclaw, por lo que el directorio home es necesario.

Configurar UFW

Instala y activa el firewall antes de exponer cualquier servicio:

sudo apt update && sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Verifica las reglas:

sudo ufw status verbose

Deberias ver los tres puertos permitidos y una politica de denegacion por defecto para trafico entrante. El puerto 18789 (el gateway de OpenClaw) no aparece intencionalmente. El gateway se enlaza solo a localhost y esta detras de Nginx.

Instalar fail2ban

sudo apt update && sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Verifica que esta en ejecucion:

sudo systemctl status fail2ban

La salida deberia mostrar active (running). fail2ban monitoriza los logs de SSH y bloquea IPs tras intentos repetidos de inicio de sesion fallidos.

Como se instala OpenClaw en Ubuntu?

OpenClaw soporta dos metodos de instalacion: npm (directo) y Docker. Ambos se cubren a continuacion. Elige uno. Docker es recomendado para despliegues en VPS porque el aislamiento del contenedor limita el radio de impacto si el proceso del agente se ve comprometido.

Opcion A: instalacion con Docker (recomendada)

Instala Docker si no esta presente:

sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Agrega el usuario openclaw al grupo docker:

sudo usermod -aG docker openclaw

Nota: La pertenencia al grupo docker otorga el equivalente a acceso root en el host. Es necesario para la funcionalidad Docker de OpenClaw, pero significa que el usuario openclaw puede controlar todos los contenedores del sistema. El hardening de systemd y el aislamiento del sandbox que se describen abajo limitan lo que el proceso de OpenClaw puede hacer realmente.

Cambia al usuario openclaw y configura OpenClaw:

sudo -u openclaw -i

Clona el repositorio y ejecuta el setup con la imagen precompilada oficial:

git clone https://github.com/openclaw/openclaw.git ~/openclaw-src
cd ~/openclaw-src
OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:latest ./docker-setup.sh

Establecer OPENCLAW_IMAGE indica al script que descargue la imagen precompilada de GitHub Container Registry en lugar de compilar desde el codigo fuente. El script ejecuta el onboarding e inicia el gateway mediante Docker Compose.

El gateway dentro del contenedor se enlaza a todas las interfaces por defecto (modo lan). Esto es correcto para despliegues Docker porque el mapeo de puertos de Docker necesita alcanzar el gateway dentro del contenedor. El acceso externo se bloquea a nivel de host usando reglas iptables de DOCKER-USER (se cubren mas abajo).

Verifica que el gateway esta en ejecucion:

curl -fsS http://127.0.0.1:18789/healthz

Una respuesta 200 OK confirma que el gateway esta activo. El endpoint /readyz confirma que esta listo para aceptar conexiones:

curl -fsS http://127.0.0.1:18789/readyz

Opcion B: instalacion con npm

Instala Node.js 22 usando NodeSource:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Verifica la version:

node --version

La salida deberia mostrar v22.x.x o superior.

Cambia al usuario openclaw e instala:

sudo -u openclaw -i
npm install -g openclaw@latest

Ejecuta el onboarding:

openclaw onboard

Selecciona loopback para el modo de enlace. El asistente de onboarding genera un token de autenticacion del gateway y lo almacena en ~/.openclaw/openclaw.json.

Inicia el gateway:

openclaw gateway start

Verifica:

curl -fsS http://127.0.0.1:18789/healthz

Verificar el enlace del gateway

Comprueba en que direccion esta escuchando el gateway:

ss -tulpn | grep 18789

Para instalaciones npm: La salida deberia mostrar 127.0.0.1:18789, no 0.0.0.0:18789. Si ves 0.0.0.0, deten el gateway y establece gateway.bind a "loopback" en openclaw.json.

Para instalaciones Docker: Veras 0.0.0.0:18789 del proceso docker-proxy. Esto es esperado. El mapeo de puertos de Docker publica el puerto en todas las interfaces del host para que el trafico localhost pueda alcanzar el contenedor. Las reglas iptables de DOCKER-USER (cubiertas en la seccion del firewall abajo) bloquean el acceso externo a nivel de red.

Restringir permisos de archivos

El archivo de configuracion contiene tu token de autenticacion y claves API:

chmod 700 /home/openclaw/.openclaw
chmod 600 /home/openclaw/.openclaw/openclaw.json

Verifica:

ls -la /home/openclaw/.openclaw/openclaw.json

Deberias ver -rw-------. Para instalaciones npm, el propietario es openclaw. Para instalaciones Docker, el propietario puede mostrarse como uid 1000 (el usuario node dentro del contenedor). Esto es normal y necesario para que el contenedor pueda leer la configuracion.

Como se configura la autenticacion del gateway?

El gateway de OpenClaw requiere autenticacion por defecto. Si no se configura un token ni una contrasena, el gateway rechaza las conexiones WebSocket (fail-closed). El asistente de onboarding genera un token automaticamente.

OpenClaw soporta tres modos de autenticacion:

Modo	Como funciona	Recomendado para
token	Token bearer compartido en cada solicitud	VPS de un solo usuario (recomendado)
password	Autenticacion basada en contrasena	Configuraciones multi-dispositivo
trusted-proxy	Delega la autenticacion a un proxy inverso	Configuraciones enterprise/SSO

Establecer un token fuerte

Si quieres reemplazar el token auto-generado, genera uno nuevo:

openssl rand -base64 32

Almacenalo como variable de entorno en lugar de escribirlo directamente en el archivo de configuracion. Crea un archivo de entorno:

sudo mkdir -p /etc/openclaw
sudo tee /etc/openclaw/env > /dev/null << 'EOF'
OPENCLAW_GATEWAY_TOKEN=your-generated-token-here
EOF
sudo chmod 600 /etc/openclaw/env
sudo chown openclaw:openclaw /etc/openclaw/env

Edita ~/.openclaw/openclaw.json para referenciar la variable de entorno:

{
  gateway: {
    bind: "loopback",  // use "loopback" for npm, keep default for Docker
    port: 18789,
    auth: {
      mode: "token",
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  }
}

OpenClaw soporta sustitucion ${VARIABLE} en su configuracion JSON5, de modo que el token se lee del entorno al iniciar. Para instalaciones Docker, establece la variable OPENCLAW_GATEWAY_TOKEN en el archivo .env dentro del directorio openclaw-src. El script docker-setup.sh genera este archivo automaticamente.

Reinicia el gateway y verifica que las solicitudes no autenticadas son rechazadas:

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:18789/healthz

El endpoint de salud devuelve 200 sin autenticacion (es un health check). Para comprobar que la autenticacion se aplica en el endpoint WebSocket, revisa los logs del gateway:

Para instalaciones systemd/npm:

journalctl -u openclaw-gateway --no-pager -n 20

Para instalaciones Docker:

cd ~/openclaw-src && docker compose logs openclaw-gateway --tail 20

Busca entradas auth required o connection rejected que confirmen el comportamiento fail-closed.

Como se configura Nginx como proxy inverso TLS para OpenClaw?

El gateway se enlaza a localhost. Nginx se situa delante, termina TLS y reenvia las conexiones WebSocket al gateway. Esto te da conexiones cifradas sin exponer el puerto del gateway.

Para informacion sobre proxies inversos Nginx, consulta Nginx Reverse Proxy. Para la configuracion TLS con Let's Encrypt, consulta Nginx SSL/TLS with Let's Encrypt.

Instalar Nginx y Certbot

sudo apt install -y nginx certbot python3-certbot-nginx

Obtener un certificado TLS

sudo certbot --nginx -d openclaw.example.com

Reemplaza openclaw.example.com con tu dominio real. Certbot configura la renovacion automatica.

Configurar el proxy inverso

Crea el bloque de servidor Nginx:

sudo tee /etc/nginx/sites-available/openclaw.conf > /dev/null << 'NGINX'
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name openclaw.example.com;

    ssl_certificate /etc/letsencrypt/live/openclaw.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Hide Nginx version
    server_tokens off;

    # WebSocket proxy to OpenClaw gateway
    location / {
        proxy_pass http://127.0.0.1:18789;

        # WebSocket support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Overwrite X-Forwarded-For, do not append
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;

        # Timeouts for long-running agent sessions
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name openclaw.example.com;
    return 301 https://$host$request_uri;
}
NGINX

Atencion: observa que proxy_set_header X-Forwarded-For $remote_addr usa $remote_addr (sobreescribe), no $proxy_add_x_forwarded_for (adjunta). Esto es intencional. Adjuntar permite que los clientes inyecten IPs falsas en el header. La documentacion de OpenClaw recomienda sobreescribir.

Activa el sitio y comprueba la configuracion:

sudo ln -s /etc/nginx/sites-available/openclaw.conf /etc/nginx/sites-enabled/
sudo nginx -t

La salida deberia mostrar syntax is ok y test is successful. Recarga Nginx:

sudo systemctl reload nginx

Configurar OpenClaw para confiar en el proxy

Indica al gateway que confie en los headers reenviados por Nginx agregando trustedProxies a ~/.openclaw/openclaw.json:

{
  gateway: {
    bind: "loopback",  // use "loopback" for npm, keep default for Docker
    port: 18789,
    trustedProxies: ["127.0.0.1"],
    auth: {
      mode: "token",
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  }
}

Reinicia el gateway para aplicar los cambios. Verifica que TLS funciona desde tu maquina local (no desde el servidor):

curl -I https://openclaw.example.com/healthz

Deberias recibir una respuesta 200 sobre HTTPS. Para mas hardening de seguridad de Nginx, consulta la guia de hardening de seguridad de Nginx (proximamente).

Como se corrige el bypass del firewall Docker y UFW?

Docker manipula iptables directamente, saltandose UFW por completo. Si ejecutas OpenClaw con Docker y publicas un puerto, ese puerto es accesible desde internet aunque UFW lo bloquee. Esta es una de las configuraciones erroneas mas comunes en despliegues Docker.

Para una explicacion completa de este problema, consulta Docker UFW Firewall Fix.

La solucion usa la cadena DOCKER-USER, que Docker procesa antes de reenviar trafico a los contenedores.

Bloquear todo el acceso externo a puertos Docker

sudo iptables -I DOCKER-USER -i eth0 -j DROP

Esto descarta todo el trafico de la interfaz externa (eth0) que Docker reenviaria a los contenedores. Ajusta el nombre de la interfaz si el tuyo es diferente (comprueba con ip link show).

Permitir trafico loopback

Nginx en el mismo host necesita alcanzar el contenedor del gateway en localhost:

sudo iptables -I DOCKER-USER -i lo -j ACCEPT

Permitir conexiones establecidas

sudo iptables -I DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Hacer las reglas persistentes

sudo apt install -y iptables-persistent
sudo netfilter-persistent save

Verificar las reglas

sudo iptables -L DOCKER-USER -n -v

Deberias ver las reglas ACCEPT para loopback y conexiones establecidas por encima de la regla DROP para eth0. El orden importa: iptables procesa las reglas de arriba a abajo.

Comprueba desde una maquina externa que el puerto del gateway no es alcanzable:

nmap -p 18789 your-server-ip

El puerto 18789 deberia mostrar filtered o closed, no open.

Como se activa el sandboxing de Docker para OpenClaw?

El sandboxing de Docker ejecuta las herramientas de los agentes dentro de contenedores aislados. Cuando un agente ejecuta un comando de shell o escribe un archivo, ocurre en un contenedor desechable, no en tu host.

Agrega la configuracion del sandbox a ~/.openclaw/openclaw.json:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        scope: "session",
        workspaceAccess: "none",
        docker: {
          image: "openclaw-sandbox:bookworm-slim",
          network: "none",
          user: "1000:1000",
          memory: "1g",
          cpus: 1
        }
      }
    }
  }
}

Que hace cada ajuste:

Ajuste	Valor	Efecto
mode	"all"	Cada sesion se ejecuta en sandbox, sin excepciones
scope	"session"	Cada sesion de chat obtiene su propio contenedor
workspaceAccess	"none"	El sandbox no puede ver el workspace del agente
network	"none"	Sin acceso a red desde el sandbox (previene exfiltracion)
memory	"1g"	Limita la RAM del contenedor a 1 GB
cpus	1	Limita el contenedor a 1 nucleo de CPU

Compila la imagen del sandbox:

cd ~/openclaw-src
scripts/sandbox-setup.sh

Verifica la configuracion del sandbox:

openclaw sandbox explain

Para instalaciones Docker, ejecuta via compose:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js sandbox explain

Este comando imprime el modo de sandbox efectivo, el scope, el acceso al workspace, la politica de herramientas y cualquier override. Confirma que mode: all y network: none aparecen en la salida.

Si necesitas acceso a red para herramientas especificas (por ejemplo, web_search), concedelo selectivamente por agente en lugar de cambiar el valor global por defecto. Consulta la seccion de politica de herramientas abajo.

OpenClaw bloquea por defecto las fuentes peligrosas de bind mount: /var/run/docker.sock, /etc, /proc, /sys y /dev estan todos denegados. No sobreescribas esto con bind mounts personalizados que los reexpongan. Si un contenedor sandbox necesita acceso a datos del host, usa montajes de solo lectura con rutas explicitas:

{
  agents: {
    defaults: {
      sandbox: {
        docker: {
          binds: ["/home/openclaw/shared-data:/data:ro"]
        }
      }
    }
  }
}

El sufijo :ro asegura que el contenedor puede leer los datos pero no modificarlos.

Como se restringe la politica de herramientas de OpenClaw?

La politica de herramientas (tool policy) controla que herramientas pueden usar los agentes. El sandbox tiene su propio filtro de herramientas separado de los permisos a nivel de agente. Deny siempre gana sobre allow.

Politica de denegacion por defecto

Establece un valor restrictivo por defecto en ~/.openclaw/openclaw.json:

{
  tools: {
    deny: ["exec", "write", "edit", "browser"],
    allow: ["read", "web_search"]
  }
}

Esto bloquea la ejecucion de comandos, la escritura de archivos, la edicion de archivos y el acceso al navegador por defecto. Los agentes pueden leer archivos y buscar en la web.

Perfiles por agente

Sobreescribe los valores por defecto para agentes especificos que necesitan mas acceso. Agrega perfiles bajo agents.list:

{
  agents: {
    list: [
      {
        name: "coding-agent",
        tools: {
          allow: ["exec", "read", "write", "edit"],
          deny: ["browser"]
        },
        sandbox: {
          mode: "all",
          docker: {
            network: "none"
          }
        }
      },
      {
        name: "messaging-agent",
        tools: {
          allow: ["read", "web_search"],
          deny: ["exec", "write", "edit", "browser"]
        }
      }
    ]
  }
}

El coding-agent puede ejecutar comandos pero solo dentro de un contenedor sandboxed sin red. El messaging-agent puede leer y buscar pero no puede ejecutar nada.

Desactivar el modo elevado

El modo elevado (elevated mode) permite a los agentes ejecutar comandos directamente en el host del gateway, saltandose el sandbox. Desactivalo:

{
  tools: {
    elevated: {
      enabled: false
    }
  }
}

Si dejas el modo elevado activado, cualquier usuario que pueda chatear con el agente puede potencialmente ejecutar comandos en el host. En un VPS, esto es ejecucion remota de codigo.

Aislamiento de DM multi-usuario

Si varias personas van a enviar mensajes a tu instancia de OpenClaw, activa el scoping de DM por peer. Por defecto, todos los DMs comparten una unica sesion principal. Esto significa que el Usuario A puede ver contexto de la conversacion del Usuario B.

{
  session: {
    dmScope: "per-peer"
  }
}

Esto le da a cada remitente su propia sesion con contexto aislado y contenedor sandbox.

Como se ejecuta OpenClaw como servicio systemd protegido?

Ejecutar OpenClaw bajo systemd significa que arranca con el sistema, se reinicia si falla y obtiene aislamiento de procesos mediante directivas de hardening.

Crear la unidad de servicio

Para instalaciones Docker, crea el siguiente archivo de unidad:

sudo tee /etc/systemd/system/openclaw-gateway.service > /dev/null << 'EOF'
[Unit]
Description=OpenClaw Gateway
After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/openclaw-src
EnvironmentFile=/etc/openclaw/env
ExecStart=/usr/bin/docker compose up --no-log-prefix openclaw-gateway
ExecStop=/usr/bin/docker compose down
Restart=always
RestartSec=10

# Security hardening
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/home/openclaw/.openclaw
CapabilityBoundingSet=
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictSUIDSGID=yes
MemoryMax=4G

[Install]
WantedBy=multi-user.target
EOF

Para instalaciones npm, reemplaza las lineas ExecStart y ExecStop:

ExecStart=/usr/bin/openclaw gateway start --foreground
ExecStop=/usr/bin/openclaw gateway stop

Y elimina la linea Requires=docker.service.

Que hace cada directiva de hardening:

Directiva	Proteccion
NoNewPrivileges	Impide que el proceso obtenga privilegios adicionales via setuid/setgid
PrivateTmp	Le da al servicio su propio /tmp, invisible para otros procesos
ProtectSystem=strict	Monta todo el sistema de archivos como solo lectura excepto los ReadWritePaths explicitos
ProtectHome=read-only	Impide la escritura en cualquier directorio home excepto la ruta permitida
CapabilityBoundingSet=	Elimina todas las capabilities de Linux (conjunto vacio)
ProtectKernelTunables	Bloquea escrituras a /proc/sys, /sys
ProtectKernelModules	Impide cargar modulos del kernel
MemoryMax=4G	Mata el servicio si excede 4 GB de RAM, previniendo OOM en el host

Activar e iniciar

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw-gateway

enable hace que arranque con el sistema. --now lo inicia inmediatamente.

Verifica que esta en ejecucion:

sudo systemctl status openclaw-gateway

La salida deberia mostrar active (running). Revisa los logs en busca de errores:

journalctl -u openclaw-gateway -f --no-pager -n 50

Como se verifica que el despliegue completo es seguro?

Recorre esta lista de verificacion despues del despliegue para confirmar que cada capa esta funcionando.

1. Ejecutar la auditoria de seguridad integrada de OpenClaw

Para instalaciones npm:

sudo -u openclaw openclaw security audit --deep

Para instalaciones Docker:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js security audit --deep

Esto senala configuraciones erroneas comunes: exposicion de red sin autenticacion, permisos de herramientas elevados, problemas de permisos de archivos. Corrige cualquier advertencia antes de continuar.

2. Confirmar el enlace del gateway

ss -tulpn | grep 18789

Instalaciones npm: Esperado 127.0.0.1:18789. No 0.0.0.0:18789.

Instalaciones Docker: Esperado 0.0.0.0:18789 desde docker-proxy. Esto es normal. El acceso externo esta bloqueado por las reglas iptables de DOCKER-USER.

3. Escaneo de puertos externo

Desde tu maquina local (no el servidor):

nmap -p 18789 your-server-ip

Esperado: filtered o closed.

4. Verificar TLS

curl -I https://openclaw.example.com/healthz

Esperado: 200 sobre HTTPS con un certificado valido.

5. Comprobar la aplicacion de autenticacion

curl -s -o /dev/null -w "%{http_code}" https://openclaw.example.com/

El gateway deberia requerir autenticacion para los endpoints que no sean de salud.

6. Comprobar el aislamiento del sandbox

Para instalaciones npm:

sudo -u openclaw openclaw sandbox explain

Para instalaciones Docker:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js sandbox explain

Confirma mode: all, network: none y sin overrides elevados.

7. Verificar permisos de archivos

ls -la /home/openclaw/.openclaw/openclaw.json
ls -la /etc/openclaw/env

Ambos deberian mostrar permisos 600. El archivo env pertenece a openclaw. Para instalaciones Docker, openclaw.json puede pertenecer al uid 1000 (el usuario node del contenedor).

8. Comprobar el hardening de systemd

systemd-analyze security openclaw-gateway

Esto puntua las propiedades de seguridad del servicio. Apunta a una puntuacion cercana a 5.0 o menor (menor es mas seguro). Los servicios basados en Docker tipicamente puntuan entre 5.0-5.5 porque Docker requiere acceso a namespaces e interfaces de dispositivos. Las directivas de hardening anteriores bajan la puntuacion del valor por defecto de ~9.6 a aproximadamente 5.2.

9. Verificar reglas UFW y DOCKER-USER

sudo ufw status
sudo iptables -L DOCKER-USER -n -v

UFW deberia mostrar solo los puertos 22, 80 y 443. La cadena DOCKER-USER deberia descartar el trafico externo.

10. Comprobar servicios expuestos

ss -tulpn

Solo deberian aparecer SSH (22), Nginx (80, 443) y OpenClaw (127.0.0.1:18789 para npm, o 0.0.0.0:18789 via docker-proxy para Docker).

Como se mantiene OpenClaw actualizado y respaldado?

Ocultacion de version

Oculta la version de OpenClaw en las respuestas del gateway. La divulgacion de la version ayuda a los atacantes a apuntar a vulnerabilidades conocidas. En ~/.openclaw/openclaw.json:

{
  gateway: {
    exposeVersion: false
  }
}

Combinado con la directiva server_tokens off; ya presente en la configuracion de Nginx, esto previene el fingerprinting tanto del proxy inverso como de la aplicacion.

Actualizaciones

OpenClaw publica releases frecuentemente. Comprueba la version actual:

openclaw --version

Para instalaciones Docker:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js --version

Para actualizar una instalacion Docker:

cd ~/openclaw-src
git pull
docker compose pull
docker compose up -d openclaw-gateway

Para actualizar una instalacion npm:

npm update -g openclaw

Despues de actualizar, reinicia el gateway y ejecuta de nuevo la auditoria de seguridad:

sudo systemctl restart openclaw-gateway

Para npm:

sudo -u openclaw openclaw security audit

Para Docker:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js security audit

Lee las notas de la release antes de actualizar. Los cambios incompatibles en el formato de configuracion suceden. La version 2026.3.7 introdujo un campo obligatorio gateway.auth.mode cuando tanto token como password estan presentes. Si falta despues de la actualizacion, te bloquea el acceso al gateway.

Copias de seguridad

Respalda el directorio de configuracion:

sudo tar czf /root/openclaw-backup-$(date +%Y%m%d).tar.gz /home/openclaw/.openclaw

Almacena los respaldos fuera del servidor. El directorio de configuracion contiene tus tokens de autenticacion, configuraciones de agentes y estado de las conversaciones. Protege los respaldos con el mismo cuidado que la configuracion en produccion: cifralos con gpg o guardalos en un volumen cifrado.

Gestion de logs

Visualiza logs en tiempo real:

journalctl -u openclaw-gateway -f

Los logs de OpenClaw pueden contener fragmentos de conversaciones. Establece la retencion de logs para limitar la exposicion:

sudo tee /etc/systemd/journald.conf.d/openclaw.conf > /dev/null << 'EOF'
[Journal]
MaxRetentionSec=7d
MaxFileSec=1d
EOF
sudo systemctl restart systemd-journald

Algo salio mal?

Sintoma	Causa probable	Solucion
El gateway no arranca	Puerto 18789 ya en uso	ss -tulpn | grep 18789 para encontrar el proceso en conflicto
Las conexiones WebSocket fallan a traves de Nginx	Faltan los headers Upgrade y Connection	Revisa las directivas proxy_set_header en tu configuracion de Nginx
Los contenedores sandbox no arrancan	Permisos del socket Docker	Asegurate de que el usuario openclaw esta en el grupo docker y vuelve a iniciar sesion
openclaw security audit muestra advertencias	Desviacion de configuracion tras una actualizacion	Revisa la salida de la auditoria y aplica las correcciones recomendadas
El gateway es accesible desde una IP externa	Bypass Docker/UFW	Agrega las reglas iptables de DOCKER-USER como se describio arriba
Errores de certificado TLS	La renovacion de Certbot fallo	Ejecuta sudo certbot renew --dry-run para diagnosticar
OOM kills en el VPS	Falta MemoryMax en la unidad systemd	Agrega MemoryMax=4G a la seccion [Service]

---

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproduccion, republicacion o redistribucion sin permiso escrito esta prohibida.