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

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

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

Cuando Userssolicite acceso a Internet, squidsolicite su nombre y pasaporte, LDAPautentíquelos y si ldap los aprobó, entonces él los otorgó.

Todos estaban felices hasta que algunos rastreadores robaron el pasaporte en la ruta entre los usuarios y el calamar [ruta A]. Este desastre ocurrió porque el calamar utilizó el Basic-Authenticationmétodo.

La gente de la jungla se reunió para resolver el problema. Algunos conejitos se ofrecen usando el NTLMmétodo. Serpientes preferido Digest-Authenticationmientras Kerberosrecomendadas por los árboles.

Después de todo, ¡mucha solución ofrecida por la gente de la jungla y todo estaba confundido! El león decidió poner fin a la situación. Gritó las reglas para las soluciones:

• ¡La solución será segura!
• ¿Funcionará la solución para la mayoría de los navegadores y softwares (por ejemplo, descargar software)
• La solución será simple y no necesitará otro subsistema enorme (como el servidor Samba)
• ¿No dependerá el método de un dominio especial? (por ejemplo, Active Directory)

¡Entonces, una solución muy razonable, completa e inteligente ofrecida por un mono, convirtiéndolo 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 tiene que asegurarlo.

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

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

Actualizar:

Massimo explicó que el método de autenticación entre Users- squidy squid- LDAPno tiene que ser el mismo. Podemos utilizar el método arbitrario para obtener información de autenticación de los usuarios y el 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 de "contraseña de nombre de usuario" en una línea y responder OKsi el pase de usuario es correcto oERR
• un Digestautenticador debería leer username:realmay responder un codificado hexadecimal de HA(A1)o an ERR.

Aunque no existe una relación directa entre el método cliente-calamar 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 del usuario, tal vez 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 recomienda que sea ​​seguro y compatible con la mayoría de los navegadores ? Estoy confundido entre NTLM, Kerberosy Digest.

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

Kerberos no es una opción para la autenticación HTTP. NTLM no está bien soportado en ningún navegador que no sea IE. Basic no es seguro a menos que lo pongas detrás de HTTPS que AFAIK squid no puede hacer. Entonces te quedas con Digest.

Una característica interesante que podría ayudarlo aquí es que el método que Squid usa para solicitar la autenticación del navegador del cliente (ruta A) no necesita estar relacionado con el método que usa para validar realmente las credenciales proporcionadas por el usuario (ruta B ) Esto significa, por ejemplo, que puede hacer que Squid "hable" NTLM con navegadores de clientes, pero podría validar a los usuarios contra la base de datos interna de usuarios de Linux (/ etc / passwd). No hay ninguna necesidad de credenciales adquiridas mediante NTLM (en la vía A) para ser validado en realidad contra un dominio de Windows (en la trayectoria 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 manera segura para solicitar autenticación NTLM de los navegadores de los clientes en lugar de la 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 aún así seguir validando a los usuarios contra un servidor LDAP después de que proporcionen 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 habilita una autenticación específica para los navegadores del cliente (ruta A), mientras que la parte "programa" establece lo que Squid realmente usará para validar las credenciales proporcionadas por los usuarios. Puede usar 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".

Solo necesita tomar el autenticador que esté utilizando para hacer su consulta LDAP y pegarlo en las declaraciones "auth_param ntlm" o "auth_param digest", en lugar de la "auth_param basic" donde está ahora.

Actualizar:

Definitivamente deberías usar squid_ldap_auth como tu autenticador, pero no puedo decirte exactamente cómo sin ningún detalle sobre el servidor LDAP específico que estás utilizando.

Con respecto 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.

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

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

Esto solicitará credenciales de usuario (ruta A) usando NTLM, luego las validará en 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 .