Blog
DevOps·14 min read

Blindar tu servidor Clawdbot: Guía completa de seguridad

a los 60 segundos de configurar fail2ban, detectó un ataque de fuerza bruta activo. así es como aseguras tu servidor Clawdbot correctamente.

Jo V·January 27, 2026
Blindar tu servidor Clawdbot: Guía completa de seguridad

Instalé fail2ban en mi servidor Clawdbot esta noche. En 60 segundos, baneó a su primer atacante.

No fue una prueba. Un bot real estaba intentando fuerza bruta contra SSH mientras yo configuraba el firewall.

Jan 27 02:46:55 sshd: Invalid user oracle from 217.154.38.135
Jan 27 02:47:25 sshd: Invalid user main from 217.154.38.135
Jan 27 02:47:56 sshd: Invalid user HwHiAiUser from 217.154.38.135
Jan 27 02:48:26 sshd: Invalid user guest from 217.154.38.135
Jan 27 02:48:57 sshd: Invalid user git from 217.154.38.135

Cada 30 segundos. Diferentes nombres de usuario. Automatizado. Implacable.

Entonces fail2ban entró en acción:

2026-01-27 02:50:54 NOTICE [sshd] Ban 217.154.38.135

Listo. Ban de 30 días. Si estás corriendo Clawdbot en un VPS, necesitas esto.

Por qué los servidores Clawdbot son un objetivo

Los servidores Clawdbot son un blanco jugoso porque típicamente tienen:

  • Acceso a shell — El agente puede ejecutar comandos
  • Credenciales de API — Anthropic, OpenAI, plataformas de mensajería
  • Datos personales — Logs de sesión, archivos de memoria, contactos
  • Conectividad permanente — Uptime 24/7 en un VPS en la nube

Un atacante que comprometa tu servidor Clawdbot obtiene acceso a todas las capacidades de tu asistente de IA. Podría leer tus conversaciones, suplantarte en plataformas de mensajería, o disparar tus facturas de API.

Vamos a solucionarlo.

Paso 1: Autenticación SSH con clave (Crítico)

Este es el paso de seguridad más importante. La autenticación por contraseña es el eslabón más débil. Las claves SSH son criptográficamente seguras e imposibles de atacar por fuerza bruta.

En tu máquina local, genera un par de claves:

ssh-keygen -t ed25519 -C "your_email@example.com"

Esto crea dos archivos:

  • ~/.ssh/id_ed25519 — Tu clave privada (nunca la compartas)
  • ~/.ssh/id_ed25519.pub — Tu clave pública (va en el servidor)

Copia tu clave pública al servidor:

ssh-copy-id user@your-server-ip

O manualmente:

# En tu máquina local
cat ~/.ssh/id_ed25519.pub
# Copia la salida, luego en tu servidor:
echo "your-public-key-here" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Comprueba que funciona:

ssh user@your-server-ip

Si entras sin que te pida contraseña, está funcionando.

Paso 2: Desactivar autenticación por contraseña

Una vez que las claves SSH funcionan, desactiva la autenticación por contraseña por completo:

sudo nano /etc/ssh/sshd_config

Busca y cambia estas líneas:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Reinicia SSH:

sudo systemctl restart sshd

Ahora la única forma de entrar es con tu clave privada. Los ataques de fuerza bruta se vuelven completamente inútiles — están intentando adivinar una contraseña que no existe.

Paso 3: Instalar fail2ban

Incluso con claves SSH, queremos fail2ban como capa de respaldo para mantener los logs limpios y evitar desperdiciar recursos.

sudo apt update
sudo apt install -y fail2ban

Crea una configuración local:

sudo tee /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 2592000
findtime = 600
EOF

Qué hace esto:

  • maxretry = 3 — Tres intentos fallidos = baneado
  • bantime = 2592000 — Ban de 30 días (si usas claves SSH, cualquier intento fallido es definitivamente un atacante)
  • findtime = 600 — Los intentos se cuentan en una ventana de 10 minutos

Inícialo:

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Comprueba si está funcionando:

sudo fail2ban-client status sshd

Paso 4: Configurar el firewall ufw

# Por defecto: bloquear todo lo entrante
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Permitir solo lo que Clawdbot necesita
sudo ufw allow 22/tcp # SSH (lo cambiaremos después)
sudo ufw allow 80/tcp # HTTP (si usas webhooks)
sudo ufw allow 443/tcp # HTTPS
# Activar
sudo ufw --force enable

Verifica:

sudo ufw status verbose

Paso 5: Trampa SSH con endlessh (La parte divertida)

Aquí es donde se pone interesante. La idea: mover el SSH real a un puerto no estándar, poner endlessh en el puerto 22. Los bots se conectan al puerto 22 y quedan atrapados en un banner infinitamente lento que envía un byte aleatorio cada 10 segundos. Nunca llegan al prompt de login. Mientras tanto, el SSH real funciona sin problemas en otro puerto.

Qué hace endlessh

endlessh es una trampa SSH (tarpit). Cuando un bot se conecta, envía un banner SSH infinitamente lento — un byte aleatorio cada 10 segundos. La especificación SSH permite banners de hasta 255 caracteres, pero no establece una velocidad mínima. La mayoría de los bots esperan pacientemente el banner completo, consumiendo un slot de conexión y perdiendo su tiempo.

Es como arenas movedizas digitales para bots SSH.

Instalar endlessh

sudo apt install endlessh

Mover el SSH real al puerto 2222

En Ubuntu moderno, SSH se gestiona con sockets de systemd, así que necesitamos sobreescribir la configuración del socket:

sudo mkdir -p /etc/systemd/system/ssh.socket.d/
sudo tee /etc/systemd/system/ssh.socket.d/override.conf << 'EOF'
[Socket]
ListenStream=
ListenStream=2222
EOF

Recarga y reinicia:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo systemctl restart ssh

Verifica que SSH está ahora en el 2222:

ss -tlnp | grep :2222

Configurar endlessh para el puerto 22

sudo mkdir -p /etc/endlessh
sudo tee /etc/endlessh/config << 'EOF'
Port 22
Delay 10000
MaxLineLength 32
MaxClients 4096
LogLevel 1
EOF

Esto configura:

  • Port 22 — El puerto SSH estándar (los bots encontrarán este)
  • Delay 10000 — Enviar un byte cada 10 segundos
  • MaxClients 4096 — Manejar muchos bots atrapados
  • LogLevel 1 — Registrar conexiones para entretenimiento

Arreglar el servicio systemd

endlessh puede fallar con un error NAMESPACE en sistemas modernos. Crea una sobreescritura del servicio:

sudo mkdir -p /etc/systemd/system/endlessh.service.d/
sudo tee /etc/systemd/system/endlessh.service.d/override.conf << 'EOF'
[Service]
PrivateUsers=false
EOF

Iniciar endlessh

sudo systemctl daemon-reload
sudo systemctl enable endlessh
sudo systemctl start endlessh

Comprueba que funciona:

sudo systemctl status endlessh
ss -tlnp | grep :22

Actualizar ufw para el nuevo puerto SSH

# Permitir el nuevo puerto SSH
sudo ufw allow 2222/tcp
# Eliminar la regla anterior de SSH (el puerto 22 ahora es la trampa)
sudo ufw delete allow 22/tcp

Probar la trampa

Desde otra máquina, intenta conectarte al puerto 22:

ssh user@your-server-ip -p 22

Debería quedarse colgado, enviando un carácter cada 10 segundos. Después de un rato verás un banner super lento y distorsionado. Pulsa Ctrl+C para escapar.

Ahora prueba el SSH real:

ssh user@your-server-ip -p 2222

Conexión instantánea con tu clave SSH.

Los resultados

Los bots pierden su tiempo en el puerto 22 mientras tu SSH real funciona tranquilo en el 2222. Tus logs se mantienen limpios porque los intentos fallidos caen en la trampa, no en tu servicio SSH real. Ver journalctl -f -u endlessh es sorprendentemente entretenido — bots conectándose y simplemente... esperando.

¿Qué tan efectivo es realmente?

Un investigador ejecutó endlessh durante meses y recopiló datos sobre los bots atrapados. Los resultados son hilarantes:

  • Un bot mantuvo 416 conexiones simultáneas abiertas al mismo tiempo — seguía abriendo nuevas sin cerrar las anteriores
  • Una sola IP permaneció conectada durante 690.172 segundos — eso son 8 días seguidos — descargando 1,2 MB de basura aleatoria pensando que era un banner SSH
  • Algunas conexiones duraron más de 12.000 segundos (3,3 horas) antes de que el bot se rindiera
  • El tiempo medio de trampa fue 17 segundos (los bots "inteligentes" con timeouts), pero la media fue 119 segundos — arrastrada por los tontos que esperan eternamente

La calidad del software de escaneo clandestino varía enormemente. Algunos bots tienen un timeout de 15 segundos y pasan al siguiente. Otros no tienen timeout — se quedarán ahí hasta la muerte térmica del universo esperando un prompt de login que nunca llegará.

Y lo mejor: endlessh usa prácticamente cero recursos. Es un solo proceso manejando miles de conexiones con un uso mínimo de CPU y memoria. Los bots son los que queman recursos, no tú.

Monitorear la trampa

Observa bots quedarse atrapados en tiempo real:

journalctl -f -u endlessh

Cuenta las conexiones atrapadas actualmente:

ss -tn | grep :22 | grep ESTAB | wc -l

Paso 6: Cambiar el puerto SSH (Breve)

Ya movimos SSH al 2222 para la trampa, pero aquí tienes el enfoque general si solo quieres cambiar puertos sin endlessh:

# En /etc/ssh/sshd_config
Port 2222

Actualiza el firewall:

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo systemctl restart sshd

La seguridad por oscuridad no es seguridad real, pero sí reduce el ruido de escaneos aleatorios. Combinado con claves SSH y fail2ban, es efectivo.

Paso 7: Gestión de secretos con pass

No guardes claves de API ni contraseñas en archivos de configuración en texto plano. Usa pass — el gestor de contraseñas estándar de Unix.

Instálalo:

sudo apt install pass gnupg

Configúralo:

# Genera una clave GPG (si no tienes una)
gpg --gen-key
# Inicializa pass con tu clave GPG
pass init "your-email@example.com"

Guarda secretos:

pass insert api/anthropic
pass insert api/openai
pass insert gmail/app-password

Recupera secretos en scripts:

export ANTHROPIC_API_KEY=$(pass show api/anthropic)

Por qué importa:

  • Los secretos están cifrados con GPG en reposo
  • Aunque alguien acceda a tu sistema de archivos, no puede leer las contraseñas sin tu clave GPG
  • Puedes sincronizar tu almacén de contraseñas vía git (de forma segura, ya que todo está cifrado)
  • Funciona genial con Clawdbot — guarda tus claves de API y tokens de canales de forma segura

Tu directorio ~/.password-store/ está cifrado. Tu ~/.clawdbot/clawdbot.json con tokens en texto plano? No tanto.

Paso 8: Auditoría de seguridad de Clawdbot

Clawdbot tiene un escáner de seguridad integrado. Ejecútalo:

clawdbot security audit

Para una comprobación más profunda:

clawdbot security audit --deep

Para corregir automáticamente problemas comunes:

clawdbot security audit --fix

Qué comprueba la auditoría

  • Acceso entrante — ¿Pueden extraños enviar mensajes a tu bot?
  • Radio de explosión de herramientas — ¿Podría una inyección de prompt llevar a acceso al shell?
  • Exposición de red — ¿Está tu Gateway expuesto sin autenticación?
  • Control del navegador — ¿Está asegurado el control remoto del navegador?
  • Permisos de disco — ¿Están protegidas las credenciales y los logs?
  • Plugins — ¿Hay extensiones no confiables cargadas?

Corregir permisos del workspace

La auditoría probablemente advertirá sobre permisos. Corrígelos:

chmod 700 ~/.clawdbot
chmod 600 ~/.clawdbot/clawdbot.json

Esto asegura que solo tu usuario puede leer la configuración y credenciales de Clawdbot.

Ubicaciones de almacenamiento de credenciales

Sabe dónde viven tus secretos:

  • Token de Telegram: config o channels.telegram.tokenFile
  • Auth de WhatsApp: ~/.clawdbot/credentials/whatsapp/*/creds.json
  • Listas blancas de emparejamiento: ~/.clawdbot/credentials/*-allowFrom.json
  • Logs de sesión: ~/.clawdbot/agents/*/sessions/*.jsonl

Todos estos deberían ser legibles solo por tu usuario (ni grupo ni otros).

Paso 9: Seguridad de canales

Restringir los DMs

Por defecto, Clawdbot podría aceptar mensajes de cualquiera. Restríngelo:

En tu configuración, establece las políticas de DM a allowlist:

{
"channels": {
"telegram": {
"dmPolicy": "allowlist",
"dmAllowFrom": ["your_telegram_id"]
}
}
}

Restringir los grupos

Lo mismo para grupos — usa listas blancas en lugar de abierto:

{
"groupPolicy": "allowlist",
"groupAllowFrom": ["allowed_group_id"]
}

La auditoría de seguridad marcará políticas abiertas.

Paso 10: Reportar atacantes a AbuseIPDB

Bloquear atacantes localmente está bien. Que los incluyan en listas negras globales es mejor.

AbuseIPDB es una base de datos comunitaria de IPs abusivas. Cuando reportas un atacante, todos los demás servidores que usan su lista de bloqueo se benefician. Es defensa colectiva.

Obtener una clave API gratuita

Regístrate en abuseipdb.com — el tier gratuito permite 1000 reportes/día.

Guárdala de forma segura:

pass insert abuseipdb/api-key

Reportar una IP baneada

ABUSEIPDB_KEY=$(pass show abuseipdb/api-key)
curl -s https://api.abuseipdb.com/api/v2/report \
-H "Key: $ABUSEIPDB_KEY" \
-H "Accept: application/json" \
--data-urlencode "ip=2.57.122.209" \
-d "categories=18,22" \
--data-urlencode "comment=SSH brute-force (fail2ban auto-ban)"

Las categorías 18,22 = fuerza bruta + SSH.

Auto-reportar con Clawdbot

Construí un skill de Clawdbot que reporta automáticamente cada nuevo ban a AbuseIPDB. Si estás corriendo Clawdbot, instálalo:

clawdhub install fail2ban-reporter

O descárgalo de GitHub:

git clone https://github.com/jestersimpps/clawdbot-fail2ban-reporter.git
sudo bash clawdbot-fail2ban-reporter/scripts/install.sh

Después de la configuración, cada ban de fail2ban se reporta automáticamente a AbuseIPDB. Cero esfuerzo, máximo impacto comunitario.

Paso 11: Monitorear ataques en curso

Comprueba quién ha sido baneado:

sudo fail2ban-client status sshd

Observa bans en vivo:

sudo tail -f /var/log/fail2ban.log | grep Ban

Revisa intentos SSH recientes:

journalctl -u ssh -n 50 | grep -E "Failed|Invalid"

Observa endlessh atrapando bots en tiempo real:

sudo journalctl -f -u endlessh

Verás conexiones que simplemente se quedan ahí. Cada una es un bot perdiendo el tiempo en lugar de molestar a tu SSH real.

Lo que los atacantes realmente intentan

De los logs de mi servidor en solo una hora:

  • oracle — Usuario por defecto de Oracle DB
  • postgres — Por defecto de PostgreSQL
  • git — Servidores GitLab/Gitea
  • solana — Operadores de nodos crypto (objetivo popular)
  • HwHiAiUser — Por defecto de dispositivos Huawei
  • admin, root — Los clásicos
  • ftpuser — FTP legacy

Lanzan nombres de usuario comunes esperando que alguno funcione. fail2ban los detiene después de 3 intentos, pero ahora primero caen en la trampa.

La configuración completa en 5 minutos

Copia y pega este bloque completo para blindar un servidor Clawdbot recién instalado:

# Install security tools
sudo apt update && sudo apt install -y fail2ban ufw endlessh gnupg pass
# Generate SSH key (run on your LOCAL machine)
ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id user@your-server-ip
# Disable password auth (ON THE SERVER)
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
# Move SSH to port 2222 for tarpit setup
sudo mkdir -p /etc/systemd/system/ssh.socket.d/
sudo tee /etc/systemd/system/ssh.socket.d/override.conf << 'EOF'
[Socket]
ListenStream=
ListenStream=2222
EOF
# Configure endlessh tarpit on port 22
sudo mkdir -p /etc/endlessh
sudo tee /etc/endlessh/config << 'EOF'
Port 22
Delay 10000
MaxLineLength 32
MaxClients 4096
LogLevel 1
EOF
# Fix endlessh systemd service
sudo mkdir -p /etc/systemd/system/endlessh.service.d/
sudo tee /etc/systemd/system/endlessh.service.d/override.conf << 'EOF'
[Service]
PrivateUsers=false
EOF
# Configure fail2ban
sudo tee /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 2592000
findtime = 600
EOF
# Configure firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # New SSH port
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
sudo ufw --force enable
# Start everything
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket ssh
sudo systemctl enable --now fail2ban endlessh
# Fix Clawdbot permissions
chmod 700 ~/.clawdbot
chmod 600 ~/.clawdbot/clawdbot.json 2>/dev/null
# Run Clawdbot security audit
clawdbot security audit --fix
# Verify everything
echo "=== SSH on port 2222 ==="
ss -tlnp | grep :2222
echo "=== endlessh tarpit on port 22 ==="
ss -tlnp | grep :22
echo "=== fail2ban status ==="
sudo fail2ban-client status sshd
echo "=== ufw status ==="
sudo ufw status verbose
echo "=== Clawdbot security ==="
clawdbot security audit

Importante: Después de ejecutar esto, conéctate por SSH en el nuevo puerto:

ssh user@your-server-ip -p 2222

El stack de seguridad completo

Después de seguir esta guía, tu servidor Clawdbot tiene:

  • Autenticación con clave SSH — No hay contraseñas que atacar por fuerza bruta
  • Autenticación por contraseña desactivada — Aunque adivinen bien, no funcionará
  • Trampa endlessh — Los bots pierden tiempo en el puerto 22 mientras el SSH real se oculta en el 2222
  • fail2ban — 3 intentos → ban de 30 días (capa de respaldo)
  • Firewall ufw — Solo los puertos necesarios expuestos
  • pass — Secretos cifrados con GPG en reposo
  • Emparejamiento de Clawdbot — Extraños no pueden enviar mensajes a tu bot
  • Permisos correctos — Configuración y credenciales bloqueados
  • Reportes a AbuseIPDB — Los atacantes se incluyen en listas negras globales

Eso es defensa en profundidad. Múltiples capas, cada una haciendo el siguiente ataque más difícil. La trampa es la guinda del pastel — en lugar de solo bloquear atacantes, les haces perder tiempo y recursos mientras tus servicios reales permanecen ocultos.

No es paranoia cuando cada servidor con una IP pública es atacado en cuestión de horas. Cinco minutos de configuración. Duerme más tranquilo.


Para más detalles de seguridad de Clawdbot, consulta la documentación oficial de seguridad.

Stay Updated

Get notified about new posts on automation, productivity tips, indie hacking, and web3.

No spam, ever. Unsubscribe anytime.

Comments

Related Posts