Switch ssl profile based on weak cipher detection via IRULE
Hi Team, I am looking to create an IRULE to switch ssl profile, if weak cipher detected on tls1.2connection I have created below script but it not accepting on f5 and giving error. Please help me correct below IRULE. IRULE:- when CLIENTSSL_HANDSHAKE { set hsl [HSL::open -proto UDP -pool POOL-SPLUNK-SYSLOG] # List of ciphers to log set log_ciphers { "AES256-GCM-SHA384" "AES128-GCM-SHA256" "ECDHE-RSA-AES256-CBC-SHA" "ECDHE-RSA-AES128-SHA256" "AES256-SHA" "AES128-SHA" "AES128-SHA256" "ECDHE-RSA-AES256-SHA384" } # Get the negotiated cipher set negotiated_cipher [SSL::cipher name] # Apply profile based on TLSv2 if { [string match "*TLS1.2*" $negotiated_cipher] } { SSL::profile weak_cipher_profile } else { SSL::profile strong_cipher_profile } # Log details for specific ciphers if { [lsearch -exact $log_ciphers $negotiated_cipher] != -1 } { HSL::send $hsl "<190>, Cipher Matched: $negotiated_cipher, ClientIP:[IP::client_addr], F5 Vip:[IP::local_addr], Destination Port:[TCP::local_port]" } }
How to check the disabled rules in ASM Policy
Hi Experts , We would like to know the allowed/disbale url or Parameters configured for the Specific ASM policy . Example: www.example.com is the url for which I would like to know the rules applied . How can I check this? Any way I can pull the detailed configuration of ASM Policy from cli ?How to block specific User-Agent in ASM Policy
Hi Experts , We are getting many requests from specific IP with the User Agent libcurl .We would like to block this user agent containing curl . Could you please help to configure the rule in the existing ASM Policy? I would like to apply the Policy for the URI - /bluewhale/api/ProdSearch . Dec 19 12:08:29 F5-ASM-PROD-P1 ASM:"2024-12-16 12:08:28";"213.X.X.X";"20179";"192.168.30.35";"443";"/Common/PRD_ASM_SSL";"GET";"passed";"9232836799849750123";"301";"/bluewhale/api/ProdSearch/Search";"N/A";"N/A";"0";"N/A";"N/A";"N/A";"N/A";"Host: www.example.com\r\nUser-Agent: libcurl/8.10.1 r-curl/6.0.1 httr/1.4.7\r\nAccept-Encoding: deflate, gzip\r\nAccept: application/json, text/xml, application/xml, */*\r\nX-Forwarded-For: 213.X.X.X\r\n\r\n"5 Technical Sessions That Should Be Great: F5 AppWorld 2025
These F5 Academy sessions explore modern app delivery, security, and operations. The full list of sessions is on the F5 AppWorld 2025 Academy page - if you haven't yet registered you can do so here: Register for F5 AppWorld 2025 LAB - F5 Distributed Cloud: Discovering & Securing APIs API security has never been more critical, and this lab dives straight into the tough stuff. Learn how to find hidden endpoints, detect sensitive data and authentication states, and apply integrated API security measures to keep your environment locked tight. TECHNICAL BRIEFING - LLM Security and Delivery with F5’s Distributed Cloud Security Ecosystem AI is fueling the next wave of applications—but it’s also introducing new security blind spots. This briefing explores how to secure LLMs and integrate the right solutions to ensure your AI-driven workloads remain fast, cost-effective, and protected. LAB - F5 NGINX Plus Ingress as an API Gateway for Kubernetes Containerized environments and microservices are here to stay, and this lab helps you navigate the complexity. Configure NGINX Plus Ingress as a powerful API gateway for your Kubernetes workloads, enabling schema enforcement, authorization, and rate-limiting all in one streamlined solution. LAB - Zero Trust at Scale With F5 NGINX Zero trust principles become a whole lot more meaningful when you can scale them. Get hands-on with NGINX Plus and BIG-IP GTM to build a robust, scalable zero trust architecture, ensuring secure and seamless app access across enterprises and multi-cluster Kubernetes environments. LAB - F5 Distributed Cloud: Security Automation & Zero Day Mitigation In this lab, you’ll learn how to leverage advanced matching criteria and custom rules to quickly respond to emerging threats. Shore up your defenses with automated policies that deliver frictionless security and agile zero-day mitigation. Session Updates Coming in January 🚨 AppWorld's Breakout Sessions officially drop in January 2025 but here is a sneak preview! Check back in January to add these to your agenda. Global App Delivery With a Global Network How Generative AI Breaks Traditional Application Security and What You Can Do About It The New Wave of Bots: A Deep Dive into Residential IP Proxy Networks From ZTNA to Universal ZTNA: Expanding Your App Security Strategy --- See you at F5 AppWorld 2025! #AppWorld25Setting up BIG-IP with AWS CloudHSM
Recently I was working on a project and there was a requirementfor using AWS CloudHSM. F5 has documented the process to install the AWS CloudHSM client in the implementation guide. I found it light on details of what a config should look like and showing examples. So let's pickup where the article leaves you on having installed the client software what does a working configuration look like?
ASM/AWAF custom block page for specific violation
If you have a need to display a custom block page for a specific ASM/AWAF violation, you can use an iRule to achieve this. ASM/AWAF has the ability to modify the Response and Blocking pages within the ASM Policy itself but these block pages apply across all violations. Modifying the Response and Blocking pages within the policy can be useful if you need to add a corporate look and feel, or embed links or information to contact your support desk for further help etc. There may be cases where you need to display certain information on a block page related to a specific violation. Do have a good think about what negative effects this may have on your organisation, for advising an attacker that they were blocked for a specific reason could very well aid them in finding other ways around the block. The following example is based on ASM/AWAF being integrated with an ICAP server for file upload anti-virus scanning, targeting the VIRUS_DETECTED violation, however it can be manipulated for any violation(s) once you identify the name of the violation. The iRule contains a line to log out the violation name into /var/log/ltm whenever ASM/AWAF implements a block. Substitute "VIOLATION_VIRUS_DETECTED" with the logged violation name you are targeting. Firstly you need to configure your ASM/AWAF policy's "Trigger ASM iRule Events Mode" and set this to "Normal", this is found in the Advanced Settings area on the policy's General Settings. Save and apply the policy. This will enable ASM iRules to trigger. (Note this setting is relevant on later versions of BIG-IP, previous versions have an additional setting 'Trigger ASM iRule Events' which needs to be set to Enable). Then create an iRule based on the below, and attach it to the VIPs/Virtual Servers of which your ASM/AWAF policy is enabled on. To test, hit your web application/API to generate an ASM/AWAF block page for the specific violation you are wanting a custom block page for, and have a look in your /var/log/ltm log for the logged out "ASM Violation was: <violation name here>". Substitute this violation name in the iRule for the 'if' command where it is matching $asm_violation_name. Refresh the page (you may need to close/reopen the page, use an incognito window, or clear your cookies etc depending on your LTM VIP's configuration) trigger the same violation again, and you should now see the information as created in the iRule in the 'set response' section. The iRule could be modified to match on multiple violations by expanding out the 'if' command. when ASM_REQUEST_DONE { set asm_support_id [ASM::support_id] set asm_violation_name [ASM::violation_data] } when ASM_REQUEST_BLOCKING { log local0. "ASM Violation was: $asm_violation_name" if {$asm_violation_name contains "VIOLATION_VIRUS_DETECTED"} { HTTP::header remove Content-Length HTTP::header insert header_1 value_1 set client_ip [IP::client_addr] set response "<html> <head> <title>Request Rejected</title> </head> <body> AWAF has blocked your request due to the ICAP server indicating a file it scanned contained a virus.<br><br> <b>Your support ID:</b> $asm_support_id<br><br> <b>Source IP:</b> $client_ip<br> </body> </html>" ASM::payload replace 0 [ASM::payload length] "" ASM::payload replace 0 0 $response } }Securing Model Serving in Red Hat OpenShift AI (on ROSA) with F5 Distributed Cloud API Security
Learn how Red Hat OpenShift AI on ROSA and F5 Distributed Cloud API Security work together to protect generative AI model inference endpoints. This integration ensures robust API discovery, schema enforcement, LLM-aware threat detection, bot mitigation, sensitive data redaction, and continuous observability—enabling secure, compliant, and high-performance AI-driven experiences at scale.
