Cómo detectar escaneos NULL y XMAS en MikroTik con firewall RAW

Hay un tipo de escaneo de puertos que no deja rastro en los logs estándar de tu router. Los escaneos NULL y XMAS explotan el comportamiento del protocolo TCP para mapear puertos abiertos sin generar conexiones completas — y por tanto, sin activar los mecanismos de detección habituales. Si administras redes con MikroTik y solo confías en el firewall filter para protegerte, estos escaneos pueden pasar completamente desapercibidos. En este artículo te explicamos cómo funcionan, por qué el firewall RAW es la herramienta correcta para bloquearlos y te damos las reglas listas para implementar en RouterOS.

Qué son los escaneos NULL y XMAS y por qué no los ves en los logs

Para entender estos escaneos necesitas saber cómo funciona TCP a nivel de flags. Cada paquete TCP lleva una combinación de flags que indica su propósito: SYN para iniciar conexión, ACK para confirmar, FIN para cerrar, RST para resetear, PSH para enviar datos inmediatamente y URG para marcar urgencia.

En una comunicación legítima, estas flags siguen patrones predecibles — el clásico three-way handshake SYN → SYN+ACK → ACK. Pero nada impide que un atacante envíe paquetes con combinaciones de flags que no deberían existir en tráfico normal.

NULL scan

Un paquete TCP sin ningún flag activado. Literalmente, un paquete vacío. Según la RFC 793, cuando un sistema recibe un paquete así en un puerto cerrado, responde con RST. Pero si el puerto está abierto, no responde nada. El atacante envía estos paquetes a miles de puertos y, por descarte, identifica cuáles están abiertos — los que no respondieron.

Lo peligroso es que al no haber flags, no hay conexión, y al no haber conexión, el connection tracking de RouterOS no lo registra como una sesión. No aparece en los logs a menos que tengas reglas específicas para detectarlo.

XMAS scan

El opuesto del NULL: un paquete con las flags FIN, PSH y URG activadas simultáneamente — como un árbol de Navidad con todas las luces encendidas, de ahí su nombre. Esta combinación es absurda en tráfico legítimo: no tiene sentido enviar un FIN (cerrar) con PSH (enviar inmediato) y URG (urgente) sin haber establecido una conexión primero.

El mecanismo de detección es el mismo que en NULL: puerto cerrado responde con RST, puerto abierto no responde. Y al igual que el NULL scan, pasa por debajo del radar del firewall filter si no tienes reglas explícitas.

Otras combinaciones inválidas

Los escaneos NULL y XMAS son los más conocidos, pero hay más combinaciones de TCP flags que nunca deberían existir en tráfico legítimo: FIN+SYN (cerrar y abrir al mismo tiempo), SYN+RST (iniciar y resetear a la vez), FIN+RST (cerrar y resetear simultáneamente), o FIN sin ACK. Si ves cualquiera de estas en tu red, es tráfico malicioso o malformado — en ambos casos, hay que descartarlo.

Por qué usar RAW en lugar de Filter

La mayoría de guías de firewall en MikroTik ponen las reglas de detección de escaneos en la cadena input o forward del firewall filter. Funciona, pero no es la forma más eficiente.

El firewall RAW procesa los paquetes antes del connection tracking. En el diagrama de packet flow de RouterOS, RAW está justo al principio — el paquete entra por la interfaz, pasa por RAW prerouting, y solo después llega al connection tracking y al firewall filter.

¿Por qué importa esto? Porque el connection tracking consume recursos. Cuando un atacante lanza un escaneo masivo con nmap, está enviando miles de paquetes por segundo. Si esos paquetes llegan hasta el firewall filter, el router ya gastó CPU procesando cada uno en el connection tracking — analizando si pertenece a una conexión existente, si es nuevo, si es inválido. Con RAW, el paquete se descarta antes de todo eso.

En pruebas reales, la diferencia es significativa. Un escaneo masivo procesado por firewall filter puede llevar un RB750 al 13% de CPU. El mismo escaneo filtrado en RAW baja al 5%. En equipos más potentes la diferencia absoluta es menor, pero en un ataque sostenido o en equipos con muchas reglas, cada punto de CPU cuenta.

Las cadenas disponibles en RAW son prerouting (tráfico entrante) y output (tráfico generado por el router). Para detectar escaneos externos, usamos prerouting.

Las reglas: detectar y bloquear combinaciones inválidas de TCP flags

Aquí van las reglas para implementar en tu router. Cada una detecta un tipo específico de paquete TCP inválido:

# NULL scan — ningún flag activado
/ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg \
  action=drop comment="Drop NULL scan"
 # XMAS scan — FIN+PSH+URG sin SYN/RST/ACK
/ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=fin,psh,urg,!syn,!rst,!ack \
  action=drop comment="Drop XMAS scan"
 # FIN+SYN — imposible en tráfico legítimo
/ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=fin,syn \
  action=drop comment="Drop FIN+SYN"
 # SYN+RST — imposible en tráfico legítimo
/ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=syn,rst \
  action=drop comment="Drop SYN+RST"
 # FIN+RST — imposible en tráfico legítimo
/ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=fin,rst \
  action=drop comment="Drop FIN+RST"
 # FIN sin ACK — inválido según RFC
/ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=fin,!ack \
  action=drop comment="Drop FIN sin ACK"

Estas seis reglas cubren las combinaciones de TCP flags que nunca deberían aparecer en tráfico legítimo. Puedes copiarlas directamente en tu terminal de RouterOS.

Un detalle importante sobre el orden: coloca estas reglas al principio de tu tabla RAW, antes de cualquier regla de accept. RAW se procesa secuencialmente de arriba a abajo — si tienes un accept general antes, los paquetes maliciosos lo matchearán y pasarán.

Ir un paso más allá: blacklisting automático con address-lists

Dropear los paquetes está bien, pero tiene una limitación: solo descartas ese paquete concreto. El atacante puede seguir enviando otros tipos de tráfico desde la misma IP. Si alguien está escaneando tus puertos con técnicas stealth, probablemente tiene malas intenciones — mejor bloquear toda la IP.

Para esto combinamos la detección con address-lists:

# Detectar y añadir a blacklist
/ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg \
  action=add-src-to-address-list \
  address-list=port-scanners address-list-timeout=1w \
  comment="Detect NULL scan → blacklist"
 /ip/firewall/raw/add chain=prerouting protocol=tcp \
  tcp-flags=fin,psh,urg,!syn,!rst,!ack \
  action=add-src-to-address-list \
  address-list=port-scanners address-list-timeout=1w \
  comment="Detect XMAS scan → blacklist"
 # Bloquear todo el tráfico de IPs en la blacklist
/ip/firewall/raw/add chain=prerouting \
  src-address-list=port-scanners \
  action=drop comment="Drop todo tráfico de port-scanners"

Con esta configuración, cualquier IP que envíe un paquete NULL o XMAS queda bloqueada durante una semana (address-list-timeout=1w). Puedes ajustar el timeout según tu criterio — desde unas horas para ser menos agresivo hasta varias semanas para entornos con requisitos de seguridad estrictos.

Para ver qué IPs han sido detectadas:

/ip/firewall/address-list/print where list=port-scanners

Te sorprenderá la cantidad de IPs que aparecen en pocas horas si tu router tiene una IP pública expuesta.

Cómo verificar que funciona

Configurar reglas sin probarlas es como poner una alarma sin comprobar que suena. Desde una máquina externa (nunca desde la misma red que estás protegiendo), puedes usar nmap para generar exactamente estos tipos de escaneo:

# NULL scan nmap -sN [IP_DEL_ROUTER]  # XMAS scan nmap -sX [IP_DEL_ROUTER]

Después de ejecutarlos, verifica en tu router que los contadores de las reglas RAW se han incrementado:

/ip/firewall/raw/print stats

Si usas el método de blacklisting, la IP desde la que lanzaste nmap debería aparecer en la address-list:

/ip/firewall/address-list/print where list=port-scanners

Y a partir de ese momento, todo el tráfico desde esa IP será descartado.

Una advertencia importante: nunca lances estos escaneos contra equipos en producción que no sean tuyos o contra IPs de terceros. Es ilegal en la mayoría de jurisdicciones y es exactamente lo que estamos intentando bloquear.

Practica en un entorno seguro

Acabas de leer la teoría y tienes los comandos listos. Pero probar reglas de firewall en producción es arriesgado — un error en una regla RAW puede dejarte sin acceso al router o bloquear tráfico legítimo.

En LanPixel Labs hemos creado laboratorios virtuales gratuitos donde puedes practicar exactamente esto: configurar reglas RAW, lanzar escaneos con nmap contra tu router virtualizado y comprobar que tus reglas funcionan — sin riesgo y sin romper nada en producción. La plataforma incluye labs específicos de firewall donde puedes experimentar con todas las técnicas de este artículo en un entorno controlado.

Es gratuito, no necesitas instalar nada y puedes empezar ahora mismo. Accede a los labs en labs.lanpixel.com y pon a prueba lo que has aprendido.