web-dev-qa-db-ja.com

Squidでの安全なユーザー認証のストーリー

むかしむかし、南アメリカに美しい暖かい仮想ジャングルがあり、イカのサーバーがそこに住んでいました。これはネットワークの知覚的なイメージです：

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

Usersがインターネットへのアクセスを要求するとき、squidは名前とパスポートを尋ね、LDAPによってそれらを認証し、LDAPがそれらを承認した場合、それらを許可します。

何人かのスニファーがユーザーとイカの間のパスでパスポートを盗むまで、誰もが満足していました[パスA]。この災害は、Squidが_Basic-Authentication_メソッドを使用したために発生しました。

ジャングルの人々が問題を解決するために集まった。一部のバニーは、NTLMメソッドを使用して提供されました。ヘビは_Digest-Authentication_を好む一方、Kerberosは木が推奨しました。

結局、ジャングルの人々によって提供された多くの解決策はすべて混乱しました！ライオンは状況を終わらせることを決めました。彼は解決策のルールを叫んだ：

  • ソリューションは安全でなければなりません！
  • ほとんどのブラウザーとソフトウェア（ダウンロードソフトウェアなど）でソリューションが機能するか
  • ソリューションはシンプルで、他の巨大なサブシステム（Sambaサーバーなど）を必要としないものとします。
  • その方法は特別なドメインに依存してはならない。 （例：Active Directory）

次に、サルが提供する非常に手ごろな包括的で賢い解決策は、彼をジャングルの新しい王にします！

解決策は何だったと思いますか？

ヒント：squidとLDAPの間のパスはライオンによって保護されているため、ソリューションで保護する必要はありません。

注：話が退屈で乱雑なものである場合は申し訳ありませんが、そのほとんどは本物です！ =）

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

更新：

Massimo は、Users-squidとsquid-LDAPの間の認証方法が同じである必要はないことを説明しました。任意の方法を使用してユーザーから認証情報を取得し、任意の方法を使用して収集されたデータを認証することができます。

しかし、問題があります。すべてのタイプの認証システムの入出力は同じではありません。例えば：

  • Basic認証者は、「ユーザー名とパスワード」のペアを1行で読み取り、ユーザーパスが正しい場合はOKを返信するか、ERR
  • Digestオーセンティケーターは_username:realm_を読み取り、HA(A1)またはERRの16進エンコードされた応答を返す必要があります。

Client-squidメソッドとsquid-ldapメソッドの間に直接の関係はありませんが、クライアントから収集されたデータは、squid-ldap部分で使用されるメソッドと互換性がある必要があります。したがって、ユーザー側で認証方法を変更する場合は、おそらく認証システムも変更する必要があります。

したがって、問題は次のように単純化されます：

  1. 最初のレベルでは、私（サル！）がユーザー側で適切な認証方法を探しています。どの方法が安全でほとんどのブラウザーでサポートされているかをお勧めしますか？ NTLM、Kerberos、Digestの間で混乱しています。

  2. 選択したメソッドの資格情報をサポートし、LDAPを介して認証するオーセンティケーターを見つけることができる場所。

securityauthenticationldapsquidkerberos
17
Isaac

KerberosはHTTP認証のオプションではありません。 NTLMは、IE以外のブラウザでは十分にサポートされていません。 AFAIK squidでは実行できないHTTPSの背後に配置しない限り、Basicは安全ではありません。ダイジェストが残りました。

1
delimiter69

ここで役立つ1つの興味深い機能は、Squidがクライアントブラウザに認証を要求するために使用する方法（パスA）が、ユーザーによって提供された資格情報を実際に検証するために使用する方法（パスB）に関連する必要がないことです。 ）。つまり、Squidでクライアントブラウザを使用してNTLMを「話す」ことができますが、Linuxの内部ユーザーデータベース（/ etc/passwd）に対してユーザーを十分に検証できます。 no（パスAの）NTLMを使用して取得した資格情報を実際に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とパスワードを受け取り、 "yes"または "no"と回答できる限り、ここで必要な認証プログラム（カスタム作成のプログラムでも）を使用できます。

LDAPクエリを実行するために使用しているオーセンティケーターをすべて取得し、現在の「auth_param basic」ステートメントではなく、「auth_param ntlm」または「auth_param digest」ステートメントに貼り付けるだけです。

更新：

オーセンティケーターとして必ず squid_ldap_auth を使用する必要がありますが、正確にはわかりませんhow使用している特定の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 。

4
Massimo