OpenSSL対策まとめ | no news.

OpenSSL対策まとめ

OpenSSLの脆弱性については場当たり的な対応してしまっていたので実は細かいことがよくわかっていません。これはまずいということでまとめることにしました。ちなみにここでは主にnginxでの設定・確認手順を載せています。

Heartbleed

すべての始まり。

OpenSSLの脆弱性「Heartbleed」について(サイバートラスト株式会社)

OpenSSL の heartbeat 拡張に情報漏えいの脆弱性(JVN iPedia)

そうだった、heartbeatの不備でheartbleedになったんだった。

スポンサーリンク
レクタングル大

対策

ハートブリード(Wikipedia)より

基本的な対策はハートビートを使用しない(-DOPENSSL_NO_HEARTBEATS オプションを付けて再コンパイルする)か、脆弱性を修正したバージョン(1.0.1g以降)への更新となる。

その他参考

OpenSSLとHeartbleed脆弱性(Symantec)

修正版の OpenSSL への更新後、基本的なセキュリティ対策(ベストプラクティス)の一環として、「SSL サーバ証明書」の発行元の認証局に連絡して再発行を依頼してください。

OpenSSLの「Heartbleed」脆弱性は2年前から存在、「最悪のケースを想定して対処を」と専門家(@IT)

 辻氏によると、「この脆弱性は、さかのぼると2年前から存在していたことが確認されている。そして、この攻撃では攻撃の痕跡が残らないため、最悪のケース――つまり、秘密鍵の漏えいを想定して対処すべき」。もし、脆弱なバージョンのOpenSSLを運用していたことが判明した場合は、アップグレードや証明書の再発行といった対策を講じた後にその旨を公表し、ユーザーにパスワードの変更などを呼びかけるとなおベターだという。

そうそう、ログに残らないというのも管理者としては嫌でした。証明書の再発行についてはSHA1からSHA2への移行手順を踏めばOK。最後にチェックツールのご紹介。

SSL Labs Server Test

 米クォリスが提供している、SSLに関する総合的なチェックが行えるWebサービスで、HeartBleed脆弱性の有無だけでなく包括的なチェックができる。ただ「1つ注意事項がある。テストした結果がデフォルトで掲載されるため、脆弱だった場合はそのことを公にさらしてしまうことになる」(辻氏)。もし結果を掲載されたくない場合は「『Do not show the results on the boards』にチェックを入れることをお忘れなく!」と同氏はコメントしている。

POODLE

SSL 3.0の脆弱性「POODLE」について知っておくべきこと(ZDNet Japan)

OpenSSL およびその他の製品で使用される SSL プロトコルにおける平文データを取得される脆弱性(JVN iPedia)

ふざけた名前ですね。

対策

SSLv3を無効にする。

apache

設定ファイルのSSLProtocolディレクティブを下記のようにする。

SSLProtocol All -SSLv2 -SSLv3

設定が終わったらapacheの再起動をすれば完了。

nginx

設定ファイルの


ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

こちらも設定が終わったらnginxの再起動をすれば完了。

ブラウザ

ブラウザ側でも対応しないといけないようですが、今はよっぽどアップデートを怠っているPCでない限り対応できているはずなので、書きません。

FREAK

FREAK(wiki)

TLSの前身となったSSLの開発当時には、アメリカからの暗号輸出には厳しい規制が課されており、公開鍵暗号であるRSA暗号については512ビットの鍵長のものしか認められなかった。1990年代当時では、この強度の暗号はアメリカ国家安全保障局(NSA)には解読可能で、その他の組織には解読不能であったが、コンピューターの性能向上、クラウドコンピューティングの一般化により、2015年時点では「50ドル、12時間程度」[1]で解読できる程度に脆弱なものとなっていた。

対策

opensslのバージョンアップ。

OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k.
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p.
OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zd.

webサーバの設定については下記サイトで自動生成したものを使えば良いらしい。→輸出グレードの暗号を使用しないようにする設定

Mozilla SSL Configuration Generator

※ブラウザ側については現段階では最新版にアップデートしておけば大丈夫

番外編

bashも脆弱性がありましたね。こちらも書いておきます。

SHELLSHOCK

GNU bash の脆弱性に関する注意喚起

対策・回避策

III. 対策

** 更新: 2014年10月08日修正 ****************************************
GNU Project から脆弱性を修正したバージョンの GNU bash が公開されてい
ます。十分なテストを実施の上、修正済みバージョンの適用をご検討ください。

修正済みのバージョンは、以下の通りです。

– Bash 4.3 Patch 29
– Bash 4.2 Patch 52
– Bash 4.1 Patch 16
– Bash 4.0 Patch 43
– Bash 3.2 Patch 56
– Bash 3.1 Patch 22
– Bash 3.0 Patch 21

また、一部のディストリビュータからは、修正済みのバージョンが提供され
ています。詳細については、使用中のディストリビュータの情報を参照してく
ださい。

パッチの適用が困難な場合は、以下の回避策の適用を検討してください。

********************************************************************
IV. 回避策

** 更新: 2014年9月30日修正 *****************************************
– GNU bash を代替のシェルに入れ替える
– WAF や IDS を用いて脆弱性のあるサービスへの入力にフィルタをかける
– 継続的なシステム監視を行う

********************************************************************

まとめ

結局最新のopensslに更新してMozilla SSL Configuration Generatorを使って設定ファイル作ってSSL Labs Server TestGeoTrust SSL ToolboxでテストしてOKだったら全て完了なんじゃ。。。

追記

IPAよりSSL/TLS暗号設定ガイドライン~安全なウェブサイトのために(暗号設定対策編)~というドキュメントが公開されました。SSLの基礎知識に始まり、nignxを含むwebサーバの具体的な設定も載っていますのでお勧めです。またチェックリストもあります。

スポンサーリンク
レクタングル大