How to achieve hiding internal URLs and HTTP dynamic redirection with F5 XC HTTP Load Balancer
This is a comprehensive list of the XC options to change the Host or URL values in the requests and to trigger dynamic redirections. XC HTTP LB basic rewrite options By default, XC with or without a route rewrites the Host value of the client’s http request to the origin server’s FQDN name in the origin pool (only if the origin server is FQDN, not IP address). Under the XC origin pool, you can control the SNI selection for the origin pool. Sometimes having not the correct SNI could generate 400 errors for nginx origin web servers, for example. XC HTTP LB Host 3xx Redirection Under the XC HTTP LB route, you can configure host redirection even for non standard port. If you don't configure an explicit path option, then XC will auto-redirect and keep the original URL. I found this not something well-explained. For basic HTTP to HTTPS redirection you can easily enable it under and HTTPS LB and the only issue is it assumes that HTTP is on port 80, so for custom redirection from HTTP on port other than 80 you need to use the below methods. You can even configure the HTTP LB to listen on ports other than the default ones (80 for HTTP or 443 for HTTPS) and to redirect to also not custom ports. In some cases you will need to add the FQDN domain with the non-custom port. Some web browsers send traffic to not custom ports with the port in the host name and this could cause XC not to match the traffic. To test this with "curl" that can even be directed with the "resolve" option to HTTP LB that the public DNS still does not direct to it. XC HTTP LB internal URL Rewrite Under the XC HTTP Route advanced options, you can find the Request URL rewrite can match on prefix or even a regex to be used. This in some cases helps for apps that don't handle very well 3xx redirects (mobile apps are one such case) as for example "/test" URL is auto-changed to "/" otherwise 404 code would be seen if the page does not exist! The rewrite option seems particularly useful for Customer Edge (CE) deployments that are inside the customer networks RE > CE traffic where the HTTP LB is on the RE and the origin servers in the origin pool are on the CE and the SSL/IPSEC tunnel between RE and CE is used to stich things. Sometimes a rewrite of the response is needed, as for example to change the HTML response image urls to the new ones. In this case, Nginx containers can be used with XC Virtual Kubernetes (v8ks) that will offer this advanced function that I have described in article F5 XC vk8s workload with Open Source Nginx | DevCentral XC Custom Route Under Multi-Cloud App Connect, you can create custom route objects that can also do redirects or rewrite request URLs. The main benefit is that many HTTP LB can use the custom routes and can attach custom Request/Response headers or Cookies, even on Redirect routes that the Simple Routes that are directly created under the HTTP LB can't. This can be useful for some logic in mobile apps or custom non browser Agents like API clients. Summary The XC Cloud provides many options. In the future, you might see things like TCL iRule scripts that will offer advanced changes and rewrites of even HTTP request and response bodies without adding Nginx containers. So, keep checking release notes at Release Changelogs | F5 Distributed Cloud Technical Knowledge to not miss anything new that is released! Useful Links: Layer 7 Content Routing in F5 XC | DevCentral How to setup path-based routing or application load-balancing – F5 Distributed Cloud Services How to do an URL redirection? – F5 Distributed Cloud Services How do I configure a redirection with a URL that contains path and query parameters? Article DetailBIG-IP Next for Kubernetes, addressing today’s enterprise challenges
Enterprises have started adopting Kubernetes (K8s)—not just cloud service providers—as it offers strategic advantages in agility, cost efficiency, security, and future-proofing. Cloud Native Functions account for around 60% TCO savings Easier to deploy, manage, maintain, and scale. Easier to add and roll out new services. Kubernetes complexities With the move from traditional application deployments to microservices and containerized services, some complexities were introduced, Networking Challenges with Kubernetes Default Deployments Kubernetes networking has some problems when using default settings. These problems can affect performance, security, and reliability in production environments. Core Networking Challenges Flat Network Model All pods can communicate with all other pods by default (east-west traffic) No network segmentation between applications Potential security risks from excessive inter-pod communication Service Discovery Limitations DNS-based service discovery has caching behaviors that can delay updates No built-in load balancing awareness (can route to unhealthy pods during updates) Limited traffic shaping capabilities (all requests treated equally) Ingress Challenges No default ingress controller installed Multiple ingress controllers can conflict if not properly configured SSL/TLS termination requires manual certificate management Network Policy Absence No network policies applied by default (allow all traffic). Difficult to implement zero-trust networking principles No default segmentation between namespaces DNS Issues CoreDNS default cache settings may not be optimal. Pod DNS policies may not match application requirements. Nodelocal DNS cache not enabled by default Load-Balancing Problems Service `ClusterIP` is the default (no external access). NodePort` services can conflict on port allocations. Cloud provider load balancers can be expensive if overused CNI (Container Network Interface) Considerations Default CNI plugin may not support required features Network performance varies significantly between CNI choices IP address management challenges at scale Performance-Specific Issues kube-proxy inefficiencies Default iptables mode becomes slow with many services IPVS (IP Virtual Server) mode requires explicit configuration Service mesh sidecars can double latency Pod Network Overhead Additional hops for cross-node communication Encapsulation overhead with some CNI plugins No QoS guarantees for network traffic Multicluster Communication No default solution for cross-cluster networking Complex to establish secure connections between clusters Service discovery doesn’t span clusters by default Security Challenges No default encryption between pods No default authentication for service-to-service communication. All namespaces are network-accessible to each other by default. External traffic can bypass ingress controllers if misconfigured. These challenges highlight why most production Kubernetes deployments require significant, complex customization beyond the default configuration. Figure 1 shows those workarounds being implemented and how complicated our setup would be, with multiple add-ons required to overcome Kubernetes limitations. In the following section, we are exploring how BIG-IP Next for Kubernetes simplifies and enhances application delivery and security within Kubernetes environment. BIG-IP Next for Kubernetes Introducing BIG-IP Next for Kubernetes not only reduces complexity, but leverages the main networking components to the TMM pods rather than relying on the host server. Think of where current network functions are applied, it’s the host kernel. Whether you are doing NAT or firewalling services, this requires intervention by the host side, which impacts the zero-trust architecture and traffic performance is limited by default kernel IP and routing capabilities. Deployment overview Among the introduced features in 2.0.0 Release API GW CRs (Custom Resources). F5 IPAM Controller to manage IP addresses for Gateway resource. Seamless firewall policy integration in Gateway API. Ingress DDoS protection in Gateway API. Enforced access control for Debug and QKView APIs with Admin Token. In this section, we explore the steps to deploy BIG-IP Next for Kubernetes in your environment, Infrastructure Using different flavors depending on your needs and lab type (demo or production), for labs microk8s, k8s or kind, for example. BIG-IP Next for Kubernetes helm, docker are required packages for this installation. Follow the installation guide BIG-IP Next for Kubernetes current 2.0.0 GA release is available. For the desired objective in this article, you may skip the Nvidia DOCA (that's the focus of the coming article) and go directly for BIG-IP Next for Kubernetes. Install additional CRDs Once the licensing and core pods are ready, you can move to adding additional CRDs (Customer Resources Definition). BIG-IP Next for Kubernetes CRDs BIG-IP Next for Kubernetes CRDs Custom CRDs Install F5 Use case Custom Resource Definitions Related Content BIG-IP Next for Kubernetes v2.0.0 Release Notes System Requirements BIG-IP Next for Kubernetes CRDs BIG-IP Next for Kubernetes BIG-IP Next SPK: a Kubernetes native ingress and egress gateway for Telco workloads F5 BIG-IP Next for Kubernetes deployed on NVIDIA BlueField-3 DPUs BIG-IP Next for Kubernetes running in Amazon EKS
Securing Modern Applications with BIG-IP Advanced WAF
In today’s digital landscape, applications are the engine of business success. They drive customer engagement, innovation, and operational agility. But with this reliance on applications comes an expanding attack surface, exposing organizations to increasingly sophisticated cyber threats. To stay ahead, businesses need a security solution that’s both comprehensive and flexible—one that’s built to secure, deliver, and optimize applications in a rapidly evolving environment. That’s where BIG-IP Advanced WAF comes in. BIG-IP Advanced WAF at a Glance BIG-IP Advanced WAF delivers sophisticated controls that mitigate automated application attacks, protect against known and zero-day vulnerabilities, and further detect and minimize the risk of attacks using F5 intelligent security threat services. In addition to standard app security capabilities, BIG-IP Advanced WAF offers protection for sensitive web form data, such as login credentials, app-layer denial of service (DoS) protection, defense against targeted threat campaigns, proactive bot defense, and fine-grained controls for API security Advanced WAF includes key features like: Mitigating Application Vulnerabilities: Proactively identifying and addressing OWASP Top 10 risks like injection attacks, cross-site scripting (XSS), and more. Preventing Malicious Bots: Distinguishing legitimate users from malicious automation and applying tailored mitigations. Behavioral DoS Protection: Detecting and stopping volumetric and application-layer denial-of-service attacks before they disrupt services. API Discovery and Security: Automatically discovering APIs and integrating protections specifically designed to secure API traffic. Declarative APIs for CI/CD Integration: Integrating WAF functionality into DevOps pipelines to secure applications from the start. Want to see these capabilities in action? Check out the demo, embedded below. Conclusion BIG-IP Advanced WAF delivers a powerful, modular approach to web application and API security. With advanced tools to mitigate vulnerabilities, stop malicious bots, prevent denial-of-service attacks, and secure APIs, coupled with automation capabilities to streamline workflows, BIG-IP helps organizations protect their critical assets in an increasingly complex threat landscape. By combining world-class protection with adaptive learning and declarative APIs, BIG-IP doesn’t just safeguard applications—it empowers businesses to stay agile, scalable, and secure. It’s the ideal solution for organizations looking to optimize their security posture while preparing for future challenges. F5 Related Content: Advanced WAF Product Page F5 Named a Leader in the IDC MarketScape: Worldwide Web Application and API Protection Enterprise Platforms 2024 Vendor Assessment Declarative Advanced WAF policy lifecycle in a CI/CD pipeline Demo Guide: F5 Hybrid and Multi-cloud Security Architectures: One WAF Engine, Total Flexibility (Automation)
Will the F5 BIG-IP DDoS Hybrid Defender(DHD) be available on a platform like F5OS/rSeries
Hello Everyone, Will the F5 BIG-IP DDoS Hybrid Defender be available on a platform like F5OS/rSeries? The current appliances are called Herculon iSeries (End of Sale announcement for Herculon DDoS Hybrid Defender, Herculon SSL Orchestrator, and Herculon iSeries platforms) so I wonder about Herculon rSeries . I also think it will be based on 5xx or 10xx series because Virtual wire is supported only on F5 r5000/r10000 and this feature is heavily used by DHD ? Network SettingsIntroducing F5 Distributed Cloud Web App Scanning
F5 Distributed Cloud Web App Scanning is a powerful and proactive solution for discovering security vulnerabilities in web applications and APIs across distributed and dynamic environments. With its automation, scalability, detailed reporting, and seamless integration into the broader F5 security ecosystem, it’s a valuable tool for safeguarding modern applications from vulnerabilities and ensuring compliance with regulatory standards.
F5 BIG-IQ What's New in v8.4.0?
Introduction Effective management—orchestration, visibility, and compliance—relies on consistent app services and security policies across on-premises and cloud deployments. Easily control all your BIG-IP devices and services with a single, unified management platform, F5® BIG-IQ®. 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
A Guide to F5 Volumetric (Routed) DDoS Protection in F5 Distributed Cloud
Introduction F5 Volumetric (Routed) DDoS protection is a service in F5 Distributed Cloud (F5 XC) available for standard deployment and emergency use. F5 has over 100 engineers in its incident response team and 24/7 dedicated SOC analysts in 3 security operations centers around the world. This means F5 can help with the quick detection, mitigation, and resolution of Layer3-4 routed DDoS attacks. F5 Volumetric DDoS Protection stands out for several key reasons, especially for enterprises needing fully managed, hybrid, and multicloud-based DDoS mitigation with human-led and AI-assisted support. Here’s some of the ways Volumetric DDoS protection with F5 stands out: Fully Managed 24/7 Security Operations Center (SOC) F5’s SOC continuously monitors traffic for DDoS attacks in real time. Unlike purely automated solutions, human analysts intervene to fine-tune attack mitigation. The SOC provides expert-led response to mitigate complex or evolving threats. Hybrid Deployment Flexibility Cloud-based, always-on, or on-demand models for different use cases. Integrates with on-prem F5 BIG-IP solutions for a hybrid defense strategy. Helps reduce false positives by fine-tuning security policies. Advanced Attack Detection & AI-driven Mitigation Uses behavioral analytics to differentiate between legitimate traffic and attacks. Mitigates volumetric, application-layer, and multi-vector attacks. AI-assisted rules dynamically adapt to new attack patterns. Large-Scale Scrubbing Capacity Global scrubbing centers prevent volumetric DDoS attacks from overwhelming networks. Reduces the risk of downtime by filtering malicious traffic before it reaches critical infrastructure. F5 blocks volumetric DDoS attacks by denying offending /24 prefixes (via BGP) the ability to route to the Distributed Cloud scrubbing centers. (reference DevCentral) API-Driven and Customizable Security Policies Offers API integration for automated DDoS mitigation and security orchestration. Supports custom policies to protect specific applications from targeted attacks. Enterprise-Grade Support & Compliance Designed for large enterprises, financial institutions, and high-security industries. Meets compliance standards such as PCI DSS, GDPR, and SOC 2. Backed by F5’s global threat intelligence network. Logging & Observability Recently introduced is the capability to observe security events using external handlers via the Global Log Receiver (GLR) service. Organizations can use AWS S3 buckets, HTTP(s) servers, Datadog, Splunk, AWS CloudWatch, Azure Event Hubs and Blog Storage, Google Cloud Platform (GCP), Kafka Receiver, NewRelic, IBM QRadar, and SumoLogic, to store Distributed Cloud events. Then, they can use any platform to watch DDoS and other security events. If you’re curious how Distributed Cloud events look using ELK (Elasticsearch, Logstash, and Kibana), including how to set it up, see this related article in DevCentral. To configure Distributed Cloud to send events from Global Log Receiver, log in to the Distributed Cloud console and navigate to Shared Configuration > Manage > Global Log Receiver. Add a new item, and ensure the following: Log Type: Security Events Log Message Selection: Select logs from all namespaces For this example, I use Distributed Cloud App Connect to securely deliver events to an instance of ELK Stack running on AWS. To deliver the events locally with internal networking between Distributed Cloud and ELK Stack, I use a Customer Edge (CE) appliance, also in AWS. Having the CE deployed locally provides a secure endpoint with only local routing in the AWS VPC. ➡️ See the following documentation for how to deploy a CE in AWS. Next is to use App Connect with an HTTP Load Balancer. In this case, the origin pool is my ELK Stack receiver, and I’ve configured ELK to receive events over HTTP. Because I’ve configured the HTTP Load Balancer to be publicly available on the Internet to accept traffic from the Global Log Receiver, a Service Policy has been configured to restrict access to specific IP ranges. Although not shown, only traffic from the F5 Global Log Receiver designated IP ranges is allowed to access this load balancer. ➡️ See the following Allowlist reference documentation to learn which IP addresses to allow. To receive and process events in ELK, I’ve configured the following for logstash: root@3c99db3fa334:/etc/logstash/conf.d# cat 50-f5xc-logs.conf input { http { port => 8080 } } filter { json { source => "message" } } output { elasticsearch { hosts => ["localhost"] index => "f5xc-logs-%{+YYY.MM.dd}" } } In the ELK console, new messages are visible under Analytics > Discover. With messages arriving from GLR, we can now see many of the fields becoming searchable in the “message_parsed” hierarchy. Volumetric (Routed) DDoS events appear in the field “sec_event_type” with value “routed_ddos_sec_event”. The following alert and mitigation messages may be classified and searched as follows: New ongoing alert msg = “alert created” no “alert_ended_at” field present New and already completed alert msg = “alert created” alert_ended_at field present Completed ongoing alert msg = “alert completed” alert_started_at field present alert_ended_at field present New ongoing mitigation msg = “mitigation created” mitigation_ongoing = true no “mitigation_stop_time” field present New and already-completed mitigation msg = “mitigation created and completed” mitigation_ongoing = false migitation_stop_time field present Completed mitigation msg = “mitigation completed” mitigation_ongoing = false “mitigation_stop_time” field present Putting it all together in ELK, it’s easy to visualize each routed_ddos_sec_event with a filtered dashboard. Using the pie visual below allows security admins to decide what type of attacks have happened and whether any are still occurring. The dashboard visual can be added to other existing security dashboards in Kibana to provide a complete and robust overview of your security posture. Demo The following video further illustrates the capabilities of Volumetric (Routed) DDoS protection in Distributed Cloud. In it, I walk through the different ways protection can be activated and what some of the mitigation events and alerts look like in the console. 🎥 YouTube: https://youtu.be/jYiqog_tz2I Conclusion F5 Volumteric (Routed) DDoS protection combines integrated services to provide core-protect, auto-mitigation, security-analyst-initiated mitigations, and advanced deep packet inspection and filtering to provide the best protection available for Layer-3 and Layer-4 routed networking. Adding routed DDoS to networks is a simple onboarding process. F5 also provides emergency DDoS mitigation for customers who are actively being attacked. Observing DDoS attacks is not only available in the Distributed Cloud console but is also available directly in your monitoring platform of choice when using Global Log Receiver. Additional Resources 🎥 YouTube: Tour of Routed (Layer3 & Layer4) DDoS Protection in F5 Distributed Cloud How I did it - "Remote Logging with the F5 XC Global Log Receiver and Elastic" Deploy Secure Mesh Site v2 in AWS (ClickOps) Firewall and Proxy Server Allowlist Reference How To: Configure Global Log Receiver
