Guía de seguridad OpenClaw 2026

Desactive por completo el acceso con contraseña

El SSH basado en contraseña es el vector más atacado en cualquier VPS. Los bots automatizados golpean el puerto 22 miles de veces por hora, probando contraseñas comunes y forzando las débiles. Generamos para usted un par de claves SSH Ed25519, instalamos la clave pública en su servidor y desactivamos permanentemente PasswordAuthentication en /etc/ssh/sshd_config. Esto hace que los ataques de fuerza bruta sean impracticables: no hay nada que adivinar.

Protección anti-fuerza bruta que banea a los atacantes

Incluso con SSH solo por clave, los bots persistentes desperdician ancho de banda y llenan los registros. Fail2ban vigila los registros de autenticación en tiempo real y bloquea automáticamente las direcciones IP tras 3 intentos fallidos durante 24 horas. Configuramos jaulas para SSH, autenticación HTTP y endpoints específicos de OpenClaw. Los reincidentes reciben bloqueos permanentes. Esto reduce notablemente el tráfico malicioso durante la primera semana.

Permitir solo los puertos 22, 80 y 443

Un firewall con política default-deny es su primera línea de defensa. Activamos UFW (Uncomplicated Firewall) con denegación por defecto para el tráfico entrante y después permitimos explícitamente solo tres puertos: 22 (SSH), 80 (HTTP para Let's Encrypt) y 443 (HTTPS). Cualquier otro puerto (incluidos los de bases de datos, el daemon Docker, Redis e interfaces de depuración) se descarta silenciosamente. Sin respuesta, sin conexión, sin rastro.

unattended-upgrades para parches de zero-day

Los CVEs críticos se parchean en cuestión de horas desde su divulgación, pero solo si su sistema está configurado para aplicarlos. Instalamos y configuramos unattended-upgrades para aplicar automáticamente los parches de seguridad del repositorio oficial de Ubuntu/Debian cada 6 horas. Las actualizaciones de kernel disparan reinicios automáticos durante una ventana de mantenimiento que usted elige (por defecto: 4:00 AM UTC). Se mantiene al día sin mover un dedo.

Nunca use el flag --privileged

Ejecutar contenedores con --privileged les da acceso root completo a la máquina host; anula por completo el propósito de la contenerización. Ejecutamos OpenClaw con las capabilities mínimas necesarias (solo NET_BIND_SERVICE), un sistema de archivos raíz de solo lectura siempre que es posible, la opción de seguridad no-new-privileges y red aislada. El contenedor no puede acceder a los dispositivos del host, ni a los módulos del kernel ni a otros contenedores.

Principio del menor privilegio

OpenClaw nunca se ejecuta como root. Creamos un usuario de sistema dedicado (openclaw) sin shell de login, sin acceso a sudo y con propiedad solo de los directorios que necesita. Si un atacante llegara a comprometer el proceso de OpenClaw, quedaría confinado a una cuenta de usuario sin poder, incapaz de escalar privilegios, modificar archivos del sistema o instalar paquetes.

Permisos de .env fijados en 600

Su archivo .env contiene claves API que valen cientos de dólares: OpenAI, Anthropic, Google, Stripe. Una sola clave filtrada puede generar una factura de 6.000 $ en una noche. Fijamos los permisos del archivo en 600 (lectura/escritura solo para el propietario), propiedad del usuario openclaw. El archivo se excluye de todos los scripts de backup y del control de versiones. También configuramos Docker secrets para los despliegues de producción donde los archivos .env son insuficientes.

Previene abusos y sobrecostes

Un endpoint de API de OpenClaw sin protección es una pasarela de IA gratuita para cualquiera que la encuentre. Configuramos rate limiting en nginx a 30 peticiones/minuto para endpoints de chat, 5 peticiones/minuto para endpoints de autenticación y 100 peticiones/minuto para assets estáticos. Los márgenes de burst gestionan los picos legítimos. Headers de rate-limit personalizados indican a los clientes cuántas peticiones les quedan. Las peticiones excesivas reciben respuestas 429, no completions de IA caras.

Restringir el acceso cross-origin

Sin configuración CORS, cualquier web de Internet puede hacer peticiones a su instancia de OpenClaw a través del navegador de un visitante. Configuramos headers CORS estrictos: solo sus dominios específicos se aceptan como origen, las credenciales requieren opt-in explícito y las respuestas preflight se cachean durante 24 horas. Esto previene la falsificación de peticiones cross-site (CSRF) y los accesos no autorizados a la API desde sitios maliciosos.

Certificados Let's Encrypt siempre válidos

Cada instalación de OpenClawPro obtiene HTTPS desde el primer día con certificados Let's Encrypt. Configuramos Certbot con renovación automática 30 días antes de la expiración, redirección HTTP-a-HTTPS, headers HSTS con un max-age de 1 año, TLS 1.2 como mínimo (TLS 1.3 preferido) y calificación A+ en SSL Labs. Sin avisos de contenido mixto, sin downtime por expiración del certificado, sin excusas.

Detectar intrusiones antes de que causen daño

Los logs son las grabaciones de su cámara de seguridad. Configuramos logrotate para todos los logs de OpenClaw, nginx y del sistema con retención de 30 días y compresión. Más importante aún, configuramos la monitorización de logs con alertas: intentos de SSH fallidos por encima del umbral, patrones inusuales de uso de la API, bucles de reinicio de contenedores y avisos de espacio en disco al 80 %. Recibe una notificación en el canal de mensajería que haya configurado (Telegram, Discord, etc.) cuando algo parece sospechoso.

Snapshots diarios automatizados

Un incidente de seguridad sin copias de seguridad es una catástrofe. Con copias de seguridad, es una molestia. Configuramos snapshots diarios automatizados de su directorio de datos OpenClaw, volúmenes Docker y archivos de configuración. Las copias se comprimen, se cifran con AES-256 y se almacenan en una ubicación separada (ya sea un directorio diferente para snapshots VPS o un bucket compatible con S3). Conservamos 7 diarias, 4 semanales y 3 mensuales. La restauración se prueba durante la instalación.