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 Users
o dostęp do Internetu, squid
zapytaj ich nazwiska i paszportu, uwierzytelnij je, LDAP
a 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-Authentication
metodę kałamarnicy .
Ludzie dżungli zebrali się, aby rozwiązać problem. Niektóre króliczki oferowane za pomocą NTLM
metody. Węże preferowane Digest-Authentication
podczas gdy Kerberos
zalecana 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 squid
i LDAP
jest 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
- squid
i squid
- LDAP
nie 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:
Basic
uwierzytelnienia powinien przeczytać „Haslo” pary w linii i odpowieOK
jeśli użytkownik-pass jest prawidłowa lubERR
Digest
uwierzytelnienia należy czytaćusername:realm
i odpowiadać hex kodowane zHA(A1)
lubERR
.
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:
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
,Kerberos
aDigest
.Gdzie mogę znaleźć wystawcę uwierzytelnienia, który obsługuje dane uwierzytelniające wybranej metody i uwierzytelnia się za pośrednictwem LDAP.
Odpowiedzi:
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.
źródło
digest_ldap_auth
(pochodzi z kałamarnicy) na serwerze LDAP.Negotiate
mechanizmu; Z powodzeniem użyłem go z Apache i Squid. SSL jest również opcją dla Squid, tylko Debian go nie włącza z powodu problemów licencyjnych.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
:Każda
auth_param
dyrektywa 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:
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 .
źródło
NTLM
?Kerberos
? który z nich jest obsługiwany w większości przeglądarek i ma już „moduł uwierzytelniający”, który obsługuje ldap?auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>
go nie działa, awaria squid i uruchamiana jest ponownie za każdym razem, gdy użytkownik próbuje się uwierzytelnić. Może dlatego, że używam niewłaściwegoparameters
, ale używam tych samych parametrówbasic
i działa dobrze. Jakieś pomysły?