ASM Login Page protection for Basic Authentication without failed string
Hello, Its possible to create and configure an ASM Login Page for Brute Force protection to a system that uses APM Basic Auth (401) and does not send any String for failed/wrong username? According the F5 Documentation on how to create a Login page, its needs to configure a failed string: A string that should NOT appear in the responseA string that indicates a failed login attempt and prohibits user access to the authenticated URL; for example, Authentication failed. Ref: https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-asm-implementations-14-1-0/creating-login-pages-for-secure-application-access.html So my question is, its possible to configure APM to send 401 with an failed string, so it can be detected by ASM on Brute Force Login Mitigation? **For the ASM protection on APM VS, im using the layered Virtual Server configuration.
ASM Brute Force Protection feature inserts the script to response headers. How it may be removed?
Hello, We have faced with a problem, when Brure Force Protection feature inserts the script to response header. I have pasted the script below. The fact is that script is inserted for each application resource URL and break some of its functions. From the configuration of Brute Force Protection, we have only one login page with Username and IP Addres protection and Alarm and CAPTCHA mitigation. Additionaly we have Distributed Brute Force Protection being configured. for Alarm and CAPTCHA mitigation. No Client Side Integrity Bypass Mitigation andCAPTCHA Bypass Mitigation. Any ideas how to switch of the script insert and move on with simple User login attempts tracking only? -----the script----- <script type="text/javascript"> (function(){ window.PXtt=!!window.PXtt;try{(function(){(function(){})();var b=81;try{var ba,da,ma=c(71)?0:1;for(var pa=(c(608),0);pa<da;++pa)ma+=(c(854),3);ba=ma;window.Pa===ba&&(window.Pa=++ba)}catch(a){window.Pa=ba}var e=!0;function f(a,d){a+=d;return a.toString(36)}function sa(a){var d=42;a&&(document[p(d,160,147,157,147,140,147,150,147,158,163,125,158,139,158,143)]&&document[p(d,160,147,157,147,140,147,150,147,158,163,125,158,139,158,143)]!==f(68616527624,d)||(e=!1));return e} function p(a){var d=arguments.length,g=[];for(var h=1;h<d;++h)g.push(arguments[h]-a);return String.fromCharCode.apply(String,g)}function va(){}sa(window[va[f(1086773,b)]]===va);sa(typeof ie9rgb4!==p(b,183,198,191,180,197,186,192,191));sa(RegExp("\x3c")[f(1372124,b)](function(){return"\x3c"})&!RegExp(f(42808,b))[f(1372124,b)](function(){return"'x3'+'d';"})); var wa=window[t(b,178,197,197,178,180,185,150,199,182,191,197)]||RegExp(t(b,190,192,179,186,205,178,191,181,195,192,186,181),f(-63,b))[t(b,197,182,196,197)](window["\x6e\x61vi\x67a\x74\x6f\x72"]["\x75\x73e\x72A\x67\x65\x6et"]),xa=+new Date+(c(66)?883940:6E5),ya,Aa,Ca,Da=window[p(b,196,182,197,165,186,190,182,192,198,197)],Ga=wa?c(280)?41740:3E4:c(40)?5090:6E3; document[p(b,178,181,181,150,199,182,191,197,157,186,196,197,182,191,182,195)]&&document[p(b,178,181,181,150,199,182,191,197,157,186,196,197,182,191,182,195)](p(b,199,186,196,186,179,186,189,186,197,202,180,185,178,191,184,182),function(a){var d=53;document[t(d,171,158,168,158,151,158,161,158,169,174,136,169,150,169,154)]&&(document[t(d,171,158,168,158,151,158,161,158,169,174,136,169,150,169,154)]===f(1058781930,d)&&a[p(d,158,168,137,167,170,168,169,154,153)]?Ca=!0:document[t(d,171,158,168,158,151, 158,161,158,169,174,136,169,150,169,154)]===f(68616527613,d)&&(ya=+new Date,Ca=!1,z()))});function z(){if(!document[t(86,199,203,187,200,207,169,187,194,187,185,202,197,200)])return!0;var a=+new Date;if(a>xa&&(c(971)?357226:6E5)>a-ya)return sa(!1);var d=sa(Aa&&!Ca&&ya+Ga<a);ya=a;Aa||(Aa=!0,Da(function(){Aa=!1},c(151)?0:1));return d}z();var Ia=[c(518)?10764609:17795081,c(13)?27611931586:2147483647,c(291)?1738068546:1558153217]; function t(a){var d=arguments.length,g=[];for(var h=1;h<d;h++)g[h-1]=arguments[h]-a;return String.fromCharCode.apply(String,g)}function Ja(a){var d=75;a=typeof a===f(1743045601,d)?a:a[t(d,191,186,158,191,189,180,185,178)](c(919)?20:36);var g=window[a];if(!g||!g[t(d,191,186,158,191,189,180,185,178)])return;var h=""+g;window[a]=function(k,l){Aa=!1;return g(k,l)};window[a][p(d,191,186,158,191,189,180,185,178)]=function(){return h}}for(var Ka=(c(361),0);Ka<Ia[f(1294399124,b)];++Ka)Ja(Ia[Ka]); sa(!1!==window[t(b,161,169,197,197)]);window.Ea=window.Ea||{};window.Ea.Tb="0872e5a9b7194000fb04471cd1841afc6bba0c62c7db56573b9c11b63d25ddd1c1a44f037a57d1166fd77c497d0714ca9ba53a24cbbac8c76c2c3d741c020071564ba89bfedd964f";function B(a){var d=+new Date;if(!document[t(20,133,137,121,134,141,103,121,128,121,119,136,131,134,85,128,128)]||d>xa&&(c(136)?480406:6E5)>d-ya)var g=sa(!1);else g=sa(Aa&&!Ca&&ya+Ga<d),ya=d,Aa||(Aa=!0,Da(function(){Aa=!1},c(580)?0:1));return!(arguments[a]^g)}function c(a){return 33>a}(function La(a){return a?0:La(a)*La(a)})(!0);})();}catch(x){}finally{ie9rgb4=void(0);};function ie9rgb4(a,b){return a>>b>>0}; })(); </script>
F5 ASM Start Page + Brute Force Protection - SoftLockout
Ver. 14.1 ASM Policy framework: ASM OWA Policy Trying to provide a soft lockout to user logins to OWA when they failed to auth 2 times and they have to wait 15 minutes and when we create the Brute Force Protection for the start page, we are seeing that UserID only has Alarm, Alarm and Client Side Integrity, and Alarm and CAPTCHA. Preferably, we would want the option to Alarm and Block when users keep hitting the VIP. NOW, we can provide some softlockout features if we also change the IP address action with Alarm and Blockm but the userID is the option we were hoping to provide the block at. With UserID set to Alarm and IP address to Alarm and Block, dont feel like we are getting the full soft out function as we want to monitor user login activity. Thoughts?OWA bruteforce protection with ASM
Hi, Have you ever tried to protect MS Outlook Web Access login page with ASM? I'm trying to set up brute force protection but don't have any luck. I made a login page with the following parameters: Login URL Explicit HTTPS /owa/auth.owa Authentication Type HTML Form Username Parameter Name username Password Parameter Name password Expected HTTP response status code 302 With this configuration I can see all requests including usernames in the Event Viewer. I expected that after enabling brute force protection for my login page I will have this page protected. But I don't. Could you please share with me your experience?
ASM, Reporting on brute force attacks not working
Hi all, I've implemented brute force protection for HTML form based and a JSON form based login pages using ASM 13.0 HF2. This is working fine in both cases - requests are blocked when the thresholds for failed logins are exceeded and I get the correct violation in the request logs (Security>>Event Logs:Application:Requests), namely "Brute Force: Maximum login attempts are exceeded" and attack type: "Brute force Attack". However I don't get a single entry in neither the event log for Brute Force (Security>>Event Logs:Application:Brute Force Attacks) nor the Brute Force report (Security>>Reporting:Application:Brute Force Attacks). What am I missing? Thank you very much and kind regards, gha
ASM JSON login page
Hi, Trying to configure a JSON login page in ASM. The page first asks for the username and only then for the password. 1) When configuring JSON login in ASM, you must supply both the parameters( username and password), how can I configure only one? 2) In case I'ts possible to configure only one parameter, what is the best approach in this case? to configure 2 different login pages, each with one parameter( 1) password , 2)user)? Thanks, AlexASM 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. PiotrASM 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 Brute Force when app success/fail isn't the first response?
Hi guys, I've been looking at configuring ASM Brute Force protection for a couple of web apps. The challenge I'm hitting is that the app doesn't instantly respond with a success/fail criterion in the initial response to a POST. For one example you might enter your username/pass, hit post, then a 'checking your details' screen appears, waits a while then redirects you to either the success/fail pages. In another instance, username is on the initial screen, you hit post, the server then responds with a partial (generic) response before 302ing to the next screen where password chars are entered. That in turn follows the same pattern of partial response after a post, then a 302 to the eventual success page. Is there any way out of the box to use ASM Brute Force to protect apps of this type? Basically I seem to need to be able to protect based on subsequent responses rather than the immediate response to the initial post. Do the initial login pages defined in brute force have to be the pages with the login info form on? Or could I perhaps track the intermediate pages where the user hasn't physically typed anything in, but the subsequent response is where they'd finally be taken to the success/fail pages? I'd considered an iRule but again if login pages need to be the initial form, then the responses I'd need to trap in the iRule wouldn't be available until later in the session. TL;DR - Does ASM Brute Force have to be defined against the page with a form on it, or can I target deeper into the app's login process..? Thoughts and comments appreciated! Dan
How to know if a certain policy has brute force , DDOS Attack etc mitigation?
Hi All/DC Expert, Your expertise please, I am new at ASM and I want to know it is possible to see if a certain ASM policy has brute force attack mitigation. I know in my self that it has because I configured it. But what if I another person will review the policy something like that. Thank you. -Nat
