This iRule will find any heartbeat request from a client and close the connection immediately. We believe this is an effective mitigation because we have not seen any clients that send a valid heartbeat request, even if they do advertise heartbeat support.
Most of the malicious clients we've seen don't bother to do a full TLS handshake; they start the handshake, then send the malicious heartbeat request. This iRule works even if someone writes a malicious client that negotiates the full SSL handshake then sends an encrypted heartbeat reqest.
##############################################
# Name: heatbleed.c rejector irule.
# Description: This irule is a tweak to https://devcentral.f5.com/s/articles/ssl-heartbleed-irule-update
# Purpose: to block heartbleed requests.
# - added check for 768 and 769 ( SSLv3 and TLSv1 )
# - Ensure r is a positive value. This only happens when there is no valid SSL record.
# VERSION: 4 - 16.apr.14
##############################################
when CLIENT_ACCEPTED {
TCP::collect
set s 0
set r 0
}
when CLIENT_DATA {
set c [TCP::payload length]
set i 0
while { $i < $c } {
set b [expr {$c - $i}]
if { $s } {
# skipping payload
if { $b >= $r } {
set s 0
set i [expr {$i + $r}]
} else {
set r [expr {$r - $b}]
set i [expr {$i + $b}]
}
} else {
# parsing TLS record header
if { $b < 5 } {
break
}
binary scan [TCP::payload] @${i}cSS t v r
set r [expr {$r & 0xFFFF}]
set i [expr {$i + 5}]
if { $t == 24 }{
switch -- $v {
"768" -
"769" -
"770" -
"771" -
"772" {
log local0. "Detected Heartbeat Request from [IP::remote_addr]. REJECTING!"
reject
}
}
}
set s 1
}
}
TCP::release $i
TCP::collect
}
If you have clients that do issue valid heartbeat requests,we have a server side iRule that will only pass valid short heartbeat responses at the cost of a small performance penalty.
that's the next version after 1.2, perhaps there are some TLS 1.3 draft implementations out there? Previous version of the iRule had 769-711 accounted for. I'll inquire.
For a client heartbeat request, the plaintext SSL record header will have a length in bytes. This is very small for both a malicious client and a benign client.
In the case of the early attacks, the heartbeat request payload is in plaintext, so the iRule could see that it's malicious.
However, this iRule as written will stop a malicious HB request even after the SSL handshake is completed and the SSL record payload is encrypted.
If you want a little bit more fine grained control and only stop heartbeat responses that have server data, click the link at the bottom of the story to see a server side iRule that stops the server responses if they are too large.
I've tested this rule on a vs which does terminate SSL, to provide visibility of attackers scanning for the vulnerability. It mostly seems to work well; but I've seen a couple of the following log messages:
- missing count for "@" field specifier while executing "binary scan [TCP::payload] @${i}cSS t v r"
If you already have an SSL profile, I suspect that it would be more efficient to use either CLIENTSSL_DATA or SERVERSSL_DATA events to find the heartbeats.
As for the @${i} warning, we haven't seen it despite having passed hundreds of gigabytes of traffic from curl. It is likely non-TLS traffic, or possibly an aborted client.
For customers looking to simply alert on scan attempts once backend servers are patched, comment out the "reject" line and of course, change the text of the log statement.
