- Portspoof hace que los 65535 puertos TCP parezcan abiertos y emula firmas de servicio, convirtiendo la fase de reconocimiento del atacante de un escaneo rápido en una tarea larga y costosa
- Devuelve
SYN+ACK a todos los intentos de conexión y responde en cada puerto como si fuera un servicio legítimo distinto mediante más de 9000 firmas de servicio dinámicas basadas en expresiones regulares
- Asigna al inicio modos de entrega mixtos por puerto, como banner inmediato, respuesta diferida o silencio, e introduce jitter en el tiempo de mantenimiento de la conexión para dificultar el filtrado basado en temporización
- Con la configuración tarpit predeterminada, un escaneo completo de versiones
nmap -sV -p- puede tardar más de 10 horas y generar cientos de MB de datos falsos, consumiendo tiempo e hilos del escáner del atacante
- La implementación usa un bucle de eventos
epoll de un solo hilo, se ejecuta en espacio de usuario sin privilegios de root y solo enlaza un puerto TCP por instancia en ejecución
El problema que Portspoof busca resolver
- El objetivo de Portspoof es hacer que el reconocimiento del atacante sea lento, costoso y poco confiable
- En lugar de que un escaneo típico de Nmap de 5 segundos mapee los servicios reales del sistema, frente a Portspoof los 65535 puertos parecen estar abiertos
- Cada puerto parece un servicio legítimo distinto, y está diseñado para que no haya una forma rápida de distinguir cuáles son los servicios reales
Funciones clave
-
Responde como si los 65535 puertos TCP estuvieran abiertos
- En vez de indicar que un puerto está
CLOSED o FILTERED, devuelve SYN+ACK a todos los intentos de conexión
-
Emulación de servicios
- Usa más de 9000 firmas de servicio dinámicas basadas en expresiones regulares
- Cada puerto responde a las sondas del escáner con una identidad de servicio distinta y convincente
-
Modos de entrega mixtos
- Cada puerto recibe al inicio un perfil de comportamiento diferente
- Se mezclan modos de envío inmediato de banner, respuesta diferida y mantenimiento en silencio
- Los tiempos de retención se distribuyen en un rango amplio, haciendo que la detección de versiones en todo el rango
nmap -sV -p- supere los límites prácticos
-
Defensa agresiva
- Puede usarse como un “Exploitation Framework Frontend” para apuntar a vulnerabilidades del propio escáner del atacante
-
Modelo de ejecución ligero
- Se ejecuta en espacio de usuario
- No requiere privilegios de root
- Solo enlaza un puerto TCP por instancia en ejecución
- El uso de CPU y memoria es bajo
Cómo confunde a los escáneres y a la detección de versiones
- En un escaneo simple de puertos, incluso un rango pequeño como los puertos 1~20 aparece completamente como
open
- En la salida de ejemplo se mezclan nombres de servicios como
tcpmux, compressnet, echo, daytime y ftp-data
- En un escaneo de detección de versiones, devuelve firmas dinámicas válidas a las sondas de servicio
- En el ejemplo de los puertos 1~100 aparecen distintos servicios y cadenas de versión como
irc, http, pop3, ssh, ftp, smtp, telnet y tor-control
- Como resultado, al atacante le resulta difícil determinar qué números de puerto usa realmente el sistema
- Un escaneo completo de versiones
nmap -sV -p- puede tardar más de 10 horas con la configuración tarpit predeterminada y generar cientos de MB de datos falsos
- El escáner consume tiempo e hilos en conexiones que no llevan a resultados reales
Enfoque de diseño: tarpit epoll de un solo hilo
- Servicios reales como SSH, SMTP, FTP y HTTP envían banners, mantienen la conexión y esperan la entrada del cliente
- Una emulación convincente también debe seguir el flujo de accept, send, hold
- Un modelo con un hilo por cliente consume memoria y CPU, y por el costo del cambio de contexto el defensor puede agotar primero sus propios recursos
- Portspoof usa un bucle de eventos
epoll de un solo hilo
- Cada puerto recibe un modo de entrega al inicio
- Algunos puertos envían un banner de inmediato, algunos responden después de recibir datos del cliente y otros permanecen en silencio
- Los tiempos de retención se distribuyen desde decenas de milisegundos hasta minutos, cubriendo varios órdenes de magnitud
- Hay jitter por conexión, por lo que incluso si se sondea repetidamente el mismo puerto no devuelve siempre la misma temporización
- Este enfoque dificulta los ataques que envían datos basura a todos los puertos y miden el tiempo de respuesta
- Un tarpit simple mantiene la conexión por unos segundos, mientras que un servicio real puede cerrar rápido ante un protocolo incorrecto
- Con modos mixtos y una amplia dispersión temporal, incluso miles de puertos falsos cierran dentro de rangos similares a los de servicios reales
- Ya no existe un umbral limpio que pueda usarse para filtrar
Asimetría de costos
- El costo para el defensor es de aproximadamente 1~2 KB de memoria del kernel por conexión inactiva
- El bucle
epoll es de un solo hilo, así que no hay sobrecarga por cambio de contexto
- Incluso hardware de nivel común puede soportar más de 10 mil conexiones simultáneas
- El costo para el atacante se traslada al tiempo y al esfuerzo
- Solo con un escaneo de puertos es difícil obtener información útil porque todos los puertos parecen abiertos
- Para encontrar servicios reales, necesita detección de versiones sobre los 65535 puertos y sondeo a nivel de protocolo sobre los objetivos plausibles
- Un escaneo de 5 segundos se convierte en más de 10 horas de trabajo activo y aun así el resultado sigue siendo como buscar en un pajar
Cambios en v2.0
- v2.0 deja atrás el método anterior de enviar un banner y luego cerrar la conexión
- Ese método anterior era vulnerable a la evasión del cierre de conexión descrita en la publicación del blog de Vicarius/Hored1971
- El nuevo motor tarpit mantiene todas las conexiones abiertas con temporización mixta
- Este enfoque busca impedir el filtrado por cierre de conexión, el fingerprinting por temporización, el análisis de banners y el modelado estadístico de patrones
Instalación y configuración básica
- La compilación requiere un compilador de C++ y CMake 3.10+
- El procedimiento para compilar desde el código fuente es el siguiente
mkdir build && cd build
cmake -DCMAKE_INSTALL_SYSCONFDIR=/etc ..
make
sudo make install
- Portspoof se ejecuta en espacio de usuario, pero para interceptar tráfico dirigido a otros puertos se necesitan reglas del firewall del sistema
- El puerto predeterminado es 4444; primero se excluyen los puertos de servicios reales y luego el resto del tráfico TCP se redirige a Portspoof
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j RETURN
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 4444
eth0 debe sustituirse por la interfaz de red real- Debe agregarse una regla
RETURN para cada puerto donde esté corriendo un servicio real
- Para aplicación persistente se puede guardar la regla de iptables o usar
iptables-config del directorio system_files
- Para el script de inicio se puede usar el ejemplo de
system_files/init.d/
Modos de ejecución
- El modo de emulación de servicios es el modo recomendado
- Genera y entrega firmas falsas de servicio a los escáneres de puertos
portspoof -c /etc/portspoof.conf -s /etc/portspoof_signatures -D
- La temporización personalizada del tarpit se especifica con
-t y -T
- El ejemplo mantiene cada conexión entre 10 y 60 segundos
portspoof -s /etc/portspoof_signatures -t 10 -T 60 -D
- El Open Port Mode solo devuelve estado
OPEN a todos los intentos de conexión, sin banners de servicio
- La conexión sigue siendo procesada por el tarpit
portspoof -D
- El Fuzzing Mode puede usarse para enviar payloads aleatorios o basados en wordlists a herramientas de escaneo
portspoof -1 -v
portspoof -f payloads.txt -v
Refuerzo basado en iptables
- Funciona incluso solo con la regla básica
REDIRECT, pero los escáneres agresivos pueden presionar a Portspoof mediante la cantidad de conexiones
- Las reglas de refuerzo agregan limitación de velocidad y bloqueo automático
- Los puertos de servicios reales se excluyen de la redirección
- En el ejemplo se excluye el puerto SSH 22
- La regla de bloqueo global también se aplica a los servicios reales
- El ejemplo de reglas incluye los siguientes elementos
- Permitir loopback
- Descartar durante 60 segundos las IP marcadas como
PORTSCAN
- Descartar nuevos SYN por IP de origen cuando excedan 10 por segundo con ráfaga de 30
- Si una sola IP mantiene más de 100 conexiones al puerto 4444 de Portspoof, marcar y luego descartar
- Permitir tráfico established/related y nuevos SYN, y luego descartar el resto
- En despliegues de alto tráfico, puede aumentarse el tamaño de la lista
xt_recent
echo "options xt_recent ip_list_tot=10000" > /etc/modprobe.d/xt_recent.conf
- También pueden ajustarse configuraciones del kernel relacionadas con seguimiento de conexiones y backlog
sysctl -w net.netfilter.nf_conntrack_max=131072
sysctl -w net.core.somaxconn=4096
Portspoof Pro
- Portspoof Pro amplía la deception desde un solo host a todo el nivel de red
- Un solo sensor emula una red completa
/16
- Proporciona miles de IP
- Cada IP tiene servicios únicos en todos los puertos
- Mantiene conversaciones de múltiples etapas con estado
- Ofrece capacidades de deception en toda la red
- Convierte espacio dark IP y subredes no utilizadas en una cuadrícula activa de deception
- Cada host emulado presenta servicios únicos con distinta personalidad según la IP de origen
- El tarpit activo agota el pool de sockets del atacante y aplica throttling a las herramientas automatizadas
- Soporta detección de escaneos y fingerprinting de herramientas
- Detecta técnicas de escaneo SYN, FIN, NULL, XMAS y ACK
- Hace fingerprinting de Nmap, Masscan, ZMap y escáneres personalizados
- Envía telemetría JSON estructurada al SIEM con mapeo MITRE ATT&CK incluido
- Considera el despliegue en entornos operativos
- Se ejecuta en un entorno sandbox junto al tráfico de producción
- Las políticas de enrutamiento envían el tráfico de deception al sensor
- Indica que no requiere taps inline y que no hay riesgo para las cargas de trabajo reales
- Compatible con NIS2, DORA, ISO 27001, NIST CSF y CIS Controls
Licencia y reporte de issues
- Portspoof usa la licencia GNU GPLv2
- Se indica que, para aplicaciones comerciales y legales, se contacte al autor para discutir el licenciamiento apropiado
- Los bugs y solicitudes de funciones pueden reportarse en el GitHub Issue Tracker o por correo electrónico
1 comentarios
Opiniones en Hacker News
Hay 65536 puertos, y el puerto 0 también es un puerto en el que, en algunos sistemas operativos, se puede levantar un servicio accesible desde internet.
Y si algún desarrollador de MariaDB está leyendo esto: la configuración predeterminada de hacer que la base de datos escuche en el puerto 0 para bloquear el acceso desde internet en realidad no impide el acceso a la DB desde internet en bastantes sistemas.
if (mysqld_port)significa “cuandomysqld_portes distinto de 0”, y parece ser un comportamiento que existe al menos desde MariaDB 5.5.La seguridad informática, al final, parece destinada a seguir evolucionando hacia una defensa activa como la descrita arriba.
Si uno ve lo complejo y multicapa que es el sistema inmunológico, algún día las computadoras o las redes probablemente terminarán pareciéndose a eso.
Algún día IT será un campo lo suficientemente experimentado, pero hoy todavía no.
Aunque, si incluimos también ese aspecto, más bien se ve un paralelismo preocupante.
Una vez hice una página web que generaba direcciones de correo aleatorias infinitas para frenar a los spambots recolectores de emails: http://web.archive.org/web/20020610054821/http://www.sourtim...
Si corres algo así, alguien podría escanear tu máquina y mandarte decenas de solicitudes de bug bounty diciendo que se está ejecutando una “versión vulnerable conocida de X”.
A mediados de los 90 había un producto honeypot llamado CyberCop Sting, anterior a Ballista de Secure Networks.
CyberCop Sting podía simular servicios TCP/UDP de varias implementaciones y, si mal no recuerdo, también permitía configurar el comportamiento del stack TCP/IP para que pareciera el de distintos sistemas operativos. Para hace casi 30 años era una funcionalidad bastante innovadora.
[1] https://theswissbay.ch/pdf/Gentoomen%20Library/Security/0321...
[2] https://news.ycombinator.com/item?id=26440139
Obviamente es algo que alguien debería haber hecho, pero me sorprende un poco no haberlo pensado antes, y me sorprende aún más estar oyendo esta idea por primera vez.
Me pregunto si hacer esto terminaría provocando que hackers o bots miren el servidor con más detalle o, como mínimo, que llegue más tráfico.
No creo que la mayoría de los script kiddies estén filtrando posibles honeypots o dispositivos de este tipo en sus herramientas.
Pero una vez que se sabe que el host está vivo, el problema es qué puerto tocar. Si asumimos que el costo de escanear o atacar cada puerto de cada servidor es similar, aunque se puedan distinguir los puertos falsificados, conviene más buscar otra máquina con mayor probabilidad de éxito. También se podría correr portspoof en el 127.0.0.35 local y comparar los datos de respuesta o las diferencias de timing, pero el espacio de búsqueda pasa de unos pocos puertos normalmente abiertos a algo unas 5000 veces más grande, y los puertos de otros servidores podrían parecer más prometedores.
La mayoría de las herramientas no contempla una situación en la que todos los puertos estén abiertos y generen falsos positivos. En pruebas de penetración es una situación común y hace perder tiempo, pero no quiero darle a un atacante motivos para mirar más mi infraestructura. Preferiría port knocking, que es casi lo opuesto a este enfoque.
Para ataques a gran escala, tendría que desplegarse en decenas de millones de hosts para tener cierto efecto, de modo que a un atacante le resulte poco práctico encontrar e interactuar solo con honeypots. Si sufres un ataque dirigido específico, puede retrasarlos un poco mientras intentan explotar puertos honeypot, pero si estás corriendo un servicio vulnerable, terminarán entrando. Además, si eres un proveedor, cuando el equipo de seguridad de un cliente potencial te escanee, podrías tener que responder cuestionarios de seguridad muy molestos.
Hago algo parecido en mi sitio web. https://bini.wales devuelve 200 en todos los endpoints y registra todos los intentos, así que funciona como un honeypot bastante decente contra ataques automatizados
En general atrapa escaneos masivos que buscan plugins vulnerables de WordPress o puertas traseras abandonadas. De forma similar, https://varun.ch/login imita un sitio de WordPress con un pequeño giro
Bien. Me alegra que no haya aparecido ni una sola vez la palabra “honeypot”
Una vez heredé un honeypot “de verdad” y, al revisarlo, vi que tenía como 30 puertos abiertos; literalmente dije en voz alta: “¿qué es esta basura?”
Dejar puertos abiertos para que un script kiddie se emocione creyendo que accedió a algo, cuando en realidad no hay nada. Un honeypot cerrado, en ese punto, no parece mucho un honeypot
Un honeypot se usa para atraer y detectar atacantes, y normalmente registra su comportamiento y patrones para analizarlos o bloquearlos. Esta herramienta estaría mejor con más logging además de iptables, y por sí sola no es un honeypot, pero la idea no está tan lejos. Eso sí, no me creo para nada que la página de GitHub diga que esto “refuerza la seguridad del OS”. Ofrecerá algo de ofuscación frente a escáneres automáticos de servicios, pero si un servidor MySQL está escuchando en el 3306 y el atacante se conecta al 3306, seguirá hablando con MySQL. No importa si los otros 65534 puertos devuelven respuestas basura
Dice que “se vincula solo a un puerto TCP por cada instancia en ejecución”; me da curiosidad cómo funciona eso
¿Hay que ejecutar 65535 instancias para cubrir todos los puertos?
Luego llama a
getsockoptpara averiguar cuál era el puerto original: https://github.com/drk1wi/portspoof/blob/c3f3c34531c59df229e...No conozco los límites duros reales ni el uso de memoria, pero probablemente el redireccionamiento de puertos sea más simple
¿No podría esto convertirse potencialmente en un amplificador DoS?
Si se envían paquetes adecuadamente falsificados, ¿podría devolver muchos paquetes al origen aparente?
Si fuera UDP, podría volverse una locura