netfilter / iptables: ¿por qué no usar la tabla sin formato?

En Linux, usualmente usamos la tabla "filtro" para hacer un filtrado común:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

De acuerdo con el diagrama de flujo de netfilter a continuación, los paquetes primero viajan a través de la tabla "sin procesar":

Entonces podemos escribir:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

los paquetes se manejan antes, sin la necesidad de ir a través de conntrack + mangle + nat + routing. Por lo tanto, se utiliza un poco menos de CPU / memoria (y, a su vez, se compensa ligeramente por el hecho de que el módulo iptable_raw debe cargarse)
solo una regla en caso de que la caja también sea un enrutador (obviamente no estará bien para todas las reglas) porque no es necesario agregar la misma regla para filtro / reenvío

Hice solo pruebas rápidas, y esto funciona perfectamente bien.
Las documentaciones que encontré siempre describen la tabla en bruto que se utilizará en casos estrictos. Pero ninguno da ni la más mínima justificación.

Pregunta: ¿hay alguna razón para no usar la tabla sin procesar, aparte de las dogmáticas?

linux iptables

— Gregory MOUSSAT
fuente

Si simplemente desea eliminar todo el tráfico de ciertas direcciones IP, entonces la tabla sin procesar está bien. Sin embargo, el firewall suele ser un poco más detallado que eso, por lo que terminaría con algunas reglas en bruto y otras en filtro. Esto hace que el mantenimiento sea un dolor de cabeza y una simplificación que vale un par de ciclos de CPU.

— wurtel

Si es solo un problema de dolor de cabeza, creo que deberíamos encontrar algunos ejemplos que hablen sobre la tabla sin procesar. Como este no es el caso, la teoría del dolor de cabeza probablemente no sea el factor principal.

— Gregory MOUSSAT

El autor de ipset recomienda usar la tabla sin procesar para las reglas de ipset iptables ipset.netfilter.org/tips.html

— Stuart Cardall

Desde man iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

Análisis :

Entonces, la tabla RAW está antes de conntrack y fue diseñada con el objetivo de usarse para establecer la marca NOTRACK en paquetes que no desea rastrear en netfilter.

Los objetivos -j no se limitan solo a NOTRACK, por lo que sí, puede filtrar paquetes en la tabla sin formato con los beneficios de un menor consumo de CPU / memoria.

Con mayor frecuencia, los servidores no necesitan realizar un seguimiento de todas las conexiones. Solo necesita seguimiento si necesita filtrar paquetes en iptables basados en conexiones establecidas previamente. En los servidores que solo tienen un propósito simple, como solo con el puerto 80 (y tal vez 21) abierto, no lo requieren. En esos casos, puede deshabilitar el seguimiento de la conexión.

Sin embargo, si está intentando ejecutar un enrutador NAT, las cosas se complican un poco. Para NAT algo, debe realizar un seguimiento de esas conexiones para que pueda entregar paquetes desde la red externa a la red interna.

Si se establece una conexión completa con NOTRACK, tampoco podrá realizar un seguimiento de las conexiones relacionadas, conntrack y los ayudantes nat simplemente no funcionarán para conexiones no rastreadas, ni lo harán los errores ICMP relacionados. Deberá abrirlos manualmente en otras palabras. Cuando se trata de protocolos complejos como FTP y SCTP y otros, esto puede ser muy difícil de administrar.

Casos de uso :

Un ejemplo sería si tiene un enrutador con mucho tráfico en el que desea proteger el tráfico entrante y saliente, pero no el tráfico enrutado. Luego, puede establecer la marca NOTRACK para ignorar el tráfico reenviado para ahorrar potencia de procesamiento.

Otro ejemplo cuando se puede utilizar NOTRACK es que si tiene un servidor web con mucho tráfico, puede configurar una regla que active el seguimiento para el puerto 80 en todas las direcciones IP de propiedad local, o las que realmente están sirviendo el tráfico web. Luego, podría disfrutar del seguimiento con estado en todos los demás servicios, excepto el tráfico web que podría ahorrar algo de poder de procesamiento en un sistema ya sobrecargado.

Ejemplo -> ejecutando-un-semi-stateless-linux-router-for-private-network

Conclusión : no hay una razón sólida para no usar la tabla sin formato, pero hay algunas razones para tener cuidado al usar el objetivo NOTRACK en la tabla sin formato.

— Facundo Victor
fuente