17 votos

La Historia de seguro de autenticación de usuario en squid

érase una vez, había una hermosa caliente virtual-de la selva en américa del sur, y un servidor squid vivía allí. aquí está una percepción de la imagen de la red:

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

Cuando la Users solicitud de acceso a Internet, squid pregunte a su nombre y pasaporte, autenticar ellos por LDAP y si ldap aprobado, entonces él les concedió.

Todo el mundo era feliz hasta que algunos sniffers robaron el pasaporte, en el camino entre los usuarios y los calamares [ruta de acceso]. Este desastre ocurrió porque squid utiliza Basic-Authentication método.

La gente de la selva se reunieron para resolver el problema. Algunos conejitos que ofrece el uso de NTLM de método. Serpientes preferido Digest-Authentication mientras Kerberos recomendado por los árboles.

Después de todo, muchas solución ofrecida por el pueblo de la selva y todo estaba confundido! El León decidió poner fin a la situación. Él gritó de las reglas para las soluciones:

  • Será la solución a estar seguro!
  • Será la solución para la mayoría de los navegadores y los programas (por ejemplo, descarga de software)
  • Será la solución ha de ser simple y no necesita de otras grandes subsistema (como servidor Samba)
  • El método depende de dominio especial. (por ejemplo, Active Directory)

A continuación, una muy resonable-integral-inteligente solución ofrecida por un mono, convirtiéndose en el nuevo rey de la selva!

¿puedes adivinar cuál era la solución?

Sugerencia: La ruta de acceso entre squid y LDAP está protegida por el león, por lo que la solución no tiene que asegurarlo.

Nota: lo siento si la historia es aburrida y desordenado, pero la mayoría de esto es real! =)

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

Actualización:

Massimo explicó que el método de autenticación entre Users-squid y squid-LDAP no tiene que ser el mismo. podemos utilizar cualquier código método para obtener la información de autenticación de usuarios y arbitrarias método para autenticado a los datos recopilados.

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

  • un Basic autenticador debe leer "nombre de usuario contraseña" de par en una línea y una respuesta OK si el usuario pass es correcto o ERR
  • un Digest autenticador debe leer un username:realm y respuesta de una codificación hexadecimal de HA(A1) o ERR.

Aunque no hay una relación directa entre cliente-calamar método y calamares-ldap método de recogida de datos desde el cliente debe ser compatible con el método utilizado en calamar-ldap parte. Por lo tanto, si el cambio de método de autenticación de usuarios de la cara, tal vez deberíamos cambiar nuestra autenticador.

Por lo que el problema se simplifica a:

  1. En el primer nivel, yo (el mono!!!) estoy en busca de un buen método de autenticación de usuario de lado. El método que recomienda usted que es seguro y compatible con la mayoría de los navegadores? estoy confundido entre NTLM, Kerberos y Digest.

  2. Donde puedo encontrar un autenticador que soporta la información de credenciales de método seleccionado y se autentica a través de LDAP.

4voto

yulia Puntos 16

Una característica interesante que podría ayudar aquí es que el método de Squid usa para pedir que el navegador del cliente para la autenticación (ruta A) no necesita estar relacionado con el método que se utiliza realmente para validar las credenciales suministradas por el usuario (ruta B). Esto significa, f.e., que usted puede hacer Calamar "hablar" NTLM con el cliente de los navegadores, pero luego muy bien podría validar a los usuarios en contra de Linux interna de la base de datos de usuarios (/etc/passwd). No hay ninguna necesidad de credenciales adquiridas mediante NTLM (en ruta A) ser validado contra un dominio de Windows (en la ruta B). Lo mismo se aplica a cualquier combinación posible del lado del cliente y los métodos de autenticación del lado del servidor de autenticación.

Lo que esto significa en su caso, es que la f.e. de forma segura puede configurar Squid para solicitar la autenticación NTLM de los exploradores del cliente en lugar de la autenticación básica, y esto no requiere que usted para en realidad el uso de Samba/WinBind/AD/lo que sea.

Así que usted puede elegir cualquiera que sea el método que desee para la autenticación de cliente, y aún así mantener validar a los usuarios contra un servidor LDAP después de que proporciona a sus credenciales con el método seleccionado.

La magia sucede, 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_param directiva permite que una autenticación de cliente de los navegadores (ruta A), mientras que el "programa" de parte de los conjuntos lo Squid va a usar para validar las credenciales proporcionadas por los usuarios. Usted puede usar cualquier autenticador programa que queramos (incluso una costumbre-escrita), como el tiempo que puede recibir un id de usuario y una contraseña y la respuesta "sí" o "no".

Usted sólo tiene que tomar lo que autenticador que estamos utilizando para hacer su consulta LDAP y pegarla en el "auth_param ntlm" o "auth_param digerir" las declaraciones, en lugar de la "auth_param basic", uno donde se encuentra ahora.


Actualización:

Definitivamente, usted debe utilizar squid_ldap_auth como tu authenticator, pero no puedo decirte exactamente cómo sin ningún detalle sobre el servidor LDAP está utilizando.

Con respecto a la autenticación de cliente, uno debe ser bueno; estoy muy contento con NTLM, y la mayoría de los navegadores soportan en la actualidad.

Una configuración de ese tipo tendría este aspecto en el calamar.conf:

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

Este le pedirá las credenciales de usuario (ruta A) mediante NTLM, a continuación, valide contra un servidor LDAP (ruta B); pero los "parámetros" estrictamente dependen de su implementación de LDAP y configuración.

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

1voto

delimiter69 Puntos 399

Kerberos no es una opción para la autenticación HTTP. NTLM no está bien apoyado en cualquier navegador de IE. Básica no es segura a menos que se ponga detrás de HTTPS que AFAIK squid no puede hacer. Así que se quedan con la digestión.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: