Cyber Security Attack Mitigations with BIG-IP features
ArvinF is back to share mitigation options for Cyber Security Attacks with BIG-IP features! This article aim to bring these attack mitigations options much more visible and available. Cyber Security Attacks There are many types of Cyber Security Attacks. I will limit to the types that BIG-IP mostly encounter. Network Attacks Network attacks are aimed at compromising, disrupting, or gaining unauthorized access to an organization’s internal or external network, usually targeting communication protocols, devices, or services within the network. Web Application Attacks Web application attacks target weaknesses in web-based applications to gain unauthorized access to data, manipulate functionality, or exploit users. Web Application and Network Attacks are common and these can affect the Web application and network traffic processed thru F5 Virtual Servers and in some cases, affect the availability of the BIG-IP device itself. Malware Attacks Malware (malicious software) includes viruses, worms, Trojans, ransomware, and spyware designed to damage or gain control over a computer system. BIG-IP Cyber Security Attacks Mitigations But First, Finding "Help" I have always found it helpful to review the Help Tab of the feature and configuration. While logged in on the BIG-IP Configuration utility for the specific BIG-IP Application Security Manager (BIG-IP ASM/Adv WAF) or BIG-IP Advanced Firewall Manager (BIG-IP AFM) menu, the "Help" tab contains details of the relevant configurations. If you hit Launch, it opens on a new window. You can also click on Expand All to view each options documentation. On to the mitigation options.. Bot Defense Profile We have here the description of the Bot Defense Profile Templates where it provides details of each template - Relaxed, Balanced and Strict - on the Verification and Mitigation it will provide. Take note of the Relaxed template Browser verification as it uses "Challenge-Free Verification". This means clients that do not support Javascript such as mobile applications will not be prevented due to verification and is less intrusive. From K42323285: Overview of the unified Bot Defense profile https://my.f5.com/manage/s/article/K42323285 Challenge-Free Verification—The default value when Profile Template is set to Relaxed. The system performs header-based verification but does not perform JavaScript verification. The Balanced and Strict offers more stringent client verification. For the mitigation from Bot Defense to take effect, it should be in blocking mode. Relaxed Mode Defines a permissive security policy that performs basic non-intrusive verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, blocks Malicious Bots and allows all other clients. Malicious Bots are detected mostly by using bot signatures. The mode provides basic protection level with very low risk of false positives. Balanced Mode Defines a moderate security policy that performs advanced verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, blocks Malicious Bots, initiates CAPTCHA challenge for Suspicious Browsers, limits the total request rate produced by Unknown bots and allows Trusted and Untrusted Bots. Malicious Bots and Suspicious Browsers are identified by using both anomaly detection algorithms and bot signatures. This mode provides an advanced protection level with reduced latency impact because Browser verification is performed by injecting challenge in HTTP response. Strict Mode Defines a strict security policy that performs advanced verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, and blocks all bots except Trusted Bots. This mode provides the most advanced and strict protection level using all capabilities of Bot Defense. Browser clients are not allowed to access unless they pass proactive verification. Mobile clients security access requires the use of Anti-Bot Mobile SDK. Here is a sample log for Bot Defense it is detecting a client that is classified as a "Suspicious Browser". The Bot Defense Profile that detected this bot request was configured with the "Relaxed" profile template. Here are sample Bot Traffic detected and actioned by a Bot Defense profile. Notice the Alarm and Block events. A detected "Suspicious Browser" is not blocked but generates an Alarm. A "malicious bot" is blocked DoS Protection Profile For the DoS Protection profiles, detection and mitigation can be configured thru TPS , Behavioral and Stress-based. The threshold for each configuration can be configured with Manual or Automatic thresholds. Manually configured TPS based detection looks at defined conditions and thresholds by Source IP, Device ID, Geolocation, URL and Site Wide and when exceeded, configured mitigation will take effect. The DoS Protection profile should be in Blocking mode for the mitigation to take effect. When using automatic threshold configuration in BIG-IP ASM/Adv WAF DoS Protection profile, the system sets the values using a wide range to begin with, then calculates the values using 7 days of historical data and sets threshold values to the highest levels during normal activity (to minimize false positives). Reference: K000138529: Understanding Automatic Threshold in BIG-IP ASM/Adv WAF DoS Protection profile The by Device ID detection option uses JavaScript to detect clients and requires a Bot Defense profile with Device ID mode to be configured. Here is the description of conditions from the TPS based detection configuration ================== Consider an IP as an attacking entity if either of the following conditions occur: Relative Threshold: TPS increased by: <traffic percentage> and reached at least <TPS> transactions per second OR Absolute Threshold: TPS reached: <TPS> transactions per second ================== Here is the description of conditions when TPS based detection is configured with Automatic Threshold ============== Consider an IP as an attacking entity if TPS reached an auto-calculated threshold in range <minimum TPS> - <upper limit TPS> transactions per second ============== For environments that have a mix of web and mobile application clients, only the Request Blocking option does not use Javascript to mitigate attacking clients. The Behavioral and Stress-based detection threshold can also be configured as Manual or Automatic and have the same configuration options TPS based detection. The difference is Server Stress is a requirement in this detection mode. Ensure that the DoS protection profile is in blocking mode. From the Online Help ============ Behavioral & Stress-based Detection In this area you can configure the system to prevent DoS attacks based on the server’s health condition. An attack is detected if the system finds the server to be under stress and either of the TPS thresholds are crossed. =========== Similar mitigation options are also available. Another section of Behavioral & Stress-based Detection is the Behavioral Detection and Mitigation where Bad Actor detection and mitigation can be configured From the Online Help ========= Bad actors behavior detection: Enables traffic behavior, server's capacity learning, and anomaly detection. Request signatures detection: Enables signatures detection. Use TLS fingerprints identification: Allows the system to distinguish between bad and good actors behind the same IP (NAT). When disabled (default), any attack behind the NAT treats all users behind the NAT as attackers. ========= Do take note of Request signatures detection and Use TLS fingerprints identification as these options are useful in identifying attacking clients behind a NAT device by way of TLS fingerprint and clients with specific HTTP signatures. Here is the Bad actors behavior detection mitigation descriptions. Review the protection levels and use what is appropriate as per your needs. Mitigation: No mitigation:Learns and monitors traffic behavior, but no action is taken. Conservative protection:If «Bad actors detection» enabled, slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Standard protection:If «Bad actors detection» enabled, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server's health. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Aggressive protection:If «Bad actors detection» enabled, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server's health. Proactively performs all protection actions (even before an attack). Increases the impact of the protection techniques. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Increases the impact of blocked requests. Regarding Server Stress There are a couple of locations where Server Stress can be observed. A spike in Server Stress will trigger Behavioral and Stress-based DoS detection and mitigation if configured. Protected Objects List This is under Security ›› DoS Protection : Protected Objects : Protected Objects List This menu is available when you have BIG-IP AFM provisioned in this sample, notice the Server Stress is at 100/100 - this means the backend server is Stressed and the latency of Server response is High. The protected object's attack status is "red" signaling an attack is ongoing and being mitigated. On this sample, the detected attack is ongoing and the server stress value has gone down to 55/100. The request rate also shows the connections per second and has gone down. Behavioral DoS Dashboard Under the Statistics menu, click on Dashboard Select Behavioral DoS in the Dashboard options Review Server Stress Here are sample DoS Application Events generated thru a DoS protection profile TPS Based detection and mitigation Behavioral detection and mitigation It provides insight which DoS "Threshold condition" was exceeded and what "Mitigation" was applied to the detected "Attack (Attack ID)" also noting the start and end of the attack. Inspecting these events will help in figuring out a threshold you may apply. DoS Dashboard under Security Reporting When looking for details of the attack, the DoS Dashboard under Security Reporting provides insight on the detected attack and related entities and statistics. In this sample, the detected attack was triggered thru App Behavioral and mitigated with Behavioral mitigation In this sample, notice the "transaction outcomes" shows "Blocked Bad Actor" which means the transactions were blocked by Bad Actor detection and mitigation configuration in the DoS protection profile. IP reputation , IP Intelligence license - must have! During DDoS attacks, it is very likely that the some of the source IP addresses will have bad IP reputation. Having the IP Intelligence license available in the BIG-IP will provide mitigation for matched IP addresses. IP Intelligence can be used in BIG-IP LTM (iRules and LTM Policy), AFM (IP Intelligence Policy) and ASM/Adv WAF (Security Policy) configurations. Refer to the following links on sample iRule configurations. https://clouddocs.f5.com/api/irules/IP__reputation.html https://clouddocs.f5.com/api/irules/IP__intelligence.html Note that the IP intelligence feature requires an add-on license.Contact your F5 or Partner salesperson for details on ordering the license. Cyber Security Attack Scenarios and Recommendations As introduced earlier, here are Cyber Security Attack Scenarios that BIG-IP deployments encounter and corresponding mitigation options and configuration recommendations. These sample scenarios will be helpful in finding initial mitigation options using BIG-IP features should it match your deployment configuration. Scenario: DDoS attack on a F5 Virtual Server fronting a web application and the BIG-IP have ASM/Adv WAF license. There are no DoS protection and Bot Defense profile configured on the Virtual Server. Recommendations: For the DoS Protection profile, configure TPS and Behavioral and Stress based Detection. Set Detection Thresholds and mitigations for both options as per your needs. You can monitor the traffic pattern on the Virtual Server you are protecting. Consider the clients that access the web application. If the clients are web browsers and mobile application users, use non Javascript (JS) based detection and mitigations. This will allow mobile application clients that do not support Javascript challenges to access the protected web application and ensure they are not blocked by Javascript challenges or mitigations. Another detection method is thru Bad Actor detection configuration under Behavioral and Stress Based Detection menu. This feature slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Automatic Threshold can also be configured for TPS based detection. For more information on HTTP enabled DoS Protection configured with Automatic Threshold, refer to K000138529: Understanding Automatic Threshold in BIG-IP ASM/Adv WAF DoS Protection profile For the Bot Defense profile, configure the Relaxed Profile template. This does not use Javascript challenges for detecting end clients and will allow mobile application clients that do not support Javascript to access the protected web application. Configure a logging profile that logs remotely to trusted logging server for DoS protection and Bot Defense events. Scenario: DDoS attack on a F5 Forwarding IP or Performance Layer 4 Virtual Server processing network traffic. Recommendations: Ensure DoS mitigations are available to protect the network traffic. BIG-IP AFM have DoS Attack types for Network Based DoS and can be set to Mitigate to detect and mitigate/drop excess packets for the matched attack type. These DoS Attack types can be configured with Fully Manual or Fully Automatic threshold. You should set detection and mitigation thresholds as per your needs. It is important to review traffic statistics and pattern on the Virtual Server you are protecting. AFM threshold values are in EPS - Events Per Second, synonymous to Packets Per Second and the observed traffic pattern can be the basis of the manually configured thresholds. Another method of defining the threshold is thru "Threshold Sensitivity" where the BIG-IP system CPU usage and traffic pattern is the basis. When AFM DoS attack types are configured with Fully Automatic, it uses the "Threshold Sensitivity" configuration. For BIG-IP Advanced Firewall Manager (AFM) systems protecting networks against Distributed Denial of Service (DDoS) attacks, DoS Auto Threshold sensitivity can be configured for system-wide thru Device Protection and per DoS Protection Profile. A setting of High will be more sensitive to changes in BIG-IP System CPU usage and traffic. A setting of Medium is the default configuration. A setting of Low will be less sensitive to changes in BIG-IP System CPU usage and traffic. From the BIG-IP Configuration utility, navigate to: For System Wide: Security ›› DoS Protection : Device Protection per DoS Protection Profile: Security ›› DoS Protection : Protection Profiles .. select the specific profile Reference: K000141430: Configuring BIG-IP AFM DoS Protection Threshold Sensitivity https://my.f5.com/manage/s/article/K000141430 Scenario: DNS DDoS attack on F5 DNS listener Virtual Server Recommendations: BIG-IP AFM have DNS Attack types to detect and mitigate DNS DDoS attacks. If your BIG-IP does not have BIG-IP AFM licensed, it would be beneficial for the DNS service processed thru the F5 DNS listener VS to have mitigation options available from the DNS Attack types in the AFM DoS device or DNS enabled protection profile. Configure thresholds as per your needs. Here is a sample configuration from a lab device where DNS A Query Attack type in Device Protection is configured in Mitigate state and Fully Manual detection and mitigation thresholds. Bad Actor Detection can also be configured with thresholds. It is also possible to configure it for Fully Automatic threshold and will be dependent on the Threshold Sensitivity configuration. Scenario: DDoS attack on F5 Virtual Server and attacking IP addresses needs to be blocked Recommendations: BIG-IP AFM has Network Firewall Policy and rules where it can be configured to match a source address list and drop its traffic. This can also be done thru iRules, however, AFM firewall rule configuration is a native feature and is built for such operations. The F5 SIRT created a playbook for HTTP brute force mitigation and the LTM mitigation options includes such configurations should you decide to use iRules and BIG-IP LTM features. HTTP Brute Force Mitigation Playbook: BIG-IP LTM Mitigation Options for HTTP Brute Force Attacks - Chapter 3 HTTP Brute Force Mitigation Playbook: BIG-IP LTM Mitigation Options for HTTP Brute Force Attacks - Chapter 3 | DevCentral F5 also have K30534815: Attack mitigation matrix using F5 security products and services which lists existing F5 Support articles for attack mitigation. https://my.f5.com/manage/s/article/K30534815 During DDoS attacks, it is very likely that the some of the source IP addresses will have bad IP reputation, it will be beneficial to have IP Intelligence license available and use it in BIG-IP LTM (iRules and LTM Policy), AFM (IP Intelligence Policy) and ASM/Adv WAF (Security Policy) configurations. Refer to the following links on sample iRule configurations. https://clouddocs.f5.com/api/irules/IP__reputation.html https://clouddocs.f5.com/api/irules/IP__intelligence.html Note that the IP intelligence feature requires an add-on license.Contact your F5 or Partner salesperson for details on ordering the license. Scenario: BIG-IP device is suspected to be compromised. Recommendations: BIG-IP can be affected by malware and it finds it's way to it by exposing the BIG-IP management and self (self-IP) IP addresses and configured with insecure or easy to guess BIG-IP user password. BIG-IP product had previous Critical CVEs where authentication was not needed to exploit the vulnerability. F5 has the article K11438344: Considerations and guidance when you suspect a security compromise on a BIG-IP system to provide guidance on handling suspected compromised BIG-IP devices. https://my.f5.com/manage/s/article/K11438344 To minimize the attack surface of a BIG-IP device against CVEs and unauthorized access, ensure that only trusted authenticated users and networks have access to the BIG-IP management and self (self-IP) IP addresses and the BIG-IP device is running the latest BIG-IP software version. Do review the "Major Release and Long-Term Stability Release versions supported with active software development" of K5903: BIG-IP software support policy as it notes BIG-IP 15.1.x version reaches "End of Technical Support" this December 31, 2024. Note: For BIG-IP Next (BIG-IP 20.x and later), refer toBIG-IP Next software support policy. Major Release and Long-Term Stability Release versions First customer ship End of Software Development End of Technical Support Latest maintenance release 17.1.x March 14, 2023 March 31, 2027 March 31, 2027 17.1.1 16.1.x July 7, 2021 July 31, 2025 July 31, 2025 16.1.5 15.1.x December 11, 2019 December 31, 2024 December 31, 2024 15.1.10 K5903: BIG-IP software support policy https://my.f5.com/manage/s/article/K5903 F5 Distributed Cloud "F5 Distributed Cloud Services are SaaS-based security, networking, and application management services that enable customers to deploy, secure, and operate their applications in a cloud-native environment wherever needed–data center, multi-cloud, or the network or enterprise edge." https://www.f5.com/products/distributed-cloud-services F5 Distributed Cloud have many mitigation options for DDoS attacks. Volumetric DDoS can be handled by F5 Distributed Cloud DDoS Mitigation Service. F5 Distributed Cloud Bot Defense mitigates complex bot attacks. It provides integration option with your mobile application so it can be properly classified and detected as a trusted client. see Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator https://www.f5.com/products/distributed-cloud-services/bot-defense https://www.f5.com/products/distributed-cloud-services/l3-and-l7-ddos-attack-mitigation Conclusion The Cyber Security Attack Scenarios and recommendations using BIG-IP features shared are not exhaustive. There are more complex environments and scenarios that BIG-IP deployments may have opportunity to mitigate network and application attack traffic and it is important that the appropriate BIG-IP licenses are available so the relevant modules can be provisioned and related features and configuration can be enabled. This will help your environment's network and application traffic to be resilient against DDoS attacks when BIG-IP is properly licensed, positioned and configured. I hope the sample configuration, logs and configuration help details have been useful and helpful as you consider the BIG-IP features mitigation options and improve your network, application and BIG-IP device security posture. Until next time! The F5 SIRT creates security-related content posted here in DevCentral, sharing the team’s security mindset and knowledge. Feel free to view the articles that are tagged with the following: F5 SIRT series-F5SIRT-this-week-in-security TWISUse F5 Distributed Cloud to service chain WAAP and CDN
The Content Delivery Network (CDN) market has become increasingly commoditized. Many providers have augmented their CDN capabilities with WAFs/WAAPs, DNS, load balancing, edge compute, and networking. Managing all these solutions together creates a web of operational complexity, which can be confusing. F5’s synergistic bundling of CDN with Web Application and API Protection (WAAP) benefits those looking for simplicity and ease of use. It provides a way around the complications and silos that many resource-strapped organizations face with their IT systems. This bundling also signifies how CDN has become a commodity product often not purchased independently anymore. This trend is encouraging many competitors to evolve their capabilities to include edge computing – a space where F5 has gained considerable experience in recent years. F5 is rapidly catching up to other providers’ CDNs. F5’s experience and leadership building the world’s best-of-breed Application Delivery Controller (ADC), the BIG-IP load balancer, put it in a unique position to offer the best application delivery and security services directly at the edge with many of its CDN points of presence. With robust regional edge capabilities and a global network, F5 has entered the CDN space with a complementary offering to an already compelling suite of features. This includes the ability to run microservices and Kubernetes workloads anywhere, with a complete range of services to support app infrastructure deployment, scale, and lifecycle management all within a single management console. With advancements made in the application security space at F5, WAAP capabilities are directly integrated into the Distributed Cloud Platform to protect both web apps and APIs. Features include (yet not limited to): Web Application Firewall: Signature + Behavioral WAF functionality Bot Defense: Detect client signals, determining if clients are human or automated DDoS Mitigation: Fully managed by F5 API Security: Continuous inspection and detection of shadow APIs Solution Combining the Distributed Cloud WAAP with CDN as a form of service chaining is a straightforward process. This not only gives you the best security protection for web apps and APIs, but also positions apps regionally to deliver them with low latency and minimal compute per request. In the following solution, we’ve combined Distributed Cloud WAAP and CDN to globally deliver an app protected by a WAF policy from the closest regional point of presence to the user. Follow along as I demonstrate how to configure the basic elements. Configuration Log in to the Distributed Cloud Console and navigate to the DNS Management service. Decide if you want Distributed Cloud to manage the DNS zone as a Primary DNS server or if you’d rather delegate the fully qualified domain name (FQDN) for your app to Distributed Cloud with a CNAME. While using Delegation or Managed DNS is optional, doing so makes it possible for Distributed Cloud to automatically create and manage the SSL certificates needed to securely publish your app. Next, in Distributed Cloud Console, navigate to the Web App and API Protection service, then go to App Firewall, then Add App Firewall. This is where you’ll create the security policy that we’ll later connect our HTTP LB. Let’s use the following basic WAF policy in YAML format, you can paste it directly in to the Console by changing the configuration view to JSON and then changing the format to YAML. Note: This uses the namespace “waap-cdn”, change this to match your individual tenant’s configuration. metadata: name: buytime-waf namespace: waap-cdn labels: {} annotations: {} disable: false spec: blocking: {} detection_settings: signature_selection_setting: default_attack_type_settings: {} high_medium_low_accuracy_signatures: {} enable_suppression: {} enable_threat_campaigns: {} default_violation_settings: {} bot_protection_setting: malicious_bot_action: BLOCK suspicious_bot_action: REPORT good_bot_action: REPORT allow_all_response_codes: {} default_anonymization: {} use_default_blocking_page: {} With the WAF policy saved, it’s time to configure the origin server. Navigate to Load Balancers > Origin Pools, then Add Origin Pool. The following YAML uses a FQDN DNS name reach the app server. Using an IP address for the server is possible as well. metadata: name: buytime-pool namespace: waap-cdn labels: {} annotations: {} disable: false spec: origin_servers: - public_name: dns_name: webserver.f5-cloud-demo.com labels: {} no_tls: {} port: 80 same_as_endpoint_port: {} healthcheck: [] loadbalancer_algorithm: LB_OVERRIDE endpoint_selection: LOCAL_PREFERRED With the supporting WAF and Origin Pool resources configured, it’s time to create the HTTP Load Balancer. Navigate to Load Balancers > HTTP Load Balancers, then create a new one. Use the following YAML to create the LB and use both resources created above. metadata: name: buytime-online namespace: waap-cdn labels: {} annotations: {} disable: false spec: domains: - buytime.waap.f5-cloud-demo.com https_auto_cert: http_redirect: true add_hsts: true port: 443 tls_config: default_security: {} no_mtls: {} default_header: {} enable_path_normalize: {} non_default_loadbalancer: {} header_transformation_type: default_header_transformation: {} advertise_on_public_default_vip: {} default_route_pools: - pool: tenant: your-tenant-uid namespace: waap-cdn name: buytime-pool kind: origin_pool weight: 1 priority: 1 endpoint_subsets: {} routes: [] app_firewall: tenant: your-tenant-uid namespace: waap-cdn name: buytime-waf kind: app_firewall add_location: true no_challenge: {} user_id_client_ip: {} disable_rate_limit: {} waf_exclusion_rules: [] data_guard_rules: [] blocked_clients: [] trusted_clients: [] ddos_mitigation_rules: [] service_policies_from_namespace: {} round_robin: {} disable_trust_client_ip_headers: {} disable_ddos_detection: {} disable_malicious_user_detection: {} disable_api_discovery: {} disable_bot_defense: {} disable_api_definition: {} disable_ip_reputation: {} disable_client_side_defense: {} resource_version: "517528014" With the HTTP LB successfully deployed, check that its status is ready on the status page. You can verify the LB is working by sending a basic request using the command line tool, curl. Confirm that the value of the HTTP header “Server” is “volt-adc”. da.potter@lab ~ % curl -I https://buytime.waap.f5-cloud-demo.com HTTP/2 200 date: Mon, 17 Oct 2022 23:23:55 GMT content-type: text/html; charset=UTF-8 content-length: 2200 vary: Origin access-control-allow-credentials: true accept-ranges: bytes cache-control: public, max-age=0 last-modified: Wed, 24 Feb 2021 11:06:36 GMT etag: W/"898-177d3b82260" x-envoy-upstream-service-time: 136 strict-transport-security: max-age=31536000 set-cookie: 1f945=1666049035840-557942247; Path=/; Domain=f5-cloud-demo.com; Expires=Sun, 17 Oct 2032 23:23:55 GMT set-cookie: 1f9403=viJrSNaAp766P6p6EKZK7nyhofjXCVawnskkzsrMBUZIoNQOEUqXFkyymBAGlYPNQXOUBOOYKFfs0ne+fKAT/ozN5PM4S5hmAIiHQ7JAh48P4AP47wwPqdvC22MSsSejQ0upD9oEhkQEeTG1Iro1N9sLh+w+CtFS7WiXmmJFV9FAl3E2; path=/ x-volterra-location: wes-sea server: volt-adc Now it’s time to configure the CDN Distribution and service chain it to the WAAP HTTP LB. Navigate to Content Delivery Network > Distributions, then Add Distribution. The following YAML creates a basic CDN configuration that uses the WAAP HTTP LB above. metadata: name: buytime-cdn namespace: waap-cdn labels: {} annotations: {} disable: false spec: domains: - buytime.f5-cloud-demo.com https_auto_cert: http_redirect: true add_hsts: true tls_config: tls_12_plus: {} add_location: false more_option: cache_ttl_options: cache_ttl_override: 1m origin_pool: public_name: dns_name: buytime.waap.f5-cloud-demo.com use_tls: use_host_header_as_sni: {} tls_config: default_security: {} volterra_trusted_ca: {} no_mtls: {} origin_servers: - public_name: dns_name: buytime.waap.f5-cloud-demo.com follow_origin_redirect: false resource_version: "518473853" After saving the configuration, verify that the status is “Active”. You can confirm the CDN deployment status for each individual region by going to the distribution’s action button “Show Global Status”, and scrolling down to each region to see that each region’s “site_status.status” value is “DEPLOYMENT_STATUS_DEPLOYED”. Verification With the CDN Distribution successfully deployed, it’s possible to confirm with the following basic request using curl. Take note of the two HTTP headers “Server” and “x-cache-status”. The Server value will now be “volt-cdn”, and the x-cache-status will be “MISS” for the first request. da.potter@lab ~ % curl -I https://buytime.f5-cloud-demo.com HTTP/2 200 date: Mon, 17 Oct 2022 23:24:04 GMT content-type: text/html; charset=UTF-8 content-length: 2200 vary: Origin access-control-allow-credentials: true accept-ranges: bytes cache-control: public, max-age=0 last-modified: Wed, 24 Feb 2021 11:06:36 GMT etag: W/"898-177d3b82260" x-envoy-upstream-service-time: 63 strict-transport-security: max-age=31536000 set-cookie: 1f945=1666049044863-471593352; Path=/; Domain=f5-cloud-demo.com; Expires=Sun, 17 Oct 2032 23:24:04 GMT set-cookie: 1f9403=aCNN1JINHqvWPwkVT5OH3c+OIl6+Ve9Xkjx/zfWxz5AaG24IkeYqZ+y6tQqE9CiFkNk+cnU7NP0EYtgGnxV0dLzuo3yHRi3dzVLT7PEUHpYA2YSXbHY6yTijHbj/rSafchaEEnzegqngS4dBwfe56pBZt52MMWsUU9x3P4yMzeeonxcr; path=/ x-volterra-location: dal3-dal server: volt-cdn x-cache-status: MISS strict-transport-security: max-age=31536000 To see a security violation detected by the WAF in real-time, you can simulate a simple XSS exploit with the following curl: da.potter@lab ~ % curl -Gv "https://buytime.f5-cloud-demo.com?<script>('alert:XSS')</script>" * Trying x.x.x.x:443... * Connected to buytime.f5-cloud-demo.com (x.x.x.x) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=buytime.f5-cloud-demo.com * start date: Oct 14 23:51:02 2022 GMT * expire date: Jan 12 23:51:01 2023 GMT * subjectAltName: host "buytime.f5-cloud-demo.com" matched cert's "buytime.f5-cloud-demo.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * Using HTTP2, server supports multiplexing * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x14f010000) > GET /?<script>('alert:XSS')</script> HTTP/2 > Host: buytime.f5-cloud-demo.com > user-agent: curl/7.79.1 > accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 200 < date: Sat, 22 Oct 2022 01:04:39 GMT < content-type: text/html; charset=UTF-8 < content-length: 269 < cache-control: no-cache < pragma: no-cache < set-cookie: 1f945=1666400679155-452898837; Path=/; Domain=f5-cloud-demo.com; Expires=Fri, 22 Oct 2032 01:04:39 GMT < set-cookie: 1f9403=/1b+W13c7xNShbbe6zE3KKUDNPCGbxRMVhI64uZny+HFXxpkJMsCKmDWaihBD4KWm82reTlVsS8MumTYQW6ktFQqXeFvrMDFMSKdNSAbVT+IqQfSuVfVRfrtgRkvgzbDEX9TUIhp3xJV3R1jdbUuAAaj9Dhgdsven8FlCaADENYuIlBE; path=/ < x-volterra-location: dal3-dal < server: volt-cdn < x-cache-status: MISS < strict-transport-security: max-age=31536000 < <html><head><title>Request Rejected</title></head> <body>The requested URL was rejected. Please consult with your administrator.<br/><br/> Your support ID is 85281693-eb72-4891-9099-928ffe00869c<br/><br/><a href='javascript:history.back();'>[Go Back]</a></body></html> * Connection #0 to host buytime.f5-cloud-demo.com left intact Notice that the above request intentionally by-passes the CDN cache and is sent to the HTTP LB for the WAF policy to inspect. With this request rejected, you can confirm the attack by navigating to the WAAP HTTP LB Security page under the WAAP Security section within Apps & APIs. After refreshing the page, you’ll see the security violation under the “Top Attacked” panel. Demo To see all of this in action, watch my video below. This uses all of the configuration details above to make a WAAP + CDN service chain in Distributed Cloud. Additional Guides Virtually deploy this solution in our product simulator, or hands-on with step-by-step comprehensive demo guide. The demo guide includes all the steps, including those that are needed prior to deployment, so that once deployed, the solution works end-to-end without any tweaks to local DNS. The demo guide steps can also be automated with Ansible, in case you'd either like to replicate it or simply want to jump to the end and work your way back. Conclusion This shows just how simple it can be to use the Distributed Cloud CDN to frontend your web app protected by a WAF, all natively within the F5 Distributed Cloud’s regional edge POPs. The advantage of this solution should now be clear – the Distributed Cloud CDN is cloud-agnostic, flexible, agile, and you can enforce security policies anywhere, regardless of whether your web app lives on-prem, in and across clouds, or even at the edge. For more information about Distributed Cloud WAAP and Distributed Cloud CDN, visit the following resources: Product website: https://www.f5.com/cloud/products/cdn Distributed Cloud CDN & WAAP Demo Guide: https://github.com/f5devcentral/xcwaapcdnguide Video: https://youtu.be/OUD8R6j5Q8o Simulator: https://simulator.f5.com/s/waap-cdn Demo Guide: https://github.com/f5devcentral/xcwaapcdnguide
