Ir al contenido principal

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


Comentarios

Entradas populares de este blog

Ahorro de costes con Google Apps (III). Bye, bye, Exchange. Bienvenido, Mr. LDAP

<<<< Anterior
En los anteriores artículos vimos cómo configurar nuestro dominio para ser usado con Google Apps y aprendimos a hacer unos ajustes básicos. Ahora ya llegado la hora de configurar nuestras propias aplicaciones con el fin de sustituir el servicio Exchange en nuestra compañía.
De las principales ventajas del Exchange, hay algunas que podemos replicar casi de manera inmediata con lo visto hasta ahora. La primera y más característica de este tipo de servidor: la opción de usar una "Libreta Global de direcciones" de la compañía.
Para poder seguir usando esto, realmente nunca habríamos necesitado un Exchange, ya que éste lo único que hace es mostrarnos una vista de las direcciones que tenemos dadas de alta en nuestro dominio Active Directory. Como todo el mundo sabe, el Active Directory no es nada especialmente nuevo ni mucho menos inventado por Microsoft; es en realidad una (otra) implementación del estándar abierto LDAP (Lightweight directory access prot…

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

<< Artículo anterior

En el anterior artículo habíamos sentado las bases sobre el appliance que queremos construir: las funcionalidades, la intrastructura y el software y herramientas necesarias.
El siguiente paso es describir el planteamiento de manera más concreta y comenzar con la instalación básica del sistema operativo base y de los paquetes mínimos necesarios.
La red
Desde el punto de vista de la red local, este esquema representa la filosofía del proyecto:

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

Esta es la primera entrega de varios artículos que voy a publicar en los próximos días mostrando un caso práctico de creación de un appliance virtual para controlar el acceso a Internet de una compañía usando exclusivamente software gratuito.
La guía que vamos a desarrollar podría perfectamente valer para crear un appliance tradicional basado en un equipo headless cualquiera; además no es necesario un equipo de extremada potencia por lo que es la excusa perfecta para reutilizar cualquier PC al que íbamos a dar matarile. Sin embargo, he escogido el formato de máquina virtual porque así de paso nos aprovechamos de las distintas ventajas de usar una plataforma como VMware para usos que no siempre son tan conocidos o habituales.