L'histoire de l'authentification utilisateur sécurisée dans Squid

Il était une fois, une belle jungle virtuelle chaude en Amérique du Sud, et un serveur de calmars y vivait. voici une image perceptuelle du réseau:

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

Lorsque la Usersdemande d'accès à Internet, squiddemandez leur nom et passeport, authentifiez-les par LDAPet si LDAP les a approuvés, alors il les a accordés.

Tout le monde était content jusqu'à ce que des renifleurs volent un passeport entre les utilisateurs et le calmar [chemin A]. Cette catastrophe s'est produite parce que le calmar a utilisé la Basic-Authenticationméthode.

Les gens de la jungle se sont réunis pour résoudre le problème. Certains lapins ont proposé d'utiliser la NTLMméthode. Les serpents sont préférés Digest-Authenticationtandis qu'ils sont Kerberosrecommandés par les arbres.

Après tout, de nombreuses solutions proposées par des gens de la jungle et tout était confus! Le Lion a décidé de mettre fin à la situation. Il a crié les règles des solutions:

• La solution doit-elle être sécurisée!
• La solution doit-elle fonctionner pour la plupart des navigateurs et logiciels (par exemple, télécharger des logiciels)
• La solution doit-elle être simple et ne nécessite pas d'autre énorme sous-système (comme le serveur Samba)
• La méthode ne dépendra-t-elle pas d'un domaine spécial. (par exemple, Active Directory)

Ensuite, une solution très résonnable, complète et intelligente offerte par un singe, faisant de lui le nouveau roi de la jungle!

pouvez-vous deviner quelle était la solution?

Astuce: Le chemin entre squidet LDAPest protégé par le lion, donc la solution n'a pas à le sécuriser.

Remarque: désolé si l'histoire est ennuyeuse et désordonnée, mais la plupart sont réelles! =)

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

Mise à jour:

Massimo a expliqué que la méthode d'authentification entre Users- squidet squid- LDAPn'a pas à être la même. nous pouvons utiliser la méthode arbitraire pour obtenir des informations d'authentification des utilisateurs et la méthode arbitraire pour authentifier les données recueillies.

Mais il y a un problème: l'entrée / sortie de tous les types d'authentificateurs n'est pas la même. Par exemple:

• un Basicauthentificateur doit lire la paire "mot de passe du nom d'utilisateur" sur une ligne et répondre OKsi la passe utilisateur est correcte ouERR
• un Digestauthentificateur doit lire un username:realmet répondre à un codage hexadécimal de HA(A1)ou un ERR.

Bien qu'il n'y ait pas de relation directe entre la méthode client-squid et la méthode squid-ldap, les données recueillies du client doivent être compatibles avec la méthode utilisée dans la partie squid-ldap. Par conséquent, si nous modifions la méthode d'authentification côté utilisateur, nous devrions peut-être également changer notre authentificateur.

Ainsi, le problème se simplifie pour:

1. Au premier niveau, je (le singe!) Cherche une bonne méthode d'authentification côté utilisateur. Quelle méthode recommandez-vous qui est sécurisée et prise en charge par la plupart des navigateurs ? je suis confus entre NTLM, Kerberoset Digest.

2. Où je peux trouver un authentificateur qui prend en charge les informations d'identification de la méthode sélectionnée et s'authentifie via LDAP.

Kerberos n'est pas une option pour l'authentification HTTP. NTLM n'est pas bien pris en charge dans un navigateur autre qu'IE. Basic n'est pas sécurisé à moins que vous ne le mettiez derrière HTTPS ce que le calmar AFAIK ne peut pas faire. Vous vous retrouvez donc avec Digest.

Une fonctionnalité intéressante qui pourrait vous aider ici est que la méthode utilisée par Squid pour demander l'authentification du navigateur client (chemin A) n'a pas du tout besoin d'être liée à la méthode qu'il utilise pour valider réellement les informations d'identification fournies par l'utilisateur (chemin B ). Cela signifie, par exemple, que vous pouvez faire Squid "parler" NTLM avec les navigateurs clients, mais cela pourrait très bien valider les utilisateurs par rapport à la base de données utilisateur interne de Linux (/ etc / passwd). Il n'est pas nécessaire que les informations d'identification acquises à l'aide de NTLM (sur le chemin A) soient réellement validées par rapport à un domaine Windows (sur le chemin B). Il en va de même pour toute combinaison possible de méthodes d'authentification côté client et d'authentification côté serveur.

Dans votre cas, cela signifie que si vous pouvez configurer en toute sécurité Squid pour demander une authentification NTLM aux navigateurs clients au lieu d'une authentification de base, cela ne vous obligera en aucun cas à utiliser Samba / WinBind / AD / quoi que ce soit.

Vous pouvez donc choisir la méthode que vous souhaitez pour l'authentification côté client, tout en continuant à valider les utilisateurs par rapport à un serveur LDAP après avoir fourni leurs informations d'identification en utilisant la méthode que vous avez sélectionnée.

La magie opère, bien sûr, dans 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

Chaque auth_paramdirective permet une authentification spécifique pour les navigateurs clients (chemin A), tandis que la partie "programme" définit ce que Squid utilisera réellement pour valider les informations d'identification fournies par les utilisateurs. Vous pouvez utiliser le programme d'authentification que vous souhaitez ici (même un programme personnalisé), à condition qu'il puisse recevoir un identifiant utilisateur et un mot de passe et répondre «oui» ou «non».

Il vous suffit de prendre l'authentificateur que vous utilisez pour effectuer votre requête LDAP et de le coller dans les instructions "auth_param ntlm" ou "auth_param digest", au lieu de celle "auth_param basic" où elle se trouve actuellement.

Mise à jour:

Vous devriez certainement utiliser squid_ldap_auth comme authentificateur, mais je ne peux pas vous dire exactement comment sans aucun détail sur le serveur LDAP spécifique que vous utilisez.

Concernant l'authentification côté client, tout le monde devrait être bon; Je suis assez satisfait de NTLM, et la plupart des navigateurs le prennent en charge de nos jours.

Une telle configuration ressemblerait à ceci dans squid.conf:

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

Cela demandera les informations d'identification de l'utilisateur (chemin A) à l'aide de NTLM, puis les validera par rapport à un serveur LDAP (chemin B); mais ces "paramètres" dépendent strictement de votre implémentation et configuration LDAP.

Cela pourrait également aider: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .