F5 AWAF/ASM learning only from Trusted traffic?
I found this nice option "Only from Trusted Traffic" for the Policy Builder but this is seems to relevant only after the learning period has passed. I did increase the thresholds to the max possible value 1000000000 under "Loosen Policy" for "Untrusted Traffic "as to never learn from not trusted IP addresses in the initial learning period that is 7 days. I think that is the correct way ? I would have been nice to have a global option or option under "Loosen Policy" to learn from "Only from Trusted Traffic" like in "Track Site ".F5 Threat Report - January 14th, 2026
Knownsec Leak Reveals China's Industrialized Cyber-Espionage Ecosystem A significant data leak from the Chinese company Knownsec in November 2025 exposed its true nature as a state-aligned cyber contractor deeply integrated into China's national security, intelligence, and military objectives, rather than a conventional cybersecurity vendor. Knownsec's internal documents reveal a sophisticated, industrialized cyber-espionage ecosystem, including tools like ZoomEye for global internet-wide scanning and the Critical Infrastructure Target Library (TargetDB) which maps millions of foreign IPs, domains, and organizations by strategic value across 26 regions, with a strong focus on Taiwan, Japan, South Korea, and India. The company also maintains a massive `"o_data_*"` data lake of global breach data for identity correlation and deanonymization, enabling targeted social engineering. Its offensive toolkit comprises GhostX for browser exploitation, routing manipulation, and credential theft; Un-Mail for covert email account takeover and exfiltration across major global providers; and Passive Radar for reconstructing internal network topologies from PCAP data. Knownsec's organizational structure, including the 404 Security Lab and Military Products Division, mirrors a defense integrator, with primary clients being Public Security Bureaus, defense research institutes, and state-owned enterprises like State Grid and China Mobile, indicating a vertically integrated espionage stack for reconnaissance, exploitation, collection, and persistence in support of both domestic surveillance and foreign intelligence operations. Severity: Critical Sources https://dti.domaintools.com/the-knownsec-leak-yet-another-leak-of-chinas-contractor-driven-cyber-espionage-ecosystem/ https://www.hendryadrian.com/the-knownsec-leak-yet-another-leak-of-chinas-contractor-driven-cyber-espionage-ecosystem-domaintools-investigations-dti/ Threat Details and IOCs Malware: GhostX, GhostX Framework, GhostX RAT, Un-Mail CVEs: CVE-2012-0158, CVE-2015-1641, CVE-2017-0199, CVE-2017-11882, CVE-2018-0171, CVE-2018-13379, CVE-2019-19781, CVE-2019-3396, CVE-2020-10189, CVE-2021-26855, CVE-2021-27065, CVE-2021-44207, CVE-2021-44228 Technologies: Check Point Security Gateway, Fortinet FortiGate, Google Gmail, Microsoft Outlook, Microsoft Windows, Sophos Firewall, Yahoo Mail Threat Actors: 404Lab, APT31, APT41, MUSTANGPANDA Attacker Countries: China Attacker IPs: 103.21.60.3, 210.242.194.198, 219.80.43.14, 220.130.186.202, 220.130.186.203, 61.65.236.240 Attacker Emails: anyh@knownsec.com, chenc6@knownsec.com, chenh4@xm.knownsec.com, chenjz@xm.knownsec.com, chenrl@xm.knownsec.com, evp@knownsec.com, hey5@knownsec.com, liuj13@knownsec.com, liwc@xm.knownsec.com, mas@knownsec.com, niexy2@knownsec.com, raosh@knownsec.com, suig@knownsec.com, wangcp2@knownsec.com, wangl8@xm.knownsec.com, wangll@xm.knownsec.com, xuc2@knownsec.com, yangwh2@knownsec.com, zhanghj@knownsec.com, zouxy2@knownsec.com Attacker Domains: creategroup.cn, ittc.sh.cn, knownsec.com, knownsec.com.hk, rusnod.ru, seebug.org, telderi.ru, www.knownsec.com.hk, xm.knownsec.com, zoomeye.aigithub.com Attacker URLs: github.com/Knownsec404team, http://creategroup.cn, https://github.com/zoomeye-ai, https://www.knownsec.com.hk, https://www.knownsec.com.hk/, https://www.linkedin.com/company/上海国际技贸联合有限公司, http://www.ittc.sh.cn, www.linkedin.com/company/knownsec-hong-kong/, zhuanlan.zhihu.com/p/21881117943, zoomeye.aigithub.com/zoomeye-ai Victim Industries: Automotive, Cloud Infrastructure, Defense, Education, Energy, Financial Services, Government, Healthcare, Industrials, Multimedia, Retail, Social Media, Technology Hardware, Telecommunications, Transportation Victim Countries: Brazil, China, India, Japan, Russia, South Africa, South Korea, Taiwan, United States, Vietnam Mitigation Advice Add the IP addresses listed in Appendix A (210.242.194.198, 219.80.43.14, 220.130.186.202, 220.130.186.203, 103.21.60.3, 61.65.236.240) to the firewall blocklist. Immediately audit and apply all available security patches to internet-facing Fortinet devices. Immediately audit and apply all available security patches to internet-facing Sophos devices. Immediately audit and apply all available security patches to internet-facing Check Point devices. Audit all network routers and firewalls for any recently created or unauthorized administrator-level accounts. Review internal and external DNS server configurations and forwarders to ensure they point only to authorized and expected IP addresses. Add all specific email addresses and the domains @knownsec.com and @xm.knownsec.com listed in the article to the email gateway's blocklist. Compliance Best Practices Prioritize and enforce the rollout of phishing-resistant multi-factor authentication (MFA) across all externally accessible services, including VPN, email, and cloud applications. Develop and implement a network segmentation strategy to isolate critical servers from user workstations and restrict east-west traffic based on the principle of least privilege. Deploy and tune an Endpoint Detection and Response (EDR) solution to create detection rules for suspicious browser process behavior, command-line execution patterns, and attempts to extract credentials from memory. Implement a Web Application Firewall (WAF) to protect all public-facing web applications and portals against common attacks like Cross-Site Scripting (XSS). Implement a network detection and response (NDR) tool to establish baseline traffic patterns and create alerts for anomalous activity, such as large outbound data transfers over FTP or SSH from non-standard servers. Establish a recurring security awareness training program that educates employees on identifying and reporting sophisticated phishing attacks that may leverage their personal or professional information found in data breaches. OWASP CRS Flaw Lets Encoded Attacks Slip Past WAFs A critical vulnerability, identified as CVE-2026-21876 with a CVSS score of 9.3, has been discovered in the OWASP Core Rule Set (CRS), allowing encoded Cross-Site Scripting (XSS) attacks to bypass Web Application Firewalls (WAFs). This flaw affects CRS versions 3.3.x through 3.3.7 and 4.0.0 through 4.21.0, specifically impacting rule 922110 in Apache ModSecurity, ModSecurity v3, and Coraza environments. The bypass occurs because rule 922110, designed to detect dangerous character encodings like UTF-7 in multipart form requests, only validates the final segment of such requests. Attackers can exploit this by embedding a malicious UTF-7 encoded JavaScript payload in an earlier part of a multipart request, followed by benign UTF-8 content in the final segment, thereby evading WAF detection. To mitigate this risk, immediate upgrades to CRS version 4.22.0 or 3.3.8 are essential, alongside verifying WAF configurations, restricting accepted character encodings to UTF-8, implementing custom WAF rules for mixed charset declarations, strengthening application-layer defenses with robust input validation and Content Security Policy headers, and enhancing monitoring and incident response capabilities. This incident underscores the necessity for continuous validation and updating of security controls, moving away from "set-and-forget" approaches towards principles of continuous verification. Severity: Critical Sources https://cyberpress.org/owasp-crs-vulnerability/ https://gbhackers.com/owasp-crs-vulnerability/ https://www.esecurityplanet.com/threats/owasp-crs-flaw-lets-encoded-attacks-slip-past-wafs/ https://www.thehackerwire.com/owasp-crs-bypass-multipart-request-charset-validation-flaw-cve-2026-21876/ Threat Details and IOCs Malware: Archer RAT, RUSTRIC, RustyWater CVEs: CVE-2026-21876 Technologies: ModSecurity, OWASP Coraza, OWASP Core Rule Set Victim Industries: E-commerce, Financial Services, Government, Healthcare, Technology Hardware Mitigation Advice Identify all Web Application Firewall (WAF) instances using OWASP Core Rule Set (CRS) and upgrade them to a patched version, either 4.22.0 or 3.3.8, to fix the vulnerability. Analyze WAF and web server logs for evidence of exploitation, specifically looking for multipart form requests that contain non-standard character encodings like UTF-7 or have mixed charsets across different parts. Configure all public-facing web servers, such as Apache or Nginx, to only accept UTF-8 character encoding and explicitly reject requests with other encodings, especially UTF-7 and UTF-16. If patching the OWASP Core Rule Set cannot be done immediately, create a custom WAF rule to inspect all parts of a multipart request for dangerous character encodings, not just the final part. Compliance Best Practices Establish a secure coding program to enforce strict, server-side input validation on all user-supplied data across all web applications to prevent XSS attacks at the source. Mandate the use of context-aware output encoding libraries and practices in all web application development to neutralize any malicious scripts before they are sent to the user's browser. Develop and deploy a restrictive Content Security Policy (CSP) across all web applications to limit the impact of potential XSS vulnerabilities by controlling script execution sources. Improve security monitoring capabilities by creating specific alerts for anomalous HTTP traffic patterns, such as multipart requests with unusual or mixed character set declarations, to detect novel bypass techniques. Schedule and conduct regular incident response tabletop exercises that simulate a WAF bypass and subsequent web application compromise to test and improve your team's detection and response procedures. CVE-2026-21858 aka Ni8mare: Critical Unauthenticated Remote Code Execution Vulnerability in n8n Platform A critical unauthenticated remote code execution vulnerability, tracked as CVE-2026-21858 and dubbed Ni8mare, has been identified in the n8n AI workflow automation platform, carrying a maximum CVSS score of 10.0. This flaw, affecting all n8n versions up to and including 1.65.0, stems from a weakness in the platform's webhook request parsing and file handling logic. Specifically, when a crafted HTTP request is sent to a Forms Webhook node with a deliberately misstated "Content-Type" header (other than `multipart/form-data`), the `parseBody()` function can be exploited to overwrite the `req.body.files` variable with attacker-controlled data. This allows an attacker to specify arbitrary file paths on the local system, leading to the `copyBinaryFile()` function copying these specified local files into persistent storage without verifying their origin. Exploitation of Ni8mare can grant unauthenticated attackers full control over exposed n8n instances, potentially leading to sensitive data exposure, workflow manipulation, and credential compromise. With over 26,500 internet-accessible n8n hosts reported globally, the potential attack surface is substantial. The vulnerability was reported on November 9, 2025, and addressed in version 1.121.0, released on November 18, 2025; users are strongly advised to upgrade immediately, and temporary mitigations include restricting or disabling publicly accessible webhook and form endpoints. Severity: Critical Sources https://arcticwolf.com/resources/blog/cve-2026-21858/ https://buaq.net/go-386499.html https://buaq.net/go-386542.html https://buaq.net/go-387142.html https://cyberpress.org/ni8mare-vulnerability/ https://cyberscoop.com/n8n-critical-vulnerability-massive-risk/ https://horizon3.ai/attack-research/attack-blogs/the-ni8mare-test-n8n-rce-under-the-microscope-cve-2026-21858/ https://infosecwriteups.com/critical-n8n-security-vulnerability-cve-2026-21858-demands-immediate-action-c4bd95b5d93c?source=rss----7b722bfd1b8d---4 https://orca.security/resources/blog/cve-2026-21858-n8n-rce-vulnerability/ https://securityonline.info/public-exploit-released-critical-n8n-flaw-cve-2026-21858-exposes-100k-servers/ https://socprime.com/blog/cve-2026-21858-vulnerability/ https://socradar.io/blog/ni8mare-flaw-n8n-cve-2026-21858/ https://sploitus.com/exploit?id=329E5BE3-360F-5C2E-8422-B4D96C9C6E68 https://thecyberexpress.com/cve-2026-21858-n8n-webhook-vulnerability/ https://thehackernews.com/2026/01/critical-n8n-vulnerability-cvss-100.html https://www.bleepingcomputer.com/news/security/max-severity-ni8mare-flaw-lets-hackers-hijack-n8n-servers/ https://www.cyberkendra.com/2026/01/how-100000-automation-servers-became.html https://www.hendryadrian.com/max-severity-ni8mare-flaw-lets-hackers-hijack-n8n-servers/ https://www.infosecurity-magazine.com/news/maximum-severity-ni8mare-bug/ https://www.securityweek.com/critical-vulnerability-exposes-n8n-instances-to-takeover-attacks/ https://www.techzine.eu/news/security/137741/ni8mare-vulnerability-affects-n8n-platform-with-a-score-of-10-0/ https://www.thehackerwire.com/n8n-unauth-file-read-via-workflow-execution/ https://www.theregister.com/2026/01/08/n8n_rce_bug/ Threat Details and IOCs CVEs: CVE-2025-68613, CVE-2025-68668, CVE-2026-21858, CVE-2026-21877 Technologies: Docker, Linux, n8n, OpenAI, SQLite Attacker Countries: Bangladesh, Myanmar Victim Industries: Advertising Services, Airlines & Aviation, Artificial Intelligence, Construction, Customer Service, E-commerce, Education, Financial Services, Food and Beverage Services, Food & Beverage, Healthcare, Hospitals and Health Care, Human Resources, Information Technology, IT Services, Legal Services, Logistics, Manufacturing, Marketing & Advertising, Media and Entertainment, Professional Services, Real Estate, Retail, Sales & Marketing, Software, Software as a Service (SaaS), Supply Chain, Technology Hardware, Telecommunications, Transportation Equipment Manufacturing, Venture Capital & Private Equity Victim Countries: Australia, Brazil, Canada, Denmark, Finland, France, Germany, Iceland, India, Israel, Italy, Netherlands, Norway, Singapore, Spain, Sweden, Ukraine, United Arab Emirates, United Kingdom, United States, Vietnam Mitigation Advice Immediately upgrade all n8n instances to version 1.121.0 or later to patch the CVE-2026-21858 vulnerability. Immediately scan the network and review software inventories to identify all instances of the n8n platform in use within the organization. If you cannot immediately upgrade n8n, restrict access to or disable all publicly accessible webhook and form endpoints to prevent unauthenticated exploitation. Hunt for exploitation attempts by reviewing web server and application logs for requests to n8n webhook endpoints where the 'Content-Type' header is not 'multipart/form-data' but the request body contains file path definitions. Compliance Best Practices Develop and enforce a policy to place internal services like n8n behind a VPN or other authenticated access controls, and formally review all requests for public internet exposure. Implement network segmentation to isolate servers running workflow automation platforms like n8n from other critical internal network segments, limiting the potential impact of a successful compromise. Deploy or configure a Web Application Firewall (WAF) to inspect and block anomalous HTTP requests to web applications, including rules that detect mismatched 'Content-Type' headers and body content. Review and strengthen the vulnerability management program to ensure timely identification, prioritization, and patching of critical vulnerabilities in all third-party software, with specific focus on internet-facing applications. Trend Micro Apex Central RCE Flaw Scores 9.8 CVSS in On-Prem Windows Versions Trend Micro has issued security updates for multiple vulnerabilities affecting on-premise versions of Apex Central for Windows, specifically those below Build 7190. The most severe, CVE-2025-69258, is a Remote Code Execution (RCE) flaw with a CVSS score of 9.8. This LoadLibraryEX vulnerability enables an unauthenticated remote attacker to load a controlled DLL into the MsgReceiver.exe component by sending a specific message (0x0a8d, `"SC_INSTALL_HANDLER_REQUEST"),` resulting in code execution with SYSTEM privileges. Two additional Denial-of-Service (DoS) vulnerabilities, CVE-2025-69259 and CVE-2025-69260, both rated 7.5 CVSS, were also patched. These DoS flaws, stemming from a message unchecked NULL return value and a message out-of-bounds read, respectively, can be exploited by an unauthenticated remote attacker sending a specially crafted message (0x1b5b, `"SC_CMD_CGI_LOG_REQUEST")` to the MsgReceiver.exe process on TCP port 20001. Tenable is credited with discovering and reporting these vulnerabilities in August 2025. Organizations are advised to apply the necessary security updates and to review remote access to critical systems, ensuring that security policies and perimeter defenses are current. Severity: Critical Sources https://buaq.net/go-386777.html https://cyberpress.org/trend-micro-apex-central-vulnerabilities-enable-remote-code-execution-attacks/ https://cyberveille.esante.gouv.fr/alertes/trendmicro-cve-2025-69258-2026-01-09 https://gbhackers.com/trend-micro-apex-central-flaw/ https://securityonline.info/public-exploit-released-critical-trend-micro-flaw-grants-system-access/ https://thehackernews.com/2026/01/trend-micro-apex-central-rce-flaw.html https://www.esecurityplanet.com/threats/trend-micro-apex-central-flaws-enable-remote-code-execution/ https://www.helpnetsecurity.com/2026/01/08/trend-micro-apex-central-cve-2025-69258-rce-poc/ https://www.techzine.eu/news/security/137798/trend-micro-closes-critical-vulnerabilities-in-apex-central/ https://www.thehackerwire.com/trend-micro-apex-central-rce-via-loadlibraryex/ Threat Details and IOCs CVEs: CVE-2022-26871, CVE-2025-69258, CVE-2025-69259, CVE-2025-69260 Technologies: Microsoft Windows, Trend Micro Apex Central Victim Industries: Automotive, Cloud Infrastructure, Education, Energy, Financial Services, Government, Healthcare, Information Technology, Manufacturing, Oil & Gas, Retail Victim Countries: France, Japan, United States Mitigation Advice Identify all on-premise Trend Micro Apex Central for Windows instances and immediately apply the security updates to upgrade them to Build 7190 or a later version. Implement a firewall rule to block all inbound traffic to TCP port 20001 on Trend Micro Apex Central servers from untrusted networks and allow access only from required endpoints and management stations. On Trend Micro Apex Central servers, use endpoint security tools to monitor the `MsgReceiver.exe` process for the loading of unusual or unsigned DLLs and for spawning unexpected child processes. Scan network traffic logs for connection attempts to TCP port 20001 on Apex Central servers, investigating any connections from unexpected or external IP addresses. Compliance Best Practices Establish and enforce a formal patch management policy that defines specific timelines for applying security updates based on their severity, ensuring critical vulnerabilities are addressed within 72 hours. Implement network segmentation to create a secure management zone for critical infrastructure servers, including Trend Micro Apex Central, restricting all inbound and outbound traffic to only what is explicitly authorized. Develop and maintain a comprehensive software asset inventory that includes application names, versions, and owners, enabling rapid identification of systems vulnerable to newly disclosed threats. Conduct quarterly reviews of firewall rules and access control lists for critical servers to ensure they adhere to the principle of least privilege and that all access is documented and approved. ZDI-26-034 / CVE-2026-0768: 0-Day Code Injection RCE Vulnerability in Langflow A critical code injection remote code execution vulnerability, identified as ZDI-26-034 and CVE-2026-0768, affects installations of Langflow. This flaw, assigned a CVSS score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), allows unauthenticated remote attackers to execute arbitrary code. The vulnerability stems from insufficient validation of a user-supplied string within the `code` parameter provided to the `validate` endpoint, which is subsequently used to execute Python code. Successful exploitation grants an attacker the ability to execute code in the context of root. The vulnerability was reported on July 18, 2025, and publicly disclosed as a 0-day on January 9, 2026. The only salient mitigation strategy is to restrict interaction with the product. This vulnerability was discovered by Peter Girnus, William Gamazo Sanchez, and Alfredo Oliveira. Severity: High Sources https://www.zerodayinitiative.com/advisories/ZDI-26-034/ Threat Details and IOCs CVEs: CVE-2026-0768 Technologies: Langflow, Linux Victim Industries: Customer Service, Financial Services, Human Resources, Logistics, Manufacturing, Marketing & Advertising, Sales & Marketing Mitigation Advice Immediately conduct an inventory of all assets to identify any running instances of the Langflow application. Configure perimeter firewalls to deny all inbound internet traffic to any identified Langflow instances. Hunt for compromise by searching web server and application logs for requests to the '/validate' endpoint, particularly any requests containing a 'code' parameter. If Langflow must remain accessible, configure a Web Application Firewall (WAF) to block any HTTP requests targeting the '/validate' URI path. Compliance Best Practices Enforce the principle of least privilege by reconfiguring all production and development services, including Langflow, to run using dedicated, unprivileged service accounts instead of as the 'root' user. Implement a comprehensive software asset management program to maintain a real-time inventory of all applications deployed in the environment. Adopt a network segmentation strategy that isolates internal-facing tools and development environments from the public internet, requiring VPN access for remote users. Incorporate CVE-2026-0768 into the vulnerability management watchlist and ensure the official patch from the Langflow vendor is applied to all affected systems as soon as it is released. Stay updated on emerging threats: sign up for the F5 Threat Report to receive the Weekly Threat Report in your inbox.
OWA File Upload URIs for WAF Bypass
Hi All, We are using the OWA 2016 WAF application template (negative security model) and would like to know: The list of OWA URIs used for file uploads The recommended URIs to bypass or relax WAF inspection for uploads Our intention is to disable file upload/payload inspection and signature enforcement only for those URIs, while retaining HTTP compliance checks, as file scanning is handled via ICAP. Any guidance would be appreciated. Thanks.F5 BIG-IP SSL Orchestrator Layer 2 Services with rSeries & VELOS
Introduction F5 rSeries & VELOS are rearchitected, next-generation hardware platforms that scale application delivery performance and automate application services to address many of today’s most critical business challenges. F5 rSeries & VELOS are key components of the F5 Application Delivery and Security Platform (ADSP). rSeries & VELOS rely on a Kubernetes-based platform layer (F5OS) that is tightly integrated with F5 TMOS software. Going to a microservice-based platform layer allows rSeries & VELOS to provide additional functionality that was not possible in previous generations of F5 BIG-IP platforms. The introduction of a new tenant-based architecture changes many things, including how you configure BIG-IP. Some of these changes affect the network configuration for Inline Layer 2 Services. By default, BIG-IP tenants only have a small set of internal MAC addresses available to them. However, Layer 2 Services (or Bridging) require additional MAC addresses. You must assign an adequate number of MAC addresses to what is called a “MAC pool”. A single Layer 2 Service requires two unique MAC addresses. The MAC Pool must have sufficient MAC addresses based on the number of Layer 2 Services you need. The following KB articles contain additional information on configuring MAC Pools on a BIG-IP rSeries or VELOS platform: K000133655: MAC address assignment in VELOS and rSeries systems K000135389: Configure the MAC Block Size for an existing BIG-IP tenant on the VELOS and rSeries systems Demo Video F5OS Configuration Let’s review the Network configuration on F5OS for a BIG-IP Tenant. From Network Settings select VLANs. Here you can see I have 6 Interfaces configured with VLANs. There’s a Lan VLAN for connectivity from the internal network to the BIG-IP. A Wan VLAN for connectivity from the BIG-IP to the internet. Then there are 4 “L2” VLANs configured to support two Inline Layer 2 Services with SSL Orchestrator. From the Interfaces screen you can associate the VLANs with the physical Interfaces. Next, allocate the VLANs to your BIG-IP Tenant. This is also where you configure the MAC Pool Size for your current BIG-IP Tenant. The MAC Pool can only be changed when the Tenant is not running. From Tenant Management > Tenant Deployments, you can stop the current Tenant if it is already running. Do this with caution during a change window or prior to deployment. Check the box next to the name of the Tenant you wish to configure, “big-ip-kevin” in this example. Then click Configure. Click OK to stop the Tenant When it’s stopped click the name of the Tenant to edit the configuration. Note the VLANs that are allocated to this BIG-IP Tenant: Find the section on MAC Data/MAC Block Size. Set the allocation to Small (8), Medium (16), or Large (32) depending upon your needs. I set mine to Medium. A Small allocation would be sufficient for this deployment but I want to leave room to add more Layer 2 Services in the future. Click Save & Close Click OK to update the configuration You can Deploy the Tenant now that the changes have been made Click OK to Deploy F5 BIG-IP Configuration Minimal configuration is needed on the BIG-IP since F5OS handles the underlying physical interfaces and VLANs. Check the status of the VLANs from Network > VLANs. From here we can see the VLAN configuration from F5OS is reflected in the BIG-IP. Define any Self IPs from Network > Self IPs Now we’re ready to configure SSL Orchestrator. In the interest of time, I will skip to the Network and Services configuration. From Services List click Add Service Double-click on Generic Inline Layer 2 Under Network Configuration click Add Select the L2 VLANs for this Inline L2 Service. Click Done. Click Add again and select the L2 VLANs for this Inline L2 Service. Click Done. It should look like the following: Click Save at the bottom For the Interception Rule select the Lan VLAN under Ingress Network and move it to the right. Click Save & Next at the bottom The Network configuration is now complete. SSL Orchestrator is configured with a Generic Inline Layer 2 Service that contains two Layer 2 “servers” Conclusion F5 rSeries & VELOS are hardware platforms that scale application delivery performance and automate application services to address many of today’s most critical business challenges. They are key components of the F5 Application Delivery and Security Platform (ADSP). In this article, you learned how to configure MAC Pools on rSeries and VELOS in order to create Layer 2 Inline Services with SSL orchestrator. Related Content K000133655: MAC address assignment in VELOS and rSeries systems K000135389: Configure the MAC Block Size for an existing BIG-IP tenant on the VELOS and rSeries systems SSL Orchestrator CloudDocs: Creating an Inline Layer 2 Service F5 rSeries: Next-Generation Fully Automatable Hardware F5 VELOS: A Next-Generation Fully Automatable Platform
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 vulnerabilitiesApp Delivery & Security for Hybrid Environments using F5 Distributed Cloud
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.The Ingress NGINX Alternative: F5 NGINX Ingress Controller for the Long Term
The Kubernetes community recently announced that Ingress NGINX will be retired in March 2026. After that date, there won’t be any more new updates, bugfixes, or security patches. ingress-nginx is no longer a viable enterprise solution for the long-term, and organizations using it in production should move quickly to explore alternatives and plan to shift their workloads to Kubernetes ingress solutions that are continuing development. Your Options (And Why We Hope You’ll Consider NGINX) There are several good Ingress controllers available—Traefik, HAProxy, Kong, Envoy-based options, and Gateway API implementations. The Kubernetes docs list many of them, and they all have their strengths. Security start-up Chainguard is maintaining a status-quo version of ingress-nginx and applying basic safety patches as part of their EmeritOSS program. But this program is designed as a stopgap to keep users safe while they transition to a different ingress solution. F5 maintains an OSS permissively licensed NGINX Ingress Controller. The project is open source, Apache 2.0 licensed, and will stay that way. There is a team of dedicated engineers working on it with a slate of upcoming upgrades. If you’re already comfortable with NGINX and just want something that works without a significant learning curve, we believe that the F5 NGINX Ingress Controller for Kubernetes is your smoothest path forward. The benefits of adopting NGINX Ingress Controller open source include: Genuinely open source: Apache 2.0 licensed with 150+ contributors from diverse organizations, not just F5. All development happens publicly on GitHub, and F5 has committed to keeping it open source forever. Plus community calls every 2 weeks. Minimal learning curve: Uses the same NGINX engine you already know. Most Ingress NGINX annotations have direct equivalents, and the migration guide provides clear mappings for your existing configurations. Supported annotations include popular ones such as nginx.org/client-body-buffer-size mirrors nginx.ingress.kubernetes.io/client-body-buffer-size (sets the maximum size of the client request body buffer). Also available in VirtualServer and ConfigMap. nginx.org/rewrite-target mirrors nginx.ingress.kubernetes.io/rewrite-target (sets a replacement path for URI rewrites) nginx.org/ssl-ciphers mirrors nginx.ingress.kubernetes.io/ssl-ciphers (configures enabled TLS cipher suites) nginx.org/ssl-prefer-server-cipher mirrors nginx.ingress.kubernetes.io/ssl-prefer-server-ciphers (controls server-side cipher preference during the TLS handshake) Optional enterprise-grade capabilities: While the OSS version is robust, NGINX Plus integration is available for enterprises needing high availability, authentication and authorization, session persistence, advanced security and commercial support Sustainable maintenance: A dedicated full-time team at F5 ensures regular security updates, bug fixes, and feature development. Production-tested at scale: NGINX Ingress Controller powers approximately 40% of Kubernetes Ingress deployments with over 10 million downloads. It’s battle-tested in real production environments. Kubernetes-native design: Custom Resource Definitions (VirtualServer, Policy, TransportServer) provide cleaner configuration than annotation overload, with built-in validation to prevent errors. Advanced capabilities when you need them: Support for canary deployments, A/B testing, traffic splitting, JWT validation, rate limiting, mTLS, and more—available in the open source version. Future-proof architecture: Active development of NGINX Gateway Fabric provides a clear migration path when you’re ready to move to Gateway API. NGINX Gateway Fabric is a conformant Gateway API solution under CNCF conformance criteria and it is one of the most widely used open source Gateway API solutions. Moving to NGINX Ingress Controller Here’s a rough migration guide. You can also check our more detailed migration guide on our documentation site. Phase 1: Take Stock See what you have: Document your current Ingress resources, annotations, and ConfigMaps Check for snippets: Identify any annotations like: nginx.ingress.kubernetes.io/configuration-snippet Confirm you're using it: Run kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx Set it up alongside: Install NGINX Ingress Controller in a separate namespace while keeping your current setup running Phase 2: Translate Your Config Convert annotations: Most of your existing annotations have equivalents in NGINX Ingress Controller - there's a comprehensive migration guide that maps them out Consider VirtualServer resources: These custom resources are cleaner than annotation-heavy Ingress, and give you more control, but it's your choice Or keep using Ingress: If you want minimal changes, it works fine with standard Kubernetes Ingress resources Handle edge cases: For anything that doesn't map directly, you can use snippets or Policy resources Phase 3: Test Everything Try it with test apps: Create some test Ingress rules pointing to NGINX Ingress Controller Run both side-by-side: Keep both controllers running and route test traffic through the new one Verify functionality: Check routing, SSL, rate limiting, CORS, auth—whatever you're using Check performance: Verify it handles your traffic the way you need Phase 4: Move Over Gradually Start small: Migrate your less-critical applications first Shift traffic slowly: Update DNS/routing bit by bit Watch closely: Keep an eye on logs and metrics as you go Keep an escape hatch: Make sure you can roll back if something goes wrong Phase 5: Finish Up Complete the migration: Move your remaining workloads Clean up the old controller: Uninstall community Ingress NGINX once everything's moved Tidy up: Remove old ConfigMaps and resources you don't need anymore Enterprise-grade capabilities and support Once an ingress layer becomes mission-critical, enterprise features become necessary. High availability, predictable failover, and supportability matter as much as features. Enterprise-grade capabilities available for NGINX Ingress Controller Plus include high availability, authentication and authorization, commercial support, and more. These ensure production traffic remains fast, secure, and reliable. Capabilities include: Commercial support Backed by vendor commercial support (SLAs, escalation paths) for production incidents Access to tested releases, patches, and security fixes suitable for regulated/enterprise environments Guidance for production architecture (HA patterns, upgrade strategies, performance tuning) Helps organizations standardize on a supported ingress layer for platform engineering at scale Dynamic Reconfiguration Upstream configuration updates via API without process reloads Eliminates memory bloat and connection timeouts as upstream server lists and variables are updated in real time when pods scale or configurations change Authentication & Authorization Built-in authentication support for OAuth 2.0 / OIDC, JWT validation, and basic auth External identity provider integration (e.g., Okta, Azure AD, Keycloak) via auth request patterns JWT validation at the edge, including signature verification, claims inspection, and token expiry enforcement Fine-grained access control based on headers, claims, paths, methods, or user identity Optional Web Application Firewall Native integration with F5 WAF for NGINX for OWASP Top 10 protection, gRPC schema validation, and OpenAPI enforcement DDoS mitigation capabilities when combined with F5 security solutions Centralized policy enforcement across multiple ingress resources High availability (HA) Designed to run as multiple Ingress Controller replicas in Kubernetes for redundancy and scale State sharing: Maintains session persistence, rate limits, and key-value stores for seamless uptime. Here’s the full list of differences between NGINX Open Source and NGINX One – a package that includes NGINX Plus Ingress Controller, NGINX Gateway Fabric, F5 WAF for NGINX, and NGINX One Console for managing NGINX Plus Ingress Controllers at scale. Get Started Today Ready to begin your migration? Here's what you need: 📚 Read the full documentation: NGINX Ingress Controller Docs 💻 Clone the repository: github.com/nginx/kubernetes-ingress 🐳 Pull the image: Docker Hub - nginx/nginx-ingress 🔄 Follow the migration guide: Migrate from Ingress-NGINX to NGINX Ingress Controller Interested in the enterprise version? Try NGINX One for free and give it a whirl The NGINX Ingress Controller community is responsive and full of passionate builders -- join the conversation in the GitHub Discussions or the NGINX Community Forum. You’ve got time to plan this migration right, but don’t wait until March 2026 to start.Simplifying and Securing Network Segmentation with F5 Distributed Cloud and Nutanix Flow
Introduction Enterprises often separate environments—such as development and production—to improve efficiency, reduce risk, and maintain compliance. A critical enabler of this separation is network segmentation, which isolates networks into smaller, secured segments—strengthening security, optimizing performance, and supporting regulatory standards. In this article, we explore the integration between Nutanix Flow and F5 Distributed Cloud, showcasing how F5 and Nutanix collaborate to simplify and secure network segmentation across diverse environments—on-premises, remote, and hybrid multicloud. Integration Overview At the heart of this integration is the capability to deploy a F5 Distributed Cloud Customer Edge (CE) inside a Nutanix Flow VPC, establish BGP peering with the Nutanix Flow BGP Gateway, and inject CE-advertised BGP routes into the VPC routing table. This architecture provides full control over application delivery and security within the VPC. It enables selective advertisement of HTTP load balancers (LBs) or VIPs to designated VPCs, ensuring secure and efficient connectivity. By leveraging F5 Distributed Cloud to segment and extend networks to remote location—whether on-premises or in the public cloud—combined with Nutanix Flow for microsegmentation within VPCs, enterprises achieve comprehensive end-to-end security. This approach enforces a consistent security posture while reducing complexity across diverse infrastructures. In our previous article (click here) , we explored application delivery and security. Here, we focus on network segmentation and how this integration simplifies connectivity across environments. Demo Walkthrough The demo consists of two parts: Extending a local network segment from a Nutanix Flow VPC to a remote site using F5 Distributed Cloud. Applying microsegmentation within the network segment using Nutanix Flow Security Next-Gen. San Jose (SJ) serves as our local site, and the demo environment dev3 is a Nutanix Flow VPC with an F5 Distributed Cloud Customer Edge (CE) deployed inside: *Note: The SJ CE is named jy-nutanix-overlay-dev3 in the F5 Distributed Cloud Console and xc-ce-dev3 in the Nutanix Prism Central. On the F5 Distributed Cloud Console, we created a network segment named jy-nutanix-sjc-nyc-segment and we assigned it specifically to the subnet 192.170.84.0/24: eBGP peering is ESTABLISHED between the CE and the Nutanix Flow BGP Gateway in this segment: At the remote site in NYC, a CE named jy-nutanix-nyc is deployed with a local subnet of 192.168.60.0/24: To extend jy-nutanix-sjc-nyc-segment from SJ to NYC, simply assign the segment jy-nutanix-sjc-nyc-segment to the NYC CE local subnet 192.168.60.0/24 in the F5 Distributed Cloud Console: Effortlessly and in no time, the segment jy-nutanix-sjc-nyc-segment is now extended across environments from SJ to NYC: Checking the CE routing table, we can see that the local routes originated from the CEs are being exchanged among them: At the local site SJ, the SJ CE jy-nutanix-overlay-dev3 advertises the remote route originating from the NYC CE jy-nutanix-nyc to the Nutanix Flow BGP Gateway via BGP, and installs the route in the dev3 routing table: SJ VMs can now reach NYC VMs and vice versa, while continuing to use their Nutanix Flow VPC logical router as the default gateway: To enforce granular security within the segment, Nutanix Flow Security Next-Gen provides microsegmentation. Together, F5 Distributed Cloud and Nutanix Flow Security Next-Gen deliver a cohesive solution: F5 Distributed cloud seamlessly extends network segments across environments, while Nutanix Flow Security Next-Gen ensures fine-grained security controls within those segments: Our demo extends a network segment between two data centers, but the same approach can also be applied between on-premises and public cloud environments—delivering flexibility across hybrid multicloud environments. Conclusion F5 Distributed Cloud simplifies network segmentation across hybrid and multi-cloud environments, making it both secure and effortless. By seamlessly extending network segments across any environment, F5 removes the complexity traditionally associated with connecting diverse infrastructures. Combined with Nutanix Flow Security Next-Gen for microsegmentation within each segment, this integration delivers end-to-end protection and consistent policy enforcement. Together, F5 and Nutanix help enterprises reduce operational overhead, maintain compliance, and strengthen security—while enabling agility and scalability across all environments. This integration is coming soon in CY2026. If you’re interested in early access, please contact your F5 representative. Reference URLs https://www.f5.com/products/distributed-cloud-services https://www.nutanix.com/products/flow
getting compiling error when enabling Nginx App_potect
i m trying to install NGinx plus with App_ptotect but when trying to enable app_protect module after installing it i get the following error nginx: [emerg] APP_PROTECT config_set_id 1752649466-871-149162 not found within 45 seconds nginx: [emerg] APP_PROTECT fstat() "/opt/app_protect/config/compile_error_msg.json" failed (2: No such file or directory) and i can not start the nginx service, any idea about the issue?
