# Honeypots: cazando bots 🐼💀Cómo convertir un VPS expuesto en un sensor de ataques y entender el ruido real de internet
<br>

<figure>
  <img src="/panda/images/honeypot-cover.png" alt="Honeypot Panda Lab">
  <figcaption>Visión general del honeypot: captura, análisis y visualización de ataques.</figcaption>

</figure>

## 🐼 Honeypots: cazando bots

En internet, los ataques no se anuncian… simplemente llegan.

No necesitas ser un objetivo específico.
Basta con exponer un servicio para empezar a recibir tráfico automatizado.

Bots, escáneres y scripts recorren constantemente la red buscando errores conocidos.

En lugar de bloquearlos, decidí observarlos.

---

El honeypot no es un sistema aparte. Está integrado directamente en Nginx.

<figure>
  <img src="/panda/images/server-config.png" alt="Server block de Nginx">
  <figcaption>Integración del honeypot dentro del server block de Nginx.</figcaption>
</figure>

A través de un `include`, se agregan rutas señuelo que simulan endpoints reales:

<figure>
  <img src="/panda/images/honeypot-config.png" alt="Configuración del honeypot">
  <figcaption>Rutas señuelo configuradas para capturar tráfico automatizado.</figcaption>
</figure>

Rutas como:

- `/wp-admin`
- `/wp-login.php`
- `/phpmyadmin`
- `/.env`
- `/.git/config`

Todas responden con `200 OK`.

No es un error. Es intencional.

El objetivo no es bloquear al atacante, sino hacerle creer que encontró algo válido… y dejar que continúe.

---

El comportamiento que se observa es bastante consistente:

```text
1. Conexión inicial
2. Intento /.env
3. Prueba /wp-admin
4. Exploración de rutas comunes
5. Cambio de User-Agent


No hay interacción humana.
Es automatización pura recorriendo internet.

Y lo que buscan también es bastante predecible:

.env → credenciales expuestas
/wp-admin → paneles vulnerables
/phpmyadmin → acceso a bases de datos
/actuator, /swagger → APIs

```

En ese punto, entendí algo clave:

Los bots no atacan personas. Buscan errores conocidos.

Pero los logs por sí solos no dicen mucho si no los procesas.

Así que armé un pequeño pipeline:

Internet → Nginx → logs → scripts → cron → dashboard HTML

Los logs de Nginx se procesan con scripts en bash (awk, grep),
se ejecutan automáticamente con cron,
y generan un dashboard en HTML.

Ese dashboard lo puedes ver aquí:

👉 [Ver dashboard de atacantes](https://pandapandemio.com/top_attackers.html)

Ahí se visualiza:

- IPs más activas
- frecuencia de requests
- comportamiento repetitivo

Ya no es solo un honeypot.

Se convierte en un sistema de observación continua.

Para no depender de revisar logs manualmente, agregué alertas vía Telegram.

Cada cierto tiempo, el sistema envía eventos detectados:

[ALERT]
IP: 185.x.x.x
Path: /.env
UA: curl/7.68

No es un SIEM, pero cumple su función.

Después de observar el tráfico por un tiempo, los patrones empiezan a repetirse:

El tráfico llega en ráfagas, no de forma constante
Muchas IPs hacen pocos intentos (scanning distribuido)
Algunas IPs son persistentes
Las herramientas utilizadas son simples:
curl
python-requests
nmap
ffuf

Nada sofisticado.
Pero constante.

Este enfoque también tiene sus límites.

No detecta ataques avanzados.
No correlaciona eventos.
No analiza comportamiento profundo.

Pero revela algo importante:

No necesitas ser un blanco específico para ser atacado.

Internet está lleno de bots explorando cualquier servicio expuesto.

El honeypot no elimina ese ruido.

Lo transforma en información.

🧠 Reflexión final

En ciberseguridad, muchas veces pensamos en bloquear, filtrar, defender.

Pero hay otra perspectiva:

Observar.

Porque cuando entiendes cómo te atacan,
empiezas a ver patrones…
y los patrones son previsibles.

Y lo previsible… se puede anticipar.

Si tienes un VPS expuesto, la pregunta no es si te están escaneando.

La pregunta es:

¿ya estás viendo lo que está pasando?
