Un honeypot es, en esencia, un sistema señuelo que imita un activo real para atraer a los atacantes y observar cómo operan sin comprometer tu entorno. Lejos de ser un truco, es una fuente de inteligencia práctica: te ayuda a descubrir qué intentan explotar, qué credenciales prueban y qué tácticas usan, para luego fortalecer tus detecciones y tu respuesta. En las próximas secciones verás cuándo conviene un honeypot de baja o alta interacción, dónde ubicarlo (DMZ, nube u on-prem) y cómo configurarlo con “debilidades controladas” para que resulte creíble. También te contaré qué telemetría seguir (IOCs, TTPs, dwell time) y las buenas prácticas para que nunca se convierta en un riesgo. Empezamos.
Qué es un honeypot y por qué funciona
Del “tarro de miel” al sistema señuelo
Cuando hablo de honeypots, pienso literalmente en un tarro de miel: algo dulce, irresistible. Un honeypot (también llamado sistema señuelo, trampa de engaño o deception) imita un activo real para atraer a un atacante y observar su comportamiento con seguridad. En mi experiencia, si el señuelo huele a laboratorio, nadie pica; por eso me esfuerzo en que “parezca” de producción: servicios plausibles, datos verosímiles y alguna “debilidad controlada” que invite a quedarse.
Honeypot vs honeynet vs deception
Honeypot: un activo aislado (p.ej., una VM que finge ser un servidor FTP).
Honeynet: una red de señuelos con rutas, credenciales y tráfico simulados.
Deception platforms: soluciones más completas que siembran canarios (archivos, tokens, cuentas) por toda la red y avisan con muy poco ruido.
Idea clave que aplico: no compito con el atacante; lo retengo con un entorno creíble para aprender de sus TTPs (técnicas, tácticas y procedimientos).
Tipos de honeypots y cuándo usar cada uno
Baja vs alta interacción (ventajas/limitaciones)
Baja interacción: servicios emulados (p.ej., banner de SSH o HTTP falso). Ventajas: rápidos, seguros, bajo mantenimiento. Limitaciones: capturan menos profundidad (scripts, cadenas, intentos básicos).
Alta interacción: sistemas reales (p.ej., un Linux “vivito y coleando” con SSH y un par de apps). Ventajas: telemetría rica (comandos, movimiento lateral, payloads). Riesgo: hay que aislar muy bien y endurecer la salida.
En mi práctica, empiezo por baja para cobertura amplia y paso a alta cuando detecto vectores interesantes que merecen estudio.
Señuelos para base de datos, APIs, IoT y webapps
Base de datos: perfectos para cazar SQL injection y escaladas de privilegios.
APIs: tentadoras para ver abuso de endpoints, fuzzing y credenciales robadas.
IoT/OT: routers, cámaras, UPS/SAI o PLCs ficticios; sirven para observar barridos masivos y exploits de fábrica.
Webapps (HTTP): para LFI/RFI, file upload, path traversal y scraping agresivo.
Email/Spam traps: cuentas señuelo para atrapar recolectores y remitentes de spam.
Fragmento práctico: he usado PCs “viejas” y VMs baratas en cloud para levantar varios perfiles a la vez (web, DB y API). Es increíble la diferencia de tráfico entre un banner genérico y un sitio con favicon, login y rutas realistas.
| Aspecto | Baja interacción | Alta interacción | Cuándo usar |
|---|---|---|---|
| Riesgo | Bajo (servicios emulados) | Mayor (sistema real) | Empieza con baja; pasa a alta cuando necesites profundidad |
| Profundidad de datos | Limitada (banners, intentos básicos) | Alta (comandos, payloads, TTPs) | Investigar técnicas manuales o movimiento lateral |
| Mantenimiento | Reducido | Medio/alto | Recursos disponibles para operación continua |
| Aislamiento requerido | Segmentación simple | DMZ estricta + egress mínimo | Entornos sensibles o cercanos a producción |
| Casos típicos | Perímetro ruidoso, detección temprana | Estudio profundo de ataques dirigidos | Cuando quieras reglas IDS/IPS muy precisas |
Arquitectura segura: dónde colocarlo y cómo aislarlo
DMZ, segmentación y evitar movimiento lateral
Coloco los honeypots en DMZ o redes aisladas con:
Enrutamiento controlado (sin rutas a subredes internas).
Firewall “salida estricta” (Egress Filtering): solo lo necesario para enviar logs.
Sin credenciales reales reutilizadas.
Registro y tap mirroring para ver tráfico sin exponer herramientas internas.
Algunas organizaciones los ponen incluso antes del firewall perimetral para husmear el ruido de Internet sin tocar producción. Use lo que uses, el mandamiento es simple: que un error no se convierta en un incidente.
Datos, servicios y “debilidades controladas” para que parezca real
Crea nombres de host creíbles (erp-finanzas, files-hr, pos-store3).
Población mínima de datos “de pega” (nada sensible) para que el atacante crea que “hay premio”.
Puertos coherentes con la historia del activo (no abras 5900 si no simulas VNC).
Credenciales débiles pero plausibles (p.ej.,
backup_2023), y tecnologías desactualizadas a propósito (con versión vieja pero controlada).
Consejo de campo: “dejar debilidades controladas” no es “abrir la puerta de par en par”. Lo útil es guiar al atacante por un pasillo de espejos donde puedas verlo todo sin que salga del laberinto.
Operar un honeypot sin quemarlo
Telemetría mínima viable y paneles de control
Me funciona pensar en MVP de telemetría:
Flujos de red (IP/puerto, bytes, duración).
Registro de comandos (si hay shell).
Captura de archivos/payloads (hash, tamaño, origen).
Eventos de autenticación (usuario, IP, user-agent).
Timestamps coherentes (sin relojes desincronizados).
Luego, un panel (SIEM o dashboard ligero) para ver: picos por hora/día, top IPs, países, puertos, credenciales probadas.
Cómo distinguir ataques automatizados vs manuales
Automatizados: alta cadencia, firmas repetidas, rutas típicas (
/wp-admin,/phpmyadmin), listas de contraseñas comunes.Manuales: pausas humanas, prueba-error razonado, enumera primero, cambia payloads al ver respuestas, busca rutas internas inventadas.
Nota de experiencia: “Lo valioso no es el golpe… son los logs”. Con buenas etiquetas, en dos semanas se nota qué % es ruido automatizado y qué intentos son interactivos.
Qué capturar y cómo aprovecharlo
Logs que importan: IOCs, TTPs y dwell time
KPIs que recomiendo seguir
Dwell time en el señuelo (minutos/horas).
Ratio Automatizado/Manual (% de sesiones).
IOCs/semana (IPs, dominios, hashes, user-agents únicos).
TTPs MITRE observadas (p.ej., T1059 Command Shell, T1046 Network Service Discovery).
Top credenciales probadas (para reforzar políticas y password deny-lists).
Alimentar detección y respuesta (IDS/IPS, reglas y playbooks)
Genera reglas IDS con patrones reales (URIs, payloads, JA3/JA4 si procede).
Actualiza listas de bloqueo (IPs, ASN, países si tu negocio lo permite).
Añade detecciones de canarios (acceso a carpetas “sensibles” fake → alerta crítica).
Crea un playbook: “si honeypot recibe X, entonces Y” (p.ej., si se sube binario → enviar a sandbox + bloquear origen + abrir ticket).
En mi caso, calibrar IDS/IPS con material fresco del honeypot redujo falsos positivos y me dio reglas quirúrgicas para campañas activas.
| KPI | Cómo medir | Interpretación | Acción |
|---|---|---|---|
| Dwell time | Duración media de sesión | Más tiempo = señuelo creíble | Refinar realismo; extraer TTPs para detecciones |
| Auto vs manual | % de sesiones con patrones repetitivos | Alto auto = campañas masivas | Bloqueos por firmas/ASN; reglas IDS específicas |
| IOCs/semana | IPs, dominios, hashes únicos | Flujo de inteligencia útil | Enriquecer SIEM; listas de bloqueo temporales |
| TTPs MITRE | Técnicas observadas (p.ej., T1059, T1046) | Mapa de capacidades del adversario | Crear detecciones centradas en TTPs |
| Credenciales probadas | Top usuarios/contraseñas | Indica diccionarios activos | Actualizar deny-lists y políticas de contraseñas |
Casos de uso que realmente aportan
Detección temprana y distracción en producción
Perímetro ruidoso: capta barridos y construye contexto antes de que toquen activos reales.
Cebo en segmentos críticos: si alguien llega ahí y toca el señuelo, la señal es de alto valor.
Caza de credential stuffing: portales señuelo con login realista para atrapar diccionarios y user-agents.
Investigación y mejora continua de seguridad
Blue teaming: practicar respuesta con ataques “de verdad”.
Product security: exponer APIs “pretendidas” para ver por dónde revientan.
Threat Intel: enriquecer feeds internos con lo que pasa en TU red, no lo que dicen los reportes globales.
Micro-tip: he visto más aprendizaje levantando tres señuelos simples y distintos (web, API, DB) que uno solo muy sofisticado. Diversidad = más señales.
Riesgos, ética y buenas prácticas
Consideraciones legales y de privacidad
No guardes datos personales reales.
Notifica internamente (legal, CISO, SOC) el propósito y el aislamiento.
Condiciones de salida: evita que el honeypot sirva de pasarela a terceros (proxificación).
Retención responsable: define cuánto tiempo almacenas payloads o IPs.
Consejo directo: “Aísla el honeypot (mejor en DMZ) para que un fallo no se convierta en un incidente real.” Y revísalo como revisarías un servidor productivo.
| Control | ¿Aplicado? | Detalle |
|---|---|---|
| Aislamiento | ☐/☑ | DMZ/VLAN dedicada, sin rutas a producción |
| Egress mínimo | ☐/☑ | Solo syslog/SIEM y gestión |
| Credenciales | ☐/☑ | Ficticias, rotadas, sin reutilización |
| Vulnerabilidades controladas | ☐/☑ | Versiones viejas “guiadas”, no caos |
| Monitorización | ☐/☑ | Flujos de red, comandos, payloads, autenticación |
| Retención y legal | ☐/☑ | Plazos definidos; sin datos personales reales |
Conclusión
Un honeypot bien planteado no es un juguete: es una fuente de inteligencia que te permite atrapar hackers (o, mejor dicho, sus tácticas) sin poner en jaque tus sistemas reales. En mi experiencia, el secreto está en tres cosas: realismo, aislamiento y aprovechamiento de la telemetría. Si lo haces creíble, lo operas con cabeza y exprimes los logs para mejorar detección y respuesta, el retorno se nota en semanas.
Preguntas frecuentes
¿Un honeypot sustituye a un IDS/IPS?
No. Lo complementa: te da señales de alta calidad para mejorar reglas y playbooks.
¿Cómo evito que lo usen para pivotar?
Aislamiento en DMZ, sin rutas a subredes internas, egress mínimo y alertas si intenta salir.
¿Qué datos pongo para que parezca real?
Datos sintéticos (nombres, docs, tablas) que tengan sentido para tu negocio, pero nada sensible.
¿Cloud o on-prem?
Ambos valen. En cloud es barato probar rápido; on-prem te da más control de red. Lo clave es el aislamiento.
¿Cómo diferencio bot de humano?
Patrones de cadencia, rutas comunes, errores y cambios de payload. Si hay “pensamiento” (pausas, enumeración, prueba-error), suele ser manual.
¿Qué hago con los IOCs?
Llévalos a tu SIEM, crea bloqueos temporales si aplica, y alimenta detecciones para futuras campañas.
