Un Honeypot en AWS

En ciberseguridad, un mecanismo que simula ser un “jugoso” objetivo, pero en realidad es una trampa para investigar y analizar las estrategias de los atacantes se llama honeypot. Viene de la “trampa de miel” en inglés, donde la miel es el señuelo para atraer a muchos. Es una excelente herramienta para el aprendizaje y análisis de amenazas y ataques con información real.

En la presente entrada, quiero presentar lo práctico que es realizar el despliegue de un conocido proyecto de Deutsche Telekom en un ambiente virtual Cloud utilizando Terraform (infraestructura cómo código) y AWS.

Para conocer más acerca de los tipos de honeypot y su funcionamiento recomiendo consultar este blog de Kaspersky Latam.

T-POT CE

T-POT CE es un proyecto que reúne varias implementaciones de honeypots para despliegue en Docker sobre Debian. También incluye herramientas comunes para detección y análisis de los ataques, como ELK stack, Suricata, Spiderfoot, etc.

Despliegue en AWS

En la documentación se encuentran las instrucciones para el despliegue con Terraform. Tener en cuenta los prerrequisitos: una cuenta de AWS, AWS CLI con credenciales, una subnet y VPC ya existente, el SSH key pair en la región definida.

Nota: No se recomienda utilizar una cuenta de AWS en producción ni un VPC o subnet que tenga acceso a dispositivos reales, dado que el honeypot puede ser vulnerable.

Se edita el archivo variables.tf

Tener en cuenta la IP con acceso permitido a la interfaz de administración.

Con terraform init : se descargan los componentes necesarios para la integración con AWS.

Con terraform validate y terraform plan: se valida que todo está listo para el despliegue y cómo se crearán los recursos necesarios.

Con terraform apply : se puede observar la creación de los recursos y provisionamiento de acuerdo a los parámetros.

Finalmente, en outputs, Terraform nos indica las URLs e IPs para el acceso.

Tener en cuenta que el despliegue utiliza cloud-init, lo cual clona el repositorio, descarga Docker con sus respectivas imágenes e instala los componentes requeridos y por último reinicia el servidor. Esto puede tomar aproximadamente 20-30 minutos.

Desde AWS, se puede monitorear el avance, hasta que la instalación sea completada.

Interacción con el Honeypot

El panel principal, incluye el acceso a las herramientas principales:

Para algunos es sorprendente, que con tan solo unos minutos de tener el honeypot expuesto a Internet ya se pueden evidenciar todo tipo de eventos. Desde escaneos, ataques de fuerza bruta, bots maliciosos, hasta exploits específicos. En nuestro caso, en la segunda hora ya contamos con mas de 800 ataques.

Kibana, como parte del ELK stack es una excelente herramienta para visualizar información en volumen. Los dashboards ya están definidos de acuerdo a los honeypots habilitados.

Uno de los componentes más interesantes es la visualización de palabras en nube. En este ejemplo, podemos apreciar los usuarios y contsraseñas más comunes que están probando los atacantes.

El IDS/IPS Open Source Suricata, nos presenta los CVE ID más comunes que se están tratando de explotar.

Utilizando CloudWatch se puede monitorear las estadísticas de la instancia EC2, incluyendo CPU, uso de disco, uso de red, etc.

Nota: Para monitoreo de uso de memoria RAM se requiere instalar el agente de CloudWatch.

Una vez realizadas las pruebas requeridas, se procede a eliminar los recursos. Es importante recordar que la facturación en AWS es “Pay as you go”, es decir se paga por el tiempo que los recuros estén corriendo.

Conclusión

Para finalizar, en nuestras pruebas, el proyecto T-POT CE es muy recomendado por su facilidad de uso y velocidad de despliegue en AWS. En un trabajo hace varios años duramos semanas descargando ISOs, formateando, instalando y configurando un solo Honeypot para labores de simulación de nuestro SOC, mientras que hoy, tenemos acceso a un despliegue en 30-40 min con todas estas labores automatizadas y con posibilidad de adaptarla a nuestras necesidades.

Respecto a los resultados del análisis inicial, se observó que la mayoría de los ataques son bots maliciosos y scripts automatizados. Es algo difícil detectar ataques reales, sin embargo, se aprende mucho de los que realmente ocurre en el “salvaje Internet”.

Dado que algunos atacantes reales cuentan con técnicas para detectar honeypots, un siguiente paso es mejorar la interacción de los proyectos para hacer más difícil que se pueda detectar que es un honeypot y no un activo “jugoso”. Pero esto ya será tema de un futuro tutorial.

¿Preguntas o comentarios? Se me puede contactar aquí.