Ahora es el momento de crear su propio archivo de configuración con las reglas personalizadas del firewall, para proteger la red interna. Habrá alguna complicación al hacerlo porque no todas las funcionalidades del firewall están disponibles en los paquetes bridge. Además, existe una diferencia entre los paquetes que están en proceso de reenvío y los paquetes que está recibiendo la máquina local. En general, los paquetes de entrada pasan por el firewall solo una vez, no dos veces, como suele ser el caso; en realidad se filtran solo después de la recepción, por lo que las reglas que usan out
o xmit
nunca coincidirán. Personalmente, utilizo in via
, aunque es una sintaxis más antigua, tiene sentido cuando la lees. Otra limitación es que usted está restringido a usar solo los comandos pass
o reject
para los paquetes filtrados por un bridge. Opciones más complejas como divert
, forward
o reject
no están disponibles. Estas opciones pueden seguir utilizándose, pero solo en el tráfico hacia o desde la propia máquina bridge (si tiene una dirección IP).
El concepto de firewall con estado es nuevo en FreeBSD 4.0. Es una gran mejora para el tráfico UDP, el cual, generalmente es una solicitud de salida, seguida poco después por una respuesta con exactamente el mismo conjunto de direcciones IP y números de puerto (pero con origen y destino invertidos, por supuesto). Para los firewalls que no mantienen el estado, no hay forma de lidiar con este tipo de tráfico en una única sesión. Pero con un firewall que puede “recordar” un paquete saliente de UDP y, durante los próximos minutos, permitir una respuesta, el manejo de servicios UDP es trivial. El siguiente ejemplo muestra cómo hacerlo. Es posible hacer lo mismo con los paquetes TCP. Esto le permite evitar algunos ataques de denegación de servicio y otros trucos desagradables, pero también hace que su tabla de estado crezca rápidamente de tamaño.
Veamos una configuración de ejemplo. Primero, tenga en cuenta que en la parte superior del archivo /etc/rc.firewall
ya existen reglas predeterminadas para la interfaz de loopback lo0
, por lo que no es necesario preocuparse por ellas. Las reglas personalizadas deben colocarse en un archivo separado (por ejemplo, /etc/rc.firewall.local
) y cargarse al inicio del sistema, modificando la línea en el archivo /etc/rc.conf
donde definimos el firewall en modo open
:
firewall_type="/etc/rc.firewall.local"
Debe especificar la ruta completa, de lo contrario, no se cargará, con el riesgo de permanecer aislado de la red.
Para nuestro ejemplo, imagine que tiene la interfaz fxp0
conectada hacia el exterior (Internet) y la xl0
hacia el interior (LAN). La máquina que haga de brigde tiene la IP 1.2.3.4
(su ISP no puede proporcionarle una dirección así, pero para nuestro ejemplo, nos sirve).
# Cosas para las que tenemos que mantener el estado add check-state # Desechar todas las redes RFC 1918 add drop all from 10.0.0.0/8 to any in via fxp0 add drop all from 172.16.0.0/12 to any in via fxp0 add drop all from 192.168.0.0/16 to any in via fxp0 # Permitir que la máquina bridge diga lo que quiera # (si la máquina es IP-less no incluya estas líneas) add pass tcp from 1.2.3.4 to any setup keep-state add pass udp from 1.2.3.4 to any keep-state add pass ip from 1.2.3.4 to any # Permitir que los hosts internos digan lo que quieran add pass tcp from any to any in via xl0 setup keep-state add pass udp from any to any in via xl0 keep-state add pass ip from any to any in via xl0 # Sección TCP # Permitir SSH add pass tcp from any to any 22 in via fxp0 setup keep-state # Permitir SMTP solo hacia el servidor de correo add pass tcp from any to relay 25 in via fxp0 setup keep-state # Permitir transferencias de zona solo por el servidor de nombres esclavo [dns2.nic.it] add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state # Dejar pasar ident probes. Es mejor que esperar a que se agote el tiempo add pass tcp from any to any 113 in via fxp0 setup keep-state # Dejar paso al rango "quarantine" add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state # Sección UDP # Permitir DNS solo hacia el servidor de nombres add pass udp from any to ns 53 in via fxp0 keep-state # Dejar pasar el rango "quarantine" add pass udp from any to any 49152-65535 in via fxp0 keep-state # Sección ICMP # Dejar paso a 'ping' add pass icmp from any to any icmptypes 8 keep-state # Dejar paso a los mensajes de error generados por 'traceroute' add pass icmp from any to any icmptypes 3 add pass icmp from any to any icmptypes 11 # Todo lo demás es sospechoso. add drop log all from any to any
Aquellos de ustedes que hayan instalado firewalls antes, notarán que faltan algunas cosas. En particular, no hay reglas contra la suplantación de identidad, de hecho, no las añadimos:
add deny all from 1.2.3.4/8 to any in via fxp0
Es decir, descartar los paquetes que vienen del exterior diciendo pertenecer a nuestra red. Esto es algo que normalmente haría para asegurarse de que alguien no trata de evadir el filtrado de paquetes, generando paquetes corruptos que parecen ser de dentro de la red. El problema es que hay al menos un host en la interfaz externa que no desea ignorar: el router. Pero, por lo general, el ISP tiene reglas contra la suplantación de identidad en su router, por lo que no tenemos que tomarnos tantas molestias.
La última regla parece ser un duplicado exacto de la regla predeterminada, es decir, no dejar pasar nada que no esté específicamente permitido. Pero hay una diferencia: todo tráfico sospechoso será registrado.
Hay dos reglas para permitir el tráfico SMTP y DNS hacia los servidores de correo y de nombres, si dispone de ellos. Obviamente, todo el conjunto de reglas debe ser definido de acuerdo con sus preferencias personales, esto es solo un ejemplo específico (el formato de la regla se describe con precisión en la página del manual de ipfw(8)). Tenga en cuenta que para que el “relay” y el “ns” funcionen, las búsquedas del servicio de nombres deben funcionar antes de que el bridge esté activado. Este es un ejemplo de cómo asegurarse de configurar la IP en la tarjeta de red correcta. Como alternativa, puede especificar la dirección IP en lugar del nombre del host (requerido si la máquina no tiene IP).
Las personas que están acostumbradas a configurar firewalls probablemente también estén acostumbradas a tener una regla reset
o forward
para los paquetes ident (TCP puerto 113). Desafortunadamente, esta no es una opción válida con el bridge, por lo tanto, la mejor opción es simplemente pasarlos a su destino. Mientras la máquina de destino no esté ejecutando un demonio ident, es realmente inofensivo. La alternativa es eliminar las conexiones en el puerto 113, lo que creará algunos problemas con servicios como IRC (el probe del ident dará timeout).
Lo único raro que puede haber notado es que existe una regla para permitir que la máquina que hace de bridge hable y otra para los hosts internos. Recuerde que esto sucede porque los dos conjuntos de tráfico tendrán diferentes rutas a través del kernel y del filtro de paquetes. La red interna pasará por el bridge, mientras que la máquina local utilizará el stack normal de IP para hablar. Por lo tanto, cada regla se ocupa de una cosa diferente. Las reglas in via fxp0
funcionan para ambas rutas. En general, si utiliza las reglas in via
en todo el filtro, debe añadir una excepción para los paquetes generados localmente, ya que no llegaron a través de ninguna de nuestras interfaces.
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Si tiene dudas sobre FreeBSD consulte la
documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a
<doc@FreeBSD.org>.