Desplegar OpenClaw de forma segura en un VPS

OpenClaw es un asistente de IA open-source y autoalojado que se conecta a aplicaciones de mensajería (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 envía respuestas. Todos los datos permanecen en tu infraestructura.

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

¿Por qué 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 teoría.

A principios de 2026, investigadores encontraron más de 42.000 instancias de OpenClaw expuestas en internet. El 63% eran vulnerables a explotación remota. CVE-2026-25253 (CVSS 8.8) permitía ejecución remota de código con un solo clic mediante la exfiltración del token de autenticación a través de un enlace malicioso. El atacante podía robar el token del gateway, conectarse via WebSocket, desactivar las confirmaciones, escapar del sandboxing de Docker y ejecutar comandos arbitrarios.

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

¿Qué necesitas antes de empezar?

Requisito	Detalles
VPS	Ubuntu 24.04, 4+ vCPU, 8 GB RAM mínimo
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	Versión 22 o superior
Docker	Engine 20+ con plugin Compose

Si necesitas ayuda para aprovisionar un VPS o configurar claves SSH, consulta Seguridad en Linux VPS: Amenazas, Capas y Guía de Hardening.

¿Cómo se fortalece el VPS antes de instalar OpenClaw?

Antes de instalar nada, asegura el sistema operativo. Si ya seguiste Seguridad en Linux VPS: Amenazas, Capas y Guía de Hardening y Hardening SSH en un VPS Linux: guía completa de sshd_config, salta a la siguiente sección.

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 configuración 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 política de denegación por defecto para tráfico entrante. El puerto 18789 (el gateway de OpenClaw) no aparece intencionalmente. El gateway se enlaza solo a localhost y está detras de Nginx.

Instalar fail2ban

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

Verifica que está en ejecución:

sudo systemctl status fail2ban

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

¿Cómo se instala OpenClaw en Ubuntu?

OpenClaw soporta dos métodos de instalación: npm (directo) y Docker. Ambos se cubren a continuación. 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.

Opción A: instalación con Docker (recomendada)

Instala Docker si no está 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 código 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 más abajo).

Verifica que el gateway está en ejecución:

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

Una respuesta 200 OK confirma que el gateway está activo. El endpoint /readyz confirma que está listo para aceptar conexiónes:

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

Opción B: instalación 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 versión:

node --version

La salida debería 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 autenticación 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 dirección está escuchando el gateway:

ss -tulpn | grep 18789

Para instalaciónes npm: La salida debería mostrar 127.0.0.1:18789, no 0.0.0.0:18789. Si ves 0.0.0.0, detén el gateway y establece gateway.bind a "loopback" en openclaw.json.

Para instalaciónes 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 tráfico localhost pueda alcanzar el contenedor. Las reglas iptables de DOCKER-USER (cubiertas en la sección del firewall abajo) bloquean el acceso externo a nivel de red.

Restringir permisos de archivos

El archivo de configuración contiene tu token de autenticación 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 instalaciónes npm, el propietario es openclaw. Para instalaciónes 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 configuración.

¿Cómo se configura la autenticación del gateway?

El gateway de OpenClaw requiere autenticación por defecto. Si no se configura un token ni una contraseña, el gateway rechaza las conexiónes WebSocket (fail-closed). El asistente de onboarding genera un token automáticamente.

OpenClaw soporta tres modos de autenticación:

Modo	Como funciona	Recomendado para
token	Token bearer compartido en cada solicitud	VPS de un solo usuario (recomendado)
password	Autenticacion basada en contraseña	Configuraciones multi-dispositivo
trusted-proxy	Delega la autenticación 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 configuración. 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 configuración JSON5, de modo que el token se lee del entorno al iniciar. Para instalaciónes Docker, establece la variable OPENCLAW_GATEWAY_TOKEN en el archivo .env dentro del directorio openclaw-src. El script docker-setup.sh genera este archivo automáticamente.

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 autenticación (es un health check). Para comprobar que la autenticación se aplica en el endpoint WebSocket, revisa los logs del gateway:

Para instalaciónes systemd/npm:

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

Para instalaciónes Docker:

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

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

¿Cómo se configura Nginx como proxy inverso TLS para OpenClaw?

El gateway se enlaza a localhost. Nginx se situa delante, termina TLS y reenvía las conexiónes WebSocket al gateway. Esto te da conexiónes cifradas sin exponer el puerto del gateway.

Para información sobre proxies inversos Nginx, consulta Cómo configurar Nginx como reverse proxy. Para la configuración TLS con Let's Encrypt, consulta Configurar SSL/TLS de Let's Encrypt para Nginx en Debian 12 y Ubuntu 24.04.

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 renovación automática.

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 configuración:

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

La salida debería 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. Hardening de seguridad de Nginx en Ubuntu y DebianPara más hardening de seguridad de Nginx, consulta la guía de hardening de seguridad de Nginx (próximamente).

¿Cómo se corrige el bypass del firewall Docker y UFW?

Docker manipula iptables directamente, saltándose 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 configuraciónes erroneas más comunes en despliegues Docker.

Para una explicación completa de este problema, consulta Docker ignora UFW: 4 soluciones probadas para tu VPS.

La solución usa la cadena DOCKER-USER, que Docker procesa antes de reenviar tráfico a los contenedores.

Bloquear todo el acceso externo a puertos Docker

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

Esto descarta todo el tráfico 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 tráfico loopback

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

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

Permitir conexiónes 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 conexiónes 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 debería mostrar filtered o closed, no open.

¿Cómo 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 configuración 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 exfiltración)
memory	"1g"	Limita la RAM del contenedor a 1 GB
cpus	1	Limita el contenedor a 1 núcleo de CPU

Compila la imagen del sandbox:

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

Verifica la configuración del sandbox:

openclaw sandbox explain

Para instalaciónes 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 política de herramientas y cualquier override. Confirma que mode: all y network: none aparecen en la salida.

Si necesitas acceso a red para herramientas específicas (por ejemplo, web_search), concedelo selectivamente por agente en lugar de cambiar el valor global por defecto. Consulta la sección de política de herramientas abajo.

OpenClaw bloquea por defecto las fuentes peligrosas de bind mount: /var/run/docker.sock, /etc, /proc, /sys y /dev están 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.

¿Cómo se restringe la política de herramientas de OpenClaw?

La política 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.

Política de denegación 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 ejecución 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 específicos que necesitan más 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, saltándose 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 ejecución remota de código.

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.

¿Cómo 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 instalaciónes 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 instalaciónes npm, reemplaza las líneas ExecStart y ExecStop:

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

Y elimina la línea 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 módulos 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 está en ejecución:

sudo systemctl status openclaw-gateway

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

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

¿Cómo se verifica que el despliegue completo es seguro?

Recorre está lista de verificación despues del despliegue para confirmar que cada capa está funcionando.

1. Ejecutar la auditoria de seguridad integrada de OpenClaw

Para instalaciónes npm:

sudo -u openclaw openclaw security audit --deep

Para instalaciónes Docker:

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

Esto senala configuraciónes erroneas comunes: exposicion de red sin autenticación, 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 está 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 aplicación de autenticación

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

El gateway debería requerir autenticación para los endpoints que no sean de salud.

6. Comprobar el aislamiento del sandbox

Para instalaciónes npm:

sudo -u openclaw openclaw sandbox explain

Para instalaciónes 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 instalaciónes 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 puntuación cercana a 5.0 o menor (menor es más seguro). Los servicios basados en Docker típicamente puntuan entre 5.0-5.5 porque Docker requiere acceso a namespaces e interfaces de dispositivos. Las directivas de hardening anteriores bajan la puntuación 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 debería mostrar solo los puertos 22, 80 y 443. La cadena DOCKER-USER debería descartar el tráfico 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).

¿Cómo se mantiene OpenClaw actualizado y respaldado?

Ocultacion de versión

Oculta la versión de OpenClaw en las respuestas del gateway. La divulgacion de la versión 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 configuración de Nginx, esto previene el fingerprinting tanto del proxy inverso como de la aplicación.

Actualizaciones

OpenClaw publica releases frecuentemente. Comprueba la versión actual:

openclaw --version

Para instalaciónes Docker:

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

Para actualizar una instalación Docker:

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

Para actualizar una instalación 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 configuración suceden. La versión 2026.3.7 introdujo un campo obligatorio gateway.auth.mode cuando tanto token como password están presentes. Si falta despues de la actualizacion, te bloquea el acceso al gateway.

Copias de seguridad

Respalda el directorio de configuración:

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

Almacena los respaldos fuera del servidor. El directorio de configuración contiene tus tokens de autenticación, configuraciónes de agentes y estado de las conversaciones. Protege los respaldos con el mismo cuidado que la configuración 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 retención 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 salió mal?

Síntoma	Causa probable	Solucion
El gateway no arranca	Puerto 18789 ya en uso	ss -tulpn | grep 18789 para encontrar el proceso en conflicto
Las conexiónes WebSocket fallan a través de Nginx	Faltan los headers Upgrade y Connection	Revisa las directivas proxy_set_header en tu configuración de Nginx
Los contenedores sandbox no arrancan	Permisos del socket Docker	Asegurate de que el usuario openclaw está en el grupo docker y vuelve a iniciar sesion
openclaw security audit muestra advertencias	Desviacion de configuración tras una actualizacion	Revisa la salida de la auditoria y aplica las correcciónes 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 renovación 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 sección [Service]

Proteger tu servidor de agentes IA: sandboxing, firewall y monitorizaciónPara temas de seguridad más avanzados como rate limiting y monitorizacion para servidores de agentes IA, consulta la guía de seguridad para servidores de agentes IA (próximamente).