Proyecto para migrar de Netasq U70 a Pfsense (squid3-devel)

bellera

Con tanto movimiento sobre squid3-devel en el foro veo que en este hilo no está:

Antivirus Clamav en squid3-devel (i386)
http://egoncalves.com.br/pfsense/pfsense-squid3-dev-clamav-i386/
Para 64 bit (amd64), parece que no funciona, https://forum.pfsense.org/index.php?topic=72872.msg400869#msg400869

No sé si seguiste este tutorial…

gromero

Si lo he seguido y creo que correctamente, los servicios clamd y icap están en marcha pero sale ese error, squid3-dev y squidguard funcionan pero con la opción antivirus desactivada. La diferencia en mi instalación es que al correr en ssd he configurado para que /tmp /var se monten en ramdisk. Para evitar que se pierdan las bases de datos en los reinicios configuré clamd y freshclam para que ubiquen las db en /usr/local/db/clamav. Lo que observo es que tengo que crear un script de inicio para crear el usuario clamav porque después de reiniciar no se porque se pierde.

bellera

No veo por qué esos cambios que dices deberían ser un problema.

Pero ante la duda quizás deberías hacer las pruebas con /tmp y /var en el SSD.

A ver si sucede lo mismo.

En cuanto al usuario clamav, no deja de ser curioso. Igual se debe a que el usuario debería estar definido como administrador en el configurador de pfSense. En FreeBSD los usuarios que pueden llegar a root tienen que estar en el grupo wheel. Por eso digo de configurarlo como administrador.

gromero

Hola,

Vamos avanzando, finalmente parece que están todos los servicios en funcionamiento y siguen funcionando entre reinicios (habia problemas con esto) el proxy funciona y filtra la web, pero el antivirus que antes no permitía la navegación (error de protocolo icap) ahora parece que no detecta nada pues me permite descargar el virus eicar sin advertirlo (http://www.eicar.org/85-0-Download.html). Habilite las opciones clamd_ip y clamd_port en squidclamav.conf y servername en c-icap.conf y creo que gracias a esto dejo de dar el error de protocolo pero como digo no detecta el eicar.

Hay otras cosas que no termino de tener claras, tengo activado el proxy en modo transparente, y el webConfigurator esta configurado en el puerto 2345, por lo que entiendo que si las paginas de error o bloqueo se sirven con el mismo servidor web, no debería ser problema usar la página interna para anunciar los bloqueos sin embargo ocurre algo raro, si configuro el webconfigurator para que se sirva por http si funcionan la página interna de bloqueo del proxy, pero si configuro el webconfigurator para que vaya por https, no se muestra nada y el cliente no encuentra la página.

Algo parecido pasa con el portal cautivo, si lo configuro para que use http, funciona y veo que direcciona al puerto 8000 para mostrar la página de identificación, si lo configuro para que use https, direcciona al puerto 8001 pero la página no es accesible y nunca carga.

¿Ideas?

Saludos a todos.

bellera

Proxy Server: ACLs

acl sslports	
This is a space-separated list of ports to allow SSL "CONNECT" in addition to the already defined list: 443 563

Tienes que añadir el puerto 2345 ahí, si no lo hiciste.

A ver qué tal.

gromero

Gracias Bellera por tu paciencia,

Efectivamente, no había añadido estos puertos, y por si acaso añadí para ver si se soluciona lo del portal cautivo también quedando la cosa así:

acl safe ports : 2345 8000 8001
acl ssl ports: 2345 8001

Activé el web configurator y el portal cautivo para usar https, pero el resultado sigue siendo en el caso del bloqueo de squidguard sale el error del proxy diciendo que http://192.168.4.200:2345/sgerror.php? respuesta vacía(tamaño cero) y en el caso del portal cautivo sencillamente se queda esperando hasta que pasa el tiempo de espera y no carga nada.

Un saludo

bellera

Discutimos esto ya. ¿Probaste lo comentado?

@bellera:

Por tanto, si en Custom Options del configurador de squid añades:
http_port 127.0.0.1:3128 intercept
squid pasa (si respeta eso) a modo transparente.

y el redireccionamiento
rdr on em0 inet proto tcp from any to ! (em0) port = http -> 127.0.0.1 port 3128
debería ser, a mi entender:
rdr on em0 inet proto tcp from !127.0.0.1 to ! (em0) port = http -> 127.0.0.1 port 3128
si la sintaxis de rdr lo admite.

Los rdr en el configurador de pfSense son los NAT Port Forward.

em0 es mi LAN address (mi placa de red LAN).

A ver si hay suerte…

gromero

Cuando me propusiste esto entendí que era para el caso de que no usase el modo transparente y yo quisiese controlar las redirecciones, pero como comencé de nuevo con la versión i386 y estoy usando el modo transparente, no lo creí necesario. Lo probaré.

Saludos.

gromero

Ahora mismo no tenía activas las redirecciones, si intento añadir la que propones sale esto:

[2.1-RELEASE][admin@firewall]/root(3): rdr on re4 inet proto tcp from !127.0.0.1 to ! (re4) port = http -> 127.0.0.1 port 3128
127.0.0.1: Event not found.

Saludos.

gromero

Lo he intentado hacer desde el webconfigurator y me sale esto(que no es lo mismo ¿o si?):


[2.1-RELEASE][admin@firewall]/root(6): pfctl -s nat | grep re4
rdr on re4 proto tcp from ! <localhost>to ! <localhost>port = http -> <localhost>port 3128 round-robin
rdr on re4 proto tcp from ! <localhost>to ! <localhost>port = https -> <localhost>port 3129 round-robin
rdr on re4 inet proto tcp from any to ! (re4) port = http -> 127.0.0.1 port 3128
rdr on re4 inet proto tcp from any to ! (re4) port = https -> 127.0.0.1 port 3129</localhost></localhost></localhost></localhost></localhost></localhost>

Pero el resultado sigue siendo el mismo: si habilito https para el portal cautivo y webconfigurator, no se abre el portal, si habilito https para el webconfigurator y no para el portal cautivo, el cliente se conecta y navega, pero la redirección de pagina bloqueada interna no esta accesible, con el portal cautivo y el webconfigurator por http todo funciona.

Saludos.

gromero

Sigo intentando pero he visto que al menos con https activado para el webconfigurator, squidguard siempre redirecciona los bloqueos a http://192.168.4.200:2345/sgerror.php? independientemente de lo que que ponga en modo de redirección y url de redirección. Creo esto porque el mensaje del proxy siempre es el mismo, indicando lo de respuesta vacia de esta dirección.

bellera

@gromero:

Si intento añadir la que propones sale esto:

[2.1-RELEASE][admin@firewall]/root(3): rdr on re4 inet proto tcp from !127.0.0.1 to ! (re4) port = http -> 127.0.0.1 port 3128
127.0.0.1: Event not found.

Cualquier acción desde consola sobre PF (Packet Filter) tienes que hacerla con el comando pfctl. Lo que pusiste es sólo una regla de PF.

Lo que quería decir es que si es un rdr tienes que entrarlo en Firewall - NAT Port Forward del configurador web. Disculpa por no explicarme más claramente.

bellera

@gromero:

Lo he intentado hacer desde el webconfigurator y me sale esto(que no es lo mismo ¿o si?):

localhost es lo mismo que 127.0.0.1

Recordemos a quien pueda leer esto que lo que se pretende es que squid3-dev + squidGuard-squid3 tengan los avisos de squidGuard-squid3 en el propio pfSense a pesar de estar en modo transparente. Cuestión que el configurador web de squidGuard dice que no puede ser:

Redirect mode	
Select redirect mode here.
Note: if you use 'transparent proxy', then 'int' redirect mode will not accessible.
Options:ext url err page , ext url redirect , ext url as 'move' , ext url as 'found'.

gromero

He visto que pfctl hay que estudiarlo con tranquilidad, por lo que lo dejo para otro momento, pero no me aclaraste si:

1.-Las reglas que me indicas ¿Las debo introducir también si uso el proxy en modo transparente?.
2.-Las que yo he creado desde el webconfigurator ¿son equivalentes a la que propones?
3.-Sin haber hecho nada especial (sin crear ninguna redirección para ello ni regla) y a pesar de que el configurador indica que no es posible usar la página interna, si funciona cuando está establecido el acceso por http para webconfigurator ¿se debe a que uso el puerto 2345 para el webconfigurator?.
4.-¿Porque no funciona lo mismo usando https para webconfigurator?, He probado ha cambiar en 'common acl' el modo y la url de redirección pero parece que no hace caso, porque el proxy siempre da el mismo error. Adjunto imágenes para ver la salida en uno y otro caso. Aclaro que el cliente no tiene configurado el proxy y esta siendo redireccionado por pfsense.

Proxy_block.JPG_thumb

Proxy_block_bad.JPG_thumb

bellera

cd /usr/local/pkg
cp -p squidguard_configurator.inc squidguard_configurator.inc-2014-04-03
vi squidguard_configurator.inc

La línia que dice

$rdr_path = "http://$guiip:$guiport" . REDIRECT_BASE_URL;

cambiala por

 $rdr_path = "https://$guiip:$guiport" . REDIRECT_BASE_URL;

A ver si te funciona cuando estás en modo https.

Parece un fallo (bug) bastante evidente en squidguard_configurator.inc no prever que el webserver de pfSense debe estar sólo en este puerto y en modo SSL.

gromero

Es extraño, con el cambio que has propuesto, ahora pasa el timeout de cargar la pagina del error, que intenta encontrar en la siguiente dirección:

https://192.168.4.200:80/sgerror.php? cuando antes de añadir la 'S' era http://192.168.4.200:2345/sgerror.php?

no se porque a cambiado el puerto…

gromero

Por lo que he podido ver tras hacer el cambio y reiniciar se modificaron todas las redirecciones en /usr/pbi/squid-i386/etc/squid/squidGuard.conf que apuntan ahora al puerto 80. Porque ni siquiera dejándolo como antes funciona ahora que en vez de hacer la redirección al puerto del gui lo hace al puerto 80.

gromero

Aunque modifique manualmente /usr/pbi/squid-i386/etc/squid/squidGuard.conf o /usr/pbi/squidguard-squid3-i386/etc/squidGuard/squidGuard.conf (que son iguales) al reiniciar lo vuelve a dejar como estaba.

bellera

@gromero:

Por lo que he podido ver tras hacer el cambio y reiniciar se modificaron todas las redirecciones en /usr/pbi/squid-i386/etc/squid/squidGuard.conf que apuntan ahora al puerto 80. Porque ni siquiera dejándolo como antes funciona ahora que en vez de hacer la redirección al puerto del gui lo hace al puerto 80.

Sería lo ideal, pues no es nada elegante que las páginas de error estén en modo SSL. Problemas con el certificado y "conocimiento" del puerto usado para administrar pfSense.

Prueba:

$rdr_path = "https://$guiip:2345" . REDIRECT_BASE_URL;

Recordemos, no obstante, que en el configurador hay un aviso diciendo que si se está en modo transparente no se puede emplear la página de error interna.

¿No puedes tener un servidor web o incluso otro pfSense, virtualizado, para los avisos?

bellera

@gromero:

Aunque modifique manualmente /usr/pbi/squid-i386/etc/squid/squidGuard.conf o /usr/pbi/squidguard-squid3-i386/etc/squidGuard/squidGuard.conf (que son iguales) al reiniciar lo vuelve a dejar como estaba.

Evidente. Eso lo genera el configurador web. Es como trabaja pfSense.

Tengo bloqueado eso en mis últimos pfSense porque necesito un squidGuard.conf que el configurador web no me da. Una vez ajustado, sólo preciso modificar las listas existentes. Lo tienes explicado en https://forum.pfsense.org/index.php?topic=73759.msg404367#msg404367