Continuamos esta serie de artículos sobre el "appliance virtual" basado en Squid. Ahora ha llegado el turno de la integración con redes y dominios basados en Windows y en Active Directory. El primer paso a seguir es instalar SAMBA en nuestro FreeBSD.
Como en otras ocasiones ejecutamos sysinstall y buscamos la instalación del paquete adecuado:
Configure → Packages → net → samba34-3.4.9_1
(Obviamente el número de versión del paquete dependerá del resto de versiones de cada instalación).
Necesitamos el siguiente cambio de permisos al archivo de configuración smb.conf para garantizar que el usuario squid (usado para correr el servicio) es capaz de abrir la configuración de Samba:
chown root:squid /usr/local/etc/smb.conf
chmod 750 /usr/local/etc/smb.conf
Editamos el archivo /usr/local/etc/smb.conf y cambiamos o añadimos las siguientes líneas (cambiad los nombres de servidores, dominio, etc. por el vuestro propio):
workgroup = DEBUGMACHINE security = domain load printers = no password server = DC-01 passdb backend = tdbsam interfaces = 192.168.3.254/24 winbind uid = 10000-20000 winbind gid = 10000-20000 winbind use default domain = yes
Antes del siguiente paso, tenemos que asegurarnos de que el Appliance es capaz de resolver el nombre de host del controlador de dominio, bien mediante configuración del cliente DNS, o bien mediante el archivo /etc/hosts. Igualmente tenemos que dar al FreeBSD el nombre de host definitivo que queremos que tenga, por ejemplo, private-gw. Para ello editamos el archivo /etc/rc.conf y agregamos la línea hostname="private-gw.debugmachine.com" (no olvidéis como siempre especificar vuestro propio nombre de dominio).
También es necesario que el reloj esté sincronizado con el del controlador de dominio. Para ello tenemos que asegurarnos de que el demonio ntpd está instalado en el FreeBSD, y añadir al /etc/rc.conf las siguientes líneas:
También es necesario que el reloj esté sincronizado con el del controlador de dominio. Para ello tenemos que asegurarnos de que el demonio ntpd está instalado en el FreeBSD, y añadir al /etc/rc.conf las siguientes líneas:
ntpdate_enable="yes"
ntpdate_flags="dc-01.debugmachine.com"
Se recomienda reiniciar el equipo tras los pasos anteriores para asegurarse que todo está bien actualizado y no quedó ningún servicio por levantar.
Y ahora sí, unimos el equipo al dominio con nuestro administrador del dominio y su password:
net join -U administrador%password
Iniciamos el servicio winbindd. Es necesario para poder crear tuberías o pipes entre los servicios de autenticación y las diferentes aplicaciones (en este caso Squid).
/usr/local/sbin/winbindd
winbindd_enable=yes
Cambiamos los permisos del siguiente archivo para asegurarnos que el usuario squid nuevamente puede acceder a él:
chown root:squid /var/db/samba34/winbindd_privileged
chmod 750 /var/db/samba34/winbindd_privileged
Para ver si hasta aquí todo funciona correctamente, podemos probar a autenticar un usuario cualquiera de nuestro dominio. Si todo sale bien deberíamos tener una respuesta similar a esta:
root@private-gw:/# wbinfo -a debugmachine\\administrador%password plaintext password authentication succeeded challenge/response password authentication succeeded
Ahora nuestro appliance ya es capaz, mediante Samba/Winbind, de hacer comprobaciones de usuario y password para usuarios de nuestro dominio.
¿Qué es lo siguiente?
Ahora toca configurar nuestro Squid para que se haga cargo de todo esto. Para ello vamos a añadir las siguientes líneas al archivo /usr/local/etc/squid/squid.conf para introducir autenticadores de tipo "basic" y "ntlm". Pondremos 15 procesos "hijo" por defecto de cada tipo de autenticador, suficientes para una compañía de tamaño medio y sin llegar a saturar los recursos de la máquina:
auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 15 auth_param basic program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic auth_param basic children 15 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours
Squid permite crear ACLs o listas de acceso que sirven para controlar detalladamente los requisitos de uso del proxy. Dichas acls se escriben en el archivo squid.conf y se tienen en cuenta por el orden en que están escritas, teniendo siempre preferencia las más estrictas.
Por defecto, Squid prohíbe el acceso a todos los usuarios salvo los que cumplan algún requisito (por ejemplo, pertenecer a una subred determinada). Para ello utiliza una línea como la siguiente:
http_access deny all
Como podéis imaginar, todos los cambios y configuraciones que propondré a continuación deben estar antes de la línea mencionada o si no serán ignorados al tener prioridad la más restrictiva.
Diseñando una política de acceso
Antes de continuar con la configuración del squid.conf, es necesario tener las ideas claras de cómo será la política a implementar. Yo voy a usar una bastante simple para ilustrarlo a modo de ejemplo, pero por supuesto podría complicarse tanto como requieran nuestras necesidades (la flexibilidad de Squid es infinita).
En nuestra política se tienen que cumplir los siguientes requisitos:
- Para poder usar el proxy, es obligatorio estar autenticado (por NTLM o facilitando unas credenciales al iniciar la sesión).
- Habrá una serie de páginas web que no necesitarán autenticación previa (por ejemplo, actualizaciones de antivirus, Windows Update, etc.)
- Habrá una serie de páginas cuya visita estará totalmente prohibida (para cualquier usuario).
- Existirá un grupo en Active Directory llamado "InternetRestringido" cuyos miembros tendrán prohibido el acceso a determinadas webs (por ejemplo, http://www.twitter.com).
Para empezar vamos a crear varios archivos de texto donde se definan las URLs prohibidas, permitidas, etc. Deben definirse mediante expresiones regulares, una en cada línea.
- /usr/local/etc/squid/deny.acl - Aquí escribiremos las expresiones regulares que coincidan con aquellas URLs que deseamos que sean restringidas a un determinado grupo de usuarios.
- /usr/local/etc/squid/denyall.acl - Aquí irán las expresiones que definan a las URLs que queremos prohibir de manera global, para todo el mundo.
- /usr/local/etc/squid/noauth.acl - En este archivo definiremos aquellas URLs para las cuáles Squid no debe exigir autenticación, ideal para procesos automáticos, actualizaciones de software, etc.
Un ejemplo de expresiones regulares que sirvan para identificar el dominio facebook.com (y de paso facebook.es, facebook.it, facebook.*....) así como twitter.com podría ser:
facebook\.
twitter\.com
A continuación os copio y pego el trozo de /usr/local/etc/squid/squid.conf que tendremos que añadir con los pertinentes comentarios que explicando cada directiva de la política. Recordad que debe ir siempre antes del http_access deny all.
# En primer lugar definimos la "acl" de aquellas URLs que no # necesitan autenticarse previamente, y seguidamente la directiva # que permita el acceso a dicha acl acl NoAuthNeeded url_regex "/usr/local/etc/squid/noauth.acl" http_access allow NoAuthNeeded # definimos un tipo de ACL llamada "domainGroup" que nos permita # comprobar la pertenencia a grupos de Active Directory external_acl_type domainGroup %LOGIN /usr/local/libexec/squid/wbinfo_group.pl # definimos la acl que comprueba si los # usuarios pertenecen al grupo InternetRestringido acl PartiallyAllowedUsers external domainGroup InternetRestringido # definimos la lista de direcciones # restringidas para dicho grupo acl BlockList url_regex "/usr/local/etc/squid/deny.acl" # definimos la lista de direcciones # restringidas para todo el mundo acl BlockListAll url_regex "/usr/local/etc/squid/denyall.acl" # aplicamos la denegacion a las acls anteriores http_access deny PartiallyAllowedUsers BlockList http_access deny BlockListAll # si ninguna de las restricciones anteriores ha sido aplicada, # entonces comprobamos la exigencia de estar autenticado acl AuthorizedUsers proxy_auth REQUIRED http_access allow AuthorizedUsers
IMPORTANTE: cada vez que hagamos cambios al /usr/local/etc/squid/squid.conf es necesario reiniciar el servicio Squid. Para ello sólo tenemos que ejecutar este comando:
/usr/local/etc/rc.d/squid restart
Probando el invento
Llegados a este punto, tenemos que comprobar si todo ha salido bien. Para ello tenemos que configurar nuestro navegador favorito (o en su defecto la configuración global de acceso a Internet del sistema). Como navegador proxy pondremos la IP del lado privado de nuestro Appliance, es decir, la 192.168.3.254 y como puerto el 3128. De momento no necesitamos especificar ningún dato más.
AVISO: Si utilizamos el proxy sin especificarlo en el navegador, sólo usado como gateway (es decir, en modo proxy transparente), no podremos disfrutar de las ventajas de la autenticación NTLM de Windows. La razón es muy sencilla. El proxy transparente actúa haciendo intercepción de paquetes, es decir, en capa 3, mientras que la autenticación es un concepto relacionado con la capa 5 o superior. Si queremos forzar la configuración de proxy del navegador se pueden emplear diferentes estrategias que escapan a esta serie de artículos. No obstante, podremos seguir disfrutando del resto de funcionalidades del proxy (logueo, caché, tipos diversos de directivas, etc.) y hacer políticas de acceso basadas en la IP de cada usuario.
Para comprobar si todo va bien, podemos probar a navegar por distintos sitios, tanto de los permitidos como de los prohibidos, iniciando sesión en Windows con distintos usuarios y ver si todo se comporta como debe.
Además, es fundamental tener controlados los dos archivos de log del Squid, el de registro de accesos (e intentos) y el de información del servicio (necesario para diagnosticar problemas). Respectivamente son:
/var/squid/logs/access.log/var/squid/logs/cache.log
¿Qué nos queda? Pues aunque el núcleo de nuestro sistema ya está montado, podemos añadirle muchas cosas interesantes: un proxy SOCKS (para aplicaciones que no sean web), herramientas de monitorización y estadísticas, un control básico de consumo de ancho de banda.... como ya veremos podemos estar agregando funciones casi eternamente, por el módico precio de un rato de lectura en The Debug Machine.
Continuará...
No hay comentarios:
Publicar un comentario