☰

Squid における安全なユーザー認証のストーリー

tag-icon • tag-icon security authentication ldap squid kerberos
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は「ユーザー名パスワード」のペアを1行で読み取り、OKユーザー名パスワードが正しい場合は応答します。ERR
  • 認証Digest者は を読み取りusername:realm、 の 16 進数エンコードされたHA(A1)またはを応答する必要がありますERR。

クライアント squid 方式と squid-ldap 方式の間には直接的な関係はありませんが、クライアントから収集されたデータは、squid-ldap 部分で使用される方式と互換性がある必要があります。したがって、ユーザー側で認証方法を変更する場合は、認証子も変更する必要がある可能性があります。

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

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

  2. 選択した方法の資格情報情報をサポートし、LDAP を介して認証する認証子はどこにありますか。

答え1

Kerberos は HTTP 認証のオプションではありません。NTLM は IE 以外のブラウザでは十分にサポートされていません。Basic は、私の知る限り squid ではできない HTTPS の背後に配置しない限り安全ではありません。そのため、Digest が残ります。

答え2

ここで役立つ興味深い特徴の 1 つは、Squid がクライアント ブラウザに認証を要求する方法 (パス A) は、ユーザーが入力した資格情報を実際に検証する方法 (パス B) とはまったく関係がないことです。つまり、Squid がクライアント ブラウザと 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。

関連情報