F5 XC Distributed Cloud HTTP Header/Cookie manipulations and using the client ip/user headers
1 . F5 XC distributed cloud HTTP Header manipulations In the F5 XC Distributed Cloud some client information is saved to variables that can be inserted in HTTP headers similar to how F5 Big-IP saves some data that can after that be used in a iRule or Local Traffic Policy. By default XC will insert XFF header with the client IP address but what if the end servers want an HTTP header with another name to contain the real client IP. Under the HTTP load balancer under "Other Options" under "More Options" the "Header Options" can be found. Then the the predefined variables can be used for this job like in the example below the $[client_address] is used. A list of the predefined variables for F5 XC: https://docs.cloud.f5.com/docs/how-to/advanced-security/configure-http-header-processing There is $[user] variable and maybe in the future if F5 XC does the authentication of the users this option will be insert the user in a proxy chaining scenario but for now I think that this just manipulates data in the XAU (X-Authenticated-User) HTTP header. 2. Matching of the real client ip HTTP headers You can also match a XFF header if it is inserted by a proxy device before the F5 XC nodes for security bypass/blocking or for logging in the F5 XC. For User logging from the XFF Under "Common Security Controls" create a "User Identification Policy". You can also match a regex that matches the ip address and this is in case there are multiple IP addresses in the XFF header as there could have been many Proxy devices in the data path and we want see if just one is present. For Security bypass or blocking based based on XFF Under "Common Security Controls" create a "Trusted Client Rules" or "Client Blocking Rules". Also if you have "User Identification Policy" then you can just use the "User Identifier" but it can't use regex in this case. I have made separate article about User-Identification F5 XC Session tracking and logging with User Identification Policy | DevCentral To match a regex value in the header that is just a single IP address, even when the header has many ip addresses, use the regex (1\.1\.1\.1) as an example to mach address 1.1.1.1. To use the client IP address as a source Ip address to the backend Origin Servers in the TCP packet after going through the F5 XC (similar to removing the SNAT pool or Automap in F5 Big-IP) use the option below: The same way the XAU (X-Authenticated-User) HTTP header can be used in a proxy chaining topology, when there is a proxy before the F5 XC that has added this header. Edit: Keep in mind that in some cases in the XC Regex for example (1\.1\.1\.1) should be written without () as 1\.1\.1\.1 , so test it as this could be something new and I have seen it in service policy regex matches, when making a new custom signature that was not in WAAP WAF XC policy. I could make a seperate article for this 🙂 XC can even send the client certificate attributes to the backend server if Client Side mTLS is enabled but it is configured at the cert tab. 3. F5 XC distributed cloud HTTP Cookie manipulations. Now you can overwrite the XC cookie by keeping the value but modifying the tags and this is big thing as before this was not possible. When combined with cookies this becomes very powerful thing as you can match on User-Agent header and for Mozilla for example to change the flags as if there is bug with the browser etc. The feature changes cookies returned in the Response Set-Cookie header from the origin server as it should.
vlan associated with 2 selfIP on different subnets
Hello everyone, I have an BigIP LTM Cluster deployed on Cloud Azure, and I would like to know if it is possible to associate a new selfip (e.g. 10.20.1.1/24) to a vlan that has already associated a selfip of a different subnet (e.g. 10.10.1.1/24) Thank youUsing F5 Distributed Cloud DNS Load Balancer health checks and DNS observability
Introduction This article is a continuation of my previous article that covers how to configure F5 Distributed Cloud (XC) DNS Load Balancer to provide geo-proximity and disaster recovery, in addition to other failover scenarios. This article builds on the previous configuration to add health checks and shows how the Distributed Cloud DNS service is performing. DNS Load Balancer Configuring DNS LB Health Checks F5 XC can perform health checks on all IP members in a DNS Load Balancer Pool. To configure health checks for a pool, go to DNS Management > DNS Load Balancer Management > DNS Load Balancer Health Checks, then click "Add DNS Load Balancer Health Check". Name the rule, for example, "europe-healthcheck", and choose an appropriate health check type. The following health check types are supported for DNS LB: HTTP HTTPS TCP TCP (Hex payload) UDP ICMP Each health check type, except ICMP, supports sending a custom string payload, and looks for a response to match. For example, choosing the HTTPS health check, F5 XC will first confirm whether it received a valid SSL certificate from the member. Passing the SSL certificate check, it then sends the configured "Send String" (an HTTP request). By default, the string is "HEAD / HTTP/1.0\r\n\r\n", although more complex strings are supported. The "Receive String", in regex (re2) format, validates the application layer response. The default receive string for HTTP(S) requests is "HTTP/1." A custom TCP or UDP port can also be configured to support services running on non-standard ports. Configuring the port with "0" uses the default port belonging to the intended protocol. To apply the health check to a DNS LB Load Balancing rule, navigate to DNS Load Balancer Management > DNS Load Balancer Pools. Locate the pool to apply the health check to, and use the Manage Configuration action. Within the pool configuration, click Edit Configuration, scroll down to DNS Load Balancer Health Check, enable it, and then choose the health check created above. Save and Exit the Pool. Status information about the health of the DNS LB pools and pool members can be found at the DNS Load Balancers Overview page. In the following example, one of the members in the "eu-pool" is unhealthy. Details about each specific pool member can be found by clicking on the pool. Distributed Cloud DNS Observability The F5 XC DNS Performance Overview dashboards provide usage details for up to a 24-hour interval. Navigate to DNS Management > Overview > Performance for a high-level view showing how many requests a domain has received. To see where DNS requests are coming from, the most requested services, and specific response details, click on each DNS zone. The DNS performance dashboards provide the following views for each DNS zone: Traffic Distribution Top Requests Total Queries Query Type Response Type (by RCODE) DNS Query Rate (by Query Type) The DNS Dashboards also include showing the type and frequency of each DNS request. Query logging is available and located in the Requests tab. This view provides up to a 24-hour interval of each DNS query. The dashboard can be filtered to show requests from a particular geo location, resource record type, which record or records are being requested, in addition to the client IP and return code. The following image illustrates a filtered list. Records in the table below can be downloaded in a CSV formatted file. Details about an individual request can be viewed by clicking on the ">" symbol, and the detailed record can be shown in either JSON or YAML format. The DNS Zones overview shows zone-specific details: a comparison of zone types, deployment status, and includes the number of records and requests per 24hrs on a per-zone basis. Clicking on a one of the zones shows the records that belong to it and a breakdown of the record types. For Secondary DNS, the overview includes when the zone was last transferred, making it easier to proactively detect and troubleshoot stale DNS issues. Drilling down on an the secondary DNS zones shows the resource records and each time-to-live (TTL), another important metric when troubleshooting potentially stale records Logging & Analytics The Global Log Receiver provides the logging of DNS Requests in addition to other security services in Distributed Cloud, including WAF and Bot Defense. This article explains how to configure Global Log Receiver and send logs using HTTPS to an ELK Stack (elasticsearch, logstash, and kibana). It also shows how to configure logstash and kibana to process GLR formatted logs from Distributed Cloud. To configure the Global Log Receiver for DNS logging, go to Shared Configuration > Global Log Receiver, and create a new entry. In the Log Type field, choose DNS Request Logs. In the following example, I've configured Global Log Receiver to send via HTTPS, but many other logging platforms are also supported. See this product documentation page for up to date information on all the features available with Global Log Receiver. With DNS Request Logs configured, we can now see every DNS request to our Distributed Cloud tenant, processed by logstash, in the Kibana dashboard. The following output in Kibana shows DNS requests for all zones configured in the Distributed Cloud tenant. Additional Resources Previous article in series: Using Distributed Cloud DNS Load Balancer with Geo-Proximity and failover scenarios Technical article: How I did it - "Remote Logging with the F5 XC Global Log Receiver and Elastic" Product Documentation: DNS LB Product Documentation DNS Zone Management Global Log Receiver More information about Distributed Cloud DNS Load Balancer and DNS service: https://www.f5.com/cloud/products/dns-load-balancer https://www.f5.com/cloud/products/dnsUse F5 Distributed Cloud to control Primary and Secondary DNS
Overview Domain Name Service (DNS); it's how humans and machines discover where to connect. DNS on the Internet is the universal directory of addresses to names. If you need to get support for the product Acme, you go to support.acme.com. Looking for the latest headlines in News, try www.aonn.com or www.npr.org. DNS is the underlying feature that nearly every service on the Internet depends on. Having a robust and reliable DNS provider is critical to keeping your organization online and working, and especially so during a DDoS attack. "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 DNS (F5 XC DNS) can function as both Primary or Secondary nameservers, and it natively includes DDoS protection. Using F5 XC DNS, it’s possible to provision and configure primary or secondary DNS securely in minutes. Additionally, the service uses a global anycast network and is built to scale automatically to respond to large query volumes. Dynamic security is included and adds automatic failover, DDoS protection, TSIG authentication support, and when used as a secondary DNS—DNSSEC support. F5 Distributed Cloud allows you to manage all of your sites as a single “logical cloud” providing: - A portable platform that spans multiple sites/clouds - A private backbone connects all sites - Connectivity to sites through its nodes (F5 Distributed Cloud Mesh and F5 Distributed Cloud App Stack) - Node flexibility, allowing it to be virtual machines, live on hardware within data centers, sites, or in cloud instances (e.g. EC2) - Nodes provide vK8s (virtual K8s), network and security services - Services managed through F5 Distributed Cloud’s SaaS base console Scenario 1 – F5 Distributed Cloud DNS: Primary Nameserver Consider the following; you're looking to improve the response time of your app with a geo-distributed solution, including DNS and app distribution. With F5 XC DNS configured as the primary nameserver, you’ll automatically get DNS DDoS protection, and will see an improvement in the response the time to resolve DNS just by using Anycast with F5’s global network’s regional point of presence. To configure F5 XC DNS to be the Primary nameserver for your domain, access the F5 XC Console, go to DNS Management, and then Add Zone. Alternately, if you're migrating from another DNS server or DNS service to F5 XC DNS, you can import this zone directly from your DNS server. Scenario 1.2 below illustrates how to import and migrate your existing DNS zones to F5 XC DNS. Here, you’ll write in the domain name (your DNS zone), and then View Configuration for the Primary DNS. On the next screen, you may change any of the default SOA parameters for the zone, and any type of resource record (RR) or record sets which the DNS server will use to respond to queries. For example, you may want to return more than one A record (IP address) for the frontend to your app when it has multiple points of presence. To do this, enter as many IP addresses of record type A as needed to send traffic to all the points of ingress to your app. Additional Resource Record Sets allows the DNS server to return more than a single type of RR. For example, the following configurations, returns two A (IPv4 address) records and one TXT record to the query of type ANY for “al.demo.internal”. Optionally, if your root DNS zone has been configured for DNSSEC, then enabling it for the zone is just a matter of toggling the default setting in the F5 XC Console. Scenario 1.2 - Import an Existing Primary Zone to Distributed Cloud using Zone Transfer (AXFR) F5 XC DNS can use AXFR DNS zone transfer to import an existing DNS zone. Navigate to DNS Management > DNS Zone Management, then click Import DNS Zone. Enter the zone name and the externally accessible IP of the primary DNS server. ➡️ Note: You'll need to configure your DNS server and any firewall policies to allow zone transfers from F5. A current list of public IP's that F5 uses can be found in the following F5 tech doc. Optionally, configure a transaction signature (TSIG) to secure the DNS zone transfer. When you save and exit, F5 XC DNS executes a secondary nameserver zone AXFR and then transitions itself to be the zone's primary DNS server. To finish the process, you'll need to change the NS records for the zone at your domain name registrar. In the registrar, change the name servers to the following F5 XC DNS servers: ns1.f5clouddns.com ns2.f5clouddns.com Scenario 1.3 - Import Existing (BIND format) Primary Zones directly to Distributed Cloud F5 XC DNS can directly import BIND formatted DNS zone files in the Console, for example, db.2-0-192.in-addr.arpa and db.foo.com. Enterprises often use BIND as their on-prem DNS service, importing these files to Distributed Cloud makes it easier to migrate existing DNS records. To import existing BIND db files, navigate to DNS Management > DNS Zone Management, click Import DNS Zone, then "BIND Import". Now click "Import from File" and upload a .zip with one or more BIND db zone files. The import wizard accepts all primary DNS zones and ignores other zones and files. After uploading a .zip file, the next screen reports any warnings and errors At this poing you can "Save and Exit" to import the new DNS zones or cancel to make any changes. For more complex zone configurations, including support for using $INCLUDE and $ORIGIN directives in BIND files, the following open source tool will convert BIND db files to JSON, which can then be copied directly to the F5 XC Console when configuring records for new and existing Primary DNS zones. BIND to XC-DNS Converter Scenario 2 - F5 Distributed Cloud DNS: Primary with Delegated Subdomains An enhanced capability when using Distributed Cloud (F5 XC) as the primary DNS server for your domains or subdomains, is to have F5 XC dynamically manage the DNS records for its own managed services. Note that prior to July 2023, the delegated DNS feature in F5 XC required the exclusive use of subdomains to use dynamically managed DNS records. As of July 2023, organizations are allowed to have both F5 XC managed and self-managed DNS resource records in the same domain or subdomain. When "Allow HTTP Load Balancer Managed Records" is checked, DNS records automatically added by F5 XC appear in a new RR set group called x-ves-io-managed which is read-only. In the following example, I've created an HTTP Load Balanacer with the domain "www.example.f5-cloud-demo.com" and F5 XC automatically created the A resource record (RR) in the group x-ves-io-managed. Scenario 3 – F5 Distributed Cloud DNS: Secondary Nameserver In this scenario, say you already have a primary DNS server in your on-prem datacenter, but due to security needs, you don’t want it to be directly accessible to the Internet. F5 XC DNS can be configured as a secondary DNS server and support both zone transfer (AXFR, IXFR) and receive (NOTIFY) updates from your primary DNS server. All that's needed to complete this change is to change the nameserver records with your DNS registrar by adding the F5 XC nameservers and removing your the real primary. Having F5 XC DNS as public interface includes complimentary security services, such as DDoS protection and vector scaling. This improves both the uptime of your services as well as reducing latency by allowing all F5's nameservers world-wide to handle domain name resolution. If the primary nameserver is configured for DNSSEC and delivers RRSIG and zone DNSKEY records, F5 XC nameservers will also include these records in the lookups delivered to clients. This ensures a consistent level of security for records management end-to-end. To configure F5 XC DNS to be a secondary DNS server, go to Add Zone, then choose Secondary DNS Configuration. Next, View Configuration for it, and add your primary DNS server IP’s. To enhance the security of zone transfers and updates, F5 XC DNS supports TSIG encrypted transfers from the primary DNS server. To support TSIG, ensure your primary DNS server supports encryption, and enable it by entering the pre-shared key (PSK) name and its value. The PSK itself can be blindfold-encrypted using the F5 XC Console to prevent other admins from being able to see it. If encryption for zone transfers is desired, simply enter the remaining details for your TSIG PSK and click Apply. Once you’ve saved a new secondary DNS configuration, the F5 XC DNS pulls the zone details and begins resolving queries on the F5 XC Global Network with its pool of Anycast-reachable DNS servers. To see the status of individual zones and when they were last transferred by navigating to the DNS Management > DNS Zones overview. As applications mature and your audience broadens, ensuring low-latency for DNS requires additional services. Adding F5 XC DNS to complement an existing BIG-IP GTM or other existing primary nameserver deployment, including with DNSSEC records and TSIG-protected zone transfer support, is straight forward. Conclusion You’ve just seen how to configure F5 XC DNS both as a primary DNS as well as a secondary DNS service. Ensure the reachability of your company with a robust, secure, and optimized DNS service by F5. A service that delivers the lowest resolution latency with its global Anycast network of nameservers, and one that automatically includes DDoS protection, DNSSEC, TSIG support for secondary DNS. Watch the following demo video to see how to configure F5 XC DNS for scenarios #1 and #3 above. Additional Resources On-Demand webinar: Boost resilience and performance with F5 Distributed Cloud DNS Information about using F5 Distributed Cloud DNS Technical documentation DNS Demo Guide and step-by-step walkthrough BIND to XC-DNS Converter (open source tool)BIG-IP for Scalable App Delivery & Security in Hybrid Environments
This article highlights how F5 BIG-IP deploys identical application workloads across multiple environments, ensuring high availability, seamless traffic management, and consistent performance. By supporting smooth workload transitions and zero-downtime deployments, F5 helps organizations maintain reliable, secure, and scalable applications. From a business perspective, it enhances operational agility, supports growing traffic demands, reduces risk during updates, and ultimately delivers a reliable, secure, and high-performance application experience that meets customer expectations and drives growth.F5 Scalable App Delivery & Security for Hybrid Environments
As enterprises modernize and expand their digital services, they increasingly deploy multiple instances of the same applications across diverse infrastructure environments—such as VMware, OpenShift, and Nutanix—to support distributed teams, regional data sovereignty, redundancy, or environment-specific compliance needs. These application instances often integrate into service chains that span across clouds and data centers, introducing both scale and operational complexity. F5 Distributed Cloud provides a unified solution for secure, consistent application delivery and security across hybrid and multi-cloud environments. It enables organizations to add workloads seamlessly—whether for scaling, redundancy, or localization—without sacrificing visibility, security, or performance.Secure Extranet with Equinix Fabric and F5 Distributed Cloud
Why: The Challenge of Building a Secure Extranet Establishing a secure extranet that spans multiple clouds, partners, and enterprise locations is inherently complex. Organizations face several persistent challenges: Technology Fragmentation: Different clouds, vendors, and networking stacks introduce inconsistency and integration friction. Endpoint Proliferation: Each new partner or cloud region adds more endpoints to secure and manage. Configuration Drift: Manual or siloed configurations across environments increase the risk of misalignment and security gaps. Security Exposure: Without centralized control, enforcing consistent policies across environments is difficult, increasing the attack surface. Operational Overhead: Managing disparate systems and connections strains NetOps, DevOps, and SecOps teams. These challenges make it difficult to scale securely and efficiently, especially when onboarding new partners or deploying applications globally. What: A Unified, Secure, and Scalable Extranet Solution The joint solution from F5 and Equinix addresses these challenges by combining: F5® Distributed Cloud Customer Edge (CE): A virtualized network and security node deployed via Equinix Network Edge. Equinix Fabric®: A software-defined interconnection platform that provides private, high-performance connectivity between clouds, partners, and enterprise locations. Together, they create a strategic point of control at the edge of your enterprise network. This enables secure, scalable, and policy-driven connectivity across hybrid and multi-cloud environments. This solution: Simplifies deployment by eliminating physical infrastructure dependencies. Centralizes policy enforcement across all connected environments. Accelerates partner onboarding with pre-integrated, software-defined connectors. Reduces risk by isolating traffic and enforcing consistent security policies. How: Architectural Overview At the heart of the architecture is the F5 Distributed Cloud CE, deployed as a virtual network function (VNF) on Equinix Network Edge. This CE: Acts as a gateway node for each location (cloud, data center, or partner site). Connects to other CEs via F5’s global private backbone, forming a secure service mesh. Integrates with F5 Distributed Cloud Console for centralized orchestration, visibility, and policy management. The CE node(s) are interconnected to partners, vendors, etc. using Equinix Fabric, which provides: Private, low-latency interconnects to major cloud providers (AWS, Azure, GCP, OCI). Software-defined routing via Fabric Cloud Router. Tier-1 internet access for hybrid workloads. This architecture enables a hub-and-spoke or full-mesh extranet topology, depending on business needs. Key Tenets of the Solution Strategic Point of Control The CE becomes the enforcement point for traffic inspection, segmentation, and policy enforcement—across all clouds and partners. Unified Management F5 Distributed Cloud Console provides a single pane of glass for managing networking, security, and application delivery policies. Zero-Trust Connectivity Built-in support for mutual TLS, IPsec, and SSL tunnels ensures encrypted, authenticated communication between nodes. Rapid Partner Onboarding Equinix’s Fabric and F5 CE connectors allow new partners to be onboarded in minutes, not weeks. Operational Efficiency Automation hooks (GitOps, Terraform, APIs) reduce manual effort and configuration drift. Private interconnects and regional CE deployments help meet regulatory requirements. Additional Links F5 and Equinix Partnership The Business Partner Exchange - An F5 Distributed Cloud Services Demonstration Equinix Fabric Overview Additional Equinix and F5 partner informationJavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo)
JavaScript Supply Chain Attacks are on the Rise With a firewall, a WAF, bot defense, and a SIEM, you control and monitor web traffic entering the data center. Criminals have adapted their strategies to attack your customers in the browser. New web architectures involving dozens of third-party JavaScript files make this new attack surface even more vulnerable. Increasing Web Page Complexity Enterprises cannot keep track of all the scripts and changes that go on in their website and attackers are exploiting this lack of surveillance to introduce malicious code into the supply chain that their web page relies on. Most use 3rd party libraries (eg. Marketing Scripts) Most 3rd party libraries themeselves depend on another set of 3rd party libraries (eg. jQuery.js) Final page loads on end user's browser can easily contain scripts from 20-30 different organizations Magecart, Formjacking, and E-skimming These attacks occur when a threat actor injects one or many malicious scripts into a legitimate page or code repo to create a software supply chain man-in-the-browser attack (SC-MITB). The attacker can then run keyloggers and any other JavaScript based attacks on the end-users browser stealing any credit card data, username and password combinations etc... which will be sent to the attackers command and control server as pictured below. What is Distributed Cloud Client-Side Defense? F5® Distributed Cloud Client-Side Defense (CSD) provides a multi-phase protection system that protects web applications against Magecart-style and other malicious JavaScript attacks. This multi-phase protection system includes detection, alerting, and mitigation. Detection. A continuously evolving signal set allows CSD to understand when scripts on web pages exhibit signs of exfiltration. CSD detects network requests made by malicious scripts that attempt to exfiltrate PII data. Alerting. CSD generates timely alerts on the behavior of malicious scripts, provided by a continuously improving Analysis Engine. The Analysis Engine contains a machine learning component for accurate and informative analysis and provides details on the behavior of malicious script to help troubleshoot and identify the root cause. Mitigation. CSD detects threats in real-time and provides enforcement with one-click mitigation. CSD leverages the same obfuscation and signal technology as F5® Distributed Cloud Bot Defense, delivering unparalleled efficacy. High Level Distributed Cloud Client-Side Defense Architecture Client-Side Defense Demo: Learn about the risks of JavaScript supply-chain attacks (aka Magecart), the costs of Formjacking and PII Harvesting, and how to detect and mitigate this threat vector. Regain security control of your apps with F5’s Distributed Cloud Client-Side Defense. Related Resources Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Client-Side Defense Product Page Client-Side Defense Documentation
