Mira bots atacando un honeypot SSH en vivo

Si administras servidores SSH, tarde o temprano vas a ver intentos de acceso que no vienen de una persona sentada frente al teclado. Vienen de bots, escáneres y scripts que prueban credenciales, enumeran banners y disparan comandos apenas encuentran un puerto abierto. El problema no es solo que existan, sino que muchas veces operan a una velocidad y con una persistencia que cuesta imaginar sin verlo en vivo.

Por eso esta demo de honeypot SSH resulta tan útil: te deja observar cómo se comportan esos automatismos en tiempo real, sin tener que montar tu propio laboratorio ni esperar a que tu servidor reciba tráfico raro. La idea es simple, pero muy práctica para seguridad: ver patrones reales de ataque, entender qué buscan y reconocer señales que luego puedes aplicar en tus propios sistemas.

Qué muestra esta demo y por qué importa

La página de honeypotlive.cc expone un honeypot SSH público y muestra interacciones en vivo con bots que intentan conectarse. No es una simulación con datos inventados ni un video pregrabado. Es una ventana a sesiones reales que llegan al servicio, con intentos de login, comandos probados y comportamientos repetitivos que suelen aparecer cuando un atacante automatiza su trabajo.

Eso importa porque SSH sigue siendo uno de los servicios más expuestos en infraestructura Linux. Si administras un VPS, una instancia en AWS, un servidor en DigitalOcean o un equipo en la red de tu empresa, seguramente ya viste algo parecido en tus logs. La diferencia aquí es que puedes observar el patrón completo en tiempo real, lo que ayuda a entrenar el ojo para distinguir un intento humano de una ráfaga de automatización.

Además, esta clase de demo sirve para algo más que curiosidad. Te ayuda a explicar riesgos a un equipo no técnico, a justificar controles como MFA, llaves SSH, rate limiting y segmentación, y a entender por qué no conviene dejar un puerto 22 expuesto con credenciales débiles. Si quieres una referencia oficial sobre endurecimiento de SSH, la guía de OpenSSH y la documentación de tu distribución siguen siendo el punto de partida correcto: https://www.openssh.com/manual.html y, por ejemplo, la documentación de Ubuntu sobre OpenSSH.

Qué suele verse en un honeypot SSH

En este tipo de servicio, los bots suelen seguir una secuencia bastante predecible. Primero prueban si el puerto responde. Luego intentan autenticarse con combinaciones obvias de usuario y contraseña. Si logran entrar, suelen ejecutar comandos básicos para reconocer el entorno y decidir si vale la pena seguir.

También aparecen patrones de automatización muy reconocibles: tiempos de conexión cortos, repeticiones desde IPs distintas, nombres de usuario comunes y mensajes de error casi idénticos. No necesitas un SIEM caro para notar eso. Basta con mirar varias sesiones seguidas y comparar.

Cómo se comportan los bots cuando encuentran SSH

La parte más interesante de la demo es que te permite ver el ritmo. Un humano puede tardar segundos entre un intento y otro. Un bot, en cambio, puede probar decenas de credenciales en poco tiempo, cambiar de IP y volver a empezar. Esa diferencia de cadencia es una de las señales más claras de automatización.

En SSH, los bots suelen buscar tres cosas: acceso inicial, validación de que la sesión responde y ejecución de comandos post-acceso. Si el honeypot acepta la conexión, el siguiente paso suele ser una pequeña batería de comandos como uname, whoami, id, pwd, ls o cat /etc/os-release. No siempre verás exactamente esos comandos, pero sí una lógica parecida: identificar sistema, permisos y superficie útil.

También hay ataques más torpes, pero frecuentes. Algunos scripts prueban contraseñas por defecto, otros reutilizan listas filtradas y otros simplemente barren Internet buscando credenciales débiles. En todos los casos, la automatización deja huellas: patrones repetidos, poco contexto y cero paciencia.

Señales típicas en la sesión

Si observas varias conexiones seguidas, vas a notar indicadores muy concretos. Aquí tienes algunos de los más comunes:

1. Intentos de login con usuarios genéricos como root, admin, test o ubuntu.
2. Repetición de contraseñas cortas o muy obvias.
3. Conexiones desde rangos de IP distintos en minutos o segundos.
4. Comandos de reconocimiento básicos apenas se abre la sesión.
5. Cierre rápido cuando el entorno no responde como esperaban.

No hace falta que todos aparezcan a la vez. Con dos o tres ya puedes sospechar que no estás viendo a una persona entrando manualmente por SSH.

Tabla de patrones que puedes reconocer

Qué puedes aprender para defender tus servidores

La utilidad real de ver un honeypot SSH en vivo no está solo en el espectáculo técnico. Está en que traduce un problema abstracto en algo concreto. Cuando ves veinte intentos parecidos en pocos minutos, entiendes por qué no basta con confiar en que tu servicio “no es interesante” para un atacante.

La primera lección es obvia, pero se sigue ignorando: no expongas SSH con contraseña si puedes evitarlo. Las llaves SSH, combinadas con deshabilitar la autenticación por password, reducen muchísimo la superficie. La segunda lección es que el puerto 22 abierto no debería ser una invitación pública. Si puedes limitar por IP, mejor. Si puedes usar VPN o bastion host, aún mejor.

La tercera lección es operativa. Los logs importan. Si no revisas auth.log, journalctl, o la telemetría de tu proveedor, vas a perder contexto valioso. Y cuando el incidente escale, ese contexto te dice si fue un escaneo masivo, un intento dirigido o una sesión manual más sofisticada.

Controles que sí valen la pena

Si quieres bajar el riesgo en un entorno real, este es un orden práctico de medidas:

1. Deshabilita el login por contraseña en SSH y usa llaves.
2. Desactiva el acceso directo de root.
3. Limita el acceso por IP o por VPN cuando sea viable.
4. Aplica rate limiting o herramientas como fail2ban si tu caso lo justifica.
5. Mantén el sistema y OpenSSH actualizados.
6. Revisa logs con frecuencia y guarda retención suficiente.

No necesitas aplicar todo de golpe, pero sí priorizar lo que corta el acceso más fácil. En la práctica, quitar contraseñas y cerrar el acceso directo de root ya elimina una parte grande del ruido.

Qué no resuelve un honeypot

Un honeypot no reemplaza monitoreo, hardening ni respuesta a incidentes. Tampoco te dice todo sobre un atacante real, porque muchos bots están diseñados para ser genéricos y baratos de operar. Lo que sí hace muy bien es mostrarte el comportamiento de base que verás una y otra vez en Internet.

Tampoco conviene asumir que todo lo automatizado es inofensivo. Un bot puede ser el primer paso de una cadena más larga, desde el reconocimiento hasta el despliegue de malware o la persistencia. Por eso conviene mirar la demo como una herramienta de observación, no como una curiosidad aislada.

Cómo usar esta demo para aprender y enseñar

Si trabajas en seguridad, esta clase de sitio te sirve como material de capacitación. Puedes abrirlo en una reunión corta y pedirle al equipo que identifique qué está pasando en cada sesión. Es una forma más efectiva de enseñar que una diapositiva con definiciones, porque obliga a interpretar señales reales.

También te sirve para documentar políticas internas. Si alguien pregunta por qué SSH debe ir con llaves y no con password, puedes mostrarle el tipo de tráfico que recibe un servicio expuesto. Cuando el riesgo se ve, la discusión cambia. Ya no hablas en abstracto, sino de intentos concretos y repetitivos que ocurren todo el tiempo.

En entornos pequeños, como una startup o un equipo de infraestructura en LatAm, esto es especialmente útil porque muchas veces no hay tiempo para montar laboratorios complejos. Una demo pública bien hecha te ahorra fricción y te da un ejemplo inmediato que puedes discutir con el equipo.

Ejemplos de uso práctico

Puedes usar la demo de estas formas:

• En una sesión de onboarding para explicar por qué SSH requiere llaves.
• En una charla corta con desarrollo para mostrar el costo de exponer servicios.
• Como referencia visual para el equipo de soporte cuando revisa alertas.
• Para comparar el tráfico real de tu entorno con el comportamiento de los bots.

Si además quieres profundizar, complementa la observación con documentación oficial de OpenSSH y con guías de endurecimiento de tu distro. La demo te da contexto; la documentación te da la configuración correcta.

Limitaciones de la demo y cómo interpretarla bien

Hay que leer este tipo de herramienta con criterio. Un honeypot está diseñado para atraer interacción y registrar comportamiento, así que no representa toda la complejidad de una red real. Lo que ves es una muestra útil, no una radiografía completa del panorama de amenazas.

También puede haber sesgos según el tipo de honeypot, la ubicación del servidor y el momento del día. No todos los bots reaccionan igual, y no todos los atacantes usan las mismas herramientas. Por eso conviene usar la demo como una fuente de patrones, no como una verdad absoluta sobre todos los ataques SSH.

Aun así, el valor es alto. Ver una sesión real te ayuda a reconocer secuencias, tiempos y comandos que luego aparecen en tus propios sistemas. Y esa capacidad de reconocimiento vale mucho más que memorizar una lista de amenazas genéricas.

Si quieres montar algo parecido

Si tu equipo quiere probar un honeypot propio, empieza simple. No necesitas una arquitectura enorme para obtener aprendizaje útil. Un contenedor aislado, reglas de firewall claras y logging bien configurado ya te permiten capturar bastante señal.

Antes de hacerlo, revisa la documentación oficial del proyecto que elijas y define bien el aislamiento. Un honeypot mal aislado puede convertirse en un problema de seguridad en lugar de una herramienta defensiva. Y si lo expones a Internet, asume que va a recibir tráfico no deseado desde el primer minuto.

Tabla resumen

Mira bots atacando un honeypot SSH en vivo no es solo una curiosidad técnica. Es una forma rápida de entender cómo opera la automatización contra servicios expuestos y por qué las decisiones básicas de seguridad siguen importando. Si administras infraestructura, ver ese patrón en directo te ayuda a priorizar mejor y a explicar mejor el riesgo.