※当ブログではアフィリエイト広告を利用しています。
OpenSSLの脆弱性に起因するHeartbleed問題についてAWSではかなり早い対応が行われていますが、4/10 0:00現在AWS Elastic Beanstalkをシングルインスタンスで使用している場合、OpenSSLをアップデートしても最新の脆弱性対応版のパッチが適用されないことがあるようです。
状況と暫定対応方法をまとめたのでメモします。
Heartbleed Bugの概要
OpenSSLの脆弱性により、SSLで通信している相手のメモリを閲覧できるかなり致命的なバグのようです。
参考: CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ
Heartbleed Bugの影響を受けるかのチェック方法
以下のサイトでサーバーのホスト名を入力して、自分のサイトがHeartbleed Bugの影響を受けるかがチェック可能です。
http://filippo.io/Heartbleed/
ちなみに脆弱性がある場合、以下のように表示されます。（自身が所有するサイトで確認）
AWS各サービスのHeartbleed Bug対応状況
4/10 0:00現在、以下のサービスではHeartbleed Bugの対応が完了しているか、手動でパッチ適用することで対応が可能です。
- Elastic Load Balancing
- Amazon EC2
- AWS OpsWorks
参考:AWSからOpenSSLの脆弱性について AWS のサービスアップデート
AWS Elastic BeanstalkのHeartbleed Bug対応状況
AWS Elastic Beanstalkではシングルインスタンス環境でOpenSSLを使用している場合、Elastic Beanstalkに紐づけられているEC2インスタンスにてOpenSSLのアップデートを行ってもOpenSSLの脆弱性対応版のパッチが降ってこないことがあります。AWS側でも対応中のようです。
AWS Elastic Beanstalk: シングルインスタンス環境でElastic Beanstalkをご利用されているお客様について、対策を完了させるために取り組んでいます(訳注: なお、シングルインスタンス環境ではなくElastic Load Balancingをご利用の際は、ロードバランサー側で対処がなされています)。
AWS Elastic Beanstalkで対応版パッチが降ってこなかった状況
以下の手順でAmazon Linux AMI 2013.09の環境に手動でOpenSSLのアップデートを行いましたが、脆弱性対応版のアップデートパッケージであるopenssl-1.0.1e-37.66.amzn1ではなく、openssl-1.0.1e-37.64.amzn1が適用されました。
/etc/yum.confのreleasever=2013.09をreleasever=latestに変更sudo yum clean allでリポジトリを掃除sudo yum update opensslでOpenSSLをアップデート- httpdを再起動
参考:EC2インスタンスのOpenSSLのHartbleed Bug対応
上記対応後、脆弱性チェックサイトでチェックしても脆弱性は「有り」のままでした。
Elastic Beanstalkに紐づけられているEC2インスタンスをTerminateしてみても、その後自動的に立ち上がってくるインスタンスが参照しているAMIが脆弱性対応パッチ未適用のままのため解決しません。
暫定対応方法
該当のElastic BeanstalkアプリケーションでLaunch New Environmentにて完全に新規の環境を作成すれば脆弱性対応パッチ適用済みのAMIを使用してEC2インスタンスが立ち上がるため暫定対応が可能です。
アプリケーションについては新規Environment作成時、既存のバージョンのいずれかを選択することができます。ただしRDSインスタンスを紐づけている場合、既存のRDSインスタンスは新しいEnvironmentに紐づけできません。
そのため既存のRDSインスタンスのスナップショットを作成した後、新規Environment作成時にRDSインスタンスをスナップショットから作成する必要があります。
環境作成後にダウンタイムなしで環境を入れ替える方法は以下の公式ドキュメントが参考になります。
参考:Deploying Versions with Zero Downtime
新規EnvironmentでHeartbleed Bug脆弱性対応パッチが当たっていることの確認
完全に新規の環境を立ち上げてElastic Beanstalkに紐づけられたEC2のOpenSSLバージョンを調べたところ、バージョンは1.0.1eですが2014/04/07にビルドされたものになっていました。
[ec2-user@ip-XXX-XX-XX-XXX ~]$ openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Apr 7 23:39:44 UTC 2014 platform: linux-x86_64
以下は念のためElastic Beanstalkではなく、EC2のサービス単体で最新のAmazon Linux AMI 2014.03を使用してインスタンスを立ち上げてOpenSSLのバージョンをチェックしてみたログです。
ビルド日時が上記と同じなので、Elastic Beanstalkも新規環境を立ち上げれば脆弱性対応パッチ適用済みのEC2インスタンスが立ち上がるとみて良さそうです。
[ec2-user@ip-YYY-YY-YY-YYY ~]$ openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Apr 7 23:37:42 UTC 2014 platform: linux-x86_64
上記の状態で再度チェックサイトで確認したところ、脆弱性が修正されたことを確認できました。
おわりに
AWS Elastic Beanstalkでは単体サービスのEC2とパッケージアップデートの結果が異なったためかなりハマりました。新規環境を作る対応方法だとRDSのデータコピーが若干面倒です。
AWS側で対応中とのことなので、正式な対応方法発表があったら追記します。
2014.04.11 0:00追記
Security Bulletinsは更新されておらず、サポートフォーラムでAWSの中の人も新規Environmentを立ち上げる方法を案内しているので、この対応で良さそうです。
