SQUID es un potente y rápido servidor de caché de objetos. Hace proxy de sesiones FTP y WWW, lo que básicamente le da las propiedades de un servidor FTP y WWW, pero sólo lee y escribe ficheros dentro del directorio de su caché ( o al menos eso esperamos), lo cual le hace relativamente seguro. Sería muy difícil utilizar Squid para comprometer el sistema, se ejecuta como usuario no root (generalmente ‘nobody’), de modo que no hay mucho de lo que preocuparse. La principal preocupación con Squid debería ser la configuración incorrecta. Por ejemplo, si se engancha Squid a la red interna (como suele ser el caso), y a Internet (de nuevo, bastante habitual), se podría utilizar para alcanzar hosts internos (incluso aunque estén utilizando direcciones IP no rutables). De aquí que sea muy importante la correcta configuración de Squid.
La forma más sencilla de asegurarse de que esto no ocurre es utilizar la configuración interna de Squid y enlazarlo sólo a los interfaces internos, no dejando que el mundo exterior lo intente utilizar como un proxy para llegar a tu LAN interna. Además de esto, es una buena idea filtrarlo con el cortafuegos. Squid se puede utilizar como acelerador de HTTP (también conocido como proxy inverso), quizás se tenga un servidor NT en la red interna que se quiera compartir con el resto del mundo, en este caso las cosas se complican un poco a la hora de configurarlo, pero es posible hacerlo de una forma relativamente segura. Afortunadamente Squid tiene buenas ACL’s (listas de control de acceso) dentro del fichero squid.conf, lo cual te permite bloquear el acceso por nombres, IP’s, redes, hora del día, día real (quizás se permita acceso ilimitado los fines de semana a gente que va a la oficina). Sin embargo, recuerda que cuanto más complicada sea la ACL, más lento será el Squid para responder a las peticiones.
La mayoría de los administradores de redes preferirán configurar el Squid de forma que la red interna pueda acceder a sitios www de Internet. En este ejemplo, 10.0.0.0/255.255.255.0 es la red interna, 5.6.7.8 es la dirección externa del servidor Squid, y 1.2.3.4 es el servidor www que queremos ver.
2 3
1 4
Squid debería estar configurado de forma que sólo escuche peticiones en su interfaz interno, si estuviera escuchando en todos los interfaces, se podría ir a 5.6.7.8, puerto 3128 y solicitar http://10.0.0.2/ o cualquier máquina interna, y ver el contenido www de la red interna. Esto es lo que hay que poner en el fichero squid.conf:
tcp_incoming_address 10.0.0.1
tcp_outgoing_address 5.6.7.8
udp_incoming_address 10.0.0.1
udp_outgoing_address 5.6.7.8
Lo cual evitará que nadie utilice Squid para probar tu red interna.
En la otra cara de la moneda, tenemos a gente que utiliza Squid para poner servidores www accesibles a Internet de forma controlada. Por ejemplo, se puede querer tener un servidor www IIS 4.0 que se quiera poner accesible a Internet, pero se teme conectarlo directamente. Utilizando Squid se puede otorgar acceso de forma muy controlada. En este ejemplo, 1.2.3.4 es una máquina aleatoria de Internet, 5.6.7.8 es la dirección IP externa del servidor Squid, 10.0.0.1 es su dirección IP interna, y 10.0.0.2 es un servidor www dentro de la red interna, ejecutando IIS 4.0
2 3
1 4
Para configurar Squid como acelerador, simplemente hay que definir el puerto 80 "http_port" en squid.conf:
http_port 3128
Y después configurar las direcciones IP de forma diferente:
tcp_incoming_address 5.6.7.8
tcp_outgoing_address 10.0.0.2
udp_incoming_address 5.6.7.8
udp_outgoing_address 10.0.0.2
Y finalmente hay que definir la máquina para la que se quiere acelerar:
httpd_accel_host 10.0.0.2
httpd_accel_port 80
Todo esto viene descrito en profundidad en el FAQ de Squid en: http://squid.nlanr.net/Squid/FAQ/FAQ.html (sección 20).
Las ACL’s funcionan definiendo las reglas, y después aplicando esas reglas, por ejemplo:
acl redinterna 10.0.0.0/255.0.0.0
http_access allow redinterna
http_access deny all
Lo que define "redinterna" como cualquier cosa con origen en 10.0.0.0/255.255.255.0, permitiendo acceso al puerto http de caché, y denegando el resto. Recuerda que las reglas se leen en el orden en que se introducen, igual que con ipfwadm, permitiéndote llegar a alcanzar un buen grado de complejidad (y cometer errores si no se tiene cuidado). Empieza siempre con reglas específicas seguidas por reglas más generales, y recuerda poner negaciones en blanco después de permisos específicos, o si no podrían atravesarlo. Es mejor denegar algo por accidente que dejarlo pasar, pues se van a encontrar más rápidamente las denegaciones (generalmente provenientes de usuarios enfadados) que las que lo atraviesan (cuando un usuario enfadados se dé cuenta de que los ficheros de contabilidad del servidor www interno aparecen en Internet). Los ficheros de configuración de Squid (squid.conf) están bien comentados (en extremo) y también tiene una página de manual decente.
Otro ejemplo útil es el bloqueo de anuncios, para bloquearlos se puede añadir lo siguiente a la configuración de squid.conf:
acl anuncios dstdomain anuncios.blah.com
http_access deny anuncios
La declaración acl es simplemente un patrón, ya sea un nombre de dominio de destino, un nombre de dominio origen, regex, etc, en realidad la directiva http_access especifica qué hacer con ello (denegarlo, permitirlo, etc). Configurado correctamente es una herramienta extremadamente potente para restringir acceso al WWW. Por desgracia tiene un talón de Aquiles: no soporta autentificación basada en el usuario (no es que lo soporten muchos servidores de proxy para UNIX). Recuerda que al igual que cualquier otro tipo de reglas, se leen de arriba hacia abajo, de modo que hay que poner las denegaciones o permisos al principio, el FAQ de Squid está en: http://squid.nlanr.net/Squid/FAQ/FAQ.html
Un elemento importante de seguridad de Squid que se suele obviar son los ficheros de log que almacena. Por defecto Squid puede o no hacer un log de cada petición que maneja (depende del fichero de configuración), de http://www.nsa.gov/ a http://porno.com/cgi-bin/access&member=segismundo&password=sotogrande. Definitivamente es preferible deshabilitar los logs, a menos que se quiera saber con detalle lo que la gente ve en Internet (legalmente es cuestionable, consulta con tu abogado). La directiva es "cache_access_log" y para deshabilitarla se configura como "/dev/null", lo cual guarda log de TODOS los accessos, y las peticiones ICP (comunicaciones inter-cache). Lo siguiente es "cache_store_log", que es en realidad medio útil para generar estadísticas de lo efectiva que es tu caché www, no guarda log de quién ha hecho la petición, simplemente de cuál es el estado de los objetos de la caché, de modo que en este caso se verían las imágenes de un sitio pornográfico repetidamente servidas, así que desactívalo con "none". El "cache_log" probablemente debería dejarse activado, contiene información básica de debug, como la hora en que se inició el servidor y cuándo se paró, para desactivarlo, dejarlo en "/dev/null". Otro fichero de log no tan bien documentado es el "cache_swap_log", que lleva un registro de lo que está pasando con la caché, y también mostrará las URL’s que la gente está visitando (pero no quién/etc), configurarlo en "/dev/null" no funciona (de hecho Squid casca bruscamente) y configurarlo en "none" simplemente cambia el nombre de fichero de "log" a "none". La única forma de pararlo es enlazar el fichero a "/dev/null" (el raíz por defecto de los ficheros de la caché www /log), y también enlazar el "log-last-clean" a "/dev/null" (aunque durante mis rápidas pruebas no me ha parecido que guarde nada de lo que no se pueda estar seguro). Resumiendo:
en squid.conf:
cache_access_log /dev/null
cache_store_log none
cache_log /dev/null
y enlazar:
/var/spool/squid/log con /dev/null
/var/spool/squid/log-last-clean con /dev/null
o cualquiera que sea el directorio que mantiene el raíz de la caché www (los directorios 00 a 0F).
Otro elemento importante que se suele olvidar es el component ICP (Protocolo de Caché Internet). La única vez que se usará ICP es cuando se creen arrays o cadenas de servidores de proxy. Si eres como yo, sólo tienes un servidor de proxy y el ICP lo tienes definitivamente desactivado. Esto se hace fácilmente configurando el puerto ICP de squid.conf cambiando el "3130" que viene por defecto por el "0". También se debería filtrar de Internet el puerto 3128, con el cortafuegos (el puerto por defecto al que se enlazan los clientes).
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 3128
ipfawdm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 3128
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 3128
o con ipchains:
ipchains –A input –p all –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 3128
ipchains –A input –p all –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 3128
ipchains –A input –p all –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 3128
squidGuard
squidGuard te permite poner listas de control de acceso, filtrar listas y redireccionar peticiones, de manera fácil y eficiente. Es ideal para controlar el acceso al WWW, y para tareas más específicas, como bloquear contenidos pornográficos (algo válido para mucha gente). Sin embargo no se pueden tomar decisiones basadas en el contenido, simplemente consulta con las URL’s procesadas, de forma que no se puede utilizar para bloquear contenido activo, etc. squidGuard se encuentra disponible en: http://info.ost.eltele.no/freeware/squidGuard/
DeleGate
DeleGate es un proxy multiprotocolo con soporte para HTTP, NNTP, FTP, proxy SSL y más. Además de esto tiene controles de acceso y de rendimiento bastante buenos. Se puede conseguir en: http://wall.etl.go.jp/delegate
Copyright © 1999, Kurt Seifried, José Antonio Revilla
Todos los derechos reservados.