No CAPTCHA - URL is not yet qualified for challenge injection
Hi, I am setting up Brute Force protection in ASM and have noted that I can get this drop traffic and alert, but when attempting to show the CAPTCHA, I only get the blocking page we have configured. The help notes that this occurs when theURL is not yet qualified for challenge injection, but the help also provides no details how to correct this. Can anyone assist? Assuming ASM policy: PolicyX and url: /LoginHere.aspx Thank you
Syslog irule corrupts the web page with Captcha configuration
Hi, We have an irule to send vs traffic through the syslog. But when we enable the page does not work. The webpage is configured with captcha. Have you any suggestions for this issue? Thanks. when HTTP_REQUEST { set http_method HTTP/[HTTP::method] set http_uri HTTP/[HTTP::uri] set http_version HTTP/[HTTP::version] set http_request_time [clock clicks -milliseconds] set http_user_agent "\"[HTTP::header User-Agent]]\"" set http_host [HTTP::host] set http_username [HTTP::username] set client_ip [IP::remote_addr] set client_port [TCP::remote_port] set http_request_uri [HTTP::uri] set request_content_length 0 if { [HTTP::header exists "Content-Length"] } { set request_content_length [HTTP::header "Content-Length"] } set request_content_type [HTTP::header "Content-type"] set referer [HTTP::header value referer] set now [clock format [clock seconds] -format "%Y-%m-%d %H:%M:%S"] } when HTTP_RESPONSE { set response_time [expr [clock clicks -milliseconds] - $http_request_time] set virtual [virtual] set content_length 0 if { [HTTP::header exists "Content-Length"] } { set content_length [HTTP::header "Content-Length"] } set lb_server "[LB::server addr]:[LB::server port]" if { [string compare "$lb_server" ""] == 0 } { set lb_server "" } set status_code [HTTP::status] set content_type [HTTP::header "Content-type"] set log_msg "" append log_msg "virtual=$virtual|" append log_msg "client_ip=$client_ip|" append log_msg "client_port=$client_port|" append log_msg "lb_server=$lb_server|" append log_msg "request_content_type=$request_content_type|" append log_msg "$request_content_length|" append log_msg "$http_request_time|" append log_msg "host=$http_host|" append log_msg "username=$http_username|" append log_msg "$http_method|" append log_msg "$http_uri|" append log_msg "http_version=$http_version|" append log_msg "server_status=$status_code|" append log_msg "response_content_type=$content_type|" append log_msg "$content_length|" append log_msg "$response_time|" append log_msg "user_agent=$http_user_agent|" HSL::send [HSL::open -proto UDP -pool POOLNAME] $log_msg log -noname IP:PORT local0. $log_msg log local0. $log_msg
APM Capcha based on source IP
hey, i have a requirement to show captcha on APM login based on the source IP of the clint. i am using the built in captcha on the APM. is there a simple way to do it? i thought about moving the login page to a macro block and have 2 login pages one with captcha and the other without captcha, however the logon page is customized is there a way to clone and move the logon page to the macro block saving all the page design and customizations ? thanks dor
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. Piotr