根据以下文章，显然可以检查与 Heartbleed 漏洞利用中描述的有效负载匹配的心跳请求日志。
这是否任何服务器操作员都可以在他们自己的日志中检查（在服务器级别，任何标准 Linux 发行版）？如果是这样，应该检查哪些日志，以及检查什么模式？
检查 Heartbleed 漏洞利用的日志？
信息安全
日志记录
服务器
心血来潮
2021-09-06 04:20:56
1个回答
从服务（nginx、Dovecot 等）的访问日志中，您无法看到您是否受到影响。除非您之前捕获了所有 SSL 流量，否则您也无法查看过去是否受到过攻击。
在数据包捕获中匹配的模式非常简单：
- 发送恶意心跳请求。
- 返回过长的 Heartbeat 响应（对于有缺陷的版本）。
如果 Heartbeat 请求未加密（即在握手完成之前发送），则传输层（UDP、TCP 或额外的应用程序特定层）中的数据为：
18 # Content Type Heartbeat
vv vv # TLS version (e.g. 03 01 is TLS 1.0, 03 03 is TLS 1.2)
ll ll # Record length (length of the following data)
01 # Message type (1 = request, 2 = response)
xx xx # Payload length
[payload]
[at least 16 bytes of padding]
如果有效载荷不完全是长度xx xx（大端），那么您可能受到了攻击。如果您收到回复，那就成功了：
18 vv vv # Same record layer header
ll ll # Length of following data
02
xx xx # Same length as requested
[data of length xx xx]
一个示例命令（需要 root）从网络接口捕获所有未来数据，eth0直到中断：
tcpdump -i eth0 'tcp port 443' -w ssl.pcap
您可以使用Wireshark调查该文件ssl.pcap。显示过滤器ssl.heartbeat_message显示所有心跳请求和消息。注意：有时 SSL 过滤器不会被应用。在这种情况下，右键单击一个数据包，单击Decode as..并选择SSL。由于 git commit 3f81af22e0116a2f83c0298de7874959b3967da2（2014 年 4 月 11 日），您还可以使用专家过滤器ssl.heartbeat_message.payload_length.invalid来定位格式错误的心跳请求（如果未加密）。
至于加密的心跳……心跳并不常见，所以当你得到一个用于TCP连接的时候，它已经变得可疑了。加密心跳的一些提示可能会有所帮助：
- 一个心跳请求和巨大的心跳响应是一个易受攻击的服务器被成功利用的标志。
- 心跳请求之后没有心跳响应可能表示试图利用服务器，但服务器已打补丁并且没有响应。
- 带有加密警报的心跳请求可能表示试图利用服务器，但服务器不运行 OpenSSL 并拒绝无效请求。
- 大量后续心跳（即使它很小）可能是有效载荷长度较小的成功利用尝试。