Tu cortafuegos acepta instrucciones de desconocidos. Apaga los ayudantes de protocolo.

En tu cortafuegos hay una función que lee dentro de tus paquetes, encuentra ahí una dirección IP y un número de puerto escritos en texto, y abre un hueco entrante para ellos. Sin regla. Sin petición de cambio. Sin una línea de registro que vayas a mirar jamás. En la mayoría del equipamiento que la lleva viene encendida de fábrica, lleva así casi veinticinco años, y el sector que la puso ahí ha ido concluyendo en silencio durante los últimos veinte que debería estar apagada: en documentos de estándares, en valores por defecto del kernel y en cuatro tandas separadas de parches de emergencia para navegadores.

Se llama ayudante de protocolo, o Application Level Gateway, ALG, session helper, fixup, motor de inspección, ayudante de conntrack. Lo mismo. Existe porque NAT rompió un puñado de protocolos que escriben direcciones dentro de su propia carga útil, y porque alguien decidió que la solución menos mala era enseñar al traductor a leer y reescribir esa carga al vuelo.

Aquí viene la parte que debería detenerte.

El ayudante no puede saber quién escribió el texto. Lee bytes de una conexión y actúa según ellos, al instante, sin preguntar a nada ni a nadie. No tiene manera de saber si la cadena PORT 192,168,1,29,4,0 vino de un cliente FTP real haciendo una transferencia real, o de un formulario oculto en una página web que tu usuario abrió sin querer. En el cable se ven idénticos, porque en el cable son idénticos. Así que un desconocido en internet que consiga que algo dentro de tu red envíe los bytes correctos — un navegador, un cliente de chat, cualquier cosa que envíe lo que le digas — puede elegir qué puerto entrante abre tu cortafuegos, y hacia dónde.

Eso no es un fallo en el analizador de un fabricante concreto. Eso es lo que hace la función. Los informes de fallos y los CVE son el detalle interesante que va encima; la forma de debajo es un dispositivo de seguridad que toma instrucciones de configuración de datos no confiables y las ejecuta de inmediato.

Samy Kamkar enseñó la versión del navegador en enero de 2010¹, una mucho mejor en octubre de 2020², y tres meses después Armis la extendió para que el puerto abierto ni siquiera tuviera que estar en la máquina que hizo clic: puede estar en tu impresora, en tu cámara o en un controlador programable dos VLAN más allá³. Entremedias, el IETF dejó escrito que estas cosas deben venir apagadas de fábrica⁴, Linux las apagó en el kernel⁵, y los fabricantes de navegadores publicaron una lista de puertos bloqueados que se lee, casi línea por línea, como el índice de los módulos de conntrack de Linux⁶. Cada uno de esos arreglos se aplicó en otro sitio, porque lo que de verdad había que arreglar vive en una caja que nadie va a parchear.

Mi conclusión es que los ayudantes de protocolo deben venir apagados en todas partes, y deben estar realmente apagados en cualquier red de la que respondas tú. No afinados. No restringidos a subredes confiables como primera medida. Apagados, con las dos o tres excepciones reales escritas y fechadas, exactamente igual que documentarías cualquier otra regla entrante, porque eso es lo que son.

Lo que sigue es el mecanismo, luego los ataques en el orden en que se descubrieron, luego el lado del cumplimiento normativo, porque en el Reino Unido esto no es solo poco recomendable sino un incumplimiento directo de un requisito de certificación que quizá ya tengas, y por último los comandos para arreglarlo.

Qué saca de esto un desconocido

Empieza por el resultado, porque el mecanismo se sigue mejor cuando ya has visto la factura. Alguien abre un enlace. Esa es toda su contribución. La página ejecuta JavaScript que habla con el servidor del atacante, y ese servidor moldea la conversación — la rellena, la mide, confirma unas partes y otras no — hasta que llega a tu cortafuegos un segmento que parece exactamente el mensaje de apertura de una llamada VoIP. Tu cortafuegos se lo cree, porque creérselo es la función. Crea un enlace entrante, y el atacante se conecta de vuelta a través de él de inmediato.

En la versión de 2020 el puerto se abre en la máquina que hizo clic, así que cualquier servicio que esté escuchando en ese equipo queda alcanzable desde internet mientras el enlace siga vivo². Compartición de ficheros. El escritorio remoto que nadie quería dejar escuchando. Sobre el Fisher-Price OS (Windows), Armis hizo la observación obvia: alcanza el puerto de compartición de ficheros y estás a un equipo sin parchear del camino por el que pasó WannaCry³.

La versión de 2021 es peor, y es la parte que debería decidirlo por ti. Como el ayudante de H.323 gestiona el desvío de llamada, un solo mensaje puede nombrar una tercera dirección en lugar de uno de los dos extremos de la conexión. El atacante deja entonces de estar limitado a la máquina que hizo clic y puede recorrer tu rango interno, abrir un puerto en cualquier dirección y leer lo que responda. Armis demostró exactamente eso: puerto 80 en todo un rango, banners recogidos, un objetivo elegido, y después el puerto de impresión en crudo de la impresora abierto y un trabajo enviado a él. Su segunda demostración alcanzó un controlador por el puerto de gestión sin autenticar y cambió el programa³.

En ninguno de esos dispositivos se explotó una vulnerabilidad. La impresora era una impresora que funcionaba, la cámara una cámara que funcionaba, el controlador un controlador que funcionaba, y lo único que falló fue el perímetro, que falló haciendo exactamente aquello para lo que estaba configurado. Piensa además en quién está dentro de ese perímetro. No solo tu plantilla: un visitante en la red de invitados, el portátil de un contratista, cualquiera con un navegador. El ataque no necesita credenciales, ni un punto de apoyo previo, ni malware, porque el vehículo es el navegador y ya está instalado y ya goza de confianza.

Ahora pon eso junto a para qué sirve un cortafuegos: para que nada de fuera inicie una conversación con nada de dentro salvo que tú lo hayas dicho. El ayudante es la excepción, y esa excepción se concede por la autoridad de una cadena de texto dentro de un paquete.

Qué es en realidad un ayudante de protocolo

Un NAT normal es una cosa tonta y honrada. Llega un paquete, reescribe la dirección y el puerto de origen en la cabecera, anota una entrada para poder deshacerlo en la respuesta, y lo reenvía. Nunca mira por debajo de la cabecera de transporte, y le da igual que los bytes de dentro sean una petición web, una consulta a una base de datos o la foto de un perro.

Eso funciona hasta que un protocolo escribe una dirección dentro de su propia carga útil. FTP lo hace, en texto plano dentro del flujo de control: conéctate de vuelta a mí en esta dirección, en este puerto. SIP lo hace en los campos Via, Contact y SDP, H.323 lo hace, e IRC lo hace para las transferencias directas. Todos se diseñaron cuando la dirección de un equipo era la dirección de ese equipo y cualquier máquina podía alcanzar a cualquier otra, y bajo esa premisa es perfectamente razonable. Mete un traductor en el camino y la dirección de la carga útil se convierte en una mentira.

Así que se inventó el ayudante. Lee la carga útil, encuentra la dirección, la reescribe a la dirección pública, y entonces hace la parte que todo el mundo pasa por alto: crea una entrada que permite exactamente la conexión entrante que acaba de describir la carga útil. Netfilter llama a esa entrada una expectativa. Cisco la llama un pinhole, o una puerta NAT⁷. Palo Alto la llama un pinhole NAT dinámico⁸. Juniper la llama una gate. Otra palabra, el mismo objeto: un agujero en el perímetro, abierto por la autoridad de algo leído dentro de un paquete.

El IETF le puso nombre al patrón antes de que existieran la mayoría de estos productos. Un ALG, dice el RFC 2663, es un «application specific translation agent» que «may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is necessary to get the application running across disparate address realms»⁹. Léelo otra vez pensando en un adversario: whatever else is necessary, dirigido por application specific payload. Y ya en febrero de 2002 la taxonomía de middleboxes del IETF nombraba el mecanismo, observando que algunos ALG causan problemas de fragmentación «although in this case the problem is arguably the result of a deliberate layer violation (e.g., mucking with the application data stream of an FTP control connection by twiddling TCP segments on the fly)»¹⁰.

Una violación de capa deliberada. Manosear segmentos TCP al vuelo. Ese es el mecanismo, descrito por las personas que lo cartografiaron hace veinticuatro años, y es el mismo mecanismo por el que pasa de largo cada ataque de este artículo.

La expectativa es todo el problema

Todo lo demás en este artículo se deduce de un solo objeto, así que vale la pena entenderlo bien.

Una expectativa es una conexión preautorizada: una tupla de dirección de origen, puerto de origen, dirección de destino, puerto de destino y protocolo, con algunos campos rellenos y otros dejados como comodines, más un temporizador. Si llega un paquete que encaja, el cortafuegos lo trata como emparentado con un flujo permitido que ya existe en lugar de como una conexión entrante nueva, lo deja pasar y consume la expectativa. En Linux las lees directamente de /proc/net/nf_conntrack_expect, o con conntrack -L expect. En un sistema sano esa lista está vacía, y ese es justo el punto: las expectativas deberían ser raras, de vida corta y provocadas por algo que un equipo de dentro pidió de verdad.

Dos de esas respuestas son peores de lo que la gente espera. Los valores vienen de la carga útil y no del cortafuegos, es decir, del extremo de la conversación que el ayudante resultó leer. Y en el ayudante de IRC la dirección de origen es un comodín por diseño, porque el protocolo no puede saber quién se va a conectar: «creates expectations whose destination address is the client address and source address is any address»¹¹.

Esta es la frase que hay que llevarse. Una expectativa es una regla de cortafuegos entrante, creada a velocidad de línea, por una parte no confiable, sin ningún rastro de quién la pidió ni por qué. Guárdala hasta la sección de Cyber Essentials, porque allí es el argumento entero.

Tal como se diseñó: FTP dice PORT, y el cortafuegos se lo cree

Coge el ayudante más simple y mira cómo funciona correctamente, porque el ataque es la misma secuencia con un participante sustituido. El FTP activo usa dos conexiones. El cliente abre una conexión de control al servidor por el puerto 21 y le manda comandos en ASCII llano, y cuando hace falta una transferencia abre un socket a la escucha y envía un comando PORT con la dirección y el puerto a los que devolver la llamada, tras lo cual el servidor se conecta hacia dentro. Eso es el protocolo tal como está especificado, y así funciona desde 1985. En el cable son seis números, cuatro para la dirección y dos para el puerto, el byte más alto primero:

PORT 192,168,1,29,4,0

Eso es 192.168.1.29, puerto 1024, porque 4 × 256 + 0 = 1024.

El ayudante vigila ese flujo, ve PORT, reescribe la dirección de la privada a la pública ajustando los números de secuencia porque el texto cambió de longitud, y crea una expectativa que permite la conexión entrante del servidor al puerto indicado. Genuinamente útil, perfectamente razonable dadas las limitaciones de 1994, y correcto en cada paso.

Mira bien qué se comprobó antes de que se abriera el hueco. Los bytes iban por una conexión al puerto 21. Empezaban por PORT. Eso es todo. Nada más, porque no hay nada más que comprobar: FTP no ofrece firma alguna, ni clave de sesión, ni autenticación de ningún tipo, y el ayudante está leyendo un flujo del que no forma parte.

En ese código hay algo más, y es un aviso que los autores se escribieron a sí mismos. Si la dirección del comando PORT no es la del propio cliente — es decir, si el cliente le pide al servidor que se conecte a otro sitio —, el ayudante de Linux lo rechaza por defecto, y el comentario del código fuente dice por qué: «DMZ machines opening holes to internal networks, or the packet filter itself»¹². Pon el parámetro de módulo loose y ese rechazo desaparece. Quienes escribieron el ayudante sabían exactamente a qué se le podía inducir. Publicaron el valor por defecto seguro y un interruptor, y veinticinco años después el interruptor sigue ahí.

No como se diseñó: los mismos bytes, desde una página web

Un ayudante lee un flujo de bytes buscando un patrón. No comprueba, y estructuralmente no puede comprobar, si lo que hay al otro lado es el cliente que dice ser. Samy Kamkar publicó la consecuencia en enero de 2010 y la llamó NAT Pinning¹. El truco es vergonzosamente pequeño: pon un formulario en una página web, apúntalo al servidor del atacante en el puerto 6667, y haz que su contenido lleve dentro una petición de chat directo.

PRIVMSG samy :^ADCC CHAT samy 3325256705 22^A

El navegador lo envía creyendo que hace un POST de HTTP. El ayudante de IRC del router, vigilando una conexión al puerto 6667, ve pasar DCC CHAT con una dirección y un puerto y hace aquello para lo que se construyó. La dirección de ahí es 198.51.100.1 escrita como un solo número decimal, porque así la codifica el protocolo, y el puerto es el 22; nada de ese texto lo eligió la víctima. La variante de FTP es la misma idea apuntada al puerto 21, con una línea de respuesta en modo pasivo en su lugar¹.

Nada de cross-site scripting. Nada de request forgery en el sentido habitual. Ninguna vulnerabilidad del navegador. El navegador hizo lo que hacen los navegadores, el cortafuegos hizo aquello para lo que estaba configurado, y el resultado es una redirección de puerto hacia el atacante.

Eso fue en 2010. Hace dieciséis años. Los fabricantes de navegadores metieron los puertos de IRC en su lista de bloqueo, lo cual cerró esa puerta concreta y dejó la habitación exactamente como estaba.

Di el punto sin rodeos, porque se pierde entre los nombres de fabricante y los números de CVE. Los ataques no explotan un fallo en los ayudantes. Usan los ayudantes correctamente. Cada paquete está bien formado y cada comprobación se supera honradamente. La función hace su trabajo, y su trabajo es el problema.

Colocar los bytes donde el ayudante va a leer

Entre NAT Pinning y algo mucho peor había un obstáculo real, y la forma de rodearlo es lo más ingenioso de todo el asunto. La mayoría de los ayudantes no buscan un patrón en cualquier sitio de un flujo: comprueban que la palabra clave esté al principio de la parte de datos de un paquete, lo cual es cierto en un mensaje de protocolo real y nunca en el cuerpo de una petición HTTP, porque ese cuerpo llega después de un montón de cabeceras que el atacante no controla. Samy cita el propio comportamiento del kernel: el manejador abandona salvo que el método esté al principio de los datos².

Así que el atacante necesita que el navegador emita un segmento cuyo primerísimo byte sea la palabra clave. No puede escribir las cabeceras, pero sí el cuerpo, y tan largo como quiera, lo cual convierte el problema en aritmética.

El navegador envía una petición grande con un separador reconocible escondido en el cuerpo; el servidor del atacante escucha, mide cuántos bytes de cabecera lo precedieron y con eso conoce el desplazamiento. Después, o bien anuncia un tamaño de segmento que deja el byte deseado en un límite, o bien envía una confirmación parcial para que la víctima retransmita empezando justo ahí — y Armis añade que la ventana TCP de esas confirmaciones también se puede fabricar, «in order to fully control how the TCP stream is to be segmented»³. Ese es todo el truco, y no usa más que el extremo remoto de una conexión que el propio navegador de la víctima abrió.

Con eso en la mano, el navegador es un generador de paquetes universal apuntado al interior de tu cortafuegos. No perfecto, porque no puede poner cabeceras arbitrarias ni elegir protocolos arbitrarios, pero nunca hizo falta. Solo tiene que colocar los treinta bytes correctos al principio de un segmento.

El trabajo de 2021 se saltó casi toda la aritmética. Una conexión de relay del navegador sobre TCP lleva un campo de nombre de usuario controlado por el atacante, enviado pronto, que admite saltos de línea y bytes nulos mientras el resultado sea texto válido — Armis mostró una captura en la que ese campo es la cadena \r\nPORT 192,168,1,29,4,0\r\n, con una confirmación parcial que hace que la víctima retransmita justo desde el PORT³. Peor aún, ese camino no consultaba la lista de bloqueo del navegador en absoluto, con lo que la única medida que el sector había publicado dos veces quedaba sorteada sin esfuerzo.

NAT Slipstreaming, de principio a fin

Junta las piezas y este es el ataque entero, en orden.

Tiempo total transcurrido: segundos. Interacción total del usuario: un clic. Vulnerabilidades explotadas en la máquina de la víctima: ninguna.

La cronología de la divulgación es prueba por sí sola. Samy publicó el 31 de octubre de 2020, Armis contactó tres días después, y la notificación coordinada a los fabricantes de navegadores empezó el 11 de noviembre. Chrome publicó una medida el 6 de enero de 2021, Edge al día siguiente, Safari el 14 en beta y el 1 de febrero en estable, Firefox el 26³, registrado como CVE-2020-16043, CVE-2021-23961 y CVE-2021-1799.

Cuatro fabricantes de navegadores publicando parches de emergencia por una función de cortafuegos. Armis explica por qué con sus propias palabras: «While the underlying issue of this attack is the way NATs are implemented (in various ways in routers and firewalls, throughout numerous vendors and applications), the easiest and fastest way to mitigate was through a patch to browsers»³.

Eso no es un arreglo. Son cuatro sectores distintos apilando sacos terreros delante de la puerta de otro, porque esa puerta nunca se iba a cambiar.

El desvío de llamada de H.323 apunta a cualquier cosa de tu red

La mayoría de los ayudantes limitan el daño sin pretenderlo. El ayudante de FTP fija el destino de la expectativa al cliente que la creó, así que lo peor que consigue un atacante es un puerto en la máquina que hizo clic: malo, pero sobrevivible.

H.323 es catastrófico, y la razón es una función de telefonía.

Una centralita tiene que soportar el desvío de llamada, y una llamada desviada es por definición una llamada con alguien que no está al teléfono. Así que la señalización tiene que poder nombrar un tercer extremo, y el ayudante tiene que abrir un camino hacia él, o el desvío a través de NAT no funciona en absoluto. Cualquier implementación seria puede hacerlo, y el ayudante de netfilter documenta el comportamiento explícitamente, con dibujo, en el sitio de netfilter¹³. Armis leyó el código y resumió la consecuencia en una frase: «a single H.323 packet sent over TCP port 1720 that initiates call forwarding can open a pinhole (named an expectation in the conntrack subsystem) to any TCP port of any internal IP on the network»³.

Cualquier puerto TCP. Cualquier dirección interna. A partir de un paquete, que el atacante consiguió que enviara un navegador.

Con eso, el ataque deja de tratar sobre la máquina de la víctima y se convierte en un escaneo de puertos de tu red interna, ejecutado desde internet, con los resultados leídos de vuelta por conexiones que tu propio cortafuegos permite. Los dispositivos que encuentra son el meollo, porque no están parcheados, a menudo no se pueden parchear, y el modelo de seguridad de la mayoría de ellos es está dentro. Armis le puso una cifra a esa premisa: un año después de la publicación, el 97 % de los controladores industriales vulnerables a un conjunto de fallos críticos seguían sin parchear³. Nadie dice que esa cifra esté bien. Es la realidad que sostiene «está dentro».

Así que H.323 es lo primero que hay que tratar en cualquier plataforma, porque es lo único que alcanza más allá de la víctima, y como además es el protocolo que ya casi nadie usa, es la mejora de seguridad más barata de este artículo. Apágalo. Nadie te llamará por ello.

El ayudante puede dispararse con un mensaje que tú nunca enviaste

Una variante merece su propia sección, porque destruye la premisa a la que se agarra la gente cuando busca una razón para no hacer nada: vale, pero el disparo tiene que venir de dentro, así que controla los navegadores y controlas el problema.

No.

En julio de 2022 David Leadbeater encontró dos fallos en el ayudante de IRC de Linux¹⁴. El módulo busca la cadena \1DCC en cualquier parte del flujo en lugar de comprobar que esté en el sitio correcto de un mensaje bien enmarcado, y la comprobación de dirección compara con la dirección del servidor de chat en vez de con el equipo detrás del traductor, con lo que basta la dirección públicamente conocida de un servidor público. Junta las dos y un atacante envía al cliente de la víctima un ping de cliente a cliente — algo perfectamente normal de recibir de otro usuario — con una petición de transferencia directa dentro:

PRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A

Según las reglas del protocolo, un cliente responde a un ping devolviendo el contenido, así que el cliente de la víctima envía esa cadena obedientemente hacia fuera, y el ayudante, vigilando el flujo saliente, encuentra DCC dentro y abre el puerto.

Nadie de dentro hizo nada mal y nadie hizo clic. El cliente siguió la especificación, y entre la especificación y el ayudante produjeron un hueco entrante al puerto 22 de una máquina de la red. Se le asignó el CVE-2022-2663, y la descripción de la base de datos nacional de vulnerabilidades es admirablemente clara: «A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured»¹⁵.

Fíjate en la palabra unencrypted. Recuérdala también.

La recomendación del autor es exactamente donde desemboca el resto de este artículo por otro camino: «Potentially entirely deprecate and remove nf_conntrack_irc, it’s unclear it has much use anymore»¹⁴.

Los analizadores son la otra mitad

Hasta aquí el tema han sido ayudantes funcionando correctamente. Hay un segundo problema, aparte: son analizadores de protocolo escritos en C, ejecutándose en el camino rápido de un dispositivo de seguridad, sobre datos que aportan desconocidos, y tienen la tasa de fallos que cabe esperar de esa descripción. Y esto no es un problema de Linux ni de routers baratos: aparece en todos los fabricantes, en el código por el que más cobran.

Todos ellos son alcanzables desde la red sin autenticación alguna, por cualquiera que pueda hacer llegar un paquete a la interfaz externa, es decir, por cualquiera. Y lee el lenguaje: specific SIP messages, specific H.323 packets, a specific SIP packet. Eso no es un protocolo cediendo bajo carga. Es alguien construyendo un paquete a propósito.

Quédate un momento con el caso de Cisco. El CVE-2018-15454 se publicó el 31 de octubre de 2018 con una gravedad de 8,6, se explotó en la práctica, y el aviso decía que la actualización de software aún no estaba disponible¹⁶. La medida paliativa de Cisco, en su propio aviso, es no inspect sip. O sea, que la respuesta del fabricante a un fallo activamente explotado en la función fue apagar la función, lo cual plantea la pregunta sobre la que descansa el resto del artículo. Si apagarlo es una respuesta aceptable durante un incidente, ¿sobre qué base está encendido el resto del tiempo?

Un ayudante solo funciona si no cifras

Esta es la parte que debería zanjar la discusión por sí sola, y es la que menos atención recibe. Un ayudante de protocolo lee tu carga útil y no puede leer una cifrada. Así que un ayudante solo hace algo con tráfico que dejaste deliberadamente sin cifrar, y mantener el ayudante en funcionamiento significa mantener ese tráfico sin cifrar.

Todos los protocolos de la lista llevan más de una década con un modo cifrado. FTP tiene TLS desde 2005¹⁷; actívalo y los intercambios PORT y PASV son invisibles y el ayudante no hace nada. SIP tiene TLS desde su especificación base, con medios cifrados al lado. H.323 tiene su propio anexo de seguridad. El chat tiene TLS desde hace muchísimo, y el consejo oficial junto al CVE-2022-2663 era literalmente usarlo para que el ayudante no vea tus peticiones de transferencia¹⁵.

Así que la formulación honrada de «necesitamos el SIP ALG» es: necesitamos que nuestra señalización de llamadas viaje sin cifrar por redes no confiables, para que un middlebox que no controlamos pueda reescribirla. Dilo así en una revisión de diseño y mira hasta dónde llegas.

Hay una versión más afilada, y por eso esto no está ni cerca de ser discutible. Dejar un ayudante encendido es un incentivo permanente contra el cifrado: el día que alguien active SIP sobre TLS, las llamadas se rompen y el ayudante es la razón, así que el cambio se revierte y el texto en claro se queda otro año. Pregúntale a cualquiera que lo haya intentado detrás de un cortafuegos doméstico cómo le fue.

Todos los demás protocolos de internet han ido en la dirección contraria: tráfico web cifrado por defecto, DNS cifrado, transporte de correo cifrado, QUIC cifrando incluso la cabecera de transporte precisamente para que los middleboxes no puedan leerla ni cambiarla. La era del middlebox terminó hace años en la internet abierta, y los últimos sitios que aún dependen de un dispositivo intermedio que lee la carga útil son los sitios donde alguien dejó un ayudante encendido.

IPsec es el caso en el que el ayudante no puede leer nada

Lo que plantea la pregunta obvia sobre el protocolo que no es más que cifrado. La respuesta es peor de lo que imaginarías.

ESP no tiene números de puerto, porque es un protocolo IP por derecho propio y no algo transportado sobre UDP, y un traductor demultiplexa el tráfico de vuelta por puerto. Así que con dos clientes detrás de una misma dirección pública yendo a la misma pasarela no hay nada que distinga sus paquetes entrantes. El RFC 3715 lo dejó escrito en marzo de 2004: un NAT no puede aprender la correspondencia por inspección, y «it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination»¹⁸.

Así que los fabricantes construyeron un ayudante. Vigila el intercambio IKE en UDP 500, cuyos primeros paquetes van en claro, cosecha las cookies y el índice de parámetros de seguridad, y abre una puerta para que el ESP entrante que lleve ese valor llegue al equipo correcto de dentro. Juniper lo describe con la mayor claridad: «When ESP traffic hits the IKE ALG gates, sessions are created to capture subsequent ESP traffic»¹⁹. El inspect ipsec-pass-thru de Cisco hace lo mismo con ESP y AH «associated with an IKE UDP port 500 connection», con un mapa por defecto que no fija límite alguno de conexiones ESP por cliente²⁰.

El mismo objeto, la misma autoridad, salvo que aquí el ayudante ni siquiera está buscando una palabra clave. No puede analizar ESP, porque ESP es justo la parte cifrada; está dirigiendo paquetes por un número de 32 bits que vio pasar en claro. La sección del RFC 3715 que cubre esto se titula, sin ironía alguna, «Helper Incompatibilities», y deja constancia de que demultiplexar por cookie «results in problems with re-keying» y de que los dispositivos que analizan cargas útiles ISAKMP «may not handle all payload ordering combinations»¹⁸. Una conjetura en lugar de una regla, y un analizador casero en el camino de los paquetes, escrito hace veintidós años.

El arreglo llegó diez meses después, dentro del protocolo, que es donde corresponde: el RFC 3947 hace que los dos extremos detecten un traductor durante el intercambio de claves, y el RFC 3948 envuelve ESP en UDP por el puerto 4500 para que vuelva a haber puertos²¹. Y entonces Juniper lo dice en voz alta: «IKE NAT-T traffic on floating port 4500 is not processed in an IKE ALG»¹⁹. Hazlo bien y el ayudante queda enteramente sorteado, que es la misma frase que el FTP pasivo y que ICE.

El Linux principal nunca aceptó este. No hay módulo ESP entre los protocolos de conntrack, y un parche de 2021 que añadía seguimiento basado en el SPI pasó la revisión en la lista de netfilter y nunca se integró²². Los fabricantes que lo llevan lo llevan fuera del árbol, en los equipos que menos probablemente se actualicen jamás.

Incumple Cyber Essentials, punto por punto

Hasta aquí esto ha sido un argumento de seguridad. Para quien se certifica en el Reino Unido es también un argumento de cumplimiento, y no hace falta ninguna interpretación ingeniosa: son tres puntos contra tres puntos. Cyber Essentials es el programa respaldado por el gobierno británico y gestionado a través de IASME, su primer control técnico es sobre cortafuegos, y el documento de requisitos vigente es la versión 3.3 de abril de 2026. Esto es lo que te exige, literalmente²³:

• block unauthenticated inbound connections by default
• ensure inbound firewall rules are approved and documented by an authorised person, and include the business need in the documentation
• remove or disable unnecessary firewall rules, when they are no longer needed

Ahora pon un ayudante de protocolo al lado.

Una expectativa existe precisamente para permitir una conexión entrante que de otro modo se bloquearía, y la parte cuyos datos la provocaron no se autenticó contra nada, así que el primer punto se incumple de plano. La regla la escribió un módulo del kernel a velocidad de línea, así que no hay documento, no hay necesidad de negocio registrada y no hay persona autorizada en ningún punto de la cadena: pídele a un auditor la prueba de aprobación de la regla que dejó llegar una conexión al puerto 9100 de tu impresora y no la tienes ni la puedes fabricar, porque existió durante noventa segundos hace dieciocho meses. Y las reglas de un ayudante las borra un temporizador, y un temporizador no es una revisión.

Tres requisitos, tres incumplimientos, en el primero de cinco controles, que en palabras del propio programa se aplica a «boundary firewalls, desktop computers, laptops, routers, servers»²³, es decir, a todo lo que posees.

Sé honrado sobre lo que eso significa, porque yo no soy el organismo certificador. Un evaluador trabaja con el cuestionario y con las pruebas que tú le das, y ese cuestionario pregunta si bloqueas por defecto las conexiones entrantes no autenticadas y si tus reglas entrantes están documentadas y aprobadas. Responde que sí con un ayudante corriendo en tu perímetro y la respuesta es falsa. Probablemente apruebes igual. Aprobar y cumplir no son lo mismo, y la diferencia entre ambos sale a la luz después de un incidente en lugar de antes.

Cyber Essentials tampoco es raro en lo que pide, solo inusualmente claro al escribirlo. Un estándar del sector de las tarjetas, un programa gubernamental, el cuestionario de un cliente y el formulario de tu aseguradora piden todos lo mismo con otras palabras: ¿sabes qué permite entrar tu cortafuegos, y lo decidió alguien? Así que esta es la sección para quien firma el certificado. No los ataques ni los CVE. Tres puntos, y la respuesta honrada a cada uno.

El sector decidió esto hace veinte años

Nada de esto es nuevo y nada es discutible. Lo notable es cuánto tiempo lleva tomada la decisión mientras los valores por defecto seguían impasibles.

El RFC 3027 cartografió en enero de 2001 todos los protocolos que NAT rompe²⁴. El RFC 3234 metió los ALG en la taxonomía de middleboxes un año después, llamó al mecanismo «a deliberate layer violation», y fue claro sobre el coste de añadir cajas a un camino: «creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models»¹⁰. Después, en enero de 2007, el RFC 4787 — una Best Current Practice, no una sugerencia — estableció cómo debe comportarse NAT, y el requisito número diez decía esto:

REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off.⁴

Apagados. Hace diecinueve años, con el motivo incluido: los ayudantes estorban a los mecanismos que sí funcionan, y te impiden proteger la integridad de tu propio tráfico. La misma sección observa con hastío que algunos productos llevan los ALG «turned on permanently»⁴.

Tres años después, NAT Pinning dejó que una página web abriera un puerto¹. Netfilter respondió en 2012 con una forma de hacerlo deliberadamente en lugar de automáticamente: el destino CT, que ata un ayudante a un flujo concreto mediante una regla explícita, y un interruptor para detener del todo la asignación automática¹¹. Después, el 25 de abril de 2016, el kernel cambió su valor por defecto, con un mensaje de commit que merece leerse entero de lo cansado que suena:

Four years ago we introduced a new sysctl knob to disable automatic helper assignment […] This knob kept this behaviour enabled by default to remain conservative. This measure was introduced to provide a secure way to configure iptables and connection tracking helpers through explicit rules. Give the time we have waited for this, let’s turn off this by default now, worse case users still have a chance to recover the former behaviour by explicitly enabling this back through sysctl.⁵

Eso llegó con Linux 4.7, y desde entonces una caja con esos módulos cargados no hace nada con ellos hasta que escribas una regla que ate uno a un flujo, con una línea de registro que te lo dice. Todo lo posterior está en el diagrama de arriba: Slipstreaming y la variante para cualquier dispositivo, cuatro fabricantes de navegadores publicando medidas mientras el propio estándar de la plataforma web incorporaba la lista de puertos²⁵, el ayudante de IRC disparándose con un mensaje que nadie redactó, y cuatro vulnerabilidades más de ALG en los cortafuegos insignia de un solo fabricante.

Ahora fíjate en qué falta de la lista. En veinticinco años, ninguna de sus líneas es un fabricante de cortafuegos publicando una actualización de firmware que apague estas cosas en equipos ya entregados. El organismo de estándares lo pidió. El kernel lo hizo aguas arriba. Los investigadores lo demostraron cuatro veces por separado. Los navegadores lo pagaron. Las cajas siguieron funcionando.

Y la lista de puertos bloqueados es la señal. Los puertos 69, 137, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 y 10080 están todos ahí⁶ — TFTP, NetBIOS, SNMP, RTSP, H.323 dos veces, PPTP, SIP dos veces, el protocolo de escáner y el de copias de seguridad Amanda. Enumera los módulos de ayudante de un árbol del kernel de Linux y descubrirás que has leído la misma lista dos veces. No es casualidad, y no es una medida de seguridad. Es un sector manteniendo permanentemente una lista creciente de puertos bloqueados porque otro sector no quiere cambiar un valor por defecto.

Debajo de la mayoría de los logotipos hay Linux

El detalle de netfilter es la parte importante y no una digresión con forma de Linux, y vale la pena decir por qué antes de la lista de fabricantes. Una enorme proporción de las cajas que hacen NAT en este planeta es Linux con netfilter bajo una carcasa de fabricante: todos los derivados de OpenWrt, es decir, la mayor parte del mercado de routers de consumo y pyme, la mayoría de los routers domésticos que entrega el operador, buena parte del equipamiento de NAT a escala de operador, y un montón de appliances comerciales cuya interfaz web no delata nada de lo que hay debajo. El ayudante que analiza tu SIP es, en muchísimos casos, ese mismo nf_conntrack_sip.c que está en el kernel principal, compilado por otro y expuesto en un menú.

La prueba está en la propia investigación. Cuando Samy fue a buscar el SIP ALG dentro de un router Netgear, extrajo el firmware y encontró un módulo del kernel con ftp_decode y sip_decode². La lista de pruebas de Armis incluía OpenWrt y VyOS más una categoría que llamaron simplemente «various consumer grade Linux routers, with likely older kernel versions», y el análisis de H.323 que produjo el hallazgo de «cualquier equipo interno» nació leyendo el código fuente de netfilter y se confirmó después en cortafuegos comerciales de tres fabricantes³.

De ahí salen dos consecuencias prácticas.

El valor por defecto del kernel no te llega. Linux 4.7 apagó la asignación automática en 2016, pero solo si el kernel es lo bastante nuevo y nadie lo ha vuelto a encender. Armis encontró VyOS poniendo nf_conntrack_helper de vuelta a 1 explícitamente, y señaló que un montón de productos basados en Linux lo reactivan «as it is still useful for many users»³. Un kernel de 2014 dentro de un producto de 2026 tiene el comportamiento de 2014, y un kernel actual con el interruptor cambiado tiene el mismo. Ninguno de los dos aparece en una hoja de características.

Quien entiende el modelo de netfilter sabe qué preguntarle a cualquier otra caja. Las tres preguntas de la sección sobre expectativas no son preguntas de Linux. Son las preguntas. Cada fabricante tiene el mismo objeto con otro nombre, la documentación casi nunca da las respuestas, y saber qué hace la implementación de referencia es cómo deduces qué hay que probar.

Haz bien el trabajo de Linux, y luego lee a cualquier otro fabricante contra él.

Los ayudantes de Linux, en condiciones

Empieza por lo que hay cargado de verdad:

lsmod | grep -E 'nf_conntrack|nf_nat'

Los módulos de ayudante son los que llevan nombre de protocolo — nf_conntrack_ftp, _sip, _h323, _irc, _tftp, _pptp, _snmp, _amanda, _sane, _netbios_ns y _talk —, cada uno con su nf_nat_* correspondiente donde se reescriben las direcciones. Después comprueba si la asignación automática está encendida, que es el interruptor que decide si un módulo cargado actúa por su cuenta:

sysctl net.netfilter.nf_conntrack_helper

Cero es lo que quieres, y cero es el valor por defecto desde Linux 4.7⁵. Uno significa que cualquier ayudante cargado está activo sobre cualquier flujo que encaje con su puerto, desde cualquier dirección, que es el comportamiento de 2015 y el que asumen los ataques de este artículo.

Luego mira conntrack -L expect en un cortafuegos en marcha. Con los ayudantes apagados sigue vacío; con ellos encendidos, pon una captura al lado y verás aparecer entradas mientras la gente usa la red. Ese ejercicio merece hacerse una vez en la vida, porque nada demuestra el punto más rápido que ver aparecer y desaparecer ante tus ojos un permiso entrante que tú no escribiste.

Si la asignación automática está apagada y aun así quieres un ayudante concreto sobre un flujo concreto, la vía correcta es una regla explícita, que al menos lo limita a un destino y un puerto:

iptables -t raw -A PREROUTING -p tcp --dport 21 -d 192.0.2.10 -j CT --helper ftp

El equivalente en nftables declara un objeto ct helper y lo ata con ct helper set en la cadena prerouting, la misma disciplina con mejor sintaxis.

Mira lo que es esa regla: una excepción entrante documentada, aprobada y con justificación de negocio, escrita por una persona, dentro del conjunto de reglas, donde un auditor puede leerla. Exactamente lo que la versión automática nunca pudo ser.

Si los quieres fuera en lugar de meramente dormidos — y en un cortafuegos deberías quererlo —, impide que los módulos se carguen siquiera:

for m in ftp sip h323 irc tftp pptp snmp amanda sane netbios_ns talk; do
  echo "install nf_conntrack_$m /bin/false"
done > /etc/modprobe.d/no-conntrack-helpers.conf

install ... /bin/false en lugar de blacklist es deliberado: blacklist solo impide la carga automática por alias, y quien pida el módulo por su nombre lo obtendrá igual. Y si la capa de cortafuegos de tu distribución los carga por ti — firewalld lo hace cuando una zona tiene activados los servicios FTP o TFTP —, esa es la capa que hay que tratar, porque los vuelve a poner muy servicialmente.

Todos los demás logotipos, y cómo apagarlo

Comprueba tu propia versión en lugar de creerte algo de internet, lo mío incluido, porque estos valores por defecto cambian entre versiones y entre modelos de la misma gama.

pfSense y OPNsense son la prueba de que el debate terminó. No hay ningún SIP ALG que apagar, porque nunca hubo uno que encender. Están entre las distribuciones de cortafuegos más desplegadas que existen, mueven telefonía para muchísimas organizaciones, y si de verdad hiciera falta un ayudante para que el VoIP moderno funcione, eso no sería posible. Evidentemente lo es. Con el proxy FTP pasó lo mismo: Netgate lo sacó del sistema base en enero de 2015 y lo degradó a un paquete opcional que la mayoría nunca ha instalado.

El diseño de OpenBSD es lo que todos los demás deberían haber copiado. pf no reescribe carga útil en absoluto en el camino de reenvío. Si quieres FTP asistido ejecutas ftp-proxy, un demonio aparte en espacio de usuario, y escribes una regla divert-to explícita que le envía la conexión de control; el proxy se conecta entonces al servidor en nombre del cliente²⁶. De ahí salen tres propiedades de golpe: está apagado salvo que lo enciendas a propósito, solo ve el tráfico que has nombrado en una regla, y un fallo dentro tumba un proceso de espacio de usuario en lugar del camino de los paquetes. Así se ve la opción de participación voluntaria cuando alguien la diseña en vez de atornillarla después.

OpenWrt no incluye los módulos de ALG, y la asignación automática sigue apagada aunque los instales.

Cisco ASA y FTD llevan motores de inspección en la política global por defecto, y no inspect sip es el propio consejo de Cisco durante un incidente:

policy-map global_policy
 class inspection_default
  no inspect sip
  no inspect h323 h225
  no inspect h323 ras
  no inspect skinny

En FTD es configure inspection sip disable desde la CLI del dispositivo¹⁶. El paso de IPsec es lo que Cisco hizo bien: inspect ipsec-pass-thru no está en la política por defecto, así que salvo que alguien lo añadiera a propósito no hay nada que quitar²⁰.

Cisco IOS y IOS XE también lo traen encendido — «NAT support for SIP is enabled by default on port 5060», en palabras de Cisco⁷, y lo mismo para H.323:

no ip nat service sip tcp port 5060
no ip nat service sip udp port 5060
no ip nat service h225

Juniper SRX activa SIP y H.323 en los modelos de sucursal y no en el equipamiento de gama alta, lo cual ya dice por sí solo qué opinan los ingenieros de Juniper. Mira dónde estás con show security alg status, y luego:

set security alg h323 disable
set security alg sip disable
set security alg ftp disable
set security alg ike-esp-nat disable

FortiGate inspecciona VoIP por defecto a través del perfil de VoIP, con un ayudante de sesión del kernel debajo. La secuencia documentada por Fortinet quita primero el ayudante²⁷:

config system session-helper
 show
 delete <la entrada de SIP>
end
config system settings
 set default-voip-alg-mode kernel-helper-based
end

Lee el número de entrada de tu propia salida de show en lugar de copiar uno, porque cambia entre modelos y versiones. Fortinet advierte de que a menudo hace falta reiniciar.

Check Point es el caso difícil para una auditoría, porque no hay un interruptor único. El ayudante es una propiedad del objeto de servicio usado en la regla, así que el servicio SIP predefinido te trae el manejador de protocolo y todo lo que hace. Evitarlo significa definir un servicio UDP o TCP simple propio en el puerto 5060 con tipo de protocolo «none», activar la coincidencia y poner esa regla por encima de cualquier cosa que siga usando el integrado. Así que «¿está encendido el ALG?» no es una pregunta que pueda responder una página de configuración. Ten cuidado antes de creerte la palabra de alguien de que está apagado.

Palo Alto te da un interruptor por aplicación, y su propia documentación dice que el SIP ALG «creates dynamic NAT pinholes»⁸. Objects, Applications, busca sip, edita la opción de ALG, marca Disable ALG, commit.

MikroTik trae diez ayudantes bajo /ip firewall service-port — SIP, H.323, FTP, IRC, TFTP, PPTP, RTSP y más —, cada uno documentado en una línea, sin ninguna advertencia de seguridad en la página. Enuméralos primero, y luego apaga lo que encuentres:

/ip firewall service-port print
/ip firewall service-port set [find name=sip] disabled=yes
/ip firewall service-port set [find name=h323] disabled=yes
/ip firewall service-port set [find name=ftp] disabled=yes

Routers de consumo y de operador. Busca «SIP ALG», «SIP helper», «VoIP passthrough» o «application layer gateway», normalmente bajo una página de NAT avanzado. En muchos de ellos, y desde luego en el equipamiento del operador, no hay ningún ajuste, lo cual te dice si esa caja pinta algo en una red de la que respondes tú.

Sea cual sea la plataforma, termina igual: demuéstralo. Pon una captura en la interfaz externa, envía desde fuera una línea PORT o REGISTER fabricada al puerto correspondiente, y comprueba que no se abre nada. Un ajuste que no has probado es una creencia.

Casi todo lo que se rompe ya estaba muerto

Ser honrado sobre el coste es toda la base para pedirle esto a alguien, así que ahí va. Apagar el ayudante de SIP en una red con teléfonos mal configurados puede romper llamadas, normalmente audio en un solo sentido o registros que se caen. Apagar el ayudante de FTP rompe el FTP activo saliente. Apagar el ayudante de H.323 rompe H.323, si aún lo tienes. Eso es real, y deberías esperar al menos una de esas cosas si haces esto en un solo cambio sobre una red que nadie ha mirado en años.

Ahora vuelve a leer la lista y fíjate en que casi todos los protocolos a los que sirve un ayudante son protocolos que el resto del sector enterró hace mucho. H.323 perdió contra SIP hace veinte años. PPTP es indefendible desde 1998, y ese argumento lo desarrollé por extenso en IPsec fue una buena idea. Las transferencias directas de IRC pertenecen a una década que nadie recuerda con nostalgia. El servicio de nombres de NetBIOS, las versiones de SNMP con cadena de comunidad, el protocolo de descubrimiento de escáneres y el viejo protocolo de copias de seguridad son reliquias para redes locales que nunca debieron cruzar un perímetro. El FTP en claro ha desaparecido incluso de los navegadores: Firefox lo apagó en la versión 88 y lo eliminó en la 90 en julio de 2021, y Chrome quitó el código en octubre siguiente en la versión 95, ambos alegando que el uso era insignificante y la seguridad no merecía el mantenimiento²⁸.

Así que «no podemos apagar el ayudante, se rompe algo» es casi siempre un argumento para mantener un protocolo muerto con respiración asistida, con el fin de justificar una función que abre puertos a desconocidos. Apagarlo no rompe tu red. Expone lo único que debería haberse retirado hace años, y esa es información que querías tener de todas formas.

SIP es la excepción real, y la única. Todo lo demás de esa lista es una discusión que te alegrarás de perder, y nada de ello es irresoluble, porque cada protocolo implicado resolvió su propio problema de traducción hace años, dentro del protocolo, que es donde corresponde.

Qué hacer en su lugar

FTP. Modo pasivo, en la especificación desde 1985 y el valor por defecto de cualquier cliente desde hace veinte años: ambas conexiones salen hacia fuera y no queda nada que hacer para un ayudante. Y si en 2026 mueves ficheros entre organizaciones, FTP no es el protocolo para eso: SFTP y FTPS van cifrados, y ninguno de los dos toca un ayudante.

SIP y todo lo demás en tiempo real. El extremo le pregunta a un servidor de internet cómo se ven su dirección y su puerto públicos desde fuera, ofrece todos los caminos que tiene, y los dos extremos prueban los caminos entre ellos y se quedan con uno que funcione, usando un relay donde no exista camino directo. Eso es STUN, TURN e ICE, y es lo que hace cada navegador del mundo en cada videollamada, a través de cualquier tipo de traductor, sin un solo ALG en el camino. Si tu centralita no puede hacer eso en 2026, el problema es la centralita.

IPsec. Travesía de NAT, es decir RFC 3947 y RFC 3948: los dos extremos detectan el traductor durante el intercambio de claves y envuelven ESP en UDP 4500 el resto de la sesión²¹, sin puerta en ninguna caja intermedia.

H.323. Retíralo. SIP ganó esa discusión hacia 2005, así que no hay migración que planificar, solo una eliminación. Las transferencias directas, TFTP, SNMP, NetBIOS, el descubrimiento de escáneres y el protocolo de copias siguen el mismo camino: ninguno tiene por qué cruzar un perímetro.

IPv6. Ahí no existe nada de esto, porque no hay traducción y por tanto no hay nada que un ayudante pueda reescribir. Un equipo tiene su propia dirección, la dirección de la carga útil es cierta, y un cortafuegos con estado permite lo que tú dijiste y nada más. Todos los problemas de este artículo descienden de la traducción de direcciones, y la traducción de direcciones desciende de no desplegar IPv6, un argumento que he desarrollado en otra parte y que no repito aquí.

Ahora la parte en la que no voy a ser diplomático.

Si alguien te dice que enciendas estas cosas — un fabricante, un instalador de telefonía, un servicio gestionado, un integrador de un contrato marco —, no es ingeniero de redes ni especialista en seguridad. Puede que sea muy bueno en lo que hace de verdad, y esto no será eso. La respuesta correcta a una centralita que necesita que un cortafuegos le reescriba la señalización es arreglar la centralita, y quien en su lugar te diga que abras tu perímetro a un analizador que busca texto te está diciendo que o no sabe qué es una expectativa o le da igual. Aquí no somos aficionados. Desde 2007 hay documentos de vía de estándares que dicen cómo debe hacerse esto, y «enciende el ayudante de SIP y ya está» es el sonido de alguien agarrándose a lo que cierra el ticket hoy.

Pregúntale, en la sala, contra qué se compara el comodín de dirección de origen de la expectativa. Si la pregunta le sorprende, ya tienes tu respuesta, y nunca fue sobre el protocolo.

Si aún los ejecutas, ¿puedes llamarte profesional?

Es una pregunta seria y merece una respuesta seria, así que aquí van tres, porque hay tres casos. Depende de si lo sabes, y saberlo no es algo que te ocurra sin más. Asegurarte de saberlo es el trabajo.

Si hay un ayudante de SIP, H.323 o FTP encendido en un perímetro del que respondes tú, y no puedes decir sin buscarlo qué es una expectativa, cuáles de sus campos son comodines, quién aporta los valores y qué afirma tu compromiso de certificación sobre las reglas entrantes, entonces no. En esto no. No has elegido una configuración, has heredado un valor por defecto y nunca lo has leído. La carencia no es el hueco: todo el mundo tiene huecos, y yo también tenía este. Es construir un perímetro sobre un hueco que nunca fuiste a cerrar, y después firmar algo que dice que el perímetro está bien.

Si sabes exactamente qué hace, y está encendido porque un regulador nombra el protocolo, porque el equipamiento de un socio no termina otra cosa, o porque la centralita se cambia en marzo y esto tiene que aguantar hasta entonces, entonces sí, claro, y estás haciendo bien el trabajo. Esas son restricciones reales y yo he trabajado con peores. Lo que lo hace profesional en vez de negligente es haber escrito qué ayudante, en qué interfaz, para qué flujo, por qué, y en qué fecha se va. Exactamente el papeleo que el requisito de cortafuegos ya pedía.

El caso indefendible es el del medio. Saber lo suficiente como para estar incómodo, y dejarlo funcionando porque nadie te obligó nunca a justificarlo. Eso no es ingeniería. Es costumbre con un número de cambio pegado, y así es como una función que una Best Current Practice te dijo que apagaras en enero de 2007 sigue encendida en 2026.

Esto pesa más cuando le pagas a alguien por su criterio, porque el criterio no se puede inspeccionar en la entrega. Así que inspecciónalo antes. Pregunta qué hace su construcción estándar con los ayudantes de protocolo y por qué, pregunta qué pasa si alguien de la red de invitados abre un enlace, y pregunta qué dispositivos internos serían alcanzables con el ayudante de H.323 encendido. Fíjate en si dicen «solo la máquina que hizo clic», porque eso es falso, y es la respuesta falsa que da alguien que suena competente. Sabrás en dos minutos si te están contando algo o recitándolo, y dos minutos son una prueba mucho más barata que un incidente.

Y si la respuesta llega como un encogimiento de hombros y firmas igual, eso también es una decisión. Solo que ha dejado de ser suya y ha pasado a ser tuya.

Nadie tuvo que justificarlo nunca

Quiero ser justo con la gente que construyó estas cosas, porque se lo merece.

En 1994 el ayudante era una respuesta razonable a un problema real. Las direcciones se agotaban, NAT era el arreglo pragmático, un puñado de protocolos importantes no sobrevivía a él, y la elección era arreglar todos los clientes FTP del mundo o enseñar a la caja a leer. Enseñaron a la caja a leer, publicaron los valores por defecto más seguros que se les ocurrieron, y escribieron en el código fuente avisos sobre a qué se le podía inducir. Esos avisos siguen ahí. Uno lo he citado.

Lo que salió mal después no es un fallo técnico. Es que nada en este sector obligó nunca a nadie a volver a mirarlo. El IETF dijo que los apagaran y no tenía poder para que nadie lo hiciera. El kernel cambió su valor por defecto y no podía alcanzar los dispositivos ya entregados. Los investigadores lo demostraron cuatro veces en dieciséis años, y cada vez el arreglo aterrizó en cualquier sitio menos en el cortafuegos.

Mientras tanto, el valor por defecto siguió encendido. No porque nadie lo defendiera. Porque un valor por defecto que nadie discute vive indefinidamente, y porque en ningún sitio hay un departamento cuyo trabajo sea terminar cosas.

Ese es el patrón, y es más grande que una función de cortafuegos. Esta profesión es excelente manteniendo y pésima parando. El mantenimiento tiene presupuesto, personal, facturación y seguridad, mientras que retirar algo requiere una persona que ponga su nombre en un cambio sin beneficio si sale bien y con su nombre en todas partes si sale mal. Así que la cosa se queda, y se queda, y un día alguien descubre que abre puertos hacia tu impresora.

La señal, para mí, es esa expresión de la propia documentación de Cisco: el ALG crea una puerta NAT. No un filtro. No una comprobación. Una puerta, en el muro que pagaste, abierta por cualquiera que consiga colar por ella un paquete con las palabras correctas al principio, y la respuesta arraigada del sector es pedirle a los transeúntes que por favor no prueben el picaporte.

La tuya puedes cerrarla esta tarde, y merece la pena terminar ahí. No con los ataques; los ataques son solo lo que ocurre cuando nadie lo hace. Ve a ver qué permite entrar tu perímetro sin que tú lo hayas escrito nunca, decide si era tu intención, y quita lo que no lo era, con una fecha al lado de lo que te quedes.

Un perímetro nunca fue otra cosa: una lista de cosas que alguien eligió permitir y podía justificar. Lo que esté ahí sin que nadie lo eligiera no es seguridad. Es mobiliario.