Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner
Jeff_Costlow_10
Historic F5 Account

Get the latest updates on how F5 mitigates HeartbleedGet the latest updates on how F5 mitigates Heartbleed

For those of you tuning in to learn more about the OpenSSL Heartbleed vulnerability, here are more details about it and how F5 customers are protected. The iRule below mitigates the Heartbleed vulnerability for virtual servers that do not use SSL termination.
 

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.

Comments
matth_58967
Nimbostratus
Nimbostratus
Why "772" (03 04)? To which version of TLS/SSL does it refer?
JRahm
Community Manager
Community Manager
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.
JRahm
Community Manager
Community Manager
That's for TLS 1.3. Just future-proofing there!
Craig_C_
Nimbostratus
Nimbostratus
Wouldn't the most ideal solution check for the payload size and the declared payload size?
Jeff_Costlow_10
Historic F5 Account
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.
Sam_Pickles_110
Nimbostratus
Nimbostratus
Hi Jeff;

 

 

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!
Jeff_Costlow_10
Historic F5 Account
Hi Sam.

 

 

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.
BAMcHenry
F5 Employee
F5 Employee
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.
Matt_Slosser
Nimbostratus
Nimbostratus
"TCL error: /Common/hb_Rule: CLIENT_DATA> - missing count for "@" field specifier while executing "binary scan [TCP::payload] @${i}cSS t v r"

 

**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.
Jeff_Costlow_10
Historic F5 Account
Thanks.

 

The problem happens when something that is not a TLS record appears.

 

Version 4 is now posted to solve the issue.
Matt_Slosser
Nimbostratus
Nimbostratus
Problem seems fixed. Good update
Version history
Last update:
‎18-Mar-2022 09:56
Updated by: