Un servidor expuesto en internet es un objetivo constante, independientemente del período del año. Para demostrarlo, configuré un honeypot y lo dejé online durante siete días en el mes de agosto, un período a menudo percibido como más tranquilo. Los números recopilados son claros: la actividad maliciosa nunca se detiene y cada sistema accesible desde la red está bajo escrutinio constante. El objetivo era cuantificar el volumen y la tipología de ataques dirigidos hacia un sistema Linux recién instalado, sin hardening específico, simulando un servidor que podría haber sido olvidado o configurado de forma superficial. Los datos recopilados ofrecen una visión realista de la amenaza diaria que enfrentan las infraestructuras IT.
Tested on: Ubuntu 22.04 LTS · Cowrie Honeypot 2.4.0 · agosto 2026
Requisitos Previos / Entorno de Prueba
Para este análisis, utilicé Cowrie, un honeypot SSH y Telnet de baja interacción. Cowrie emula un sistema Linux, registrando cada intento de acceso, comando ejecutado y archivo descargado por los atacantes. El honeypot se instaló en una VM con Ubuntu 22.04 LTS, expuesta directamente en internet con una dirección IP pública. No se aplicaron hardening o configuraciones de seguridad adicionales, salvo las básicas para el funcionamiento de Cowrie. La elección de agosto no es casual: es un mes en el que muchas empresas operan con personal reducido, lo que hace que la reactividad a los incidentes sea potencialmente más lenta. Este escenario permite entender qué sucede con un servidor expuesto sin protección activa, un riesgo que muchos entornos legacy o mal configurados corren diariamente.
Qué sucede a un servidor expuesto en agosto
Durante los siete días de exposición (del 5 al 12 de agosto), el honeypot registró una actividad incesante. El tráfico más significativo se dirigió al servicio SSH, con un promedio de casi 170 intentos de acceso al día. Estos intentos eran casi exclusivamente de tipo brute-force, con los atacantes probando combinaciones de nombres de usuario y contraseñas comunes. Lee también: SSH Linux sin Password: Configura Claves en 5 Minutos
Análisis del tráfico SSH
El log principal de Cowrie muestra un flujo continuo de intentos de autenticación fallidos. Los nombres de usuario más atacados incluían ‘root’, ‘admin’, ‘user’, ‘test’, y nombres de servicios como ‘oracle’ o ‘postgres’. Las contraseñas intentadas eran a menudo débiles o predeterminadas. Este tipo de ataque es automatizado y no requiere habilidades elevadas, pero es extremadamente eficaz contra sistemas con credenciales débiles o no protegidas por mecanismos como el bloqueo de cuentas o el MFA.
Para analizar los intentos de acceso, utilicé comandos sencillos para extraer y contar los datos de los logs de Cowrie:
# Contar los intentos de acceso SSH fallidos
grep 'Failed password' cowrie.log | wc -l
# Identificar los nombres de usuario más usados en los ataques
grep 'Failed password' cowrie.log | awk '{print $9}' | sort | uniq -c | sort -nr
# Identificar las direcciones IP de origen más activas
grep 'Failed password' cowrie.log | awk '{print $11}' | sort | uniq -c | sort -nrEscaneos e intentos de exploit web
Además de SSH, el honeypot también registró intentos de escaneo web. Aunque Cowrie es principalmente un honeypot SSH/Telnet, noté tráfico HTTP en puertos comunes (80/443) que indicaba escaneos automatizados en busca de directorios vulnerables o servicios web expuestos. Estos ataques buscan identificar instalaciones de CMS conocidos, paneles de administración o archivos de configuración sensibles. Aunque Cowrie no emula un servidor web completo, el registro de estas solicitudes HTTP en los logs del sistema o del firewall es una señal importante.
Para un análisis más profundo del tráfico web, sería necesario un honeypot específico como Dionaea o un web application firewall (WAF) en modo de log. Sin embargo, la presencia de estos escaneos confirma que los atacantes buscan cualquier punto débil, no solo los puertos estándar para los servicios de gestión.
Origen geográfico y tipología de los atacantes
Las direcciones IP de origen de los ataques provenían de una amplia gama de países, con una fuerte concentración de regiones conocidas por alojar botnets e infraestructuras maliciosas. Identifiqué más de 20 IP únicas que intentaron ataques persistentes. No se trataba de actores sofisticados, sino más bien de bots automatizados que escanean internet en busca de objetivos fáciles. Su persistencia es la verdadera amenaza: aunque cada intento individual puede ser bloqueado, el volumen total puede sobrecargar los sistemas de defensa o pasar desapercibido en ausencia de una monitorización adecuada. Lee también: UFW Firewall Ubuntu: Configuración Completa Paso a Paso
Esta actividad constante subraya la importancia de implementar geoblocking o listas de bloqueo para IP conocidas, aunque estas medidas no son una solución definitiva.
Errores Comunes y Resolución de Problemas
Un error común en la gestión de servidores expuestos es subestimar la rapidez con la que son detectados y atacados. Un servidor sin un firewall configurado o con credenciales débiles puede ser comprometido en pocas horas, si no minutos. Otro error es confiar exclusivamente en un único mecanismo de defensa. Aunque un honeypot es útil para la recopilación de inteligencia, no es una solución de seguridad activa. Es fundamental combinar el uso de firewalls, sistemas de detección de intrusiones (IDS/IPS), autenticación multifactor (MFA) y políticas de contraseñas robustas. Lee también: Fortinet PSIRT: Evaluar Exposición en Red Segmentada
En caso de compromiso, la prontitud en la respuesta es crucial. Un honeypot puede ayudar a entender las tácticas de los atacantes, pero un verdadero sistema de producción requiere un plan de incident response bien definido, con procedimientos para el aislamiento, la remediación y la restauración de los sistemas. La falta de logging adecuado es otro problema: sin logs detallados, es casi imposible entender qué sucedió o cómo ocurrió el compromiso.
FAQ — Preguntas Frecuentes
¿Disminuyen los ataques durante los períodos vacacionales?
No, los datos del honeypot muestran que la actividad de los atacantes automatizados permanece constante. Los bots no se van de vacaciones y continúan escaneando internet 24/7. De hecho, los períodos vacacionales podrían ser vistos como una oportunidad por los atacantes, sabiendo que la vigilancia y la reactividad de los equipos IT podrían estar reducidas.
¿Cuál es el primer paso para proteger un servidor expuesto?
El primer paso es implementar un firewall (como UFW en Linux o FortiGate) para limitar el acceso solo a los puertos y servicios necesarios. Posteriormente, es fundamental configurar la autenticación SSH para usar solo claves públicas y deshabilitar el acceso root directo, además de implementar un sistema como Fail2ban para bloquear las IP que intentan accesos brute-force.
¿Un honeypot puede ser comprometido?
Sí, aunque un honeypot está diseñado para ser un entorno seguro para la recopilación de datos, una configuración errónea o vulnerabilidades en el propio software del honeypot pueden exponerlo a riesgos. Es importante mantenerlo actualizado y aislado de la red de producción para evitar que se convierta en un punto de entrada para ataques reales.
¿Debo deshabilitar Telnet?
Absolutamente sí. Telnet es un protocolo inseguro que transmite las credenciales en claro. Aunque es menos común que SSH, he observado intentos de acceso Telnet en el honeypot. Deshabilitar Telnet y utilizar solo SSH (con las medidas de seguridad oportunas) es una práctica fundamental.
Conclusiones con Puntos Clave Operativos
El experimento del honeypot de agosto ha confirmado un dato crucial: la amenaza informática es persistente y automatizada. Cada servidor expuesto en internet es un objetivo, independientemente de su propósito o del período del año. Los puntos clave operativos son claros:
- Firewall: Configurar un firewall para exponer solo los servicios estrictamente necesarios.
- Hardening SSH: Deshabilitar el acceso root directo, usar solo claves SSH, implementar MFA y cambiar el puerto SSH predeterminado (aunque no es una medida de seguridad, reduce el ruido en los logs).
- Monitorización: Implementar un sistema de monitorización de logs (SIEM/EDR) para detectar intentos de acceso y anomalías en tiempo real.
- Awareness: Sensibilizar al equipo IT sobre la importancia de la seguridad perimetral, incluso durante los períodos de menor actividad.
No esperes a que un incidente real te golpee para entender la importancia de la seguridad. Cada segundo de exposición sin protección es un riesgo calculado que podría costar caro.
Fuentes
Actualizado: agosto 2026
