Historia bezpiecznego uwierzytelniania użytkownika w kałamarnicy

Dawno, dawno temu w południowej Ameryce była piękna ciepła wirtualna dżungla, w której mieszkał serwer kałamarnic. oto percepcyjny obraz sieci:

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

Kiedy poprosisz Userso dostęp do Internetu, squidzapytaj ich nazwiska i paszportu, uwierzytelnij je, LDAPa jeśli ldap je zatwierdzi, to je udzieli.

Wszyscy byli szczęśliwi, dopóki niektórzy snifferzy nie ukradli paszportu między użytkownikami a kałamarnicą [ścieżka A]. Ta katastrofa wydarzyła się, ponieważ zastosowano Basic-Authenticationmetodę kałamarnicy .

Ludzie dżungli zebrali się, aby rozwiązać problem. Niektóre króliczki oferowane za pomocą NTLMmetody. Węże preferowane Digest-Authenticationpodczas gdy Kerberoszalecana przez drzewa.

W końcu wiele rozwiązań oferowanych przez ludzi z dżungli i wszystko było zdezorientowane! Lew postanowił zakończyć sytuację. Wykrzykiwał zasady rozwiązań:

• Czy rozwiązanie będzie bezpieczne!
• Czy rozwiązanie będzie działać w przypadku większości przeglądarek i oprogramowania (np. Oprogramowanie do pobrania)
• Czy rozwiązanie powinno być proste i nie wymaga innego ogromnego podsystemu (takiego jak serwer Samba)
• Czy metoda nie zależy od specjalnej domeny. (np. Active Directory)

Następnie bardzo rezonansowe, wszechstronne i sprytne rozwiązanie oferowane przez małpę, co czyni go nowym królem dżungli!

zgadniesz, jakie było rozwiązanie?

Wskazówka: Ścieżka między squidi LDAPjest chroniony przez lwa, więc rozwiązanie nie ma go zabezpieczyć.

Uwaga: przepraszam, jeśli historia jest nudna i niechlujna, ale większość z nich jest prawdziwa! =)

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

Aktualizacja:

Massimo wyjaśnił, że metoda uwierzytelniania pomiędzy Users- squidi squid- LDAPnie musi być taka sama. możemy użyć dowolnej metody, aby uzyskać informacje uwierzytelniające od użytkowników, oraz dowolnej metody uwierzytelnienia zgromadzonych danych.

Ale jest problem: wejście / wyjście wszystkich typów wystawców uwierzytelnienia nie jest takie samo. Na przykład:

• Basicuwierzytelnienia powinien przeczytać „Haslo” pary w linii i odpowie OKjeśli użytkownik-pass jest prawidłowa lubERR
• Digestuwierzytelnienia należy czytać username:realmi odpowiadać hex kodowane z HA(A1)lub ERR.

Chociaż nie ma bezpośredniego związku między metodą klient-squid a metodą squid-ldap, zebrane dane od klienta muszą być zgodne z metodą stosowaną w części squid-ldap. Dlatego jeśli zmienimy metodę uwierzytelniania po stronie użytkownika, być może powinniśmy również zmienić naszego uwierzytelniacza.

Problem upraszcza więc:

1. Na pierwszym poziomie ja (małpa!) Szukam dobrej metody uwierzytelniania po stronie użytkownika. Którą metodę polecasz, która jest bezpieczna i obsługiwana przez większość przeglądarek ? jestem w pomieszaniu między NTLM, Kerberosa Digest.

2. Gdzie mogę znaleźć wystawcę uwierzytelnienia, który obsługuje dane uwierzytelniające wybranej metody i uwierzytelnia się za pośrednictwem LDAP.

Kerberos nie jest opcją uwierzytelniania HTTP. NTLM nie jest dobrze obsługiwany w żadnej przeglądarce innej niż IE. Basic nie jest bezpieczny, chyba że umieścisz go za HTTPS, czego nie może zrobić kałamarnica AFAIK. Pozostajesz więc z Digest.

Jedną z interesujących funkcji, które mogą ci w tym pomóc, jest to, że metoda, której używa Squid, aby poprosić przeglądarkę klienta o uwierzytelnienie (ścieżka A), wcale nie musi być powiązana z metodą, której używa do faktycznej weryfikacji poświadczeń dostarczonych przez użytkownika (ścieżka B ). Oznacza to, na przykład, że możesz sprawić, by Squid „rozmawiał” NTLM z przeglądarkami klienckimi, ale wtedy mógłby bardzo dobrze zweryfikować użytkowników względem wewnętrznej bazy danych użytkowników Linuksa (/ etc / passwd). Nie ma potrzeby weryfikowania poświadczeń uzyskanych za pomocą NTLM (na ścieżce A) względem domeny Windows (na ścieżce B). To samo dotyczy dowolnej możliwej kombinacji metod uwierzytelniania po stronie klienta i uwierzytelniania po stronie serwera.

W twoim przypadku oznacza to, że możesz bezpiecznie skonfigurować Squid, aby żądał uwierzytelnienia NTLM z przeglądarek klienta zamiast uwierzytelniania podstawowego, i to w żaden sposób nie będzie wymagało od ciebie używania Samba / WinBind / AD / cokolwiek.

Możesz więc wybrać dowolną metodę uwierzytelniania po stronie klienta, ale nadal sprawdzać poprawność użytkowników na serwerze LDAP po tym, jak podadzą oni swoje poświadczenia przy użyciu wybranej metody.

Magia dzieje się oczywiście w 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

Każda auth_paramdyrektywa umożliwia określone uwierzytelnianie w przeglądarkach klienckich (ścieżka A), podczas gdy część „programowa” określa, czego Squid użyje do zweryfikowania poświadczeń podanych przez użytkowników. Możesz użyć dowolnego programu uwierzytelniającego, który chcesz tutaj (nawet niestandardowego), o ile może on otrzymać identyfikator użytkownika i hasło oraz odpowiedzieć „tak” lub „nie”.

Wystarczy wziąć dowolny uwierzytelniacz, którego używasz do wykonania zapytania LDAP i umieścić go w instrukcjach „auth_param ntlm” lub „auth_param digest”, zamiast w „auth_param basic”, gdzie jest teraz.

Aktualizacja:

Zdecydowanie powinieneś użyć squid_ldap_auth jako swojego wystawcy uwierzytelnienia, ale nie mogę ci powiedzieć dokładnie, jak to zrobić, bez żadnych szczegółów na temat konkretnego serwera LDAP, którego używasz.

Jeśli chodzi o uwierzytelnianie po stronie klienta, każdy powinien być dobry; Jestem bardzo zadowolony z NTLM, a większość przeglądarek obsługuje go obecnie.

Taka konfiguracja wyglądałaby tak w squid.conf:

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

Spowoduje to zapytanie o poświadczenia użytkownika (ścieżka A) przy użyciu NTLM, a następnie zweryfikuje je na serwerze LDAP (ścieżka B); ale te „parametry” ściśle zależą od implementacji i konfiguracji LDAP.

To też może pomóc: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .