IBM Cloud Docs
Setting up a web application firewall with F5 BIG-IP

Setting up a web application firewall with F5 BIG-IP

There are several architectural approaches to enabling consumer connectivity to the workload VPC. When using public internet access to the workload VPC, a web application firewall (WAF) is required. A WAF helps protect web applications by filtering and monitoring internet traffic. This tutorial guides you through one approach to enabling WAF by using IBM Cloud® Internet Services (CIS) and F5 BIG-IP Virtual Edition. Global load balancing along with a WAF forms the basis for you to meet IBM Cloud Framework for Financial Services requirements for boundary protection.

Guidance is provided, but you are solely responsible for installing, configuring, and operating IBM third-party software in a way that satisfies IBM Cloud Framework for Financial Services requirements. In addition, IBM does not provide support for third-party software.

The following architecture diagram shows a deployment of the VPC reference architecture that uses BIG-IP for WAF.

IBM Cloud for Financial Services reference architecture with BIG-IP WAF
Figure 1. Single-region IBM Cloud for Financial Services reference architecture for VPC with BIG-IP

There are two main components to this solution:

  • CIS provides global load balancing and layer 3/4 protection against distributed denial-of-service (DDoS) attacks.
  • BIG-IP that provides WAF protection and layer 7 protection against denial-of-service (DoS) attacks.

CIS is not Financial Services Validated. Because of this, TLS connections must not be terminated in CIS and should be configured only for pass-through connections. CIS global load balancers must be configured with the proxy configuration setting value of off. CIS Use range applications sto provide DDoS protection in front of global load balancers.

Network path

The following diagram shows the flow of network traffic from a client application passing through CIS and BIG-IP to server-side applications running in Red Hat OpenShift on IBM Cloud.

IBM Cloud Network path from client application through CIS and BIG-IP to provider's Red Hat OpenShift on IBM Cloud application
Figure 2. Network path from client application to Red Hat OpenShift on IBM Cloud application passing through CIS and BIG-IP.

The network flow goes through the following steps:

  1. Client applications connect to a CIS Range application through a public hostname that is exposed by CIS. This connection is treated as a TCP connection (not an HTTPS connection) by CIS and passes through CIS without TLS termination. The Range application provides DDoS protection.
  2. A CIS global load balancer routes traffic to the WAF provided by BIG-IP instances. The global load balancer has a public hostname, but it is not advertised for use.
  3. The first TLS termination occurs in BIG-IP running in IBM Cloud. BIG-IP treats the connection as an HTTPS connection. The application's public certificate is used by BIG-IP for TLS termination.
  4. Network traffic is reencrypted between BIG-IP and the application. The Red Hat OpenShift on IBM Cloud ingress controller is configured for pass through so that it does not terminate the TLS connection. The final TLS termination is done by the application.

The following table summarizes the fully qualified domain names (FQDNs) used by the three layers:

Host description Example FQDN DNS How Protected
Range application hostname (user application hostname) www.application.example.com Managed by CIS, no explicit record CIS Layer 3/4
GLB hostname <uuid>-example.com Managed by CIS, no explicit record, public network Obfuscated, BIG-IP Virtual Server accepts only the Range Application Host Header
BIG-IP hostname f5-app.example.com A record maps to public external IP of BIG-IP, public network Security Group to only allow traffic from CIS
Red Hat OpenShift on IBM Cloud application hostname (not externalized) application-internal.example.com CNAME record maps to private-router ALB, private network Only accessible within network and protected by BIG-IP firewall. Security group restricts traffic to accept traffic only from BIG-IP.

Before you begin

The following items are needed to deploy and configure the reference architecture with CIS and BIG-IP to create a WAF:

  • Provisioned and licensed BIG-IP
  • Registered domain for CIS
  • Certificate for your registered domain (can be a wildcard certificate)
  • Intermediate certificate for your server-side application

Provision CIS

  1. Provision an instance of CIS that uses the Enterprise Usage plan.
  2. Click Create to provision the service.

Configure CIS TLS Mode

  1. Register your domain name with CIS.
  2. Go to Security > TLS set the TLS encryption mode to End-to-end flexible. End-to-End CA signed must not be used because it causes the TLS connection to be terminated in CIS.

Configure CIS Global Load Balancer

When a global load balancer is created in CIS, it is automatically assigned the fully qualified domain name (FQDN) of <global load balancer name>.<domain>. This hostname is registered in public DNS. However, this hostname should not be used for the application because it lacks DDoS protection. Use he hostname that is assigned to the Range application in the next step for the application.

  1. Go to Reliability > Global load balancers.
  2. Click Create.
  3. Set Enable to On.
  4. Set Proxy to Off. You must do this to avoid terminating the TLS connection in CIS.
  5. Enter a Name for the load balancer. This name is not used externally, but is referenced by the Range application.
  6. Set values for TTL and Traffic steering that are appropriate for your application.
  7. Click Create.
  8. Configure an origin pool for the new load balancer that contains the BIG-IP endpoints.
  9. Configure appropriate health checks.

You can use the following curl command to verify that the global load balancer is working correctly.

$ curl -v https://<global load balancer name>.<domain>/<path>

The verbose output from the curl command shows the signer of the SSL certificate that is terminating TLS. The signer should be the SSL certificate that is within the BIG-IP. If the signer of the certificate includes Cloudflare, then CIS is incorrectly terminating the TLS connection. Check that the global load balancer's Proxy is turned off and that the TLS encryption mode is set to End-to-End CA Flexible.

Configure CIS Range Application

DDoS protection in CIS is enabled by using a Range application. The Range application becomes the application's front end and sets the FQDN for the service.

  1. Go to Security > Range.
  2. Click Create.
  3. Select TCP as the Type. This enables pass-through without terminating TLS.
  4. Set the Name to the hostname that you want to expose for the application. The application's FQDN becomes <name>.<CIS domain>.
  5. Set the Edge port to the appropriate value. For HTTPS traffic, set the edge port to 443.
  6. Select an appropriate value for Edge IP connectivity.
  7. Set the Origin to Load balancer.
    1. Set Load balancer to the name of the global load balancer created in the previous step.
    2. Set the Port to the port that is exposed by the global load balancer.
  8. You can enable IP firewall if you want to restrict the IP ranges that can connect to the service. If IP filtering is not needed, disable IP firewall.
  9. TLS Termination must be set to off to prevent the TLS connection from being terminated in CIS.
  10. Leave TLS mode greyed out.
  11. Set Proxy protocol to Off.

You can use the following curl command to verify that the combination of the Range Application and Global Load Balancer is working correctly.

$ curl -v https://<Range application name>.<domain>/<path>

The verbose output from the curl command shows the signer of the SSL certificate where TLS is being terminated. The signer should be the signer of the application's SSL certificate. If the signer of the certificate includes "Cloudflare", then CIS is incorrectly terminating the TLS connection. Check that the Global Load Balancer's Proxy is configured to Off and that the TLS encryption mode is set to End-to-End CA Flexible.

When the edge application is working, it is important to prevent users from using the global load balancer directly. This is especially important to prevent a DDoS attack against the global load balancer. To prevent users from accessing the global load balancer directly, create a policy within BIG-IP that allows traffic to pass that specifies the FQDN of the Range application only.

Enable license modules on the BIG-IP

  1. Under System > License, click the Module Allocation tab.
  2. If Application Security (ASM) is not enabled, enable it with the Nominal selection.
  3. After BIG-IP restarts, log back into the BIG-IP console.

Import client certificate and key to BIG-IP

Import client key

  1. In the BIG-IP console, go to System > Certificate Management > Traffic Certificate Management.
  2. Click Import.
  3. Select Key from the Import Type.
  4. Type in a name for your key under the option Key Name.
  5. Either upload your key or paste your key under the option Key Source.
  6. Select the proper security type.
  7. Click Import.

Import client certificate

  1. In the BIG-IP console, go to System > Certificate Management > Traffic Certificate Management.
  2. Click Import.
  3. Select Certificate from the Import Type.
  4. In the Certificate Name field, enter a name for your certificate.
  5. Either upload your certificate or paste your certificate under the option Certificate Source.
  6. Click Import.

Import server-side intermediate certificates to BIG-IP

For each server certificate that you have, complete the following actions:

  1. In the console, go to System > Certificate Management > Traffic Certificate Management.
  2. Click Import.
  3. Select Certificate from the Import Type.
  4. In the Certificate Name field, enter a name for your certificate.
  5. Either upload your certificate or paste your certificate under the option Certificate Source.
  6. Click Import.

Configure ciphers

In this step, you create a cipher policy and group to limit the ciphers that are able to be used for a secure connection.

For more information on TLS requirements and acceptable cipher suites, see Data encryption in transit.

Create a cipher policy

  1. In the BIG-IP console, go to Local Traffic > Ciphers > Rules.
  2. Click Create.
  3. Set the following options:
    • Name: Name that you want to user for this policy
    • Cipher Suites: ECDHE-ECDSA-CHACHA20-POLY1305-SHA256:ECDHE-RSA-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLSV1_3
  4. Click Finished.

Create a cipher group

  1. In the BIG-IP console, go to Local Traffic > Ciphers > Groups.
  2. Click Create.
  3. Set the following options:
    • Name: Name that you want to user for this group
    • Under Group Details, move the rule that you created to the Allow the following section
  4. Click Finished.

Create SSL profiles in BIG-IP

In this step, you create a client and server SSL profile by using the client certificate or key and server certificate from the previous steps.

Create a client SSL profile

  1. In the BIG-IP console, go to Local Traffic > Profiles > SSL > Client.
  2. Click Create.
  3. Set the following options:
    • Name: Name that you want to user for this profile
  4. In the Configuration section, change Basic to Advanced, select Custom and set the following values:
    • Certificate Key Chain: Add both the key and certificate that you imported in the previous steps
    • Ciphers: select Cipher Group and the name of the group that you created in the previous step
    • Options: Options List...
    • Options List: The only enabled option should be Don't insert empty fragments
  5. Click Finished.

Create a server SSL profile

For each server certificate that you imported, create a server SSL profile by completing the following steps:

  1. In the BIG-IP console, navigate to Local Traffic > Profiles > SSL -> Server.
  2. Click Create.
  3. In the General Properties section, specify:
    • Name: Name that you want to use for this profile
  4. In the Configuration section, change Basic to Advanced, click the Custom checkbox and set the following values:
    • Secure Renegotiation: Require Strict
    • Server Name: FQDN of your custom application
    • Ciphers: select Cipher Group and the name of the group you created in the step above
    • Options: Options List...
    • Options List: Only enabled option should be Don't insert empty fragments
  5. In the Server Authentication section, set the following options:
    • Server Certificate: require...
    • Trusted Certificate Authorities: Set to your intermediate server certificate
  6. Click Finished.

Setting Up the HPCS integration with F5

Transport Layer Security (TLS) secures the communication between clients and servers, safeguarding against possible hacking attempts and man-in-the-middle attacks. TLS offloading involves employing a Hardware Security Module (HSM) to handle TLS encryption and decryption tasks instead of relying on the web server. This approach notably diminishes the risk of key compromise since TLS encryption keys are stored within FIPS 140-2 Level 4 validated HSMs. F5 Big IP offers configuration options through through which it can be integrated with HPCS for TLS offloading. To configure the HPCS to manage encryption keys and perform cryptographic operations in Big IP F5, see F5 docs on Setting Up the Network HSM.

Create a BIG-IP virtual server

In this step, you create a BIG-IP virtual server for traffic distribution with a backend pool.

Create iRules

An iRule is a feature within the BIG-IP local traffic management (LTM) system that you can use to manage your network traffic. See Getting started with iRules: Basic Concepts for more information about iRules.

  1. If you have a backend that serves multiple HTTPS sites by using the TLS Server Name Indication feature, for more information see Configure a virtual server to serve multiple HTTPS sites using the TLS Server Name Indication feature.
  2. Host header rewrite is used if your public facing domain is different than your backend. Use the following example to rewrite the host header based on the FQDN of the incoming request:
when HTTP_REQUEST {
    set hostname [getfield [HTTP::host] ":" 1]
}
when HTTP_REQUEST_SEND {
    switch -glob [string tolower $hostname] {
    "mysiteA.public.domain" {
      clientside {
        HTTP::header replace host "mysiteA.backend.domain"
      }
    }
    "mysiteB.public.domain" {
      clientside {
        HTTP::header replace host "mysiteB.backend.domain"
      }
    }
    default {
      reject
    }
  }
}

Create the backend pool

  1. In the BIG-IP console, go to Local Traffic > Pools > Pool List.
  2. Click Create.
  3. In the Configuration section, set the following fields:
    • Name: Name that you want to use for the pool
    • Health Monitor: Select an appropriate protocol to monitor the health of your members
  4. In the Resources section, set the following fields:
    • Load Balancing Method: Select an appropriate method that you would like to use for balancing traffic
    • New Members: For each IP or FQDN, input the members of your backend server

Create policies

If you have multiple backend pools to which you need to route traffic, you must create a policy to route traffic to the proper backend pool. For more information, see Introducing Local Traffic Policies.

  1. Go to Local Traffic > Policies > Policy List.
  2. Click Create.
  3. Set the following under General Properties:
    • Policy Name: Name that you want to use for the policy
    • Strategy: Set the strategy that you would like to use for rule matching
    • Type: Traffic Policy
  4. Click Create.
  5. Under Rules, click Create.
  6. Under Name, enter the name that you want to specify for this rule.
  7. Click the + symbol and enter the conditions that must be matched.
  8. Click the + symbol and enter what should be done when the condition is met. If you want to forward to a backend pool, select Forward Traffic.
  9. If you need to create multiple rules, click Create again and repeat the previous steps.
  10. After all rules are created, click Save Draft.
  11. Under Local Traffic > Policies > Policy List, select your policy and click Publish.

Create the virtual server

  1. In the console, go to Local Traffic > Virtual Servers > Virtual Server List.
  2. Click Create
  3. In the General Properties section, select or input the following fields:
    • Name: Name that you want to use for the virtual server
    • Type: Standard
    • Destination Address/Mask: Internal IP of the External interface
    • Service Port: 443
    • State: Enabled
  4. Under the Configuration section, select or input the following fields:
    • Protocol: TCP
    • Protocol Profile (Client): tcp
    • Protocol Profile (Server): (Use Client Profile)
    • HTTP Profile (Client): http
    • HTTP Profile (Server): (Use Client Profile)
    • SSL Profile (Client): Name of the client SSL profile you created previously
    • SSL Profile (Server): If you have one server profile, select the name that you created in a previous step, otherwise see the iRules sections
    • Source Address Translation: Auto Map
  5. Click Finished.
  6. Click the name of your newly created virtual server from the Virtual Server List.
  7. Click the Resources tab.
  8. Under the Load Balancing section select the following options:
    • Default Pool: Name of backend pool that you created in a previous step
  9. Under the iRules section:
    • Click Manage.
    • Move the iRules that you want to enable to the Enabled section.
  10. Under the Policies section:
    • Click Manage.
    • Move the policy that you want to enable to the Enabled section.

Configure WAF on the virtual server

Enable license

  1. Under System > License, click the Module Allocation tab.
  2. If Application Security (ASM) is not enabled, enable it with the Nominal selection.
  3. BIG-IP restarts.
  4. When the restart completes, log back into BIG-IP.

Set up WAF

  1. Go to Security > Guided Configuration.
  2. Click Web Application Protocol and then Web Application Comprehensive Protection.
  3. Click Next.
  4. Under Security Layers* do the following:
    1. Enter a configuration name.
    2. Enable any security layers that you would like. The security layers of Security Policy and Behavioral Analysis DoS should at least be enabled.
    3. Click Save and Next.
  5. Under Web Application Security Policy Properties:
    1. Set the following:
    • Select Enforcement Mode: Blocking
    • Select type of policy to protect application: Generic
    • Application Language: Select the language encoding for your web application
    1. Click Save and Next.
  6. Under Bot Defense Properties
    1. Set the following:
    • Select Enforcement Mode: Blocking
    • Profile Template: Balanced
    1. Click Save and Next.
  7. Under DoS Profile Properties
    1. Set the following under Operation Mode:
    • Operation Mode: Blocking
    • Verify that Bad actors behavior detection and Request signature detection are selected
    1. Set the following under Mitigation Mode:
    • Mitigation Mode: Standard
    1. Click Save and Next.
  8. Under Virtual Server Properties
    1. Check Assign Policy to Virtual Server(s).
    2. Under Virtual Server select Use Existing.
    3. Under Assign Virtual Servers, move the virtual server that you created previously over from Available to Selected.
    4. Click Save and Next.
  9. Click Deploy.
  10. Verify that the configuration is under *Deployed status.