Puntos ciegos

Existe una gran cantidad de tráfico malicioso en Internet y es imposible bloquearlo todo. Sin embargo, existen herramientas que ayudan a reducir considerablemente la superficie de ataque: proxies como Squid, firewalls como iptables o nftables, sistemas como fail2ban y muchas otras. Hoy hablaremos de Suricata, pero desde una perspectiva diferente.

Se ha escrito mucho sobre este IDS/IPS. Hay excelentes tutoriales sobre su instalación, configuración y reglas, por lo que no profundizaré en esos aspectos. En cambio, hoy abordaré un problema que suele pasar desapercibido en redes LAN pequeñas y medianas. Pero antes, un poco de contexto.

Filtrado por DNS o Proxy: Dos versiones del mismo problema

Es común pensar que un proxy o un filtro DNS (como Pi-hole) son suficientes para detener el tráfico malicioso. En realidad, ambos tienen limitaciones estructurales. Un ejemplo son las aplicaciones que establecen conexiones directamente hacia direcciones IP, evitando el uso de nombres de dominio. Este comportamiento es habitual en numerosos protocolos P2P y también en algunas familias de malware. En el caso del proxy Squid podemos impedir este tipo de conexiones mediante reglas como las siguientes:

# Block: Direct IPv4
acl direct_ipv4 dstdom_regex -n -i ^([0-9]{1,3}\.){3}[0-9]{1,3}$
http_access deny direct_ipv4
# Block: Direct IPv6
acl direct_ipv6 dstdom_regex -n -i ^\[([0-9a-f:]+)\]$
http_access deny direct_ipv6

Estas reglas funcionan correctamente, e impiden que el tráfico malicioso haga peticiones a sus propias IPs y nos permite declarar antes una lista blanca para excluir las IPs que nos interesa antes de cerrar la llave (grifo), pero estas reglas aplican únicamente sobre el tráfico que ya está siendo procesado por el proxy. Si un cliente intenta abrir un CONNECT 37.17.94.15:443 o GET http://37.17.94.15... a través de Squid, será bloqueado, pero Squid jamás verá el tráfico que no pase por el proxy, por ejemplo, conexiones UDP y TCP directas utilizadas por protocolos como BitTorrent DHT o la red TOR.

Con el filtrado DNS ocurre exactamente el mismo problema. Herramientas como Pi-hole, OpenDNS o cualquier otro resolver DNS basado en listas negras, bloquean un dominio antes de resolverlo, devolviendo NXDOMAIN o una dirección inexistente. Mientras el cliente dependa del DNS, el mecanismo funciona perfectamente. El problema aparece cuando la aplicación nunca necesita resolver un nombre de dominio. Algunos ejemplos:

• BitTorrent DHT: los clientes descubren otros pares mediante el propio protocolo DHT (Kademlia). Obtienen directamente direcciones IP y puertos de otros nodos, sin realizar consultas DNS.
• TOR: el cliente descarga el documento de consenso con la lista de relays disponibles y establece conexiones directamente hacia esas direcciones IP, sin consultar el DNS para cada conexión.
• Web3 / Blockchain: los nodos de redes como Ethereum o Bitcoin descubren pares mediante su propio protocolo de descubrimiento (Kademlia-like en el caso de Ethereum, gossip de direcciones en Bitcoin), obteniendo IP y puerto directamente de otros nodos, sin depender del DNS para cada conexión.

En los tres casos, el tráfico nunca atraviesa la capa de control del proxy ni del resolver DNS. Este punto ciego es compartido por ambas soluciones.

Nota: no todo el tráfico relacionado con blockchain constituye un punto ciego. Muchos servicios RPC públicos (como Infura, Alchemy o QuickNode) dependen de DNS y HTTPS, por lo que pueden ser bloqueados por un filtro DNS o un proxy. Lo mismo ocurre con malware cuyo C2 utiliza nombres de dominio. Incorporar estas comunicaciones al mecanismo basado en Suricata -que explicaremos más adelante- añade una capa adicional de protección que continúa siendo efectiva si los controles basados en DNS o proxy son eludidos.

Filtrado por firmware: ¿una capa diferente?

Existe además la capa de filtrado que realizan directamente los gateways, routers y firewalls de red. Fabricantes como MikroTik, UniFi, Cisco, Fortinet, Aruba y otros integran en el firmware o software embebido de sus dispositivos funciones de filtrado que, al igual que sucede con las soluciones basadas en software (desplegadas en sistemas operativos), permiten aplicar reglas sobre el tráfico basándose, según las capacidades de cada equipo, en parámetros como dirección IP de origen o destino, protocolo, puerto, estado de la conexión, interfaces, listas de direcciones, dominios, etc.

Sin embargo, este mecanismo también tiene limitaciones. Las capacidades disponibles dependen del fabricante, del modelo, de su arquitectura y, en determinados casos, de la licencia o de las funciones habilitadas. Del mismo modo, el grado de aceleración disponible varía entre dispositivos: algunas operaciones pueden ejecutarse mediante ASIC, NPU, hardware offload u otros mecanismos de aceleración, mientras que otras deben procesarse mediante la CPU del equipo. Esto determina tanto el volumen de tráfico que puede procesarse como el costo asociado a determinadas funciones. Además, aunque estos dispositivos pueden tomar decisiones de filtrado a partir de distintos atributos del tráfico, normalmente saben qué está comunicándose y bajo qué protocolo, pero no necesariamente qué contiene o qué tipo de actividad representa dicha comunicación. Un firewall de este tipo puede bloquear una IP, un puerto o una combinación de ambos; sin embargo, no puede determinar que una conexión corresponde a un relay de TOR, a un nodo de BitTorrent DHT, a un coinminer, a un aplicativo de circumvention que utilice técnicas avanzadas de ofuscación o a un patrón concreto de malware; para ello se requiere un nivel de inspección mucho más profundo.

A esto se suma otra limitación cuando se pretende utilizar el firewall como mecanismo de filtrado por dominios. Aunque muchos equipos permiten cargar listas de dominios para bloquearlos, el dispositivo necesita resolver esos nombres y mantener actualizada su correspondencia con las direcciones IP para poder aplicar las reglas. Esto puede implicar consultas DNS y actualizaciones frecuentes de las estructuras de filtrado, especialmente cuando se utilizan listas extensas o dominios cuyas direcciones IP cambian con frecuencia. Además, una misma dirección IP puede corresponder a múltiples dominios, por ejemplo cuando se utilizan servicios de alojamiento compartido o CDN, por lo que bloquear la IP puede afectar también a otros servicios que no forman parte de la lista de bloqueo.

¿Y si, en lugar de intentar convertir cada herramienta en una solución todo en uno, utilizamos cada tecnología para aquello para lo que fue diseñada y buscamos otra capa especializada cuando necesitamos saber qué está ocurriendo dentro de una comunicación? Es en este punto donde Suricata aporta valor.

¿Qué aporta Suricata?

Suricata no es una solución mágica, pero su valor radica en que no depende de lo que el cliente use para conectarse. Analiza una copia del tráfico directamente sobre la interfaz de red, observando todos los paquetes independientemente del protocolo utilizado, del puerto empleado o de si existió una consulta DNS previa. Gracias a ello puede identificar patrones propios de protocolos como BitTorrent DHT, P2P Vuze, relays TOR, User-Agent sospechosos, Coinminers, indicadores de compromiso y miles de firmas adicionales directamente sobre el contenido de los paquetes. Desde la perspectiva de detección, Suricata amplía la cobertura a niveles extremos, siempre que exista una firma capaz de identificar aquello que se quiere controlar, permitiendo de esta manera eliminar muchos de los puntos ciegos descritos anteriormente.

Cuello de botella

El costo de esa visibilidad es que Suricata debe inspeccionar todo el tráfico, con todo lo que esto implica. 

En modo IDS (el modo utilizado por la mayoría de las instalaciones), Suricata analiza cada paquete contra miles de firmas y simplemente genera alertas, pero si queremos que bloquee tráfico (modo IPS mediante NFQUEUE), cada paquete debe ser inspeccionado antes de que el kernel del sistema operativo decida si continúa o no.

Esto no representa un problema para las grandes empresas con High-End Gateways -que cuentan con aceleración por hardware (ASIC/NPU)-, pero para las pequeñas y medianas empresas con gateways de gama moderada, activar el modo IPS implica un enorme cuello de botella. La inspección profunda de paquetes y el alto volumen de conexiones concurrentes, introducen un nuevo problema: latencia, incremento en el uso de CPU y degradación del rendimiento general de la red.

En resumen, no es una tarea que pueda trasladarse simplemente al hardware convencional de un gateway de gama media: inspeccionar cada paquete y mantener ese nivel de análisis a velocidad de línea requiere recursos que estos equipos normalmente no pueden proporcionar sin sacrificar rendimiento.

Workaround

Nuestra propuesta consiste en dejar que cada herramienta haga aquello para lo que fue diseñada.

La inspección profunda (IDS) continúa realizándose únicamente en Suricata, fuera del camino del paquete. Suricata se encarga de inspeccionar el tráfico y generar las alertas, mientras que el firewall es el encargado de aplicar el bloqueo mediante una consulta O(1) sobre un conjunto hash. Por su parte, EveBox proporciona una interfaz para visualizar y analizar las alertas generadas por Suricata, facilitando su identificación y seguimiento. El proceso es sencillo y se describe a continuación:

• Se selecciona un subconjunto de firmas sobre las cuales realmente interesa actuar y se introducen en un archivo llamado drop.conf, reduciendo así el ruido y falsos positivos. Esta lista puede ir creciendo con el tiempo, a medida que salen nuevas alertas relevantes.
• Suricata continúa inspeccionando el tráfico y registrando alertas sin intervenir en el flujo de los paquetes.
• Un proceso periódico muy liviano -bash script programado preferentemente en cron- lee las entradas del registro de alertas, filtra las correspondientes al subconjunto de firmas de drop.conf y extrae las direcciones IP involucradas.
• Esas direcciones IP -en principio solo de destino, para no penalizar la IP de la LAN por un solo evento- se almacenan en una lista permanente que alimenta un ipset basado en hash:ip.
• El firewall (iptables, nftables y similares) consulta ese ipset mediante una única regla y descarta cualquier conexión dirigida a esa lista de direcciones IP.

El resultado es una arquitectura que aprovecha la capacidad de detección de Suricata, reemplazando el bloqueo IPS en línea por uno basado en ipset, mucho más eficiente.

Los puntos ciegos del proxy y del filtrado DNS siguen desapareciendo, ya que el bloqueo se realiza sobre las direcciones IP detectadas (modo IDS), independientemente del protocolo utilizado, del puerto o de si existió una consulta DNS previa.

Cada componente cumple una función específica:

• Suricata detecta (IDS).
• El proceso auxiliar transforma las alertas en inteligencia utilizable (bash/cron).
• El firewall aplica el bloqueo con un costo constante y sin introducir inspección profunda en el camino de cada paquete (iptables/ipset).

Ejemplo:

2026-08-06 11:16:50 suridata start...
2026-08-06 11:18:51 INFO: 22541 SID(s) newly resolved to drop -- rescanning full eve.json for them
2026-08-06 11:19:29 INFO: 136.61.46.254 added to suridata.txt
2026-08-06 11:19:29 INFO: 149.56.27.47 added to suridata.txt
2026-08-06 11:19:29 INFO: 38.114.121.180 added to suridata.txt
2026-08-06 11:19:29 3 new IP(s) added
2026-08-06 11:19:30 suridata done at: jue 06 ago 2026 11:19:30 -05

Regla Ipset:

# SURIDATA
suridatalst="$acl_ipt_path/suridata.txt"
if ! ipset list suridata &>/dev/null; then
    ipset create suridata hash:ip -exist
else
    ipset flush suridata
fi
if [ -f "$suridatalst" ]; then
    for suridataip in $(grep -vE '^\s*#|^\s*$' "$suridatalst" | sort -u 2>/dev/null); do
        is_valid_ip "$suridataip" && ipset add suridata "$suridataip" -exist
    done
else
    log "WARNING: $suridatalst not found -- skipping suridata"
fi
iptables -t mangle -A PREROUTING -i "$lan" -m set --match-set suridata dst -j NFLOG --nflog-prefix "SURIDATA DROP: "
iptables -t mangle -A PREROUTING -i "$lan" -m set --match-set suridata dst -j DROP

El sistema puede extenderse a cualquier SID (Signature ID) o Regex (regular expression filter) de Suricata que el administrador decida incorporar a drop.conf — siempre que exista cobertura real en el ruleset para las firmas específicas. Una vez incluida la entrada y ejecutada la actualización (suricataupdate.sh), suridata.sh captura automáticamente las direcciones IP asociadas a esas alertas y las incorpora a las listas de bloqueo del firewall. Esto incluye tanto alertas nuevas como las que ya estuvieran registradas en el eve.json vigente antes de que la regla pasara a "drop".

Recomendación

La solución descrita en este artículo está orientada a redes LAN pequeñas y medianas, administradas por un servidor Linux que centraliza las comunicaciones, donde suricata e iptables corren y donde toda la infraestructura opera sobre IPv4 .

En este escenario, mantener IPv6 habilitado cuando no se utiliza aporta poco valor y, en cambio, introduce una segunda pila de red que debe administrarse y protegerse por separado. Protocolos como NDP (Neighbor Discovery Protocol) reemplazan a ARP, las reglas del firewall deben duplicarse en ip6tables o su equivalente, y las listas de bloqueo, firmas y controles también deben contemplar direcciones IPv6.

Si la organización no tiene previsto utilizar IPv6 a corto o mediano plazo, es recomendable deshabilitarlo tanto en el gateway como en los equipos cliente. De esta forma se reduce la superficie de ataque, se simplifica la administración del firewall y se evita que tráfico IPv6 eluda controles diseñados únicamente para IPv4.

Esta recomendación no implica que IPv6 sea inseguro o deba deshabilitarse de forma general. Si la infraestructura utiliza IPv6 de manera activa, la solución debe extenderse para inspeccionar y aplicar las mismas políticas de seguridad sobre ambos protocolos. 

 

Puede consultar los archivos en nuestro repositorio Vault/Gateproxy.