Heartbleed OpenSSLエクスプロイトについて、ウェブサイト運営者は何をすべきですか？
これは、Heartbeatエクスプロイトの処理に関する正規の質問であるはずです。
OpenSSLを使用するApache Webサーバーと、OpenSSLに依存する他のいくつかのユーティリティ（クライアントとして）を実行しています。リスクを軽減するにはどうすればよいですか？
- バグを分析
- サイトが脆弱かどうかを確認してください （たとえば、Duckduckgo.comは脆弱です！）
I looked at some of the data dumps
from vulnerable sites,
and it was ... bad.
I saw emails, passwords, password hints.
SSL keys and session cookies.
Important servers
brimming with visitor IPs.
Attack ships on fire off
the shoulder of Orion,
c-beams glittering in the dark
near the Tannhäuser Gate.
I should probably patch OpenSSL.
クレジット： [〜＃〜] xkcd [〜＃〜] 。
影響を受けるすべてのサーバーには、新しい証明書（または、新しいキーペア）だけではなく、考慮すべき詳細があります。それはまた意味します：
- 影響を受けるシステムにOpenSSL 1.0.1gをパッチする
- 置き換えられたばかりの古い鍵ペアの取り消し
- すべてのパスワードを変更する
- すべてのセッションキーとCookieを無効にする
- 漏洩した可能性のある脆弱なサーバーによって処理された実際のコンテンツを評価し、それに応じて対応します。
- メモリアドレスやセキュリティ対策など、明らかにされた可能性のあるその他の情報を評価する
Neel Mehta（Googleセキュリティエンジニア 最初の報告 バグ） ツイートされた ：
ヒープ割り当てパターンにより、＃heartbleed #dontpanicで秘密鍵が公開される可能性は低くなります。
Tomas Rzepka（おそらくスウェーデンのセキュリティ会社 Certezza ） 返信 がキーを回復するために何をしなければならなかったか：
Apacheを再起動し、ssltest.pyで最初のリクエストを行った後、FreeBSDで秘密鍵を正常に抽出できます。
秘密キーの盗難は CloudFlare Challenge でも実証されています。
そしてTwitterユーザー makomkwith でチャイムされました：
GentooのApacheからバイナリのベアプライムファクターとしてそれを回復しましたが、あなたのデモははるかに明確です...それは成功率が低く、同じ接続での再試行が役に立たない、再接続するかもしれません、再起動する可能性がありますまあ...まともなヒープ活用スキルを持つ誰かがおそらく信頼性を向上させるでしょう。私はそんなに一生懸命頑張っていません。
上記の箇条書きのポイントを heartbleed.com （私の強調）からまとめました：
リークされた主キーマテリアルとは何ですか？どのように回復しますか？
これらは王冠の宝石、暗号化キー自体です。漏洩した秘密鍵により、攻撃者は保護されたサービスへの過去および将来のトラフィックを解読し、自由にサービスを偽装することができます。暗号化とX.509証明書の署名によって提供される保護はバイパスできます。このリークからの回復には、脆弱性へのパッチ適用、侵害されたキーの取り消し、および新しいキーの再発行と再配布が必要です。これらすべてを実行しても、過去に攻撃者によって傍受されたトラフィックは依然として復号化に対して脆弱です。これはすべて、サービスの所有者が行う必要があります。
漏洩した二次鍵の資料とは何ですか？どのように回復しますか？
これらは、脆弱なサービスで使用されるユーザー資格情報（ユーザー名とパスワード）などです。このリークから回復するには、最初にサービスの所有者が上記の手順に従ってサービスへの信頼を復元する必要があります。この後、ユーザーは、侵害されたサービスの所有者からの指示に従って、パスワードと可能な暗号化キーの変更を開始できます。すべてのセッションキーとセッションCookieを無効にし、侵害されたと見なす必要があります。
漏洩した保護されたコンテンツとは何ですか？どのように回復しますか？
これは脆弱なサービスによって処理される実際のコンテンツです。個人的または財務上の詳細、電子メールやインスタントメッセージなどのプライベートコミュニケーション、ドキュメント、または暗号化によって保護する価値があると思われるものなどです。リークされた可能性を推定できるのはサービスの所有者のみであり、それに応じてユーザーに通知する必要があります。最も重要なことは、前述のように、プライマリおよびセカンダリキーマテリアルへの信頼を復元することです。これだけが、侵害されたサービスを将来的に安全に使用できるようにします。
漏洩した担保とは何ですか？どのように回復しますか？
漏えいした担保は、漏えいしたメモリコンテンツで攻撃者に公開された他の詳細です。これらには、メモリアドレスなどの技術的な詳細や、オーバーフロー攻撃から保護するために使用されるカナリアなどのセキュリティ対策が含まれる場合があります。これらは現代的な価値しかなく、OpenSSLが修正バージョンにアップグレードされると、攻撃者にとってその価値は失われます。
OpenSSLサイト から直接コピー
OpenSSLセキュリティアドバイザリ[2014年4月7日]
TLSハートビート読み取りオーバーラン（CVE-2014-0160）
TLSハートビート拡張の処理における境界チェックの欠落は、接続されたクライアントまたはサーバーに最大64kのメモリを明らかにするために使用できます。
OpenSSLの1.0.1および1.0.2-betaリリースのみが影響を受け、1.0.1fおよび1.0.2-beta1が含まれます。
このバグを発見してくれたGoogle SecurityのNeel Mehtaと、修正の準備をしてくれたAdam LangleyとBodo Moellerに感謝します。
影響を受けるユーザーは、OpenSSL 1.0.1gにアップグレードする必要があります。すぐにアップグレードできないユーザーは、代わりに-DOPENSSL_NO_HEARTBEATSを使用してOpenSSLを再コンパイルできます。
1.0.2は1.0.2-beta2で修正される予定です。
上記のバージョンのOpenSSLを使用しているかどうかを確認します。使用している場合は、パッチを1.0.1gにパッチします（ source からコンパイルして、パッケージを [〜＃〜] fpm [でラップします。 〜＃〜] ）。
（atkによる追加）その後、公開された証明書を置き換えて、取り消します。
（dr.jimbobによる追加）OpenSSHはOpenSSLのバグの影響を受けないことを指摘する価値があります。OpenSSHはいくつかのキー生成関数にopensslを使用しますが、TLSプロトコル（および特にハートブリード攻撃を行うTLSハートビート拡張）を使用しません。したがって、opensslを1.0.1gまたは1.0.2-beta2に更新することをお勧めしますが、SSHが危険にさらされることを心配する必要はありません（ただし、SSHキーペアの交換を心配する必要はありません）。
- （OrangeDog）：SSHキーがOpenSSLのTLSを使用しているプロセスのメモリにある場合を除き、@ drjimbob。可能性は低いですが可能です。
（ディアハンターによる追加）： [〜＃〜] dmz [〜＃〜] で報告されているアクティブな試行によって判断すると、今のところ最良のことは FRIKKIN SERVER ASAP。セッションが乗っ取られ、パスワードが漏洩し、機密のビジネスデータが明らかになりました。
（余分なビット EFF.orgの礼儀 ）： "Heartbleedの歴史についてより確かな結論に到達するには、ネットワーキングコミュニティがKoemanの調査結果を再現することを試みるのが最善です。広範なTLSを持つネットワークオペレーター-layerトラフィックログは、TCPペイロード
18 03 02 00 03 01 40 00または18 03 01 00 03 01 40 00、ただし0x4000末尾の数字は、特に複数のmallocチャンクビンを読み取ろうとする実装では、より小さな数字に置き換えられる可能性があります。 "簡単に言えば、詳細なTLSログを保持している場合（そこにいる大多数のオペレーターにはありそうもない）、過去のチェック搾取の試み（そしてあなたが持っているものを共有する）。
ServerFaultでの関連するQ＆A：
https://serverfault.com/questions/587338/does-heartbleed-affect-aws-elastic-load-balancer
https://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it
AskUbuntuでのよく書かれた要約： https://askubuntu.com/a/444905
Unix＆Linux SEでの包括的なQ＆A： https://unix.stackexchange.com/questions/123711/how-do-i-recover-from-the-heartbleed-bug-in-openssl
万が一Mac OS Xでサーバーを実行している場合： https://Apple.stackexchange.com/questions/126916/what-versions-of-os-x-are-affected-by-heartbleed =
ハートブリードを使用してプライベートSSLキーを取得する： http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed はい、それが可能だ！
[編集]
SSLのステータスを確認し、ハートビートが有効で脆弱かどうかを確認するツールを作成しました。ツール： http://rehmann.co/projects/heartbeat/
http://filippo.io/Heartbleed/ にはもう1つあります。
脆弱な場合は、OpenSSLパッケージをアップグレードして証明書を更新してください！
Jspenguinは anofflinetool と書き、サーバーに欠陥があるかどうかを確認しました。それをダウンロードして監査し、実行します。
私は ssl-heartbleed-check.pl （オフラインツールでもあります）を書いて、Perlスタック（* n * xでは多くの場合、システム全体で使用されるopenssl）で使用されているOpenSSLを確認しました影響を受けた。これは、クライアント側で影響を受けているかどうかを判断するのに役立ちます。
Nmap 6.45にはssl-heartbleed 脚本。 ssl-heartbleed.nse も使用できます nmap≥6.25と一緒に使用 。
クラウドベースのプロバイダーまたはコンテンツ配信ネットワークを使用していて、それらが脆弱である場合、Webサイトの漏洩コンテンツは、このプロバイダーを使用する他のすべてのWebサイトのコンテンツと混合されることに注意してください。私はちょうど Incapsulaでそれを見ただけです です。そこでは、銀行のWebサイトのコンテンツが暗号通貨のWebサイトに沿ってリークされました。幸い、現在は修正されています。