Ej. Práctico 3.2.2: Proxy No Transparente con Autenticación Digest Solución Ej. Pr. 3.2.2.I.- Configuración de un Proxy No Transparente Auth. Digest .........................................................................................................................................99

Práctica Nº3.-Proxy HTTP Caché. Squid

¡¡Importante!! Para comprobar quien se autentica o los contenidos que va cacheando nuestro Proxy, pueden consultarse los archivos *.log de auditoría indicados en su configuración: [root@mv1]# more /var/log/squid3/store.log [root@mv1]# tail -f /var/log/squid3/store.log (nos irá mostrando en tiempo real lo que cachea) [root@mv1]# more /var/log/squid3/access.log [root@mv1]# tail -f /var/log/squid3/access.log [root@mv1]# more /var/log/squid3/cache.log [root@mv1]# tail -f /var/log/squid3/cache.log

No obstante, al final del presente capítulo, se propondrá un ejercicio práctico para mostrar vía Web el contenido del fichero de auditoria.

Ej. Práctico 3.2.2: Proxy No Transparente con Autenticación Digest

Con la finalidad de completar al ejercicio anterior, en el presente ejercicio se mostrará como configurar squid para ofrecer un servicio Proxy donde la autenticación se hace mediante el método digest, el cual nos garantiza que las contraseñas introducidas por el usuario desde su equipo cliente viajen al servidor de manera cifrada. Solución Ej. Pr. 3.2.2.I.- Configuración de un Proxy No Transparente Auth. Digest

Para cambiar el tipo de autenticación de basic a digest en nuestro Proxy será necesario modificar aquellas directivas utilizadas en el ejercicio anterior relativas a "auth_param basic". Además la librería encargada de la autenticación ya no será "ncsa_auth", sino que ahora utilizaremos "digest_pw_auth". El aspecto que deberá tener nuestro nuevo archivo de configuración "squid.conf" será ahora el siguiente (las principales directivas usadas ya se han comentadas en el ejercicio anterior, por lo que no se volverá a hacerlo): [root@mv1:/etc/squid3]# nano squid.conf # Directivas globales visible_hostname miproxy

http_port 3128 http_port 8088

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 99

Práctica Nº3.-Proxy HTTP Caché. Squid

cache_mem 32 MB cache_dir ufs /var/spool/squid3 1000 16 256 maximum_object_size_in_memory 128 MB

access_log /var/log/squid3/access.log cache_log /var/log/squid3/cache.log cache_store_log /var/log/squid3/store.log

auth_param digest program /usr/lib/squid3/digest_pw_auth -c /etc/squid3/claves-digest.dat auth_param digest children 5 auth_param digest realm proxy-digest

acl autenticacion proxy_auth REQUIRED acl cualquier-maquina src all acl maquina1 src 192.168.2.101 acl websprohibidas1 dstdomain "/etc/squid3/websprohibidas1.dat" acl websprohibidas2 url_regex "/etc/squid3/websprohibidas2.dat" http_access deny maquina1 http_access allow cualquier-maquina autenticacion !websprohibidas1 !websprohibidas2

Antes de chequear la configuración anterior, y reiniciar el servicio, generaremos el nuevo archivo de autenticación de usuarios, llamado en este ejercicio "claves-digest.dat". Para su creación existen dos posibles opciones (se recomienda por sencillez la primera, htdigest): (1ª opción) Mediante el comando "htdigest" (al igual que "htpasswd", disponible a través del software apache2). Su sintaxis y uso es la siguiente (la opción "-c" es para crear el fichero de autenticación, y el realm el indicado en la configuración anterior): [root@mv1:/etc/squid3]# htdigest [-c] [ruta_archivo_de_autenticación] [realm] [nombre_usuario]

Por tanto, según lo establecido en los requisitos del enunciado, el fichero de usuarios del Proxy para autenticación digest quedaría de la siguiente manera: [root@mv1:/etc/squid3]# htdigest -c /etc/squid3/claves-digest.dat proxy-digest usuproxy1 [root@mv1:/etc/squid3]# htdigest /etc/squid3/claves-digest.dat proxy-digest usuproxy2 [root@mv1:/etc/squid3]# htdigest /etc/squid3/claves-digest.dat proxy-digest usuproxy3

(2ª opción) Mediante el comando "md5sum". Este comando nos permite generar una contraseña útil para la autenticación digest. Por ejemplo, si queremos dar de alta un usuario llamado "usuproxy1", dentro de la zona de autenticación con realm "proxy-digest", y contraseña "1", el siguiente comando nos generaría la contraseña cifrada que habría que introducir el el archivo de contraseñas: [root@mv1:/etc/squid3]# echo -n 'usuproxy1:proxy-digest:1' | md5sum | cut -f1 -d' '

Como el resultado habría que dejarlo en el fichero de autenticación de usuarios y contraseñas establecido en "squid.conf", claves-digest.dat siguiendo el formato

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 100

Práctica Nº3.-Proxy HTTP Caché. Squid

"usuario:realm:contraseña_cifrada", podríamos hacer lo siguiente (es un poco más engorroso, pero es otra opción posible): [root@mv1:/etc/squid3]# echo "usuproxy1:proxy-digest:`echo -n 'usuproxy1:proxy-digest:1' | md5sum | cut -f1 -d' '`" >> claves-digest.dat

¡¡Aclaración!! Por su sencillez se recomienda la utilización del comando htdigest para la creación del fichero de autenticación de usuarios digest. No obstante, se ha comentado esta segunda opción mediante md5sum, para comprender que htdigest lo que 'por debajo' es simplemente hacer uso de md5sum. Más tarde, en los ejercicio 3.16 y 3.1.7 se implementará un portal cautivo en PHP bajo apache2 donde la autenticación la realizaremos mediante esta misma técnica de cifrado de claves, md5.

Después de todo lo anterior tan sólo nos quedará reiniciar el servicio para que surtan efecto los cambios en la configuración, aunque antes comprobaremos que no hayamos cometido algún error sintáctico o semántico ("-k check" o "-k parse" nos proporcionan información equivalente): [root@mv1]# squid3 -k check [root@mv1]# squid3 -k parse [root@mv1]# /etc/init.d/squid3 restart

Al comprobar su correcto funcionamiento desde un cliente Web, nos aparecerá la correspondiente ventana de autenticación:

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 101