The DevCentral Chronicles June Edition 1(6)

Heading into the summer months is always a nice time of year – school is out, warmer weather, BBQs, beaches, baseball and maybe some vacation time. And hopefully all the Dads had a nice Father’s Day as we dive into our 6^th installment of the DC Chronicles. The Chronicles are intended to keep you updated on DevCentral happenings and highlight some of the cool content you may have missed since the last issue and you can always catch up with the links at the bottom. Welcome!

We had 20 new articles published since Volume 1, Issue 5, including 5 new Lightboard Lessons! We really enjoy making these and you, the audience, certainly express your enjoyment in watching. John Wagnon lit some cool security related topics like, Explaining TLS 1.3, What Are AEAD Ciphers? and The TLS 1.3 Handshake while Jason Rahm drew up the F5 software lifecycle and BIG-IP Cloud Edition Overview. Since we’re on Cloud, Chris Zhang also wrote up how to Achieve firewall high-availability in Azure with F5.

We also published a bunch of materials about our new BIG-IP Cloud Edition. BIG-IP Cloud Edition is designed to enable easy to use and fast self-serve deployments of application services in private and public clouds and is composed of BIG-IP Per-App VEs and BIG-IQ CM 6.0. To get the scoop, you can check out the BIG-IP Cloud Edition FAQ, Building Applications For The Rest Of Us With BIG-IQ 6 and Skies Never Looked So Good With BIG-IP Cloud Edition. DevCentral’s Chase Abbott lays out the details.

Moving from Cloud to Security, several vulnerability mitigations from our SIRT team dropped recently. You got coverage for Remote Code Execution with Spring OAuth Extension (CVE-2018-1260), a New BIG-IP ASM v13 Drupal v8 Ready Template, and a New BIG-IP ASM v13 WordPress v4.9 Ready Template. Also filed under Security, Steve Lyons showed how to Configure Smart Card Authentication to BIG-IP Management Interface.

Other highlights include Lori MacVittie’s Three HTTP Routing Patterns You Should Know with Eric Chen’s follow on, SNI Routing with BIG-IP. Chen also gives us Clone Pool Across L3 explaining how you can use the “clone pool” feature to copy traffic to an IDS and/or network monitoring device. Jason continues his Getting started with the Python SDK series covering Working with Statistics and Working with Request Parameters and finally, Jie Gao was DevCentral's Featured Member for June.

As always, You can stay engaged with @DevCentral by following us on Twitter, joining our LinkedIn Group or subscribing to our YouTube Channel. Look forward to hearing about your BIG-IP adventures.

The Chronicles:

• Volume 1, Issue 1
• Volume 1, Issue 2
• Volume 1, Issue 3
• Volume 1, Issue 4
• Volume 1, Issue 5

The OWASP Top 10 - 2017 vs. BIG-IP ASM

With the release of the new 2017 Edition of the OWASP Top 10, we wanted to give a quick rundown of how BIG-IP ASM can mitigate these vulnerabilities.

First, here's how the 2013 edition compares to 2017.

And how BIG-IP ASM mitigates the vulnerabilities.

	Vulnerability	BIG-IP ASM Controls
A1	Injection Flaws	Attack signatures Meta character restrictions Parameter value length restrictions
A2	Broken Authentication and Session Management	Brute Force protection Session tracking HTTP cookie protection
A3	Sensitive Data Exposure	Data Guard
A4	XML External Entities (XXE)	Attack signatures (see below)
A5	Broken Access Control	File types URL URL flows Session tracking URL flows Attack signatures (Directory traversal)
A6	Security Misconfiguration	Attack Signatures
A7	Cross-site Scripting (XSS)	Attack signatures Parameter meta characters Parameter value length restrictions Parameter type definitions (such as integer)
A8	Insecure Deserialization	Attack Signatures (see below)
A9	Using components with known vulnerabilities	Attack Signatures integration
A10	Insufficient Logging and Monitoring	BIG-IP ASM can help with the monitoring process to detect, alarm and deter attacks

Specifically, we have attack signatures for “A4:2017-XML External Entities (XXE)”:

• 200018018           External entity injection attempt

• 200018030           XML External Entity (XXE) injection attempt (Content)

Also, XXE attack could be mitigated by XML profile, by disabling DTDs (and of course enabling the “Malformed XML data” violation):

For “A8:2017-Insecure Deserialization” we have many signatures, which usually include the name “serialization” or “serialized object”, like:

• 200004188           PHP object serialization injection attempt (Parameter)
• 200003425           Java Base64 serialized object - java/lang/Runtime (Parameter)
• 200004282           Node.js Serialized Object Remote Code Execution (Parameter)

A quick run-down thanks to some of our security folks.

ps

Related:

• What’s New In The OWASP Top 10 And How TO Use It
• BIG-IP ASM Operations Guide

Mitigate L7 DDoS with BIG-IP ASM

Today, let’s look at a couple ways to mitigate an application DDoS attack with BIG-IP ASM.

We’ve logged into a BIG-IP ASM and navigated to Security>DDoS Protection>DDoS Profiles. In the General Settings of Application Security, we’ll activate an application DoS iRule event.

We’ll click TPS-based Detection to see the temporarily lowered TPS thresholds to easily simulate an attack. Often, there are multiple mitigation methods that are sequentially applied as you can see with the Source IP settings.

We can also record traffic packet captures during attacks for post analysis.

When the user requests a web application proxied by BIG-IP ASM, ASM will create a unique identifier or a Device ID. ASM will inject JavaScript to register each client device. You can see X-Device-ID: at the bottom.

And JavaScript incapable clients never make it through.

Now that the unit is ready, let’s enable some packet capture and take a go at that damn vulnerable web application.

Path for the log files is /var/log/ or /shared/log/…the PCAP folder is empty so let’s see the action.

Attack commence in 3-2-1. Some quick refreshes should do as our thresholds are low.

The first mitigation is Client Side Integrity Defense. The system issues a client-side integrity challenge that consumes client computation resources and slows down the attack. Next is Built-in Captcha. The third mitigation is Rate Limiting…

..then if they’re still not listening, you can instantly transform into a Honeypot.

The logs below show the IP address and the type of mitigation technique deployed. First Integrity, then Captcha, then Rate Limiting, then Honeypot if they don't stop. The traffic you recorded will be found in the, now populated, PCAP folders.

Thanks to F5 SE Artiom Lichtenstein for the demo video.

ps

Related:

• Lightboard Lessons: What is DDoS?