I was in Las Vegas a couple of months ago and happened to be walking out of a casino just as five fancy tour buses pulled up. All five bus doors opened simultaneously, and out poured 200 Miss Universe contestants in shimmering gowns, high heels, sashes emblazoned with their country names, and winning smiles. There goes Miss Colombia! There goes Miss Philippines! The informal parade was such a spectacle that I failed to see if the pageant’s owner, one Donald J. Trump, was in the retinue. Trump has been known to be a judge on the pageant panel as well as its owner, and I'm sure he has a difficult time choosing the best from among so many winning candidates.

The Donald

I feel Trump’s pain.

Because F5 is again releasing a new version of BIG-IP, it falls to me, David Holmes, the Donald Trump of F5 Marketing, to choose among hundreds of beautiful security doodads and select from them The Top Ten Hardcore Security Features. This task gets harder every six months because BIG-IP’s features get ever more hardcore.

Version 12.1 of BIG-IP is heavy with additions to the web application firewall, ASM, the network firewall, AFM, and a couple of hardy entries from that upstart new girl, WebSafe. Are you ready for this beautiful security pageant?

Let’s get started!

Number 10: [AFM] Port Misuse detection and prevention

You know what gets misused these days? The “service dog” certificate. I’ve seen so many yippy Chihuahuas and Lhasa apsos on airplanes ever since they relaxed the policy about what constitutes a service animal. I know one woman who brings her labradoodle for emotional support because she can’t vape sativa while in the air. Really, lady, really?

Bad service dog!You know what also gets misused? Ports 53 and 80. Since these ports are always open both ways, people start using them for all kinds of mischief, rather than the fine DNS and HTTP protocols that God gave us.

Ever found someone creating SSH tunnels through port 80? Ha ha, I have. Actually, those were my tunnels; and okay, I promise to stop this time. Please don’t take away my network privileges. Again.

Now you can use AFM to put an end to this mischief. You can specify expected protocol per intended application destination port and detect mismatches, while also logging (or dropping) requests. Policy can be applied with granularity per-(dest) port for incoming TCP, SCTP, and UDP protocols.  Allowable actions for detected misuse include:

  • Count the event
  • Log and count the event
  • Drop and count the event
  • Drop, log and count the event

The port misuse policy is associated with either a context or an AFM Rule. Logging is available, and the AVR does report visually on the number of port-misuse events, broken down by context, drill-down by port number. 

Now if only they’d do something about those service dogs! But that’s not a problem AFM is ready to solve. Maybe by version 13.1.

Number 9: [AFM] Remote Trigger Black Hole (RTBH)

AFM has been enhanced to support source-based RTBH to stop push-back denial of service attacks. This is basically like “Talk to the Hand” for malicious source addresses.

AFM has always been able to automatically detect and block network denial of service (DoS) attacks, but with 12.1, AFM can now push the blocking up to the ISP to prevent the attacks from even entering the network. AFM does this by advertising a BGP routing message into the network to instruct selected upstream edge routers to drop the suspicious traffic. 

Blacklist publisher

The RTBH feature uses AFM’s “shun” Blacklist Category address lists so admins can manually or automatically blacklist naughty source IP addresses. In the example above, a clever administrator has created profiles for different Scanners, which will be then be prevented from even reaching the site. Take that, scanners!

Number 8: [AFM] Auto-thresholds for global DDoS vectors

I’ve been telling people everywhere that AFM is the only firewall that was born from DDoS attacks (Operation Avenge Assange, to be exact). So of course it has the coolest protections against malicious network packets. My favorite protection was always AFM’s ability to detect floods and then mitigate them temporarily and automatically. Have a sudden spike in RST packets? AFM would categorize it and then start dropping them like they were hot. But one thing was missing: exactly how many packets constituted a flood? We had set some arbitrary numbers (10,000), but they were the same limits for all packet types for all customers.

Auto threshold DDoS profile

Now AFM has been enhanced to allow admins to set auto-configure for DDoS Thresholds for AFM’s Global DoS vectors. Once you have configured auto-threshold, AFM will start calculating new auto-thresholds every five minutes and use them as a baseline against which spikes are measured. Traffic history will persist across a reboot providing the last seven days of data from the persistent file. The threshold data will of course be transmitted through to any high-availability peers. 

Number 7: [AFM] SSH Proxy controls

Since before germs, you’ve been able to set up virtual servers on BIG-IP to forward your SSH connection to a server. But it was a dumb virtual server that just forwarded packets willy-nilly. In version 12.1, out of nowhere, AFM has become SSH-aware. You can now define SSH proxies in AFM to start enforcing some security around your SSH servers.

SSH Proxy permissions

You can specify that the SSH channel commands restrict user actions, which means you can define a security policy around SSH at the BIG-IP. In the screenshot above, you, the security administrator, have decided that those UX guys are cool and all, but hell, no, they aren’t allowed to SCP stuff off the box. Because, data loss prevention.

You could also be less restrictive but have BIG-IP send you logging events so you can spy be aware about what your SSH users are doing. The SSH proxy can also be configured to allow only specific versions of SSH (e.g., disallow SSH v1).

Now that F5 is full proxy for SSH, you can expect to see more and more intelligence built into AFM for port 22. 

To read more about AFM's new features in version 12.1, check out the AFM release notes.

Whew, four features for AFM. You’re already freaking out about how hardcore these features are, and we haven’t even cracked the top five yet. Take a chill pill to calm down and read on, because we’re not letting up.

WebSafe, the anti-fraud mastermind of BIG-IP, has been improved significantly for version 12.1. Two of its hardcore features are making the Top Ten for the first time.

Number 6: [WebSafe] User-Defined Alerts

I don’t need to tell you that the security landscape is ever-changing, because that’s a trope you hear from vendors all day long. Even though the phrase is wildly overused, that doesn’t mean it’s not true. The fluid nature of fraud is what drives the new User-Defined Alerts (UDA) feature of WebSafe.

Suppose a new class of Dyre, Dridex, Zeus, or SpyEye malware comes out and it’s just different enough to evade existing software signatures. After learning a little about its new attack pattern, you can configure WebSafe to search for your own custom signatures within requests. As WebSafe matches your signatures, it sends the specific alert that you also defined.

From WebSafe’s Anti-Fraud interface you can build a signature to scan HTTP headers, payloads, query strings, or client IP addresses. You can define multiple searches for the same request, and the overall number of searches is unlimited.

Version 12.1 shows that WebSafe is continuing to change just like that ever-changing security landscape. Whoops, I said it again!

Number 5: [WebSafe] Score-based Remediation

WebSafe’s primary strength is to quantify user behavior with behavioral scoring. Now you can put that scoring to use in three new ways:

  • Define a remediation policy.
  • Temporarily send the suspicious requests to an alternate pool.
  • Forward the scoring data directly to your risk engine (via HTTP POST).

WebSafe User-Defined Alerts

The scoring data takes the form of a rule, which is defined as event=score (action). For example, you could make a rule where 2=50 (redirect), which means redirect connections on web injection alerts with a score of 50 or more.

Here’s a handy table of events.




Client-Side (browser) events

Generic Malware


Malware recognized on client.

Web Inject


HTML has been modified in transit.

Phishing URL


Phishing detection.

Phishing User


Phishing detection.



Remote Access Trojan detected.

Mandatory Words


Required words missing in page.

Client Network Connection


Access to predefined domains blocked.

Client-side Missing Components


Missing components detected in JavaScript

Source Integrity


Source integrity violation.

WebSafe events

Referrer Checks


Referrer check failed.

Server-side Missing Components


Missing components detected in plugin.

Encryption Failure


Cryptographic failure.

Automated Transactions


Automated transactions detected.




Any other Alert

Each of these events can generate an alert, and the destination of that alert varies depending on where it was detected. Alerts that are generated on client side by JavaScript will be sent to BIG-IP. BIG-IP will forward it to BIG-IQ, and after processing on BIG-IQ a response will be sent to BIG-IP containing the event number and score. Alerts that are generated by WebSafe itself (on the BIG-IP) will be sent to the BIQ-IQ Dashboard, but no response is required from BIG-IQ in order to take an action. 


There are four possible actions to take for each rule:

  1. Post to Web service. WebSafe will send by default a post request to a web service (your risk engine) with the following data: username, IP address, event type, and score score. The default payload looks like the highlighted text above.
  2. Route. WebSafe will route next requests to a specified pool for a specific time.
  3. Redirect. WebSafe will redirect the next request (once) to a specified URL.

Many admins will use the “Post to Web service” action to send the data directly to a risk engine and let the risk engine decide what to do. But in a pinch (or if you don’t have a risk engine), you can have BIG-IP and WebSafe reroute or redirect suspicious connections.

Thank you, Ms. WebSafe. 

Now, everyone, put your hands together for F5’s Web Application Firewall, ASM. As a layer-7 anti-hacking control, ASM is about as hardcore as anything gets—so it should be no surprise that ASM has four entries in version 12.1’s Top Ten list. Are you ready for the last four? Take a long breath, say Namaste, and give a little bow to center yourself.

Number 4: [ASM] Proactive Bot defense iRule support

The previous version of ASM added the recognition of Good Bots and Bad Bots. Good Bots are beneficial robots like search engines. Bad Bots are, well, naughty computers doing naughty things. Speaking of that, here’s a salutatory link to The Lemonheads and Kate Moss covering Arling and Cameron's “Dirty Robot”!

Anyway, version 12.1 makes bot defense useful by integrating new iRule primitives to allow you to act on Bad Bot detection. 

So what can you do with these new iRule primitives? Here are some ideas:

  1. Replace the user's rude TCP reset with a redirect to a honeypot (Mwahaha!).
  2. Send a high-speed logging message upon block and challenge actions.
  3. Filter Bot defense based on headers or URLs.
  4. Force a JavaScript challenge (and cookie) on certain URLs.
  5. Force a CAPTCHA challenge or replace the white-page challenge with a CAPTCHA challenge.

There’s a whole new category of iRule events to trigger off of, but the primary ones will be BOTDEFENSE_REQUEST and BOTDEFENSE_ACTION. These take the place of HTTP_REQUEST and HTTP_RESPONSE.

Here’s a simple example of what a BOTDEFENSE_REQUEST event might look like in an iRule.

# EXAMPLE 1: Allow client-side challenges for tenaciousD URLs
    if {[HTTP::uri] eq "/tenaciousD/a.php"} {
        BOTDEFENSE::cs_allowed true

Here’s another example where an admin is allowing a connection to pass through on a specific URL pattern even though Bot Defense thinks something weird is going on. I wouldn’t recommend doing this, but it gives you an idea of how you can tweak things.

# EXAMPLE 2: Bypassing enforcement for tenaciousD URLs
    if {[HTTP::uri] starts_with "/tenaciousD/"} {
        log local0. "bypassing enforcement for URI [HTTP::uri]"
        set res [BOTDEFENSE::action allow]
        log local0. "set action to allow, result \"$res\""
        log local0. "resulting action [BOTDEFENSE::action] reason \"[BOTDEFENSE::reason]\""


The full list of new BOTDEFENSE iRule commands can be found on the DevCentral Wiki.

Number 3: [ASM] JSON/AJAX brute force login protection

Remember the old days when HTTP basic authentication was all the rage? Okay, neither do I, but the old timers say it only took a week for people to realize that HTTP Authentication was vulnerable to passive sniffing attacks. HTTP 1.1 tried to fix the sniffing problem by using hashes, but it ended up being vulnerable to replay attacks and no one used it, either. And the popups were super annoying. So we all switched to login forms in HTML itself.

One of the problems of login form pages is that attackers can guess their passwords, and when they use automation, they can try thousands of guesses per second and “brute force” their way through all the possible (or likely) password combinations such as password, password1 and monkey (why is monkey always in the top ten most common passwords?).

Anyway, ASM has had brute force protection for login pages since before Kanye and Beyoncé became Jayoncé. Jayoncé have evolved since then, and so has the Internet. 

Modern Web application frameworks like Angular JS use AJAX authentication, in which the login form is submitted as an AJAX POST request with the login details and response in JSON format. The important difference is not the format (JSON instead of HTML), but rather the fact that the response is consumed by the JavaScript code running on the browser and includes logical data rather than HTML presentation data (e.g., captions like the "logout" next to the logout button).

In version 12.1, ASM adds support for AJAX login pages both for manual configuration and automatic discovery. ASM also enriches the logout pages with metadata that can indicate whether it is login or logout for cases in which the same URL is used for both.

AJAX Login Page properties

You can define each AJAX login page from ASM. But who wants to go trawling through server-side code looking for login pages? I certainly don’t. Let ASM learn all the pages for you and then provide automatic brute force protection.

This leaves you more time to catch up on your reading or your DVR queue. Maybe you can re-watch the Miss Universe pageant. Did you know it was originally called the Miss Pulchritude Pageant? That sounds nasty, but according to dictionary.com, pulchritude means “beauty.”

Number 2: [ASM] REST API security

Protecting AJAX and JSON login pages is cool, but what’s even cooler is protecting the REST APIs underneath. The second Most Hardcore Security Feature in 12.1 is the ability to enforce a policy of specific HTTP methods against specific REST API URLs. You can define, in a granular way, how each method will be used for specific URLs in your REST API.

Why would you want this? Suppose your REST API allows all the normal HTTP methods including the ones with possible server-side effects PUT, DELETE, MERGE and MODIFY. And most of the time, the API does the right thing when someone tries to MODIFY a REST API that shouldn’t be modified. But every now and then the developer misses something, and a MODIFY could slip through and mess everything up.

With version 12.1 you can now enforce which HTTP methods can be used on which URLs. Any HTTP methods that are not specified for the URL will generate an illegal-use violation. You can even define your own custom HTTP methods, just in case you have a super-customized AJAX client.

File types and Violations

If you have ASM in policy-building mode, where it is learning new URLs, there’s now a setting that retains the HTTP method policies when new URLs are discovered. You can tell the policy builder to apply the HTTP method policy to new URLs from the “Policy Building -> Learning and Blocking Settings” page.

The circular twist to this feature is that you can use F5’s REST API to set the security policy that enforces your REST API security.

Mind blown.

Okay, we’re ready for number one.

Let’s bring Steve Harvey out to announce the winner! And the winner is….

Miss Colombia!

No, wait! There's been a mistake!

The number one Hardcore Security Feature of version 12.1 is actually:

Number 1: [ASM] WebSocket protection

This is my favorite new feature in ASM! Security for WebSockets. WebSockets are a relatively new addition to Web applications: they provide an open bi-directional full-duplex channel between the client and the server. Unlike half-duplex, client-server HTTP, in WebSockets either the client or the server or both can send streaming data to each other indefinitely at any time. The WebSocket Protocol is specified in RFC 6455, and you can play with WebSockets using a demo at websockets.org:

JavaScript WebSockets demo

You’ve almost certainly used WebSockets without even knowing about it. Ever had an online chat session in a customer-support window? That was probably WebSockets. Or have you ever opened a stock-ticker window and just watched as it went up and up, increasing your wealth beyond all dreams of avarice (okay, that never happened to me either, but I do watch stocks from time to time). That was probably WebSockets as well.

Version 12.1 adds WebSocket security to ASM. There are so many different protections ASM adds for WebSockets that I was considering making a WebSocket ticker window showing all the mitigations, but I got lazy and just made this table instead. Actually, I just copied this table from the functional specification and removed most of the profanity.


Threat Prevented


Handshake protocol correctness

Server stack abuse.

Enforce well-formed, mandatory headers in requests.

Cross-origin access

Session riding/ CSRF

Deny access from origins not in the configured whitelist.

Login enforcement

Information leakage

Enforce login session for WS/WSS URLs.

Attack signature detection

XSS, SQLi and
command shell injection

Find attack signatures in each textual WS message. Close the WebSocket with a Close message.

Illegal encoding

Stack exploit

Enforce UTF-8, check for illegal meta characters & null

Enforce message masking

Cache poisoning

Enforce message masking for client textual messages.

Enforce message size and framing

Buffer overflow

Limit message size, frame size and enforce correctness of framing

Enforce JSON
message format

Stack exploit
Buffer overflow

Apply JSON content profile per WS message with all possible defenses including signatures and meta-characters.

Slow send/receive

Exhaust server socket

Limit the time for sending a message and time between messages.


Most of those mitigations are automatically done for you by ASM. In the screenshot below, you can see how to configure each WebSocket URL (ws) and then set the format (text, JSON or binary). There’s not a lot that can be done for binary formats, but the other messages can be enforced via size and content.

To read more about the new features in ASM for version 12.1, see the ASM release notes.

I'm exhausted! That was difficult judging. At least I won’t have to judge again until I cast my ballot for either Hillary R. Clinton or Donald J. Trump in November. Or maybe I will write in a candidate: Miss Philippines!

Now that you’ve come all this way, you’re ready to start planning how you can use these hardcore security features in your network. Have a chat with your local Sales Engineer and download Version 12.1!