どこまでもSE

世の中の様々な事象をSE / PG視点で見ていきます。徹底的に偏見ブログ。

3分で理解して3分で対応完了する OpenSSLの脆弱性問題(Heartbleed) 解説

存在がセキュリティホール、ishidoです。

数日前から問題になっているOpenSSLの脆弱性問題の事象私なりにまとめました。
既に微に入り細を穿ちなまとめは多くの人がやってくれているので、こまけぇこたぁいいんだよ な人向けです。
 
さくっと分かるように、ロシアのクリミア問題への関心くらいで理解できる程度にまとめてあります。
どれくらいかの関心が必要かというと
「なんか最近クリミアってよく聞くなー 知ってるといいことあるのかなー (チラッ) あーわかんねからもういいや」
このくらいの関心レベルです。w
 

事象概要

1.何が起きたのか

OpenSSLに重大な脆弱性が見つかりました。
セキュリティの専門家でも「10年に一度の危険なバグ」と言うほどの問題です。
 

2.何のバグなのか

OpenSSLのHeartbeatの実装上に見つかったバグです。
Heartbleed(心臓からの出血)と称されています。
 

3.それによって何が起きるのか

SSLを処理しているプロセスのメモリ内容を取得することが出来ます。
ロードバランサで処理していればロードバランサの、
Apacheで処理していればApacheのメモリ内容を抜き取られることになります。
抜き取りは64Kbyteずつ、何度でも行うことが出来るため、
メモリ内の全ての内容を抜き取ることが可能です。
 

4.それによって何のリスクがあるのか

メモリ内には暗号化されていない情報が乗っていることがあります
メモリ内に乗っている情報に限られますが、
セッション情報が抜き取られれば成りすましが出来ます。
ユーザID、Password、クレジットカード情報などの個人情報が乗っていれば
それらを悪用されます。
DBの接続情報が乗っている場合もあります。
また、SSL秘密鍵が乗っていた場合は、全ての暗号化情報を盗み見ることが出来ます。
 
以上が概要です。
 
 
以下に対策方法をまとめました。
 

まずは対策が必要かどうか確認

 
0.OpenSSL 1.0.1~1.0.1fを使用しているかチェック
  →使用していなければ問題なし。終わり。

0が当てはまってしまった場合の対応方法

1.OpenSSLのアップデート
yum update 程度のアバウトさでOK
 
2.OpenSSLを使用しているサービスの個別再起動
もしくは、サーバの再起動で一発OK
 
3.SSL証明書の再発行(念のため)
使用しているCAによって方法が違うため、各CAのページから「失効・再発行」などで探す。
大体ウェブ上で申請が出来るようです。
参考URLの2.のリンクにもCAへのリンクがあります。
 
 
いじょーでーす。

参考URL

ここまでで更に深く知りたくなったという方は、天才まとめ師達の仕事から学んでください。

1.対策まとめ

http://d.hatena.ne.jp/nekoruri/20140408/heartbleed

2.事象まとめ

(ページ末にSSL証明書の再発行方法のリンクあり)
 

3.1.AWSでの対策を実際にやった方の行動

3.2. AWSインスタンス再起動方法

 

4.## HeartBleed(OpenSSL脆弱性)テストサイト ##

”All good, www.xxxxx.co.jp(ここは自サイトドメイン) seems not affected!"
と出ればOK
ただし、デフォルトでは検査結果が公開されてしまうため、
"Do not show the results on the boards"のチェックをオフにすることを忘れずに
 

おしまい

結構な大ごとなのに、こんなに軽く書いてしまってどこかから怒られそうな気はしている。しかし反省はしていない。w
この記事が誰かの理解の一助になりますように!
 
それでは、皆さん、ぷわぷわーおー。