noviembre 22, 2014

Squid Cache II

Log personalizado TCP_DENIED/403
Last Update: Feb 19/2016
En la primera parte del post Squid Cache explicamos algunos parámetros para mejorar el funcionamiento del Squid y por ende de nuestro proxy cache. También en nuestra serie Firewall detallamos que para el filtrado podíamos utilizar ACLs con usos específicos, independientemente de si es un proxy manual o transparente, sin embargo esto puede ser un arma de doble filo; pero veamos mejor el siguiente escenario:
Supongamos que tenemos un proxy en Linux con Squid (o cualquiera de sus derivados), y lo ponemos en modo transparente (192.168.1.10 es la ip del server), para no tener que enredarnos con configurar el proxy en cada navegador de cada usuario, ni rompernos la cabeza con WPAD / PAC.
# Squid normally listens to port 3128
http_port 192.168.1.10:3128 intercept
Y el filtrado https (puerto 443) lo hacemos por el Iptables, con una ACL que contiene las IPs que solo queremos dejar pasar y el resto de las conexiones en DROP, tal y como se explica en el post Firewall.
En este tipo de configuración el Squid filtraría el tráfico por el puerto 80, que puede ser supervisado en tiempo real por la aplicación web SqStat (o cualquier otra de preferencia del administrador IT).
Si ponemos una ACL en el Squid, tipo blacklist, que se encargue del bloqueo de sitios. Para mayor información visite el proyecto blacklistweb.com
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl blacklistweb dstdomain -i "/home/servidor/acl/blacklistweb"
http_access deny blacklistweb
Entonces cada vez que accedamos a una URL por HTTP, incluida en esta ACL "blacklist", obviamente seríamos bloqueados. Y si por error bloqueamos un sitio legítimo, el camino más expedito es ir a la ACL blacklist y sacar la URL bloqueada accidentalmente. Hasta aquí la película es más o menos aburrida. Ahora lo importante...
Múltiples ACLs
Puede darse el caso de que nuestro servidor con Squid maneje varias ACLs que realicen diferentes tipos de bloqueos. Por ejemplo:
acl whiteips src "/home/servidor/acl/whiteips"
acl blacklistweb dstdomain -i "/home/servidor/acl/blacklistweb"
acl no_ip dstdom_regex -i ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$
acl rwords url_regex -i "/home/servidor/acl/rwords"
acl extensiones url_regex "/home/servidor/acl/ext"
acl archivos-bloqueados rep_mime_type -i "/home/servidor/acl/ext-mime"
http_access deny blacklistweb
http_access deny no_ip !whiteips
http_access deny rwords
http_reply_access deny ext
http_access deny ext-mime
Donde:
whiteips: Contiene ips permitidas
blacklistweb: Contiene sitios restringidos http. (Visite blacklistweb.com)
no_ip: Bloquea las peticiones a IPs por http (solo se permiten URLs)
rwords (restricted words): Contiene palabras a bloquear, ejemplo: "porno", "proxy", "sex", etc
ext: Bloquea extensiones como #\.scr$, #\.ink$, \.exe, \.msi, \.iso, etc
ext-mime: Similar a la anterior pero utilizando mime-type. Ejemplo: ^application/exe$, ^application/ogg$, ^application/exe$, ^application/x-msi$, ^vnd.ms-cab-compressed$, etc
Nota: se utilizan dos ACLs similares para las extensiones, por si un archivo con extensión no deseada, logra "saltarse" la restricción de una ACL, la segunda pueda bloquearlo, ya que son dos métodos diferentes de bloqueo de extensiones. Las extensiones también pueden ser filtradas en el Iptables. Vea el post Firewall
Supongamos entonces que un usuario está suscrito a las publicaciones de nuestro blog y le llega un mail de feedburner con este post. El usuario abre el enlace feedproxy.google.com y de pronto le sale un mensaje en su navegador PÁGINA RESTRINGIDA (o el mensaje que esté configurado en el Squid para las situaciones de bloqueo). Habla con el administrador IT y busca la URL bloqueada en las ACLs, pero no aparece. Como maneja varias ACLs el próximo paso más lógico es revisar los logs del Squid.
Suponiendo que tengamos activo en su Squid el cache.log.
#Default:
cache_log /var/log/squid3/cache.log
Y esté bien configurado el access.log...
access_log /var/log/squid3/access.log squid
Entonces procedemos a leerlo...
tail -f /var/log/squid3/access.log
Y en ese mar de líneas, encontramos el siguiente mensaje:
416669690.372 108 192.168.1.40 TCP_DENIED/403 417706 GET http://feedproxy.google.com/~r/fan_de_este_puto_sitio/~3/Q5y7jB2v9ZA/leyendo_estupideces_en_internet.html? - NONE/- text/html
El cual contiene la información de al IP local que generó la petición (192.168.1.40), sitio bloqueado (http://feedproxy.google.com) y la leyenda TCP_DENIED/403 (indíca bloqueo), entre otros parámetros, pero el mensaje no cita nada acerca cuál ACL es la responsable del bloqueo. Sin embargo existe una forma de manipular el Squid para conocer la actividad del mismo y por consecuencia la ACL responsable del bloqueo TCP_DENIED/403 y es activando el 'modo de depuración' o debug_options.
Por default, el Squid no lo trae activo, pero muestra la leyenda:
#Default:
# debug_options ALL,1
Entonces si descomentamos esta línea y cambiamos el 1 por el 9, sabremos todos los detalles de lo que hace el Squid, incluyendo el bloqueo y su responsable.
#Default:
debug_options ALL,9
En este punto muchos se dirán que con un simple...
sudo grep -i checklistmatches /var/log/squid3/cache.log
o
sudo grep -i feedproxy /var/log/squid3/cache.log
...sabríamos de inmediato quién es el responsable del bloqueo al sitio feedproxy.google.com. Es cierto, pero tiene un precio muy alto, ya que cuando el debug_options se encuentra en nivel ALL,9 (Full debugging) y lanzamos el comando grep, el servidor puede colapsar, porque, como Squid registra cada evento de manera pormenorizada, el archivo cache.log se llena al punto de volverse inmanejable (puede llegar a ocupar más de 20 GB en una red local con un tráfico de apenas 30 equipos). Es por esta razón que explicaremos otras opciones más viables de modificar el debug.
Modificando debug_options (opciones de depuración)
Ahora modificaremos debug_options para que registre lo que necesitamos, pero NO TODO, para evitar la congestión de cache.log, descomentando la línea que viene por default y con esta acción sería suficiente:
#Default:
debug_options ALL,1
Sin embargo se recomienda que también habilite la sección 33 del nivel 2 y 28 del nivel 9
#Default:
debug_options ALL,1 33,2 28,9
Para que cache.log registre, en el caso de 33,2 el match de las reglas y 28,9 el procesamiento de las ACLs. Estas opciones son muy importantes sobre todo si tenemos más de un http_access y http_access deny. Con ellas podremos saber el último intento de acceso y la información sobre las ACLs que hacen match con el TCP_DENIED/403.
También podemos echar mano de otras opciones...
#Default:
debug_options ALL,2 28,4 82,4
En fin, debug_options tiene infinidades de alternativas de configuración. Para conocerlas visite DebugSections; sin embargo tenga en cuenta que a mayor cantidad de secciones activas en el debug_options, el cache.log se llenará más rápido y al ejecutar un grep corre el riesgo de hacer colapsar su servidor, si éste no es lo suficientemente robusto.
Reinicio y verificación
Finalmente guardamos los cambios y reiniciamos el Squid (o lo reconfiguramos para que tome los cambios sin reiniciar).
sudo service squid3 restart
o
sudo squid3 -k reconfigure
Y verificamos que nuestro Squid no tenga errores.
sudo squid3 -k parse
Ahora podemos acceder a la URL bloqueada y el archivo cache.log registrará la ACL culpable. Para hacerlo más rápido, usamos el comando grep
sudo grep -i feedproxy /var/log/squid3/cache.log
Y el resultado es:
2014/11/22 10:39:05.872| The request GET http://feedproxy.google.com/favicon.ico is DENIED, because it matched 'rwords
Entonces la ACL responsable es "rwords", ya que, al tener incluida la parabra "proxy" (para realizar bloqueo de cualquier petición que incluya esta palabra), restringió también el portal feedproxy.google.com.
Es por esta razón que utilizar un bloqueo en el Squid, basado en expresiones no es muy recomendable.
Registro de eventos personalizado (opcional)
Una buena alternativa es crear un archivo de log que registre solamente los bloqueos tipo TCP_DENIED/403, para poder supervisar mejor lo que está rechazando el Squid (también se puede hacer con otros tipos de mensajes de access.log. Para mayor información sobre los diferentes mensajes de access.log visite Analizar los logs de access.log de squid y para los mensajes de error TCP_Denied cuando está activo NTML, visite BlueCoat)
Lo anterior se logra modificando el squid.conf y agregándole lo siguiente, (creando primero deny.log con sus respectivos permisos):
acl DENY_ACCESS http_status 403
access_log /var/log/squid3/deny.log squid DENY_ACCESS
Ahora en deny.log (pueden llamarlo como gusten) se guardarán solamente los registros de bloqueos (403) del Squid. Para mayor comodidad puede visualizarlos en el webmin, tal y como se muestra en la imagen al principio del post.
Muy Importante
Los parámetros de debug_options se procesan de forma secuencial y el último valor reescribe el primero, por tanto se recomienda especial cuidado a la hora de escribir los valores. Ejemplo:
debug_options 9,5 20,9 4,2 ALL,1
En este caso, el valor final sobreescribirá los anteriores, porque ALL,1 selecciona el nivel de 'debugging' a 1 para todas las secciones. Para mayor información sobre este punto lea el E-Book Squid: The Definitive Guide de Duane Wessels.
También se recomienda encarecidamente no dejar activas permanentemente las secciones (parámetros) de depuración (debug_options) descritos anteriormente. Una vez que haya diagnosticado el problema, se sugiere desactivarlos. Puede dejar el modo depuración en ALL,1 (en dependencia de sus necesidades) para que Squid solamente registre eventos esenciales.

Problemas conocidos
a. Muchos son los escenarios en los que puede presentarse el error squid: ERROR: No running copy y ocurre cuando reiniciamos después de los cambios. A veces en el terminal muestra el squid reiniciando normalmente con el mensaje "ok", sin embargo no inicia. El problema es de permisos. Acceda a los logs del sistema (/var/log/syslog) y haga una búsqueda de la palabra "writeable", "Permission denied", "squid" o expresiones similares y encontrará el responsable:
Cannot open '/var/log/squid3/deny.log' for writing.#012#011The parent directory must be writeable by the#012#011user 'proxy', which is the cache_effective_user#012#011set in squid.conf
La solución es asignarle los permisos correspondientes chmod (para este ejemplo el archivo deny.log pero puede ser ocasionado por cualquier otro archivo) y reinicie squid y apache:
sudo chmod 666 /var/log/squid3/deny.log && sudo squid3 -k reconfigure | sudo invoke-rc.d apache2 reload
b. Puede parametrizar el Logformat (que se encarga de darle un formato específico a los log del squid), sin embargo tenga presente que si lo modifica puede presentarse conflicto con Sarg. En este caso puede optar por la alternativa de ver el access.log con el formato adecuado por terminal:
tail -f /var/log/squid3/access.log | perl -pe 's/[\d\.]+/localtime($&)/e'
Para más información visite el foro Alterserv
c. Si después de parametrizar su squid.conf y reiniciar squid3 (o verificar con sudo squid3 -k parse) sale un mensaje similar a:
WARNING: Netmasks are deprecated. Please use CIDR masks instead
WARNING: IPv4 netmasks are particularly nasty when used to compare IPv6 to IPv4 ranges
WARNING: For now we will assume you meant to write /32
Significa que su versión de squid3 ya no soporta mascaras de subred. En su reemplazo deberá especificar el CIDR. Para el caso de 255.255.255.255 es 32. Para mayor información consulte la siguiente tabla CIDR.
Y si Squid al reiniciar genera un mensaje de tipo:
Page faults with physical i/o
Entonces revise su squid.conf, en especial los parámetros relacionados con la memoria (cache_mem, etc), ya que está haciendo swapping.
d. En las versiones más recientes de Squid, no se puede utilizar el puerto 3128 con la cláusula intercept (antes transparent) ya que genera el error: "No forward-proxy ports configure" (/var/log/squid3/cache.log). El puerto por default para proxy transparente es 8080 (NAT), sin embargo puede utilizar cualquier otro puerto, para cualquier proxy, siempre que no sea reservado.
Para mayor información lea el post No Forward-proxy ports configure
e. Error 'pinger'
De acuerdo con fossies.org, 'pinger' es un programa de sonido (ping) de Squid que especifica la localización del ejecutable para proceso de sonido de ping. Esto es sólo útil si has configurado Squid (durante la compilación) con la opción '--enable-icmp'. Según Pfsense, interviene en el proceso de caché padre.
Sea cual sea su uso, genera error en la versión squid3 v3.3x y está reportado como Bug. Para desactivarlo o eliminar el error, (o ambas) realice lo siguiente:
# Modifique Pinger
sudo chmod 4755 /usr/lib/squid3/pinger
sudo /usr/lib/squid3/pinger
# Configurar Squid3
sudo gedit /etc/squid3/squid.conf
# Modifique la linea de pinger a off
pinger_program /usr/lib/squid3/pinger
pinger_enable off
# Reinicie squid
sudo service squid3 restart
Y a no ser que se requiera específicamente, se recomienda desactivar la directiva emulate_httpd_log. Por defecto viene inactiva
emulate_httpd_log off
e. TCP_MISS_ABORTED/000
Cuando este error (y otros. Vea el post Proxy) se presenta asociado a una IPv6, es debido a que las versiones recientes de squid soportan ambas versiones del protocolo. La solución es agregar al squid el parámetro:
dns_v4_first on

Continua Squid Cache III
Maravento, Actualizado en: 20:58
Escrito por: Maravento Studio
 
© 2017 Maravento. All Rights Reserved | Powered by Maravento
Design by Novatoz and Maravento | Bloggerized By LawnyDesignz
# https://github.com/google/code-prettify