この記事では、Red Hat Enterprise Linux (RHEL) 8 の暗号化ポリシーを設定して Cipher Block Chaining (CBC) を削除する方法の一例を紹介します。まずは、CBC の簡単な背景と RHEL 8 のデフォルトの暗号化ポリシーについて説明します。
運用レベルではほとんどの人が、システムに複雑な構成があって情報が多すぎるためにすべてを理解しきれない、またはすべてを理解するには情報が不足しているという状況を経験しています。
たとえば、「このサーバーでは、脆弱性があるため非推奨となった CBC 暗号がサポートされている」という調査結果が出て、新たな脆弱性から保護されているかどうかを尋ねられ、環境内のシステムが影響を受けているかについて至急報告して対処するように依頼されたことはありませんか?
このような状況下では、どのようなツールを使用しますか?どのような確認を行いますか?システムは適切に設定されていますか?サーバーに既知の脆弱性は存在しませんか?
幸いなことに、これらの質問は RHEL 8 で利用可能なテクノロジーによって解決し、運用効率の改善と、暗号化ポリシーツールの信頼性と理解の向上を実現できます。
問題の分析
まずは、この Wikipedia のエントリーを参考にしながら、目下の問題を分析してみましょう。
Wikipedia では、CBC とはブロック暗号を使用する多数のモードのうちの 1 つで、現在の暗号文ブロックと前のブロックを XOR 演算してから暗号化するものであると説明されています。また、「最も一般的に使用される操作モード」であり、「Niels Ferguson と Bruce Schneier が推奨する 2 つのブロック暗号モードの 1 つ」との説明もあります。
さらに、1976 年に開発されたとの記述もあるので、この方式はすでに古く安全性に疑問があると考えることもできます。しかし、古いからといって、安全でないことを意味するわけではありません。Diffie-Hellman キー交換も 1976 年に登場しましたが、現在でも広く使用されており、安全性が低いとは考えられていません。
とはいえ、そのような情報はどれも、この状況を理解するには役立ちません。先ほどの調査結果が出る発端となったのはおそらく自動脆弱性スキャナーが実行され、OpenSSH サーバーが CBC 暗号モードの使用を拒否しないことについて、CVE-2008-5161 を根拠としてアラートを発したことにあります。また、こちらや別の同様の暗号化文書も引き合いに出されたかもしれません。「したがって、このプロトコルの弱点を利用して対話型セッションが有効に攻撃される可能性は非常に低い。攻撃者は、成功するまでに約 11,356 回の接続強制終了を試行することになるだろう」といった解説を読めば安心材料にはなりますが、このことは、10 年以上前から知られているこのセキュリティ問題が RHEL で対処されていないことを意味するのでしょうか。
幸いなことに、Red Hat は製品に存在する脆弱性を監視し、緩和するために積極的に取り組んでいます。実際、前述の NIST の CVE-2008-5161 のページでは、Red Hat ベンダーの声明が目立つように取り上げられ、この問題は RHEL 5 で修正されていることがわかります。Red Hat では、sshd 構成で CBC 暗号を無効にする回避策も提供しています。
その記事では、対象のリスク軽減策がアップストリームのパッチを適用することであると明示されており、それにより攻撃が成功する可能性はさらに低下します。脆弱性スキャナーはそのような情報を認識していません。特定のパッケージバージョンが存在するかどうかを確認し、影響を受ける既知のバージョンと照合して、結果を報告するだけです。これらのツールは完璧ではなく、そのような軽減策の有無を検出することはできません。
特定のアルゴリズムのセキュリティに疑念があるなら、もう一歩踏み込んで、無効にすることを検討してもよいでしょう。こうした変更を検討するにあたり、互換性の問題とのバランスを考慮する必要があります。
これらの CBC 暗号は、古い SSH クライアントやサーバーと相互運用するための唯一の共通言語となっている可能性があります。また、より安全なデフォルト設定と互換性のバランスを取るのは、ディストリビューション作成者の責任になります。
たとえば、Fedora 33 では、このマージリクエスト・アップストリームにあるように、SSH での CBC 暗号の使用は無効にされています。しかし、その 1 年前にリリースされたエンタープライズ向けディストリビューションである RHEL 8 では、デフォルトで有効な状態を維持することが選択されています。その根拠には、Bugzilla の 1818103 - SSH Server CBC Mode Ciphers Enabled in RHCOS にあるように、軽減策があることと互換性の理由が含まれます。
バランスの取れたデフォルトは重要ですが、デフォルトとは変更されるものです。ユーザーの状況はそれぞれ異なり、適切な決定を下すのは各ユーザーに任されています。RHEL 8 はこのニーズを満たすために、暗号化アルゴリズムの使用の無効化/有効化を一元的に管理する新しいメカニズムに切り替えました。それが crypto-policies です。この機会に、crypto-policies を使用して CBC 暗号を無効にする方法を確認しましょう。
RHEL 8 の暗号化ポリシー関連の機能と設定
RHEL 8 のデフォルトポリシーを確認すると、状況をより深く理解できます。
sudo less /usr/share/crypto-policies/policies/DEFAULT.pol
# A reasonable default for today's standards.It should provide
# 112-bit security with the exception of SHA1 signatures needed for DNSSec
# and other still prevalent legacy use of SHA1 signatures.
RHEL 8 には、crypto-policies に関して追加のセキュリティ要件に合わせて設定できるその他のポリシーもあります。
FIPS.pol:承認済みの FIPS アルゴリズムのみを使用するポリシー
FUTURE.pol:短期的な将来の攻撃に耐えられると考えられる保守的なレベルのセキュリティを提供するレベル
LEGACY.pol:レガシーシステムとの最大の互換性を維持する設定を提供する
サブポリシーを作成してこれらのポリシーを変更したり、独自のポリシーをゼロから作成したりできる柔軟性もあります。以前公開した Red Hat ブログの記事で、update-crypto-policies ツールとその機能、使用方法について説明しています。
ここでのトピックに関連する RHEL 8 のその他の重要なドキュメントとして、「システム全体の暗号化ポリシーの使用」があります。
RHEL 8 の暗号化ポリシーを設定して CBC を削除する方法
最初の問題に戻って、監査人が追加の裏付けとして、脆弱性評価ツールによって報告された次のような問題を示してきたとします。"Vulnerability Name: SSH CBC Mode Ciphers Enabled, Description: CBC Mode Ciphers are enabled on the SSH Server."
ここでは区別が必要で、オンラインのコメントからわかるように、多くの場合は脆弱性スキャンに合格した後でシステムを設定し、問題を修復できます。実際には、sshd プロセスが CBC 関連の暗号を使用しないように設定するので、sshd はこれらの暗号を使用できません。その種の回避策を適用する方法に関する手順も公開されています。
これは sshd プロセスのみが対象であり、サーバー全体ではありません。システムレベルではなくプロセスレベルで機能します。つまり、SSH CBC モードのチェックは合格しますが、一部の CBC 暗号は依然としてサーバーに残ります。この変更はシステムレベルで行うことが推奨され、これはまさに update-crypto-policies ツールが実行できることです。
まず、現在 RHEL 8 サーバーで使用されている暗号化ポリシーを確認します。
update-crypto-policies --show
DEFAULT
RHEL 8 が暗号化ポリシーとして DEFAULT を使用していることが確認できたので、CBC に関連する暗号を /usr/share/crypto-policies/policies/DEFAULT.pol で検索します。
tls_cipher = ...AES-256-CBC ...AES-128-CBC
cipher = ...AES-256-CBC CAMELLIA-256-CBC AES-128-CBC CAMELLIA-128-CBC
(わかりやすくするため、関係のない暗号は除外されています)
DEFAULT ポリシーで使用されている CBC 関連の暗号は 6 つあります。
これにより、状況が複雑になります。この記事の執筆時点では、追加の暗号化ポリシー設定 ssh_cipher の例を示すポリシーファイルはありません。これについては man ページで次のように言及されています。man crypto-policies (... ssh_cipher: Optional; list of allowed symmetric encryption algorithms (including the modes) for use with the SSH protocol.If absent, the value is derived from cipher...)。
しかし ssh_cipher は存在します。DEFAULT ポリシーでは明示的に表示されていませんが、CBC に関連する暗号を事実上すべて削除するには、サブポリシーで明示的に除外する必要があります。
使用中の DEFAULT ポリシーを修正するサブポリシーを作成できます。そのためには、サブポリシーファイルを作成する必要があります。
/etc/crypto-policies/policies/modules/DISABLE-CBC.pmod注:命名規則は重要です。サブポリシー名はすべて大文字、拡張子名 .pmod は小文字にする必要があります。
このファイルには、 DEFAULT ポリシーに加えたい変更を含める必要があります。
DEFAULT プロファイルを変更してサーバーから CBC 暗号を削除するには、次の内容を追加する必要があります。
tls_cipher = -AES-256-CBC -AES-128-CBC
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC
ssh_cipher = -AES-128-CBC -AES-256-CBC
sshd のみについてサーバーから CBC アルゴリズムを削除するには、次のようにします。
ssh_cipher = -AES-128-CBC -AES-256-CBC
注:ssh_cipher については例が存在しないため、値は次のように仮定できます。
ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC実際には、この -CAMELLIA は指定しません。man sshd_config | grep -i cbc を実行すると、実際には sshd によって通知されたり使用されたりしていないであろうことがわかります。
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc )
ssh -vv を実行して "Their offer" の aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr) で確認できるように、3des-cbc も RHEL 8.2 サーバーから通知されていません。
CBC 暗号を削除する設定のサブポリシーを設定します。
sudo update-crypto-policies --set DEFAULT:DISABLE-CBC適切に設定されていることを、次のようにして確認できます。
sudo update-crypto-policies --show
DEFAULT:DISABLE-CBC
ポリシーとサブポリシーを有効にするため、サーバーをリブートする必要があります。
この時点で、サーバーによって使用される CBC 暗号は残っていません。このことを簡単に確認する方法の 1 つは、RHEL 8 サーバーからこのコマンドを実行して sshd で実際に確認することです。
ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 ログイン情報が表示され、ユーザーは有効な資格情報を使用して接続できるはずです。
sshd が使用できる CBC 暗号がない場合は、次のように表示されます。
Unable to negotiate with 127.0.0.1 port 22: no matching cipher found. その後、sshd プロセスから、そのサーバーが提供する暗号が次のように表示されます。 “Their offer: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr”
まとめ
このブログ投稿では、特定の暗号化ポリシー要件に準拠するように RHEL 8 サーバーを設定する方法について概要を説明しました。セキュリティ上の懸念を検証した後に、CBC 関連の暗号をサーバーから削除する方法を説明しました。update-crypto-policies などのツールを使用し、個々のコンポーネントレベルで対応するのではなくサーバーレベルで、適切な方法で一部のセキュリティ・コンプライアンス要件を満たすことができます。
執筆者紹介
Jean-Sébastien Tougne has more than 14 years of experience as an engineer in DTV, Oil and Gas, Computer Systems and Finance industries. He is currently a Red Hat consultant.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
仮想化
オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください