Lea el Cortafuegos-Como,
http://www.insflug.org/documentos/Cortafuegos-Como/
Esto le dirá donde obtener ipfwadm si no lo tiene ya. Hay otras
herramientas que puede obtener, pero no he hecho avances con ellas hasta que no
probé ipfwadm. ˇEstá muy bien, y es de bajo nivel! Puede ver
exactamente lo que está pasando.
Ha compilado soporte de reenvío IP y enmascaramiento en el kernel, así que querrá comprobar que el cortafuegos está en su estado por defecto (aceptando) con
ipfwadm -I -l
ipfwadm -O -l
ipfwadm -F -l
Esto es respectivamente: mostrar las reglas que afecten entrantes o salientes o
reenviando (enmascarando) hacia ambos lados del cortafuegos. El -l
significa listar.
Si también ha compilado soporte de informes (accounting):
ipfwadm -A -l
Debería ver que no hay reglas definidas y que por defecto se aceptan todos los paquetes. Puede volver a este estado en cualquier momento usando
ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -f
El -f significa «vaciar». Puede que necesite usarlo.
Quiero evitar a mi red llegar al mundo, y nada más, por lo que por lo menos
daré una regla última (por defecto) que diga que el cortafuegos debería ignorar
aquellos paquetes que vengan de la red interna dirigidos al exterior. Pongo las
reglas (en este orden) en /etc/rc.d/rc.firewally lo ejecuto desde
/etc/rc.d/rc.local en el arranque.
ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0
El -S es la dirección/máscara origen. El -D es la
dirección/máscara de destino.
Este formato es demasiado largo. ipfwadm es suficientemente
inteligente sobre temas de red y entiende algunas abreviaturas. Lea las páginas
del manual.
Posiblemente es más conveniente poner algunas o todas estas reglas en la parte
saliente del cortafuegos usando -O en vez de -I, pero fijaré
las reglas para la mitad entrante.
Antes de la regla por defecto, tengo que poner algunas reglas que me sirvan como excepciones a esta denegación de servicios externos general a los clientes internos.
Quiero tratar las direcciones internas de los cortafuegos en especial. He de evitar que la gente entre en el firewall a no ser que tengan un permiso especial, pero una vez que entren deberían ser capaces de hablar con el resto del mundo.
ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 -D 0.0.0.0/0.0.0.0
También quiero que los clientes puedan hablar con el cortafuegos. ˇA lo mejor le convencen de que les deje salir!
ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 -D 192.168.2.100/255.255.255.255
Compruebe en este punto de que puede entrar en los clientes desde fuera del
cortafuegos usando telnet, pero que no puede salir. Esto debería
significar que puede hacer el primer contacto, pero los clientes no pueden
enviarle la línea de comandos. Debe ser capaz de llegar hasta el final si usa
la máquina cortafuegos como paso intermedio. Intente un rlogin y un
ping también, con tcpdump ejecutándose en una tarjeta o en
otra. Debe ser capaz de dar sentido a lo que ve.
Seguí relajando las reglas protocolo por protocolo. Quiero permitir los
ping desde el exterior al interior para obtener un eco de respuesta,
por ejemplo, así que inserté la regla:
ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0
El parámetro -P icmp realiza la magia necesaria a nivel del protocolo.
Hasta que use un proxy ftp voy a permitir los ftp salientes con
permisos específicos de puerto. Esto se dirige a los puertos 20
21 y 115 de las máquinas exteriores.
ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
-D 0.0.0.0/0.0.0.0 20 21 115
No puedo hacer que sendmail funcione entre los clientes locales sin un
servidor de nombres. En vez de instalar un servidor de nombres en el
cortafuegos, lo levanto para las peticiones de servicio en el dominio tcp que
se dirijan al servidor de nombres más cercano, poniendo esta dirección en los
archivos /etc/resolv.conf de los clientes.(nameserver
123.456.789.31 en una línea aparte).
ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
-D 123.456.789.31/255.255.255.255 54
Puede encontrar el puerto y protocolo usado por un servicio con
tcpdump. Lance el servicio con un ftp o un telnet o
lo que sea a o desde la máquina interna y mire lo que ocurre en los puertos de
entrada y salida del cortafuegos con tcpdump:
tcpdump -i eth1 -e host client04
por ejemplo: El archivo /etc/services es otra fuente importante de
pistas. Para permitir telnet y ftp entrantes al cortafuegos
desde el exterior, debe permitir a los clientes locales llamadas salientes en
un puerto específico. Entiendo por qué es necesario esto para para ftp
(es el servidor el que establece el flujo de datos al final) pero no sé por qué
telnet también lo necesita.
ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \
-D 0.0.0.0/0.0.0.0
Hay un problema específico con algunos demonios que buscan el nombre del
cortafuegos para buscar su dirección de red. Rpc.yppasswdd es uno con
el que tuve problemas. Insiste en transmitir información que diga que está
fuera del cortafuegos (en la segunda tarjeta). Esto significa que los clientes
de dentro no pueden contactar con él.
En vez de empezar a hacer IP aliasing o cambiar el código del demonio, he
correspondido el nombre a la dirección de la tarjeta interna en los clientes,
en el archivo /etc/hosts.
Querrá comprobar que puede hacer telnet, rlogin y
ping desde el exterior. Desde el interior debería poder hacer
ping hacia fuera. Debería ser capaz también de hacer telnet a la
máquina cortafuegos desde el interior, y la última debería ser incapaz de hacer
nada.
Y ya está. En este momento probablemente quiera aprender cosas sobre
rpc y NIS/NYS (Páginas amarillas) y la interacción con el
archivo de contraseñas. La red con cortafuegos debe funcionar sin que los
usuarios normales tengan capacidad de entrar al cortafuegos y,
consiguientemente, salir al exterior. ˇA lo mejor esto es otro COMO!