BIG-IP Next for Kubernetes Nvidia DPU deployment walkthrough
Introduction Modern AI factories—hyperscale environments powering everything from generative AI to autonomous systems—are pushing the limits of traditional infrastructure. As these facilities process exabytes of data and demand near-real-time communication between thousands of GPUs, legacy CPUs struggle to balance application logic with infrastructure tasks like networking, encryption, and storage management. Data Processing Units (DPUs), purpose-built accelerators that offload these housekeeping tasks, freeing CPUs and GPUs to focus on what they do best. DPUs are specialized system-on-chip (SoC) devices designed to handle data-centric operations such as network virtualization, storage processing, and security enforcement. By decoupling infrastructure management from computational workloads, DPUs reduce latency, lower operational costs, and enable AI factories to scale horizontally. BIG-IP Next for Kubernetes and Nvidia DPU Looking at F5 ability to deliver and secure every app, we needed it to be deployed at multiple levels, a crucial one being edge and DPU. Installing F5 BIG-IP Next for Kubernetes on Nvidia DPU requires installing Nvidia’s DOCA framework to be installed. What’s DOCA? NVIDIA DOCA is a software development kit for NVIDIA BlueField DPUs. BlueField provides data center infrastructure-on-a-chip, optimized for high-performance enterprise and cloud computing. DOCA is the key to unlocking the potential of the NVIDIA BlueField data processing unit (DPU) to offload, accelerate, and isolate data center workloads. With DOCA, developers can program the data center infrastructure of tomorrow by creating software-defined, cloud-native, GPU-accelerated services with zero-trust protection. Now, let's explore BIG-IP Next for Kubernetes components, The BIG-IP Next for Kubernetes solution has two main parts: the Data Plane - Traffic Management Micro-kernel (TMM) and the Control Plane. The Control Plane watches over the Kubernetes cluster and updates the TMM’s configurations. The BIG-IP Next for Kubernetes Data Plane (TMM) manages the supply of network traffic both entering and leaving the Kubernetes cluster. It also proxies the traffic to applications running in the Kubernetes cluster. The Data Plane (TMM) runs on the BlueField-3 Data Processing Unit (DPU) node. It uses all the DPU resources to handle the traffic and frees up the Host (CPU) for applications. The Control Plane can work on the CPU or other nodes in the Kubernetes cluster. This makes sure that the DPU is still used for processing traffic. Use-case examples: There are some recently awesome use cases released by F5’s team based on conversation and work from the field. Let’s explore those items: Protecting MCP servers with F5 BIG-IP Next for Kubernetes deployed on NVIDIA BlueField-3 DPUs LLM routing with dynamic load balancing with F5 BIG-IP Next for Kubernetes deployed on NVIDIA BlueField-3 DPUs F5 optimizes GPUs for distributed AI inferencing with NVIDIA Dynamo and KV cache integration. Deployment walk-through In our demo, we go through the configurations from BIG-IP Next for Kubernetes Main BIG-IP Next for Kubernetes features L4 ingress flow HTTP/HTTPs ingress flow Egress flow BGP integration Logging and troubleshooting (Qkview, iHealth) You can find a quick walk-through via BIG-IP Next for Kubernetes - walk-through Related Content BIG-IP Next for Kubernetes - walk-through BIG-IP Next for Kubernetes BIG-IP Next for Kubernetes and Nvidia DPU-3 walkthrough BIG-IP Next for Kubernetes F5 BIG-IP Next for Kubernetes deployed on NVIDIA BlueField-3 DPUs
F5 Distributed Cloud Telemetry (Metrics) - Prometheus
Scope This article walks through the process of collecting metrics from F5 Distributed Cloud’s (XC) Service Graph API and exposing them in a format that Prometheus can scrape. Prometheus then scrapes these metrics, which can be visualized in Grafana. Introduction Metrics are essential for gaining real-time insight into service performance and behaviour. F5 Distributed Cloud (XC) provides a Service Graph API that captures service-to-service communication data across your infrastructure. Prometheus, a leading open-source monitoring system, can scrape and store time-series metrics — and when paired with Grafana, offers powerful visualization capabilities. This article shows how to integrate a custom Python-based exporter that transforms Service Graph API data into Prometheus-compatible metrics. These metrics are then scraped by Prometheus and visualized in Grafana, all running in Docker for easy deployment. Prerequisites Access to F5 Distributed Cloud (XC) SaaS tenant VM with Python3 installed Running Prometheus instance (If not check "Configuring Prometheus" section below) Running Grafana instance (If not check "Configuring Grafana" section below) Note – In this demo, an AWS VM is used with Python installed and running exporter (port - 8888), Prometheus (host port - 9090) and Grafana (port - 3000) running as docker instance, all in same VM. Architecture Overview F5 XC API → Python Exporter → Prometheus → Grafana Building the Python Exporter To collect metrics from the F5 Distributed Cloud (XC) Service Graph API and expose them in a format Prometheus understands, we created a lightweight Python exporter using Flask. This exporter acts as a transformation layer — it fetches service graph data, parses it, and exposes it through a /metrics endpoint that Prometheus can scrape. Code Link -> exporter.py Key Functions of the Exporter Uses XC-Provided .p12 File for Authentication: To authenticate API requests to F5 Distributed Cloud (XC), the exporter uses a client certificate packaged in a .p12 file. This file must be manually downloaded from the F5 XC console (steps) and stored on the VM where the Python script runs. The script expects the full path to the .p12 file and its associated password to be specified in the configuration section. Fetches Service Graph Metrics: The script pulls service-level metrics such as request rates, error rates, throughput, and latency from the XC API. It supports both aggregated and individual load balancer views. Processes and Structures the Data: The exporter parses the raw API response to extract the latest metric values and converts them into Prometheus exposition format. Each metric is labelled (e.g., by vhost and direction) for flexibility in Grafana queries. Exposes a /metrics Endpoint: A Flask web server runs on port 8888, serving the /metrics endpoint. Prometheus periodically scrapes this endpoint to ingest the latest metrics. Handles Multiple Metric Types: Traffic metrics and health scores are handled and formatted individually. Each metric includes a descriptive name, type declaration, and optional labels for fine-grained monitoring and visualization. Running the Exporter python3 exporter.py > python.log 2>&1 & This command runs exporter.py using Python3 in background and redirects all standard output and error messages to python.log for easier debugging. Configuring Prometheus docker run -d --name=prometheus --network=host -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus:latest Prometheus is running as docker instance in host network (port 9090) mode with below configuration (prometheus.yml), scrapping /metrics endpoint exposed from python flask exporter on port 8888 every 60 seconds. Configuring Grafana docker run -d --name=grafana -p 3000:3000 grafana/grafana:latest Private IP of the Prometheus docker instance along with port (9090) is used as data source in Grafana configuration. Once Prometheus is configured under Grafana Data sources, follow below steps: Navigate to Explore menu Select “Prometheus” in data source picker Choose appropriate metric, in this case “f5xc_downstream_http_request_rate” Select desired time range and click “Run query” Observe metrics graph will be displayed Note : Some requests need to be generated for metrics to be visible in Grafana. A broader, high-level view of all metrics can be accessed by navigating to “Drilldown” and selecting “Metrics”, providing a comprehensive snapshot across services. Conclusion F5 Distributed Cloud’s (F5 XC) Service Graph API provides deep visibility into service-to-service communication, and when paired with Prometheus and Grafana, it enables powerful, real-time monitoring without vendor lock-in. This integration highlights F5 XC’s alignment with open-source ecosystems, allowing users to build flexible and scalable observability pipelines. The custom Python exporter bridges the gap between the XC API and Prometheus, offering a lightweight and adaptable solution for transforming and exposing metrics. With Grafana dashboards on top, teams can gain instant insight into service health and performance. This open approach empowers operations teams to respond faster, optimize more effectively, and evolve their observability practices with confidence and control.
10 Settings to Lock Down your BIG-IP
EDITORS NOTE, Oct 16, 2025: This article was originally written in 2012 and may contain guidance that is out of date. Please see the new Security Best Practices for F5 Products article, updated in Oct 2025. Earlier this year, F5 notified its customers about a severe vulnerability in F5 products. This vulnerability had to do with SSH keys and you may have heard it called “the SSH key issue” and documented as CVE-2012-1493. The severity of this vulnerability cannot be overstated. F5 has gone above and beyond its normal process for customer notification but there is evidence that there are still BIG-IP devices with the exposed SSH keys accessible from the internet. There are several options available to reduce your organization’s exposure to this issue. Here are 10 mitigation techniques that you can implement today to secure your F5 infrastructure. 1. Install the hotfix. Do it. Do it now. The hotfix is non-invasive and requires little testing since it has no impact on the F5 data processing functionality. It simply edits the authorized key file to remove access for the offending key. Control Network Access to the F5 2. Audit your BIG-IP management ports and Self-IPs. Of course you should pay special attention to public addresses (non-RFC-1918), but don’t forget that even private addresses can be vulnerable to internal threats such as malware, malicious employees, and rogue wireless access points. By default, Self-IPs have many ports open – lock these down to just the ones that you know you need. 3. If you absolutely need to have routable addresses on your Self-IPs, at least lock down access to the networks that need it. To lock-down SSH and the GUI for a Self-IP from a specific network: (tmos)# modify /sys sshd allow replace-all-with { 192.168.2.* } (tmos)# modify /sys httpd allow replace-all-with { 192.168.2.* } (tmos)# save /sys config 4. By definition, machines within the network DMZ are at higher risk. If a DMZ machine is compromised, a hacker can use it as a jumping point to penetrate deeper into the network. Use access controls to restrict access to and from the DMZ. See Solution 13309 for more information about restricting access to the management interface. Lock down User Access with Appliance Mode F5’s iHealth system reports consistently that many systems have default passwords for the root and admin accounts and weak passwords for the other users. After controlling access to the management interfaces (see above), this is the most critical part of securing your F5 infrastructure. Here are three easy steps to lock down user access on the BIG-IP. 5. The Appliance Mode license option is simple. When enabled, Appliance Mode locks down the root user and removes the Unix bash shell as a command-line option– Permitting root login is a historical artifact that many F5 power users cherish. But when root logs in, you don’t know who that user really is, do you? This can be an audit issue if there’s a penetration or other funny business. If you are okay with locking down root but find that you cannot live without bash, then you can split the difference by just setting this db variable to true. (tmos)# modify /sys db systemauth.disablerootlogin value true (tmos)# save /sys config 6. Next, if you haven’t done this already, configure the BIG-IP for remote authentication against, say, the enterprise Active Directory repository. Make this happen from the System > Users > Authentication screen and ensure that the default role is Application Editor or less. You can use the /auth remote-role command to provide somewhat granular authorization to each user group. (tmos)# help /auth remote-role 7. Ensure that the oft-forgotten ‘admin’ user has no terminal access. (tmos)# modify /sys auth user admin shell none (tmos)# save /sys config With steps 5-7, you have significantly hardened the BIG-IP device. Neither of the special accounts, root and admin, will be able to login to the shell and that should eliminate both the SSH key issue and the automated brute force risk. Keep Up to Date on Security News, Hotfixes and Patches 8. If you haven’t done so already, subscribe to the F5 security alert mailing list at f5.com/about-us/preferences. This will ensure that you receive timely security notices. 9. Check your configuration against F5’s heuristic system iHealth. When you upload your diagnostics to iHealth, it will inform you of any missing or suggested security upgrades. Using iHealth is easy. Generating the support file is as simple as pressing a couple buttons on the GUI. Then point your browser at ihealth.f5.com, login and upload the support file. iHealth will tell you what else to look to help you lock down your system. There you have it, nine steps to lock down a BIG-IP and keep on top of infrastructure security… Wait, what, I promised you 10? 10. Follow me (@dholmesf5) and @f5security on Twitter. There that was easy. If you take anything away from this blog post (and congratulations for getting this far), it is be sure you install the SSH key hotfix and protect your management interfaces. And then, fun aside; remember that securing the infrastructure really is serious business.Distributed Cloud for 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.Red Hat in the news, £5.5B in Bitcoin recovered from scammer, more Breaches
Hello! ArvinF is your editor of the F5 SIRT This Week in Security, covering 28 September to 4 October 2025. This week, Red Hat is in the news for their Consulting GitLab instance breach and an "Important" rated vulnerability in their OpenShift AI Service product. A win - UK's Metropolitan police have arrested a scammer and recovered £5.5B (!) in Bitcoin. Then came the breach disclosures from Alianz, Westjet, Motility and a "US tech company”. Finally, the ransomware and extortion gangs - Scattered LAPSUS$ Hunters 1B Salesforce record under ransom and Radiant Group's extortion attempt getting slammed by another extortion group. Let’s get to it! Red Hat's Consulting GitLab instance has been breached by an extortion group named Crimson Collective. The group initially bragged about the breach on Telegram, showing file listings and other sensitive data in Customer Engagement Reports (CERs) that are related to Redhat customers environments. Redhat published a security incident advisory: We recently detected unauthorized access to a GitLab instance used for internal Red Hat Consulting collaboration in select engagements. Upon detection, we promptly launched a thorough investigation, removed the unauthorized party’s access, isolated the instance, and contacted the appropriate authorities. Our investigation, which is ongoing, found that an unauthorized third party had accessed and copied some data from this instance. Crimson Collective threat group notes that they found authentication tokens inside these repos and have “already used these to compromise downstream Red Hat customers.” In an advisory from the Belgian government, it notes the incident is “High Risk” for Belgian organizations and has “potential supply chain impact if service providers or IT partners worked with Red Hat Consulting” From the same advisory, it provided recommendations: Revoke & Rotate all tokens, keys, and credentials shared with Red Hat or used in integrations. Engage Third-Parties – ask your IT providers or partners whether they have used Red Hat Consulting and assess your potential exposure. Contact Red Hat for guidance on your specific exposure. Increase monitoring of authentication events, API calls, and system access for anomalies. https://www.theregister.com/2025/10/03/red_hat_gitlab_breach/ https://www.redhat.com/en/blog/security-update-incident-related-red-hat-consulting-gitlab-instance https://www.theregister.com/2025/10/02/cybercrims_claim_raid_on_28000/ https://ccb.belgium.be/news/hackers-crimson-collective-use-leaked-authentication-tokens-access-customer-systems From standard user to Full Cluster Admin in Red Hat Openshift AI Service via CVE-2025-10725 Red Hat OpenShift AI Service has a 9.9 out of 10 CVSS Score CVE, tracked as CVE-2025-10725, thinly avoiding a 10 out of 10, due to a requirement of a Low-Privileged attacker. https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H In the advisory: A flaw was found in Red Hat OpenShift AI Service. A low-privileged attacker with access to an authenticated account, for example as a data scientist using a standard Jupyter notebook, can escalate their privileges to a full cluster administrator. This allows for the complete compromise of the cluster’s confidentiality, integrity, and availability. The attacker can steal sensitive data, disrupt all services, and take control of the underlying infrastructure, leading to a total breach of the platform and all applications hosted on it. To resolve the vulnerability, upgrade to RHOAI 2.16.3 or if Kueue features are not required, the Kueue component management state can be set to “Removed” in the RHOAI DataScienceCluster resource. For RHOAI 2.19+, a workaround is Prevent the RHOAI operator from managing the kueue-batch-user-rolebinding then Disable the ClusterRoleBinding by updating its subject to a different, non-existent, group. Once updates providing fixes have been applied, it's recommended to remove the clusterrolebinding. This “Important” rated CVE came out approx the same time as the Red Hat Consulting GitLab breach. https://www.theregister.com/2025/10/01/critical_red_hat_openshift_ai_bug/ https://access.redhat.com/security/cve/cve-2025-10725#cve-affected-packages £5.5B in Bitcoin recovered from scammer A scammer caught by the London Metropolitan Police after a seven-year investigation and recovered a record-busting Bitcoin seizure worth £5.5B. .. carried out what the police describe as a "large-scale fraud in China" between 2014 and 2017, and then attempted to launder the significant proceeds after arriving in the UK. The three-year fraud affected more than 128,000 people and netted 61,000 Bitcoin, which at current prices is worth more than £5.5 billion ($7.4 billion). At the point the crypto tokens were seized, they would have been worth around $404 million. The scammer fled using false documents and entered the UK and attempted to launder the stolen money by buying property, said the Met. An associate helped in attempting to cash in on the laundering by buying properties in the UK and Dubai. This associate was caught last year and was jailed/sentenced. The scammer may get additional time if they fail to pay up and return more than £3.1 million. The Crown Prosecution Service said the associate benefited by £3.5 million (c $4.7 million) from the fraud, led by the scammer, and the £3.1 million figure was the total sum of her available assets at the time. Reforms to crime legislation under the previous Conservative government aimed to make it easier for the UK authorities to seize, freeze and recover crypto assets, external. The changes would also allow some victims to apply for the release of their assets held in accounts. https://www.theregister.com/2025/09/30/met_police_bitcoin_fraud/ https://www.bbc.com/news/articles/cy0415kk3rzo https://news.met.police.uk/news/woman-convicted-following-worlds-largest-seizure-501569 https://www.gov.uk/government/news/new-powers-to-seize-cryptoassets-used-by-criminals-go-live 3.7M breach notification letters - The mailman and mail servers will be busy sending breach notification letters. From the Maine AG breach disclosure pages on affected persons: Insurance biz Allianz Life - 1,497,036 WestJet - 1.2 million Motility - 766670 From the news ... "US tech company" - 250,000 The Impact: Allianz Life - The attackers accessed the data of the insurer's customers, staff, and financial professionals WestJet - affected its online services and mobile app, exposed customer data - could include names, contact details, information and documents provided in connection with their reservation and travel, and data regarding victims' Motility Software Solutions - "unauthorized actor deployed malware that encrypted a portion of our systems. Although the malware primarily restricted our access to internal data, the forensic evidence suggests that, before encryption, the actor may have removed limited files containing customers' personal data ... could include full names, home and email addresses, telephone numbers, dates of birth, SSNs, and driver's license numbers." That’s a lot of names, SSNs, CCs, email addresses, addresses, IDs. All three businesses offered identity protection and credit monitoring services – Allianz Life and WestJet two years of coverage, Motility 12 months. https://www.theregister.com/2025/10/01/north_american_data_breaches/ Scattered LAPSUS$ Hunters 1B Salesforce Records under ransom Scattered LAPSUS$ Hunters gave Salesforce until October 10, a deadline to negotiate payment or leak their customer’s data. Scattered LAPSUS$ Hunters are 3 threat / ransomware groups - Scattered Spider, ShinyHunters, and Lapsus$ - that had a moment of solidarity "to break into businesses' networks, steal their data, and force an extortion payment." Per Salesforce advisory: "We are aware of recent extortion attempts by threat actors, which we have investigated in partnership with external experts and authorities," "Our findings indicate these attempts relate to past or unsubstantiated incidents, and we remain engaged with affected customers to provide support," "At this time, there is no indication that the Salesforce platform has been compromised, nor is this activity related to any known vulnerability in our technology." In August of 2025, there was the Salesloft drift breach that affected Salesforce customers. https://www.theregister.com/2025/10/03/scattered_lapsus_hunters_latest_leak/ https://www.theregister.com/2025/09/14/in_brief_infosec/ https://www.theregister.com/2025/09/08/drift_breach_entry_salesloft_github/ https://www.theregister.com/2025/08/12/scattered_spidershinyhunterslapsus_cybercrime_collab/ https://status.salesforce.com/generalmessages/20000224?locale=en-US Radiant Group extortion gang crosses the line and gets schooled by other ransomware groups Radiant Group stole data from Kido International, a school for young children with branches in the UK, US, and India. They then posted unblurred pictures of 10 children, along with their addresses, parents’ names, and other personal data, and threatened to expose more if a ransom wasn't paid. Parents of some children claimed to have received threatening calls after Radiant published the data. London's Metropolitan Police investigators are following up on the case. But now, Radiant says it removed the child data it had posted after receiving pressure from other ransomware groups. It seems they crossed a line in the criminal world and backed down when called out for it. Rebecca Taylor, a threat intelligence knowledge manager at security biz Sophos, tells The Register that the crew was called out by the well-established ransomware-as-a-service Nova gang on the Russian Anonymous Market Place (RAMP), an online souk for cybercriminals. One of Nova's affiliate members, going under the handle BlackBeard, told Radiant, "reputation important, don't attack child right." "We have disabled any attacks relating to them, is not allowed anymore," Radiant answered, and added, "Any data relating to under 18s who attended have been deleted." BlackBeard congratulated them and wished the extortionists good luck for the future and Nova offered to help in future raids. Radiant claimed to have information on over 8,000 children enrolled at Kido, as well as their family, teachers, and staff. Taylor told us that the Radiant Group seems to be new script kiddies on the block and have overstepped themselves, and are now trying to make nice with the rest of the criminal community. https://www.theregister.com/2025/10/02/ransomware_radiant_delete_kids_info/ https://www.theregister.com/2025/09/25/ransomware_gang_publishes_toddlers_images/ https://www.theguardian.com/technology/2025/oct/02/kido-nursery-hackers-say-they-have-deleted-stolen-data Outro The amount of breach news from this week was something - the leaked personal and financial information will surely be the foundation of future breaches and extortions. These breaches were perpetrated by ransomware and extortion gangs that utilized social engineering and known and unknown vulnerabilities in their campaigns. As defenders, we should advise our organizations to keep our systems updated, implement levels and layers of security defenses and keep ourselves and our peers educated on good security practices. The silver lining is the recovery of the £5.5B worth of Bitcoin from scammers caught in the UK. The many victims of scammers have an opportunity to recover their lost assets. Credit to the original source and posts! I hope the news I picked is informative and educational. Till next time - Stay Safe and Secure! As always, if this is your first TWIS, you can always read past editions. We also encourage you to check out all of the content from the F5 SIRT.Introducing F5 WAF for NGINX with Intuitive GUI in NGINX One Console and NGINX Instance Manager
F5 WAF for NGINX (formerly NGINX App Protect WAF) now has an intuitive, GUI-based policy management experience within NGINX One Console and NGINX Instance Manager. It’s easier than ever to streamline security operations and reduce false positives and false negatives. Important Changes! This product release unites the latest version of F5 WAF for NGINX with NGINX One Console and NGINX Instance Manager to deliver major enhancements empowering SecOps teams. New and enhanced capabilities for F5 WAF for NGINX users include: A GUI for WAF Policy Management A modern, wizard-driven UI debuts in NGINX One Console and NGINX Instance Manager, for F5 WAF for NGINX. The initial phases of the new UI focus on foundational tasks for SecOps workflows, which will be followed by subsequent phases supporting additional advanced capabilities to mitigate false positives and false negatives. The current release delivers GUI based attack mitigation workflows that provide: Enabling or disabling signature sets for fast but broad categories of attacks Enabling or disabling signatures for a specific attack type Enabling or disabling signatures and defining actions for a specific user-defined URL, cookie, or parameter A New Name NGINX App Protect is now F5 WAF for NGINX and F5 DoS for NGINX. This is the first product rename to align with F5’s unified platform, enabling security for any app and API, anywhere. Any prior or historical articles, blogs, and other materials will remain unchanged. While the name has changed, all product functionality, code, and configurations remain intact, ensuring a seamless experience for customers. Only branding changes – from NGINX App Protect to F5 WAF for NGINX – have been made to documentation and materials to ensure that no breaking changes have been implemented. Existing workflows remain fully compatible. Upgrading also remains seamless. Users may move from v4.x (e.g. v4.16) to F5 WAF for NGINX v5.9, just as in prior version upgrades. Version Alignment Both packaged and containerized versions of F5 WAF for NGINX now share a single version label for this release: v5.9. This eliminates confusion, simplifies deployments, and ensures consistency across form factors. Additional information is available in the F5 WAF for NGINX 5.9 release notes. Documentation Update F5 WAF for NGINX and F5 DoS for NGINX now feature a completely redesigned documentation experience. Monolithic configuration pages have been replaced with streamlined, logically organized sections, making content easier to navigate, consume, and contribute for faster adoption and collaboration. For more details, refer to the F5 WAF for NGINX docs. Operations Simplification in Kubernetes (EA) This is an ‘Early Availability’ feature for limited customers in the F5 WAF for NGINX v5.9 release for NGINX Plus. This capability removes the need for custom policy compilation workflows. Users can now update policies directly – fully Kubernetes-native with support for JSON, YAML, and Bundle formats, streamlining security operations for modern environments. In future releases, this capability will also extend to NGINX Ingress Controller. For more details, refer to the NGINX docs. Please note that F5 WAF for NGINX v5.9 is a standard release, and upgrading to this version is at the customer’s option. Also, signature updates will continue for NGINX App Protect WAF v4.x customers under the current policy. GUI Eases Implementing Best Practices for WAF Workflows Start in Detection Mode Deploy signature sets in Transparent mode initially to analyze traffic patterns without blocking legitimate requests. This approach allows teams to identify false positives before switching to Block mode. Granular Exception Strategy Rather than broad exclusions that weaken security, implement targeted exceptions that address specific false positive scenarios while maintaining protection elsewhere. Continuous Monitoring and Adjustment Security teams should regularly review WAF logs to identify new false-positive patterns and adjust signature sets accordingly. WAF signatures are updated regularly, requiring ongoing tuning. Enable or disable signature sets for fast but broad categories of attacks. Enabling or disabling signatures for a specific attack type Enabling or disabling signatures and defining actions for a specific user-defined URL, cookie, or parameter The key to effective WAF deployment lies in precise tuning through signature sets and targeted exceptions, ensuring robust protection without disrupting business operations. Releases F5 WAF for NGINX v5.9 (formerly NGINX App Protect WAF) released in September 2025. The complete changelog details are here. F5 DoS for NGINX (formerly NGINX App Protect DoS) documentation update is here. There has been no new release of this package. NGINX One Console, with the GUI supporting the new workflows, will be released in early October 2025. Find all the latest additions to the NGINX One Console in the changelog here. NGINX Instance Manager with the GUI supporting the new workflows will be coming soon (November 2025).
