| name | openclaw-security |
| description | Security hardening and connectivity checklist for OpenClaw installations running on EC2.
Use when setting up OpenClaw on a new EC2 instance, when the instance has been attacked
by bots, when disk/CPU spikes, or when reviewing how to connect securely (Tailscale, SSM,
SSH). Covers rate limiting, fail2ban, SSM Session Manager, Tailscale-only access, and
AWS security group hygiene.
|
| triggers | ["OpenClaw security","hardening","ataque bot","saturación cpu nginx","conectar EC2 sin SSH","SSM session manager","cerrar puerto 22","rate limit","fail2ban"] |
| tools | ["exec","read","write"] |
| distribute-to | ["claude"] |
OpenClaw Security Skill
Blueprint para que una instancia de OpenClaw en EC2 sobreviva ataques de bots y no se
tumbe por saturación de CPU/RAM. Documenta también las tres formas seguras de conectarte
a OpenClaw y cuándo usar cada una.
TL;DR del modelo mental
OpenClaw corre en una EC2 con:
- nginx expuesto al internet (80/443) para dashboards y landings
- puerto 22 (SSH) que por default está abierto al mundo
- Tailscale corriendo dentro (red privada entre tus máquinas)
- SSM Session Manager disponible (conexión vía AWS console, sin puertos abiertos)
La regla de oro: nginx recibe del mundo, SSH nunca. SSH es para Tailscale o SSM.
Parte 1: Las tres formas de conectarte a OpenClaw
1. Tailscale (el canal principal para uso diario)
Ya está instalado. IPs típicas:
- EC2 OpenClaw:
100.117.155.74 (ejemplo — revisar con tailscale ip)
- Mac laptop:
100.72.67.120 (ejemplo)
Conexión desde tu lap:
ssh ec2-user@100.117.155.74
ssh ec2-user@jarvis-v3
Ventaja: sin abrir nada al mundo. Cifrado de punta a punta. Tailscale gestiona la identidad.
2. AWS SSM Session Manager (el canal de emergencia)
amazon-ssm-agent.service debe estar active (running).
Conexión desde tu lap con AWS CLI:
aws ssm start-session --target i-XXXXXXXXXXXXXXXXX --region us-east-1
O desde la consola AWS: EC2 → Instances → Connect → Session Manager.
Ventaja: no necesita SSH abierto, no necesita llave, auditado en CloudTrail. Ideal cuando
Tailscale no responde o la IP pública cambió.
Requisitos:
- SSM Agent corriendo en la instancia (viene preinstalado en Amazon Linux 2023)
- IAM role de la instancia con policy
AmazonSSMManagedInstanceCore
- Subnet con acceso a internet o endpoints VPC para
ssm, ssmmessages, ec2messages
3. SSH directo a IP pública (solo si las dos de arriba fallan)
Si y solo si Tailscale y SSM no funcionan, abrir temporalmente el puerto 22 a tu IP pública
actual (no a 0.0.0.0/0). Revisar tu IP de salida:
curl ifconfig.me
Cerrar inmediatamente cuando termines.
Parte 2: Protecciones aplicadas (y cómo se verifican)
Rate limit en nginx (bloquea abusadores antes de que saturen CPU)
Archivo: /etc/nginx/conf.d/00-rate-limit.conf
Define tres zonas:
general: 10 requests/segundo por IP (burst 20)strict: 2 requests/segundo para endpoints sensiblesperip: máx 20 conexiones simultáneas por IP- map
$bad_bot: devuelve 429 a scrapers conocidos (ahrefs, semrush, gptbot, bytespider,
python-requests con user agent default, wget, curl sin customizar)
Verificar:
sudo nginx -T 2>/dev/null | grep -E "limit_req_zone|limit_conn_zone|bad_bot"
sudo nginx -t
Si se modifica, recargar:
sudo systemctl reload nginx
fail2ban (banea IPs que abusan de nginx o hacen brute force SSH)
Archivo: /etc/fail2ban/jail.d/nginx.conf
Jails activos:
sshd (default) — banea IPs que fallan login SSH repetidamentenginx-limit-req — banea IPs que disparan el límite de nginx
Verificar:
sudo fail2ban-client status
sudo fail2ban-client status nginx-limit-req
sudo fail2ban-client status sshd
sudo fail2ban-client banned
Política:
findtime = 600 (ventana de 10 min)maxretry = 10 (disparos al limit_req antes de banear)bantime = 7200 (2 horas baneado)
CloudWatch Agent (observabilidad de RAM y disco desde consola AWS)
Por default AWS muestra CPU, red y disco del hipervisor, NO muestra RAM ni swap. Con
CloudWatch Agent expones esas métricas a la consola AWS.
Instalación:
sudo dnf install -y amazon-cloudwatch-agent
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
sudo systemctl enable --now amazon-cloudwatch-agent
Requiere IAM role con CloudWatchAgentServerPolicy attach.
Verificar:
sudo systemctl status amazon-cloudwatch-agent
Parte 3: Checklist de hardening para nuevo OpenClaw
Cuando el usuario diga "estoy instalando OpenClaw en nueva EC2" o "configura seguridad",
sugiere este orden:
Fase 1 — Día 1 (obligatorio)
Fase 2 — Día 1 (en cuanto nginx expone algo al mundo)
Fase 3 — Semana 1 (observabilidad)
Fase 4 — Opcional pero ideal
Parte 4: Señales de que estás bajo ataque o saturación
Síntomas que debe detectar OpenClaw
- CPU > 85% sostenido por 10+ minutos
- Load average > número de vCPUs durante 5+ minutos
- Swap usage > 500 MB (indica RAM llena)
- Disco > 90% (matará procesos tarde o temprano)
- nginx
limit_req disparándose (ver error.log)
- fail2ban baneando IPs nuevas cada minuto
Comandos de triaje rápido
free -h && df -h / && uptime
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
sudo awk -F\" '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
ps aux --sort=-rss | head -15
sudo tail -50 /var/log/nginx/error.log | grep "limit_req"
sudo fail2ban-client banned
sudo zgrep "Ban " /var/log/fail2ban.log* | tail -20
sudo dmesg -T | grep -iE 'oom|killed process' | tail -10
Respuesta ante saturación activa
- Identificar IP(s) atacante(s) con
awk sobre access.log
- Banear manual:
sudo fail2ban-client set nginx-limit-req banip <ip>
- Si son muchas IPs: cerrar temporalmente el puerto 80 en security group (cortar el ataque)
y abrir solo para tu IP mientras investigas
- Si es DDoS real: activar AWS Shield Advanced (paga, pero incluye respuesta DRT)
Parte 5: Lo que aprendimos de los crashes de abril 2026
2026-04-22: EC2 t3.medium se colgó por CPU a 91% + RAM saturada + swap activo.
Diagnóstico: bot abusando endpoints. Reboot básico dio respiro pero no solucionó raíz.
2026-04-23: volvió a colgarse. Mitigación real aplicada:
- 9 GB liberados de disco (docker prune + npm cache + journal rotate + proyectos duplicados)
- Rate limit nginx configurado
- fail2ban con jail nginx-limit-req
- Mantener Tailscale como canal primario, SSM como secundario
Lección: la t3.medium con 4 GB RAM tiene poco margen para OpenClaw + nginx + cloudflared
- tailscale + docker + chrome headless. Si vuelve a pasar: subir a
t3.large (8 GB RAM)
cuesta ~$30/mes extra pero elimina el riesgo de colapso por RAM.
Invocación del skill
Cuando el usuario dice:
- "ayuda con seguridad de openclaw"
- "mi EC2 se está saturando"
- "alguien está atacando"
- "cómo conecto a openclaw sin SSH"
- "instalar cloudwatch agent"
- "bloquear bots en nginx"
→ Lee este skill completo. Ejecuta los checks relevantes. Aplica el nivel que aplique al
momento (fase 1 si es nueva instalación, fase 2-3 si ya hay ataque en curso).
Siempre verifica con los comandos de triaje ANTES de recomendar algo. No asumas.
