Vulnerabilities from SWEET32 in F5 Load Balancers Reveal

How to Mitigate Vulnerabilities from SWEET32 in

F5 Load Balancers

The SWEET32 vulnerability is targeting long lived SSL sessions using Triple DES in CBC mode. The attack targets the cipher itself and thus there is and will be no hotfix for this. The only way to mitigate is to either disable the 3DES-CBC ciphers or set a limit on the renegotiation size.

This guide will cover how to configure both in the load balancer, and also how to protect your management interface (only possible by changing the cipher string).

For the official F5 article, please refer to this link: https://support.f5.com/csp/#/article/K13167034

Configuring an SSL Renegotiation size limit

SSL renegotiation options determines if the BigIP will allow the client to make mid-stream reconnections or not. The option called size limit will set a limit, in megabytes, of how much data that is allowed to pass through the connection before an SSL renegotiation will be disabled (on that specific connection). Since the attack targets long lived sessions (or rather high amount of SSL data) this will mitigate the attack. F5 recommends to set the limit to 1000MB.

Possible impact of setting a renegotiation size limit

Clients with renegotiation support will need to be able to handle a failed SSL Renegotiation and instead establish a new one completing the full SSL handshake. This should not pose a problem in the vast majority of applications.

SSL session settings are regulated by SSL profiles. While you can change the parent profiles we do not recommend doing so without doing proper testing.

Procedure to set an SSL Renegotiation size limit via the GUI

  1. Log in to the F5 administration interface
  1. Navigate to Local Traffic -> Profiles -> SSL -> Client
  1. Click on the profile you wish to set the limit to
  1. In the settings, locate Renegotiation size
  1. If it’s disabled (see the picture below), click on the custom option checkbox to allow changes

  1. Change the value from Indefinite to Specify, then enter 1000

  1. Click on “Update”

Procedure to set an SSL Renegotiation size limit via TMSH

  1. Connect to your load balancer via an SSH client
  1. If not already in the tmsh, enter it
  1. To modify the size limit of a profile, issue this command and replace the profile name with the full path of the ssl profile you wish to modify:

modify /ltm profile client-ssl <profile_name> renegotiate-size 1000

Example:

modify /ltm profile client-ssl /Common/example.com renegotiate-size 1000

  1. Commit the configuration to disk by running the command “save sys config

Disabling 3DES-CBC ciphers in SSL Client profiles and the management interface

This method will remove the affected ciphers from the list of applicable ciphers during SSL connection negotiations. SSL cipher settings are regulated by SSL profiles. While you can change the parent profiles we do not recommend doing so without doing proper testing.

 

Possible impact of disabling 3DES-CBC ciphers

While most modern browsers supports wide array of ciphers this will still reduce the cipher support of the virtual servers using the modified SSL profile. Depending on your current cipher string this could or could not pose a risk to clients and the virtual servers not being able to agree on a cipher.

Please note that the following guide is just meant to show how to disable these specific ciphers and uses the system default cipher list to do so. Using the default list is not recommended. To determine which cipher list you should use, please read up on ciphers.

 

This guide is a really good start:

https://f5.com/Portals/1/Premium/Architectures/RA-SSL-Everywhere-deployment-guide.pdf

Procedure to set an SSL cipher string via the GUI

  1. Log in to the F5 administration interface
  1. Navigate to Local Traffic -> Profiles -> SSL -> Client
  1. Click on the profile you wish to alter the cipher string on
  1. In the settings, locate Ciphers
  1. If it’s disabled (see the picture below), click on the custom option checkbox to allow changes.

  1. Change the value from the current value to <CURRENTLIST>: !DHE-RSA-DES-CBC3-

SHA:!DES-CBC3-SHA:!ECDHE-RSA-DES-CBC3-SHA

  1. Click on “Update”

Procedure to set an SSL cipher string via TMSH

 

  1. Connect to your load balancer via an SSH client
  1. If not already in the tmsh, enter it
  1. Show the current cipher string with the following command:

list /ltm profile client-ssl [profile name] ciphers

Example:

list ltm profile client-ssl /Common/example.com ciphers

ltm profile client-ssl Testpartition/testthemciphers { ciphers DEFAULT

}

  1. Note your current cipher string. In the example above it was “DEFAULT”
  1. Modify the cipher string with the following command:

modify ltm profile client-ssl [profile name] ciphers <CURRENTLIST>:!DHE-RSA-DES-CBC3-SHA:!DES-CBC3-SHA:!ECDHE-RSA-DES-CBC3-SHA

Example:

modify ltm profile client-ssl /Common/example.com ciphers DEFAULT:!DHE-RSA-DES-CBC3-SHA:!DES-CBC3-SHA:!ECDHE-RSA-DES-CBC3-SHA

  1. Commit the configuration to disk by running the command “save sys config

Thank you to Patrik Jonsson for contributing this article.

How to Reset Device Trust – F5 LTM Load Balancing Methods Troubleshooting ConfigSync and Device Clustering

indeni, cisco

F5 LTM Load Balancing Methods: How to Reset Device Trust.

The official F5 SOL13946 provides information on troubleshooting device clustering and configuration sync for 11v  F5 load balancers  and other products, however it is rather long winded.  This guide is designed as a quick reference when troubleshooting device clustering or config sync. An overview of the config sync process for version 9.x and 10.x units can be found in F5 SOL7024

Version 11.x

  • Communication between machines occurs in the following manner to form a device cluster:
    mcpd process on the local machine connects to the tmm process on the local machine on port 6699
  • tmm process then contacts the peer’s config sync IP on port 4353
  • Once the peer receives, they use tmm to contact mcpd over port 6699 on their local device.
  • If this process fails, it is re-attempted every 5 seconds.
  • If this process succeeds, there is a mesh between peer mcpd processes.

* local machine here refers to the self IP configured for config sync. Check it under Device Management > Devices > click on device > Device Connectivity > Config Sync, for example.

Continue reading

F5 bigd process down

This is a real life sample alert from indeni

Description:

The F5 bigd process is down and has not restarted. Among its responsibilities, bigd runs the monitors for nodes, pool members and services. For more information, read SOL6967.

Manual Remediation Steps:

Review the logs to identify why the bigd process is down. indeni will attempt to determine the source of the issue automatically as well.

How does this alert work?

indeni tracks the status of all of the critical operating-system level processes and alerts if any of them crashes or shuts down unexpectedly.

F5 IPSec Tunnel Causing Traffic Issues

This is a real life sample alert from indeni for F5 Load Balancing Methods

Description:

Some of the F5 IPsec tunnels have multiple security associations negotiated for them. This may result in traffic issues.

Affected Tunnels:

Tunnel to 165.160.15.20

Manual Remediation Steps:

Review SOL14646.

How does this alert work?

indeni uses the various “show /net ipsec” commands to track the IPsec tunnels.

Check Point and F5© BIG-IP© LTM© Alert of the Week: RX traffic drastically reduced post fail over, possible ARP issue

ALERT concept. Business technology internet and networking concept - ALERT text on virtual screens

 

 

NOTE: The alert detailed below is given with a Check Point ClusterXL example, although F5 BIG-IP LTM is covered for this issue as well (see SOL7332).

This is a real life sample alert from indeni

Description:

A fail over was identified at Device time: Jul 18 03:02 2014 UTC, indeni time: Jul 18 03:02 2014 UTC. This device is now the active member of the cluster and in the period immediately following the fail over (3 minutes more or less) it received 0 packets compared to 104462 packets that were received by jcnj-fw2 (10.10.10.2) in a similar amount of time immediately BEFORE the fail over. This indicates the possibility that the surrounding network equipment may not be aware of the fail over on the layer 2 level.

Manual Remediation Steps:

It is possible this is caused by the fact that during a fail over the responsibility for the virtual IPs moves from one cluster member to the other and the MAC addresses change. ClusterXL issues gratuitous arps to deal with this but it may not work with your equipment. Please review SK50840 for more information.

How does this alert work?

indeni monitors the traffic passing through all members of an HA cluster. If it sees that post a failover the newly active member isn’t seeing remotely similar levels of traffic as the pre-failover active member did, the alert is triggered.

Interested in learning more? Download for free the official indeni guide to Preemptive Maintenance of Check Point Firewalls. Just fill out the form below:

[ninja_form id=5]