Orchestrated Infrastructure Security - Advanced WAF

The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latest here.

Introduction

This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working.

If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here.

This article focuses on configuring F5 Advanced WAF deployed as a Layer 2 solution. It covers the configuration of Advanced WAF protection on an F5 BIG-IP running version 16.0.0.

Configuration files of BIG-IP deployed as Advanced WAF can be downloaded from here from GitLab.

Please forgive me for using SSL and TLS interchangeably in this article.

This article is divided into the following high level sections:

Advanced WAF Network Configuration
Attach Virtual Servers to an Advanced WAF Policy

Advanced WAF: Network Configuration

The BIG-IP will be deployed with VLAN Groups. This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. Vwire configuration will be covered later.

From the F5 Configuration Utility go to Network > VLANs. Click Create on the right.

Give it a name, ingress1 in this example. Set the Interface to 2.1. Set Tagging to Untagged then click Add.

Note: In this example interface 2.1 will receive decrypted traffic from sslo1

Interface 2.1 (untagged) should be visible like in the image below. Click Repeat at the bottom to create another VLAN.

Give it a name, egress1 in this example. Set the Interface to 2.2. Set Tagging to Untagged then click Add.

Note: In this example interface 2.2 will send decrypted traffic back to sslo1

Interface 2.2 (untagged) should be visible like in the image below. Click Finished.

Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators. Therefore, you should repeat these steps to configure VLANs for the two interfaces connected to sslo2. These VLANs should be named in a way that you can differentiate them from the others. Example: ingress2 and egress2

It should look something like this when done:

Note: In this example Interface 2.3 and 2.4 are physically connected to sslo2.

Click VLAN Groups then Create on the right.

Give it a name, vlg1 in this example. Move ingress1 and egress1 from Available to Members. Set the Transparency Mode to Transparent. Check the box to Bridge All Traffic then click Finished.

Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators. Therefore, you should repeat these steps to configure a VLAN Group for the two interfaces connected to sslo2. This VLAN Group should be named in a way that you can differentiate it from the other, example: vlg1 and vlg2. It should look like the image below:

For full Layer 2 transparency the following CLI option needs to be enabled:

(tmos)# modify sys db connection.vgl2transparent value enable

Attach Virtual Servers to an Advanced WAF Policy

You can skip this step if you already have an Advanced WAF policy created and attached to one or more virtual servers. If not, we’ll cover it briefly. In this example we configured Comprehensive Protection which includes Bot Mitigation, Layer 7 DoS and Application Security.

Give it a name, App_Protect1 in this example then click Save & Next.

Select the Enforcement Mode and Policy Type. Click Save & Next.

Configure the desired Bot Defense options. Click Save & Next on the lower right.

Configure the desired DoS Profile Properties. Click Save & Next.

Assign the policy to your application server(s) by moving them to Selected. Click Save & Next.

Click Finish/Deploy when done.

Summary

In this article you learned how to configure BIG-IP in layer 2 transparency mode using VLAN groups. We also covered how to create an Advanced WAF policy and attach it to your Virtual Servers.

Next Steps

Click Next to proceed to the next article in the series.

Updated Aug 11, 2022

Version 2.0

series-big-ip-ssl-orchestrator

series-orchestrated-infrastructure-security

sslo

waf

Was this article helpful?

4 Comments

SanjayP
Nacreous
Oct 20, 2022
KevinGallaugher thanks for the article? How to define application-specific virtual servers in layer 2 deployment mode and what should be the backend pool for it? How F5 will act as a proxy to decrypt all the traffic to apply adv WAF rules?
KevinGallaugher
Employee
Oct 27, 2022
Hi Sanjay, sorry for the delayed response.

In a layer 2 mode there’s no pool. The BIG-IP does not participate in layer 3.

However, you can define different VIPs that define source and/or destination IP addresses that act as filters for the traffic. So for example:

Let’s say you have a backend application at 192.168.1.100. In a layer 2 mode it’s expected that the client will route directly to this destination IP address, where the BIG-IP is physically in the path. When the client request comes to the F5, the destination address will be 192.168.1.100, and you cannot NAT or SNAT at the BIG-IP.

If you want to create application specific VIPs, you can create different L2 VIP with different destination IP “filters”. So an L2 VIP with a destination address of 192.168.1.100 would only consume that traffic. Again, source and destination IPs in an L2 mode are just filters for the traffic. An L2 VIP otherwise has a virtual-wire VLAN attached, no pool, and address and port translation are disabled.

You could also just create multiple AWAF policies and attach a CPM policy to your L2 VIP that dynamically selects one of the AWAF policies based on the incoming HTTP Host header. For example:

CPM policy

Rule 1: HTTP Host is www.f5labs.com on request -> enable asm (waf_policy_a)

Rule 2: HTTP Host is www1.f5labs.com on request -> enable asm (waf_policy_b)

Rule 3: disable asm on request
SanjayP
Nacreous
Oct 27, 2022
KevinGallaugher - Np Kevin. Thanks for your response. It's clear now.

If we have multiple ISP (lets say 3) connected to BIGIP and we would have 3 virtual wire VLANs configured for ingress and egress, how those would be assigned to the VIP?

Also, how can we make sure that IP conflict won't happen for the destination 192.168.1.100, if we configure VIP with the same IP address?
KevinGallaugher
Employee
Nov 03, 2022
For the multiple ISP question, the virtual wires/vlan groups will be set to Intercept in SSL Orchestrator. This is part of the Guided Config.

I'm not sure how to avoid the IP conflict in that example. My apologies, I wrote this article over 2 years ago.