¿Es seguro deshabilitar el seguimiento de la conexión en iptables?

Question

¿Es seguro deshabilitar el seguimiento de la conexión en iptables?

#1 de Spacy (13 votos)

12

Mientras leía sobre el objetivo NOTRACK de la tabla raw en iptables, encontré un artículo que sugiere que para cierto tráfico podría (o incluso debería) deshabilitar el seguimiento de la conexión. Los dos ejemplos fueron: (1) todo tipo de paquetes enrutados y (2) si tiene un servidor web u otros servicios que consumen recursos, también debe deshabilitar el seguimiento de la conexión para dicho servicio. No tengo un servidor web, pero sí tengo algunos clientes p2p. Las siguientes son reglas estándar para el seguimiento de la conexión:

iptables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -t filter -A INPUT -p udp -m conntrack --ctstate NEW -j udp
iptables -t filter -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp

y en las cadenas udp y tcp abro el puerto para un cliente de torrent usando:

iptables -t filter -A udp -p udp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT
iptables -t filter -A tcp -p tcp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT

Cuando verifico las entradas de conntrack:

# cat /proc/net/nf_conntrack | wc -l
3569

Ahora, la opción sería establecer NOTRACK en la tabla raw para este tipo de tráfico, por ejemplo:

iptables -t raw -A notrack_in -p udp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p udp --dport 33333 -j ACCEPT
iptables -t raw -A notrack_in -p tcp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p tcp --dport 33333 -j ACCEPT

y también necesita dos reglas en la tabla de filtro:

iptables -t filter -A INPUT -p udp --dport 33333 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 33333 -j ACCEPT

Después de esta operación, el número de entradas en /proc/net/nf_conntrack se redujo a 150-200, y no hay línea con el puerto 33333.

Mi pregunta es la siguiente: ¿es seguro deshabilitar el seguimiento de la conexión? ¿Sería necesario agregar reglas a iptables? ¿Cuáles son los pros y los contras de esta solución?

firewalls linux iptables

pregunta Mikhail Morfikov 13.07.2014 - 10:41

fuente

1 respuesta

Lea otras preguntas en las etiquetas firewalls linux iptables

detección de caja de arena de malware ¿El tamaño de la clave de encriptación AES de WPA2 Enterprise?

score 13 · Answer 1

La respuesta corta

Por lo general, solo necesitará el seguimiento de la conexión para las conexiones salientes. Si algún dispositivo local realiza una conexión a Internet, el cortafuegos registra que esta IP y este puerto específicos intentaron establecer una conexión con la otra IP y otro puerto.

Por lo tanto, cuando llega la respuesta de Internet, el firewall debe dejarlo pasar, porque ha visto un paquete saliente anteriormente. Si no hubiera un seguimiento de la conexión, tendría que establecer reglas explícitas sobre desde dónde o hacia dónde puede viajar un paquete (por ejemplo, permitir todos los paquetes desde el puerto 80 de google.com). Es fácil ver que esto haría que las reglas de firewall sean bastante complicadas.

La respuesta larga

Solo hay diferencias sutiles entre las dos soluciones si se usan para conexiones entrantes. Una diferencia es en qué sistema se produce la carga de CPU de la comprobación de paquetes. Si tiene una computadora / enrutador / firewall dedicado (llamado firewall desde aquí) haciendo esto, con el seguimiento de la conexión habilitado, este dispositivo verificará al menos la plausibilidad de un paquete. Esto liberará al servidor de aplicaciones (el servidor que recibe los paquetes) de hacerlo.

La plausibilidad se refiere a que el paquete proviene del host esperado y del puerto esperado en el caso de UDP, y adicionalmente en el número de secuencia en el caso de TCP.

Por lo general, la validación solo puede ocurrir dentro de la capa de la aplicación, ya que la validez solo se puede asegurar en función del protocolo en la propia aplicación.

Hay tres consecuencias de estas suposiciones:

La CPU y la carga de la red se mueven hacia el "borde" de la red en el caso del seguimiento de estado. Eso significa que (por lo general) el primer dispositivo en su red realizará alguna inspección básica del paquete, antes de reenviarlo a la red local, manteniendo así su red interna limpia y la carga en el firewall.
El servidor de aplicaciones solo tendrá que preocuparse de si el paquete es válido, es decir, si los datos dentro del paquete cumplen con el protocolo esperado.
Esto podría abrir la posibilidad de superar una conexión UDP, dependiendo del protocolo. Si la aplicación no tiene (o no es confiable) la forma de autenticar al remitente de un paquete, aceptaría la carga útil correcta de cualquier dirección IP. Por ejemplo, en una transmisión de datos, sería posible enviar basura al receptor, si el paquete UDP pasa la validación.

Sin embargo, la práctica común (a menos que se trate de entornos de alta seguridad) es utilizar el seguimiento de la conexión (general) solo para las conexiones salientes, para no tener que permitir explícitamente que cada servidor de Internet responda a una solicitud de la red local. Para el caso de las conexiones entrantes, por lo general solo se permite que se pueda acceder al puerto (definido) (-A ENTRADA -p tcp --dport 80 -j ACEPTAR). Esto se aplicaría a las nuevas conexiones, pero también se aplicaría a las conexiones existentes, evitando la sobrecarga, para realizar un seguimiento de la conexión. De manera similar, solo reenviaría los paquetes a un puerto de destino específico a un servidor de aplicaciones dentro de su red local.

seguimiento de conexión específico de la aplicación

Hay un caso que aún no mencioné y es el seguimiento de conexión específico de la aplicación. Para algunos protocolos (ftp, irc, tftp, amanda, sip y posiblemente otros, consulte enlace por ejemplo) puede haber módulos iptables especiales para permitir el seguimiento avanzado de la conexión. Por ejemplo, en FTP, abriría una conexión del cliente al servidor en el puerto 21, llamada conexión de control, que debería abrirse en el firewall por medios normales. Dentro de este canal, el cliente y el servidor definen una segunda conexión a la que se enviarán los datos sin procesar del archivo. Por lo general, esta conexión se establece desde el servidor al cliente (en el modo ACTIVO). Este puerto local y remoto es aparentemente aleatorio, por lo que no se pueden definir en un archivo de configuración de firewall estático. Si hubiera un servidor de seguridad con iptables en la red del cliente, denegaría esta conexión, porque no existe una asociación anterior. Con el seguimiento de la conexión específica de la aplicación, el módulo buscaría "dentro" del contenido del paquete para ver si se realizó dicho acuerdo y si el firewall permitiría una nueva conexión entrante en el puerto acordado, incluso si no había una conexión antes.