Manual de exposición del Gateway

​

Elegir el patrón de exposición

​

Inventario previo

• Host, usuario del sistema operativo y directorio de estado del Gateway (valor predeterminado: ~/.openclaw).
• URL y modo de enlace del Gateway (gateway.bind; puerto predeterminado: 18789).
• Modo de autenticación, origen del token o la contraseña, u origen de identidad del proxy de confianza.
• Cada canal habilitado y si acepta mensajes directos, grupos o webhooks.
• Agentes accesibles para remitentes no locales.
• Perfil de herramientas, modo de aislamiento y política de herramientas con privilegios elevados de cada agente accesible.
• Credenciales externas disponibles para esos agentes.
• Ubicación de la copia de seguridad de ~/.openclaw/openclaw.json y de las credenciales.

​

Comprobaciones de referencia

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

​

Referencia mínima segura

{
  gateway: {
    bind: "loopback",
    auth: {
      mode: "token",
      token: "replace-with-a-long-random-token",
    },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  agents: {
    defaults: {
      sandbox: { mode: "non-main" },
    },
  },
  tools: {
    profile: "messaging",
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}

​

Exposición de mensajes directos y grupos

• Prefiera dmPolicy: "pairing" o una lista allowFrom estricta en lugar de dmPolicy: "open".
• No combine listas de permitidos "*" con un acceso amplio a herramientas.
• Exija menciones en los grupos, a menos que la sala esté estrictamente controlada.
• Configure session.dmScope: "per-channel-peer" (o "per-account-channel-peer" para canales con varias cuentas) cuando varias personas puedan enviar mensajes directos al bot, para que las sesiones de mensajes directos no compartan contexto.
• Dirija los canales compartidos a agentes con herramientas mínimas y sin credenciales personales.

​

Comprobaciones del proxy inverso

• El proxy debe autenticar a los usuarios antes de reenviar tráfico al Gateway.
• El firewall o la política de red deben bloquear el acceso directo al puerto del Gateway.
• gateway.trustedProxies debe incluir únicamente las direcciones IP de origen del proxy.
• El proxy debe eliminar o sobrescribir los encabezados de identidad y reenvío proporcionados por el cliente.
• Configure gateway.auth.trustedProxy.allowUsers cuando el proxy atienda a más de una audiencia.
• Use gateway.auth.trustedProxy.allowLoopback solo para un proxy en el mismo host donde se confíe en los procesos locales y el proxy controle los encabezados de identidad.

​

Revisión de herramientas y aislamiento

• Confirme qué sesiones se ejecutan en el host y cuáles en el entorno aislado.
• Deniegue la ejecución en el host o exija aprobación para ella.
• Mantenga deshabilitadas las herramientas con privilegios elevados, salvo que las necesite un remitente específico y de confianza.
• Evite las herramientas de navegador, lienzo, Node, Cron, Gateway y creación de sesiones en superficies de mensajería abiertas o parcialmente abiertas.
• Mantenga restringidos los montajes enlazados; evite las rutas de credenciales, del directorio personal, del socket de Docker y del sistema.
• Use gateways, usuarios del sistema operativo o hosts independientes para límites de confianza sustancialmente diferentes.

​

Validación posterior a los cambios

1. Ejecute de nuevo openclaw security audit --deep.
2. Confirme que se establece correctamente una conexión autorizada.
3. Confirme que se rechaza a un remitente o una sesión de navegador no autorizados.
4. Confirme que los registros ocultan los secretos.
5. Confirme que el enrutamiento de mensajes directos y grupos llega únicamente al agente previsto.
6. Confirme que las herramientas de alto impacto solicitan aprobación o se deniegan.
7. Documente las advertencias residuales aceptadas.

​

Plan de reversión

{
  gateway: {
    bind: "loopback",
  },
  channels: {
    whatsapp: { dmPolicy: "disabled" },
    telegram: { dmPolicy: "disabled" },
    discord: { dmPolicy: "disabled" },
    slack: { dmPolicy: "disabled" },
  },
  tools: {
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}

1. Detenga el reenvío público, Tailscale Funnel o las rutas del proxy inverso.
2. Rote los tokens o contraseñas del Gateway y las credenciales de integración afectadas.
3. Elimine "*" y los remitentes inesperados de las listas de permitidos.
4. Revise los registros de auditoría recientes, el historial de ejecuciones, las llamadas a herramientas y los cambios de configuración.
5. Ejecute de nuevo openclaw security audit --deep.
6. Vuelva a habilitar el acceso con el patrón más restrictivo que satisfaga el flujo de trabajo.

​

Lista de verificación de la revisión

• El Gateway sigue siendo accesible solo mediante loopback, salvo que exista un motivo documentado.
• El acceso que no usa loopback cuenta con autenticación y firewall, y no dispone de ninguna ruta pública directa.
• Las implementaciones con proxies de confianza tienen direcciones IP de proxy estrictas y controles de encabezados.
• Los mensajes directos usan emparejamiento o listas de permitidos, no acceso abierto de forma predeterminada.
• Los grupos exigen menciones o listas de permitidos explícitas.
• Los canales compartidos no pueden acceder a credenciales personales.
• Las sesiones secundarias se ejecutan en modo aislado.
• La ejecución en el host y las herramientas con privilegios elevados se deniegan o requieren aprobación.
• Los registros ocultan los secretos.
• Los hallazgos críticos de la auditoría están resueltos.
• Los pasos de reversión están probados y documentados.