公衆インターネットを介したKerberos認証

Question

リモートクライアントがインターネット経由でKDCにアクセスできるようにすることの脅威は何ですか？

認証はチャレンジ/レスポンスプロトコルであり、パスワードは送信されないというのは私の理解です。ブルートフォース攻撃は、これが一般的でない理由ですか？

これは、複数のホスト上の複数のサービスが一度に侵害される可能性があるため、Kerberos認証は個々のSSHまたはメールアカウントをブルートフォースで強制するよりも価値があるためですか？それは、KDC自体の攻撃面のためであり、ピンホールファイアウォールは、認証と承認のためのこの貴重なリンチピンへのアクセスを防止するための十分な障壁とは見なされていないのですか？

gowenfawr · Accepted Answer

間違いなく、Kerberosが公衆インターネット経由で使用されない理由は、プロトコルのセキュリティやKDCの公開とは関係ありませんが、ほとんどの「公衆」のニーズに適合しない認証モデルです。インターネット」アプリケーション。

Wikipediaを引用すると、Kerberosは " 相互認証を提供します—ユーザーとサーバーの両方が互いのIDを確認します。 "これは、ユーザー認証が行われる前に、クライアントマシンがそのIDを保証するために必要なキーを持っている必要があることを意味します場所。「パブリックインターネット」アプリケーション用にこれらのキーを配布することは、いくつかの理由で実用的ではありません。Windowsパッチを定期的にインストールするさまざまな人が所有する銀行のWebサイトにアクセスするPCの数を検討してください。企業のITが登場してKerberosを構成するのとは異なります。

Kerberosは厳密に同期されたクロックを必要とします-集中管理された企業または教育環境ではそれを実行するのは難しくありません。マシンがすべて所有および管理されている場合ははるかに困難です完全に異なる人々。

Kerberosの利点の1つは、初期認証を複数のアプリケーションアクセスにシームレスに活用できることです。公共のインターネットでは、複数のアプリケーションが相互に関連することはほとんどありません-私の銀行、私のメール、私の/などです。アカウントは、お互いまたは同じ一連の人々を信頼するための呼び出しを持ちません。（これはフェデレーションIDの領域に該当し、この領域で作業は行われますが、Kerberosがテーブルにもたらすものと同じものを組み合わせる必要はありません）。

つまり、Kerberosは重いソリューションであり、パブリックインターネットアプリケーションのアクセス制御は軽量な問題です。

実際の質問に直接答えるために、いいえ、ブルートフォース攻撃やKDCの脆弱性に関する懸念がKerberosをインターネットから遠ざけているとは信じていません。このプロトコルは、20年以上にわたって、十分に吟味、攻撃、修正、および更新されてきました。クライアント（マシン）認証の部分だけでも、インターネットなどの大規模なオープンネットワークで予想される多くの攻撃に対する強力な保護を提供します。

Michael Hampton · Answer

Kerberos自体は通常、インターネット経由で使用しても安全です。結局のところ、これは世界で最も敵対的な公衆ネットワークの1つであるMITキャンパスネットワーク）を介して安全になるように設計されていました。

Kerberosホワイトペーパー "Kerberosが信頼できるセキュリティソリューションである理由" は、提起したすべてのポイントに対処しています。部分的に引用するには：

決して公開されたり、ネットワークを介して送信されたりしないパスワードは、攻撃者が盗み取るのがはるかに困難です。したがって、ユーザーのKerberos認証では、認証サービスにパスワードを提示する必要はありません。代わりに、Kerberos認証サービスは暗号化プロトコルを使用します。これにより、ユーザーはパスワードを実際に明らかにすることなく、その所持を証明できます。

分散環境では、要求を認証する必要のあるすべてのクライアントとサーバーでパスワードなどの共有シークレットを維持するのは極端に厄介です。さらに、共有シークレットを多くのシステムに分散すると、潜在的な脆弱性がシステムの数に正比例して増加します。この問題は、「最弱リンク」現象によって悪化します。 Kerberosは、少数の認証サーバーのみに分散された集中データベースを維持することにより、この要件に対処します。全体的なセキュリティは、この中央データベースの保護に大きく依存していますが、多くの汎用システムを保護するよりも、攻撃に対していくつかの専用サーバーを強化する方がはるかに簡単です。認証シークレットを集中管理することで、新しい資格情報の発行、既存の資格情報の取り消し、および資格情報の侵害からの回復も容易になります。

Kerberos開発者は、誰でもネットワークトラフィックを盗聴し、任意のユーザーであると主張し、Kerberosサービス自体を含む任意の正当なサービスを装うことができる不正なサーバーを設定できると想定していました。盗聴攻撃を防ぐために暗号化が使用され、リプレイ攻撃を防ぐためにタイムスタンプとともにセッションキーが導入されました。ユーザー（またはホスト/サービス）がKerberos認証サービスに対して認証を行うと、認証サービスは、以前に確立された共有シークレットを知っていることを証明することにより、ユーザー（またはホスト/サービス）に対して自身を認証します。これらの対抗策の副産物は、Kerberosが、当時は一般的に実行不可能であると見なされていた中間者攻撃からの保護を提供し、Kerberosが最初に展開されてから10年以上になることです。悲しいことに、中間者攻撃はもはや単なる推測ではなく、悪意のある環境を想定して設計されていない今日のインターネットWebでは一般的です。

すべてのシステムをKerberosレルムに合理的に参加させることができる場合、たとえば、それらが会社内のすべてのサイトである場合は、使用しても問題ありません。ただし、すべてを暗号化する必要はありません;たとえば、HTTPはまだ暗号化されていません。ただし、NFSなどの一部のサービスでは、Kerberosを使用してデータフローを暗号化できます。アプリケーションと送信するデータによっては、サイト間でVPNを使用することもできます。

しかし、アプリケーションが一般に公開される場合、Kerberosはおそらく望んでいるものではありません。