Squid 2.6 en la PYME
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:
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.
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
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
}
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
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).
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:
iptables -A INPUT -i eth0 -p tcp -s 192.168.0.0/24 –dport 443 -j ACCEPT.
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
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.