CentOS 6 サーバーを新しい OpenSSL 脆弱性から安全に保つ

CloudLinux は、CentOS 6 サーバーを新しい OpenSSL 脆弱性から安全に保つために、2024 年までの延長サポートを提供します。

OpenSSL は最近、バージョン 1.0.2 および 1.1.1 を実行しているサーバーに影響を与える高レベルの調査結果に対するセキュリティパッチをリリースしました。残念ながら、OpenSSL は、CentOS 6 用のパッチはリリースせず、CentOS 7 と CentOS 8 のみをリリースすると発表しました。これにより、CentOS 6 オペレーティングシステムを含む、パッチが適用されていない OpenSSL を実行しているサーバーは、ソフトウェア、重要なサービス、またはオペレーティングシステムがクラッシュする可能性があります。ただし、CloudLinux は、OpenSSL の現在のバージョン、サポートされていない 1.0.1 バージョン、および CentOS 6 オペレーティングシステムを実行しているサーバーにパッチを適用します。

CVE-2020-1971 の脆弱性の詳細

OpenSSL には、2 つのパラメータを比較して次の 2 つのアクションを実行する GENERAL_NAME_cmp() という名前の関数があります。

X.509 証明書を証明書失効リスト (CRL) 内の項目と比較します。
応答トークンの署名者のタイムスタンプを機関名のタイムスタンプと比較します。

この機能は、証明書が失効していないことを保証するための安全な通信において重要です。認証局 (CA) 組織は、いくつかの理由で証明書を取り消します。サーバーの秘密キーが侵害により盗まれた場合、CA は通信の整合性を保護するために証明書を取り消します。失効のその他の理由としては、証明書の誤用のため新しい証明書を発行する必要がある、CA が侵害された、または CA がドメイン所有者の許可なしに証明書を作成したなどが挙げられます。これらのいずれの場合でも、攻撃者が標的のドメインになりすましてユーザーをだましてサイトを信頼させると、高度なフィッシング攻撃や機密データの漏洩につながる可能性があります。

攻撃者が GENERAL_NAME_cmp() 関数に渡される両方のパラメータを制御できる場合、両方のパラメータが同じタイプであれば DoS 条件が満たされます。この脆弱性を発見した Google 研究者は、OpenSSL コードで定義されているタイプ EDIPartyName の 2 つのパラメータを関数に渡すことで、概念実証のデモを実行することができました。

ID CVE-2020-1971 が割り当てられたこの脆弱性のパッチは、2020 年 12 月 8 日にリリースされました。オープンソースコードへの変更は、OpenSSL の Github のリポジトリで見つけることができます。。この脆弱性の詳細については、OpenSSL のお知らせページでご覧いただけます。

OpenSSL にパッチを適用しないままにするとどうなりますか?

リモートコード実行 (RCE) は懸念事項ではありませんが、パッチが適用されていないサーバーは DoS の対象となり、サービスがオフラインになりユーザーが利用できなくなる分散型サービス拒否 (DDoS) 状態に陥る可能性があります。ビジネスの生産性を維持するために可用性を維持する必要がある、またはサービスレベルアグリーメントを満たすためにオンラインにする必要がある重要なサーバーは、攻撃者の標的になる可能性があります。 CVE はリスクレベルを「高」に設定します。これは、組織にとって深刻な脆弱性とみなされることを意味します。「緊急」とラベル付けされた脆弱性のみがより深刻であり、これらの脆弱性は約 5 年に 1 回発生します。

CentOS 6 および/または KernelCare+ の延長サポートによる軽減

CentOS 6 の CloudLinux 延長サポートでは、顧客がこのセキュリティパッチを利用できます。 CentOS 6 のサポート終了 (EOL) は 2020 年 11 月でしたが、CloudLinux は、管理者がオペレーティングシステムの新しいバージョンにアップグレードできるまで、openSSL の脆弱性からサーバーを保護するために 2024 年までの延長サポートを提供します。延長サポートにサインアップするには、このフォームに記入してください。

KernelCare には、OpenSSL や他のいくつかの共有ライブラリに対するライブパッチ適用のサポートもあります。

CentOS 6 の CloudLinux 拡張サポートのインストール

CloudLinux 延長サポートのインストールには、いくつかのコマンドのみが必要です。

インストーラースクリプトをダウンロードします。

wget https://repo.cloudlinux.com/centos6-els/install-centos6-els-repo.py

インストーラースクリプトを実行します (ライセンスキーが必要であることに注意してください)。

python install-centos6-els-repo.py --license-key XXX-XXXXXXXXXXXX

上記のコマンドは、リポジトリ PGP キーを含む centos-els-release パッケージをインストールします。次のコマンドを実行すると、インストールが完了したことを確認できます。

rpm -q centos-els-release

上記のコマンドの出力には次のように表示されるはずです。

centos-els-release-6-6.10.1.el6.x86_64

注: 2020 年 12 月 1 日の時点でまだ CentOS を実行している既存のお客様は、自動的に EOL サポートに変換されました。

KernelCare+ のインストール

KernelCare+ は、CloudLinux ES をインストールするのと同じくらい簡単です。 KernelCare+ をインストールするには、次のコマンドのいずれかを実行します。

curl -s -L https://kernelcare.com/installer | bash

または、

wget -qq -O - https://kernelcare.com/installer | bash

KernelCare+ のインストールの詳細については、公式ドキュメントを参照してください。

結論

研究者らは、この OpenSSL の脆弱性が悪用するのははるかに難しいと指摘していますが、これはサーバーへのパッチ適用を遅らせる必要があるという意味ではありません。手動で行う場合でも、OpenSSL の新しいバージョンにアップグレードする場合でも、KernelCare+ によるライブパッチ適用を選択する場合でも、すぐに実行してください。 OpenSSL は依然として最もソフトウェアを標的としたテクノロジーの 1 つであり、DDoS 攻撃は思っているよりも頻繁に発生しています。

関連記事:

再起動せずに Linux サーバーを実行するのに役立つ 5 つのカーネルライブパッチツール