El cortafuegos original de IP (núcleos 2.0)

La primera generación del soporte de cortafuegos de IP para Linux apareció en la serie de núcleos 1.1. Consistía en una implementación del cortafuegos ipfw de BSD por Alan Cox. El soporte de cortafuegos que apareció en la serie de núcleos 2.0 que constituye la segunda generación fue una mejora de Jos Vos, Pauline Middelink y otros.
Uso de ipfwadm
La orden ipfwadm era la herramienta de configuración para la segunda generación de cortafuegos de IP de Linux. Quizás la forma más simple de describir el uso de la orden ipfwadm es con un ejemplo. Para empezar, se codificará el ejemplo que se presentó antes.
Un ejemplo trivial
Supóngase que se dispone de una red en nuestra organización y que se utiliza una máquina cortafuegos basada en Linux para conectar la red a Internet. Además, supóngase que se desea que los usuarios de la red sean capaces de acceder a servidores ’web’ de Internet, pero que cualquier otro tipo de tráfico no sea permitido.
Se pondrá una regla de tipo ’forwarding’ para permitir que los datagramas con dirección de origen en nuestra red y un conector de destino con puerto 80 sean reenviados hacia fuera, y los correspondientes datagramas de respuesta sean reenviados de vuelta vía el cortafuegos.
Asúmase que nuestra red tiene una máscara de 24 bits (clase C) y una dirección de 172.16.1.0. La reglas que se podrían utilizar serían:
El argumento -F de la línea de órdenes significa especifica a ipfwadm que es una regla de tipo ’forward-ing’, es decir, de reenvío. La primera orden instruye a ipfwadm que se «desprenda» de todas las reglas de tipo ’forwarding’. Esto asegura que se trabajará con un estado conocido antes de que se añadan reglas específicas.
La segunda regla establece nuestra política por defecto de reenvío. Se le dice al núcleo que niegue o que no permita el reenvío de datagramas de IP. Es muy importante establecer la política por defecto, porque describe qué le pasará a cualquier datagrama que no esté específicamente controlado por cualquier otra regla. En la mayoría de las configuraciones de cortafuegos, usted querrá establecer la política por defecto a ’deny’16, como se muestra en el ejemplo, para estar seguro de que sólo el tráfico que usted específicamente permita pasar su cortafuegos sea reenviado.
La tercera y la cuarta reglas son las que implementan el requisito. La tercera orden permite que nuestros datagramas salgan, y la cuarta permite las respuestas de vuelta.
Vamos a revisar cada unos de los argumentos: