Use 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/xcwaapcdnguideDeploy WAF on any Edge with F5 Distributed Cloud (SaaS Console, Automation)
F5 XC WAAP/WAF presents a clear advantage over classical WAAP/WAFs in that it can be deployed on a variety of environments without loss of functionality. In this first article of a series, we present an overview of the main deployment options for XC WAAP while follow-on articles will dive deeper into the details of the deployment procedures.Overview of Trusted Client IP Headers in F5 Distributed Cloud Platform
Introduction: With day-to-day enhancements in security architecture, a request initiated at the source point traverses through multiple hops before it reaches the destination point. By design, if a request passes through any CDN/ Proxy that is present between the real client and the load balancer, we will no longer see the client’s IP address as the source address in the Load Balancer but the CDN/Proxy IP instead. Identification of real Client IP address is sometimes necessary for monitoring, logging, defining allow/deny policies and other purposes. “Trusted Client IP Header” feature of F5 Distributed Cloud platform solves the above concern and provides the ability to identify the real client IP address that initiated the connection. Security events and request logs will show this real client IP address as the source IP, when this feature is enabled.Trusted Client IP Header feature in F5 Distributed Cloud platform allows the admin to configure Client IP Headers. The admin can define a list of one or more Client IP Headers as Trusted headers. Below are some key points to be considered while configuring headers list: When multiple headers are configured, F5 Distributed Cloud platform follows top to bottom precedence, which means initially first header is considered and system checks for its availability in the request. If not present in the request, the system will proceed to check for the second header, and so on, until one of the listed headers is found. When none of the defined headers exists, or the value of the configured header is not an IP address, then the system will use the source IP of the packet. When multiple IP addresses are available in header value, the system will read the rightmost IP address and considers it as real Client IP address. But when using X-Forwarded-For Header and if multiple IPs are available in value, the system reads the rightmost-1 IP address and considers it as real client IP address. Below video provies brief introduction to Trusted Client IP Headers feature: Demonstration: In this demonstration, we will see how to identify the real client IP address using “Trusted Client IP headers” option in F5 Distributed Cloud platform. We are using F5 Distributed Cloud Content Distribution Network (check references for more details) Load-balancer configured with “Trusted Client IP Header” option enabled Airlines test application as a backend origin server. As shown in the below demo architecture, the request initiated at the client initially reaches to the available F5 CDN server and then the request from CDN hits the load balancer. Load balancer validates the request for configured headers availability, identifies the true client IP address and displays it rather than the CDN IP. The request from load balancer finally hits the backend application. Step 1: Creation of Origin Pool From your desired namespace, navigate to Manage -> Load Balancers -> Origin pools Click on "Add Origin Pool" Provide a name for Origin pool Configure Origin server details with valid Port details. Proceed with “Save and Exit” Step 2: Creation of Load Balancer with Trusted Client IP Header enabled From your desired namespace, Navigate to Manage -> Load Balancers -> HTTP Load Balancers Click on "Add HTTP load balancer" Provide a name for the Load Balancer Provide valid domain name and choose appropriate load balancer type under Basic Configuration Associate the above created Origin Pool in the load balancer In Other Settings, Enable Trusted Client IP Headers Provide a list of one or more Client Headers. Admin can configure any header which is used to find client IP address. Click on “Save and Exit” to save the Load Balancer configuration. Step 3: Create any Content Delivery Network or Proxy Here we are using F5 XC CDN between the client and the load balancer. CDN is a server that is used to serve web content quickly. CDN servers are distributed globally, and the main aim is to reduce latency and delay in end-to-end communication and thereby increases the efficiency. Check references for more exploration links. Navigate to Home -> Content Delivery Network -> Manage -> Distributions Click on “Add Distribution” Provide a name for the CDN Provide a valid domain name Choose appropriate CDN type Create a CDN Origin Pool by clicking on “Configure” Provide your HTTP Load Balancer domain name which is created above in the DNS name Add above created HTTP Load balancer domain name in the list of Origin Servers of CDN Origin pool Click on “Apply” twice CDN Origin pool gets created and associated with the CDN Click on “Save and Exit” Note: F5 CDN has provided a dedicated header called “X-F5-True-Client-Ip” to extract the real client address. Customers who are using F5 CDN can use this header to identify the client IP address. Similarly, customer can configure any headers or custom headers to identify the client IP. Step 4: Access the backend Origin Server Open a browser Access the backend server using the configured domain Observe that request hits the backend server and response page is visible Step 5: Validate logs and source IP To check the source IP, in F5 Distributed Cloud Console, Navigate to Home -> Load Balancer -> Virtual Hosts -> HTTP Load Balancers Choose the appropriate load balancer and open Security Monitoring -> Requests Observe the Client IP and validate it with the client public IP address. Client IP address should be displayed in the logs rather than the CDN/Proxy IP as the feature is enabled. This source IP can further be used in WAF Exclusions rules, to block or allow clients. Conclusion: As you can see from the above demonstration, with Trusted Client IP Headers option enabled in F5 Distributed Cloud platform, the request logs and security events are getting logged with the real client IP address as the source IP rather than the CDN IP. Reference Links: F5 Distributed Cloud Services F5 Distributed Cloud WAF F5 XC CDN Exploration Configure CDN Distribution
Mitigating OWASP API Security Top 10 risks using F5 NGINX App Protect
This 2019 API Security article covers the summary of OWASP API Security Top 10 – 2019 categories and newly published 2023 API security article covered introductory part of newest edition of OWASP API Security Top 10 risks – 2023. We will deep-dive into some of those common risks and how we can protect our applications against these vulnerabilities using F5 NGINX App Protect. Excessive Data Exposure Problem Statement: As shown below in one of the demo application API’s, Personal Identifiable Information (PII) data, like Credit Card Numbers (CCN) and U.S. Social Security Numbers (SSN), are visible in responses that are highly sensitive. So, we must hide these details to prevent personal data exploits. Solution: To prevent this vulnerability, we will use the DataGuard feature in NGINX App Protect, which validates all response data for sensitive details and will either mask the data or block those requests, as per the configured settings. First, we will configure DataGuard to mask the PII data as shown below and will apply this configuration. Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches. If needed, we can update configurations to block this vulnerability after which all incoming requests for this endpoint will be blocked. If you open the security log and filter with this support ID, we can see that the request is either blocked or PII data is masked, as per the DataGuard configuration applied in the above section. Injection Problem Statement: Customer login pages without secure coding practices may have flaws. Intruders could use those flaws to exploit credential validation using different types of injections, like SQLi, command injections, etc. In our demo application, we have found an exploit which allows us to bypass credential validation using SQL injection (by using username as “' OR true --” and any password), thereby getting administrative access, as below: Solution: NGINX App Protect has a database of signatures that match this type of SQLi attacks. By configuring the WAF policy in blocking mode, NGINX App Protect can identify and block this attack, as shown below. If you check in the security log with this support ID, we can see that request is blocked because of SQL injection risk, as below. Insufficient Logging & Monitoring Problem Statement: Appropriate logging and monitoring solutions play a pivotal role in identifying attacks and also in finding the root cause for any security issues. Without these solutions, applications are fully exposed to attackers and SecOps is completely blind to identifying details of users and resources being accessed. Solution: NGINX provides different options to track logging details of applications for end-to-end visibility of every request both from a security and performance perspective. Users can change configurations as per their requirements and can also configure different logging mechanisms with different levels. Check the links below for more details on logging: https://www.nginx.com/blog/logging-upstream-nginx-traffic-cdn77/ https://www.nginx.com/blog/modsecurity-logging-and-debugging/ https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/ https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ https://docs.nginx.com/nginx-app-protect-waf/logging-overview/logs-overview/ Unrestricted Access to Sensitive Business Flows Problem Statement: By using the power of automation tools, attackers can now break through tough levels of protection. The inefficiency of APIs to detect automated bot tools not only causes business loss, but it can also adversely impact the services for genuine users of an application. Solution: NGINX App Protect has the best-in-class bot detection technology and can detect and label automation tools in different categories, like trusted, untrusted, and unknown. Depending on the appropriate configurations applied in the policy, requests generated from these tools are either blocked or alerted. Below is an example that shows how requests generated from the Postman automation tool are getting blocked. By filtering the security log with this support-id, we can see that the request is blocked because of an untrusted bot. Lack of Resources & Rate Limiting Problem Statement: APIs do not have any restrictions on the size or number of resources that can be requested by the end user. Above mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute force attacks. Solution: NGINX App Protect provides different ways to rate limit the requests as per user requirements. A simple rate limiting use case configuration is able to block requests after reaching the limit, which is demonstrated below. Conclusion: In short, this article covered some common API vulnerabilities and shows how NGINX App Protect can be used as a mitigation solution to prevent these OWASP API security risks. Related resources for more information or to get started: F5 NGINX App Protect OWASP API Security Top 10 2019 OWASP API Security Top 10 2023Mitigating OWASP API Security Risk: Mass Assignment using F5 XC Platform
Overview: This article is a continuation of the series of articles on OWASP API Security vulnerabilities and demonstrates a scenario for mitigating API Mass Assignment using F5 Distributed Cloud Platform (XC). Introduction to OWASPAPI Mass Assignment: APIs are the foundation building blocks for today’s modern applications and because of such high acceptance there are software frameworks available to help the developers with the implementation, but these frameworks sometimes allow developers to automatically bind client’s request parameters into the code variables, opening gates for the attackers to exploit the Mass Assignment vulnerability. API Mass Assignment vulnerability occurs when manually crafted requests from clients to modify immutable internal object properties are not restricted by API Endpoints. Attackers can take advantage of this vulnerability by framing an HTTP request to escalate user privilege, bypass security mechanisms or use any other approach to make the API Endpoints work in a way it was not designed to work. Note: Mass Assignment and Excessive Data Exposure which were a separate risk category in OWASP API Sec 2019 are now merged into a new risk category named Broken Object Property Level Authorization The above image is the pictorial representation of possible exploitation of Mass Assignment vulnerability. You can see the attacker is successfully able to escalate his privilege from normal user to admin by manipulating the JSON content of the API request. In the first step, the attacker sends a valid API request to add the user and gets a response back with a parameter carrying information about the role. In the second step, the attacker adds the role parameter to the JSON object in the API request eventually resulting in successful exploitation of the vulnerability. Prevention Steps: Automatic binding ofclient’s input data into application's internal code variables should be avoided. Allow/Deny list should be clearly defined for the properties that should or shouldn't be accessible by the clients. Application schema should be well defined and enforced on all incoming client requests. Demonstration: For this demonstration we’ve already hosted crAPI (completely ridiculous API) application by referring to the QuickStart guide in the repository. Also, in the XC console we added the hosted application as an origin server and attached it with the newly created HTTP Load Balancer (LB). Note: crAPI is a vulnerable application designed for training purposes and can be a helpful tool to understand the OWASP top 10 most critical API security risks. For more details you can refer to OWASP crAPI repository Attack Scenario: In the use case below we have an API endpoint which is used to order products. This endpoint has a vulnerable field named “quantity” that can be exploited for mass assignment by providing a negative value resulting in a successful purchase order with an increase in available balance. As shown below at the start of the demo, the available balance for a user account is 200 $. Step1: First step is to gather the endpoint and request payload data by placing a valid purchase order from GUI. In the above screenshot, you can see we have successfully placed the order from the GUI which resulted in a decrease of available balance by 10$. This is a valid customer use case scenario. Step2: Next, we will try to place an order for a product with negative quantity using the gathered endpoint and check if mass assignment vulnerability is present or not. As you can see in the above screenshot the order with the negative quantity is placed successfully and the available balance is increased by 10$ which is not expected. Hence, we can conclude that mass assignment vulnerability exists in this demo application. Prevention through F5 XC: As mentioned in the prevention steps for the purpose of schema validation we will upload OpenAPI specification file to XC and set up the validation rules on incoming client requests If a mismatch occurs, an API Security event will betriggered and based on the enforcement mode set in the validation rules, the request will either getreported or blocked. Step1: As shown in the below image, update the crAPI’s OpenAPI specification file (a.k.a. swagger file) by adding a “minimum” keyword with value as “1” for the “quantity” parameter to restrict the request carrying a negative quantity to bypass Step2: Import crAPI’s swagger file to the LB and create API Definitions Login to F5 XC console Navigate to your LB and start editing the applied configuration Scroll down to API Protection and select “Enable” in API Definition field Click “Add Item”, Enter a name Click “Upload Swagger file”, Enter a name and upload the swagger file for your application, Apply the changes Now from your LB main config page, select “Custom List” for “Validation” field and click Configure. Start configuring Validation List, click “Add Item”, Enter a name, select “Validate” for “OpenAPI Validation Request Processing Mode” field, select “Block” for field “Request Validation Enforcement Type” and select all available properties in “Request Validation Properties” field, below of the config page select “Base Path - /” for “Type” field, Apply the changes. Refer to the document for more details. Step3: Try to repeat the attack scenario of ordering a product with negative quantity. As you can see in the above screenshot the attack was blocked successfully by the XC. Step4: Monitor the “Security Analytics” logs from F5 XC console Conclusion: API Mass assignment vulnerability can illegally be exploited by attackers to cause some serious damage but as demonstrated, F5 XC API security solutions can help to detect and mitigate such vulnerabilities with the help of Open-API schema validation feature. For more details, follow below links: OWASP API Security Project OWASP API6:2019 Mass Assignment F5 Distributed Cloud Services F5 Distributed Cloud WAAP Overview of OWASP API Security Top 10 2019 Introduction to OWASP API Security Top 10 2023Introduction to F5 Distributed Cloud Platform Per Route WAF Policy
Introduction: By default, F5 Distributed Cloud Platform supports WAF and routing at thedomain level i.e the origin pool associated with the Load balancer. F5 Distributed Cloud WAF provides the feasibility to create multiple routes with specific paths and attach the WAF rules individually on each path. This article is specifically demonstrating the above use case. In general, when a load balancer of host type HTTP/HTTPS, the request can be further matched based on parameters like URLs, headers, query parameters, http methods, etc. Once the request is matched, it can be sent to a specific endpoint based on the routing configuration and policy rules. The route object is used to configure L7 routing decision and is made of 3 things. Matching condition for incoming request Actions to take if the matching condition is true Whether the custom java script is enabled for this route match. Parameters offered per route configuration: URL path Prefix Specific header or Regex Demonstration: In this demo we will see how to forward a HTTP request depending on the route configuration and their associated WAF rules from F5 Distributed Cloud Services to origin server endpoints. we are using F5 Distributed Cloud Platform as the Environment. Arcadia Application as an origin server. Refer Load-balancer configured with multiple routes which are associated with different WAF rules. We shall see the demonstration in the below video to know the flow of how to configure and validate F5 Distributed Cloud Per-Route WAF Policy. Procedure: Step 1: Origin Pool Creation From your desired namespace, navigate to Manage --> Load Balancers --> Origin pools Click on "Add Origin Pool" Give it a name Add the Origin server details along with Port info. Click on ‘Save and Exit’ Step 2: Load Balancer with Route config and WAF Rules From the WAAP --> Navigate to Manage --> Load Balancers --> HTTP Load Balancers Click on "Add HTTP load balancer" Give it a name Set the domain name under Basic Configuration Under Routes section, click on ‘Configure’, click on ‘Add Item’ Select the type of Route as "Simple Route". Select HTTP method as “Any”. Select "Regex" under the "Path match" drop-down menu. Enter the string “\/trading\/.*” (without the quotes) as the regular expression (or Regex). This matches the requests for https://perroutewaf.com/trading/ Associate the above created Origin Pool. Under Advanced Options -->navigate to Security --> Web Application Firewall -->App Firewall -->Add Item. Create a WAF App firewall rule with Enforcement mode as “Blocking”. After attaching the WAF rule to the route, click on “Apply”. Repeat the above steps to create another route with Regex “.*” and the WAF rule Enforcement Mode ‘Monitoring’. Click on “Save and Exit” to save the Load Balancer configuration. Step 3: Validating perRouteWAF functionality - Output of /trading/.* route path: Open a browser and navigate to the login page of the application load balancer. try to generate SQL Injection attack to login as higher privileged user like admin. - Output of /.* route path: Try to access the Load Balancer with another route “/index.html”. Generate the SQL Injection attack to home page to get the privileged info. Step4: Logs Verification Monitor the security event log from F5 Distributed Cloud console, Navigate to WAAP --> Apps & APIs --> Security, select your LB and click on ‘Security Event’ tab. Conclusion: As you can see from the demonstration, F5 Distributed Cloud WAF has allowed and blocked the requests based on the route configuration and their associated WAF policies applied on the Load balancer. For further information click the links below: F5 Distributed Cloud Services F5 Distributed Cloud WAF
Getting started with the F5 Distributed Cloud Web App and API Protection Demo Guide
Overview Sometimes all it takes to get started learning something new is just a little guidance, for those times when we just don't know where to begin. Providing that direction is the purpose of the F5 Distributed Cloud Web App and API Protection (XC WAAP) demo guide. The guide and accompanying demo videoswill run you through sample app deployment, as well as App, API, Bot, and DDoS Protection use cases. We provide the app, the testing tool, and the guidance, everything you need to get started and kick the tires. All you need to bring is anF5 Distributed Cloud Account (trial is sufficient for this demo guide) and a bit of time. The guide uses a representative customer app scenario: a Star Ratings application which collects user ratings and reviews/comments on various items. The app runs on Kubernetes, and can be deployed on any cloud, but for the purposes of the demo guide we will deploy it on F5 XC virtual Kubernetes (vK8s) and protect it with F5 XC WAAP. The Scenario The Guide https://github.com/f5devcentral/xcwaapdemoguide Video Series Part 1:Infrastructure Setup Video Series Part 2:WAF Configuration Video Series Part 3: API Protection Video Series Part 4: Bot & DDoS Detection and Protection "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts.
F5 Distributed Cloud Content Delivery Network: an overview and what's new
From a technical feature perspective, there's nothing new in the world of Content Delivery. You read that right. What's new about it, however, is F5's Distributed Cloud blend of Content Delivery: It marries network connectivity, ingress networking, web security, and, of course, caching, and delivers it in a way that no other CDN provider has before. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. Most apps nowadays aggregate content from many sources, and many don't use the same internal networks or even one specific cloud provider. Modern apps now pull content from everywhere, and depending on how frequently the content is accessed, it doesn't make sense to pay a premium to have all of it always available within milliseconds. This is where F5 Distributed Cloud CDN breathes new life and adds color to readily accessible on-demand content. If you're like me, you're probably wondering what's different in Content Delivery Networks today? Higher expectations and more specialization among providers. At F5, we see these trends grow by the day: Stronger user-driven demand for personalized content, live streaming, on-demand video, and other dynamic elements Increased expectations for strong application performance, availability, uptime, and a robust security posture to support a user-focused experience A growing need to deliver application logic closer to consumers using standard software development pipeline and lifecycle management More specialization – most CDN providers are now focusing primarily on: o Security, the fast-growing market segment o Online gaming o OTT (over-the-top) video o Web, email, and data o File sharing The first step for any CDN is to deliver content from the location closest to the point of origin. To do that, F5 uses its high-capacity global network to resolve DNS as close to that point as possible, and to direct clients to the closest regional point of presence. From there, F5 provides global DDoS protection at OSI model Layers 3 through 7 with its consolidated DNS, and Web App and API Protection (WAAP). Putting all the bits together, the F5 Distributed Cloud Console streamlines configuration for modern app types and API traffic (files, video, images), with integrated security control and advanced caching policies. The centralized control plane provides both management and observability into specific application traffic and events across all the endpoints, including those on different network. Now, let's see an example of how we can use the F5 CDN to distribute a modern app. Arcadia Finance is an example of a microservices app that we use at F5 to showcase new product features. It uses independent modules that can live in multiple cloud providers and on different networks. Frontend/Main - IBM Cloud Satellite, OpenShift k8s Backend - Azure AKS Money-Transfer - IBM Cloud Satellite, OpenShift k8s Refer-A-Friend - Google GKE Frontend/Main and Money-Transfer are workloads that run as pods in a k8s cluster on IBM OpenShift and are connected to the F5 Global Network using a Cluster-native k8s customer endpoint (CE), a workload managed by F5. Backend is a workload connected via F5 Distributed Cloud Customer Endpoint (CE) native to Azure. Refer-A-Friend is workload connected via F5 Distributed Cloud Customer Endpoint (CE) native to Google Cloud Service. To support the above app, the following configuration has been added as a distribution in the Distributed Cloud Console CDN service: metadata: name: arcadia-cdn labels: {} spec: domains: - arcadia-cdn.demo.internal http: dns_volterra_managed: true add_location: false more_option: cache_ttl_options: cache_ttl_default: 1m origin_pool: public_name: dns_name: ves-io-f85551e2-8a82-4fb4-88a4-b5c202e56d41.ac.vh.ves.io no_tls: {} origin_servers: - public_name: dns_name: ves-io-f85551e2-8a82-4fb4-88a4-b5c202e56d41.ac.vh.ves.io dns_info: [] state: VIRTUAL_HOST_READY auto_cert_info: auto_cert_state: AutoCertDisabled dns_records: [] service_domains: - domain: arcadia-cdn.demo.internal service_domain: ves-io-cdn-arcadia-cdn-demo-internal.autocerts.ves.volterra.io When a user accesses and logs into the Arcadia App, F5 Distributed Cloud CDN first screens each request and then passes it through to the backend, in this case, Frontend/Main. The main pod then works to pull content from the backend, money-transfer, and refer-a-friend modules, all of which are available as different internal endpoints and virtual servers accessible only from other pods within the F5 Global Network. Only after the content has been successfully fetched by Frontend is the landing page finally presented to the user. In the context of CDN, we refer to this first case as a Cache-Miss. % curl -I http://arcadia-cdn.demo.internal/images/image1.jpg HTTP/1.1 200 OK Date: Thu, 15 Sep 2022 00:38:22 GMT Content-Type: image/jpeg Content-Length: 54142 Connection: keep-alive last-modified: Wed, 10 Aug 2022 18:48:47 GMT etag: "62f3fd8f-d37e" x-envoy-upstream-service-time: 5 Server: volt-cdn x-cache-status: MISS Accept-Ranges: bytes When Arcadia Finance is front ended with the Distributed Cloud CDN, content no longer needs to be fetched by Frontend/Main every time the user accesses the page. To reduce load on the app modules, the CDN caches all the content and delivers it to the user upon subsequent hits. This is known as a Cache-Hit. % curl -I http://arcadia-cdn.demo.internal/images/image1.jpg HTTP/1.1 200 OK Date: Thu, 15 Sep 2022 00:38:25 GMT Content-Type: image/jpeg Content-Length: 54142 Connection: keep-alive last-modified: Wed, 10 Aug 2022 18:48:47 GMT etag: "62f3fd8f-d37e" x-envoy-upstream-service-time: 31 Server: volt-cdn x-cache-status: HIT Accept-Ranges: bytes When using Distributed Cloud CDN to distribute frontend apps, even when there's a Cache-Miss, the user experience will be improved vs going to the app directly because the CDN directs the connection to F5's closest regional point of presence (PoP), eliminating much of the uncontrolled and variable latency inherent on the Internet. After accessing the Arcadia Finance app for some time, even when the cached page Time To Live (TTL) policy is set to a very low value of 1 minute, we're still able to see a good amount of caching provided by F5's CDN. Viewing the app's distribution performance in the Distributed Cloud Console, we can see the percentage of hits vs. misses, what the returned latency is for each, how much of the app is returning HTTP 2xx, 3xx, 4xx, or 5xx status codes, and even which versions of SSL and HTTP the connections use. Overall, F5's CDN pulls out all the stops when it comes to safeguarding your environments. Regardless of whether an app's content sprawls multiple private and public networks, F5's CDN can connect to it securely at the app level and cache it. Endpoint-specific security policies within the CDN can be added with a few clicks and the use of a Swagger file to further restrict the operations and content allowed to prevent malicious actors. All in all, F5's Content Delivery Network delivers the best set of network connectivity and security-focused functionality to enable today's most modern applications. In the following video, I share some of the additional benefits of using the F5 Distributed Cloud CDN and show the difference that users will notice when the CDN provides more content from the cache. Additional Resources For more information about this product as well as details on how to configure it, go to the following additional resources. CDN product information CDN product documentation F5 Distributed Cloud Secure CDN Solution: CDN + WAAP (Web App & API Security)
