[ Introducción ] [
Caso-Estudio
] [ Instalación ] [ Configuración base ] [
Alias ] [ NAT
] [ Reglas ] [ DNS ] [ DHCP
] [ Caudal ] [ OpenVPN
] [ Portal ]
[ OpenVPN sin DHCP
] [ spamd ]
Estamos ahora en el corazón del cortafuegos. Aquí se decide qué conexiones se permiten y cuáles no.
Tenemos que entender el cortafuegos como una caja con una serie de puertas de entrada. Se trata de dejar o no dejar entrar (paquetes de información) por cada una de las puertas que tenemos. Este concepto es muy importante, ya que si un paquete de información puede entrar por una puerta querrá decir que saldrá (en principio) por cualquier otra. Por tanto, en lo que se refiere a las salidas sólo nos ocuparemos de seleccionar cuál queremos. Nada más que esto.
Cada puerta tiene pues sus reglas, que se ejecutan según el orden en que están puestas. De la primera hacia la última de la lista. Digo "hacia la última" porque cuando un paquete de información cumple una de las reglas se hace la acción que dice la regla y ya no se miran las siguientes.
¿Y qué pasa si se llega a la última regla y ninguna de ellas se ajusta a nuestro paquete de información? Pues que el paquete no pasa. Si no hay regla, el paquete es bloqueado.
¿Y qué acciones puede hacer una regla? Pues tres: dejar pasar (pass), bloquear (block) y rechazar (reject). La diferencia entre bloquear y rechazar es importante. Si se bloquea, simplemente se ignora el paquete de información que se está recibiendo. Si se rechaza, se comunica al emisor que no se quiere el paquete. Por tanto, normalmente se bloquea. ¿Por qué? Pues porqué bloquear es silencioso, es no hacer caso al emisor y nada más.
También podemos desactivar reglas. Las reglas desactivadas se ven "difuminadas" en la lista de reglas. Ello resulta especialmente interesante cuando se precisa de reglas ocasionales. Por ejemplo, para tareas de administración de la red.
Todos los ordenadores cliente emplean como configuración automática de proxy el archivo www.dominio.ejemplo/proxy.pac capaz de detectar si el proxy está disponible o no. En caso de no estar disponible, la navegación se hace de forma directa. El contenido del archivo proxy.pac es:
function FindProxyForURL(url,
host) { // No emplear proxy desde 192.168.XXX/24 // Hace obsoletas las regles 3 y 4 de la LAN isInNet(myIpAddress(), "192.168.XXX.0", "255.255.255.0") {return "DIRECT";} // No emplear proxy para nuestros dominios if (shExpMatch(url,"*.dominio.ejemplo/*")) {return "DIRECT";} if (shExpMatch(url,"*.dominio.ejemplo:*")) {return "DIRECT";} if (shExpMatch(url,"*.dominio.ejemplo2/*")) {return "DIRECT";} if (shExpMatch(url,"*.dominio.ejemplo2:*")) {return "DIRECT";} if (shExpMatch(url,"*/localhost/*")) {return "DIRECT";} if (shExpMatch(url,"*/localhost:*")) {return "DIRECT";} // No emplear proxy para
microsoft |
Si se desea, se pueden configurar reglas destinadas a bloquear el acceso al proxy, con el fin de forzar las conexiones de determinados clientes de forma directa. Por tanto, no hay que perder de vista que proxy.pac y las reglas del cortafuegos actúan conjuntamente.
¡Vamos allá, pues! A las reglas de cada una de las seis interfases ...
[Firewall] [Rules] [LAN]
[Firewall] [Rules] [WAN]
[Firewall] [Rules] [WAN1]
[Firewall] [Rules] [WAN2]
[Firewall] [Rules] [Alumnes]
[Firewall] [Rules] [Wireless]
Explicación de las reglas:
Explicación de las reglas:
Las reglas corresponden a la autorización del tráfico (desde la red WAN1) para los NAT Port Forward anteriormente definidos ...
Las reglas corresponden a:
Explicación de les reglas:
Se permite el tráfico hacia FTP-Proxy Helper, que reside en localhost (127.0.0.1).
Se bloquea el acceso a la administración de pfSense desde la red Alumnes.
Se bloquea el acceso a servicios de Microsoft desde la red Alumnes. Este bloqueo funciona sólo si no se pasa por el proxy que hay en la WAN. Por ello, en proxy.pac hay una regla para ir directo en el caso de Microsoft.
En contraposición a la regla 2, se permiten el resto de accesos de Alumnes a Alumnes. Esta regla es necesaria porqué la red Alumnes ve la IP de pfSense como servidor DHCP, DNS y puerta de enlace predeterminada.
Regla desactivada. Si se la activa sirve para bloquear el acceso al servidor proxy situado en la red WAN.
Permite el acceso a la red WAN desde la red Alumnes. Regla necesaria para poder acceder al servidor proxy de la WAN.
Regla desactivada. Si se la activa permite el acceso a la red WAN1 desde la red Alumnes.
Regla desactivada. Si se la activa permite el acceso a la red WAN2 desde la red Alumnes.
Permite el acceso desde la red Alumnes a www por los puertos estandard (HTTP, HTTPS y SSH).
Permite el acceso desde la red Alumnes a www por los puertos samba (servidor Samba/CIFS).
Permite el acceso SSH desde la red Alumnes a s207.
Permite el acceso desde la red Alumnes a s207 por los puertos samba (servidor Samba/CIFS).
Permite el acceso desde la red Alumnes a mail por los puertos correu (SMTP, POP3 SSL, HTTP y HTTPS).
Permite el acceso desde la red Alumnes a s204 por el puerto 60080 (webcam).
Permite el acceso desde la red Alumnes a s204 por los puertos samba (servidor Samba/CIFS).
Permet el acceso por RDP desde la red Alumnes a s204.
Permite el acceso desde la red Alumnes a cb50 por el puerto 60081 (webcam).
Permite el acceso desde la red Alumnes a s206 por los puertos samba (servidor Samba/CIFS).
El resto de tráfico de la red Alumnes saldrá hacia Internet por el router ADSL 192.168.AAA.1.
Vistas las reglas de la red Alumnes (sin duda la más compleja), las de la red Wireless se explican por si mismas ...
Las diferencias son que para la Wireless sólo se autorizan los servicios locales que se tendrían si se accediese desde Internet (web, SSH, correo y webcams) y que la conexión a Internet se hace por el router ADSL 192.168.CCC.1.
Autor: Josep Pujadas i Jubany
© 2007. Todos los derechos reservados