web-dev-qa-db-ja.com

RADIUSサーバーでTTLSを使用してPAPを使用しても大丈夫ですか?

RADIUSサーバー(Freeradius 3.x)を展開し、LDAPデータベース(ForgeRock OpenDJ)に接続しました。

有効な証明書を使用してEAP-TTLSを正常に構成し、デフォルトの接続方法として設定しました。 (他のほとんどすべての設定はデフォルトのままです)

ただし、EAP-TTLSが確立されると、パスワードはPAPを使用して転送されます。私はネットワークの専門家ではありませんが、PAPは保護されておらず、使用すべきではないことを読みましたか? (オンラインには紛らわしい資料がたくさんあるように感じます

MS-CHAPv2などの他の方法でログインしようとすると、さまざまなエラーで失敗します。

 FAILED: No NT/LM-Password.  Cannot perform authentication'

または

freeradius_1  | (22) eap_md5: ERROR: Cleartext-Password is required for EAP-MD5 authentication

明らかに追加の構成が必要です。

問題は、2019年の時点でEAP-TTLSがある場合、PAPで問題ありませんか?または、デフォルトとして別のタイプを設定することを検討する必要がありますか?

LDAPには(明らかに)パスワードがハッシュされているので、別のオプションもありますか?私が見つけた このドキュメント に基づくと、これが私たちの唯一の選択肢のようです。

1
pagep

EAP-TTLS protocol layering diagram

この場合、サーバーによって提示された証明書がサプリカントによって正しく検証されていれば、機密性(スヌーピングに対する保護)と整合性(変更に対する保護)はEAP-TLS/TLSによって提供されます。

ここで重要なのは、サーバーの証明書で正しく検証されていることです。そうでない場合、攻撃者はハニーポットネットワークを設定し、偽の証明書をサプリカントに提示して、プレーンテキストの資格情報を収集する可能性があります。

セキュリティに真剣に取り組む組織は、EAP-TLS(パスワードの必要性を否定する)を実装するか、ワイヤレスクライアントでディゾルブ可能なインストーラー(SecureW2、Cloudpath、eduroamCAT-これがeduroamの場合)を実行して、802.1X認証設定を正しく構成します。

前回Windows10をチェックしたとき、特に、証明書/ SSIDの固定は実装されていなかったため、最初の認証試行中にサーバーの証明書を信頼したことを示しても、実際にはセキュリティは追加されませんでした。別の証明書を使用した後続の認証試行では、サプリカントは、不一致を示すことなく、新しい証明書のフィンガープリントを喜んで提示します。これを修正する唯一の方法は、ワイヤレスネットワークの証明書検証設定(信頼できるCA、予想されるサブジェクト名パターン)を手動で、または(上記のように)ディゾルブ可能なインストーラーを使用して明示的に設定することです。

LDAPで機能するTTLS/PEAP内部メソッドに関する他の質問に答えるために、LDAPv3認証済みバインドを使用してユーザーを認証している場合は、はい、PAPまたはGTC(PEAPv0/GTCを参照)のみが機能します。どちらもほぼ同じように動作します。

ハッシュをプルバックしてRADIUSサーバーでローカルに比較を行い、ユーザーのパスワードのNT-Passwordハッシュと、使用している他のハッシュを保存する場合、これはMSCHAPv2を実行できます。

ただし、正直なところ、NTパスワードは非常に弱いハッシュ(MD4)を使用しているため、OpenLDAPにクリアテキストを保存するのとほぼ同じくらい悪いです。 OpenLDAPインストールが危険にさらされる可能性、すべてのハッシュが盗まれたりひびが入ったりするリスク、誰かがMITM攻撃を仕掛ける可能性、およびパスワードのサブセットが盗まれるリスクを比較検討する必要があります。

最後に、EAP-PWDを使用している場合、サプリカントとRADIUSサーバーの両方でパスワードのハッシュコピーを使用するためのサポートが制限されていますが、このEAPメソッドは外部では広くサポートされていませんLinux環境の。

TBHの状況にはかなり不満がありますが、すべての人に新しいEAPメソッドを採用させるには、複数のベンダーの多大な努力が必要になります。

FreeRADIUS側で実装できるのは、証明書の検証設定で「スポットチェック」を設定し、失敗したユーザーを修正することだけです。これを行う方法は、サプリカントに提示された証明書を無効な証明書と動的に交換し、サプリカントが正しいアラート(invalid_ca)をRADIUSサーバーに返すことを確認することです。これにより、認証の失敗(すべてが正しく機能する場合)が、スポットチェックの頻度がかなり低い限り、サプリカントもかなり迅速に再試行します。

2