Intergración de squid-kerberos con Samba4 como ADDC

Datos:

  • Sistema Operativo de los servidores: Debian Stretch / Buster
  • ADDC: addc.nodo.local, ntp1.nodo.local (192.168.9.15)
  • PROXY1: proxy1.nodo.local (192.168.9.69). No está unida al dominio y tiene un disco
    cache “/dev/sdb1” de 5 GB.
  • Versión de Squid: 3.5.x / 4.x
  • Versión de Samba: 4.10.x

1. ADDC Samba4:

Las configuraciones que se describen a continuación, se deben hacer en el servidor
que contiene al controlador de dominio, en este caso basado en Samba4. En caso de
usar Active Directory de Windows, simplemente usar las RSAT de Windows para crear
los OU, grupos y usuarios.
#========================================
NOTA:
Desde una PC unida al dominio con un usuario con permisos de administración en el
controlador de dominio basado en Samba4, puede hacer uso también de las RSAT y no
ejecutar los comandos que se describen a continuación.
#========================================

Records del servidor proxy:

Crear nueva Unidad Organizativa para “Usuarios”:

Crear nueva Unidad Organizativa para “Redes”:

Crear nueva Unidad Organizativa para “Proxy”:

Crear grupos de navegación para “Proxy”:

Crear usuarios de navegación para “Proxy”:

Agregar usuarios a los grupos creados:

Agregamos el SRV para ldaps desde las RSAT de Windows, usando la herramienta de
administración “DNS”, desde una de las PC unida al dominio, con un usuario con poder de
administración:

Proxy Squid:

Las configuraciones que se describen a continuación, se deben hacer en el servidor que contiene al proxy Squid.

Disco cache identificado en este caso con la etiqueta “/dev/sdb1”:

Agregar lo siguiente:

Aplicamos los cambios:

Editamos el fichero “/etc/resolv.conf”:

Borramos todo y agregamos el dominio y el servidor DNS que se encuentra en el ADDC (adapte a su red):

Fichero hosts, para dar mayor disponibilidad en caso de fallo del DNS:

Lo dejamos como sigue, adaptando a su red, para brindar mayor disponibilidad ante una falla del servicio DNS:

2.1. Sincronización de tiempo

Configuramos la zona horaria (America/Havana):

Sincronizamos el tiempo con el servidor:

Verificamos el estado del tiempo después de la sincronización:

2.2. Integrando Squid al AD mediante Kerberos

Instalamos Squid, paquetes necesarios para Kerberos y herramientas para LDAP:

Editamos o creamos si no existe “/etc/default/squid”.

Configuración de Kerberos:

A continuación, se describe cómo generar archivo “proxy.keytab” y registrar el SPN en el dominio:

Generamos el ticket y registramos el SPN para el  squid en el dominio:

Comprobamos que todo haya resultado bien:

Verificamos el ticket:

Establecemos los permisos del archivo keytab para que solo pueda ser leido por squid:

Comprobamos que la cuenta de host se actualiza correctamente:

Nos debe devolver lo siguiente:

Terminamos el “kinit” con el usuario “administrator”:

2.3. Configuración básica de Squid con autenticación por Kerberos

Editamos el fichero de configuración, no sin antes hacer una copia de respaldo:

Agregamos la siguiente configuración básica para un único proxy. Recuerde adaptar la configuración a su red:

#===============================

NOTA:

En la configuración anterior se usó la autenticación de grupos con Kerberos por su “helper” correspondiente “ext_kerberos_ldap_group_acl”. Esto posibilita que la calidad del servicio en el proxy responda a los usuarios que pertenezcan a dichos grupos del directorio activo.

Esta variante aprovecha la ventaja de la seguridad, pues usando el “helper” “ext_kerberos_ldap_group_acl” se realizan consultas al LDAP directamente, usando un “bind dn” o usuario para autenticarse, mientras Kerberos usa su propia autenticación y ticket,  se cuentan en el servidor para la autenticación del LDAP, que ya se encuentra integrado en Samba4.

También es necesario aclarar que, si se tiene IPv6 deshabilitado, se recomienda mantener la opción ipv4 en la definición de la ACL externa genérica, de lo contrario el programa no hará su función correctamente, aun cuando Squid inicie sin errores.

#===============================

Detenemos Squid:

Creamos los directorios para la cache de Squid:

Nos debe devolver lo siguiente:

Iniciamos Squid:

Comprobamos que no haya errores de sintaxis en la configuración de Squid:

Si el comando anterior no devuelve nada, es porque la configuración no tiene errores.

Nos autenticamos por Kerberos, con un usuario del grupo de internet, para las pruebas:

Comprobamos que en la base de datos de LDAP exista la computadora que representa al proxy:

Nos debe devolver algo como esto:

Comprobamos la autenticación por Kerberos:

Debe devolver algo como esto:

#===========================

NOTA:

Podría haber devuelto “OK”, pero en su lugar devolvió “AF”. No importa, esto es correcto, es por la versión de squid. A partir de la versión de 3.4 se desprecia esa respuesta en favor de OK.

#===========================

Probamos los grupos de Kerberos:

Ahora tecleamos un usuario que pertenezca al grupo indicado en el comando anterior:

Referencias Bibliográficas
Squid Documentation: http://www3.us.squid-cache.org/Versions/v3/3.2/manuals/ext_kerberos_ldap_group_acl.html. Markus Moeller.

(Visited 1 times, 1 visits today)
Arian Molina Aguilera
Sobre Arian Molina Aguilera 3 Artículos
Administrador de redes y servicios telemáticos avanzados.

9 Comentarios

  1. Ojo, en Ubuntu el paquete msktutil no está en los repos, para que no intenten el tutorial y se queden a medias.

    Deben descargarlo de las fuentes o pedirlo prestado de los repos de debian.

    Aún así me gusta más la integración desde la PC/CT del squid unida al dominio y usando NTLM… pero esta es solo mi opinión.

    • Gracias por la aclaración Pavel. Esto es algo particular para los ususarios de Ubuntu. El presente tutorial se probó sobre Debian Stretch/Buster.
      Sobre qué solución es mejor usar o no, lo dejamos a consideración del sysadmin. NTLM es un método más antiguo y con esta vía se evita tener que unir el servicio al dominio, por mi parte me quedo con ésta.
      SL2

  2. NTLM esta en desuso y descontinuado por la propio microsoft, se conocen múltiples vulnerabilidades en este protocolo no solucionadas, de ahí su abandono y no recomendación de su uso, de hecho ya windows 10 lo tiene deshabilitado por defecto. Por otra parte no tener que unir el servidor proxy al dominio sin necesidad alguna ya es otra ventaja a considerar. Si no lo vez así hermano estar embarcado.

    • LinuxCuba que haces en el caso que tengas clientes que naveguen y las maquinas no se encuentren unidas al dominio, la navegación de celulares por APN y las aplicaciones de descargas como IDM que hasta donde conozco no soportan kerberos, porque los mecanismos de autenticacion que me quedan son basicos y eso significa que el usuario y contraseña viajan por la red en texto claro y eso pasa a ser otra vulnerabilidad.

      • No tienes de otra que usar basic y el fallback usando LDAP, y ya sabes que eso es vulnerable pero bueno una red como el APN es privada, si quieres asegurar tráfico debes implementar una VPN contra el proxy o implementar un proxy https El cual implica tener certificados válidos o el respectivo CA de la pki instalado en el dispositivo. No queda otra, la seguridad del uso de proxy más bien está pensado para redes LAN con dominio y el uso de Kerberos.

    • No para nada tiene que estar en la misma subred clientes y servidores. Se recomienda el empleo de wpad, pero igualmente se puede definir el proxy usando el fqdn en las opciones del mismo en el navegador.

  3. Hola
    Alguna vez leí que existe una linea de comando en la configuración del squid que se utiliza para:
    PARA QUE LA CUENTA NO PUEDA SER ABIERTA EN DOS SECCIONES!!!
    alguien conoce eso?

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*