B.2. Paquetes cuyo estado es NEW pero cuyo bit SYN no se ha establecido

Existe cierta característica de iptables que no está muy bien documentada y puede ser obviada por mucha gente (sí, incluso yo). Si empleas el estado NEW de los paquetes, aquellos con el bit SYN sin establecer pasarán por el cortafuegos. Se ha programado así porque en determinadas ocasiones se necesita considerar que un paquete puede ser parte de una conexión ya establecida (ESTABLISHED) en, por ejemplo, otro cortafuegos. Con éllo es posible tener dos o más cortafuegos y poder "caerse" ("colgarse") uno de ellos sin pérdida de datos: el trabajo de filtrado de la subred lo puede asumir automáticamente el cortafuegos secundario. Sin embargo ésto conduce al hecho de que el estado NEW permitirá casi cualquier tipo de conexión TCP, independientemente de si se trata de un "saludo" inicial (un establecimiento de conexión) o no. Para evitar este problema se añaden las siguientes reglas a las cadenas INPUT, OUTPUT y FORWARD de los cortafuegos:

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG \ --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
    

Las reglas anteriores evitarán este problema. Nos encontramos ante un comportamiento mal documentado del proyecto Netfilter/iptables que debería ser claramente expuesto para el conocimiento general. Para ser más claro, que quede como un enorme aviso acerca de este tipo de comportamiento en tu cortafuegos.

Ten en cuenta que existen algunas incompatibilidades entre las reglas anteriores y las malas implementaciones (adaptaciones) del TCP/IP realizadas por Microsoft. Las reglas anteriores conducirán a ciertas condiciones en que los paquetes generados por los productos de Microsoft serán etiquetados con el estado NEW y por tanto registrados y desechados. De todas formas, por lo que sé no derivarán en pérdidas de conexiones. El problema ocurre cuando una conexión se cierra, se envía el paquete FIN/ACK final, la máquina de estados (state machine) de Netfilter cierra la conexión y a partir de entonces ya no existe en la tabla del seguimiento de conexiones (conntrack table). Llegados a este punto, la defectuosa implementación de Microsoft envía otro paquete que es considerado NEW, pero carece del bit SYN y por ello es interceptado por las reglas anteriores. O sea, no te preocupes demasiado por estas reglas, aunque si lo haces incluye la opción --log-headers a la regla y registra también las cabeceras, de forma que podrás analizar mejor cómo es el paquete.

Aún existe otro problema conocido con estas reglas: cuando alguien está conectado al cortafuegos (por ejemplo desde la red local) y has configurado el script (guión, conjunto de comandos de shell) para que se active al producirse una conexión PPP. En este caso, cuando estableces una conexión PPP, aquel que estuviera previamente conectado a través de la red local será poco menos que eliminado. Aunque es cierto que ésto sólo ocurre cuando estás trabajando con el seguimiento de conexiones y los códigos base de NAT cargados ambos como módulos, y además los módulos son cargados y descargados cada vez que ejecutas el script. Otra forma de llegar a este problema es ejecutar el script rc.firewall.txt mediante una conexión telnet, desde un servidor situado fuera de la red del cortafuegos. Para aclararlo: conectas mediante telnet u otro tipo de conexión, arrancas los módulos de seguimiento de conexiones, después cargas las reglas "NEW not SYN" y por último, el cliente/demonio telnet intenta enviar algo. Es entonces cuando el código de seguimiento de conexiones no reconoce esta conexión como legal, puesto que no tiene constancia de ningún paquete en ninguna dirección para esta conexión; además no habrá ningún bit SYN establecido, puesto que no es el primer paquete de la conexión. Como consecuencia, el paquete será interceptado por estas reglas y después de añadirlo al registro, será eliminado.