Die Geschichte der sicheren Benutzerauthentifizierung in Squid

Es war einmal ein wunderschöner warmer virtueller Dschungel in Südamerika, und dort lebte ein Tintenfisch-Server. Hier ist ein wahrnehmbares Bild des Netzwerks:

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

Wenn die UsersAnfrage Zugriff auf das Internet, squidfragen Sie ihren Namen und Reisepass, authentifizieren Sie sie durch LDAPund wenn LDAP sie genehmigt, dann gewährt er ihnen.

Alle waren glücklich, bis ein paar Schnüffler den Pass zwischen Benutzern und Tintenfisch gestohlen hatten [Pfad A]. Diese Katastrophe geschah, weil Tintenfisch Basic-AuthenticationMethode verwendet.

Die Leute aus dem Dschungel versammelten sich, um das Problem zu lösen. Einige Hasen boten NTLMMethoden an. Schlangen bevorzugt, Digest-Authenticationwährend Kerberosvon Bäumen empfohlen.

Immerhin waren viele Lösungsvorschläge von Leuten aus dem Dschungel und alles verwirrt! Der Löwe beschloss, die Situation zu beenden. Er rief die Regeln für Lösungen:

• Soll die Lösung sicher sein!
• Funktioniert die Lösung für die meisten Browser und Software (z. B. Software herunterladen)?
• Soll die Lösung einfach sein und kein anderes riesiges Subsystem (wie Samba-Server) benötigen?
• Sollte die Methode nicht von einer bestimmten Domain abhängen. (zB Active Directory)

Dann eine sehr vernünftige, umfassende und clevere Lösung, die von einem Affen angeboten wird und ihn zum neuen König des Dschungels macht!

Kannst du raten, was die Lösung war?

Tipp: Der Weg zwischen squidund LDAPist durch den Löwen geschützt, daher muss die Lösung diesen nicht sichern.

Hinweis: Tut mir leid, wenn die Geschichte langweilig und chaotisch ist, aber das meiste davon ist echt! =)

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

Aktualisieren:

Massimo erklärte, dass die Authentifizierungsmethode zwischen Users- squidund squid- LDAPnicht identisch sein muss. Wir können eine beliebige Methode verwenden, um Authentifizierungsinformationen von Benutzern abzurufen, und eine beliebige Methode, um erfasste Daten zu authentifizieren.

Es gibt jedoch ein Problem: Die Eingabe / Ausgabe aller Arten von Authentifikatoren ist nicht identisch. Beispielsweise:

• Ein BasicAuthentifizierer sollte das "Benutzername Passwort" -Paar in einer Zeile lesen und antworten, OKwenn der Benutzerpass korrekt ist oderERR
• Ein DigestAuthentifikator sollte a lesen username:realmund einen hexadezimalen Code von HA(A1)oder a beantworten ERR.

Obwohl es keine direkte Beziehung zwischen der Client-Squid-Methode und der Squid-LDAP-Methode gibt, müssen die vom Client erfassten Daten mit der im Squid-LDAP-Teil verwendeten Methode kompatibel sein. Wenn wir also die Authentifizierungsmethode auf der Benutzerseite ändern, sollten wir möglicherweise auch unseren Authentifikator ändern.

Das Problem vereinfacht sich also zu:

1. In der ersten Ebene suche ich (der Affe!) Nach einer guten Authentifizierungsmethode auf Benutzerseite. Welche Methode empfehlen Sie, welche ist sicher und wird von den meisten Browsern unterstützt ? ich bin in verwirrt zwischen NTLM, Kerberosund Digest.

2. Wo finde ich einen Authentifikator, der Anmeldeinformationen der ausgewählten Methode unterstützt und über LDAP authentifiziert.

Kerberos ist keine Option für die HTTP-Authentifizierung. NTLM wird in keinem anderen Browser als dem IE gut unterstützt. Basic ist nur dann sicher, wenn Sie es hinter HTTPS stellen, was AFAIK Squid nicht kann. Sie bleiben also bei Digest.

Eine interessante Funktion, die Ihnen dabei helfen könnte, ist, dass die Methode, mit der Squid den Client-Browser nach Authentifizierung fragt (Pfad A), in keiner Weise mit der Methode verknüpft sein muss, mit der die vom Benutzer angegebenen Anmeldeinformationen überprüft werden (Pfad B) ). Dies bedeutet zB, dass Sie Squid dazu bringen können, mit Client-Browsern über NTLM zu "sprechen", aber dann können Benutzer sehr gut anhand der internen Linux-Benutzerdatenbank (/ etc / passwd) überprüft werden. Es ist nicht erforderlich, dass Anmeldeinformationen, die mit NTLM (auf Pfad A) erworben wurden, tatsächlich für eine Windows-Domäne (auf Pfad B) validiert werden. Gleiches gilt für jede mögliche Kombination von clientseitigen und serverseitigen Authentifizierungsmethoden.

Dies bedeutet in Ihrem Fall, dass Sie Squid sicher so konfigurieren können, dass die NTLM-Authentifizierung von Client-Browsern anstelle der Standardauthentifizierung angefordert wird, und dass Sie in keiner Weise Samba / WinBind / AD / whatever verwenden müssen.

Sie können also die von Ihnen gewünschte Methode für die clientseitige Authentifizierung auswählen und die Überprüfung der Benutzer anhand eines LDAP-Servers fortsetzen, nachdem sie ihre Anmeldeinformationen mit der von Ihnen ausgewählten Methode angegeben haben.

Die Magie geschieht natürlich in 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

Jede auth_paramDirektive ermöglicht eine spezifische Authentifizierung für Client-Browser (Pfad A), während der "Programm" -Teil festlegt, was Squid tatsächlich verwendet, um die von Benutzern bereitgestellten Anmeldeinformationen zu validieren. Sie können hier ein beliebiges Authentifizierungsprogramm verwenden (auch ein benutzerdefiniertes), sofern es eine Benutzer-ID und ein Kennwort erhalten und mit "Ja" oder "Nein" antworten kann.

Sie müssen nur den Authentifikator verwenden, den Sie für Ihre LDAP-Abfrage verwenden, und ihn in die Anweisungen "auth_param ntlm" oder "auth_param digest" einfügen, anstatt in die Anweisung "auth_param basic", in der er sich jetzt befindet.

Aktualisieren:

Sie sollten auf jeden Fall squid_ldap_auth als Ihren Authentifikator verwenden, aber ich kann Ihnen nicht genau sagen, wie, ohne Einzelheiten über den von Ihnen verwendeten LDAP-Server.

In Bezug auf die clientseitige Authentifizierung sollte jeder gut sein. Ich bin ziemlich zufrieden mit NTLM und die meisten Browser unterstützen es heutzutage.

Eine solche Konfiguration würde in squid.conf so aussehen:

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

Hierbei werden Benutzeranmeldeinformationen (Pfad A) unter Verwendung von NTLM abgefragt und anschließend anhand eines LDAP-Servers (Pfad B) überprüft. Diese "Parameter" hängen jedoch streng von Ihrer LDAP-Implementierung und -Konfiguration ab.

Dies könnte auch helfen: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .