☰

La historia de la autenticación segura de usuarios en Squid

tag-icon • tag-icon security authentication ldap squid kerberos
La historia de la autenticación segura de usuarios en Squid

Érase una vez una hermosa y cálida jungla virtual en América del Sur, y allí vivía un servidor de calamares. Aquí hay una imagen perceptual de la red:

                 <the Internet>
                        | 
                        | 
           A            |          B
Users <---------> [squid-Server] <---> [LDAP-Server]

Cuando Userssolicitan acceso a Internet, squidpreguntan su nombre y pasaporte, los autentifican LDAPy si ldap los aprueba, entonces se los concede.

Todos estaban felices hasta que unos rastreadores robaron el pasaporte en el camino entre los usuarios y los calamares [camino A]. Este desastre ocurrió porque el calamar usó Basic-Authenticationel método.

La gente de la selva se reunió para solucionar el problema. Algunos conejitos ofrecieron el uso NTLMdel método. Las serpientes son preferidas Digest-Authenticationy Kerberosrecomendadas por los árboles.

Después de todo, ¡muchas soluciones ofrecidas por la gente de la jungla y todo estaba confuso! El León decidió poner fin a la situación. Gritó las reglas para las soluciones:

  • ¿Será segura la solución?
  • ¿La solución funcionará para la mayoría de los navegadores y software (por ejemplo, descargar software)?
  • ¿La solución debe ser simple y no necesita otro subsistema enorme (como el servidor Samba)?
  • ¿No dependerá el método de un dominio especial? (por ejemplo, Directorio Activo)

Luego, una solución muy razonable, integral e inteligente ofrecida por un mono, ¡lo que lo convierte en el nuevo rey de la jungla!

¿Puedes adivinar cuál fue la solución?

Consejo: El camino entre squidy LDAPestá protegido por el león, por lo que la solución no es asegurarlo.

Nota:Lo siento si la historia es aburrida y confusa, ¡pero la mayor parte es real! =)

               /~\/~\/~\
            /\~/~\/~\/~\/~\
          ((/~\/~\/~\/~\/~\))
        (/~\/~\/~\/~\/~\/~\/~\)
       (////     ~   ~     \\\\)
       (\\\\(   (0) (0)   )////)
       (\\\\(   __\-/__   )////)
        (\\\(     /-\     )///)
         (\\\(  (""""")  )///)
          (\\\(  \^^^/  )///)
           (\\\(       )///)
             (\/~\/~\/~\/)         **
               (\/~\/~\/)        *####*
                |     |           ****
               /| | | |\            \\
            _/  | | | | \_ _________//   Thanks!
           (,,)(,,)_(,,)(,,)--------'

Actualizar:

MáximoExplicó que el método de autenticación entre Users- squidy squid- LDAPno tiene por qué ser el mismo. Podemos utilizar un método arbitrario para obtener información de autenticación de los usuarios y un método arbitrario para autenticar los datos recopilados.

Pero hay un problema: la entrada/salida de todos los tipos de autenticadores no es la misma. Por ejemplo:

  • un Basicautenticador debe leer el par "nombre de usuario contraseña" en una línea y responder OKsi la contraseña de usuario es correcta oERR
  • un Digestautenticador debe leer username:realmy responder un código hexadecimal de HA(A1)o un ERR.

Aunque no existe una relación directa entre el método cliente-squid y el método squid-ldap, los datos recopilados del cliente deben ser compatibles con el método utilizado en la parte squid-ldap. Por lo tanto, si cambiamos el método de autenticación en el lado de los usuarios, quizás también deberíamos cambiar nuestro autenticador.

Entonces el problema se simplifica a:

  1. En el primer nivel, yo (¡el mono!) Estoy buscando un buen método de autenticación en el lado del usuario. ¿Qué método recomiendas?es seguro y compatible con la mayoría de los navegadores? Estoy confundido entre NTLMy .KerberosDigest

  2. ¿Dónde puedo encontrar un autenticador que admita información de credenciales del método seleccionado y se autentique a través de LDAP?

Respuesta1

Kerberos no es una opción para la autenticación HTTP. NTLM no es compatible con ningún otro navegador que no sea IE. Basic no es seguro a menos que lo coloque detrás de HTTPS, lo que AFAIK squid no puede hacer. Entonces te queda Digest.

Respuesta2

Una característica interesante que podría ayudarle aquí es que el método que utiliza Squid para solicitar autenticación al navegador del cliente (ruta A) no necesita estar relacionado en absoluto con el método que utiliza para validar las credenciales proporcionadas por el usuario (ruta B). ). Esto significa, por ejemplo, que puede hacer que Squid "hable" NTLM con los navegadores del cliente, pero luego podría validar a los usuarios con la base de datos de usuarios interna de Linux (/etc/passwd). HayNoEs necesario que las credenciales adquiridas mediante NTLM (en la ruta A) se validen realmente con un dominio de Windows (en la ruta B). Lo mismo se aplica a cualquier combinación posible de métodos de autenticación del lado del cliente y de autenticación del lado del servidor.

Lo que esto significa en su caso es que puede configurar Squid de forma segura para solicitar autenticación NTLM de los navegadores del cliente en lugar de autenticación básica, y esto de ninguna manera requerirá que use Samba/WinBind/AD/lo que sea.

Por lo tanto, puede elegir el método que desee para la autenticación del lado del cliente y seguir validando a los usuarios con un servidor LDAP después de que hayan proporcionado sus credenciales utilizando el método que seleccionó.

La magia ocurre, por supuesto, en squid.conf:

#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#auth_param digest children 5
#auth_param digest realm Squid proxy-caching web server
#auth_param digest nonce_garbage_interval 5 minutes
#auth_param digest nonce_max_duration 30 minutes
#auth_param digest nonce_max_count 50
#auth_param basic program <uncomment and complete this line>
#auth_param basic children 5
#auth_param basic realm Squid proxy-caching web server
#auth_param basic credentialsttl 2 hours
#auth_param basic casesensitive off

Cada auth_paramdirectiva permite una autenticación específica.para navegadores de clientes(ruta A), mientras que la parte "programa" establece qué utilizará realmente Squid para validar las credenciales proporcionadas por los usuarios. Puede utilizar cualquier programa de autenticación que desee aquí (incluso uno personalizado), siempre que pueda recibir una identificación de usuario y una contraseña y responder "sí" o "no".

Sólo necesita tomar cualquier autenticador que esté usando para realizar su consulta LDAP y pegarlo en las declaraciones "auth_param ntlm" o "auth_param digest", en lugar de "auth_param basic" donde está ahora.

Actualizar:

Definitivamente deberías usarsquid_ldap_authcomo su autenticador, pero no puedo decirle exactamentecómosin ningún detalle sobre el servidor LDAP específico que estás utilizando.

En cuanto a la autenticación del lado del cliente, cualquiera debería ser bueno; Estoy bastante contento con NTLM y la mayoría de los navegadores lo admiten hoy en día.

Esta configuración se vería así en squid.conf:

auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>

Esto solicitará las credenciales de usuario (ruta A) utilizando NTLM y luego las validará con un servidor LDAP (ruta B); pero esos "parámetros" dependen estrictamente de su implementación y configuración de LDAP.

Esto también podría ayudar:http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html.

información relacionada