网站运营商应如何处理Heartbleed OpenSSL漏洞？

 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.

#1 楼

对于每个受影响的服务器，要考虑的不仅仅是新的证书（或更确切地说，是新的密钥对）。这也意味着：


将受影响的系统修补到OpenSSL 1.0.1g
撤销刚刚被取代的旧密钥对
更改所有密码
使所有无效会话密钥和cookie
评估可能已泄漏的易受攻击的服务器处理的实际内容，并做出相应的反应。
评估可能已泄露的任何其他信息，例如内存地址和安全措施

Neel Mehta（首先报告此错误的Google安全工程师）发了一条推文：


堆分配模式使#heartbleed #dontpanic不太可能公开私钥。 >

Tomas Rzepka（可能来自瑞典安全公司Certezza）回答了恢复密钥所要做的事情：


我们可以成功地提取私钥。
重新启动apache并使用ssltest.py发出第一个请求后，FreeBSD也已通过CloudFl进行了演示。是挑战。

Twitter用户makomk赞叹道：二进制文件，但是您的演示更加清晰...成功率很低，
在同一连接上进行更多尝试无济于事，重新连接可能会
重新启动可能不会...体面的堆利用技术可能会提高可靠性。我不是真的很努力。




我总结了heartbleed.com（重点是我）的上述要点：


什么是泄漏的主密钥材料以及如何恢复？

这些是皇冠上的珠宝，是加密密钥本身。泄漏的
秘密密钥使攻击者可以解密到受保护服务的过去和将来的流量
，并随意模拟该服务。任何
可以绕过X.509
证书中的加密和签名所提供的保护。要从此漏洞中恢复，需要修补漏洞，撤消被破坏的密钥以及重新发行和重新分发新密钥。即使这样做，仍会
使攻击者过去拦截的任何流量仍然容易受到解密。所有这些都必须由
服务的所有者完成。

什么是泄露的辅助密钥材料以及如何恢复？

例如，这些用户易受攻击的服务中使用的凭据（用户名和
密码）。要从此泄漏中恢复
，首先需要服务的所有者根据上述步骤恢复对服务的信任
。之后，用户可以根据受到损害的服务所有者的
说明开始
更改密码和可能的加密密钥。所有会话密钥和会话cookie均应无效，并且被认为受到损害。

什么是泄露的受保护内容以及如何恢复？

这是由...处理的实际内容。脆弱的服务。它可能是个人或财务详细信息，私人通信（例如，电子邮件或即时消息，文档）或任何值得保护的内容（通过加密保护）。只有服务的所有者才能
估计泄漏的可能性，并应相应地通知
其用户。最重要的是如上所述恢复对主密钥和辅助密钥材料的信任。只有这
才能在将来安全地使用受到破坏的服务。在泄漏的内存内容中暴露给
攻击者。这些可能包含技术性
详细信息（例如内存地址）和安全措施（例如用于防止溢出攻击的金丝雀）。这些仅具有
现代价值，并且在OpenSSL升级到固定版本后将对攻击者失去其价值。

#2 楼

直接从OpenSSL站点直接复制

OpenSSL安全通报[2014年4月7日]

TLS心跳读取溢出（CVE-2014-0160）

缺少可以使用TLS心跳扩展的边界检查
向连接的客户端或服务器显示最多64k的内存。

仅1.0.1和1.0.2-beta版本的OpenSSL受到影响，包括
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（通过从源代码进行编译，并使用FPM将其包装）。替换您公开的证书并吊销它们。

（dr.jimbob的补充）值得指出的是，OpenSSH不受OpenSSL错误的影响。尽管OpenSSH确实将openssl用于某些密钥生成功能，但并未使用TLS协议（尤其是令人发泄攻击的TLS心跳扩展）。因此，不必担心SSH会受到威胁，尽管将openssl更新为1.0.1g或1.0.2-beta2还是个好主意（但您不必担心替换SSH密钥对）。 >

（OrangeDog）：@drjimbob，除非您的SSH密钥位于使用OpenSSL TLS的进程的内存中。



（Deer Hunter的补充）：从DMZ中报告的活动尝试来看，现在最好的办法就是尽快停止FRIKKIN服务器。会话被劫持，密码泄露，机密业务数据被泄露。
（额外感谢EFF.org）：“要对Heartbleed的历史得出更坚定的结论，最好是网络社区尝试复制Koeman的发现。任何拥有大量TLS层流量日志的网络运营商都可以检查恶意心跳，最常见的是TCP负载为18 03 02 00 03 01 40 00或18 03 01 00 03 01 40 00，尽管末尾的0x4000可以用较小的数字代替，特别是在尝试读取多个malloc块容器的实现中。”简而言之，如果您保留详细的TLS日志（对于大多数操作员而言不太可能），请检查过去的利用尝试（并分享您所拥有的内容）。


相关在ServerFault上进行问答：

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

https://serverfault.com/questions/587348/best -method-to-update-ubuntu-13-10-to-path-the-heartbleed-bug

https://serverfault.com/questions/587324/heartbleed-how-to-relially- and-portably-check-the-openssl-version

AskUbuntu上写得很好的摘要：https://askubuntu.com/a/444905

全面的问答在Unix＆Linux SE上：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/wh at-versions-os-x-受心脏出血影响

使用心脏出血获取私有SSL密钥：http://blog.cloudflare.com/answering-the-critical-question -您能否使用令人心碎的私人ssl键
是的，有可能！

#3 楼

[编辑]

我制作了一个工具来检查您SSL的状态，并查看心跳是否已启用且容易受到攻击。
该工具位于：http://rehmann.co/projects/heartbeat/

http://filippo.io/Heartbleed/

中还有一个您容易受到攻击，请升级您的OpenSSL软件包并更新证书！

#4 楼

请注意，如果您使用的是基于云的提供商或内容分发网络，并且它们容易受到攻击，则网站泄漏的内容将与使用此提供商的所有其他网站的内容混合在一起。我刚刚通过Incapsula看到了这一点，其中银行网站的内容沿着加密货币网站泄露了。现在已经修复了。

#5 楼

Jspenguin编写了一个脱机工具来检查服务器是否存在缺陷。下载它，对其进行审核，然后运行它。 x通常是整个系统使用的openssl）。这可以帮助您确定是否在客户端受到影响。

Nmap 6.45包含一个ssl-heartbleed脚本。 ssl-heartbleed.nse也可以与nmap≥6.25一起使用。