Equinix and F5 Distributed Cloud Services: Business Partner Application Exchanges
As organizations adopt hybrid and multicloud architectures, one of the challenges they face is how they can securely connect their partners to specific applications while maintaining control over cost and limiting complexity. Unfortunately, traditional private connectivity models tend to struggle with complex setups, slow on-boarding, and rigid policies that make it hard to adapt to changing business needs. F5 Distributed Cloud Services on Equinix Network Edge provides a solution that makes partner connectivity process easier, enhances security with integrated WAF and API protection, and enables consistent policy enforcement across hybrid and multicloud environments. This integration allows businesses to modernize their connectivity strategies, ensuring faster access to applications while maintaining robust security and compliance. Key Benefits The benefits of using Distributed Cloud Services with Equinix Network Edge include: • Seamless Delivery: Deploy apps close to partners for faster access. • API & App Security: Protect data with integrated security features. • Hybrid Cloud Support: Enforce consistent policies in multi-cloud setups. • Compliance Readiness: Meet data protection regulations with built-in security features. • Proven Integration: F5 + Equinix connectivity is optimized for performance and security. Before: Traditional Private Connectivity Challenges Many organizations still rely on traditional private connectivity models that are complex, rigid, and difficult to scale. In a traditional architecture using Equinix, setting up infrastructure is complex and time-consuming. For every connection, an engineer must manually configure circuits through Equinix Fabric, set up BGP routing, apply load balancing, and define firewall rules. These steps are repeated for each partner or application, which adds a lot of overhead and slows down the onboarding process. Each DMZ is managed separately with its own set of WAFs, routers, firewalls, and load balancers. This makes the environment harder to maintain and scale. If something changes, such as moving an app to a different region or giving a new partner access, it often requires redoing the configuration from scratch. This rigid approach limits how fast a business can respond to new needs. Manual setups also increase the risk of mistakes. Missing or misconfigured firewall rules can accidentally expose sensitive applications, creating security and compliance risks. Overall, this traditional model is slow, inflexible, and difficult to manage as environments grow and change. After: F5 Distributed Cloud Services with Equinix Deploying F5 Distributed Cloud Customer Edge (CE) software on Equinix Network Edge addresses these pain points with a modern, simplified model, enabling the creation of secure business partner app exchanges. By integrating Distributed Cloud Services with Equinix, connecting partners to internal applications is faster and simpler. Instead of manually configuring each connection, Distributed Cloud Services automates the process through a centralized management console. Deploying a CE is straightforward and can be done in minutes. From the Distributed Cloud Console, open "Multi-Cloud Network Connect" and create a "Secure Mesh Site" where you can select Equinix as a Provider. Next, open the Equinix Console and deploy the CE image. This can be done through the Equinix Marketplace, where you can select the F5 Distributed Cloud Services and deploy it to your desired location. A CE can replace the need for multiple components like routers, firewalls, and load balancers. It handles BGP routing, traffic inspection through a built-in WAF, and load balancing. All of this is managed through a single web interface. In this case, the CE connects directly to the Arcadia application in the customer’s data center using at least two IPsec tunnels. BGP peering is quickly established with partner environments, allowing dynamic route exchange without manual setup of static routes. Adding a new partner is as simple as configuring another BGP session and applying the correct policy from the central Distributed Cloud Console. Instead of opening up large network subnets, security is enforced at Layer 7, and this app-aware connectivity is inherently zero trust. Each partner only sees and connects to the exact application they’re supposed to, without accessing anything else. Policies are reusable and consistent, so they can be applied across multiple partners with no duplication. The built-in observability gives real-time visibility into traffic and security events. DevOps, NetOps, and SecOps teams can monitor everything from the Distributed Cloud Console, reducing troubleshooting time and improving incident response. This setup avoids the delays and complexity of traditional connectivity methods, while making the entire process more secure and easier to operate. Simplified Partner Onboarding with Segments The integration of F5 and Equinix allows for simplified partner onboarding using Network Segments. This approach enables organizations to create logical groupings of partners, each with its own set of access rules and policies, all managed centrally. With Distributed Cloud Services and Equinix, onboarding multiple partners is fast, secure, and easy to manage. Instead of creating separate configurations for each partner, a single centralized service policy is used to control access. Different partner groups can be assigned to segments with specific rules, which are all managed from the Distributed Cloud Console. This means one unified policy can control access across many Network Segments, reducing complexity and speeding up the onboarding process. To configure a Segment, you can simply attach an interface to a CE and assign it to a specific segment. Each segment can have its own set of policies, such as which applications are accessible, what security measures are in place, and how traffic is routed. Each partner tier gets access only to the applications allowed by the policy. In this example, Gold partners might get access to more services than Silver partners. Security policies are enforced at Layer 7, so partners interact only with the allowed applications. There is no low-level network access and no direct IP-level reachability. WAF, load balancing, and API protection are also controlled centrally, ensuring consistent security for all partners. BGP routing through Equinix Fabric makes it simple to connect multiple partner networks quickly, with minimal configuration steps. This approach scales much better than traditional setups and keeps the environment organized, secure, and transparent. Scalable and Secure Connectivity F5 Distributed Cloud Services makes it simple to expand application connectivity and security across multiple regions using Equinix Network Edge. CE nodes can be quickly deployed at any Equinix location from the Equinix Marketplace. This allows teams to extend app delivery closer to end users and partners, reducing latency and improving performance without building new infrastructure from scratch. Distributed Cloud Services allows you to organize your CE nodes into a "Virtual Site". This Virtual Site can span multiple Equinix locations, enabling you to manage all your CE nodes as a single entity. When you need to add a new region, you can deploy a new CE node in that location and all configurations are automatically applied from the associated Virtual Site. Once a new CE is deployed, existing application and security policies can be automatically replicated to the new site. This standardized approach ensures that all regions follow the same configurations for routing, load balancing, WAF protection, and Layer 7 access control. Policies for different partner tiers are centrally managed and applied consistently across all locations. Built-in observability gives full visibility into traffic flows, segment performance, and app access from every site - all from the Distributed Cloud Console. Operations teams can monitor and troubleshoot with a unified view, without needing to log into each region separately. This centralized control greatly reduces operational overhead and allows the business to scale out quickly while maintaining security and compliance. Service Policy Management When scaling out to multiple regions, centralized management of service policies becomes crucial. Distributed Cloud Services allows you to define service policies that can be applied across all CE nodes in a Virtual Site. This means you can create a single policy that governs how applications are accessed, secured, and monitored, regardless of where they are deployed. For example, you can define a service policy that adds a specific HTTP header to all incoming requests for a particular segment. This can be useful for tracking, logging, or enforcing security measures. Another example is setting up a policy that rate-limits API calls from partners to prevent abuse. This policy can be applied across all CE nodes in the Virtual Site, ensuring that all partners are subject to the same rate limits without needing to configure each node individually. The policy works on the L7 level, meaning it passes only HTTP traffic and blocks any non-HTTP traffic. This ensures that only legitimate web requests are processed, enhancing security and reducing the risk of attacks. Distributed Cloud Services provides different types of dashboards to monitor the performance and security of your applications across all regions. This allows you to monitor security incidents, such as WAF alerts or API abuse, from a single dashboard. The Distributed Cloud Console provides detailed logs with information about each request, including the source IP, HTTP method, response status, and any applied policies. If a request is blocked by a WAF or security policy, the logs will show the reason for the block, making it easier to troubleshoot issues and maintain compliance. The centralized management of service policies and observability features in Distributed Cloud Services allows organizations to save costs and time when managing their hybrid and multi-cloud environments. By applying consistent policies across all regions, businesses can reduce the need for manual configurations and minimize the risk of misconfigurations. This not only enhances security but also simplifies operations, allowing teams to focus on delivering value rather than managing complex network setups. Offload Services to Equinix Network Edge For organizations that require edge compute capabilities, Distributed Cloud Services provides a Virtual Kubernetes Cluster (vK8s) that can be deployed on Equinix Network Edge in combination with F5 Distributed Cloud Regional Edge (RE) nodes. This solution allows you to run containerized applications in a distributed manner, close to your partners and end users to reduce latency. For example, you can deploy frontend services closer to your partners while your backend services can remain in your data center or in a cloud provider. The more services you move to the edge, the more you can benefit from reduced latency and improved performance. You can use vK8s like a regular Kubernetes cluster, deploying applications, managing resources, and scaling as needed. The F5 Distributed Cloud Console provides a CLI and web interface to manage your vK8s clusters, making it easy to deploy and manage applications across multiple regions. Demos Example use-case part 1 - F5 Distributed Cloud & Equinix: Business Partner App Exchange for Edge Services Video link TBD Example use-case part 2 - Go beyond the network with Zero Trust Application Access from F5 and Equinix Video link TBD Standalone Setup, Configuration, Walkthrough, & Tutorial Conclusion F5 Distributed Cloud on Equinix Network Edge transforms how organizations connect partners and applications. With its centralized management, automated connectivity, and built-in security features, it becomes a solid foundation for modern hybrid and multi-cloud environments. This integration simplifies partner onboarding, enhances security, and enables consistent policy enforcement across regions. Learn more about how F5 Distributed Cloud Services and Equinix can help your organization increase agility while reducing complexity and avoiding the pitfalls of traditional private connectivity models. Additional Resources F5 & Equinix Partnership: https://www.f5.com/partners/technology-alliances/equinix F5 Community Technical Article: Building a secure Application DMZ F5 Blogs F5 and Equinix Simplify Secure Deployment of Distributed Apps F5 and Equinix unite to simplify secure multicloud application delivery Extranets aren’t dead; they just need an upgrade Multicloud chaos ends at the Equinix Edge with F5 Distributed Cloud CE
Mitigating OWASP Web Application Risk: Insecure Design using F5 XC platform
Overview: This article is the last part in a series of articles on mitigation of OWASP Web Application vulnerabilities using F5 Distributed Cloud platform (F5 XC). Introduction to Insecure Design: In an effort to speed up the development cycle, some phases might be reduced in scope which leads to give chance for many vulnerabilities. To focus the risks which are been ignored from design to deployment phases, a new category of “Insecure Design” is added under OWASP Web Application Top 10 2021 list. Insecure Design represents the weaknesses i.e. lack of security controls which are been integrated to the website/application throughout the development cycle. If we do not have any security controls to defend the specific attacks, Insecure Design cannot be fixed by any perfect implementation while at the same time a secure design can still have an implementation flaw which leads to vulnerabilities that may be exploited. Hence the attackers will get vast scope to leverage the vulnerabilities created by the insecure design principles. Here are the multiple scenarios which comes under insecure design vulnerabilities. Credential Leak Authentication Bypass Injection vulnerabilities Scalper bots etc. In this article we will see how F5 XC platform helps to mitigate the scalper bot scenario. What is Scalper Bot: In the e-commerce industry, Scalping is a process which always leads to denial of inventory. Especially, online scalping uses bots nothing but the automated scripts which will check the product availability periodically (in seconds), add the items to the cart and checkout the products in bulk. Hence the genuine users will not get a fair chance to grab the deals or discounts given by the website or company. Alternatively, attackers use these scalper bots to abandon the items added to the cart later, causing losses to the business as well. Demonstration: In this demonstration, we are using an open-source application “Evershop” which will provide end to end online shopping cart facility. It will also provide an Admin page which helps to add/delete the item from the website whereas from the customer site users can login and checkout the items based on the availability. Admin Page: Customer Page: Scalper bot with automation script: The above selenium script will login to the e-commerce application as a customer, checks the product availability and checkout the items by adding the items into the cart. To mitigate this problem, F5 XC is providing the feasibility of identifying and blocking these bots based on the configuration provided under HTTP load balancer. Here is the procedure to configure the bot defense with mitigation action ‘block’ in the load balancer and associate the backend application nothing but ‘evershop’ as the origin pool. Create origin pool Refer pool-creation for more info Create http load balancer (LB) and associate the above origin pool to it. Refer LB-creation for more info Configure bot defense on the load balancer and add the policy with mitigation action as ‘block’. Click on “Save and Exit” to save the Load Balancer configuration. Run the automation script by providing the LB domain details to exploit the items in the application. Validating the product availability for the genuine user manually. Monitor the logs through F5 XC, Navigate to WAAP --> Apps & APIs --> Security Dashboard, select your LB and click on ‘Security Event’ tab. Conclusion: As you have seen from the demonstration, F5 Distributed Cloud WAAP (Web Application and API Protection) has detected the scalpers with the bot defense configuration applied on the Load balancer and mitigated the exploits of scalper bots. It also provides the mitigation action of “_allow_”, “_redirect_” along with “_block_”. Please refer link for more info. Reference links: OWASP Top 10 - 2021 Overview of OWASP Web Application Top 10 2021 F5 Distributed Cloud Services F5 Distributed Cloud Platform Authentication Bypass Injection vulnerabilitiesF5 VELOS: A Next-Generation Fully Automatable Platform
What is VELOS? The F5 VELOS platform is the next generation of F5’s chassis-based systems. VELOS can bridge traditional and modern application architectures by supporting a mix of traditional F5 BIG-IP tenants as well as next-generation BIG-IP Next tenants in the future. F5 VELOS is a key component of the F5 Application Delivery and Security Platform (ADSP). VELOS relies on a Kubernetes-based platform layer (F5OS) that is tightly integrated with F5 TMOS software. Going to a microservice-based platform layer allows VELOS to provide additional functionality that was not possible in previous generations of F5 BIG-IP platforms. Customers do not need to learn Kubernetes but still get the benefits of it. Management of the chassis will still be done via a familiar F5 CLI, webUI, or API. The additional benefit of automation capabilities can greatly simplify the process of deploying F5 products. A significant amount of time and resources are saved due to automation, which translates to more time to perform critical tasks. F5OS VELOS UI Why is VELOS important? Get more done in less time by using a highly automatable hardware platform that can deploy software solutions in seconds, not minutes or hours. Increased performance improves ROI: The VELOS platform is a high-performance and highly scalable chassis with improved processing power. Running multiple versions on the same platform allows for more flexibility than previously possible. Significantly reduce the TCO of previous-generation hardware by consolidating multiple platforms into one. Key VELOS Use-Cases NetOps Automation Shorten time to market by automating network operations and offering cloud-like orchestration with full-stack programmability Drive app development and delivery with self-service and faster response time Business Continuity Drive consistent policies across on-prem and public cloud and across hardware and software-based ADCs Build resiliency with VELOS’ superior platform redundancy and failover capabilities Future-proof investments by running multiple versions of apps side-by-side; migrate applications at your own pace Cloud Migration On-Ramp Accelerate cloud strategy by adopting cloud operating models and on-demand scalability with VELOS and use that as on-ramp to cloud Dramatically reduce TCO with VELOS systems; extend commercial models to migrate from hardware to software or as applications move to cloud Automation Capabilities Declarative APIs and integration with automation frameworks (Terraform, Ansible) greatly simplifies operations and reduces overhead: AS3 (Application Services 3 Extension): A declarative API that simplifies the configuration of application services. With AS3, customers can deploy and manage configurations consistently across environments. Ansible Automation: Prebuilt Ansible modules for VELOS enable automated provisioning, configuration, and updates, reducing manual effort and minimizing errors. Terraform: Organizations leveraging Infrastructure as Code (IaC) can use Terraform to define and automate the deployment of VELOS appliances and associated configurations. Example json file: Example of running the Automation Playbook: Example of the results: More information on Automation: Automating F5OS on VELOS GitHub Automation Repository Specialized Hardware Performance VELOS offers more hardware-accelerated performance capabilities with more FPGA chipsets that are more tightly integrated with TMOS. It also includes the latest Intel processing capabilities. This enhances the following: SSL and compression offload L4 offload for higher performance and reduced load on software Hardware-accelerated SYN flood protection Hardware-based protection from more than 100 types of denial-of-service (DoS) attacks Support for F5 Intelligence Services VELOS CX1610 chassis VELOS BX520 blade Migration Options (BIG-IP Journeys) Use BIG-IP Journeys to easily migrate your existing configuration to VELOS. This covers the following: Entire L4-L7 configuration can be migrated Individual Applications can be migrated BIG-IP Tenant configuration can be migrated Automatically identify and resolve migration issues Convert UCS files into AS3 declarations if needed Post-deployment diagnostics and health The Journeys Tool, available on DevCentral’s GitHub, facilitates the migration of legacy BIG-IP configurations to VELOS-compatible formats. Customers can convert UCS files, validate configurations, and highlight unsupported features during the migration process. Multi-tenancy capabilities in VELOS simplify the process of isolating workloads during and after migration. GitHub repository for F5 Journeys Conclusion The F5 VELOS platform addresses the modern enterprise’s need for high-performance, scalable, and efficient application delivery and security solutions. By combining cutting-edge hardware capabilities with robust automation tools and flexible migration options, VELOS empowers organizations to seamlessly transition from legacy platforms while unlocking new levels of performance and operational agility. Whether driven by the need for increased throughput, advanced multi-tenancy, the VELOS platform stands as a future-ready solution for securing and optimizing application delivery in an increasingly complex IT landscape. Related Content Cloud Docs VELOS Guide F5 VELOS Chassic System Datasheet F5 rSeries: Next-Generation Fully Automatable Hardware Demo Video
Realtime DoS mitigation with VELOS BX520 Blade
Introduction F5 VELOS is a rearchitected, next-generation hardware platform that scales application delivery performance and automates application services to address many of today’s most critical business challenges. F5 VELOS is a key component of the F5 Application Delivery and Security Platform (ADSP). Demo Video DoS attacks are a fact of life Detect and mitigate large-scale, volumetric network and application-targeted attacks in real-time to defend your businesses and your customers against multi-vector, denial of service (DoS) activity attempting to disrupt your business. DoS impacts include: Loss of Revenue Degradation of Infrastructure Indirect costs often include: Negative Customer Experience. Brand Image DoS attacks do not need to be massive to be effective. F5 VELOS: Key Specifications Up to 6Tbps total Layer 4-7 throughput 6.4 Billion concurrent connections Higher density resources/Rack Unit than any previous BIG-IP Flexible support for multi-tenancy and blade groupings API first architecture / fully automatable Future-proof architecture built on Kubernetes Multi-terabit security – firewall and real-time DoS Real-time DoS Mitigation with VELOS Challenges Massive volume attacks are not required to negatively impact “Goodput”. Shorter in duration to avoid Out of Band/Sampling Mitigation. Using BIG-IP inline DoS protection can react quickly and mitigate in real-time. Simulated DoS Attack 600 Gbps 1.5 Million Connections Per Second (CPS) 120 Million Concurrent Flows Example Dashboard without DoS Attack Generated Attack Flood an IP from many sources 10 Gb/s with 10 Million CPS DoS Attack launched (<2% increase in Traffic) Impact High CPU Consumption: 10M+ new CPS High memory utilization with Concurrent Flows increasing quickly Result Open connections much higher New connections increasing rapidly Higher CPU Application Transaction Failures Enable Network Flood Mitigation Mitigation Applied Enabling the Flood Vector on BIG-IP AFM Device DoS Observe “Goodput” returning to normal in seconds as BIG-IP mitigates the Attack Conclusion Distributed denial of service (DDoS) attacks continue to see enormous growth across every metric. This includes an increasing number and frequency of attacks, average peak bandwidth and overall complexity. As organizations face unstoppable growth and the occurrence of these attacks, F5 provides organizations multiple options for complete, layered protection against DDoS threats across layers 3–4 and 7. F5 enables organizations to maintain critical infrastructure and services — ensuring overall business continuity under this barrage of evolving, and increasing DoS/DDoS threats attempting to disrupt or shut down their business. Related Articles F5 VELOS: A Next-Generation Fully Automatable Platform F5 rSeries: Next-Generation Fully Automatable Hardware Accelerate your AI initiatives using F5 VELOS
F5 BIG-IP SSL Orchestrator and ReversingLabs Integration Guide
Introduction F5 BIG-IP SSL Orchestrator centralizes & manages decryption of SSL/TLS traffic. This enables security and monitoring tools to view the decrypted content and analyze it for threats and other anomalies. SSL Orchestrator removes the burden of decrypting content from your security tools, so they perform better and are more scalable. SSL Orchestrator is a key component of the F5 Application Delivery and Security Platform (ADSP). An integrated F5 and ReversingLabs Spectra Detect ICAP Server solution provides an enterprise-class malware detection and analysis platform while eliminating the blind spots introduced by SSL/TLS-encrypted content as follows: Delivers unmatched speed and scalability Broad Threat and file coverage Industry-leading object size unpacking and analysis Flexible deployment using AMI, OVA, or Kubernetes End-to-End Yara Rule Workflow Seamless secure sandbox connection to Spectra Analyze Deep Cloud Analysis and enrichment reports ReversingLabs Spectra Detect ICAP Server provides comprehensive, enterprise-wide visibility into malicious files and objects, enabling the identification of threats wherever they reside. High-volume, high-speed file unpacking, inspection, and definitive threat classification empower security operations teams with real-time, context-rich intelligence to drive faster and more effective threat detection and response, along with more powerful and precise hunting, so that dangerous malware can no longer hide and dwell within the organization. Demo Video Deployment Prerequisites This guide was tested with the following software versions: F5 BIG-IP version 17.5 SSL Orchestrator version 12.1.5 ReversingLabs Spectra Detect version 5.5.1-24 ReversingLabs Hub version 5.5.1 ReversingLabs Worker version 5.5.1 This article assumes you have SSL Orchestrator configured with a Topology and Service Chain. ReversingLabs Configuration The Spectra Detect Manager, Worker and Hub nodes should be deployed and working. The Hub and Worker need to be members of the same Configuration Group. The Dashboard should look like the following: NOTE: Proceed to the section on “Add the Connector” if the Worker and Hub are already in the same Configuration Group. If they are not in the same Configuration Group you can resolve this from the Central Configuration screen by clicking Add New Group. Give it a name, Hub-Group in this example. Set the Group Type to Hub Group by clicking the down arrow on the right. Set the Primary Host by clicking the down arrow on the right. Enter 1 for the Router ID. Click Add at the bottom Click Confirm Set the Configuration Group to Hub Group Under Appliances select All then Save Click Save and Apply The Hub and the Worker should now be visible Add the ICAP Connector Go back to the Dashboard Click on the Hub appliance On the right select Actions then Connectors Select ICAP Server on the left and then click Enable Connector Optionally configure Max File Size and other settings on this page Specify the REQMOD Block Page URL NOTE: Replace 172.16.60 202 with the IP address of your Spectra Detect Manager Disable the Use TLS option. The port should default to 1344 Click Start Connector Click Yes Back on the Dashboard click the green arrow next to Integrations It should look like the following: NOTE: you can come back later and configure the ICAP Server TLS option SSL Orchestrator Configuration From the SSL Orchestrator Configuration screen select the Services tab then click Add Select the ICAP tab then double click on the Generic ICAP Service Give it a name, RL_SpectraDetect in this example Click the Add button for ICAP Devices Enter the IP address of your ReversingLabs Hub, 172.16.60.201 in this example Click Done Set the Request and Response Modification URI to “spectraconnector” Scroll down then click Save & Next From the Services Chain List screen click on the name of your Service Chain, ServiceChain1 in this example Select the RL_SpectraDetect Service and click the right arrow to move it to the right. It should look like the following Click Save Click OK Click Save & Next Click Deploy Click OK Afterwards it should look like this: Test the Solution Access the internet from a client computer that connects through BIG-IP SSL Orchestrator. Note that the connection to www.f5.com is secure and the certificate has been verified by f5labs.com instead of Entrust, Inc. This indicates that SSL Orchestrator is decrypting and encrypting the connection. Next I will connect to the eicar.org web site which hosts a test virus. I’ll attempt to download the EICAR.TXT file. The test virus is successfully blocked by ReversingLabs! The Analytics Dashboard on the Spectra Detect Manager shows more details about the files processed. Conclusion F5 BIG-IP SSL Orchestrator is a great solution for managing encrypted traffic. Traffic can be selectively steered to one or more security solutions to check for threats. ReversingLabs Spectra Detect works in tandem with SSO Orchestrator to protect Enterprise networks from malicious threats. Related Content Introduction to BIG-IP SSL Orchestrator Integrating Security Solutions with F5 BIG-IP SSL Orchestrator F5 BIG-IP Zero Trust with BIG-IP SSL Orchestrator
Service Extensions with SSL Orchestrator: Advanced Blocking Pages
Introduction Service Extensions are a new programmable capability in F5 BIG-IP SSL Orchestrator (as of F5 BIG-IP 17.0) that allow for customizable behaviors on decrypted HTTP traffic directly from within the Service Chain. SSL Orchestrator is a key component of the F5 Application Delivery and Security Platform (ADSP). In this article you will learn how to download, install, and configure the policy that enables the “Advanced Blocking Pages” Service Extension. Demo Video What are Advanced Blocking Pages? Advanced Blocking Pages allow for easy customization of the block page as well as flexible policy options to trigger specific block pages. This Service Extension creates a Service that will return a block page when placed into a Service Chain. It can also apply the iRule logic to dynamically inject the contents of a blocking page. Deployment Prerequisites F5 BIG-IP version 17.1.x SSL Orchestrator version 11.1+ This article assumes you have an SSL Orchestrator configured with a Topology and Service Chain. Advanced Blocking Pages Service Extension Installation The information below is from the GitHub repository for the Advanced Blocking Pages Service Extension (click here for a direct link). It includes an installer to create all the necessary objects. Download the installer: curl -sk https://raw.githubusercontent.com/f5devcentral/sslo-service-extensions/refs/heads/main/advanced-blocking-pages/advanced-blocking-pages-installer.sh -o advanced-blocking-pages-installer.sh CLI output: Make the script executable: chmod +x advanced-blocking-pages-installer.sh CLI output: Export the BIG-IP username and password: export BIGUSER='admin:password' CLI output: Note: replace “password” with your actual BIG-IP admin password Run the script to create all the SaaS Tenant Isolation objects: ./advanced-blocking-pages-installer.sh CLI output: The installer creates a new Inspection Service named "ssloS_F5_Advanced-Blocking-Pages". Add this Inspection Service to any Service Chain that can receive decrypted HTTP traffic. Service Extension Services will only trigger on decrypted HTTP, so can be inserted into Service Chains that may also see TLS bypass traffic (not decrypted). SSL Orchestrator will simply bypass this Service for anything that is not decrypted HTTP. After following the steps above, the SSL Orchestrator screen should look like this: Customizing Functionality To customize the functionality of the Blocking Pages we’ll start by editing an iRule. Navigate to Local Traffic > iRules > iRule List Click on the iRule named “advanced-blocking-pages-rule” (you may need to expand the iRule List) To enable the Advanced Blocking Pages, set the value for “GLOBAL_BLOCK” from 0 to 1. Click Update. NOTE: We’ll go over the other customization options later in this article. Move the Advanced-Blocking-Pages Service to a Service Chain Go to the SSL Orchestrator Configuration screen Click Service Chains then Add NOTE: For testing purposes, it is recommended to create a new Service Chain and add the Advanced-Blocking-Page Service to it Give it a name, “AdvancedBlocking” in this example. Select the ssloS_F5_Advanced-Blocking-Pages Service and click the arrow to move it to the right Click Deploy Click OK Edit the Security Policy From the Configuration screen, select Security Policies then click the policy you want to edit, “L3_Outbound” in this example. Click Add to add a Rule Give the Rule a name, “BlockThreats” in this example Configure the Rule Conditions by selecting Category Lookup (All) Select the Categories you wish to Block by clicking in the “Click to select” field Select all Malware-related categories These are all the Malware-related categories: Advanced Malware Command and Control Advanced Malware Payloads Malicious Embedded Link Malicious Embedded iFrame Malicious Web Sites Mobile Malware You may want to consider adding the following Categories, too: Spyware and Adware Suspicious NOTE: For testing purposes, it would be safer to add a category like “Alcohol and Tobacco” to the above rule in order to test its efficacy. Set the Action to Allow (this is counterintuitive) Set the SSL Proxy Action to Intercept Set the Service Chain to the one created previously, “AdvancedBlocking” Click OK The Security Policy should look like this: Click Deploy Click Deploy Click OK Test the Advanced Blocking Page Assuming you have added the “Alcohol and Tobacco” Category to the Security Policy, go to a client computer and test it now. An attempt to view the Products page on www.marlboro.com results in the following: Note: remember to remove the “Alcohol and Tobacco” category from the Security Policy. Customizing the Blocking Page First, you need an html file to use as the custom Blocking Page. You can use a sample file from the GitHub repository. Expand the folder “blocking-page-samples” and click “blocking-page-sample1.html”. Click the Download button on the right. To Customize the Blocking Page, go to System > File Management > iFile List > Import Choose the Blocking Page sample file in your Downloads folder. Choose Overwrite Existing, then click Import. Test the Blocking Page again and it should look like the following: Injecting Dynamic Messages To inject a dynamic message in the block page, edit the “advanced-blocking-pages-rule” iRule. Find “set static::GLOBAL_BLOCK_MESSAGE” in the iRule and replace all the text within the quotation marks: Click Update when done Test the Blocking Page again and it should look like the following: Handling Server-Side Certificate Errors SSL Orchestrator can also be customized to handle different server-side certificate validation errors. To configure this, start by editing the SSL Configuration. Click the Edit icon Click Show Advanced Settings Near the bottom, set Expire Certificate Response and Untrusted Certificate Authority from Drop to Mask. Click Save & Next when done. The Mask option tells SSL Orchestrator to send a good/valid certificate to the client when these certificate errors occur. This allows a custom blocking page to be presented to the client. Click OK Click Deploy Click OK Next, edit the Interception Rule for this Topology Click the Edit icon In the Resources section near the bottom, move the “ssl-tls-verify-rule” from Available to Selected. Click Save & Next Click Deploy Click OK NOTE: The blocking page iRule (when GLOBAL_BLOCK is 0) will read this context array variable and trigger the blocking page if the certificate verification code is not ‘ok’. It also injects the verification code string into the page. You can test this using the site, https://badssl.com Under Certificate, try “expired” and “self-signed” Example of Expired Certificate: Example of Self-Signed Certificate: Handling Custom Blocking Page Triggers The included iRule is intentionally sparse to include the two primary blocking page use cases (global blocking and server-side certificate validation errors): when HTTP_REQUEST { if { $static::GLOBAL_BLOCK } { call GEN_BLOCK_PAGE ${static::GLOBAL_BLOCK_MESSAGE} event disable all } else { sharedvar ctx if { ( [info exists ctx(tlsverify)] ) and ( $ctx(tlsverify) ne "ok" ) } { call GEN_BLOCK_PAGE "This request has been blocked due to a server side TLS issue: <br /></br>[string toupper $ctx(tlsverify)]" event disable all } } } To customize this for additional triggers, add iRule logic inside the “else” block as required: if { some-condition } { call GEN_BLOCK_PAGE "message to send into blocking page `receive_msg` variable" event disable all } Conclusion SSL Orchestrator Advanced Blocking Pages allow for easy customization of the block page as well as flexible policy options to trigger specific block pages. Related Content Service Extensions with SSL Orchestrator SaaS Tenant Isolation Service Extensions with SSL Orchestrator User Coaching of AI Related Content SSL Orchestrator Service Extensions: DoH Guardian Office 365 Tenant Restrictions Introduction to BIG-IP SSL Orchestrator Integrating Security Solutions with F5 BIG-IP SSL Orchestrator
F5 BIG-IQ What's New in v8.4.0?
Introduction F5 BIG-IQ Centralized Management, a key component of the F5 Application Delivery and Security Platform (ADSP), helps teams maintain order and streamline administration of BIG-IP app delivery and security services. In this article I’ll highlight some of the key features in the BIG-IQ v8.4.0 release. Demo Video Upgrading to BIG-IQ Version 8.4 Supported upgrade paths You can upgrade from BIG-IQ 8.x.0 to BIG-IQ 8.4.0 version. New Features in BIG-IQ Version 8.4.0 BIG-IQ Support for AWS IMDSv2 AWS introduced a token-based Instance Metadata Service API (IMDSv2) that enhances security, requiring authentication for metadata access. Previously, BIG-IQ used the older IMDSv1, which does not require authentication and remained the default for launching instances. Without IMDSv2 support, instances that require this version could not be licensed, relicensed, or used for metadata-based features. For BIG-IQ, this limitation affected SSH key authentication and license activation, as its API calls to EC2 instances like m5.xlarge failed due to missing authentication token implementation. This release adds IMDSv2 support, which allows BIG-IQ to work properly in AWS environments that require IMDSv2. Instances can now be licensed, metadata-based features are functional, and SSH key authentication works well, ensuring full compatibility with AWS security standards. BIG-IQ Support for BIG-IP 17.5.0 BIG-IQ provides full support for BIG-IP 17.5.0, ensuring seamless discovery and compatibility across all modules. Users who upgrade to the BIG-IP 17.5.0 version retain the same functionality without disruptions, maintaining consistency in their management operations. Interoperability Support for BIG-IP Access 17.5.0 BIG-IQ supports the creation, import, modification, and deployment of BIG-IP Access 17.5.0 version configurations. This update ensures full interoperability between BIG-IQ and BIG-IP 17.5.0 for managing access policies. Support for AS3 Compatibility with BIG-IQ 8.4.0 With this release, the AS3 schema is fully compatible with BIG-IQ 8.4.0, enabling seamless deployment of applications using Application Templates through the BIG-IQ user interface. Venafi 22.x, 23.x, and 24.x Support for BIG-IQ BIG-IQ now integrates with Venafi 22.x, 23.x, and 24.x versions that enable centralized certificate lifecycle management for BIG-IP devices. This update introduces support for AES256 encryption, enhancing security beyond the existing OpenSSL algorithm. By automating certificate management, this integration eliminates the manual and time-consuming process of maintaining certificates across various BIG-IP devices. Supported BIG-IP Services BIG-IP 17.5.0 support BIG-IQ now includes support for the following services running on BIG-IP version 17.5.0: Access Policy Manager (APM) Advanced Firewall Manager (AFM) Application Delivery Controller (ADC) Web Application Security (ASM / WAF) Fraud Protection Service (FPS) Statistics and Monitoring Application Services Extension 3 (AS3) support BIG-IQ supports Application Services Extension 3 (AS3) version 3.53.0 and later. Declarative Onboarding (DO) support BIG-IQ supports Declarative Onboarding (DO) version 1.29 and later. All objects up to 17.5.0 are supported. BIG-IP SSL Orchestrator (SSLO) support BIG-IQ now supports SSLO RPM version 12.0. You can now discover, import, configure, and deploy configurations for managed BIG-IP devices running this RPM version. To learn more about features supported in this SSLO RPM version, refer to the F5 SSL Orchestrator Release Notes version 17.5.0-12.0. F5OS Platform Management Support to display the VELOS device information You can now see the details such as Model type, Serial Number, Platform Version, and Blade Configuration for the VELOS platform Support to export F5OS Inventory details You can now export the F5OS platform or devices inventory information into a .CSV format file regardless of the status or assignment. Support to delete remote backup You can now delete backup files stored in the F5OS rSeries or VELOS platforms. This will also delete the partition backup files, when you delete the local F5OS backup file in the BIG-IQ. Support IPv6 address for F5OS VELOS partition This release now supports IPv6 addresses for F5OS VELOS partitions. Export F5OS backups to the external server You can now store a copy of the F5OS backup remotely on an SCP or SFTP server. BIG-IQ License Management License pool properties enhancements The License Pool UI was enhanced to include the following: You can now select the number of registration keys displayed per page under the Registration Keys section. You can now view information about the Service Check Date, Max allowed Throughput Rate, Max Allowed VE Cores, and Permitted SW Version of the Registration keys. All licenses usage report You can now generate a CSV report that meticulously includes all licenses from the selected group. F5 Advanced Web Application Firewall (On-Box) service as an SSL Orchestrator Service BIG-IP SSL Orchestrator (SSLO) Support BIG-IQ 8.4.0 supports configuring and deploying Advanced WAF profiles within the SSL Orchestrator interface for all topologies. This update makes it easier to set up and manage Advanced WAF profiles. You can set them up directly within SSL Orchestrator. In addition, you can also validate the service as a service chain object. For this setup, you should have Application Security Manager (ASM) and Advanced Web Application Firewall (WAF) profiles set up, licensed, and provisioned on BIG-IQ. Security Policy enhancements SSL Orchestrator Security Policy now has the following enhancements while creating a new rule: A new drop-down list contains the "is" and "is not" operators to compare or negate your specified condition. A new condition, "IP Protocol," lets you match SSL traffic based on Internet Protocols such as TCP and UDP. With the new "Bypass (Client Hello)" setting in SSL Proxy Action, you can bypass traffic on certain conditions without triggering the TLS handshake. However, the SSL conditions such as "Server Certificate (Issuer DN, SANs, Subject DN)" and "Category Lookup (All)" do not have this setting enabled. In a custom security policy, you can now redirect the traffic to a remote URL for the specified conditions (matches). BIG-IQ Centralized Management Compatibility Matrix Refer to Knowledge Article K34133507 BIG-IQ Virtual Edition Supported Platforms BIG-IQ Virtual Edition Supported Platforms provides a matrix describing the compatibility between the BIG-IQ VE versions and the supported hypervisors and platforms. Conclusion Managing hundreds or thousands of apps across a hybrid, multicloud environment is complex. Your apps must be always available and secure, no matter where they're deployed, creating a need for a new kind of Application Delivery Controller (ADC)—one that provides holistic, unified visibility and management of apps, services, and infrastructure everywhere. F5® BIG-IQ® Centralized Management reduces complexity and administrative burden by providing a single platform to create, configure, provision, deploy, upgrade, and manage F5® BIG-IP® security and application delivery services. Related Content BIG-IQ 8.4.0 Product Documentation Boosting BIG-IP AFM Efficiency with BIG-IQ: Technical Use Cases and Integration Guide Blog: Five Key Benefits of Centralized Management
BIG-IP Next Edge Firewall CNF for Edge workloads
Introduction The CNF architecture aligns with cloud-native principles by enabling horizontal scaling, ensuring that applications can expand seamlessly without compromising performance. It preserves the deterministic reliability essential for telecom environments, balancing scalability with the stringent demands of real-time processing. More background information about what value CNF brings to the environment, https://community.f5.com/kb/technicalarticles/from-virtual-to-cloud-native-infrastructure-evolution/342364 Telecom service providers make use of CNFs for performance optimization, Enable efficient and secure processing of N6-LAN traffic at the edge to meet the stringent requirements of 5G networks. Optimize AI-RAN deployments with dynamic scaling and enhanced security, ensuring that AI workloads are processed efficiently and securely at the edge, improving overall network performance. Deploy advanced AI applications at the edge with the confidence of carrier-grade security and traffic management, ensuring real-time processing and analytics for a variety of edge use cases. CNF Firewall Implementation Overview Let’s start with understanding how different CRs are enabled within a CNF implementation this allows CNF to achieve more optimized performance, Capex and Opex. The traditional way of inserting services to the Kubernetes is as below, Moving to a consolidated Dataplane approach saved 60% of the Kubernetes environment’s performance The F5BigFwPolicy Custom Resource (CR) applies industry-standard firewall rules to the Traffic Management Microkernel (TMM), ensuring that only connections initiated by trusted clients will be accepted. When a new F5BigFwPolicy CR configuration is applied, the firewall rules are first sent to the Application Firewall Management (AFM) Pod, where they are compiled into Binary Large Objects (BLOBs) to enhance processing performance. Once the firewall BLOB is compiled, it is sent to the TMM Proxy Pod, which begins inspecting and filtering network packets based on the defined rules. Enabling AFM within BIG-IP Controller Let’s explore how we can enable and configure CNF Firewall. Below is an overview of the steps needed to set up the environment up until the CNF CRs installations [Enabling the AFM] Enabling AFM CR within BIG-IP Controller definition global: afm: enabled: true pccd: enabled: true f5-afm: enabled: true cert-orchestrator: enabled: true afm: pccd: enabled: true image: repository: "local.registry.com" [Configuration] Example for Firewall policy settings apiVersion: "k8s.f5net.com/v1" kind: F5BigFwPolicy metadata: name: "cnf-fw-policy" namespace: "cnf-gateway" spec: rule: - name: allow-10-20-http action: "accept" logging: true servicePolicy: "service-policy1" ipProtocol: tcp source: addresses: - "2002::10:20:0:0/96" zones: - "zone1" - "zone2" destination: ports: - "80" zones: - "zone3" - "zone4" - name: allow-10-30-ftp action: "accept" logging: true ipProtocol: tcp source: addresses: - "2002::10:30:0:0/96" zones: - "zone1" - "zone2" destination: ports: - "20" - "21" zones: - "zone3" - "zone4" - name: allow-us-traffic action: "accept" logging: true source: geos: - "US:California" destination: geos: - "MX:Baja California" - "MX:Chihuahua" - name: drop-all action: "drop" logging: true ipProtocol: any source: addresses: - "::0/0" - "0.0.0.0/0" [Logging & Monitoring] CNF firewall settings allow not only local logging but also to use HSL logging to external logging destinations. apiVersion: "k8s.f5net.com/v1" kind: F5BigLogProfile metadata: name: "cnf-log-profile" namespace: "cnf-gateway" spec: name: "cnf-logs" firewall: enabled: true network: publisher: "cnf-hsl-pub" events: aclMatchAccept: true aclMatchDrop: true tcpEvents: true translationFields: true Verifying the CNF firewall settings can be done through the sidecar container kubectl exec -it deploy/f5-tmm -c debug -n cnf-gateway – bash tmctl -d blade fw_rule_stat context_type context_name ------------ ------------------------------------------ virtual cnf-gateway-cnf-fw-policy-SecureContext_vs rule_name micro_rules counter last_hit_time action ------------------------------------ ----------- ------- ------------- ------ allow-10-20-http-firewallpolicyrule 1 2 1638572860 2 allow-10-30-ftp-firewallpolicyrule 1 5 1638573270 2 Conclusion To conclude our article, we showed how CNFs with consolidated data planes help with optimizing CNF deployments. In this article we went through the overview of BIG-IP Next Edge Firewall CNF implementation, sample configuration and monitoring capabilities. More use cases to cover different use cases to be following. Related content F5BigFwPolicy BIG-IP Next Cloud-Native Network Functions (CNFs) CNF Home
