¿Aceptar "RELACIONADO, ESTABLECIDO" para todas las fuentes en iptables se considera "demasiado abierto"?

9

A menudo he visto la regla -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTaplicada. Si bien no soy un experto, esa línea en particular me preocupa. Es bastante obvio que la regla permite todo el tráfico con la única excepción de que la conexión debe haberse establecido o relacionado con una conexión establecida.

Guión

Permitiré conexiones al puerto SSH predeterminado 22desde la LAN del servidor en la subred 192.168.0.0/16o lo que sea.
SuperInsecureApp®expone algo en el puerto 1337, que agrego a mi INPUTcadena.
He agregado la conntrackregla para aceptar ESTABLISHEDy RELATEDde todas las fuentes
La política de la cadena es DROP

Básicamente, esa configuración debe permitir conexiones SSH solo desde la LAN, al tiempo que permite el tráfico entrante en el puerto 1337 del mundo.

Aquí es donde florece mi confusión. ¿Expondría conntrackde alguna manera una falla de seguridad que le permitiría a uno obtener una conexión establecida en 1337 (ya que está abierto en todo el mundo), y luego utilizar esa conexión para obtener acceso al puerto SSH (o cualquier otro puerto para el caso)?

security iptables ip tcp

— Dencker
fuente

8

No consideraría el tráfico ESTABLECIDO y RELACIONADO demasiado abierto. Es posible que pueda omitir RELACIONADO, pero definitivamente debe permitir ESTABLECIDO. Ambas categorías de tráfico utilizan estados conntrack.

Las conexiones ESTABLECIDAS ya han sido validadas por otra regla. Esto hace que sea mucho más simple implementar reglas unidireccionales. Esto solo le permite continuar las transacciones en el mismo puerto.

Las conexiones RELACIONADAS también son validadas por otra regla. No se aplican a muchos protocolos. Nuevamente, hacen que sea mucho más sencillo configurar reglas. También aseguran una secuencia adecuada de las conexiones donde se aplican. Esto realmente hace que sus reglas sean más seguras. Si bien esto puede permitir la conexión en un puerto diferente, ese puerto solo debe ser parte de un proceso relacionado, como una conexión de datos FTP. Los puertos permitidos están controlados por módulos conntrack específicos del protocolo.

Al permitir conexiones ESTABLECIDAS y RELACIONADAS, puede concentrarse en las nuevas conexiones que desea que acepte el firewall. También evita reglas rotas destinadas a permitir el tráfico de retorno, pero que permiten nuevas conexiones.

Dado que ha clasificado el programa en el puerto 1337 como inseguro, debe iniciarse utilizando una identificación de usuario no root dedicada. Esto limitará el daño que alguien puede hacer si logran descifrar la aplicación y obtener un acceso mejorado.

Es muy poco probable que se pueda usar una conexión en el puerto 1337 para acceder al puerto 22 de forma remota, pero es posible que se pueda usar una conexión al puerto 1337 para proxy una conexión al puerto 22.

Es posible que desee asegurarse de que SSH esté asegurado en profundidad:

Use hosts.allow para limitar el acceso además de las restricciones del firewall.
Evite el acceso a la raíz, o al menos requiera el uso de claves y limite su acceso en el archivo autorizado_claves.
Auditar errores de inicio de sesión. Un escáner de registro puede enviarle informes periódicos de actividad inusual.
Considere usar una herramienta como fail2ban para bloquear automáticamente el acceso en fallas de acceso repetidas.

— BillThor
fuente

Aunque este fue un ejemplo arbitrario, lo primero que hago en los nuevos servidores siempre es deshabilitar el acceso raíz y la autenticación de texto sin formato en sshd, es un buen consejo. Además, fail2ban ya está instalado en la configuración de la vida real de la que se inspiró el ejemplo. "Las conexiones ESTABLECIDAS ya han sido validadas por otra regla" era exactamente lo que no estaba seguro y responde perfectamente a mi pregunta. Gracias por tu respuesta muy clara!

— Dencker

Pregunta secundaria: desde una perspectiva de rendimiento, ¿cambia algo si la conntrackregla está al principio o al final de la cadena? Por lo que entiendo iptables, ¿tendría que procesar todas las reglas en las conexiones establecidas si fuera al final, y solo esa regla si se colocara al principio?

— Dencker

@Dencker Desea primero la regla ESTABLECIDA Y RELACIONADA. Aceptará con mucho la mayor parte del tráfico. Más allá de eso, es posible que desee tener las reglas que acepten la mayor parte del tráfico, aunque es mejor considerar la legibilidad. Mis reglas son agrupadas, sensibles a la latencia, alto tráfico (agrupadas por tipo), otras. Iptables tiene contadores que le permiten ver cuánto tráfico procesa cada regla. Uso Shorewall, que agrega algunos valores predeterminados útiles y tiene un archivo de reglas fácil de leer para construir mis firewalls.

— BillThor

2

ESTABLECIDO y RELACIONADO son características del filtrado de paquetes "con estado", donde el filtrado no solo depende de un conjunto de reglas estáticas sino también del contexto, dentro del cual se consideran los paquetes. Necesita ESTABLECIDO para permitir que las conexiones funcionen, y necesita RELACIONADO para los mensajes ICMP relevantes. El filtrado con estado permite filtrar con mayor precisión en comparación con las reglas estáticas "sin estado".

Veamos ESTABLECIDO primero. Por ejemplo, considere TCP en el puerto 22. El iniciador (cliente) envía un SYNa serverIPaddr:22. El servidor vuelve SYN+ACKal cliente. Ahora es el turno del cliente para enviar un ACK. ¿Cómo debería ser la regla de filtrado en el servidor, de modo que solo ACKse acepte la "coincidencia" ? Una regla general sin estado parecería

-A INPUT --proto tcp --port 22 -j ACCEPT

que es más liberal que la regla estatal correspondiente. La regla sin estado permite segmentos TCP arbitrarios, por ejemplo, ACKo FINsin haber establecido una conexión primero. Los escáneres de puertos pueden explotar este tipo de comportamiento para las huellas digitales del sistema operativo.

Ahora echemos un vistazo a RELACIONADO. Esto se usa para mensajes ICMP, principalmente mensajes de error. Por ejemplo, si se descarta un paquete del servidor al cliente, se envía un mensaje de error al servidor. Este mensaje de error está "relacionado" con la conexión establecida previamente. Sin la regla RELACIONADA, uno debería permitir los mensajes de error entrantes en general (sin contexto) o, como es costumbre en muchos sitios, abandonar ICMP por completo y esperar tiempos de espera en la capa de transporte. (Tenga en cuenta que esta es una mala idea para IPv6; ICMPv6 juega un papel más importante para IPv6 que ICMP para el legado de IP).

— contramodo
fuente