The Top Ten Hardcore F5 Security Features in BIG-IP 14.0
Stop! You must be this smart to read this article!
Seriously, dude, put down the wireless trackball and back away from the computer. RIGHT NOW. Because this article is too hardcore for you. Yeah, yeah, you’ve read the previous Top Ten Hardcore Security Feature lists (12, 12.1, 13), and you think you’re clever, but just stahp. You’re not ready for this one.
You are strongly advised to stand down and read the standard version 14.0 release notes instead, like normal people, because this Top Ten Hardcore list for version 14.0 makes all the previous Top Ten lists look like corporate marketing fluff written by a tribble!
What?!? You’re going to continue reading? Well, don’t say I didn’t warn you. I bet you won’t even get past the first two features before you scroll to the end looking for a bad joke.
Number 10 [ ASM ] – Name Your Own WAF Cookies
In days of yore, just after Al Gore invented the Internet, F5 bought a little application security product called “TrafficShield.” That’s a super cool name for a web application firewall, but eventually the F5 marketing drones standardized on “ASM.”
The spirit of TrafficShield lived on in the ASM cookies, which were always named TSCookie. So one could, in theory, fingerprint an F5 web application firewall by looking for the TSCookie. Not that anyone ever did that.
Version 14 lets you create your own cookie naming patterns for the ASM cookie and the Device ID cookie. If you’re worried about fingerprinting, make up your own names (I’m going with NOTanF5Cookie). This feature can also help you conform to in-house cookie conventions.
The maximum cookie size is also increased from 8 KB to 16 KB to accommodate user applications which block 8 KB cookies. I know, you’re thinking, who on God’s green earth uses 9K cookies? It’s called cookie bloat and it’s a thing because people are jamming entire web objects into cookies these days. Who designed this internet anyway? Certainly not Spock.
Number 9 [FPS] – Single Page Application Support
Guys, I have seen the future. The future is the Single Page Application (SPA). Many of the most popular webpages are SPA now, like Twitter, Facebook, and Gmail. In theory, SPA allows the application developers to focus on UX and not on URL management. But SPA relies heavily on duplex technologies like isomorphic React, Websockets and AJAX. That’s the future. Or the present or whatever.
In a Single Page Application, a URL can have multiple views (layouts/content sets), where views change without a full page reload. As you can imagine, the normal tricks that our Fraud Protection Service (FPS) code uses to protect the application need to change. Starting with version 14.0, you can direct the FPS to treat an application as SPA. The DataSafe component of ASM now also supports SPA.
SPA views in FPS can be configured in version with Malware Detection, Automatic Transactions Detection, and Application Level Encryption; and an SPA view can be configured as a login page. You can apply application layer integrity to the whole payload between the client and server with minimal performance loss. With application layer encryption, FPS will have to encrypt the whole payload (instead of just fields), but it stills manages to extract the username for enriching the alerts!
Obviously you can’t enable Integrity and Encryption at the same time, because encryption already includes integrity, duh! Even McCoy knows that!
Did those first two features seem hardcore to you? Well, you’re only half wrong! Those were the teasers. This list is just starting to get hardcore! We showed the next three features to Commander Spock, and his brain exploded.
Speaking of… Here’s a hilarious musical tribute to Spock’s Brain on Spockify. I’ve listened to it like five times while drinking my Saurian brandy and it just keeps getting better.
Number 8 [AFM] – NXDOMAIN Attack Detection – Water Torture, Anyone?
Remember the Mirai botnet? Of course you do, because we write about him, errr, it, all the time, especially in our F5 Labs’ Hunt for IoT Series. That's our depiction of the Mirai bot below. He's like a transformer only he doesn't transform and he infects your internet-connected condiment gun. Mirai has splintered into 50 or more different botnets, and all of them contain the “DNS Water Torture” attack. DNS Water Torture is a specific form of an NXDOMAIN DNS attack, and it’s is one of my personal favorites.
Anyway… a DNS Water Torture attacker sends requests for non-existent subdomains of your domain to different ISP resolvers. Those resolvers then inundate your domain, wiping out your cache and eventually overwhelming your authoritative name server. Goodness, who designed this internet?
Our Advanced Firewall Manager (AFM) module can detect and mitigate these NXDOMAIN attacks in version 14.0. I won’t say how AFM detects them, because that might be a secret (it’s actually machine-learning your subdomains, shhhh). But AFM mitigates by auto-thresholding and rate-limiting queries for subdomains that don't actually exist. Which is pretty much what you’d want, and exactly what you’d expect from our AFM development team whose mantra, lately, is “you don’t want to deal with this stuff, so we’ll just handle it for you.”
Number 7 [APM] – Inline SAML WebSSO
The Access Policy Manager (APM) is how most office plebes know the F5 icon – it’s the most common client application that provides SSL/VPN, SSO and WebSSO for all their company applications. Yeah, the client is cool and all (I’m using it right now), but the real magic happens on the F5 itself of course. In version 14.0, our crack dev team has added nine (!) new features to APM, one for each of Frodo’s fingers.
The most hardcore of these features is the Inline SAML WebSSO feature. SAML WebSSO is one of the most commonly used SAML profiles currently used on the web. In some deployments, the SAML Service Provider is not directly reachable by the users; sometimes because the admin wants to limit direct access to the Service Provider, or because the application can’t be hosted on the Internet.
In those cases, where the service provider is unreachable, you can still provide WebSSO through APM. It works because the F5 APM module impersonates the browser at key moments during the authentication. Here’s what the single application workflow looks like:
Do note that I stole these diagrams from the developer’s actual documentation. They don’t have access to our cool marketing graphics, so they’re apparently using use MS Paint and hand-drawing the shadows behind “Red Man," as I'm going to call him now lol.
After only 12 steps, Red Man has authenticated through APM and received authorization from internal SP. And it supports both single applications and multiple applications if you’re feeling randy. How cool is that? As you might have guessed, the feature is more complicated than I'm letting on, so I recommend you read the actual APM user guide by the fireplace on a quiet night.
Number 6 [APM] – ADFS Proxy as a Simple checkbox
I had a dream last night that St. Peter maintained an Active Directory (AD) cluster for all the souls in Heaven. When I got there, he said, “oh, I’m sorry, David, you’re not in the directory” and then I vanished in a puff of smoke and reappeared in St. Louis. Nooooo!
A common problem for people like St. Peter is that they have an active directory server farm inside their perimeter, but they need to authenticate people on the outside of the perimeter. For this, you could use the Microsoft Active Directory Proxy Server, but why not just use your F5 APM instead? F5 is already sitting in front of your AD server farm, busily load-balancing requests ADFS anyway.
Your F5 APM will give your users single sign-on, and if you have the firewall module, too, it’s the perfect secure setup.
The coolest part is that you can configure the whole thing through one of our new “Guided Configuration” user interface. Just a couple of clicks and a checkbox! Compare that to installing, provisioning, configuring and securing the Microsoft ADFS Proxy.
It makes so much sense. This is a total forehead slapper!!! Slap away!
We have been advised that no one should read beyond this line due to the risks of moderate-to-severe aneurysms. Read on at your peril, because it only gets more hardcore now.
Number 5 [TMOS] – Forced Password Change and Admin Password Policy
As more and more instances of F5 get virtualized into single-nic public cloud environments, we’ve seen a rash of people accidentally exposing their F5 admin interface to the public Internet. Unfortunately, some of these people are also apparently a little lax about changing their passwords from the default; a practice that was vaguely understandable in test environments, but today, those test environments are often in the public cloud.
In BIG-IP 14.0.0, the root and admin default passwords are marked as expired on new installations. After logging in with the default password, you are required to change the password before proceeding. Additionally, the password policy is enabled by default. The new passwords must meet the password policy requirements. Please change all your passwords to ‘admin123’ now. Just kidding, don’t do that. Use a decent password instead. I always use ‘cGFzc3dvcmQ=’.
You can be even more secure by disabling both the root and admin accounts. The root account can be disabled simply by running this command.
The admin account is more difficult to disable: https://support.f5.com/csp/article/K14943
Do note that if you roll-forward a configuration, it will retain your existing credentials (not force you to change), nor will it enforce password policy by default. We felt that too much of the Internet would simply break if we did that without warning. But we might next time.
Number 4 [ TMOS ] - Local Attestation for TPM Chain of Custody
Do you guys remember those confusing days when the United States Tailored Access Operations (TAO) group was accused of intercepting and installing surveillance software on those Cisco routers before they were shipped overseas? Or the Bloomberg Super Micro accusations from, oh, two days ago? People were understandably freaked out by these apocolyptic scenarios and turned to alcohol, mystics, and Trusted Platform Modules (TPM).
A TPM is a hardware module implements security functions to provide the ability to determine a trusted computing environment, allowing for an increased assurance of trust that a device behaves for its intended purpose. TPM Chain of Custody provides assurance that the software loaded on your platform at startup time has the same signature as the software that is loaded by F5 when the system is manufactured.
Platform support
These platforms include a Trusted Platform Module (TPM).
- BIG-IP i2000 Series
- BIG-IP i4000 Series
- BIG-IP i5000 Series
- BIG-IP i7000 Series
- BIG-IP i10000 Series
- BIG-IP i11000 Series
- BIG-IP i15000 Series
- VIPRION B4450 blade
You can check the validity of the F5 TMOS platform software by running the following tmsh command.
You should see a message like this “System Integrity Status: Valid." I have no idea what you’re supposed to do if it doesn’t say Valid. Have a quick drink and speed dial your swami? Oh, I know, open a ticket. And send me your passwords just in case.
If you download and install an update, and you’re happy with it, the -a option will write the new checksums to the TPM.
You can read more about the TPM here.
And FYI, regarding the Super Micro thing. As per our official statement, F5 doesn't use Super Micro; we design our own boards and control the manufacturing tests and processes used by our contract manufacturer. And we take multiple steps to validate and ensure the integrity of all firmware and software loaded on our systems during the manufacturing process. And of course, we have the TPM now!
Alright dear reader, if you’ve gotten this far, your frontal lobes have expanded 8% from all this hardcore technical goodness you’re probably bleeding from your ears. Push your brains back into your ear canals using two pencils and take a deep breath because we’re going to push through to the top three!
Number 3 [SSL Orchestrator] – TLS Forward Proxy Revocation checking
“Revocation is the Achilles heel of PKI.”– Pavel Chekov, first mate, NCC-1701D
If you’re not familiar with the SSL Orchestrator you should be! It’s the perfect tool for decrypting outbound (and now inbound) traffic to send to all your security inspection devices. Your favorite b-list F5 celebrity recorded a lightboard describing how it works and why you need it.
Version 14 adds forward certificate revocation checking to the SSL Orchestrator. Suppose Red Man is at the agricultural office and he visits a website whose certificate had been revoked. Prior to version 14, Red man would be unaware of the revocation and would blithely click around and possibly expose his credentials. But now, the SSL Orchestrator can do an OCSP check and then terminate the session on revocation, protecting young Red Man (and you).
Seems simple, right? Actually, to make this work we basically made the “ServerSSL” TLS profile work the same as the much more powerful ClientSSL profile. So now ServerSSL can do OCSP and CRLDP certificate checks, the latter of which is meaningless in the forward proxy case but quite powerful in the inbound federal or enterprise space.
66% of popular Internet sites (according my developer’s documentation) offer some kind of revocation checking. Now the SSL Orchestrator can take advantage of these revocation checks so that Red Man can be protected from malicious man-in-the-middle devices (as opposed to benevolent man-in-the-middle like the SSL Orchestrator).
Number 2 [ LTM ] – Ultra-secure ECDSA keys in HSM
Nothing says serious like a FIPS 140-2 hardware security module (HSM). A good one will keep your keys secret, your beers cold and costs more than my first three cars. Guess who wrote the first F5 + FIPS implementation? Yours truly, back in 2002! “Shut up, David, you say that every top ten list!”
Back then, sonny, we didn’t have these new-fangled elliptic curve digital signature algorithm (ECDSA) keys that all the millennials are using now, and even if we did we couldn’t put them into an HSM, because HSMs only supported RSA keys, like God intended.
ECDSA keys and certificates are becoming more popular across the Internet. ECDSA usage grows a few percent each quarter, with some periodic larger jumps when a CDN adopts it.
With version 14.0, F5 supports ECDSA keys in our own Cavium N3FIPS HSM cards. Version 14 also supports ECDSA keys in external Net-HSMs like Thales and nCipher.
I, myself, grudgingly switched over to ECDSA keys last year, finally giving up my RSA and DSA keys, which I sold at a garage sale for 0.000006 bitcoin.
Are you ready for the Number One Most Hardcore Security Feature in version 14.0? This one is cooler than the other side of the pillow!
Number One [ LTM ] – Support for Curve25519 (X25519).
Of course the most hardcore feature is going to be about cryptography. Put succinctly, Curve25519 is the fastest, coolest and soon-to-be most popular elliptic curve used in transport layer security (TLS). It was discovered by Internet super-god, Daniel J. Bernstein, and released to the public domain unencumbered by patents. You can go look at the source code for it on his site, cr.yp.to. Here’s the link: https://cr.yp.to/ecdh.html
If you’re splitting hairs, Curve25519 describes the actual elliptic curve, and X25519 describes it as a Diffie-Hellman function, where it is used in the client-server TLS handshake.
And if you’re wondering where the digits 25519 come from, it’s actually 2255-19, which, as everyone knows is a prime number, duh. Bernstein claims X25519 is provably secure (doesn’t rely on magic numbers) so is free from nation-state meddling. By design, it’s immune to timing attacks (beware, famous last words).
X25519 is recommended by the IETF TLS committee, and most recently, NIST publicly stated that they are behind it, too. X25519 has 40% lower computational complexity than the standard curve, P-256 so virtual machines should prefer it to P-256. The lower complexity also means that it will be easier on low-CPU devices like the billions found in the Internet of Things (IOT).
X25519 is one of three ‘DH-Groups’ in the Cipher Group configuration screen (the others are the standard NIST curves P-256 and P-384). Because it’s newer, we’ve prioritized X25519 last in the preference list, so unless a client requests it specifically, they won't get it. But you could move it to front of the preference list by using the cool new cipher rules that I introduced in the Top Ten List for version 13.
# Create a Cipher rule that moves X25519 to the front
ltm cipher rule Curvy {
description "X25519
priority first"
dh-groups X25519:P256:P384
}
# Create a Cipher Group that uses it.
ltm cipher group CurvyGroup
{ allow { Curvy { } } }
# Insert it into your clientssl profile
ltm profile client-ssl x25519 {
...
cipher-group CurvyGroup ciphers none
...
}
And then, to test it, get a distro with OpenSSL 1.1.0h or better, and when you run the s_client command you’ll see the X25519 function in the Server Temp Key field of the output.
--- No client certificate CA names sent Peer signing digest: SHA256 Server Temp Key: X25519, 253 bits ---
You’re welcome! But don’t actually use that config above – it’s just an example. You’d want to make sure your cipher group includes all the other common ciphers, too.
Because X25519 is so awesome, it’s already supported by most major browsers, TLS vendors, clouds and CDNs.
Spoiler: TLS 1.3 will rely heavily on X25519. If you’re wondering where TLS 1.3 support was in this Top Ten List, just wait a little longer and keep monitoring DevCentral.
As Spock would say, “dang, that was a gnarly list, bro, so hardcore.” Let’s recap this Top Ten in short list form:
| Top Ten | Module | Hardcore Security Feature |
|---|---|---|
| 10 | ASM / FPS | Name Your Own WAF Cookies |
| 9 | Single Page Application support | |
| 8 | AFM | NXDOMAIN Attack Detection |
| 7 | APM | Inline SAML WebSSO |
| 6 | ADFS Proxy as a simple Checkbox | |
| 5 | TMOS | Forced Password Change |
| 4 | TPM Chain of Custody | |
| 3 | LTM / SSL | TLS Forward Proxy Revocation Checking |
| 2 | Ultra-Secure ECDSA Keys in HSMs | |
| 1 | TLS support for Curve25519 |
Honestly (honestly, guys) of all the Top Ten lists I’ve done, this one was the most hardcore. The most technically arcane. The least marketing-friendly. But that’s what makes it the best, and the most satisfying! Because DevCentral is where the technology (see the list) meets the people (that’s you).
I’ve been running version 14 for all of two days now and I already love it more than bathing. If you're curious what else is in version 14, check out the full list of Version 14 Release Notes.
Enjoy your BIG-IP version 14.0, and boldly upgrade where no man has gone before!
Stay tuned for the next edition of the Top Ten, and follow me on Twitter but not in real life please, I have run out of restraining order forms. Until next time!
