오징어의 안전한 사용자 인증 이야기

옛날 옛적에 남아메리카에는 아름다운 따뜻한 가상 정글이 있었고 오징어 서버가 그곳에 살았습니다. 다음은 네트워크의 지각적인 이미지입니다.

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

Users인터넷에 대한 요청이 있을 때, squid그들의 이름과 여권을 요청하고, 그들을 인증 LDAP하고, ldap이 그들을 승인 한 경우, 그것들을 부여했습니다.

일부 스니퍼가 사용자와 오징어 사이의 경로에서 여권을 훔칠 때까지 모두가 행복했습니다 [경로 A]. 이 재해는 오징어가 Basic-Authentication방법을 사용했기 때문에 발생했습니다 .

정글 사람들은 문제를 해결하기 위해 모였습니다. 일부 토끼 NTLM는 방법을 사용하여 제안했습니다 . 뱀 은 나무가 권장하는 Digest-Authentication동안 선호 했습니다 Kerberos.

결국 정글 사람들이 제공하는 많은 솔루션이 혼란 스러웠습니다. 라이온은 상황을 끝내기로 결정했습니다. 그는 솔루션 규칙을 외쳤다.

• 솔루션이 안전해야합니다!
• 솔루션이 대부분의 브라우저 및 소프트웨어 (예 : 소프트웨어 다운로드)에서 작동해야합니다.
• 솔루션이 단순하고 Samba 서버와 같은 다른 거대한 하위 시스템이 필요하지 않아야합니다.
• 방법이 특수 도메인에 의존하지 않아야합니다. (예 : Active Directory)

그런 다음 원숭이가 제공하는 매우 공감할 수있는 포괄적 인 영리한 솔루션으로 정글의 새로운 왕이되었습니다!

해결책이 무엇인지 추측 할 수 있습니까?

팁 : 사이의 경로 squid및 LDAP솔루션을 확보하지 않은, 그래서 사자에 의해 보호됩니다.

참고 : 이야기가 지루하고 지저분하면 죄송하지만 대부분은 실제입니다! =)

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

최신 정보:

Massimo 는 Users- squid와 squid- 사이의 인증 방법 LDAP이 동일 할 필요는 없다고 설명했습니다 . 임의 방법을 사용하여 사용자로부터 인증 정보를 얻고 임의 방법을 사용하여 수집 된 데이터를 인증 할 수 있습니다.

그러나 문제가 있습니다. 모든 유형의 인증 자의 입력 / 출력이 동일하지 않습니다. 예를 들면 다음과 같습니다.

• Basic인증은 줄에 "사용자 이름 암호"쌍을 읽고 답장을해야 OK사용자 패스가 올 경우, 또는ERR
• Digest인증은을 읽어야 username:realm과의 진수로 인코딩 답장을 HA(A1)하거나 ERR.

client-squid 방법과 squid-ldap 방법간에 직접적인 관계는 없지만, 클라이언트에서 수집 된 데이터는 squid-ldap 부분에서 사용 된 방법과 호환되어야합니다. 따라서 사용자 측에서 인증 방법을 변경하면 인증 자도 변경해야합니다.

따라서 문제는 다음과 같이 단순화됩니다.

1. 첫 번째 수준에서 i (원숭이!)는 사용자 측에서 좋은 인증 방법을 찾고 있습니다. 대부분의 브라우저에서 안전하고 지원되는 방법은 무엇입니까? 내가 사이에 혼동에서 오전 NTLM, Kerberos하고 Digest.

2. 여기서 선택한 방법의 자격 증명 정보를 지원하고 LDAP를 통해 인증하는 인증자를 찾을 수 있습니다.

Kerberos는 HTTP 인증을위한 옵션이 아닙니다. NTLM은 IE 이외의 브라우저에서는 잘 지원되지 않습니다. AFAIK 오징어가 할 수없는 HTTPS 뒤에 두지 않으면 기본은 안전하지 않습니다. 그래서 당신은 다이제스트와 함께 남아 있습니다.

여기서 도움이 될 수있는 흥미로운 기능 중 하나는 Squid가 클라이언트 브라우저에 인증을 요청하는 데 사용하는 방법 (경로 A)이 사용자가 제공 한 자격 증명을 실제로 확인하는 데 사용하는 방법 (경로 B)과 전혀 관련이 필요하지 않다는 것입니다. ). 이는 fe가 클라이언트 브라우저와 NTLM을 "통화"할 수있게하지만 Linux의 내부 사용자 데이터베이스 (/ etc / passwd)에 대해 사용자를 매우 잘 검증 할 수 있음을 의미합니다. NTLM (경로 A)을 사용하여 획득 한 자격 증명은 실제로 Windows 도메인 (경로 B)에 대해 유효성을 검사 할 필요 가 없습니다 . 클라이언트 측 인증 방법과 서버 측 인증 방법의 가능한 조합에도 동일하게 적용됩니다.

이것이 의미하는 바는 기본 인증 대신 클라이언트 브라우저에서 NTLM 인증을 요청하도록 Squid를 안전하게 구성 할 수 있으며 실제로는 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가 사용자가 제공 한 자격 증명의 유효성을 검증하기 위해 실제로 사용할 항목을 설정합니다. 사용자 ID 및 비밀번호를 수신하고 "예"또는 "아니오"로 응답 할 수있는 한 여기에서 원하는 인증 프로그램 (사용자 정의 작성 프로그램)을 사용할 수 있습니다.

LDAP 쿼리를 수행하는 데 사용하는 인증자를 가져 와서 "auth_param basic"문 대신 "auth_param ntlm"또는 "auth_param digest"문에 붙여 넣으면됩니다.

최신 정보:

squid_ldap_auth 를 인증 자로 사용해야 하지만, 사용중인 특정 LDAP 서버에 대한 세부 정보가 없으면 정확히 어떻게 말할 수 없습니다 .

클라이언트 측 인증과 관련하여 어느 것이나 좋을 것입니다. NTLM에 매우 만족하고 있으며 현재 대부분의 브라우저에서 지원합니다.

이러한 구성은 squid.conf에서 다음과 같습니다.

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

NTLM을 사용하여 사용자 자격 증명 (경로 A)을 요청한 다음 LDAP 서버 (경로 B)에 대해 유효성을 검사합니다. 그러나 이러한 "매개 변수"는 LDAP 구현 및 구성에 따라 다릅니다.

http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html 도 도움이 될 수 있습니다.