|
|
Atención: 20 al 24 de febrero, Curso Global de Servidores con CentOS 6. Atención: 21 y 28 de enero, 4 y 11 de febrero, Taller de programación de Python. Atención: Disponible ALDOS 1.4.2. Nuestro sistema operativo para escritorio. Configuración de Squid: Parámetros básicos.
Autor:dark Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com Sitio de Red: http://www.alcancelibre.org/ Jabber ID: darkshram@jabber.org Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1
Introducción.¿Qué es Servidor Intermediario (Proxy)?El término en ingles «Proxy» tiene un significado muy general y al mismo tiempo ambiguo, aunque invariablemente se considera un sinónimo del concepto de «Intermediario». Se suele traducir, en el sentido estricto, como delegado o apoderado (el que tiene el que poder sobre otro). Un Servidor Intermediario se define como una computadora o dispositivo que ofrece un servicio de red que consiste en permitir a los clientes realizar conexiones de red indirectas hacia otros servicios de red. Durante el proceso ocurre lo siguiente:
Los Servidores Proxy generalmente se hacen trabajar simultáneamente como muro cortafuegos operando en el Nivel de Red, actuando como filtro de paquetes, como en el caso de iptables, o bien operando en el Nivel de Aplicación, controlando diversos servicios, como es el caso de TCP Wrapper. Dependiendo del contexto, el muro cortafuegos también se conoce como BPD o Border Protection Device o simplemente filtro de paquetes. Una aplicación común de los Servidores Proxy es funcionar como caché de contenido de Red (principalmente HTTP), proporcionando en la proximidad de los clientes un caché de páginas y archivos disponibles a través de la Red en servidores HTTP remotos, permitiendo a los clientes de la red local acceder hacia éstos de forma más rápida y confiable. Cuando se recibe una petición para un recurso de Red especificado en un URL (Uniform Resource Locator) el Servidor Intermediario busca el resultado del URL dentro del caché. Si éste es encontrado, el Servidor Intermediario responde al cliente proporcionado inmediatamente el contenido solicitado. Si el contenido solicitado no estuviera disponible en el caché, el Servidor Intermediario lo traerá desde servidor remoto, entregándolo al cliente que lo solicitó y guardando una copia en el caché. El contenido en el caché es eliminado luego a través de un algoritmo de expiración de acuerdo a la antigüedad, tamaño e historial de respuestas a solicitudes (hits) (ejemplos: LRU, LFUDA y GDSF). Los Servidores Proxy para contenido de Red (Web Proxies) también pueden actuar como filtros del contenido servido, aplicando políticas de censura de acuerdo a criterios arbitrarios. Acerca de Squid.Squid es un Servidor Intermediario de alto desempeño que se ha venido desarrollando desde hace varios años y es hoy en día un muy popular y ampliamente utilizado entre los sistemas operativos como GNU/Linux y derivados de Unix®. Es muy confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública General GNU (GNU/GPL). Siendo equipamiento lógico libre, está disponible el código fuente para quien así lo requiera. Entre otras cosas, Squid puede funcionar como Servidor Intermediario y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, WWCP, aceleración HTTP, caché de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario. Squid consiste de un programa principal como servidor, un programa para búsqueda en servidores DNS, programas opcionales para reescribir solicitudes y realizar autenticación y algunas herramientas para administración y y herramientas para clientes. Al iniciar Squid da origen a un número configurable (5, de modo predefinido a través del parámetro dns_children) de procesos de búsqueda en servidores DNS, cada uno de los cuales realiza una búsqueda única en servidores DNS, reduciendo la cantidad de tiempo de espera para las búsquedas en servidores DNS.
URL: http://www.squid-cache.org/ Algoritmos de caché utilizados por Squid.A través de un parámetro (cache_replacement_policy) Squid incluye soporte para los siguientes algoritmos para el caché:
Equipamiento lógico necesario.Para poder llevar al cabo los procedimientos descritos en este y otros documentos relacionados, usted necesitará tener instalado al menos lo siguiente:
Debe tomarse en consideración que, de ser posible, se debe utilizar siempre las versiones estables más recientes de todo equipamiento lógico que vaya a ser instalado para realizar los procedimientos descritos en este manual, a fin de contar con los parches de seguridad necesarios. Ninguna versión de Squid anterior a la 2.5.STABLE6 se considera como apropiada debido a fallas de seguridad de gran importancia. Squid no se instala de manera predeterminada a menos que especifique lo contrario durante la instalación del sistema operativo, sin embargo viene incluido en casi todas las distribuciones actuales. El procedimiento de instalación es exactamente el mismo que con cualquier otro equipamiento lógico. Instalación a través de yum.Si cuenta con un sistema con CentOS o White Box Enterprise Linux 3 o versiones posteriores, ejecute lo siguiente y se instalará todo lo necesario junto con sus dependencias:
SELinux y el servicio squid.A fin de que SELinux permita al servicio squid que los clientes se conecten desde cualquier dirección IP, ejecutar lo siguiente.
Antes de continuar.Evite dejar espacios vacíos en lugares indebidos. El siguiente ejemplo muestra la manera incorrecta de habilitar un parámetro. Mal
El siguiente ejemplo muestra la manera correcta de habilitar un parámetro. Bien
Configuración básica.Squid utiliza el archivo de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes:
El resto de los parámetros, mencionados en este documento, son opcionales. Controles de acceso.Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas y otras. Listas de control de acceso.De modo predeterminado en CentOS 6, y Red Hat Enterprise Linux 6, Squid habilita el acceso a todas las redes locales, definidas en el RFC1918. Es decir, permite el acceso a 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7, y fe80::/10.
Deshabilite todo lo anterior, colocando una almoadilla (# al inicio de cada línea.
Regularmente una lista de control de acceso se establece con la siguiente sintaxis:
Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se tiene una red donde las máquinas tienen direcciones IP 192.168.70.n con máscara de sub-red de 24 bit, podemos utilizar lo siguiente:
También puede definirse una Lista de Control de Acceso especificando un archivo localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones IP. Ejemplo:
El archivo /etc/squid/listas/permitidos tendría un contenido simiular al siguiente:
Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el archivo /etc/squid/listas/permitidos. Reglas de Control de Acceso.Estas definen si se permite o no el acceso hacia 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 de una regla de control de acceso es la siguiente:
En el siguiente ejemplo se considera una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos:
También pueden definirse reglas valiéndose de la expresión !, la cual significa no. 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:
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. Aplicando Listas y Reglas de control de acceso.Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso, procederemos a determinar cuales utilizar para nuestra configuración. Caso 1.Considerando como ejemplo que se dispone de una red 192.168.70.0/24, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo: Listas de Control de Acceso: definición de una red local completa
A continuación procedemos a aplicar la regla de control de acceso:
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar de modo similar al siguiente: Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
La regla http_access allow localnet permite el acceso a Squid a la Lista de Control de Acceso denominada localnet, la cual está conformada por 192.168.70.0/24. Esto significa que cualquier máquina desde 192.168.70.1 hasta 192.168.70.254 podrá acceder a Squid. Caso 2.Si sólo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un archivo que contenga dicha lista. Genere el archivo /etc/squid/listas/localnet, dentro del cual se incluirán sólo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:
Denominaremos a esta lista de control de acceso como localnet:
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo: Listas de Control de Acceso: definición de una red local completa
A continuación procedemos a aplicar la regla de control de acceso:
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar de modo similar al siguiente: Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
La regla http_access allow localnet permite el acceso a Squid a la Lista de Control de Acceso denominada localnet, la cual está conformada por las direcciones IP especificadas en el archivo /etc/squid/listas/localnet. Esto significa que cualquier máquina no incluida en /etc/squid/listas/localnet no tendrá acceso a Squid. Parámetro cache_mgr.Este parámetro es de carácter informativo. De modo predefinido, si algo ocurre con el caché, como por ejemplo que muera el procesos, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.
Parámetro http_port.Este parámetro es utilizado para indicar el puerto a través del cual escuchará peticiones Squid. EL valor predeterminado es 3128, es deicr, Squid escuchará peticiones a través del puerto 3128/tcp.
El puerto estándar designado para servidores de caché de Internet (webcache) es el puerto 8080.
El parámetro permite establecer también si se quiere utilizar una dirección IP en particular. Esto añade mayor seguridad al servicio, pues si se tiene dos tarjetas de red, una con una dirección IP pública, y otra con una dirección IP privada, se puede establecer que Squid solo permita conexiones desde la dirección IP privada.
Si se necesita configurar un servidor proxy en modo transparente, solo es necesario añadir la opción intercept, misma que desde la versión 3.1 de Squid reemplaza a la opción transparent.
Parámetro cache_dir.Este parámetro se utiliza para establecer que tamaño se desea que utilice Squid para almacenamiento de caché en el disco duro. De modo predefinido Squid utilizará un caché de 100 MB, dividido en jerarquías de 16 directorios subordinados, hasta 256 niveles cada uno:
Se puede incrementar el tamaño del caché hasta donde lo desee el administrador. Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se consumirá menos el ancho de banda. La siguiente línea establece un caché de 2 GB:
Parámetro cache_mem.El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente:
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 frecuentemente utilizados (Hot), y aquellos negativamente almacenados en el caché, podrán utilizar la memoria sin utilizar 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. De modo predeterminado, desde la versión 3.1 de Squid, se establecen 256 MB, que es más que suficiente para el 99% de las necesidades. Si se dispone de cantidad suficiente de RAM en el servidor (al menos 2 GB RAM), puede especificarse una cantidad mayor, o bien, si se dispone de una cantidad menor de RAM en el servidor (menos de 1 GB RAM), puede especificar una cantidad menor.
Parámetro cache_peer: caches padres y hermanos.El parámetro cache_peer se utiliza para especificar otros Servidores Proxy con caché en una jerarquía como padres o como hermanos. Es decir, definir si hay un Servidor Intermediario adelante o en paralelo. La sintaxis básica es la siguiente:
Ejemplo: Si su caché va a estar trabajando detrás de otro servidor cache, es decir un caché padre, y considerando que el caché padre tiene una IP 192.168.70.1, escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130 (puerto utilizado de modo predefinido por Squid) ,especificando que no se almacenen en caché los objetos que ya están presentes en el caché del Servidor Intermediario padre, utilice la siguiente línea:
Cuando se trabaja en redes muy grandes donde existen varios Servidores Intermediarios (Proxy) haciendo caché de contenido de Internet, es una buena idea hacer trabajar todos los caché entre si. Configurar caches vecinos como sibling (hermanos) tiene como beneficio el que se consultarán estos caches localizados en la red local antes de acceder hacia Internet y consumir ancho de banda para acceder hacia un objeto que ya podría estar presente en otro caché vecino. Ejemplo: Si su caché va a estar trabajando en paralelo junto con otros caches, es decir caches hermanos, y considerando los caches tienen IP 10.1.0.1, 10.2.0.1 y 10.3.0.1, todos escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130, especificando que no se almacenen en caché los objetos que ya están presentes en los caches hermanos, utilice las siguientes líneas:
Pueden hacerse combinaciones que de manera tal que se podrían tener caches padres y hermanos trabajando en conjunto en una red local. Ejemplo:
En los casos anteriores, la resolución de nombres se hace de manera local. Si se desea hacer que la resolución de nombres se realice en el servidor padre, se puede utilizar algo similar a lo siguiente:
Estableciendo el idioma de los mensajes mostrados por de Squid hacia el usuario.Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado durante su operación. Dichas traducciones se pueden encontrar en /usr/share/squid/errors/. Para poder hacer uso de las páginas de error traducidas al español, sólo es necesario cambiar el valor del parámetro error_directory de /usr/share/squid/errors/en, a /usr/share/squid/errors/es.
Iniciando, reiniciando y añadiendo el servicio al arranque del sistema.Una vez terminada la configuración, ejecute el siguiente mandato para iniciar por primera vez Squid:
Si necesita volver a cargar la configuración para probar cambios realizados, sin detener el servicio, ejecute lo siguiente:
Si necesita reiniciar para probar cambios hechos en la configuración, considerando que este proceso puede llegar a demorar algunos minutos, ejecute lo siguiente:
Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, ejecute lo siguiente:
Lo anterior habilitará a Squid en todos los niveles de ejecución. Depuración de erroresCualquier error al inicio de Squid sólo significa que hubo errores de sintaxis, errores de dedo o bien se están citando incorrectamente las rutas hacia los archivos de las Listas de Control de Acceso. Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer configuración, lo cual devolverá los errores que existan en el archivo /etc/squid/squid.conf.
Cuando se trata de errores graves que no permiten iniciar el servicio, puede examinarse el contenido del archivo /var/log/squid/squid.out con el mandato less, more o cualquier otro visor de texto:
Ajustes para el muro corta-fuegos.Si se tiene poca experiencia con guiones de cortafuegos a través de iptables, sugerimos utilizar Firestarter. éste permite configurar fácilmente tanto el enmascaramiento de IP como el muro corta-fuegos. Si se tiene un poco más de experiencia, recomendamos utilizar Shorewall para el mismo fin puesto que se trata de una herramienta más robusta y completa.
Re-direccionamiento de peticiones a través de iptables.En un momento dado se requerirá tener salida transparente hacia Internet para ciertos servicios, pero al mismo tiempo se necesitará re-direccionar peticiones hacia servicio HTTP para pasar a través del el puerto donde escucha peticiones Squid, como proxy transparente, es decir el puerto 8000/tcp, de modo que no haya salida alguna hacia alguna hacia servidores HTTP en el exterior sin que ésta pase antes por Squid. No se puede hacer Servidor Intermediario Transparente para los protocolos HTTPS, FTP, GOPHER ni WAIS, por lo que dichos protocolos tendrán que ser filtrados a través del NAT. El re-direccionamiento se hace a través de iptables. Considerando para este ejemplo que la red local se accede a través de una interfaz eth0, el siguiente esquema ejemplifica un re-direccionamiento:
Lo anterior requiere un guión de cortafuegos funcional en un sistema con dos interfaces de red. Se encarga de que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-direccionará hacia el puerto 8000 del servidor. Utilizando Firestarter, la regla anteriormente descrita se añade en el archivo /etc/firestarter/user-post. Re-direccionamiento de peticiones a través de la opción REDIRECT en Shorewall.La acción REDIRECT en Shorewall permite redirigir peticiones hacia protocolo HTTP para hacerlas pasar a través de Squid. En el siguiente ejemplo las peticiones hechas desde la zona que corresponde a la red local serán redirigidas hacia el puerto 8000 del cortafuegos, en donde está configurado Squid configurado como Servidor Proxy (Proxy) transparente.
Exclusión de sitios.En el caso de sitios que se quiera excluir de ser utilizados con Squid, es decir, sitios problemáticos, se puede configurar en Shorewall que el acceso sea directo, con una configuración similar a la del siguiente ejemplo, donde se excluye de pasar por Squid las peticiones dirigidas a las redes 201.144.108.0/24 (IMSS.gob.mx), y 200.33.74.0/24 (SAT.gob.mx), y se abre el paso directo desde la red local hacia esta red:
Última Edición 29/09/2011, 13:41|235,882 Accesos |
Comentarios Recientes