jueves, 14 de marzo de 2013

Creación de un Virtual Appliance para control de Internet con VMware (parte 4)

<< Artículo anterior

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:
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
Si queremos garantizar el arranque de los servicios en cada reinicio de la máquina, tenemos que activarlos en el /etc/rc.conf al igual que hemos venido haciendo con otros:

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á...