Apuntes sobre el error de Squid / SquidGuard en Debian: Solucionado
La configuración mínima necesaria para Squid3 parece ir de la siguiente forma:
acl usuarios src 10.40.20.0/24 acl usuarios src 10.20.20.0/24 acl Safe_ports port 80 443 8080 20 21 ## Según https://forums.gentoo.org/viewtopic-t-952948-start-0.html ## Hay que comentar esto en Squid 3.4 porque ya esta configurado por defecto # acl manager proto cache_object acl CONNECT method CONNECT acl NONE method NONE ftp_passive off host_verify_strict on http_access deny NONE http_access deny !Safe_ports http_access allow usuarios http_access deny all ## Es necesario que hay al menos uno sin intercept http_port 10.20.20.1:3128 ## TODO: ¿Funcionará al descomentar lo siguiente? # http_port 10.20.20.1:3128 intercept http_port 10.40.20.1:3128 intercept cache_mem 469 MB ## TODO: Ni siquiera recuerdo el origen de estas líneas, pero su funcionamiento no tiene ## implicaciones sobre nuestro problema #cache_dir aufs /var/spool/squid3 500 16 256 #cache_dir aufs /var/spool/squid3-${process_number} 500 16 256 min-size=322560 #debug_options 84,1 #debug_options 85,2 debug_options ALL,2 coredump_dir /var/spool/squid3/dump url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf -d url_rewrite_children 5 startup=0 idle=1 concurrency=3 url_rewrite_host_header off refresh_pattern . 0 20% 4320 relaxed_header_parser warn connect_timeout 20 seconds shutdown_lifetime 3 seconds cache_mgr fws@salud.gob.sv httpd_suppress_version_string on visible_hostname firewall.dominio.com error_default_language es-sv prefer_direct on check_hostnames on dns_retransmit_interval 2 seconds dns_timeout 1 minutes dns_nameservers 10.10.20.20 10.10.20.21 dns_v4_first onLa configuración mínima necesaria en squidGuard, y estoy hablando que esto es apenas un ejemplo para nada funcional de como va a trabajar realmente:
# # CONFIG FILE FOR SQUIDGUARD # # Caution: do NOT use comments inside { } # dbhome /var/lib/squidguard/db logdir /var/log/squidguard # # TIME RULES: # abbrev for weekdays: # s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat time laboral { weekly * 00:15 - 12:29 weekly * 13:15 - 23:55 } # # SOURCE ADDRESSES: # src usuarios { ip 10.20.20.0/24 } # # DESTINATION CLASSES: # # [see also in file dest-snippet.txt] dest deportes { domainlist BL/recreation/sports/domains log deportes.log } dest webtv { domainlist BL/webtv/domains log ocio.log } #dest adult { # domainlist BL/adult/domains # urllist BL/adult/urls # expressionlist BL/adult/expressions # redirect http://admin.foo.bar.de/cgi-bin/blocked.cgi?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&targetgroup=%t&url=%u #} # # ACL RULES: # acl { usuarios { pass !in-addr !deportes !webtv any } default { pass none redirect http://admin.foo.bar.de/cgi-bin/blocked.cgi?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&targetgroup=%t&url=%u } }Esto funcionaba en Debian Squeezy/Wheezy perfectamente. Tiene la ventaja de ser presumiblemente rápido a la hora de filtrar tráfico, la configuración se realiza por medio de ACL que son bastante fáciles de entender y tiene altas posibilidades con las listas En Debian Jessie hay un problema con las versiones presentes en los respositorios, precisamente en la forma en que squid3 le comunica los datos de la petición HTTP al redirector SquidGuard. Cuando se hace una prueba a redireccionar desde squidGuard
$ echo "http://anontv.com 10.20.20.11 - - GET" | squidGuard -c /etc/squidguard/squidGuard.conf OK rewrite-url="http://admin.foo.bar.de/cgi-bin/blocked.cgi?clientaddr=10.20.20.11&clientname=&clientuser=&clientgroup=usuarios&targetgroup=webtv&url=http://anontv.com"Mientras que /var/log/squid3/cache.log es posible ver
2016/06/14 19:22:20.711 kid1| client_side_reply.cc(1969) processReplyAccessResult: The reply for GET http://admin.foo.bar.de/cgi-bin/blocked.cgi?clientaddr=http:&clientname=/www.anontv.com/&clientuser=10.20.20.1/firewall.salud.gob.sv&clientgroup=default&targetgroup=none&url=0 is ALLOWED, because it matched 'usuarios'cuando se hace una petición a squid3 desde un equipo cliente. Usando un navegador, telnet o algo como wget. Por lo pronto no encuentro la solución a este problema, ahora mismo estoy bajando el DVD de Debian Testing, quizá en Strech los paquetes disponibles ya no tengan ese problema. Puede verse como el clientaddr que devuelve SquidGuard es diferente en cada caso. Así que debemos suponer que ese es el valor que squidGuard toma como IP a la hora de relacionarlo con las ACL.
Fuentes:
No hay comentarios:
Publicar un comentario