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.
- spalandeNacreous
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?
- KevinGallaugherEmployee
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
- spalandeNacreous
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?
- KevinGallaugherEmployee
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.