ASM Attack Signatures "Ready to be Enforced" change with iControl Rest API v17.1.x
Hi, Did anyone found out yet how to change the attack signatures that are "Ready to be Enforced" in v17.1.x can be change to "enforced" true Rest API ?? i'm trying to using this url: https://localhost/mgmt/tm/asm/policies/[policy-id]/signatures?ver=17.1.2 i can change all staging ones but but find to combination with "Ready to be Enforced" items. in K94215981 the talk about the attributes "hasSuggestions, "wasUpdatedWithinEnforcementReadinessPeriod" but it looks like the dont exist anymore in v17.1.x Any help is welcome. GIU -> Security > Policies > Policy List > (policy name) > Attack Signatures menu, and filter Status: Ready to be enforced.
F5 ASM API-Protection Policy
Hello F5 Community, Apology if my question looks stupid since iam new to F5. Recently our application starting a project which is communication between our clients and our application through API and for me as f5 administrator its my rule to protect this API communication and as i looked up in the Application Security API template there is a section which ask for the swagger file and when i asked our application team their respond was (we have 3 API endpoints so we have 3 swagger files and not one) and right now iam looking forward to check whats the best design and to how handle this request or whats the best scenario to create and deploy this policy. Is it one of below: -Asking application team to merge these swagger files and provide it to me ?which they initially respond that they can not do that and this is risky. -Creating 3 Application policy and attach it to the same virtual server (if possible)? WE are using on-primes BIG-IP. Please let me know of your thoughts and let me if you prefer additional solution over this. Thanks. Regards,
Is XFF a must for ASM WAF DoS
In this article it is mentioned that you must configure "Accept XFF" in HTTP profile in order to use DOS or Bot protection. https://my.f5.com/manage/s/article/K000133493 "HTTP profile is required also and have XFF enabled is the minimum setting needed" On the other hand in this article it says https://my.f5.com/manage/s/article/K36452759 "If the setting "Accept XFF" is not enabled in the HTTP profile associated with the virtual server using bot or DoS, then the source IP of the traffic as it arrives to the BIG-IP will be used instead." "Note: Ensure this header name is inserted by a trusted source. If you do not trust the header showing the original client IP it may be maliciously altered." "XFF, or equivalent client IP headers, must be configured to be trusted in the HTTP profile for use with Bot Defense and Application DoS profiles" This creates some confusion It is unclear whether XFF is a mandatory. Is it? If there is no trusted proxy in front of F5 and the the actual source IP (as it arrives at F5) is the public source IP, which is the relevant IP to us, does "Accept XFF" still need to be configured? Thank you
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"
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 } }
ASM don't block attack XSS
hi all, I enabled all the XSS signatures and all signatures are state no staging. why the asm don't block this : <script>alert("attack")</script> It match to some Attack Signature ID : 200101609 , 200001088, 200000098, 200001475 Here is state of signature ID 200001475 Thanks.F5 not Identifying Parameter in Text/Plain Upload
In a webkit: content disposition header, name="file" ; filename="EXAMPLE DOCUMENT 2024.txt" Content-type: text/plain Document data example system ( The issue is that there is already a parameter built at the URI for file as an upload, set to block executables. Yet, it seems that the F5 continues to scan the document and it is not picking up the built parameter. Is it doing this by design? Since F5 is able to parse text? This seems to happen on uploads whose content types are text and xml.
