on
09-Apr-2014
23:19
- edited on
18-Mar-2022
09:56
by
JRahm
Get the latest updates on how F5 mitigates HeartbleedGet the latest updates on how F5 mitigates Heartbleed
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.
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.
Thanks for the quick response iRule 🙂
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"
Any ideas on what may cause this error message?
Thanks!
 
 
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.
 
https://clouddocs.f5.com/api/irules/CLIENTSSL_DATA.html 
 
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.
**I have seen an issue where this rule causes TMM to crash and ticks off SOL6578, collects too much information and could cause the above issue.
The problem happens when something that is not a TLS record appears.
Version 4 is now posted to solve the issue.