AWS環境のPOODLE脆弱性対応 (CVE-2014-3566)

AWS
こんにちは、三井田です。

米国時間の10/14、SSLv3のPOODLE問題というセキュリティ脆弱性(CVE-2014-3566)について 詳細がアナウンスされました。

参考リンク；

AWSでもそれに併せて、セキュリティアドバイザリを発行しています。

この記事では、以下の参考情報をもとに、この脆弱性に対する対処を簡単に案内したいと思います。

POODLEアタックとは

OpenSSLのドキュメントによると、POODLEとは"Padding Oracle On Downgraded Legacy Encryption"の略とのことです。

暗号化された通信内のCookie情報などが、plaintextとして参照される恐れがあるとのことです。

影響範囲

脆弱性がシステムに与える影響ですが、

今回の脆弱性は、旧来使用されていたSSLv3に存在する仕様上の問題です。
影響範囲についていくつか気に留めておく必要があることを記載します。

  • 今回の脆弱性は、サーバ側だけではなく、SSLv3を使用するクライアント側（ブラウザやHTTPS通信をつかうアプリケーションなど）にも影響があります
  • SSLv3をもとに標準化され、後方互換性をもつTLSv1.0では影響はありません
  • TLSv1.1以降では影響はありません

対策

AWSのセキュリティアドバイザリによると、AWSのサービスとしては、Elasitc Load Balancing (ELB)と、CloudFrontを利用の場合に対応が必要なケースがあるようです。

その他、EC2上で、ApacheやNginx、PostfixなどでSSLを利用している場合にも対応が必要なケースがあると考えます。

端的にいうと、以下のいずれかの対策が必要です。この記事では、前者を紹介したいと思います。

  • SSLv3を使用しないよう設定する
  • 「TLS_FALLBACK_SCSV」により、旧バージョンのSSLを使用する試み (downgrade) を阻む

EC2での対策

2014/10/15 14:05 JST 現在、AWSのセキュリティアドバイザリによると、本件の影響を確認しパッチなどの準備を行っている模様です。近々アップデートがある模様ですので、Amazon Linux AMI Security Centerをこまめにチェックしましょう。

現時点では、こちらのスレッドHow do I patch/workaround SSLv3 POODLE vulnerability (CVE­-2014­-3566)?に、クライアント側、サーバ側それぞれでの対策がよくまとまっていましたので、サーバ側に絞って紹介します。
（詳細は、リンク先を参照ください）

Apache HTTPDサーバ

SSLの設定ファイル（RHEL系のOSでmod_sslをインストールした素の状態だと一般的に、/etc/httpd/conf.d/ssl.conf）で、SSLProtocolの設定を以下のようにし、httpdをリスタートします。 

SSLProtocol All -SSLv2 -SSLv3

sudo service httpd restart

Nginxサーバ

設定ファイルで、SSLを使用せずTLSだけを使用するよう設定します。

ssl_protocols: TLSv1 TLSv1.1 TLSv1.2;

sudo service nginx restart

Postfixサーバ

Apache HTTPDサーバと同様に、SSLv3を使用しないよう設定します。

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

sudo postfix restart

Windows Server

追記 2014/10/15 15:50 JST
Windows関連の情報を匿名さんから頂いたので追記しました。

Windowsプラットフォームについては、Microsoft社がMicrosoft Security Advisory 3009008を公開しました。

IISなどでWebサーバを公開している場合は、同様にSSLv3を無効化します。設定方法は、公式ナレッジベースのインターネット インフォメーション サービスで PCT 1.0、SSL 2.0、SSL 3.0、または TLS 1.0 を無効にする方法や、IIS で SSL 3.0 を無効にする方法が参考になります。

Elasitic Load Balancing (ELB)での対策

こちらは、AWSのセキュリティアドバイザリをもとに、実際にAWSマネジメントコンソールでの設定を紹介します。

端的には、SSLv3をネゴーシエーションオプションから外したCypherの設定「ELBSecurityPolicy-2014-10」が用意されたので、そちらを利用するようにします。

新規起動のELB

HTTPSなどSSLを利用するListner設定で、自動的に「ELBSecurityPolicy-2014-10」が利用されます。

既存のELBの設定変更

  1. AWSマネジメントコンソールを開き、ELBの画面に移動します。（コンソール -> EC2 -> Load Balancer と選択）
  2. ELBを選択し、Listnerタブを開きます
  3. 該当のポートの「Cypher」列の「Change」をクリックします
    ELB_Listner
  4. ドロップダウンより「ELBSecurityPolicy-2014-10」を選択して「Save」します
    Cypher_change

CloudFrontでの対策

AWSのセキュリティアドバイザリによると、独自SSLを使用しているディストリビューションの場合、影響があるとのことです。

独自SSLを使用していない場合は、影響は無い模様です。

ディストリビューションの設定で、「Only Clients that Support Server Name Indication (SNI)」を選択することで影響を回避できます。

しかしながら、上記は「SNI 独自 SSL」方式を採用する手順と認識しており、「専用IP 独自SSL」の場合の対処については情報収集中です。

まとめ

以上、簡単ですが、現時点で判明している影響範囲と対処法について紹介しました。AWSのセキュリティアドバイザリや各Linuxディストリビューション、Webブラウザのベンダなどの情報にご留意頂ければと思います。

参考リンク：