История безопасной аутентификации пользователей в squid

Однажды в Южной Америке были прекрасные теплые виртуальные джунгли, и там жил сервер Squid. Вот образ восприятия сети:

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

Когда Usersзапросят доступ в интернет, squidспросят их имя и паспорт, подтвердят их подлинность LDAPи, если ldap утвердит их, то он их предоставит.

Все были счастливы, пока некоторые снифферы не украли паспорт на пути между пользователями и squid [путь A]. Эта катастрофа произошла потому, что Squid использовал 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.

Хотя нет прямой связи между методом client-squid и squid-ldap, собранные данные от клиента должны быть совместимы с методом, используемым в части squid-ldap. Поэтому, если мы изменим метод аутентификации на стороне пользователя, возможно, нам следует также изменить наш аутентификатор.

Таким образом, проблема упрощается до:

1. На первом уровне я (обезьяна!) Ищу хороший метод аутентификации на стороне пользователя. Какой метод вы рекомендуете, который является безопасным и поддерживается большинством браузеров ? Я в замешательстве между NTLM, Kerberosи Digest.

2. Где я могу найти аутентификатор, который поддерживает учетные данные выбранного метода и аутентифицируется через LDAP.

Kerberos не является опцией для аутентификации HTTP. NTLM плохо поддерживается ни в одном браузере, кроме IE. Basic не является безопасным, если вы не установите его за HTTPS, чего не может сделать AFAIK squid. Итак, вы остались с дайджестом.

Одна интересная особенность, которая может вам здесь помочь, заключается в том, что метод, используемый 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 digest» вместо «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 .