F5 Distributed Cloud Reference Architecture: SaaS WAF

Use Case: SaaS Web Application Firewall

This reference architecture is for the customer who wants cloud based (SaaS) web application and API protection to defend against web threats for cloud deployed apps.

In this scenario, the customer may have one or more apps deployed in a an existing cloud VPC and wants to protect them with something simpler and/or more effective than what native cloud providers offer.

Customer Success Outcomes

Implementing this solution as outlined will allow the customer to achieve the following objectives / outcomes:

  • Protected web applications and APIs that deter attackers and serve customers
  • Increased efficacy of security solutions
  • Reduced management complexity and simplified procurement

Architecture

SaaS WAF Architecture

Solution Components

  • F5 Distributed Cloud (platform)
  • F5 Distributed Cloud WAAP
  • Customer Web Application stack
  • 3rd Party cloud provider where the application is hosted (AWS / Azure / GCP)

Prerequisites

This guide assumes the following prerequisites:

  • That you have an existing F5 Distributed Cloud account and access to the online portal. If that is not the case, please complete those steps before proceeding: Create Your F5 Distributed Cloud Account Now
  • The application must be internet accessible - in this scenario we create a new web application firewall, and route traffic to the existing application endpoint without any additional architectural changes, consequently it must be reachable by the web application firwall cloud service.
  • The operator/administrator must have the ability to manage the application’s DNS domain settings - this is necessary to redirect traffic to the web application firewall first before it is passed back to the application endpoint.

Deployment

The following steps will help you complete the configuration of the HTTP load-balancer and associated security policies. The first few steps define the configuration for the component objects and policies, and the final step will define the service endpoint that leverages them to process and route traffic.

Note that it is possible to complete this process using either the UI or API, or both. Please refer to the F5 Distributed Cloud Services API documentation for reference.


Step 1. Delegate DNS

DNS delegation is necessary for F5 Distributed Cloud to route traffic to the hosted endpoints where the load-balancer / WAF components are located. If your site is already live on the internet you may want to use an alternate DNS name for it temporarily until the entire configuration is completed and verified. Once it is verified, you can switch to the primary, production DNS name.

NOTE Becuase the DNS record needs to be delegated to F5 Distributed Cloud for it to be managed, there may be a small service interruption while the DNS information is migrated and moved under F5 Distributed Cloud’s control. Please plan your change window accordingly.

See the DNS Delegation documentation for more information.


Configuration steps:

  1. Determine the correct DNS name to use, for example www.example.com
  2. Create a DNS Delegation in the F5 Distributed Cloud Console, copy the TXT record string, and add it to your DNS provider’s configuration. This step allows F5 Distributed Cloud to verify ownership of the domain.
  3. Next you will need to delegate the NS record for your domain in your DNS provider’s console. Please refer to their instructions on how to go about this.
  4. Next you can use common DNS lookup tools to validate that the alias update has been applied.

Walkthrough: Delegating DNS


{
  "metadata": {
    "name": "demo.appro.io",
    "namespace": null,
    "labels": {},
    "annotations": {},
    "description": null,
    "disable": null
  },
  "spec": {
    "volterra_managed": {},
    "dnssec_mode": "DNSSEC_ENABLE"
  }
}

Example JSON: Delegating DNS


Step 2. Create an Origin Pool

The origin pool defines the back-end resources that will be front-ended (proxied) by the HTTP load-balancer (which applies the web application firewall security policies).

The origin pool can contain servers and Kubernetes clusters managed in F5 Distributed Cloud, or external resources that already exising on the internet / in the cloud. In this case we will leverage an existing application with an existing DNS name.


Configuration steps:

  1. Add a new Origin Pool
  2. Give the new Origin Pool a name, labels, and description
  3. Add one or more origin servers
  4. Add health checks as appropriate
  5. Define TLS settings for connecting to the origin pool members

Walkthrough: Creating an Origin Pool


{
  "metadata": {
    "name": "demo-appro-io",
    "namespace": null,
    "labels": {},
    "annotations": {},
    "description": null,
    "disable": null
  },
  "spec": {
    "origin_servers": [
      {
        "public_name": {
          "dns_name": "www.example.com"
        },
        "labels": {}
      }
    ],
    "use_tls": {
      "use_host_header_as_sni": {},
      "tls_config": {
        "default_security": {}
      },
      "volterra_trusted_ca": {},
      "no_mtls": {}
    },
    "port": 443,
    "same_as_endpoint_port": {},
    "healthcheck": [
      {
        "tenant": "tme-lab-works-oeaclgke",
        "namespace": "default",
        "name": "demo-n1"
      }
    ],
    "loadbalancer_algorithm": "LB_OVERRIDE",
    "endpoint_selection": "LOCAL_PREFERRED",
    "advanced_options": null
  }
}

Example JSON: Creating an Origin Pool


Step 3. Create an App Firewall and Define Security Policies

An App Firewall analyzes HTTP traffic and allows or denies clients and client requests based on a number of criteria. You have the option of enabling a variety of features that will govern how traffic is managed by the WAF.

The App Firewall can be configured in monitoring mode, or blocking mode. Monitoring mode will evaluate traffic and log the actions that would be taken if configured in blocking mode. Blocking mode will enfore the security policies configured. Monitoring mode can be useful to evalate policy changes and build confidence that they are approprite for the application.


Configuration steps:

  1. Add a new App Firewall
  2. Give the new App Firewall a name, labels, and description
  3. Choose and enforcment mode
  4. Choose detection settings and bot protection settings
  5. If desired, choose allowed response codes, masking of sensitive values in logs, and whether to use a custom response page
  6. Save and apply the configuration

Walkthrough: Creating an App Firewall


{
  "metadata": {
    "name": "demo-appro-io",
    "namespace": null,
    "labels": {},
    "annotations": {},
    "description": null,
    "disable": null
  },
  "spec": {
    "blocking": {},
    "detection_settings": {
      "signature_selection_setting": {
        "default_attack_type_settings": {},
        "high_medium_accuracy_signatures": {}
      },
      "enable_suppression": {},
      "enable_threat_campaigns": {},
      "default_violation_settings": {}
    },
    "default_bot_setting": {},
    "allow_all_response_codes": {},
    "default_anonymization": {},
    "use_default_blocking_page": {}
  }
}

Example JSON: Creating an App Firewall


Step 4. Create an HTTP Load Balancer

A load balancer handles SSL negotiation and routes and processes HTTP traffic for the application. If your application already has a load-balancer for traffic distribution across back-end nodes, then this HTTP load-balancer merely acts as a proxy, handling SSL and analyzing HTTP requests.

Configuration steps:

  1. Add a new HTTP Load Balancer
  2. Give the new HTTP Load Balancer a name, labels, and description
  3. Add domains for which the load balancer will pass traffic
  4. Define TLS (HTTPS) configuration, in this case we use automatically provisioned certificates
  5. Define the origin pool to use
  6. Choose where to advertise the load balancer VIP
  7. Select a Web Application Firewall Configuration
  8. Save and apply the configuration
  9. Validate the DNS and certificate provisioning

Walkthrough: Creating and HTTP load balancer with Auto Cert


{
  "metadata": {
    "name": "demo-appro-io",
    "namespace": null,
    "labels": {},
    "annotations": {},
    "description": null,
    "disable": null
  },
  "spec": {
    "domains": [
      "demo.appro.io"
    ],
    "https_auto_cert": {
      "http_redirect": true,
      "add_hsts": true,
      "no_mtls": {},
      "tls_config": {
        "default_security": {}
      },
      "default_header": {},
      "enable_path_normalize": {}
    },
    "advertise_on_public_default_vip": {},
    "default_route_pools": [
      {
        "pool": {
          "tenant": "tme-lab-works-oeaclgke",
          "namespace": "default",
          "name": "demo-appro-io"
        },
        "weight": 1,
        "priority": 1,
        "endpoint_subsets": {}
      }
    ],
    "routes": null,
    "cors_policy": null,
    "app_firewall": {
      "tenant": "tme-lab-works-oeaclgke",
      "namespace": "default",
      "name": "demo-appro-io"
    },
    "add_location": null,
    "no_challenge": {},
    "more_option": null,
    "user_id_client_ip": {},
    "disable_rate_limit": {},
    "malicious_user_mitigation": null,
    "waf_exclusion_rules": null,
    "data_guard_rules": null,
    "blocked_clients": null,
    "trusted_clients": null,
    "ddos_mitigation_rules": null,
    "service_policies_from_namespace": {},
    "round_robin": {},
    "multi_lb_app": {},
    "disable_bot_defense": {},
    "api_definitions": null
  }
}

Example JSON: Creating an HTTP Load Balancer with Auto Cert


Step 5. Access Control / Finalization

If your application is not managed by F5 Distributed Cloud, then you will need to configure the application so that it cannot receive traffic from clients directly. This ensures that all requests are routed through the WAF and analyzed, processed, and enforced accordingly.

You can use the list of F5 Distributed Cloud source addresses to build ACLs to ensure the application is only accepting connections from the appropriate source addresses. This list can be found here.


Validation

Pass traffic through the WAF endpoint

You can use a tool such as cURL to validate that the WAF is in place and allowing / denying traffic.

Walkthrough: Using cURL to Validate


curl -v https:{your domain name}/uri

Example: Using cURL to Validate


Review Security Monitoring dashboard

Take a few moments to familiarize yourself with the dashboards and reporting available in the console. The information provided will help you get the most from your investment and learn what kinds of threats are being observed and blocked.

Dashboards and reports of interest include:

  1. Malicous Users dashboard
  2. Security Events dashboard
  3. DDoS dashboard

Operational Considerations

If you eleceted to use an auto-cert configuration for the HTTP Load Balancer, you do not need to worry about renewing your SSL certificate - the system will handle this for you automatically. However if you implemented and uploaded a custom cert, you will be responsible for renewing it and keeping it up to date.


How to Buy

Individual and Team plans can be subscribed to from the F5 Distibuted Cloud Console. Billing for the above services will occur through the normal billing method selected there.

Organization plans can be quoted individually for those that need more advanced controls and premium support.

See https://www.f5.com/cloud/pricing for details or Contact Sales.