According to articles such as the following, it's apparently possible to check logs for heartbeat requests matching the payloads described in the Heartbleed exploit.

Is this something that any server operator can check for in their own logs (at the server level, any standard Linux distribution)? If so, which logs should be checked, and for what pattern?


From the access logs of a service (nginx, Dovecot, etc.), you cannot see whether you were affected or not. Unless you have previously captured all SSL traffic, you cannot see whether you got attacked in the past either.

The pattern to match in a packet capture is very simple:

  1. A malicious Heartbeat request is sent.
  2. An overly long Heartbeat response is returned (for buggy versions).

If the Heartbeat request is not encrypted (i.e. it got sent before the handshake is completed), then the data in the transport layer (UDP, TCP or an extra application-specific layer) is:

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
[at least 16 bytes of padding]

If the payload is not exactly the length xx xx (big-endian), then you were possibly attacked. It would be successful if you get a response back:

18 vv vv    # Same record layer header
ll ll       # Length of following data
xx xx       # Same length as requested
[data of length xx xx]

An example command (which requires root) that captures all future data from network interface eth0 until interrupted:

tcpdump -i eth0 'tcp port 443' -w ssl.pcap

You can use Wireshark to investigate the file ssl.pcap. The display filter ssl.heartbeat_message shows all Heartbeats requests and messages. Note: sometimes the SSL filter does not get applied. In that case, right-click a packet, click Decode as.. and select SSL. Since git commit 3f81af22e0116a2f83c0298de7874959b3967da2 (11 April 2014), you can also use the expert filter ssl.heartbeat_message.payload_length.invalid to target malformed Heartbeat requests (if unencrypted).

As for encrypted heartbeats... it is not common to see heartbeats, so when you got one for TCP connections, it already becomes suspicious. Some hints for encrypted heartbeats that may help:

  • A heartbeat request followed by gigantic heartbeat responses is a sign of a vulnerable server that was successfully exploited.
  • A heartbeat request not followed by a heartbeat response may signal an attempt to exploit the server, but the server is patched and does not respond.
  • A heartbeat request followed by an encrypted Alert may signal an attempt to exploit the server, but the server does not run OpenSSL and rejects the invalid request.
  • A large number of subsequent heartbeats (even if it is small) may be successful exploitation attempts with small payload lengths.
  • Why is there an assumption that TLS encryption == TCP? DTLS is essentially why we have heartbeats to begin with. – JZeolla Apr 15 '14 at 17:21
  • @SteelCityHacker Yes I am aware of that, that is why I explicitly say "TCP connections" instead of "TLS connections". Note that if you have DTLS traffic in your network, then you need the dtls prefix instead of ssl for Wireshark. – Lekensteyn Apr 15 '14 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.