Incosistent forwarding of HTTP/2 connections with layered virtual
Hi, I'm using a layered virtual configuration: Tier1: Virtual applying SNI-Routing (only SSL persistence profile and LTM policy as described in https://www.devcentral.f5.com/kb/technicalarticles/sni-routing-with-big-ip/282018) Tier2: Virtual applies SSL termination and delivering the actual application, with the required profiles, iRules, .... If the required, an additional LTM policy is applied for URI-based routing and forwards to Tier3 VS. Tier3 (optional, if required): Virtual delivers specific applications, like microservices, usually no monolithical apps. This configuration is very robust and I'm working with it successfully since years. Important: The tier1 uses one single IP address and a single port. So all tier2 and tier3 virtuals MUST be externally available through the same IP address and port. Now I have to publish the first HTTP/2 applications over this concept and see strange behavior of the BIG-IP. User requests www.example.com. IP and port point to tier1 virtual. Tier1 LTM policy forwards the requests, based on the SNI, to tier2 virtuals "vs-int_www.example.com". Within www.example.com there are references to piwik.example.com, which is another tier2 virtual, behind my tier1 virtual. User requests piwik.example.com. IP and port point to tier1 virtual. Tier1 LTM policy forwards the requests to "vs-int_www.example.com" instead of "vs-int_piwik.example.com". Probably not based on SNI, but on the existing TCP connection. I'm afraid, that this bahvior is a result of HTTP/2, especially because of the persistent TCP connection. I assume that, because the connection ID (gathered from browser devtools) for requests to www.example.com and piwik.example.com is identical. From the perspective of the browser I wouldn't expect such a behavior, because the target hostname differs. I didn't configure HTTP/2 in full-proxy mode, as described in several articles. I've just enabled it on the client-side. I would be very happy for any input on that. Thanks in advance!Remote log WAF based on number of violations
Hi All, At a customer I have configured a WAF to protect their web applications. Also configured a Logging Profile to send the logging to a remote server. This works fine. But customer would like to have some control on what is being send to the remote server and when. So the log of a violation that only occurs once (within a certain time frame) does not need to go to the remote log server. But a (identical) violation that occurs serveral times and has a high security violation needs to be send to the remote server I know I can configure a filter to include or exclude what is being send to the remote server. But can the F5 WAF send logs to a remote server based on number of events within a time frame? Hope you can help or point me to some useful links or documents. Regards, MartijnMitigating Application Threats with BIG-IP Next WAF
Overview of BIG-IP Next In today's modern world where the digital landscape is continuously evolving and security threats are becoming more sophisticated, the need for a robust and adaptive security solution is essential. BIG-IP Next is a next-generation solution which is setting a new standard for safeguarding your digital assets, protecting your applications, and empowering enterprises with the highest security efficacy.BIG-IP Next is the modernized solution optimized to simplify operations, enhance performance, and strengthen security. As per the official website, BIG-IP Next simplifies day-to-day ADC operations and accelerates application time-to-market through automation so that you can focus more on getting your apps online. BIG-IP Next’s modern, highly scalable software architecture is designed for maximum resiliency to support vast, dynamic application portfolios and their most complex traffic management and security policies, ensuring that applications are always available to end users. BIG-IP Next also provides deep insights into your application health, network performance, traffic patterns, and security threats to improve business decision-making. For a quick overview of BIG-IP Next and how the next-generation attributes can help you with your existing or new deployments, check out the video below. Here are some of the key capabilities that you can checkout and learn how you can mitigate app threats and security complexity with BIG-IP Next WAF: 1. Deploy HTTPS application with WAF Protection The first step in protecting your applications starts with onboarding your application in BIG-IP Next instance and creating a WAF security policy as per application requirements. Finally creating load balancers and applying the above-created WAF policies. Next, users can monitor the application traffic by navigating to their respective security dashboards and take necessary steps as per security insights. For more details, see this video. 2. Create and Manage Security Policies Sometimes creating security policies can be a time-consuming job, and BIG-IP Next has made this user-friendly for creating and managing security policies from a centralized UI. Users can create, delete or update their existing policies in fewer steps and can apply them directly to the applications, thereby decreasing the application delivery time to market. You can check out the video below for more details. 3. Create Security Policies using Templates One more advantage of BIG-IP Next is the support for creating security policies using templates and it’s just a one-click action using 'F5 BIG-IP Next’. Users can make use of default templates and protect their applications with zero effort, for ex. Using the Violation Rating Template. For more information, check below video. 4. Security Policy Migration Going through existing BIG-IP security policies and then creating the same ones in BIG-IP Next solution can be time-consuming. This is made easy so that users can migrate their security policy from 'F5 Advanced WAF' to 'F5 BIG-IP Next WAF' in a simple manner. With fewer steps, you can have your entire WAF security posture up without going through the rough step of creating them from scratch. Please refer to the video below for more insights. 5. Signatures and Threat Campaigns Update Regular update of attack signatures and threat campaigns is a vital step in safeguarding your applications against the latest attacks. This process is super easy using ‘F5 BIG-IP Next’ so that applications can mitigate them without the need for downtime. For step-by-step procedure to update signatures and threat campaigns, please check the video below. You can also check out the demo link below for detailed insights of how BIG-IP Next WAF enables the migration of apps and policies between BIG-IP TMOS and BIG-IP Next. The demo also shows how to deploy new web applications with WAF security policies included within BIG-IP Next Central Manager and finally how to analyze and respond to security incidents within the Next WAF dashboard. Reference links What is BIG-IP Next? | DevCentral Getting Started with BIG-IP Next: Fundamentals | DevCentral https://www.f5.com/products/big-ip-services/big-ip-next
Deploy WAF on any Edge with F5 Distributed Cloud (SaaS Console, Automation)
F5 XC WAAP/WAF presents a clear advantage over classical WAAP/WAFs in that it can be deployed on a variety of environments without loss of functionality. In this first article of a series, we present an overview of the main deployment options for XC WAAP while follow-on articles will dive deeper into the details of the deployment procedures.
Enterprise Security best practices with F5 WAF
When it comes to responsibilities of each layer in an enterprise (i.e. DMZ/ WAF, application, SoR etc), and provided F5 Advanced WAF is deployed on the DMZ, should other layers assume primary responsibility of mitigations supported out-of-the-box by F5 WAF. i.e. Provided that F5 WAF supports bot defense, should the the layer below (application layer) as well be hardened to defend against bots by implementing features like fingerprinting, validating remote IPs based on HTTP headers etc? Certain defense mechanisms - specifically in the case of bot defense, go beyond the expertise of typical application development and having application developers to harden their apps against bots will just add overhead IMO, however one can still argue it's agains defense in depth. What's the best practice and guideline F5 provides?
ASM instance creation
HI Team , I have to create an WAF instance similar to the one which is already available . I need help on creating the ASM policy similar to the one which is already used by other VIP . So my ASM policy name is ASM_NETWORK_443 and I have to create an identical policy with name ASM_DRNETWORK_443 . Is there any option to clone the ASM policy or export and import the policy and rename the Policy name ? Kindly help me on this .
ltm policy asm_auto_l7_policy
Hi Experts, We are migrating WAF in an HA pair from i4800 to i5800, UCS is loaded successfully on new pair. while comparing the configurations i found on some policy on previous node the status was legacy and on new node the status is published. what's the difference please? the status is highlighted in red in below config. old node config ltm policy asm_auto_l7_policy__epsite.telenorbank.pk { controls { asm } last-modified 2023-12-08:23:19:30 requires { http } rules { default { actions { 1 { asm enable policy /Common/PTCL-cloud_WAF } } ordinal 1 } } status legacy strategy first-match7 } New Node config ltm policy asm_auto_l7_policy__epsite.telenorbank.pk { controls { asm } last-modified 2024-04-17:13:00:12 requires { http } rules { default { actions { 1 { asm enable policy /Common/PTCL-cloud_WAF } } ordinal 1 } } status published strategy first-match }
Deploying F5 WAF in front of Azure Web App Services
Does anyone know of a supported architecture for deploying an Azure F5 WAF in front of Azure Web App Services to handle the SSL and ASM services against traffic destined for an Azure Web App Service (App Service not just an app server running in Azure).
