Practica #5 “INSTALACIÓN DE UN FIREWALL EN...

Seguridad en Redes de Datos

Profesor: Luis Enrique Palafox Maestre

Practica #5 “INSTALACIÓN DE UN FIREWALL EN LINUX”

Introducción:

En los tiempos actuales y en la situación que se encuentra el uso de Internet, ha quedado demostrado que resulta indispensable el empleo de dos tipos de programas: un anti-virus y un "firewall". Del primero casi todo el mundo ha oído hablar alguna vez y su empleo es más o menos mayoritario, pero el término "firewall" provoca desconcierto y desconocimiento en el que lo escucha. La traducción literal de "firewall" sería muro de fuego, que no es precisamente ni una buena traducción ni un indicativo claro de lo que realizan este tipo de utilidades. Un "firewall" no es un elemento de hardware, nada físico que se conecte a nuestro ordenador, ni por supuesto se trata de un muro de fuego.

¿Qué es un Firewall?

Un "firewall" es un programa de software que mediante unos códigos creados por el programador permite aislar completamente nuestro ordenador de una red, tanto local como exterior. Estos programas inspeccionan cada uno de los paquetes individuales de datos que llegan o salen del equipo y determinan, en función del código programado, si deben permitir el paso o la salida de esa información o por el contrario bloquearla. La presencia de un "firewall" tan importante que, pasará a ser un estándar de cualquier equipo en el futuro; baste como prueba que Microsoft incluye uno en su Windows XP. Importante es también comprender el concepto de que no solamente es necesario controlar la información que llega a nuestro ordenador, sino también la que sale. Muchos 'troyanos' actúan libremente transmitiendo información de nuestro equipo a su creador, por no hablar aquí de la enorme cantidad de programas gratuitos cuyo precio a pagar es la comunicación de datos, sin nuestro conocimiento, sobre nuestra navegación en Internet a los creadores de ese programa , en lo que se denomina "spyware". Un firewall es un dispositivo que funciona como cortafuegos entre redes, permitiendo o denegando las transmisiones de una red a la otra. Un uso típico es situarlo entre una red local y la red Internet, como dispositivo de seguridad para evitar que los intrusos puedan acceder a información confidencial. Un firewall es simplemente un filtro que controla todas las comunicaciones que pasan de una red a la otra y en función de lo que sean permite o deniega su paso. Para permitir o denegar una comunicación el firewal examina el tipo de servicio al que corresponde, como pueden ser el web, el correo o el IRC. Dependiendo del servicio el firewall decide si lo permite o no. Además, el firewall examina si la comunicación es entrante o saliente y dependiendo de su dirección puede permitirla o no. De este modo un firewall puede permitir desde una red local hacia Internet servicios de web, correo y ftp, pero no a IRC que puede ser innecesario para nuestro trabajo. También podemos configurar los accesos que se hagan desde Internet hacia la red local y podemos denegarlos todos o permitir algunos servicios como el de la web, (si es que poseemos un servidor web y queremos que accesible desde Internet). Dependiendo del firewall que tengamos también podremos permitir algunos accesos a la red local desde Internet si el usuario se ha autentificado como usuario de la red local. Un firewall puede ser un dispositivo software o hardware, es decir, un aparatito que se conecta entre la red y el cable de la conexión a Internet, o bien un programa que se instala en la máquina que tiene el modem que conecta con Internet. Incluso podemos encontrar ordenadores computadores muy potentes y con software específicos que lo único que hacen es monitorizar las comunicaciones entre redes.



Fig 1. Descripción gráfica del funcionamiento de un Firewall

Tipos de firewalls: Ruteadores filtradores de paquetes. Gateways a nivel de aplicación. Gateways a nivel de circuitería.

Ruteadores filtradores de paquetes.

El Filtrador de Paquetes trabaja a nivel TCP/IP y no tienen control de qué aplicaciones están filtrando. Aceptan paquetes pre-aprobados - aquellos que vienen de fuentes particulares o que son direccionados a direcciones específicas de su red. El Filtro de Paquetes es transparente al usuario y puede ser instalado como parte de un Router que entrega la típica conexión a Internet. De todas formas, como solución de seguridad, el Filtro de Paquetes por sí solo, tiene varios fallos. Primero, requieren que el remitente sea pre-aprobado. Usted quizá quiera permitir el acceso a un servicio desde un usuario remoto, pero no a otros servicios. La solución requiere definiciones especiales de qué tipo de servicios pueden ser autorizados. Estas definiciones especiales pueden ser particularmente difíciles de aplicar. Además, se pueden tener problemas con servicios como FTP o DNS. Estas aplicaciones usan protocolos que son extremadamente difíciles de gestionar a nivel de paquetes.

Fig 2. Ruteadores filtradores de paquetes

Gateways a nivel de aplicación. Las Gateways a Nivel de Aplicación efectúan el mismo tipo de función de las Gateways a Nivel de Circuito con una adición. Examinan los contenidos de cada paquete cuando



pasan por la Gateway. Los Hackers no tienen la oportunidad de entrar a su sistema "escondiendo" datos destructivos entre la información aparentemente "sana". Esto es particularmente importante cuando se permite el acceso de correo electrónico externo a su red interna. SMTP no es un protocolo seguro, y es el sistema de vulnerabilidad más común. La Gateway examina tanto los paquetes de salida como de entrada. Esto elimina la posibilidad de que usuarios internos accedan a servicios no autorizados que puedan crear un "agujero" en la seguridad. La Gateway a Nivel de Aplicación es el protocolo de filtro más seguro. Dado que efectúan un detallado análisis de los paquetes, son los más costosos en términos de tiempo y de equipo. Este tipo de firewall, es conocido también como proxy.

Fig 3. Gateways a nivel de aplicación

Gateways a nivel de circuitería Las Gateways por definición son seguras. Todo el tráfico de entrada y salida está gobernado por una Gateway. Ya que no hay una conexión física directa entre las máquinas de su red interna y las redes externas, las conexiones de salida pueden ser todavía permitidas cuando el destino sea autorizado. Las Gateways a Nivel de Circuito usan proxies para asegurar su red interna. Los llamantes establecen conexiones TCP/IP con la Gateway. Una puerta de la Gateway actúa como un agente para sus usuarios. Este agente verifica las transmisiones y las acepta dependiendo del usuario. La Gateway entrega luego los datos a la dirección apropiada de su red interna. Además, la dirección del agente es la única información transmitida externamente en los paquetes de salida. Los Proxies ayudan a limitar la cantidad de información de máquinas individuales que se enseña al mundo exterior. De todas formas, es posible que un usuario interno rompa esta seguridad usando una puerta no estándar o bien un servicio no autorizado. Al contrario del Filtro de Paquetes, la Gateway a Nivel de Circuito no examina cada paquete de datos. Aceptan múltiples paquetes de datos una vez verificada la información de dirección.

Fig 4. Gateways a nivel de circuitería



¿Qué es Squid?

Squid es el software para servidor Proxy más popular y extendido entre los sistemas operativos basados sobre UNIX®. Es muy confiable, robusto y versátil. Al ser software libre, además de estar disponible el código fuente, está libre del pago de costosas licencias por uso o con restricción a un uso con determinado número de usuarios.

Squid es un programa que hace caché de datos obtenidos en Internet. Realiza este trabajo aceptando peticiones de los objetos que los usuarios quieren descargar y realizando estas peticiones a la red en su nombre. Squid se conecta con el servidor correspondiente, pide el objeto. De forma transparente, este objeto se entrega a la máquina cliente, pero al mismo tiempo, guarda una copia. La próxima vez que alguna máquina cliente de squid solicite la misma página, squid simplemente le transfiere su copia almacenada en memoria o disco acelerando considerablemente la transferencia y ahorrando ancho de banda en la conexión a Internet. Actualmente Squid es capaz de hacer proxy-caché de los protocolos HTTP, FTP, GOPHER, SSL y WAIS. No soporta POP, NNTP, RealAudio y otros. El servidor proxy Squid guarda los datos cacheados en la memoria RAM, realiza caché de consultas DNS, y no guarda en el cache las peticiones que son rechazadas. Squid también soporta SSL (Secure Socket Layer) con lo que también acelera las transacciones cifradas, y es capaz de ser configurado con amplios controles de acceso sobre las peticiones de usuarios, lo que es muy útil, por ejemplo en un centro educativo para permitir y denegar acceso al servidor a diferentes grupos de usuarios. Al utilizar el protocolo de cache de Internet, squid puede ahorrar un considerable ancho de banda. Mejorando la velocidad de acceso a Internet en estos protocolos. Este software consta de un programa servidor principal llamado squid, un programa búsqueda de nombres en el DNS llamado dnsserver, un programa para recuperar ficheros vía FTP, llamado ftpget, y algunas herramientas de mantenimiento y programas cliente. Cuando arranca, levanta un numero configurable de procesos dnsserver, cada uno de los cuales realiza una búsqueda en el sistema DNS, lo que reduce el tiempo que la caché espera por la resolución de nombres. Squid es el resultado del esfuerzo de numerosas personas individuales de Internet y al igual que el sistema operativo Linux es gratis y tiene el código fuente disponible para poder modificarlo según las necesidades.



Procedimiento: El objetivo principal de esta práctica es, instalar un firewall bajo linux(RedHat 7) el cual servirá como un servidor proxy, en una PC con acceso a Internet. Este firewall se encargará de restringir el acceso hacia la red externa desde una red privada. La PC donde se instalara el firewall, contiene dos tarjetas de red, una tarjeta eth0 que se conecta hacia la red externa(Internet) una tarjeta eth1 que sirve de enlace entre la red privada y la red externa; cabe señalar que la conexión entre la tarjeta eth1 y la red privada, puede ser mediante un Hub o un cable cruzado, tomando en cuenta que utilizando un cable cruzado, obviamente solo es posible tener un equipo conectado en la red privada. Para realizar todo este proceso, será necesario seguir los siguientes pasos, suponiendo que Red Hat 7 ya se encuentra instalado:

1. Configuración de las dos tarjetas de red. 2. Instalación del demonio Routed. 3. Instalación de Squid en su versión más estable. 4. Configuración de Squid para restringir el acceso desde la red privada hacia el exterior. 5. Estableciendo reglas de control de acceso. 6. Comprobación del correcto funcionamiento del firewall(proxy server).

Diagrama de configuración del firewall:

Fig 5. Configuración física del firewall

En la figura anterior, se muestra como debe quedar configurado físicamente el firewall. Primeramente debemos tener un PC en la cual se instalara todo el software requerido para el firewall. En este caso, se utilizara un sistema operativo con plataforma linux(Redhat 7), el cual previamente debe estar instalado, de no ser así, proceder con la instalación. Esta PC debe contar con dos tarjetas de red, una de ellas permitirá el acceso a la red publica(Internet) mientras la otra servirá de enlace entre una red privada y la red publica; en este caso, la red privada consta de una sola maquina, la cual tiene Windows 2000. La tarjeta con conexión a Internet(eth0), debe estar configurada como se muestra en la figura 5, utilizando como se puede ver, una dirección física; la tarjeta que conecta a la red privada con el exterior(eth1), igualmente debe estar configurada como se muestra en la figura 5, con una dirección IP privada. Finalmente, la tarjeta de PC con Windows, que será mi único equipo conectada en red privada, al igual que eth1 debe contener una dirección IP privada, tomando en cuenta que el gateway de esta tarjeta será la dirección IP de la tarjeta eth1.



1. Configuración de las dos tarjetas de red.

Tomando en cuenta lo descrito anteriormente en base a la figura 5, procedemos ahora a la configuración de las tarjetas de red. Configurando eth0:

[root@localhost /root] # vi /etc/sysconfig/network-scripts/ifcfg-eth0 ↵ Guardamos los cambios y cerramos el archivo, para configurar ahora eth1.

Configurando eth0:

[root@localhost /root] # vi /etc/sysconfig/network-scripts/ifcfg-eth1 ↵

Guardamos los cambios y cerramos el archivo. [root@localhost /root] # _ Ahora, necesitamos configurar el gateway y DNS de eth0, para configurar el gateway debemos hacerlo dentro del archivo network ubicado en /etc/sysconfig. En este mismo archivo, tenemos que agregar también la siguiente línea:

FORWARD_IPV4=yes Esto permitirá que el tráfico salte de una red a otra a través de eth0 y eth1. Configurando el eth0:

[root@localhost /root] # vi /etc/sysconfig/network ↵

DEVICE=eth0 BROADCAST=148.231.149.127 IPADDR=148.231.149.101 NETMASK=255.255.255.192 NETWORK=148.231.149.64 ONBOOT=yes

DEVICE=eth1 BROADCAST=192.168.0.63 IPADDR=192.168.0.1 NETMASK=255.255.255.192 NETWORK=192.168.0.0 ONBOOT=yes

NETWORKING=yes HOSTNAME=localhost.localdomain GATEWAY=148.231.149.65 FORWARD_IPV4=yes



Guardar los cambios y cerrar el archivo. [root@localhost /root] # _ Finalmente para terminar la configuración de eth0 y eth1, debemos modificar el DNS, que se encuentra en el archivo resolv.conf ubicado /etc/. Modificando el DNS:

[root@localhost /root] # vi /etc/resolv.conf ↵ Guardar los cambios y cerrar el archive. [root@localhost /root] # _ Con esto hemos terminado la configuración de las tarjetas eth0 y eth1. Para que tome efecto esta configuración, es necesario reinicializar el servicio de la siguiente manera:

[root@localhost /root] # service network restart ↵ [root@localhost /root] # _

2. Instalación del demonio Routed.

La instalación del demonio Routed es bastante sencilla, únicamente tenemos que bajar el archivo correspondiente a Routed, ejecutarlo y bajarlo. Como primer paso para instalar el demonio, debemos ir al siguiente sitio Web:

http://www.rpmfind.net Después de entrar al sitio, en el cuadro de búsqueda introducimos routed para comenzar la búsqueda del demonio, en la página que aparecerá inmediatamente después, seleccionar el routed correspondiente a la versión de RedHat para posteriormente bajarlo.

Nameserver 148.231.149.66 Search localdomain



Después de bajar el archivo de instalación del routed, solo será necesario ir a la ubicación del archivo y ejecutarlo presionando doble clic sobre el. Con esto la instalación del routed se iniciara automáticamente y después de unos cuantos segundos la instalación del routed habrá terminado. 3. Instalación de Squid en su versión más estable.

Para iniciar con la instalación de Squid, primeramente debemos entrar al sitio donde podremos bajar el archivo de instalación de Squid.

http://www.squid-cache.org Ya estando en el sitio, buscar un enlace que nos permita bajar Squid en su versión más estable, como se muestra a continuación:

Después de bajar el archivo, podemos proceder ahora si con la instalación. Instalando Squid: Comenzamos abriendo una consola en RedHat, para descomprimir el archivo de Squid, y ahí poder comenzar con la instalación.:

[root@localhost /root] # tar xzf Squid-2.5.STABLE5.tar.gz ↵ [root@localhost /root] # _ Entrar a la carpeta descomprimida:

[root@localhost /root] # cd Squid-2.5.STABLE5 ↵ [root@localhost Squid-2.5.STABLE5] # _



Para iniciar con la instalación de Squid, primeramente debemos compilar Squid y posteriormente seguir con la instalación, como sigue:

[root@localhost Squid-2.5.STABLE5] # ./configure ↵ En la línea anterior, solo se compilan los archivos de Squid, después de varios segundos, regresamos a la línea de comando donde podemos introducir ahora la instrucción para instalar Squid.

[root@localhost squid-2.5.STABLE5] # make install ↵ [root@localhost squid-2.5.STABLE5] # _ Después de haber hecho lo anterior, termina con la instalación de Squid

4. Configuración de Squid para restringir el acceso desde la red privada hacia el exterior. Si estamos corriendo Squid como usuario root, antes de continuar debemos crear un directorio cache y otro llamado logs para continuar con la configuración de Squid. En nuestro caso, debemos hacer esto, creando estos dos directorios en la siguiente ubicación

/usr/local/squid/var/

[root@localhost squid-2.5.STABLE5] # mkdir /usr/local/squid/var/logs ↵

[root@localhost squid-2.5.STABLE5] # mkdir /usr/local/squid/var/cache↵ [root@localhost squid-2.5.STABLE5] # _ Para que queden listos los directorios creados anteriormente, debemos asignar como usuario dueño de estos directorios, a un usuario previamente creado.

[root@localhost squid-2.5.STABLE5] # cd /usr/local/squid/var ↵

[root@localhost var] # chown k105h2 logs ↵

[root@localhost var] # chown k105h2 cache ↵ [root@localhost var] # _ Después de esto, debemos configurar el archivo squid.conf asignando en la directiva cache_effective_user el usuario dueño indicado anteriormente. El archivo de configuración squid.conf, se encuentra en la siguiente ubicación:

/usr/local/squid/etc/

[root@localhost var] # cd /usr/local/squid/ ↵

[root@localhost etc] # vi squid.conf ↵ [root@localhost etc] # _ Dentro de squid.conf, debemos encontrar la directiva cache_effective_user:

[root@localhost etc] # vi /usr/local/squid/etc/squid.conf ↵



Solo es necesario descomentar la última línea(quitar el signo #) y sustituir “nobody” por el usuario dueño del los directorios logs y cache, como se muestra a continuación: Solo falta guardar los cambios en el archivo, y listo. Después de hacer cualquier modificación al archivo squid.conf, existe una forma de verificar que no tenga ningún error sintáctico, solo es necesario escribir lo siguiente en la línea de comando estando en /usr/local/squid/sbin:

root@localhost etc] # cd .. ↵

# TAG: cache_effective_user # TAG: cache_effective_group # # If you start Squid as root, it will change its effective/real # UID/GID to the UID/GID specified below. The default is to # change to UID to nobody. If you define cache_effective_user, # but not cache_effective_group, Squid sets the GID the # effective user's default group ID (taken from the password # file). # # If Squid is not started as root, the cache_effective_user # value is ignored and the GID value is unchanged by default. # However, you can make Squid change its GID to another group # that the process owner is a member of. Note that if Squid # is not started as root then you cannot set http_port to a # value lower than 1024. # #Default: # cache_effective_user nobody

# TAG: cache_effective_user # TAG: cache_effective_group # # If you start Squid as root, it will change its effective/real # UID/GID to the UID/GID specified below. The default is to # change to UID to nobody. If you define cache_effective_user, # but not cache_effective_group, Squid sets the GID the # effective user's default group ID (taken from the password # file). # # If Squid is not started as root, the cache_effective_user # value is ignored and the GID value is unchanged by default. # However, you can make Squid change its GID to another group # that the process owner is a member of. Note that if Squid # is not started as root then you cannot set http_port to a # value lower than 1024. # #Default: cache_effective_user k105h2



root@localhost sbin] # ./squid –k parse ↵ root@localhost sbin] # _ Si después de presionar ENTER no aparece ninguna línea indicando algún error, quiere decir que el archivo squid.conf no tiene ningún error sintáctico. De lo contrario, aparecerá una línea de error indicando el numero de línea dentro de squid.conf donde se localizado el error. Después de haber hecho todo lo anterior, continuamos con la configuración de Squid. Creación de directorios swap: Cuando se instala Squid por primera vez o cuando se modifica el directorio cache, es necesario realizar lo siguiente dentro de sbin para crear los directorios swap:

root@localhost sbin] # ./squid –z ↵ root@localhost sbin] # _ Si no se hubieran creado los directorios logs y cache, después de ejecutar la instrucción anterior, se hubiera producido un error. Este fue el motivo por el cual fue necesario crear estos directorios antes de crear los directorios swap. Comenzar Squid: Después de terminar completamente con la creación de los directorios cache, procedemos a comenzar Squid y probar si esta funcionando, para hacer esto hacer lo siguiente:

root@localhost sbin] # ./squid –NCd1 ↵ root@localhost sbin] # _ Si no existen errores, después de aparecer en pantalla un montón de líneas procesadas, regresamos a la línea de comando sin tener ningún mensaje de error. Esto quiere decir, que Squid sea inicializado sin problemas. Si por algún motivo existiera algún error, como el que se nos presento, Squid no podrá comenzar. El error que tuvimos, lo causó el hecho de no tener conexión a Internet, apareciendo el siguiente error: [root@localhost sbin] # ./squid –NCd1 ENTER 2004/05/20 13:17:28 Starting Squid cache version 2.5.STABLE5 for iC86 pc-linux-gnu… 2004/05/20 13:17:28 Process ID 11201 2004/05/20 13:17:28 With 1024 file description available 2004/05/20 13:17:28 Performing DNS test… después de varios segundos aparece lo siguiente: FATAL: IPCache_init: DNS name lockup test failed. Aborted [root@localhost sbin] # Para solucionar este error, lo único que debemos hacer es asegurarnos de tener acceso a Internet, y volver a usar la instrucción ./squid –NCd1 Cuando se desee iniciar Squid de nuevo, solo es necesario escribir

[root@localhost sbin] # ./squid ↵



Configuración básica de squid.conf: Como ya se vio, Squid esta localizado en /etc/squid/squid.conf. Existen un gran número de parámetros, de los cuales se recomiendan configurar los siguientes:

• http_port • cache_mem • ftp_user • cache_dir • Al menos una Lista de Control de Acceso • Al menos una Regla de Control de Acceso

• http_port: ¿Qué puerto utilizar para Squid? Squid por defecto utilizará el puerto 3128 para atender peticiones, sin embargo se puede especificar que lo haga en cualquier otro puerto o bien que lo haga en varios puertos a la vez. En el caso de un Proxy Transparente, regularmente se utilizará el puerto 80 y se valdrá del re-direccionamiento de peticiones de modo tal que no habrá necesidad alguna de modificar la configuración de los navegadores de Red para utilizar el servidor Proxy. Bastará con utilizar como puerta de enlace al servidor. Es importante recordar que los servidores HTTP, como Apache, también utilizan dicho puerto, por lo que será necesario reconfigurar el servidor Web para utiliza otro puerto disponible, o bien desinstalar o deshabilitar el servidor Web. Hoy en día ya no es del todo práctico el utilizar un Proxy Transparente, a menos que se trate de un servicio de Café Internet u oficina pequeña, siendo que uno de los principales problemas con los que lidian los administradores es el mal uso y/o abuso del acceso a Internet por parte del personal. Es por esto que puede resultar más conveniente configurar un servidor Proxy con restricciones por contraseña, lo cual no puede hacerse con un Proxy Transparente, debido a que se requiere un diálogo de nombre de usuario y contraseña. Regularmente algunos programas utilizados comúnmente por los usuarios suelen traer por defecto el puerto 8080 -servicio de cacheo WWW- para utilizarse al configurar que servidor proxy utilizar. Si queremos aprovechar esto en nuestro favor y ahorrarnos el tener que dar explicaciones innecesarias al usuario, podemos especificar que Squid escuche peticiones en dicho puerto también. Siendo así localice la sección de definición de http_port, y especifique:

# Default: http_port 3128 http_port 3128 http_port 8080

Si se desea incrementar la seguridad, puede vincularse el servicio a una IP que solo se pueda acceder desde la red local. Considerando que el servidor utilizado posee una IP 192.168.1.254, puede hacerse lo siguiente:

# Default: http_port 3128 http_port 192.168.1.254:3128 http_port 192.168.1.254:8080

• cache_mem

El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente:

• Objetos en tránsito. • Objetos Hot. • Objetos negativamente almacenados en el caché.



Los datos de estos objetos se almacenan en bloques de 4 Kb. El parámetro cache_mem especifica un límite máximo en el tamaño total de bloques acomodados, donde los objetos en tránsito tienen mayor prioridad. Sin embargo los objetos Hot y aquellos negativamente almacenados en el caché podrán utilizar la memoria no utilizada hasta que esta sea requerida. De ser necesario, si un objeto en tránsito es mayor a la cantidad de memoria especificada, Squid excederá lo que sea necesario para satisfacer la petición.

Por defecto se establecen 8 MB. Puede especificarse una cantidad mayor si así se considera necesario, dependiendo esto de los hábitos de los usuarios o necesidades establecidas por el administrador.

Si se posee un servidor con al menos 128 MB de RAM, establezca 16 MB como valor para este parámetro:

#Default: # cahe_mem 8 MB cache_mem 16 MB

• ftp_user

Al acceder a un servidor FTP de manera anónima, por defecto Squid enviará como contraseña Squid@. Si se desea que el acceso anónimo a los servidores FTP sea más informativo, o bien si se desea acceder a servidores FTP que validan la autenticidad de la dirección de correo especificada como contraseña, puede especificarse la dirección de correo electrónico que uno considere pertinente.

#Default: # ftp_user Squid@ ftp_user [email protected]

• cache_dir: ¿Cuanto se desea almacenar de Internet en el disco duro?

Este parámetro se utiliza para establecer que tamaño se desea que tenga el cache en el disco duro para Squid. Para entender esto un poco mejor, responda a esta pregunta: ¿Cuanto desea almacenar de Internet en el disco duro? Por defecto Squid utilizará un cache de 100 MB, de modo tal que encontrará la siguiente línea:

#Default: # cache_dir ufs /usr/local/squid/var/cache 100 16 256

Se puede incrementar el tamaño del cache hasta donde lo desee el administrador. Mientras más grande el cache, más objetos de almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. La siguiente línea establece un cache de 700 MB:

#Default: # cache_dir ufs /usr/local/squid/var/cache 100 16 256 cache_dir ufs /var/spool/squid 700 16 256

Los números 16 y 256 significan que el directorio del cache contendrá 16 subdirectorios con 256 niveles cada uno. No modifique esto números, no hay necesidad de hacerlo. Es muy importante considerar que si se especifica un determinado tamaño de cache y este excede al espacio real disponible en el disco duro, Squid se bloqueará inevitablemente. Sea cauteloso con el tamaño de cache especificado.



• Lista de Control de Acceso

Regularmente una lista de control de acceso se establece siguiendo la siguiente sintaxis:

acl [nombre de la lista] src [lo que compone a la lista] Si uno desea establecer una lista de control de acceso que defina sin mayor trabajo adicional a toda la red local definiendo la IP que corresponde a la red y la máscara de la sub-red. Por ejemplo, si se tienen una red donde las máquinas tienen direcciones IP 192.168.1.n con máscara de sub-red 255.255.255.0, podemos utilizar lo siguiente:

acl miredlocal src 192.168.1.0/255.255.255.0 También puede definirse una Lista de Control de Acceso invocando un fichero localizado en cualquier parte del disco duro, y en el cual se en cuenta una lista de direcciones IP. Ejemplo: acl permitidos src "/etc/squid/permitidos" El fichero /etc/squid/permitidos contendría algo como siguiente: • Reglas de Control de Acceso

Estas definen si se permite o no el acceso a Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda: La sintaxis básica es la siguiente:

http_access [deny o allow] [lista de control de acceso] En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos:

http_access allow permitidos También pueden definirse reglas valiéndose de la expresión !, la cual significa excepción. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2:

http_access allow lista1 !lista2

192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.15 192.168.1.16 192.168.1.20 192.168.1.40



Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso.

5. Estableciendo reglas de control de acceso. En nuestro caso, creamos una lista de tipo url_regex, para llamar la lista desde un archivo que contiene diferentes reglas aplicadas a sitios Web, como se muestra a continuación:

acl prohibidos url_regex "/usr/local/squid/prohibidos"

En nuestro ejemplo, tomamos tres casos, denegar por completo el acceso a un sitio Web, denegar el acceso a un sitio Web que contenga una palabra determinada, prohibir la posibilidad de bajar archivos con determinada extensión, como se muestra a continuación:

En el fichero creado, se esta negando el acceso a dos sitios Web, a sitios que contengan la palabra playboy y se prohíbe poder bajar los archivos con las extensiones indicadas. Después de haber creado el archivo, y agregado la lista de control de acceso, debemos agregar ahora, una regla de control de acceso que utilice esta lista, en el parámetro http_access como se muestra a continuación: # TAG: http_access # Allowing or Denying access based on defined access lists # # Access to the HTTP port: # http_access allow|deny [!]aclname ... # # NOTE on default values: # # If there are no "access" lines present, the default is to deny # the request. # # If none of the "access" lines cause a match, the default is the # opposite of the last line in the list. If the last line was # deny, then the default is allow. Conversely, if the last line # is allow, the default will be deny. For these reasons, it is a # good idea to have an "deny all" or "allow all" entry at the end # of your access lists to avoid potential confusion. # #Default: # http_access allow all http_access allow all !prohibidos La ultima línea quiere decir que estamos permitiendo el acceso a todos los sitios, menos aquellos que se encuentren en la lista prohibidos.

http://www.todito.com http://www.yahoo.com.mx playboy \.mp3$ \.zip$



Cada vez que efectuamos alguna configuración en squid.conf, es necesario reconfigurar squid para que tomen efecto todos las cambios hechos, una forma rápida de hacer esto, e de la forma siguiente:

[root@localhost sbin] # ./squid –k reconfigure ↵ [root@localhost sbin] # _ De esta manera, squid se reconfigure inmediatamente después de haber hecho cualquier modificación. Si queremos verificar que squid.conf no tenga ningún error sintáctico, solo tenemos que utilizar la instrucción ./squid –k parse y de esta forma saber si tenemos algún error en nuestra configuración.

Recordar también, que si se requiere volver a reconfigurar los dispositivos de red, es necesario reinicializar el servicio con el comando service network restart, para que las modificaciones tomen efecto. A continuación se muestran el uso completo del comando ./squid: Using: squid [-dhsvzCDFNRVYX][-fconfig-file][-[av]port] -a port specify HTTP port number(default: 3128). -d level Write debugger to stderr also. -f file Use given config-file instead of usr/local/squid/etc/squid.conf -h Print help message. -k reconfigure | rotate | shutdown | interrupt | kill | debug | check | parse

Parse configuration file, then send signal to running copy (except -k parse) end exit.

-s Enable logging to syslog. -u port Specify ICP port number(default: 3130), disable with 0. -v Print version. -z Create swap directories. -C Do not catch fatal signals. -D Disable initial DNS tests. -F Don’t serve any requests until store is rebuild. -N No domain mode. -R Do not set REUSE ADDR on port. -S Double-check swap during rebuild. -V Virtual host httpd-accelerator. -X Force full debugging. -Y Only UBP_HIT or UDP_MISS_NOFETCH during fase rebuild.

6. Comprobación del correcto funcionamiento del firewall(proxy server). Esta comprobación se llevara a cabo desde la PC en mi red privada, que contiene instalado Windows 2000. Primeramente es necesario configurar la tarjeta de red, para eso hacer lo siguiente:

• Hacer clic derecho sobre el icono My Network Places. • Seleccionar Properties. • Hacer clic derecho sobre el icono Local Area Connection. • Hacer doble clic sobre Internet Protocol(TCP/IP). • Escribir la información necesaria en la pantalla que aparece.



• Aceptar todos los cambios, y con esto la tarjeta de red se encuentra ahora configurada.

Finalmente, debemos configurar el explorador de Windows para que accese a internet pasando por un servidor proxy(nuestro firewall). Para hacer esto, seguir los siguientes pasos;

• Hacer clic derecho sobre el icono Internet Explorer. • Seleccionar Properties. • Seleccionar la ficha Connections. • Hacer clic sobre el boton LAN Settings.



• Marcar la casilla de verificación Use a proxy server for your LAN. Indicar la dirección IP inmediata de mi salida hacia la red exterior, que en este caso es mi gateway(dirección IP de la tarjeta eth1); además tenemos que indicar, el puerto que se utilizara como salida, en este caso es el puerto 3128, el cual es indicado por defecto en squid.conf.



Aceptar todas las modificaciones, y con esto Windows 2000 ya esta listo para acceder hacia la red externa utilizando el firewall instalado. A continuación, se probaran cada una de las restricciones indicadas en nuestra lista de control de accesos creada. Intentando acceder a http://www.yahoo.com, acceso denegado:

Intentando acceder a http://www.mp3downloads.com para bajar archivos mp3, acceso denegado:



Intentando bajar un archivo con extensión .zip, acceso negado:

Practica #5 “INSTALACIÓN DE UN FIREWALL EN...

Documents

Transcript of Practica #5 “INSTALACIÓN DE UN FIREWALL EN...