8.4. rc.DHCP.firewall.txt

El script rc.DHCP.firewall.txt es casi idéntico al original (rc.firewall.txt). Sin embargo, en este caso no se usa la variable STATIC_IP, lo cual es la mayor diferencia con el script original (rc.firewall.txt). La razón es que no funcionaría en una conexión con IP dinámica. Los cambios necesarios en el script original son mínimos, pero ha habido gente que me ha preguntado cómo solventar el problema de las IPs dinámicas, así que este script será una buena solución para todos los que tengan las mismas dudas. Este script es válido para todos aquellos que utilicen conexiones DHCP, PPP y SLIP para acceder a Internet.

El script rc.DHCP.firewall.txt requiere las siguientes opciones compiladas estáticamente en el núcleo, o al menos como módulos, para funcionar correctamente.

• CONFIG_NETFILTER

• CONFIG_IP_NF_CONNTRACK

• CONFIG_IP_NF_IPTABLES

• CONFIG_IP_NF_MATCH_LIMIT

• CONFIG_IP_NF_MATCH_STATE

• CONFIG_IP_NF_FILTER

• CONFIG_IP_NF_NAT

• CONFIG_IP_NF_TARGET_MASQUERADE

• CONFIG_IP_NF_TARGET_LOG

Los cambios principales efectuados al script consisten en la supresión de la variable STATIC_IP, como ya he dicho, y de todas las referencias a élla. En lugar de utilizarla, el script ejecuta la mayor parte del filtrado a través de la variable INET_IFACE. Es decir, se ha cambiado -d $STATIC_IP por -i $INET_IFACE. Básicamente éstos son los únicos cambios necesarios.

De todas formas, hay algunas cosas más en las que debemos pensar. Ya no podemos filtrar en la cadena INPUT en función de, por ejemplo, --in-interface $LAN_IFACE --dst $INET_IP. Ésto nos obliga a filtrar únicamente basándonos en interfases en aquellos casos dónde las máquinas internas deben acceder a la IP direccionable de Internet. Un buen ejemplo es cuando ejecutamos un servidor HTTP en nuestro cortafuegos: si nos dirigimos a la página principal, la cual contiene enlaces estáticos a su mismo host (que puede tener alguna solución de dns dinámico, o dyndns), nos encontraremos con un problema realmente peliagudo. La máquina "NATeada" le preguntará al DNS por la IP del servidor HTTP, para luego intentar acceder a esa IP. Si filtrásemos basándonos en la interfaz y en la IP, la máquina "NATeada" sería incapaz de llegar al servidor HTTP, puesto que la cadena INPUT simplemente desecharía los paquetes. Ésto también puede aplicarse de alguna forma en el caso de que tengamos una IP estática, pero aquí tenemos la oportunidad de evitar el problema añadiendo reglas que chequeen si hay paquetes destinados a la INET_IP que provengan de la interfaz LAN, en cuyo caso los aceptará.

Como puedes observar, puede ser una buena idea conseguir un script (o escribirlo) que gestione más razonablemente las IPs dinámicas. Así, por ejemplo podemos escribir un script que capte la IP a través de ifconfig y la asigne a una variable, tras el arranque inicial de la conexión a Internet. Una buena forma de conseguirlo sería emplear los scripts ip-up que ofrece pppd, entre otros programas. Un buen sitio para buscar scripts es la página web sobre iptables "linuxguruz.org", dónde podrás encontrar y descargar montones de éllos. Encontrarás el enlace en el apéndice Otras fuentes y enlaces.

Además, existe la posibilidad de añadir algo parecido a lo siguiente en tus scripts:

INET_IP=`ifconfig $INET_IFACE | grep inet | cut -d : -f 2 | \
cut -d ' ' -f 1`
    

Con éllo se captaría automáticamente la dirección IP de la variable $INET_IFACE, buscando la línea que contuviera la dirección IP y eliminando todo lo innecesario hasta obtener una dirección manejable. Para hacer todo ésto de una manera más elaborada, puedes aplicar las porciones de código disponibles en el script retreiveip.txt, que captarán automáticamente tu dirección IP de Internet al ejecutarlo. Ten en cuenta que, en cambio, con éllo se pueden obtener comportamientos algo extraños, como conexiones ralentizadas desde y hacia el cortafuegos en la parte interna. Los comportamientos extraños más comunes se describen en la siguiente lista:

1. Si el script se ejecuta desde otro script, que a su vez es ejecutado por, por ejemplo, el demonio PPP, todas las conexiones activas en ese momento se "colgarán", debido a las reglas "NEW not SYN" (léete el capítulo Paquetes cuyo estado es NEW pero cuyo bit SYN no se ha establecido). Es posible evitarlo si, por ejemplo, eliminas las reglas NEW not SYN, aunque esta solución es cuestionable.

2. Si tienes reglas que son estáticas y siempre tienen que estar activas, es bastante difícil añadir y borrar reglas contínuamente sin dañar las ya existentes. Por ejemplo, si quieres bloquear todos los intentos de conexión al cortafuegos provenientes de los hosts de tu LAN y, al mismo tiempo, ejecutar un script desde el demonio PPP, ¿cómo lo consigues sin borrar las reglas activas que están bloqueando tu LAN?

3. Puede complicarse innecesariamente, tal como se ha visto, lo cual puede llevar a comprometer la seguridad. Si el script se mantiene simple, es más fácil descubrir problemas y mantener un orden.