Squid 2.6 en la PYME

( sistemas / linux )

IMPORTANTE: Este artículo fue publicado en la revista Linux+ Julio/Agosto 2007 (Nº 34) y que amablemente me dieron permiso para publicarlo. El artículo fue escrito por Alberto Permuy Leal.
Es evidente que la información aquí expuesta puede estar obsoleta pero es un buen punto de referencia y aprendizaje.


La implementación de un proxy en la red del cliente es un paso inicial y que, con frecuencia, viene a solucionar muchos problemas de seguridad y saturación de comunicaciones, siendo habitual la existencia de organizaciones que han estado incrementando previamente sus comunicaciones contratadas con un ISP sin saber muy bien porqué, lo único que saben es que los anchos de banda se acaban agotando, los problemas de virus y ataques persisten y las comunicaciones siempre se quedan cortas.

Por ello, una primera tarea puede ser la de instalar un proxy, con el fin de solucionar un primer problema. Como veremos en estas páginas, SQUID, como otros, nos permitirá comenzar a organizar los dos ámbitos de las comunicaciones de la PYME, el tramo Internet, optimizando el mismo y la demanda que la red realiza sobre las comunicaciones, y el tramo de los usuarios, comenzando a organizar el uso que dan los mismos a la red, aplicando asimismo soluciones de optimización caché, que redundan de manera palpable en el rendimiento de las comunicaciones.

Ésta es una de las razones por las cuales optamos por este tipo de implantaciones como primer paso, dado que la instalación de un servicio proxy es imperceptible para los usuarios, desde su punto de vista, pero redunda en resultados claros para la organización, abriendo ese camino de confianza tan importante para abordar nuevos proyectos y soluciones en el cliente.

Por lo tanto, vamos a describir de un modo detallado las características de una de las soluciones proxy que hay en el mercado: Squid. Entre sus características principales, podemos destacar la facilidad de configuración, su fiabilidad y los excelentes resultados que ofrece una vez está operativo.

Por otra parte, Squid nos abre las puertas, posteriormente, a introducir a la PYME en cuestiones que hasta el momento le eran ajenas, tales como el control del uso de la red y el análisis del rendimiento de la misma, que nos permitirá, con la información que nos ofrece Squid, planificar mejoras en dicha red y solucionar errores en el diseño de la misma.

Squid es un software proxy, diseñado originalmente para plataformas Unix-Like, liberado bajo licencia GPL, que permite desde la aceleración de la navegación, hasta caché DNS, soportando multitud de protocolos,aunque en realidad se utiliza principalmente para HTTP y FTP.

El término proxy hace referencia a un programa o dispositivo que realiza una acción en representación de otro. La finalidad más habitual es la del servidor proxy, que sirve para permitir el acceso a Internet a todos los equipos de una organización cuando sólo se puede disponer de un único equipo conectado, esto es, una única dirección IP.

Squid posee las siguientes características:

Squid puede ejecutarse en plataformas:

Actualmente (Enero 2007) la rama estable se encuentra en la versión 2.6.x. Entre los cambios más destacables en relación a versiones anteriores destacamos:

Instalación

La instalación de Squid en una distribución Debian GNU/Linux o derivados (Ubuntu, Kubuntu, Knoppix, etc.) es muy sencilla. Desde consola y como root actualizaremos repositorios, y posteriormente instalaremos Squid:

[root@satriani] apt-get
update && apt-get
install squid

Antes de comenzar con la edición del fichero de configuración documentaremos las redes o subredes desde las que Squid aceptará peticiones así como las interfaces de red de la máquina:

Con el comando ifconfig, comprobaremos que este direccionamiento está correctamente configurado en el servidor.

[root@satriani]
ifconfig | more

En la mayoría de las distribuciones, y partiendo de una instalación de paquetes precompilados (.rpm o .deb por ejemplo), el fichero de configuración de Squid se halla en /etc/squid/squid.conf. Este fichero consta de multitud de parámetros; aunque en este artículo nos centraremos en las opciones indispensables y más interesantes para conseguir un óptimo funcionamiento.

En caso de no poder localizar squid.conf, con las herramientas find y whereis intentaremos localizarlos, y en caso contrario, crearemos el fichero.

Localizando el fichero con find:

[root@satriani] find / -name squid.conf

Localizando el fichero con whereis:

[root@satriani] whereis squid.conf
squid: /etc/squid/squid.conf

Antes de nada, haremos un backup de nuestro fichero actual de configuración de Squid y lo enviaremos por email. Realmente no es necesario, pero es una buena práctica a la hora de modificar ficheros que puedan afectar a la estabilidad del sistema:

[root@satriani]cp /etc/squid/squid.conf /etc/squid/squid.conf.bak
[root@satriani]mail -s BackupSquidConf myuser@mydomain.com < /etc/squid/squid.conf

Llegados a este punto, dividiremos en dos partes el fichero de configuración squid.conf : Configuración Global y ACLs, con el fin de aclarar la comprensión del mismo.

Configuración Global

Con nuestro editor de texto favorito (nano en este artículo), editaremos o crearemos (recomendado) el fichero squid.conf, aplicando los parámetros descritos en el punto anterior acorde con el ejemplo que se muestra a continuación (ver Listado 1).

Listado 1. Squid.conf Parte 1, definición de parámetros globales
[root@satriani] nano /etc/squid/squid.conf
Squid.conf Parte 1, Configuración Global
-----------------------------------------------------
#
#Fichero de Configuración Squid 2.6.x
#Localización: /etc/squid/squid.conf
#
#Última modificación : 07/02/07
#
visible_hostname proxy.mydomain.com
http_port 3128 transparent
#
#
#Parámetros de la cache
cache_mem 32 MB
cache_dir ufs /tmp 1024 32 256
cache_mgr myuser@mydomain.com
coredump_dir /var/spool/squid/cache
acl manager proto cache_object
maximum_object_size 32768 KB
cache_access_log /var/log/squid/access.log
#
#
#Parámetros varios
half_closed_clients off
ftp_user anonymous@nospam.com

ACLs

Un ACL es una definición de control de acceso, que en Squid se especifica mediante el parámetro acl según la siguiente sintaxis:

acl nombre_acl tipo_acl descripción
...
acl nombre_acl tipo_acl
"fichero_de_descripciones" ...

Cuando usamos un "fichero_de_descripciones", cada descripción se corresponde con una línea del fichero, como podemos ver en el siguiente ejemplo:

acl denywords url_regex "/etc/squid/denywords"
http_access deny denywords

Es necesario apuntar que antes de reiniciar el servicio, el fichero /etc/squid/denywords debe existir; en caso contrario no se podrá iniciar el servicio. Es recomendable añadir por lo menos una cadena de texto, para eliminar un posible mensaje Warning al iniciar el servicio.

Las Listas de Control de Acceso (ACL) en Squid proporcionan seguridad adicional, limitando o permitiendo tráfico. Implementando ACLs podremos, entre otras opciones filtrar tráfico por:

Listado 2. Squid.conf Parte 2, definición de ACLs
acl all src 0.0.0.0/0.0.0.0
acl localhost src 127.0.0.1/255.255.255.255
acl lan src 192.168.0.0/255.255.255.0
acl denywords url_regex "/etc/squid/denywords"
acl denydomains dstdom_regex "/etc/squid/denydomains"

A continuación describiremos el proceso para aplicar las ACLs a nuestra implementación. Definiremos las redes / subredes en las que trabajaremos. En este caso son tres redes:

Listado 3. Squid.conf Parte 3, aplicación de ACLs
http_access allow localhost
http_access allow manager localhost
http_access deny denywords
http_access deny denydomains
http_access allow lan
http_access allow mantenimiento
http_access deny CONNECT !SSL_Ports
http_access deny CONNECT !Safe_Ports
http_access deny all

Definiremos las restricciones a aplicar en los hábitos de navegación:

Llegados a este punto, tenemos prácticamente configurado Squid. Antes de iniciar el servicio, necesitamos crear la estructura del directorio swap de Squid, iniciar el servicio y verificar el funcionamiento. Para ello, como de costumbre, desde el terminal y como root (Listado 4).

Listado 4. Arrancando Squid
[root@satriani] squid -z
2007/02/07 15:10:18 | Creating Swap Directories
[root@satriani] /etc/init.d/squid start
Starting Squid HTTP Proxy: squid
[root@satriani] telnet 192.168.0.254 3128
Trying 192.168.10.254 3128 . . .
Connected to proxy.mylan.com (192.168.0.254)
Escape character is '^]'.
get http://www.gnu.org

Uno de los puntos a tener en cuenta a la hora de configurar un servidor proxy son los ficheros log. Éstos suelen aumentar de tamaño, como es lógico, a medida que nuestro proxy va sirviendo páginas. Para evitar futuros problemas, es necesario configurar la herramienta logrotate, para que la rotación de logs se realice semanalmente (Listado 5).

Listado 5. Rotando logs
[root@satriani] nano /etc/
logrotate.d/squid
/var/log/squid/access.log {
 weekly
 rotate 5
 copytruncate
 compress
 notifempty
 missingok
}

Configuración Proxy Navegadores

En párrafos posteriores, configuraremos Iptables, para dotar a nuestro servidor proxy, de las funciones de proxy transparente. Para que los navegadores de los clientes envíen las peticiones a nuestro servidor, debemos configurar los navegadores para que salgan a Internet por el proxy.

Configuración para Mozilla Firefox 2.0.x:

Herramientas/Opciones/Avanzado/Red/Configuración.
Configuración para Internet Explorer 6.0.x:
Herramientas/Opciones de Internet/Conexiones/Configuración LAN.
Configuración para Links 0.99.x: Configuración/Opciones de Red.

Se han obviado en la implementación del proxy, la instalación de filtros adicionales, que facilitan las restricciones y las configuraciones de las ACLs, como pueden ser los archiconocidos DansGuardian o Squid Guard. Una de las opciones más interesantes de Squid, es que, en binomio con Iptables, podemos configurar el mismo servidor proxy como gateway para la salida a Internet, liberando al administrador de red, de la tediosa labor de configurar puesto a puesto los navegadores y demás aplicaciones.

La instalación y configuración de estos paquetes, así como la configuración de Squid en modo transparente es relativamente sencilla, y los resultados son realmente espectaculares, pero como habrá podido observar el lector, se escapan al enfoque inicial de este artículo.

Monitorizando accesos: SARG

Con Squid funcionando, filtrando resultados y acelerando en la medida de lo posible los accesos a Internet, la monitorización de accesos desde Shell al fichero access.log, se vuelve una tarea tediosa y complicada. Existen multitud de paquetes que resuelven con más o menos soltura esta tarea, entre ellos destacamos:

Cualquier opción es altamente recomendable, pero por flexibilidad, sencillez y robustez, utilizaremos SARG. Acrónimo de Squid Análisis Report Generador, SARG es una aplicación escrita en C por Pedro Orso, que genera reportes en HTML a partir del fichero access. log generado por Squid, soportando ficheros log de: Squid, Microsoft ISA Server y Novell Border Manager.

Entre otros detalles muestra información acerca de :

La versión más actual (Enero 2007) es la 2.2.3.1, pudiendo ser descargada en formato tar.gz o en paquetes binarios para: Debian, Fedora-RedHat, SuSE, Slackware, OpenBSD, MacOS…etc.

Como se indica en el párrafo anterior, SARG genera reportes en formato HTML, con lo cual nos vemos prácticamente obligados* a instalar un servidor web en nuestra máquina, por ejemplo Apache (http://www.apache. org), disponible para casi la totalidad de distribuciones GNU/Linux. Por razones de seguridad y privacidad, a la hora de generar los reportes, se recomienda instalar el módulo mod_auth, para restringir el acceso al servidor web.

La instalación, vía apt, yum o rpm, como viene siendo habitual es muy sencilla. Para la instalación desde una versión en tar.gz, describiremos los pasos:

Desempaquetamos y descomprimimos el fichero sarg-x.x.x.tar.gz:

[root@satriani] tar zxvf sarg-x.x.x.tar.gz
[root@satriani] ./configure
configure options:
enable-bindir= Directorio dónde se instalará el binario de sarg; por defecto : /usr/bin
enable-sysconfdir – Directorio de configuración; por defecto : /usr/local/sarg
nable-htmldir – Directorio del servidor web donde se generarán los reportes; default: /var/www/html
enable-mandir - where the sarg man page will be saved; default: /usr/local/man/man1
make
make install

En el directorio /usr/local/sarg o en el directorio especificado en –sysconfigdir, editaremos el fichero sarg.conf y haremos las modificaciones oportunas.

Podemos enviar los reportes a otra máquina vía SMB,NFS…etc.

El fichero sarg.conf almacena la configuración de SARG, y se localiza en el directorio especificado en --enable-sysconfdir, y la sintaxis es como en el Listado 6.

Listado 6. Ejemplo sarg.conf
Ejemplo fichero sarg.conf
# Slovak
# Spanish
# Turkish
#
language Spanish
# TAG: access_log file
# Where is the access.log file
# sarg -l file
#
access_log /var/log/squid/
access.log
# TAG: graphs yes|no
# Use graphics where is possible.
# graph_days_bytes_bar_color blue|g
reen|yellow|orange|brown|red
#
graphs yes
graph_days_bytes_bar_color red

Pese a ser un fichero de configuración aparentemente sencillo, en realidad nos encontramos con infinidad de posibilidades y combinaciones a la hora de trabajar con SARG.

Para hacer nuestra primera prueba, desde Shell y como root simplemente:

[root@satriani] sarg

Si no hemos tenido ningún Warning, abriendo un navegador podremos ver los resultados (Figuras 4, 5, 6).

Necesitamos añadir una tarea cron para ejecutar SARG por lo menos una vez al día, para ello, con nuestro editor de textos favoritos editamos /etc/crontab y añadimos:

0 20 * * * root /usr/bin/sarg

Iptables

El proyecto Iptables, también conocido como Netfilter, comenzó en 1998 encabezado por Michael Neuling y Rusty Russell, autor también del proyecto antecesor a iptables: ipchains.

Iptables es la herramienta principal de cortafuegos para GNU/Linux en las series del Kernel 2.4 en adelante. En relación a ipchains las principales novedades son: mejor aprovechamiento de los recursos del sistema, la integración de las reglas de filtrado, NAT y manipulación.

Para instalar Iptables en nuestra/s máquinas, podemos descargar iptables de www. netfilter.org, compilarlo e instalarlo. En prácticamente cualquier distribución actual el kernel está precompilado e iptables instalado por defecto.

Iptables para su funcionamiento utiliza tres tablas: nat, magle, y filter, donde cada una tiene definidas unas reglas o chains.Cada una de estas reglas se compone de una lista de reglas de filtrado sobre el paquete mediante un par condición/acción. El paquete IP pasará secuencialmente por cada una de estas reglas hasta encajar en alguna de las reglas definidas. En caso contrario, se aplicará la acción por defecto asociada a esa regla.

Veamos un ejemplo de construcción de regla de iptables (man iptables):

iptables { -A | --append | -D | --delete } cadena especificación-de-regla [ opciones ]
/sbin/iptables –A INPUT –i eth0 –p tcp –dport 80 –j DROP

En la regla anterior, añadimos (-A) a la tabla filter (INPUT) una regla que deniega (DROP) todo el tráfico web entrante (-p tcp –dport 80) por la interfaz eth0 ( -i eth0).

Enmascarando Interfaces: Proxy transparente

Es necesario recordar que iptables no deja de ser un shell script, y que si no salvamos las reglas, con el reinicio de la máquina, éstas se perderán. Para ello, disponemos del comando iptables-save. En este ejemplo, de integración de Iptables con Squid, no utilizaremos iptables-save, sino que crearemos un shell script, que ejecutaremos cada vez que reiniciemos la máquina. Así, podremos comentar y analizar de un modo mucho más flexible el conjunto de reglas a aplicar.

Comenzaremos creando el fichero que almacenará las reglas de iptables. Como es habitual, en el terminal y como root:

[root@satriani] touch /etc/init.d/firewall
[root@satriani] chmod 700 /etc/init.d/firewall
[root@satriani] update-rc.d firewall defaults

Hemos creado el fichero /etc/init.d/firewall, modificado permisos (rxw- - - - - - ) para que solamente root pueda ejecutarlo, y a continuación con el comando update-rc.d conseguimos que se ejecute en todos los runlevels.

Retomemos la configuración de Squid. Tenemos corriendo el servicio de Proxy Caché, en el puerto TCP 3128. Supuestamente hemos llevado a cabo la tediosa labor de configurar todas y cada una de las aplicaciones en las máquinas de nuestra LAN que queremos que salgan a Internet a través de este servicio. Evidentemente este supuesto es inviable cuando el número de máquinas y aplicaciones de las que hablamos es considerable. Para ello, iptables es capaz de simular un router, actuando como puerta de enlace para las máquinas de su LAN, por medio del enmascaramiento IP o masquerading.

Llegados a este punto, iptables llama a la puerta de nuestra máquina pidiendo ser configurado. Como hemos comentado, iptables es capaz de modificar los paquetes IP, acorde a unas reglas predefinidas. Para ello añadiremos reglas en la tabla mangle, utilizando la cadena PREROUTING; es decir, redireccionaremos todas la peticiones al puerto 80 hacia el 3128:

iptables –t nat –A PREROUTING –s 192.168.0.0/0 –p tcp –dport 80 –j DNAT –to-destination 192.168.0.1:3182

Ejecutando este script, eliminando la configuración proxy en las aplicaciones configuradas en las máquinas de nuestra LAN y modificando el gateway de éstas por las IP de la interfaz enmascarada, hemos configurado un proxy transparente.

Como habrán podido observar nuestros avispados lectores, la política por defecto es ACCEPT, con lo cual nuestra máquina acepta todo el tráfico sin restricciones ni filtrado de ningún tipo, dejándola expuesta ante cualquier ataque. Así mismo, tampoco se ha mencionando las conexiones por SSL a través del proxy transparente. La razón es muy sencilla: los paquetes viajan cifrados entre el servidor web y el navegador del cliente, impidiendo que Squid pueda escuchar y procesar correctamente las peticiones https. Recordemos que el proxy se encuentra entre el webserver y el navegador del cliente. Entre las recomendaciones sugeridas para aumentar el blindaje de nuestra máquina se encuentran:

En caso de encontrar problemas a la hora de identificar los puertos utilizados en las conexiones SSL, aplicaciones como Ethereal o Iptraff, pueden ayudarnos.

Logear reglas. Iptables permite logear reglas con la directiva LOG, lo cual nos permitirá comprobar si ha habido algún intento de acceso no deseado a nuestra máquina:

iptables –A INPUT –i eth0 –p tcp –dport 22 –j LOG –logprefix=”ACCESO-SSH”

Por defecto, el fichero log donde iptables almacena los log es /var/log/messages. A medida que este fichero va aumentando, acceder a una línea concreta, puede resultar una tarea ardua y difícil. Para ello existen herramientas que permiten su legibilidad, como por ejemplo Wflogs, que convierte entradas en formato HTML.

IDS. Implementar un Sistema de Detección de Intrusos nunca está demás. Recomendamos encarecidamente Snort. La finalidad de este artículo es mostrar al lector las posibilidades globales de Squid e Iptables. Es responsabilidad de cada usuario o Administrador, proteger y blindar sus sistemas. Implementando Squid e Iptables tendrá parte del camino recorrido, el resto… está en sus manos.

Listado 7. Script de configuración iptables
#!/bin/bash
#
#
#
#Borrado de reglas previas
iptables –F
iptables –X
iptables –Z
iptables –t nat –F
#
#
#Política por defecto
iptables –P INPUT ACCEPT
iptables –P OUTPUT ACCEPT
iptables –P FORWARD ACCEPT
iptables –t nat -P PREROUTING ACCEPT
iptables –t nat –P POSTROUTING ACCEPT
#
#
#Permitimos que los paquetes puedan ser "forwardeados"
iptables –A FORWARD –p tcp –s 192.168.0.0/24 –j ACCEPT
#
#Redireccionamos el tráfico web hacia el proxy
iptables –t nat –A PREROUTING –s 192.168.0.0/24 –p tcp –dport 80
–j DNAT –to-destination 192.168.0.1:3128
#Enmascaramos la interfaz eth0
iptables –t nat –A POSTROUTING –s 192.168.0.0/24 –o eth0 –j MASQUERADE
#
#Habilitamos bit de forward. ¡Muy importante!
echo 1 > /proc/sys/net/ipv4/ip_forward

Consideraciones finales

Controlar el acceso y acelerar la navegación a los sitios visitados en Internet es una solución viable y contrastada para optimizar el acceso y el ancho de banda de una PYME. Mediante la instalación de una solución proxy gestionar la conexión a Internet desde un sólo punto, permitiendo una conexión segura, habilitando y denegando la conexión a ciertos puertos o protocolos es posible, fiable, y económico.

Implementando Sistemas Operativos Libres (Linux,*BDSs ..etc), independientemente del ahorro de costes en licencias, dotamos a las implementaciones de un nivel de seguridad y robustez añadido, que difícilmente podremos encontrar en otros Sistemas Operativos.

Squid, como software de servidor proxy, en su versión 2.6, ha alcanzado su madurez, tanto es así, que grandes corporaciones e incluso ISPs optan por su implementación bajo plataformas *NIX. Iptables va camino de convertirse en un hito en sistemas GNU/Linux con Kernel 2.4 - 2.6. Mientras tanto y a la espera de la release 2.7 de Squid… seguiremos haciendo web-caching.

Enlaces de la red:

Modificado el 22 Febrero, 2015
Creado el 1 novimebre, 2008
   

Compartiendo conocimiento desde 1995 - I.M.D. I.M.D.