Desactivación de Helpers de conntrack: Impacto y configuración

¿Qué son los Helpers de conntrack?

Los helpers de conntrack son módulos del kernel de Linux que facilitan la gestión de conexiones que utilizan puertos dinámicos, como FTP, SIP, PPTP, entre otros. Estos módulos extienden el sistema de seguimiento de conexiones, conocido como conntrack, permitiendo que ciertos protocolos funcionen correctamente, incluso cuando el filtrado de paquetes convencional no sería suficiente.

El sistema conntrack permite al kernel de Linux realizar un seguimiento de las conexiones activas en la red. Cada vez que un paquete entra o sale del sistema, conntrack intenta asociarlo con una conexión existente o, en caso contrario, crea un nuevo registro. Esto es fundamental para firewalls modernos basados en nftables o iptables, ya que les permite tomar decisiones sobre si permitir o bloquear paquetes en función del estado de la conexión.

Riesgos y desactivación de los Helpers de conntrack

Sin embargo, a pesar de su utilidad, los helpers de conntrack pueden representar un riesgo de seguridad. Pueden ser explotados para abrir puertos aleatorios sin el conocimiento del administrador del sistema, permitiendo tráfico no autorizado, disfrazando conexiones maliciosas como legítimas o incluso evadiendo reglas del firewall para habilitar conexiones entrantes que, en condiciones normales, serían bloqueadas.

Debido a estos riesgos, las versiones recientes del kernel de Linux han deshabilitado por defecto el autoloading de helpers, y a partir de la serie 6.x, esta funcionalidad ha sido eliminada por completo.

Este cambio impacta directamente en los servidores, especialmente en aquellos servicios que dependían de estos helpers, ya que pueden dejar de funcionar tras la actualización del kernel. No basta con simplemente abrir los puertos manualmente en el firewall, ya que muchos de estos protocolos requieren que el software utilice un rango específico de puertos. Para seguir utilizando estos servicios, será necesario configurar manualmente el rango de puertos en el software correspondiente y permitir dicho rango en el firewall para garantizar la conectividad adecuada.

A continuación, explicamos qué protocolos y servicios se ven afectados por este cambio y qué ajustes debes realizar tanto en el servidor como en el perfil del firewall.

Protocolos y servicios afectados por la desactivación 

Los siguientes protocolos y servicios dependen de los helpers de conntrack y, en su ausencia, requerirán una configuración manual.

• FTP (TCP/21): En modo pasivo, el servidor asignará un puerto aleatorio para la transferencia de datos y el cliente intentará conectarse, pero sin conntrack, el firewall bloqueará la conexión si esos puertos no están permitidos.
  
  • Servicios afectados: vsftpd, ProFTPD, Pure-FTPd, FileZilla Server, Microsoft IIS FTP Server, Serv-U FTP Server.
• TFTP (UDP/69): TFTP usa un solo puerto (69) para inicializar transferencias, pero los datos son enviados a través de puertos dinámicos elegidos por el servidor. Sin conntrack, estas respuestas pueden ser bloqueadas.
  
  • Servicios afectados: tftpd-hpa, atftpd, dnsmasq (cuando se usa como servidor TFTP), OpenTFTP.
• SIP (UDP/TCP 5060/5061): SIP gestiona la señalización de llamadas, pero los flujos de audio y video (RTP) se negocian en puertos dinámicos. Sin conntrack, estos paquetes pueden ser bloqueados, causando llamadas sin audio o fallos en la conexión.
  
  • Servicios afectados: Asterisk, FreePBX, Kamailio, OpenSIPS, Cisco CallManager, 3CX, Linphone, Ekiga, Zoiper, Grandstream PBX.
• H.323 (TCP/1720 y dinámicos): Similar a SIP, este protocolo de videoconferencia usa el puerto 1720 para la señalización, pero requiere puertos dinámicos para el tráfico de medios (audio/video). Sin conntrack, estos pueden ser bloqueados.
  
  • Servicios afectados: Polycom, Cisco Unified Communications, Avaya, Ekiga, Linphone, Microsoft Skype for Business, Google Meet (cuando usa H.323 gateways).
• PPTP (TCP/1723 y GRE protocolo 47): PPTP usa TCP/1723 para la autenticación y control de la conexión, pero el tráfico de datos es transportado mediante GRE (protocolo 47). Sin conntrack, los paquetes GRE pueden ser bloqueados, impidiendo la conexión VPN.
  
  • Servicios afectados: Microsoft Windows VPN Server, MikroTik PPTP Server, SoftEther VPN, Cisco PPTP, OpenVPN (cuando se usa en modo PPTP).
• IRC - DCC (UDP/1024-65535):Las conexiones Direct Client-to-Client (DCC) en IRC permiten transferencias de archivos y conexiones directas entre usuarios. Sin conntrack, los puertos aleatorios usados en estas conexiones pueden ser bloqueados.
  
  • Servicios afectados: UnrealIRCd, InspIRCd, ircd-hybrid, WeeChat, HexChat, mIRC, Kiwi IRC.

Configuración manual

A continuación, se presentan los puertos esenciales que deben abrirse manualmente en el perfil del firewall para garantizar el funcionamiento de cada servicio:

Alternativas y buenas prácticas

Para garantizar el funcionamiento de ciertos protocolos sin depender de los helpers de conntrack, es necesario configurar manualmente los rangos de puertos y realizar ajustes en los firewalls. En el caso de FTP, se recomienda el uso del modo pasivo con un rango de puertos fijos, aunque alternativas como SFTP o WebDAV sobre HTTPS ofrecen mayor seguridad y facilidad de gestión. TFTP, al utilizar puertos dinámicos, requiere una configuración similar, pero es preferible optar por métodos más seguros como SFTP o HTTPS.

Los protocolos de comunicación en tiempo real, como SIP y H.323, necesitan la definición de puertos fijos para la transmisión de medios y el uso de servidores STUN/TURN para evitar bloqueos en redes con NAT. A pesar de estas configuraciones, soluciones como WebRTC, resultan más prácticas y eliminan la necesidad de configuraciones complejas. En el caso de PPTP, es fundamental permitir el tráfico GRE en el firewall, aunque este protocolo ha quedado obsoleto y se recomienda sustituirlo por opciones más seguras como WireGuard o OpenVPN.

Para las conexiones DCC en IRC, es necesario establecer un rango de puertos fijos y abrirlos en el firewall, además de utilizar bouncers como ZNC para facilitar la conexión. Alternativas como XMPP con Jingle File Transfer o Matrix con puente a IRC pueden reemplazar DCC sin las complicaciones derivadas de los puertos dinámicos.

En general, la mejor estrategia para operar sin los helpers de conntrack es establecer configuraciones de red más predecibles y, siempre que sea posible, optar por tecnologías modernas que reduzcan la dependencia de configuraciones manuales en los firewalls.

Conclusión

La desactivación de los helpers de conntrack mejora la seguridad al evitar el procesamiento innecesario de paquetes y reducir el riesgo de ataques. Sin embargo, esto requiere ajustes manuales para garantizar el funcionamiento de ciertos servicios.

Siguiendo las configuraciones recomendadas en nuestra interfaz web, es posible mantener un firewall más seguro sin comprometer la compatibilidad con servicios esenciales.

Esperamos que este artículo te haya sido útil. Si tienes alguna duda sobre este u otro tema relacionado con tus servidores en Clouding, no dudes en escribirnos a soporte@clouding.io. ¡Estamos aquí para ayudarte! 😉