ASM not blocking
Hi all- I've been out of the loop using F5 for a couple of years and just coming back to it. I'm having a problem with ASM/AWAF working properly. I have a virtual server pointing to a single node running Apache. When I hit the virtual IP that works fine. I've attached an ASM/AWAF security policy to that server. Enforcement mode = Blocking Policy Building Learning mode = Manual I've included every attack signature group to the policy and moved all signatures out of staging to Enforced. I'm trying to get any signature to fire at this point. Any easy one should be to trigger 200010468 ("/etc/passwd" access URI) or 200010156 ("passwd.txt" access). When requesting either URI, ASM is allowing the requests through. Looking at the log for one of the requests, I can see that it does trigger the /etc/passwd signature, but apparently is still in staging: Decoded Request Request actual size: 85 bytes GET /etc/passwd HTTP/1.1 Host: 192.168.5.5 User-Agent: curl/7.64.0 Accept: */* Response Response logging was disabled Violation Details Attack signature detected [2] Detected Keyword /etc/passwd Attack Signature "/etc/passwd" access (URI) Context URL ActualURL /etc/passwd Wildcard URL *-Staging Applied Blocking Settings Staging Am I missing a setting somewhere? This is the status for that particular signature in my security policy: "/etc/passwd" access (URI) 200010468 Enforced
iRule - HTTP::is_redirect failing
We have used this iRule for many years to block PDFs from being accessed directly, unless a user logs in and comes from an allowed domain. After upgrading from 10.2.4 to 11.2.1 and then to 11.6, the iRule fails to work and complains in the ltm log: TCL error: /Common/block-pdf-searches - Operation not supported (line 1) invoked from within "HTTP::is_redirect" I've done some testing and I've confirmed that I'm able to do a simple log local0. if the http response is HTTP::is_redirect, so it seems like the syntax is supported. Can anyone find what may be wrong here? when RULE_INIT { 0=disable checking paths 1=check referer if requested URL is in "referer_check_paths" (default allow) 2=check referer if requested URL is NOT in "referer_check_paths" (default deny) set ::setting_check_paths 0 0=exact match for path check 1=starts_with match of path check set ::setting_path_check_starts_with 0 0=disable filetype checking 1=enable filetype checking set ::setting_check_filetypes 1 Set appropriate URL to send the user to set static::error_url {https://[HTTP::host]} END OF CONFIGURABLE PARAMETERS if { $::setting_path_check_starts_with == 1 } { set ::match_with "starts_with" return } set ::match_with "equals" } when HTTP_REQUEST { set error 0 if { $error == 0 && $::setting_check_filetypes == 1 && [matchclass [HTTP::path] ends_with referer_check_filetypes] } { set error 1 } if { $error == 0 && $::setting_check_paths == 1 && [matchclass [HTTP::path] $::match_with referer_check_paths] } { set error 1 } if { $error == 0 && $::setting_check_paths == 2 && ( not [matchclass [HTTP::path] $::match_with referer_check_paths] ) } { set error 1 } if { $error == 0 } { return } set refer_host [string tolower [URI::host [HTTP::header Referer]]] if { $refer_host == "" || [matchclass $refer_host contains referer_allowed_hosts] } { return } set info " NOTICE: Entry point bypass detected from host: $refer_host" append info " client { [IP::client_addr]:[TCP::client_port] -> [clientside {IP::local_addr}]:[clientside {TCP::local_port}] }" append info " ethernet { [string range [LINK::lasthop] 0 16] -> [string range [LINK::nexthop] 0 16] tag [LINK::vlan_id] qos [LINK::qos] }" append info " - [HTTP::version] - REDIR [HTTP::is_redirect], Content-Length [HTTP::header Content-Length], Transfer-Encoding [HTTP::header Transfer-Encoding]" append info " *TCP MSS([TCP::mss]) BW([TCP::bandwidth]) RTT([TCP::rtt]) OFFSET([TCP::offset])" append info " *IP TOS [IP::tos], HOPS [IP::hops], TTL [IP::ttl]" append info " *HTTP HOST [HTTP::host], KEEPALIVE [HTTP::is_keepalive], REQ_NUM [HTTP::request_num]" log local0. $info Set cache control headers on the redirect to prevent proxies from caching the response. HTTP::respond 302 Location [subst $static::error_url] Cache-Control No-Cache Pragma No-Cache }
ASM from blocking to transparent mode
Hello everyone, I apologize if this has already been asked here on this forum, but from the search I did I only found the opposite question, which is normal. Can anyone tell me what precautions or possible impacts there might be when changing the ASM from blocking to transparent? And will it just stop blocking all violations or will it keep the blocks it has cached from the previous (blocking) configuration? thank you all in advance for your time
F5 ASM learning new parameters while being in blocking mode.
Hi, I have my ASM protecting many web applications. The problem is that some of the applications/websites, don´t have that much traffic, but some of the websites have a lot of Forms etc. Since the traffic is not to much, it didn´t learned all of the parameters of the website while it was on transparent mode, and even some of the parameters learned don´t have all the meta characters allowed. Question 1: If i disable the value meta character on the parameter itself, does it still block attacks like XSS, SQLi etc? Question 2: Is there a way to have my policies in block mode, but do not block new parameters that are added by developers as an example, and then accessed by users? Question 3: Do you guys keep the Wildcard * parameter in blocking state or leave it in staging ? Question 4: When policy is in automatic, i detected that if a parameter in the website that should allow alpha-numeric values, if it gets a lot of hits by users that just post numeric values ( lets say username) the policy change the parameter data type to integer itself, and after that if some user as a username that have letters in it, will get blocked. What is the better way to get over this. Manual (extensive work checking all the policies every day) or automatic ( some things stop working after some time so have to correct it mannually), or is there and alternative in the Learning and blocking settings that allow to loosen the policy keeping it secure and manageable?ASM 13.1.0.x Brute Force - how to configure?
Hi, I am not sure when this protection changed but for sure it is quite different in version 13.1.0.8. There is plenty of new settings there - problem is I can't figure out how to set it up for best protection. When only Username is set then only protection is CAPTCHA - you can attempt to guess password as many times as you wish (if you resolve CAPTCHA) - explanation is to protect user from being locked out when his account is under attack - so far so good. There is one issue here - Your support ID. It's shown each time CAPTCHA is displayed but there is no matching entry in Even Log (All request and responses logged). Even when requests are reported as Illegal (but of course not blocked) Support ID in such request do not match one displayed to user - so what is purpose for displaying Support ID below CAPTCHA? If no other setting will be configured (Device ID, IP) then attacker can repeat attack forever - or until security will notice it and block given user name. Only way to actually block login attempt is to configure either Device ID or IP Address failed logins setting. But if any of above will be configured to Alarm and Blocking page (or Drop) then real user that made mistake will be blocked as well - so not being able to block on username is a bit artificial here. Now there is a question how to unlock such blocked IP? I can't see any way. Another issue I noticed is that for some reason (even if Device ID Tracking is enabled in Session Tracking) no Device ID is reported - is there some minimal number of request necessary to identify given device? I wonder what is good mix of settings there to: Actually do not block real user that forgot password from being locked out Do not allow malicious user to continue guessing forever (if he can afford CAPTCHA solving solution) Only way to block login after given number of resolved CAPTCHA and failed attempts is to set CAPTCHA Bypass Mitigation - but it only works for IP Address and Device ID not Username. Assuming that real user will rather try to login from the same IP Address and/or Device ID then in the end real user will be locked out. Then again there should be some way to unlock - and I can't see it. If attack is distributed (different IPs and Device ID) then not being able to block based on Username looks to me as week spot. Attacker can limit number of attempts per IP to a small number and bypass protection. Based on default settings it is possible to perform up to 9 (4th attempt trigger CAPTCHA, then 5 attempts after solving CAPTCHA) attempts per IP without being locked out. New settings are for sure more powerful but it is not so easy to figure out relations between them and create optimal combination. Piotr
ASM 13.1.0.x Brute Force - how to configure?
Hi, I am not sure when this protection changed but for sure it is quite different in version 13.1.0.8. There is plenty of new settings there - problem is I can't figure out how to set it up for best protection. When only Username is set then only protection is CAPTCHA - you can attempt to guess password as many times as you wish (if you resolve CAPTCHA) - explanation is to protect user from being locked out when his account is under attack - so far so good. There is one issue here - Your support ID. It's shown each time CAPTCHA is displayed but there is no matching entry in Even Log (All request and responses logged). Even when requests are reported as Illegal (but of course not blocked) Support ID in such request do not match one displayed to user - so what is purpose for displaying Support ID below CAPTCHA? If no other setting will be configured (Device ID, IP) then attacker can repeat attack forever - or until security will notice it and block given user name. Only way to actually block login attempt is to configure either Device ID or IP Address failed logins setting. But if any of above will be configured to Alarm and Blocking page (or Drop) then real user that made mistake will be blocked as well - so not being able to block on username is a bit artificial here. Now there is a question how to unlock such blocked IP? I can't see any way. Another issue I noticed is that for some reason (even if Device ID Tracking is enabled in Session Tracking) no Device ID is reported - is there some minimal number of request necessary to identify given device? I wonder what is good mix of settings there to: Actually do not block real user that forgot password from being locked out Do not allow malicious user to continue guessing forever (if he can afford CAPTCHA solving solution) Only way to block login after given number of resolved CAPTCHA and failed attempts is to set CAPTCHA Bypass Mitigation - but it only works for IP Address and Device ID not Username. Assuming that real user will rather try to login from the same IP Address and/or Device ID then in the end real user will be locked out. Then again there should be some way to unlock - and I can't see it. If attack is distributed (different IPs and Device ID) then not being able to block based on Username looks to me as week spot. Attacker can limit number of attempts per IP to a small number and bypass protection. Based on default settings it is possible to perform up to 9 (4th attempt trigger CAPTCHA, then 5 attempts after solving CAPTCHA) attempts per IP without being locked out. New settings are for sure more powerful but it is not so easy to figure out relations between them and create optimal combination. PiotrF5 as gateway cannot connect on 2nd attempt
Hi Guys, We have an issue with the server 192.168.1.10 that is connected on F5 (F5 is its gateway). So the scenario is When we connect on the server 192.168.1.10 port 80 it is successful When we connect on the server 192.168.1.10 port 80 it is NOT successful We are using same source server. Is there any possible blocking on the f5 side? By the way the source server is also under the F5
Blocking multiple IPs with iRules
Hi, I am trying to block multiple IP's with iRules but unable to do so. Currently using the below command, but everytime there is a new ip, I need to create an iRule for that & bind it to the virtual server. when CLIENT_ACCEPTED { if { [IP::addr [IP::client_addr] equals 1.1.1.1/32] } { log local0. "Blocking [IP::client_addr]" reject } } Is there a way to create a group where all IP addresses can be added & automatically blocked? or what is the best way of doing so? probably a nested If statement. Thanks for the help. ChadiBlock HTTPS access from specific user agent
Dear community, I want to block HTTPS access from specific user agent(UA). I found this topic following, https://devcentral.f5.com/questions/block-a-user-agent-with-an-irule and I want some idea to arrange this iRule as following. -I want to show "404" to this access and reject to accessing our web server. -I sometime want to allow specific IP address using blocked UA. How can I make such exception? the original one is below. when HTTPS_REQUEST { log local0. "User-Agent:[HTTPS::header "User-Agent"]" if { [string tolower [HTTPS::header "User-Agent"]] == "mozilla/4.0"} { drop log local0. "Rejected request: [IP::remote_addr] User-Agent:[string tolower [HTTPS::header "User-Agent"]] requested [HTTPS::host][HTTP::uri]" } } Thanks in advance for your help, Naoki