Історія безпечної автентифікації користувача в кальмарах

колись у Південній Америці був прекрасний теплий віртуальний джунглі, і там жив сервер кальмарів. ось перцептивний образ мережі:

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

Коли Usersзапит має доступ до Інтернету, squidзапитайте їх ім’я та паспорт, засвідчіть їх автентифікацією, LDAPі якщо ldap їх схвалив, він надав їх.

Всі були щасливі, поки деякі снайфери не вкрали паспорт у дорозі між користувачами та кальмарами [шлях А]. Ця катастрофа сталася тому, що кальмари використовували Basic-Authenticationметод.

Люди джунглів зібралися, щоб вирішити проблему. Деякі зайчики пропонують за допомогою NTLMметоду. Змії віддають перевагу, Digest-Authenticationпоки їх Kerberosрекомендують дерева.

Зрештою, багато рішень, пропонованих людьми джунглів, і всі були розгублені! Лев вирішив припинити ситуацію. Він кричав правила рішення:

• Чи повинен розчин бути безпечним!
• Має працювати з рішенням більшості браузерів та програмних засобів (наприклад, завантажувати програмне забезпечення)
• Нехай рішення буде простим і не потребує іншої величезної підсистеми (наприклад, сервер Samba)
• Не повинен метод залежати від спеціального домену. (наприклад, Active Directory)

Тоді, дуже резонне-всеосяжне розумне рішення, яке пропонує мавпа, що робить його новим королем джунглів!

ви можете здогадатися, яке було рішення?

Порада: Шлях між левом squidі LDAPзахищений ним, тому рішення не повинні його закріплювати.

Примітка: вибачте, якщо історія нудна і безладна, але більшість вона справжня! =)

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

Оновлення:

Массімо пояснив, що метод автентифікації між Users- squidі squid- LDAPне повинен бути однаковим. ми можемо використовувати довільний метод для отримання інформації про аутентифікацію від користувачів, а довільний метод для аутентифікованих зібраних даних.

Але є проблема: вхід / вихід усіх типів автентифікаторів неоднаковий. Наприклад:

• Basicаутентифікатор слід читати «ім'я користувача пароль» пару в лінії і відповідати OKякщо користувач прохід правильно абоERR
• Digestаутентифікатор повинен прочитати username:realmі відповісти шестнадцатеричную кодування в HA(A1)або ERR.

Начебто немає прямого зв’язку між методом «клієнт-кальмар» та методом «кальмар-ldap», зібрані дані клієнта повинні бути сумісні з методом, який використовується в частині «кальмар-ldap». Тому, якщо ми змінимо метод автентифікації на стороні користувачів, можливо, нам слід змінити і наш автентифікатор.

Тож проблема спрощується до:

1. На першому рівні я (мавпа!) Шукаю хорошого методу аутентифікації на стороні користувача. Який метод ви рекомендуєте, який захищений та підтримується більшістю браузерів ? я перебуваю в замішанні між NTLM, Kerberosі Digest.

2. Де я можу знайти автентифікатор, який підтримує інформацію про облікові дані обраного методу та аутентифікується через LDAP.

Kerberos - це не варіант для аутентифікації HTTP. NTLM не підтримується в будь-якому браузері, крім IE. Basic не є безпечним, якщо ви не поставите його за HTTPS, який кальмар AFAIK не може зробити. Отже, вам залишається дайджест.

Однією цікавою особливістю, яка може вам допомогти тут, є те, що метод Squid використовує для того, щоб запитувати у веб-переглядача клієнта автентифікацію (шлях A) взагалі не потрібно пов'язувати з методом, який він використовує для фактичної перевірки облікових даних, наданих користувачем (шлях B ). Це означає, що ви можете змусити Squid "говорити" NTLM з веб-переглядачами клієнтів, але тоді це може дуже добре перевірити користувачів щодо внутрішньої бази даних Linux (/ etc / passwd). Там немає ні необхідності в облікових даних , отриманих з допомогою NTLM (по шляху А) насправді бути підтверджено проти домену Windows (на шляху В). Це ж стосується будь-якої можливої ​​комбінації методів аутентифікації на стороні клієнта та методів аутентифікації на стороні сервера.

Що означає у вашому випадку, це те, що ви можете сміливо налаштувати Squid, щоб вимагати автентифікації NTLM у браузерів клієнтів замість основної автентифікації, і це жодним чином не вимагатиме від вас фактичного використання Samba / WinBind / AD / будь-чого іншого.

Таким чином, ви можете вибрати будь-який метод, який ви хочете для аутентифікації на стороні клієнта, але все одно продовжувати перевіряти користувачів на сервері LDAP після того, як вони надали свої дані, використовуючи обраний вами метод.

Магія відбувається, звичайно, у 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

Кожна auth_paramдиректива забезпечує специфічну автентифікацію для клієнтських браузерів (шлях A), тоді як частина "програми" встановлює те, що Squid насправді використовуватиме для перевірки даних, наданих користувачами. Тут ви можете використовувати будь-яку програму аутентифікатора (навіть написану на замовлення), якщо вона може отримати ідентифікатор користувача та пароль та відповісти "так" чи "ні".

Вам просто потрібно взяти будь-який автентифікатор, який ви використовуєте, щоб зробити свій LDAP-запит і вставити його у висловлювання "auth_param ntlm" або "auth_param дайджест", а не в "auth_param basic", де він знаходиться зараз.

Оновлення:

Ви обов'язково повинні використовувати squid_ldap_auth в якості автентифікатора, але я не можу точно сказати, як без деталей про конкретний сервер LDAP, який ви використовуєте.

Щодо аутентифікації на стороні клієнта, будь-яка повинна бути хорошою; Я дуже задоволений NTLM, і більшість браузерів підтримують його в наші дні.

Така конфігурація виглядатиме так у squid.conf:

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

Це запитає облікові дані користувачів (шлях A) за допомогою NTLM, а потім перевірити їх на сервері LDAP (шлях B); але ці "параметри" суворо залежать від вашої реалізації та конфігурації LDAP.

Це також може допомогти: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html .