Use TLS Fingerprinting as a First Level of Defense in F5 Distributed Cloud
Hi Folks! In this article I will review how F5’s Distributed Cloud (XC) allows you to use TLS fingerprinting as a first level of defense against malicious actors trying to overwhelm your servers.
What is TLS fingerprinting?
TLS fingerprinting is...
- ...a method of identifying devices based on their unique TLS fingerprint often used for security purposes to help identify potential threats and prevent attacks. By analysing the TLS fingerprint, security professionals can determine the version of TLS being used, the specific cipher suites supported, and other configuration details.
- ...a method of extracting certain parameters from a TLS client request (ClientHello) packet and then assigning a unique identifier to the device/browser.
I have purposefully mentioned that TLS fingerprinting is a “first line of defense” and you will see why further as we dig deeper.
So folks, lets get started...
First we would need a webserver, one client ( curl or browser ) and one reverse proxy (XC) in between to fingerprint our clients.
I have already set this up using Juiceshop as webserver and XC as WAAP proxy.
Now, lets access our webserver and check out our fingerprint. This is a simple request and nothing is malicious.
Here we have accessed the website/app from a standard browser ( Mozilla )
We login into the XC dashboard and look for the request logs ( not security logs as nothing malicious has happened yet )
So my Firefox was fingerprinted and value is 579ccef312d18482fc42e2b822ca2430
Now since we are going to repeat step a lot of times, i have configured the XC platform to include the fingerprint value in the response headers by invoking a predefined variable. (This is just me flexing the granular capabilities in XC platform 😛 )
Let’s see if this works, we should be able to see this in developer tools
Looks good, i can see the fingerprint value being added as oppart of response headers
Now one question you may ask yourself is does TLS fingerprint happen at OS level or at client software( browsers, curl etc ) level ?
Let’s find out by running a curl command from the same machine.
Nice, as we can see we have different fingerprint value, hence we are able to granular identify curl accessing the website vs browser accessing the website from the same Machine/Device/OS
We can go a step further and try to see if we can block curl and allow browser requests from the same device ( look at curl as simple BOT vs Mozilla as human user )
So, let’s block the curl fingerprint.
A very simple service policy can help us achieve that.
Let’s fire a request now from CURL
Yup, we are blocked!
However, the browser still works
Now if you have ever been in a wartime situation and find yourself defensing against adversaries who are DDoS’ing your website you will know, that they love to rotate their IP address for many reasons ( to bypass IP based rate limits or to hide their actual IP address )
Now, let’s use the power of TOR networks to try and see if we can change our IP address by hiding behind a malicious proxy network and access the website.
We will use Torghost for this, Welcome to Kansas city!
Let’s try and access our website now.
Still blocked,
Looking at the logs shows, that even if we rotate our IP address the TLS Fingerprint is still able to identify malicious actors and block them.
This means we have potentially made it very difficult for an attacker to DDOS us.
Overall, TLS fingerprinting is an important tool for network security professionals, as it allows them to identify potential threats and take appropriate action. By understanding the basics of TLS fingerprinting, organisations can better protect their networks and ensure the security of their data.
However…
Security is never a silver bullet and attackers keep on evolving. So let’s deep dive for educational purposed how a skilled attacker may evade this technology and also how to protect your infra/apps against such attackers
Let’s begin by looking at our client hello packet, we will run Wireshark and filter out everything else but just the DST IP and Hello Packet by using
ip.addr == X.X.X.X and ssl.handshake.type == 1
Request fired !
As you can the request failed ( due to service policy configured in above step), however we are able to see client hello packet in client side.
Let’s focus on Cipher Suites, Curl ver. 7.88.1 defaults to 91 cipher suits!
If you remember we talked about how the fingerprinting method uses CLIENT HELLO packets to do its fingerprinting.
What will happen if we change our supported CIPHERS methods thereby also changing our client hello packets ???
So out of the supported list, we will pick one randomly and ask curl to only use the cipher (ECDHE-RSA-AES128-GCM-SHA256)
As we see, the fingerprint has changed. Let’s look at Wireshark
Only 5 Ciphers advertised.
Now, we can imagine how a sophisticated attacker can craft new client hello payloads to try and evade the fingerprinting but its going to take some mighty efforts, but he will have to do this for every request he wants to fire!
This means a lot of efforts specially if he wants to DDOS.
Such sophisticated BOTs can be handled using https://www.f5.com/cloud/products/bot-defense.
The details of how we use behavioural biometrics to identify such malicious users and defense against them are out of scope of this article. However you can refer below links