HeartbleedOpenSSLの脆弱性からサーバーを保護する方法

投稿日: 2022-04-20 2022-04-20
タグ: Security

重要なSSLセキュリティの脆弱性

2014年4月7日月曜日に、最近のインターネットの歴史の中で最悪のセキュリティホールの1つと呼ばれているOpenSSLの脆弱性が公開されました。 Heartbleedバグと呼ばれるこのバグは、OpenSSLバージョン1.0.1で導入されました。 2012年3月から使用されており、2014年4月7日にリリースされたOpenSSLバージョン1.0.1gにパッチが適用されています。 CVE-2014-0160とタグ付けされた問題は、ここで詳細に説明されています。

このバグにより、攻撃者は脆弱なホストのメモリを読み取ることができます。つまり、脆弱なバージョンのOpenSSLを使用するホストで使用されたキーはすべて侵害されたと見なす必要があります。ディストリビューションはパッケージを更新し、更新をプッシュしていますが、ユーザーは最新のパッケージをプルダウンし、安全でないバージョンに基づいて以前のキーを取り消す必要があります。

安全なバージョンのOpenSSLでシステムを更新する方法、安全でないSSL証明書を取り消す方法、および脆弱性があるかどうかをテストする方法を説明します。

システムを更新する

DigitalOceanミラーは、配布パッケージャーによって利用可能になる最新バージョンのOpenSSLパッケージを含むように更新されています。パッケージを更新する最も簡単な方法は、システム全体を更新することです。

UbuntuとDebianでは、次のように入力して更新できます。

sudo apt-get update
sudo apt-get dist-upgrade

影響を受けるパッケージをのみアップグレードし、システム全体を更新しない場合（他のコンポーネントにアップグレードするとシステムが破損すると思われる場合にのみ推奨）、OpenSSLパッケージを選択的にアップグレードできます。タイピング：

sudo apt-get install --only-upgrade openssl
sudo apt-get install --only-upgrade libssl1.0.0

これにより、脆弱なパッケージがアップグレードされ、システムの残りの部分はアップグレードされていない状態のままになります。

CentOSおよびFedoraでは、次のように入力してシステム全体を更新できます。

yum update

影響を受けるパッケージのみをアップグレードする場合は、代わりに次のコマンドを発行できます。

yum update openssl

繰り返しますが、これは、システム全体を更新しない特別な理由がある場合にのみ推奨されます。

この記事の執筆時点（04/08/14）では、Fedora19の安定版リポジトリにはまだ最新バージョンがありません。更新が受け入れられるのを待つことができますが、先に進んで手動でパッケージをビルドすることもできます。これは、バグの重大度を考慮するとおそらく価値があります。

64ビットシステムの場合：

yum -y install koji
koji download-build --arch=x86_64 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm

次のように入力することで、Fedora19の32ビットシステムでも同じことができます。

yum -y install koji
koji download-build --arch=i686 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.i686.rpm

Arch Linuxでは、次のように入力してパッケージを更新できます。

sudo pacman -Syu

パッケージを選択的に更新すると、Arch Linuxシステムが非常に不安定になる可能性があるため、OpenSSLパッケージのみを更新することはお勧めしません。

これにより、指定されたミラーが最新のパッケージをプルした場合のOpenSSLを含め、最近のすべての更新がプルされます。アップグレードされたパッケージのリストにopensslまたはいくつかのバリアントが表示されます。

終了したら、マシンを再起動して、サーバーがメモリにロードされた古いバージョンを使用していないことを確認する必要があります。あなたは発行することによってそれを行うことができます：

sudo shutdown -r now

バージョン番号の確認

システムを更新した後、OpenSSLのバージョンを確認する必要があります。

OpenSSLバージョン1.0.1gはこの問題の公式修正ですが、ディストリビューションやリリースごとにこれを修正するバージョンは異なる場合があります。一部のリリースとディストリビューションでは、まったく新しいバージョンを古い安定したエコシステムにリリースするのではなく、古いバージョンにパッチを適用して問題を修正しました。

このため、openssl versionコマンドには必要な情報が反映されていない可能性があるため、ディストリビューションのパッケージシステムを確認することをお勧めします。

DebianとUbuntuのリリースと修正バージョン

DebianおよびUbuntuシステムの場合、次のように入力して、OpenSSLパッケージの現在のバージョンを取得します。

dpkg -l | grep "openssl"

次のような出力を受け取るはずです。

ii  openssl                            1.0.1e-2+deb7u6               amd64        Secure Socket Layer (SSL) binary and related cryptographic tools

Debianユーザーの場合、実行しているDebianのリリースによって、修正の正しいバージョンが決まります。 OpenSSLのバージョンが少なくともで、ディストリビューション用にここにリストされているバージョンと同じである場合は、保護する必要があります。

Debian 6（スクイーズ）：影響を受けません（脆弱性の前に古いバージョンで出荷されました）
Debian 7（Wheezy）：1.0.1e-2 + deb7u6
Debianテスト（ジェシー）：1.0.1g-1
Debian不安定版（Sid）：1.0.1g-1

Ubuntuユーザーの場合、パッチが適用された正しいバージョンもリリースに依存します。次のリストを使用して、リリースの最小の安全なバージョンを確認してください。

Ubuntu 10.04 ：影響を受けません（脆弱性の前に古いバージョンで出荷されました）
Ubuntu 12.04 ：1.0.1-4ubuntu5.12
Ubuntu 12.10 ：1.0.1c-3ubuntu2.7
Ubuntu 13.04 ：サポートの終了に達しました。アップグレードする必要があります
Ubuntu 13.10 ：1.0.1e-3ubuntu1.2

サポートされているディストリビューションのいずれかを使用している場合は、OpenSSLのバージョンが最新であることを確認してください。ディストリビューションがサポートされなくなった場合（Ubuntu 13.04）、このバグの重大性のため、サポートされているオペレーティングシステムに移行することを強くお勧めします。

CentOSとFedoraのリリースと修正バージョン

CentOSおよびFedoraシステムの場合、次のように入力して、システムにインストールされているOpenSSLパッケージのバージョンを照会できます。

rpm -q -a | grep "openssl"

次のような出力が表示されます。

openssl-1.0.1e-16.el6_5.7.x86_64

CentOSの場合、将来のSSL相互作用を保護するために適用する必要があるOpenSSLのリリースと最小バージョンは次のとおりです。リストの最後からアーキテクチャを削除します。

CentOS 5 ：影響を受けません（脆弱性の前に古いバージョンで出荷されました）
CentOS 6 ：openssl-1.0.1e-16.el6.5.7

Fedoraユーザーの場合、パッケージのバージョンが少なくとも以下にリストされているものと同じくらい新しいことを確認できます。繰り返しになりますが、これは32ビットと64ビットの両方のリリースに適用されるため、以下のアーキテクチャを削除しました。

Fedora 17 ：影響を受けません（脆弱性の前に古いバージョンで出荷されました）
Fedora 19 ：openssl-1.0.1e-37.fc19.1

注：Fedoraのバージョン番号に細心の注意を払ってください。末尾の「.1」は、パッチが適用されているかどうかを示します。パッケージの最後に「.1」が付いていない場合でも、脆弱です。

ArchLinux修正バージョン

Arch Linuxを実行している場合、複数のリリースがないため、検証ははるかに簡単です。

インストールしたOpenSSLのバージョンを確認できます。

pacman -Q | grep "openssl"

次のような出力が表示されます。

openssl 1.0.1.g-1

インストールされているバージョンがこのリリース以降であれば、問題ありません。

SSL証明書/キーの取り消しと再発行

プロバイダーからSSL証明書を購入し、サーバー上のOpenSSLパッケージを更新した場合は、古いキーを取り消す必要があり、新しいキーを再発行する必要があります。これは「キーの再生成」と呼ばれるプロセスです。

このプロセスは、最初の証明書を発行したSSLサービスに大きく依存しますが、管理インターフェイスで「キーの再生成」または「キーの再発行」に類似したオプションを検索する必要があります。ほとんどのSSL発行者は、キーを再生成すると以前のキーを取り消しますが、通常は、管理インターフェイスを使用して明示的にこれを行うこともできます。

SSLプロバイダーから提供された指示に従ってください。彼らはあなたにCSRを再生する方法について非常に具体的な指示を与えるかもしれませんし、そうでないかもしれません。

使用してほしい特定のopensslコマンドが提供されていない場合は、次のように入力して新しいSSLCSRを生成できます。ルートでない場合は、ここでもsudoを追加します。

openssl req -new -newkey rsa：2048 -nodes -keyout hostname .key -out hostname .csr

サーバーのキーを再生成するには、生成後に生成されたCSRをプロバイダーのWebインターフェイスにコピーする必要があります。次に、Webインターフェイスから新しい証明書をダウンロードする必要があります。

古いキーと証明書が保持されていたのと同じ場所に新しいキーをインストールする必要があります。証明書とキーに使用する必要のあるパスは、ディストリビューションとWebサーバーの構成方法によって異なります。たとえば、/etc/ssl/certsに保持されるものもあれば、Webサーバーによって提供される場所に保持されるものもあります。

たとえば、Apache Webサーバーを使用している場合は、メインのApache構成ファイル、仮想ホストファイル、またはSSL情報を検索する場所を指す別のソースの構成ファイルに次の行が表示されます。

SSLEngine on
SSLCertificateFile /path/to/your_domain.crt
SSLCertificateKeyFile /path/to/your_key.key
SSLCertificateChainFile /path/to/CA.crt

これらは異なって見えるかもしれませんが、SSL証明書の場所を見つけるための正しい方向を示しているはずです。

Nginxを使用している場合は、サーバーのSSL証明書とキーを指す同様のディレクティブがあります。彼らはこのように見えるかもしれません：

server {
    . . .
    ssl_certificate /path/to/your_domain.crt;
    ssl_certificate_key /path/to/your_key.key;
    . . .
}

もう1つのオプションは、ディストリビューションのドキュメントを確認するか、サーバーのファイルシステムを確認して、証明書が保存されている場所を確認することです。

終了したら、Webサーバーを再起動して新しいキーを使用する必要があります。これを行う方法は、ディストリビューションとサーバーによって異なります。

DebianまたはUbuntuでは、次のように入力してWebサーバーを再起動できます。

sudo service apache2 restart    # For Apache web server
sudo service nginx restart      # For Nginx web server

CentOSまたはFedoraでは、次のように入力して再起動できます。

sudo service httpd restart      # For Apache web server
sudo service nginx restart      # For Nginx web server

Arch Linuxの場合、次のようなものを使用する必要があります。

sudo systemctl restart httpd.service
sudo systemctl restart nginx.service

これにより、Webサーバーが新しい証明書の変更を取得できるようになります。

クライアントの観点からの追加の考慮事項

このバグは広範囲に及ぶため、他にも考慮すべき考慮事項があります。 Webサービスとサイトの利用者として、アカウントと情報への潜在的な損害を最小限に抑えるために、迅速に対応する必要もあります。

以前にSSLで保護した通信は、このバグによって危険にさらされていると見なす必要があります。これは、安全なWebサイトとのあらゆる種類の対話がスヌーピングに対して開かれていることを意味します。

良い最初のステップは、使用するすべてのサイトでパスワードを変更することです。この脆弱性にパッチを適用するためにOpenSSLバージョンが更新されたことを確認した後。リモートサイトがSSLバージョンにパッチを適用する前にパスワードを変更すると、新しいパスワードは古いパスワードと同じように脆弱になります。

重要な考慮事項の1つは、設定したVPNインスタンスを保護することです。 VPN接続を実装する方法はいくつかありますが、SSLは最も人気のある方法の1つです。たとえば、OpenVPNはSSLを使用します。サーバーへの接続に必要な証明書は、セキュリティで保護するために再生成する必要があります。

もう1つの適切な方法は、すべてのセッションキーとCookieを削除することです。これは、APIキーの再生成、ブラウザに保存されているCookieのクリアなどを意味します。これは非常に不便かもしれませんが、アカウントが基本的に広く開かれているため、OpenSSLを更新していないリモートサーバーとの通信は、プレーンテキストよりも安全であると見なされるべきではありません。

結論

これは非常に大きなバグであり、ユーザーや管理者は無視したり延期したりすることはできません。自分が管理しているサーバーをすぐに更新し、脆弱性をユーザーに通知して、ユーザーが自分の側からダメージを管理できるようにする必要があります。

システムにパッチを適用し、SSL証明書を更新することにより、将来の通信のために、ホストとしてこの脆弱性から保護する必要があります。

ジャスティン・エリングウッド

getdocs

13036