squid_lpt

Cómo configurar Squid

Autor: Joel Barrios DueñasCorreo electrónico: jbarrios arroba linuxparatodos punto netSitio Web: http://www.linuxparatodos.net/Jabber ID: darkshram@jabber.org

Usted puede contribuir financiando la elaboración de más documentos como éste haciendo aportaciones voluntarias y anónimas en:Bital, Banco Internacional, S.A. (México) Cuenta: 4007112287, Sucursal 0643A nombre de: Joel Barrios Dueñas.

Copyright.

© 1999, © 2000, © 2001, © 2002 y © 2003 Linux Para Todos. Se permite la libre distribución y modificación de este documento por cualquier medio y formato mientras esta leyenda permanezca intacta junto con el documento y la distribución y modificación se hagan de de acuerdo con los términos de la Licencia Pública General GNU publicada por la Free Software Foundation; sea la versión 2 de la licencia o (a su elección) cualquier otra posterior. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

1.- Parámetros básicos para servidor Proxy.

Introducción.

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.

Entre otras cosas, Squid puede hacer Proxy y cache con los protocolos HTTP, FTP, GOPHERy WAIS, Proxy de SSL, cache transparente, WWCP, aceleración HTTP, cache de consultas DNSy otras muchas más como filtración de contenido y control de acceso por IP y por usuario. NOTA ESPECIAL: Squid no puede funcionar como proxy para servicios como SMTP, POP3, TELNET, SSH, etc. Si se requiere hacer proxy para cualquier cosa distinta a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá o bien implementar enmascaramiento de IP a través de un NAT(Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante.

Software requerido.

Para poder llevar la cabo los procedimientos descritos en este manual y documentos relacionados, usted necesitará

tener instalado al menos lo siguiente:• squid-2.5.STABLE1• httpd-2.0.x (Apache)•

Todos los parches de seguridad disponibles para la versión de Red Hat™ que esté utilizando. Tómese en consideración

que, de ser posible, se debe utilizar siempre las versiones estables más recientes de todo el software que vaya a

instalar al 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.STABLE1 se considera como apropiada debido a fallas de seguridad de gran

importancia, y ningún administrador competente utilizaría una versión inferior a la 2.5.STABLE1. Por favor visite el sito Web de su distribución predilecta para estar al tanto de cualquier aviso de actualizaciones de seguridad.

Para Red Hat™ Linux 9 hay paquetería de actualización en los siguientes enlaces:• ftp://updates.redhat.com/9/en/os/i386/, si posee alguna distribución basada sobre Red Hat™ Linux9

Instalación del software necesario.

Regularmente Squid no se instala de manera predeterminada a menos que especifique o 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 software:

mount /mnt/cdrom/rpm -Uvh /mnt/cdrom/*/RPMS/squid-*.i386.rpm eject

Si utiliza Fedora™ Core, ejecute lo siguiente y se instalará todo lo necesario junto con sus dependencias:

yum install squid httpd

Iptables se utilizará para generar las reglas necesarias para el guión de Enmascaramiento de IP. Se instala por defecto en todas las distribuciones actuales que utilicen kernel-2.4.

Es importante tener actualizado el kernel por diversas cuestiones de seguridad. No es recomendable utilizar versiones del kernel anteriores a la 2.4.20. En el manual "Cómo actualizar el Kernel a partir de paquetes RPM®" se describe a detalle lo necesario.

Antes de continuar

Tenga en cuenta que este manual ha sido comprobado varias veces y ha funcionado en todos los casos y si algo no funciona solo significa que usted no lo leyó a detalle y no siguió correctamente las indicaciones.

Evite dejar espacios vacíos en lugares indebidos. El siguiente es un ejemplo de como no debe des- comentarse un parámetro.

# Opción incorrectamente des-comentada http_port 3128

El siguiente es un ejemplo de como si debe des-comentarse un parámetro.Bien

# Opción correctamente des-comentada http_port 3128

Configuración básica.

Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto preferido. Existen un gran número de parámetros, de los cuales recomendamos 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• httpd_accel_host• httpd_accel_port• httpd_accel_with_proxy

Parámetro http_port: ¿Que 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 Web para utilizar el servidor Proxy. bastará con utilizar como puerta de enlace al servidor. Es importante recordar que los servidores Web, 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:

## You may specify multiple socket addresses on multiple lines.## Default: http_port 3128http_port 3128http_port 8080

Si 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 IP192.168.1.254, puede hacerse lo siguiente:

## You may specify multiple socket addresses on multiple lines.## Default: http_port 3128http_port 192.168.1.254:3128

http_port 192.168.1.254:8080

Parámetro 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:

cache_mem 16 MB

Parámetro cache_dir: ¿Cuanto 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:

cache_dir ufs /var/spool/squid 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:

Los números 16 y 256 significan que el directorio del cache contendrá 16 subdirectorios con 256niveles 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.

Parámetro ftp_user

Al acceder a un servidor FTP de manera anónima, por defecto Squid enviará como contraseñaSquid@. 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.

ftp_user proxy@su-dominio.net

Controles de acceso.

Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas maquinas 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.

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-red255.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:

192.168.1.1192.168.1.2192.168.1.3192.168.1.15192.168.1.16192.168.1.20192.168.1.40

Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el fichero /etc/squid/permitidos.

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:

## INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS#

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 Accesodenominada 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 comprendalista1 excepto aquello que comprenda lista2:

http_access allow lista1 !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.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:

acl todalared src 192.168.1.0/255.255.255.0

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

## Recommended minimum configuration:acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl todalared src 192.168.1.0/255.255.255.0

A continuación procedemos a aplicar la regla de control de acceso:

http_access allow todalared

Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de

este modo:

Reglas de control de acceso: Acceso a una Lista de Control de Acceso.

http_access allow localhost http_access allow todalared http_access deny all

La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada todalared, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid.

Caso 2

Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga dicha lista. Genere el fichero /etc/squid/lista, dentro del cual se incluirán solo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:

192.168.1.1192.168.1.2192.168.1.3192.168.1.15192.168.1.16192.168.1.20192.168.1.40

Denominaremos a esta lista de control de acceso como redlocal:

acl redlocal src "/etc/squid/lista"

## Recommended minimum configuration:acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl redlocal src "/etc/squid/lista"

http_access allow redlocal

Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:

http_access allow localhost http_access allow redlocal http_access deny all

La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal, la cual está conformada por las direcciones IP especificadas en el fichero / etc/squid/lista. esto significa que cualquier máquina no incluida en /etc/squid/lista no tendrá acceso a Squid.

Parámetro cache_mgr.

Por defecto, si algo ocurre con el Cache, como por ejemplo que muera el procesos, se enviará un mensaje de aviso a la cuentawebmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.

cache_mgr joseperez@midominio.net

Parámetro cache_peer: caches padres y hermanos.

El parámetro cache_peer se utiliza para especificar otros proxy-cache en una jerarquía como padres o como hermanos. es decir, definir si hay un proxy adelante o en parelelo. La síntaxis básica es la siguiente:

cache_peer servidor tipo http_port icp_port opciones

Ejemplo: Si su cache va a estar trabajando detrás de otro servidor cache, es decir un cache padre, y considerando que el cache padre tiene una IP 192.168.1.1, escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130 (puerto utilizado por defecto por Squid),especificando que no se almacenen en cache los objetos que ya están presentes en el cache del proxy padre, utilice la siguiente línea:

cache_peer 192.168.1.1 parent 8080 3130 proxy-only

Cuando se trabaja en redes muy grandes donde existen varios servidores proxy haciendo cache de contenido de Internet, es una buena idea hacer trabajar todos los cache entre si. Configurar caches vecinos como sibbling (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 cache vecino.

Ejemplo: Si su cache 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 cache los objetos que ya están presentes en los caches hermanos, utilice las siguientes líneas:

cache_peer 10.1.0.1 sibbling 8080 3130 proxy-only cache_peer 10.2.0.1 sibbling 8080 3130 proxy-only cache_peer 10.3.0.1 sibbling 8080 3130 proxy-only

Pueden hacerse combinaciones que de manera tal que se podrían tener caches padres y hermanos trabajando en conjunto en una red local. Ejemplo:

cache_peer 10.0.0.1 parent 8080 3130 proxy-only cache_peer 10.1.0.1 sibbling 8080 3130 proxy-only cache_peer 10.2.0.1 sibbling 8080 3130 proxy-only cache_peer 10.3.0.1 sibbling 8080 3130 proxy-only

Cache con aceleración.

Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el cache de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el que ya se encuentra en el cache en lugar de volver a descargarlo desde Internet.

Esta función permite navegar rápidamente cuando los objetos ya están en el cache de Squid y además optimiza enormemente la utilización del ancho de banda.

En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros:

Proxy Acelerado: Opciones para Proxy Convencional.

httpd_accel_host virtual httpd_accel_port 0 httpd_accel_with_proxy on

Si se trata de un Proxy transparente deben utilizarse con las siguientes opciones, considerando que se hará uso del cache de un servidor web (Apache) como auxiliar:

Proxy Acelerado: Opciones para Proxy Transparente.

# Debe especificarse la IP de cualquier servidor Web en la red local# o bien el valor virtual httpd_accel_host 192.168.1.254 httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on

Nota acerca de Internet Explorer 5.5 y versiones anteriores

Si va a utilizar Internet Explorer 5.5 y versiones anteriores con un proxy transparente, es importante recuerde que dichas versiones tiene un pésimo soporte con los proxies transparentes imposibilitando por completo la capacidad de refrescar contenido. Lo más conveniente es actualizar hacia Internet Explorer 6.x o defintivamente optar por otras alternativas comoMozilla, que consiste en una suite completa de aplicaciones para Internet, o bien

Mozilla Firebird, que consiste en un navegador muy ligero y que cumple con los estándares, de las cuales encontrará versión para Windows. Si se utiliza el parámetro ie_refresh con valor on puede hacer que se verifique en los servidores de origen para nuevo contenido para todas las peticiones IMS- REFRESH provenientes de Internet Explorer 5.5 y versiones anteriores.

Proxy Acelerado: Opciones para Proxy Transparente para redes con Internet

Exlorer 5.5 y versiones anteriores.

# Debe especificarse la IP de cualquier servidor Web en la red local# o bien virtual httpd_accel_host 192.168.1.254 httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on ie_refresh on

La configuración de Squid como proxy transparente solo requiere complementarse utilizando una regla de iptables que se encargará de redireccionar peticiones haciéndolas pasar por el puerto8080.

Proxy Acelerado: Regla de iptables.

# Considerando que la red local accede a través de eth0 y que Squid# escucha peticiones en puerto 8080, se utiliza la siguiente línea:

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT--to-port 8080

Por defecto el parámetro httpd_accel_with_proxy viene con el valor off, es importante no olvidar cambiar este valor por on.

Estableciendo el idioma por defecto.

Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado. Dichas traducciones se pueden encontrar en / usr/lib/squid/errors/. Para poder hacer uso de las páginas de error traducidas al español, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte hacia /usr/lib/squid/errors/Spanish en lugar de hacerlo hacia /usr/lib/squid/errors/English.

Elimine primero el enlace simbólico actual:

rm -f /etc/squid/errors

Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al español.

Red Hat™ Linux 7.x y 8.0

ln -s /usr/lib/squid/errors/Spanish /etc/squid/errors

Red Hat™ Linux 9 y Fedora™ Core 1

ln -s /usr/share/squid/errors/Spanish /etc/squid/errors

Iniciando, reiniciando y añadiendo el servicio al

arranque del sistema.

Una vez terminada la configuración, ejecute el siguiente comando para iniciar por primera vez Squid:

service squid start

Si necesita reiniciar para probar cambios hechos en la configuración, ejecute lo siguiente:

service squid restart

Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, ejecute lo siguiente:

/sbin/chkconfig squid on

Lo anterior habilitará a Squid en los niveles de corrida 3, 4 y 5.

Nota para los novatos: Usted NO tiene porque editar cosa alguna en /etc/rc.d/rc.local o /etc/inittab para queSquid -así como cualquier otro servicio- inicie en el arranque del sistema. Mientras usted sea novato, por favor, olvide que existen esos ficheros y exclame una fuerte amenaza y alejese de quien le indique que desde ahí debe arrancar servicios.

Depuración de errores

Cualquier error al inicio de squid solo significa que hubo errores de síntaxis, errores de dedo o bien se están

citando incorrectamente las rutas hacia los ficheros de las Listas de Control de Acceso.

Puede realizar disgnóstico de problemas indicandole a Squid que vuelva a leer configuración, lo cual devolvera los errores que existan en /etc/squid/squid.conf.

service squid reload

También puede iniciar Squid directamente desde la líena de comando especicicando el modo de depuración:

squid -d 5

Ajustes para el muro contrafuegos o guión de

Enmascaramiento de IP.

A continuación comentaremos algunos ajustes que pueden añadirse o editarse en el guión de el muro contrafuegos, como el generado por herramientas como Firestarer, o bien un simple guión de Enmascaramiento de IP.

Sugerimos utilizar Firestarer debido a que permite configurar tanto el enmascaramiento de IP como el muro

contrafuegos y la importancia que tiene la presencia de éste último en un servidor que sirve como puerta de enlace para la red local.

Use Iptables en lugar de ipchains.

Desde el kernel 2.4, GNU/Linux utiliza Netfilter, el cual se configura a través de iptables. La sintaxis cambia con respecto a ipchains, y a fin de permitir a los administradores darse tiempo de adaptarse, distribuciones como Red Hat™ ™ incluyeron soporte para ipchains a manera de aplicación de legado.

Pudiendo utilizarse iptables no tiene sentido mantener instalado ipchains, que aún es utilizado por defecto en Red Hat™ Linux ™ 7.1 y 7.2. Se recomienda desinstalar ipchains y los paquetes que dependan de este.

Es importante utilizar la más reciente versión de iptables para la distribución utilizada. Ninguna versión de iptables anterior a la 1.2.4 se considera como apropiada debido a fallas de seguridad de gran importancia, y ningún administrador competente utilizaría una versión inferior a la 1.2.4. Por favor visite el sito Web de su distribución predilecta para estar al tanto de cualquier aviso de actualizaciones de seguridad. Ejemplo: para Red Hat™ Linux 7.2, 7.3. 8.0 y 9 hay paquetería de actualización en los siguientes enlaces:

• ftp://updates.redhat.com/7.2/en/os/i386/, si posee alguna distribución basada sobre Red Hat™ Linux 7.2

• ftp://updates.redhat.com/9/en/os/i386/, si posee alguna distribución basada sobre Red Hat™ Linux9

Antes de desinstalar ipchains, que se instala de modo pre-determinado en Red Hat™ Linux 7.x, primero debe eliminarse cualquier regla que pudiese existir.

/sbin/ipchains -X/sbin/ipchains -F/sbin/ipchains -Z

A continuación debe removerse el módulo de ipchains para permitir la carga del módulo ip_tables.

/sbin/rmmod ipchains/sbin/modprobe ip_tables

Para terminar, si utiliza Red Hat™ Linux 7.2 y 7.3, se debe desinstalar ipchains y toda la paquetería que dependa de éste.

rpm -e ipchains lokkit gnome-lokkit firewall-config

Esto ajustes deben poder permitir utilizar iptables en lugar de ipchains sin mayor problema.

Re-direccionamiento de peticiones.

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 Web, Web SSL, ftp, gopher o WAIS hacia el el puerto donde escucha peticiones Squid (8080), de modo que no haya salida alguna hacia alguno de estos protocolos sin que ésta pase antes por Squid.

El re-direccionamiento lo hacemos a través de iptables. Considerando para este ejemplo que la red

local se accede a través de una interfaz eht0, el siguiente esquema ejemplifica un re- direccionamiento:

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT--to-port 8080

Lo anterior hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-direccionará hacia el puerto 8080 del servidor.

Guión ejemplo de Enmascaramiento de IP con iptables.

El guión que mostramos en la tabla a continuación considera que se dispone de dos interfaces: eth0 y eth1. Para nuestro ejemplo la red local se accede por la interfaz eth0 y la salida hacia Internet de hace por la interfaz eth1. Utilice Firestarer para configurar el enmascaramiento y muro contrafuegos siempre que sea posible. Este guión NO es sustituto para un guión de muro corta-fuegos.

Guión básico de Enmascaramiento de IP.

#!/bin/sh

# cargamos los módulos del kernel necesarios:/sbin/modprobe ip_conntrack/sbin/modprobe ip_conntrack_ftp/sbin/modprobe ip_conntrack_irc/sbin/modprobe ipt_REJECT/sbin/modprobe ipt_REDIRECT/sbin/modprobe ipt_TOS/sbin/modprobe ipt_MASQUERADE/sbin/modprobe ipt_LOG/sbin/modprobe iptable_mangle/sbin/modprobe iptable_nat/sbin/modprobe ip_nat_ftp/sbin/modprobe ip_nat_irc

# Habilitamos el reenvío de direcciones IPif [ -e /proc/sys/net/ipv4/ip_forward ]; then echo 0 > /proc/sys/net/ipv4/ip_forwardfi

# Estableciendo política de reenvío del enmascaramiento/sbin/iptables -t filter -P FORWARD DROP

# Reenvío de trafico intento-externo y externo-interno/sbin/iptables -t filter -A FORWARD -d 0/0 -s 192.168.1.0/255.255.255.0-o eth0 -j ACCEPT

/sbin/iptables -t filter -A FORWARD -d 192.168.1.0/255.255.255.0 -jACCEPT

# Enmascaramiento de todo el trafico saliente# NOTA: recordemos que la salida hacia Internet es por# la interfaz eth0

/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

# No enmascararemos tráfico externo/sbin/iptables -t nat -A POSTROUTING -o eth1 -d 0/0 -j ACCEPT

# Permitir al tráfico de la red interna ir a donde sea/sbin/iptables -t filter -A INPUT -s 192.168.1.0/255.255.255.0 -d 0/0 -jACCEPT

/sbin/iptables -t filter -A OUTPUT -s 192.168.1.0/255.255.255.0 -d 0/0 -jACCEPT

/sbin/iptables -t filter -A OUTPUT -p icmp -s 192.168.1.0/255.255.255.0-d 0/0 -j ACCEPT

# Re-direccionamiento hacia el puerto 8080 (donde Squid escucha# peticiones) para cualquier petición originada desde la red# local hacia servicios que utilicen protocolo http, https y ftp# Pueden añadirse más re-direccionamientos a discreción del# administrador.# NOTA 1: recordemos que la red local se accede con la interfaz eth0

# HTTP/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT--to-port 8080

2.- Acceso por Autenticación.

Introducción.

Es muy útil el poder establecer un sistema de autenticación para poder acceder hacia Internet, pues esto permite controlar quienes si y quienes no accederán a Internet sin importar desde que máquina de la red local lo hagan. Sera de modo tal que tendremos un doble control, primero por dirección IP y segundo por nombre de usuario y clave de acceso.

Para tal fin nos valdremos de un programa externo para autenticar, como es ncsa_auth, de la NCSA(National Center for Supercomputing Applications), y que ya viene incluido como parte del paquete principal de Squid en la mayoría de las distribuciones actuales.

Este manual considera que usted ya ha leído previamente, a detalle y en su totalidad el manual"Como configurar Squid: Servidor Proxy" y que ha configurado exitosamente Squid como servidor proxy.

Software requerido.

Para poder llevar la cabo los procedimientos descritos en este manual y documentos relacionados, usted necesitará tener instalado al menos lo siguiente:• squid-2.5.STABLE1• httpd-2.0.x (Apache)

Procedimientos

Creación del fichero de claves de acceso.

Se requerirá la creación previa de un fichero que contendrá los nombres de usuarios y sus correspondientes claves de acceso (cifradas). El fichero puede localizarse en cualquier lugar del

sistema, con la única condición que sea asequible para el usuario squid.

Debe procederse a crear un fichero /etc/squid/claves:

touch /etc/squid/claves

Salvo que vaya a utilizarse un guión a través del servidor web para administrar las claves de acceso, como medida de seguridad, este fichero debe hacerse leíble y escribible solo para el usuario squid:

chmod 600 /etc/squid/claveschown squid:squid /etc/squid/claves

A continuación deberemos dar de alta las cuentas que sean necesarias, utilizando el comandohtpasswd -mismo que viene incluido en el paquete httpd-2.0.x-. Ejemplo:

htpasswd /etc/squid/claves joseperez

Lo anterior solicitará teclear una nueva clave de acceso para el usuario joseperez y confirmar tecleando ésta de nuevo. Repita con el resto de las cuentas que requiera dar de alta.

Todas las cuentas que se den de alta de este modo son independientes a las ya existentes en el sistema. Al dar de alta una cuenta o cambiar una clave de acceso lo estará haciendo EXCLUSIVAMENTE para el acceso al servidor Proxy. Las cuentas son independientes a las que se tengan existentes en el sistema como serían shell, correo y Samba.

Parámetros en /etc/squid/squid.conf

Lo primero será especificar que programa de autenticación se utilizará. Localice la sección que corresponde a la etiqueta auth_param basic program. Por defecto no está especificado programa alguno. Considerando que ncsa_auth se localiza en /usr/lib/squid/ncsa_auth, procederemos a añadir el siguiente parámetro:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/claves

Nota importante: Si usted está utilizando software obsoleto como Squid-2.4STABLE y versiones anteriores, que es utilizado en distribuciones obsoletas como Red Hat™ Linux 7.x y 8.0, Yellow Dog™ Linux 2.x, Mandrake Linux 8.x y 9.0, etc., es importante saber que para definir el programa de autenticación se utiliza otro parámetro muy distinto:authenticate_program /usr/lib/squid/ncsa_auth /etc/squid/claves

/usr/lib/squid/ncsa_auth corresponde a la localización de el programa para autenticar y /etc/squid/claves al fichero que contiene las cuentas y sus claves de acceso.

El siguiente paso corresponde a la definición de una Lista de Control de Acceso. Especificaremos una denominada passwd la cual se configurará para utilizar obligatoriamente la autenticación para poder acceder a Squid. Debe localizarse la sección de Listas de Control de Acceso y añadirse la

siguiente línea:

acl password proxy_auth REQUIRED

Habiendo hecho lo anterior, deberemos tener en la sección de Listas de Control de Acceso algo como lo siguiente:Listas de Control de Accesos: autenticación.

## Recommended minimum configuration:

acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255 acl redlocal src 192.168.1.0/255.255.255.0 acl password proxy_auth REQUIRED

Procedemos entonces a modificar la regla de control de accesos que ya teníamos para permitir el acceso a Internet. Donde antes teníamos lo siguiente:

Le añadimos passwd, la definición de la Lista de Control de Acceso que requiere utilizar clave de acceso, a nuestra regla actual, de modo que quede como mostramos a continuación:

http_access allow redlocal password

Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:Reglas de control de acceso: Acceso por clave de acceso.

## INSERT YOUR OWN RULE(S) HERE TO allow ACCESS FROM YOUR CLIENTS#http_access allow localhost http_access allow redlocal password http_access deny all

Finalizando procedimiento.

Finalmente, solo bastará reiniciar Squid para que tomen efecto los cambios y podamos hacer pruebas.

3.- Restricción de acceso a sitios Web.

Introducción.

Denegar el acceso a ciertos sitos Web permite hacer un uso más racional del ancho de banda con el que se dispone. El funcionamiento es verdaderamente simple, y consiste en denegar el acceso a nombres de dominio o direcciones Web que contengan patrones en común.

Software requerido.

Para poder llevar la cabo los procedimientos descritos en este manual y documentos relacionados, usted necesitará tener instalado al menos squid-2.5STABLE1.

Definiendo patrones comunes.

Lo primero será generar una lista la cual contendrá direcciones Web y palabras usualmente utilizadas en nombres de ciertos dominios. Ejemplos:

www.sitioporno.com www.otrositioporno.com sitioindeseable.com otrositioindeseable.com napstersex porn mp3 xxx adult warezcelebri

Esta lista, la cual deberá ser completada con todas las palabras (muchas de está son palabras obscenas en distintos idiomas) y direcciones Web que el administrador considere pertinentes, la guardaremos como /etc/squid/sitiosdenegados.

Debemos definir una Lista de Control de Acceso que a su

vez defina al fichero /etc/squid/ sitiosdenegados. Esta lista la denominaremos como "sitiosdenegados". De modo tal, la línea correspondiente quedaría del siguiente modo:

acl sitiosdenegados url_regex "/etc/squid/sitiosdenegados"

Habiendo hecho lo anterior, deberemos tener en la sección de Listas de Control de Acceso algo como lo siguiente:

## Recommended minimum configuration:acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255 acl redlocal src 192.168.1.0/255.255.255.0 acl password proxy_auth REQUIREDacl sitiosdenegados url_regex "/etc/squid/sitiosdenegados"

A continuación especificaremos modificaremos una Regla de Control de Acceso existente agregando con un símbolo de ! que se denegará el acceso a la Lista de Control de Acceso denominada sitiosdenegados:

http_access allow redlocal !sitiosdenegados

La regla anterior permite el acceso a la Lista de Control de Acceso denominada redlocal, pero le niega el acceso a todo lo que coincida con lo especificado en la Lista de Control de Acceso denominada sitiosdenegados.

Ejemplo aplicado a una Regla de Control de Acceso combinando el método de autenticación explicado en el documento Cómo configurar Squid: Acceso por Autenticación:Reglas de control de acceso: denegación de sitios.

## INSERT YOUR OWN RULE(S) HERE TO allow ACCESS FROM YOUR CLIENTS#http_access allow localhosthttp_access allow redlocal password !sitiosdenegadoshttp_access deny all

Permitiendo acceso a sitios inocentes incidentalmente

bloqueados.

Si por ejemplo el incluir una palabra en particular afecta el acceso a un sitio Web, también puede generarse una lista de dominios o palabras que contengan un patrón pero que consideraremos como apropiados.

Como ejemplo: vamos a suponer que dentro de la Lista de Control de Acceso de sitios denegados está la palabra sex. esta denegaría el acceso a cualquier nombre de dominio que incluya dicha cadena de caracteres, como extremesex.com. Sin embargo también estaría bloqueando a sitios como sexualidadjovel.cl, el cual no tiene que ver en lo absoluto con pornografía, sino orientación sexual para la juventud. Podemos añadir este nombre de dominio en un

ficheros que denominaremos /etc/squid/sitios-inocentes.

Este fichero será definido en una Lista de Control de Acceso del mismo modo en que se hizo anteriormente con el fichero que contiene dominios y palabras denegadas.

acl inocentes url_regex "/etc/squid/sitios-inocentes"

Para hacer uso de el fichero, solo bastará utilizar la expresión ! en la misma línea utilizada para laRegla de Control de Accesoestablecida para denegar el mismo.

http_access allow all inocentes

La regla anterior especifica que se denegará el acceso a todo lo que comprenda la Lista de Control de Acceso denominada denegados excepto lo que comprenda la Lista de Control de Acceso denominada inocentes. es decir, se podrá acceder sin dificultad a www.sexualidadjoven.cl manteniendo la restricción para la cadena de caracteres sex.

4.- Restricción de acceso a contenido por extensión.

Introducción.

Denegar el acceso a ciertos tipos de extensiones de fichero permite hacer un uso más racional del ancho de banda con el que se dispone. El funcionamiento es verdaderamente simple, y consiste en denegar el acceso a ciertos tipos de extensiones que coincidan con lo establecido en una Lista de Control de Acceso.

Software requerido.

Definiendo elementos de la Lista de Control de

Acceso.

Lo primero será generar una lista la cual contendrá direcciones Web y palabras usualmente utilizadas en nombres de ciertos dominios. Ejemplos:

\.avi$\.mp4$\.mp3$\.mp4$\.mpg$\.mpeg$\.mov$\.ra$\.ram$\.rm$\.rpm$\.vob$\.wma$\.wmv$\.wav$\.doc$\.xls$\.mbd$\.ppt$\.pps$\.ace$\.bat$\.exe$\.lnk$\.pif$\.scr$\.sys$\.zip$\.rar$

Esta lista, la cual deberá ser completada con todas las extensiones de fichero que el administrador considere pertinentes, la guardaremos como /etc/squid/listaextensiones.

Debemos definir una Lista de Control de Acceso que a su vez defina al fichero /etc/squid/ listaextensiones. Esta lista la denominaremos como "listaextensiones". De modo tal, la línea correspondiente quedaría del siguiente modo:

acl listaextensiones urlpath_regex "/etc/squid/listaextensiones" Habiendo hecho lo anterior, deberemos tener en la sección de Listas de Control de Acceso algo como lo siguiente:

## Recommended minimum configuration:acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255 acl redlocal src 192.168.1.0/255.255.255.0 acl password proxy_auth REQUIREDacl sitiosdenegados url_regex "/etc/squid/sitiosdenegados"acl listaextensiones urlpath_regex "/etc/squid/listaextensiones"

A continuación especificaremos modificaremos una Regla de Control de Acceso existente agregando con un símbolo de ! que se denegará el acceso a la Lista de Control de Acceso denominada listaextensiones:

http_access allow redlocal !listaextensiones

La regla anterior permite el acceso a la Lista de Control de Acceso denominada redlocal, pero le niega el acceso a todo lo que coincida con lo especificado en la Lista de Control de Acceso denominada listaextensiones.

Ejemplo aplicado a una Regla de Control de Acceso combinando el método de autenticación explicado en el documento Cómo configurar Squid: Acceso por Autenticación y el de denegación hacia sitios web explicado en el documento Cómo configurar Squid: Restricción de acceso a sitios Web:Reglas de control de acceso: denegación de extensiones.

## INSERT YOUR OWN RULE(S) HERE TO allow ACCESS FROM YOUR CLIENTS#http_access allow localhosthttp_access allow redlocal password !sitiosdenegados !listaextensioneshttp_access deny all

5.- Restricción de acceso por horarios.

Introducción.

Denegar el acceso a ciertos en ciertos horarios permite hacer un uso más racional del ancho de banda con el que se dispone. El funcionamiento es verdaderamente simple, y consiste en denegar el acceso en horarios y días de la semana.

Software requerido.

Procedimientos

La sintaxis para crear Listas de control de acceso que definan horarios es la siguiente:

acl [nombre del horario] time [días de la semana] hh:mm-hh:mm

Los días de la semana se definen con letras, las cuales corresponden a la primera letra del nombre en inglés, de modo que se utilizarán del siguiente modo:• S - Domingo• M - Lunes• T - Mastes• W - Miercoles• H - Jueves• F - Viernes• A - Sábado

Ejemplo:

acl semana time MTWHF 09:00-21:00

Esta regla define a la lista semana, la cual comprende un horario de 09:00 a 21:00 horas desde elLunes hasta el Viernes.

Este tipo de listas se aplican en las Reglas de Control de Acceso con una mecánica similar a la siguiente: se permite o deniega el acceso en el horario definido en la Lista de Control de Acceso denominada X para las entidades definidas en la Lista de Control de Acceso denominada Y. Lo anterior expresado en una Regla de Control de Acceso, quedaís del siguiente modo:

http_access [allow | deny] [nombre del horario] [lista de entidades] Ejemplo: Se quiere establecer que los miembros de la Lista de Control de Acceso denominada clasematutina tengan permitido acceder hacia Internet en un horario que denominaremos como matutino, y que comprende de lunes a viernes de 09:00 a 15:00 horas.

La definción para le horario correspondería a:

acl clasematutina src 192.168.1.0/255.255.255.0acl matutino time MTWHF 09:00-15:00

La definición de la Regla de Control de Acceso sería:

http_access allow matutino clasematutina

Lo anterior, en resumen, significa que quienes conformen clasematutina podrán acceder a Internet de Lunes a Viernes de 09:00-15:00 horas.

Más ejemplos.

Restringiendo el tipo de contenido.

Como se explica en el documento "Cómo configurar Squid: Restricción de acceso a contenido por extensión", es posible denegar acceso a cierto tipo de contenido de acuerdo a su extensión. Igual que con otras funciones, se requiere una Lista de Control de Accesoy una Regla de Control de Acceso

Si se necesita una lista denominada musica que defina a todos los ficheros con extensión .mp3, utilizaríamos lo siguiente:

acl clasematutina src 192.168.1.0/255.255.255.0acl musica urlpath_regex \.mp3$

Si queremos denegar el acceso al todo contenido con extensión .mp3, la regla quedaría del siguiente modo:

http_access allow clasematutina !musica

Combinando reglas de tiempo y contenido.

Si por ejemplo queremos restringir parcialmente el acceso a cierto tipo de contenido a ciertos horarios, pueden combinarse distintos tipos de reglas.

acl clasematutina src 192.168.1.0/255.255.255.0acl matutino time MTWHF 09:00-15:00acl musica urlpath_regex \.mp3$

http_access allow matutino clasematutina !musica

La Regla de Control de Acceso anterior especifica acceso permitido a en el horario definido como matutino a quienes integran la Lista de Control de Acceso denominada clasematutina a todo contenido [por omisión] excepto a los contenidos que coincidan con los definidos en la Lista de Control de Acceso denominada musica.

Apéndice: Listas y reglas de control de acceso para

Squid.

Opciones que habilitan función de autenticación en squid-2.5.STABLEx (Red Hat Linux 9)auth_param basic children 5auth_param basic realm Servidor Proxy-Cache Squid auth_param basic credentialsttl 2 hours# anteriores ya están descomentadas.auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squidpasswords

NOTA: Red Hat Linux 8.0 y 7.x utilizan 'authenticate_program' en lugar de 'auth_param basic program'

Para generar el fichero de contraseñas correspondiente, se debe utilizar el siguiente comando:htpasswd -c /etc/squid/squidpasswords nombre_usuario

Para modificar las contraseñas del fichero de contraseñas, se debe utilizar el siguiente comando:htpasswd /etc/squid/squidpasswords nombre_usuario

El fichero /etc/squid/squidpasswords debe ser leíble para el usuario squid:chown squid:squid /etc/squid/squidpasswords

Reglas aplicadas# Lista que define método de autenticación:

acl password proxy_auth REQUIRED

# Listas de control de acceso por defecto:acl all src 0.0.0.0/0.0.0.0acl localhost src 127.0.0.1/255.255.255.255

# Listas que definen conjuntos de maquinas acl redlocal src "/etc/squid/redlocal"acl privilegiados src "/etc/squid/privilegiados" acl restringidos src "/etc/squid/restringidos" acl administrador src 192.168.1.254

# Listas que definen palabras contenidas en un URLacl porno url_regex "/etc/squid/porno"# Contenido:## sex# porn# girl# celebrit# extasis# drug# playboy# hustler

# Lista de sitios inocentes que accidentealmente

sean bloqueados acl noporno url_regex "/etc/squid/noporno"# Contenido:## missingheart

# wirelessexcite# msexchange# msexcel# freetown# geek-girls# adulteducation

# Listas que definen tipos de extensiones

# Define uan lista estricta de extensiones prohibidas acl multimedia urlpath_regex "/etc/squid/multimedia"# Contenido:## \.mp3$# \.avi$# \.mov$# \.mpg$# \.bat$# \.pif$# \.sys$# \.lnk$# \.scr$# \.exe$

# Define una lista moderada de extensiones prohibidas acl peligrosos urlpath_regex "/etc/squid/peligrosos"# Contenido:## \.bat$# \.pif$# \.sys$# \.lnk$# \.scr$# \.exe$

# Define una sola extensiónacl realmedia urlpath_regex \.rm$

# Reglas de control de acceso

# Regla por defecto:http_access allow localhost

# Ejemplos de reglas de control de accesohttp_access allow restringidos password !porno !multimedia http_access allow redlocal password !porno !peligrosos http_access allow privilegiados password !peligrosos http_access allow administrador

http_access allow noporno all

# Regla por defecto:http_access deny all

Cómo configurar Squid: Parámetros básicos para Servidor Intermediario (Proxy).

Autor: Joel Barrios DueñasCorreo electrónico: joelbarrios arroba linuxparatodos punto netSitio de Red: http://www.linuxparatodos.net/Jabber ID: darkshram@jabber.org

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2006 Linux Para Todos. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales. c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

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 (Proxy) 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:

• Cliente se conecta hacia un Servidor Intermediario (Proxy).

• Cliente solicita una conexión, fichero u otro recurso disponible en un servidor distinto.

• Servidor Intermediario (Proxy) proporciona el recurso ya sea conectándose hacia el servidor especificado o sirviendo éste desde un caché.

• En algunos casos el Servidor Intermediario (Proxy) puede alterar la solicitud del cliente o bien la respuesta del servidor para diversos propósitos.

Los Servidores Intermediarios (Proxies) 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 Intermediarios (Proxies) es funcionar como caché de contenido de Red (principalmente HTTP), proporcionando en la proximidad de los clientes un caché de páginas y ficheros 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 Intermediarios 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 (Proxy) 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 sustento lógico libre, está disponible el código fuente para quien así lo requiera.

Entre otras cosas, Squid puede funcionar como Servidor Intermediario (Proxy) 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.

NOTA ESPECIAL: Squid no debe ser utilizado como Servidor Intermediario (Proxy) para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá implementar obligatoriamente un enmascaramiento de IP o NAT (Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante (http://www.inet.no/dante/).

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é:

• LRU Acrónimo de Least Recently Used, que traduce como Menos Recientemente Utilizado. En este algoritmo los objetos que no han sido accedidos en mucho tiempo son eliminados primero, manteniendo siempre en el caché a los objetos más recientemente solicitados. Ésta política es la utilizada por Squid de modo predefinido.

• LFUDA Acrónimo de Least Frequently Used with Dynamic Aging, que se traduce como Menos Frecuentemente Utilizado con Envejecimiento Dinámico. En este algoritmo los objetos más solicitados permanecen en el caché sin importar su tamaño optimizando la eficiencia (hit rate) por octetos (Bytes) a

expensas de la eficiencia misma, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer caché de objetos pequeños que se soliciten con menor frecuencia.

• GDSF Acrónimo de GreedyDual Size Frequency, que se traduce como Frecuencia de tamaño GreedyDual (codicioso dual), que es el algoritmo sobre el cual se basa GDSF. Optimiza la eficiencia (hit rate) por objeto manteniendo en el caché los objetos pequeños más frecuentemente solicitados de modo que hay mejores posibilidades de lograr respuesta a una solicitud (hit). Tiene una eficiencia por octetos (Bytes) menor que el algoritmo LFUDA debido a que descarta del caché objetos grandes que sean solicitado con frecuencia.

Sustento lógico necesario.Para poder llevar al cabo los procedimientos descritos en este manual y documentos relacionados, usted necesitará tener instalado al menos lo siguiente:

• Al menos squid-2.5.STABLE6• httpd-2.0.x (Apache), como auxiliar de caché con aceleración.• Todos los parches de seguridad disponibles para la versión del sistema

operativo que esté utilizando. No es conveniente utilizar un sistema con posibles vulnerabilidades como Servidor Intermediario.

Debe tomarse en consideración que, de ser posible, se debe utilizar siempre las versiones estables más recientes de todo sustento 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 sustento 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, utilice lo siguiente y se instalará todo lo necesario junto con sus dependencias:

yum -y install squid httpd

Instalación a través de up2date.Si cuenta con un sistema con Red Hat™ Enterprise Linux 3 o versiones posteriores, utilice lo siguiente y se instalará todo lo necesario junto con sus dependencias:

up2date -i squid httpd

Otros componentes necesarios.El mandato iptables se utilizará para generar las reglas necesarias para el guión de Enmascaramiento de IP. Se instala de modo predefinido en todas las distribuciones actuales que utilicen núcleo (kernel) versiones 2.4 y 2.6.

Es importante tener actualizado el núcleo del sistema operativo por diversas cuestiones de seguridad. No es recomendable utilizar versiones del kernel anteriores a la 2.4.21. Actualice el núcleo a la versión más reciente disponible para su distribución.

Si cuenta con un sistema con CentOS o White Box Enterprise Linux 3 o versiones posteriores, utilice lo siguiente para actualizar el núcleo del sistema operativo e iptables, si acaso fuera necesario:

yum -y update kernel iptables

Si cuenta con un sistema con Red Hat™ Enterprise Linux 3 o versiones posteriores, utilice lo siguiente para actualizar el núcleo del sistema operativo, e iptables si acaso fuera necesario:

up2date -u kernel iptables

Antes de continuar.Tenga en cuenta que este manual ha sido comprobado varias veces y ha funcionado en todos los casos y si algo no funciona solo significa que usted no lo leyó a detalle y no siguió correctamente las indicaciones.

Evite dejar espacios vacíos en lugares indebidos. El siguiente es un ejemplo de como no se debe habilitar un parámetro.

Mal# Opción incorrectamente habilitada http_port 3128

El siguiente es un ejemplo de como si se debe habilitar un parámetro.

Bien# Opción correctamente habilitadahttp_port 3128

Configuración básica.Squid utiliza el fichero 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:

• http_port• cache_dir• Al menos una Lista de Control de Acceso• Al menos una Regla de Control de Acceso• httpd_accel_host• httpd_accel_port• httpd_accel_with_proxy

Parámetro http_port: ¿Que puerto utilizar para Squid?De acuerdo a las asignaciones hechas por IANA y continuadas por la ICANN desde el 21 de marzo de 2001, los Puertos Registrados (rango desde 1024 hasta 49151) recomendados para Servidores Intermediarios (Proxies) pueden ser el 3128 y 8080 a través de TCP.

De modo predefinido Squid utilizará el puerto 3128 para atender peticiones, sin embargo se puede especificar que lo haga en cualquier otro puerto disponible o bien que lo haga en varios puertos disponibles a la vez.

En el caso de un Servidor Intermediario (Proxy) Transparente, regularmente se utilizará el puerto 80 o el 8000 y se valdrá del re-direccionamiento de peticiones de modo tal que no habrá necesidad alguna de modificar la configuración de los clientes HTTP para utilizar el Servidor Intermediario (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 volver a configurar el servidor HTTP para utilizar otro puerto disponible, o bien desinstalar o desactivar el servidor HTTP.

Hoy en día puede no ser del todo práctico el utilizar un Servidor Intermediario (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 Intermediario (Proxy) con restricciones por clave de acceso, lo cual no puede hacerse con un Servidor Intermediario (Proxy) Transparente, debido a que se requiere un diálogo de nombre de usuario y clave de acceso.

Regularmente algunos programas utilizados comúnmente por los usuarios suelen traer de modo predefinido el puerto 8080 (servicio de cacheo WWW) para utilizarse al configurar que Servidor Intermediario (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:

## You may specify multiple socket addresses on multiple lines.## Default: http_port 3128http_port 3128http_port 8080

Si 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:

## You may specify multiple socket addresses on multiple lines.## Default: http_port 3128http_port 192.168.1.254:3128http_port 192.168.1.254:8080

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

• Objetos en tránsito.

• Objetos frecuentemente utilizados (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.

De modo predefinido 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:

cache_mem 16 MB

Parámetro cache_dir: ¿Cuanto desea almacenar de Internet en el disco duro?Este parámetro se utiliza para establecer que tamaño se desea que tenga el caché 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? De modo predefinido Squid utilizará un caché de 100 MB, de modo tal que encontrará la siguiente línea:

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 utilizará menos el ancho de banda. La siguiente línea establece un caché de 700 MB:

Los números 16 y 256 significan que el directorio del caché contendrá 16 directorios subordinados 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 caché y éste excede al espacio real disponible en el disco duro, Squid se bloqueará inevitablemente. Sea cauteloso con el tamaño de caché especificado.

Parámetro ftp_user.Al acceder a un servidor FTP de manera anónima, de modo predefinido Squid enviará como clave de acceso 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 clave de acceso, puede especificarse la dirección de correo electrónico que uno considere pertinente.

ftp_user proxy@su-dominio.net

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.

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

acl [nombre de la lista] src [lo que compone a la lista]

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.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 especificando un fichero localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones IP. Ejemplo:

acl permitidos src "/etc/squid/permitidos"

El fichero /etc/squid/permitidos contendría algo como siguiente:

192.168.1.1192.168.1.2192.168.1.3192.168.1.15192.168.1.16192.168.1.20192.168.1.40

Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el fichero /etc/squid/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 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 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:

http_access allow lista1 !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.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:

acl todalared src 192.168.1.0/255.255.255.0

## Recommended minimum configuration:acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl todalared src 192.168.1.0/255.255.255.0

http_access allow todalared

## INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS#http_access allow localhosthttp_access allow todalaredhttp_access deny all

La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada todalared, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid.

Caso 2.

Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga dicha lista. Genere el fichero /etc/squid/listas/redlocal, dentro del cual se incluirán solo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:

192.168.1.1192.168.1.2192.168.1.3192.168.1.15192.168.1.16192.168.1.20192.168.1.40

Denominaremos a esta lista de control de acceso como redlocal:

acl redlocal src "/etc/squid/listas/redlocal"

## Recommended minimum configuration:acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl redlocal src "/etc/squid/listas/redlocal"

## INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS#http_access allow localhosthttp_access allow redlocalhttp_access deny all

La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal, la cual está conformada por las direcciones IP especificadas en el fichero /etc/squid/listas/redlocal. Esto significa que cualquier máquina no incluida en /etc/squid/listas/redlocal no tendrá acceso a Squid.

Parámetro chache_mgr.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.

cache_mgr joseperez@midominio.net

Parámetro cache_peer: caches padres y hermanos.El parámetro cache_peer se utiliza para especificar otros Servidores Intermediarios (Proxies) con caché en una jerarquía como padres o como hermanos. Es decir, definir si hay un Servidor Intermediario (Proxy) adelante o en paralelo. La sintaxis básica es la siguiente:

cache_peer servidor tipo http_port icp_port opciones

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.1.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 (Proxy) padre, utilice la siguiente línea:

cache_peer 192.168.1.1 parent 8080 3130 proxy-only

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:

cache_peer 10.1.0.1 sibling 8080 3130 proxy-onlycache_peer 10.2.0.1 sibling 8080 3130 proxy-onlycache_peer 10.3.0.1 sibling 8080 3130 proxy-only

Pueden hacerse combinaciones que de manera tal que se podrían tener caches padres y hermanos trabajando en conjunto en una red local. Ejemplo:

cache_peer 10.0.0.1 parent 8080 3130 proxy-onlycache_peer 10.1.0.1 sibling 8080 3130 proxy-onlycache_peer 10.2.0.1 sibling 8080 3130 proxy-onlycache_peer 10.3.0.1 sibling 8080 3130 proxy-only

Caché con aceleración.Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el caché de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el que ya se encuentra en el caché en lugar de volver a descargarlo desde Internet.

Esta función permite navegar rápidamente cuando los objetos ya están en el caché de Squid y además optimiza enormemente la utilización del ancho de banda.

La configuración de Squid como Servidor Intermediario (Proxy) Transparente solo requiere complementarse utilizando una regla de iptables que se encargará de re-direccionar peticiones haciéndolas pasar por el puerto 8080. La regla de iptables necesaria se describe más adelante en este documento.

Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) en modo convencional.En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros:

httpd_accel_host virtualhttpd_accel_port 0httpd_accel_with_proxy on

Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) Transparente.Si se trata de un Servidor Intermediario (Proxy) transparente, deben utilizarse las siguientes opciones, considerando que se hará uso del caché de un servidor HTTP (Apache) como auxiliar:

# Debe especificarse la IP de cualquier servidor HTTP en la # red local o bien el valor virtualhttpd_accel_host 192.168.1.254httpd_accel_port 80httpd_accel_with_proxy onhttpd_accel_uses_host_header on

Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) Transparente para redes con Internet Exlorer 5.5 y versiones anteriores.Si va a utilizar Internet Explorer 5.5 y versiones anteriores con un Servidor Intermediario (Proxy) transparente, es importante recuerde que dichas versiones tiene un pésimo soporte con los Servidores Intermediarios (Proxies) transparentes imposibilitando por completo la capacidad de refrescar contenido. Si se utiliza el parámetro ie_refresh con valor on puede hacer que se verifique en los servidores de origen para nuevo contenido para todas las peticiones IMS-REFRESH provenientes de Internet Explorer 5.5 y versiones anteriores.

# Debe especificarse la IP de cualquier servidor HTTP en la# red localhttpd_accel_host 192.168.1.254httpd_accel_port 80httpd_accel_with_proxy onhttpd_accel_uses_host_header onie_refresh on

Lo más conveniente es actualizar hacia Internet Explorer 6.x o definitivamente optar por otras alternativas. Mozilla es en un conjunto de aplicaciones para Internet, o bien Firefox, que es probablemente el mejor navegador que existe en el mercado. Firefox es un navegador muy ligero y que cumple con los estándares, y está disponible para Windows, Linux, Mac OS X y otros sistemas operativos.

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, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte hacia /usr/share/squid/errors/Spanish en lugar de hacerlo hacia /usr/share/squid/errors/English.

Elimine primero el enlace simbólico actual:

rm -f /etc/squid/errors

Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al español.

ln -s /usr/share/squid/errors/Spanish /etc/squid/errors

Nota: Este enlace simbólico debe verificarse, y regenerarse de ser necesario, cada vez que se actualizado Squid ya sea a través de yum, up2date o manualmente con el mandato rpm.

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:

service squid start

Si necesita reiniciar para probar cambios hechos en la configuración, utilice lo siguiente:

Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, utilice lo siguiente:

chkconfig squid on

Lo anterior habilitará a Squid en todos los niveles de corrida.

Depuración de erroresCualquier error al inicio de Squid solo significa que hubo errores de sintaxis, errores de dedo o bien se están citando incorrectamente las rutas hacia los ficheros 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 fichero /etc/squid/squid.conf.

service squid reload

Cuando se trata de errores graves que no permiten iniciar el servicio, puede examinarse el contenido del fichero /var/log/squid/squid.out con el mandato less, more o cualquier otro visor de texto:

less /var/log/squid/squid.out

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.

• Firestarter: http://www.fs-security.com/

• Shorewall: http://www.shorewall.net/

Re-direccionamiento de peticiones a través de iptables y Firestarter.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 (8080), 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 (Proxy) 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 lo hacemos 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:

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Lo anterior, que requiere un guión de cortafuegos funcional en un sistema con dos interfaces de red, hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-direccionará hacia el puerto 8080 del servidor.

Utilizando Firestarter, la regla anteriormente descrita se añade en el fichero /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 8080 del cortafuegos, en donde está configurado Squid configurado como Servidores Intermediario (Proxy) transparente.

#ACTION SOURCE DEST PROTO DESTREDIRECT loc 8080 tcp 80

Linux Para Todoshttp://www.linuxparatodos.net/geeklog/staticpages/index.php?page=19-0-como-squid-general

squid_lpt

Documents

Transcript of squid_lpt

Diccionario de lunfardo

BAREMOS

Municipios de España

Ejemplos de ficha bibliográfica

Mapas Conceptuales

acrostics

Calculo Ciclon

PRECIOSCHACO

Acta de Recepción Definitiva de Obras de Urbanización

MIRTA VARGAS DE ARGENTINA MEDIA 9 CALZADA Cat B 2° grupo 1ª Actividad

BIBLIOGRAFIA

VALORIZACION OCTUBRE VICTOR ROMERO

FORMATOS DE CONTABILIDAD

Kar Español

captura imagen c#

Libro1

DÍA DE LA ANUNCIACIÓN

hoja de costos falda2

CARGUE PUCC

problemes unitats de mesura