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?HTTP Brute Force Mitigation Playbook: Slow Brute Force Protection Using Behavioural DOS - Chapter 6
Brute Force attack is where attacker tries to find the password of users quickly, there are times when attacker is not in hurry and do make his attack go under the radar, using very slow brute force attack.It can not be detected by detection criteria of Brute force protection feature of Advanced WAF/ASM reason being if you try to tweak the setting to catch slow brute force attack then its very hard for ASM/Advance WAF to distinguish between attack and legitimate user login atttempt. We may use other protection available in ASM/Advance WAF to protect from Slow brute force attack. In this chapter to protect from Slow brute force attack we will use TLS signature generated by behavioural DOS. But first: Benefits, Limitation and Requirement. Benefits Benefit of using TLS fingerprint: Good and bad Clients can be differentiated based on SSL handshake. Once the Advance WAF/ASM is 100% confident user does not have to do anything to find out unusual/attack traffic pattern. This can be also used to protect mobile application as it does not use Javascript. Limitations To get TLS fingerprinting signature using BADOS legitimate traffic should be learned by Advanced WAF/ASM On ASM, Behavioural DOS can be configured on max 2 virtual servers, where as on Advanced WAF, Although there is no license limitation of attaching DOS profile with BADOS enable to Virtual server but it is not recommended to configure more then 70 BADOS enabled Virtual server per box. Requirements ASM/Advanced WAF license. Appropriate rights to access/make changes from GUI and command line. Some of the reporting is available only if AFM is provisioned in addition to the above mentioned modules. (If AFM is not provisioned you can still find the information using CLI) Proactiveness As a general rule, instead of waiting for attack and then take necessary action, We should always be proactive in defending attack. Preparation for mitigating slow Brute force attack. Slow brute force is very hard to detect, So most important thing to protect application from slow brute force attack is Advanced WAF/ASM should know the normal traffic. For that we can use Behavioral & Stress-based (D)DoS Detection option under DoS Protection profile of Advance WAF/ASM. For Configuring DoS Protection profile, to protect against slow brute force attack using TLS fingerprinting follow the below mentioned steps. Important:For BIG-IP ASM/Advance WAF 14.1.0, you can access theTLS fingerprinting signaturesconfiguration sectiononly when you had previously selectedUse Legacy Application Dos viewin theHTTP Propertiesconfiguration pop-up. Go to Security››DOS Protection ›› Protection Profiles››click create. Enter the profile name as per your requirement, select the family as HTTP and press Commit Changes to System Click on newly shown HTTP and then click configure settings for HTTP Family settings. Next click on Use Legacy Application DOS View Go to Behavioral and stress-based detection under Application security. Change operation mode to blocking and Threshold mode to automatic. Under Behavioral Detection and Mitigation enable Request signature detection along with TLS fingerprinting signatures and Use approved signatures only (In case you don’t want to use unapproved signature). Leave all the settings unchanged and click save and finished. (Make Sure Bad actors behavior detection is unchecked as we want to use TLS signature) Select Mitigation to Standard or as per requirement from available options and then Click save Next apply the newly created dos profile to the appropriate https virtual server. Go toLocal Traffic>Virtual Servers. Select the name of the HTTPSvirtual server. Go toSecuritytab and selectPolicies. ForDoS Protection Profile, selectEnabled. ForProfile, select the DoS profile created in above steps. Select theUpdatebutton. Let the normal traffic pass through the VS. This will allow ASM to learn the traffic. How do we know ASM is ready and is 100% confident about the normal traffic? Login to cli of BIGIP Run command “admd -s vs./Common/<VSname>+/Common/<DOSprofilename.info.learning>” For exampleadmd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info.learning You will see output as similar to the one mentioned below. vs./Common/BF-Test+/Common/Brute-Force-test.info.learning:[0, 0, 0, 0] Once the traffic starts passing through vs these values will increase. Each value has its own meaning as described below. A.baseline_learning_confidence: Description: in % how confident the system is in the baseline learning. Desired Value: > 90% B. learned_bins_count: Description: number of learned bins Desired Value: > 0 C. good_table_size: Description: number of learned requests Desired Value: > 2000 D. good_table_confidence: Description: how confident, as %, the system is in the good table Desired Value: Must be 100 for signatures You may run the command again if the Behavioral DoS is still learning Still learning admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info.learning Behavioural DOS feature is based on learning analysing all traffic to the web application, building baselines, and then identifying anomalies when server stress is detected.So its important to know when server is stress and how to check the server street level. To find out the stress level Go to Security››DoS Protection››Protected Objects(This option is only available if you have AFM Provisioned) Find out the VS for which you would like to check the status and Click the arrow below Attack status. Once you click you will detailed informed is displayed on the screen, which includes Server Stress To check the Server stress using CLI you may run below mentioned command. admd -s vs./Common/<VSname>+/Common/<DOSprofilename.sig.health> Server Stress value Range: If there is no traffic server value is 0.5 If server functions properly value is between (0,1) Value higher then 1 is considered as load and mitigation may be applied for example admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.sig.health Once the output of below command shows appropriate values (as mentioned above) which tells ASM is confident, ASM is ready to differentiate between normal and attack traffic. Below output shows ASM is 100% confident admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info.learning Slow brute Force attack has been reported To check the status of attack and Server stress level. Go to Security››DoS Protection››Protected Objects(This option is only available if you have AFM Provisioned) Find out the VS for which you would like to check the status and Click the arrow below Attack status. Once you click you will see detailed informed is displayed on the screen. For example as show below Server Stress is 100 now. If AFM is not provisioned you may run below mentioned command to check if the server is under stress. admd -s vs./Common/<VSname>+/Common/<DOSprofilename.sig.health> Server Stress value Range: If there is no traffic server value is 0.5 If server functions properly value is between (0,1) Value higher then 1 is considered as load and mitigation may be applied For example admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.sig.health You may continue to monitor the output using command line or GUI to find out if attack has started. To check if attack has started you may check using command line. If the value is 0,0 then there is no attack if the value is 1 VS is under attack admd -s vs./Common/<VSname>+/Common/<DOSprofilename.info> for example: admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info Using the GUI Go to Security››DoS Protection:Protected Objects Note: (To get this view AFM should be provisioned ) If you continue to monitor you may notice that BADOs has started generating signature. But accuracy in start will not be 100% and it may take some time to become 100% accurate. Using CLI admd -s vs./Common/BF-PHP+/Common/ASM-TLS-Fingerprinting.info Using GUI Security››DoS Protection››Protected Objects(This option is only available if you have AFM Provisioned) If the Dynamic Signature status is unready the signature is not ready and does not have 100% accuracy. Note: (To get this view AFM should be provisioned, If AFM is not provisioned you may continue monitor using CLI ) Once signature is ready Dynamic signature status will change as shown below. Note: (To get this view AFM should be provisioned, If AFM is not provisioned you may continue monitor using CLI ) Once the signature’s accuracy is 100%, It will be available underSecurity››DoS Protection:Signatures >> Dynamic. As shown below. You may notice in above screenshot that Accuracy of signature is 100% where as approval status is Unapproved, If you want to use only approved signature (which we have used in this case) you need to click the check box infront of the signature, as soon as you will enable check box a window on right side will pop up and you may enable check box in-front of Approved and then press update to manually approve the signature. Note: User approved signatures only under Behavioral & Stress-based (D)DoS Detection in the DOS profile should be enable. Once you approve the signature, Signature approval state will change to manually approved as shown below You may also check DOS logs by checking Security››Event Logs››DoS›› Application Events Another Graphical view option for DOS can be checked by going to Security››Reporting:DoS:Dashboard If you want to check a specific attack ID then please on right side under Attack IDs find the attack ID and click on it. As soon as you will click on it page will show the data related to specific attack ID as shown below. As shown above during attack, TLS signature generate by Behavioural DOS ismitigating the attack and normal requests are still passing through using Behavioural attack signature. Note: By default, when the systemidentifies signature pattern anomalies, itsilently drops the connection. You can change the mitigation mode and force the system to send a reset(RST) when the traffic matches a signature pattern. To change the mitigation mode fromdrop to reset, perform the following steps: 1. Log in to tmsh by typing the following command: tmsh 2. To change themitigation mode to reset, typethe following command: modify sys db adm.mitigation.accelerated.signatures.drop.mode value reset Note: If you want to generate HTTP signature using BADOS instead of TLS signature in DOS protection profile you can select accelerated signature and rest of the steps will remain same.
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. PiotrDoS and NTLM Brute force protection for HTTP(s) traffic
Problem this snippet solves: This snippet has been designed to mainly protect against NTLM's Denial of Service and brute force attacks against web application that use this authentication mecanism. This irule help companies to fight against brute force attacks at the HTTP layer. You can combine this irule with another one on non-http traffic to provide a brute force protection across multiple layers. For pure HTTP application, you should prefer the Brute force protection provided by the ASM module. How to use this snippet: This irule should be installed on each Virtual Server that require NTLM protection. In a Microsoft Skype for Business deployment, you may need to protect following services : Web Services Conf Autodiscover Exchange Web Services TO BE DONE : Provide a way to unlock blocked users External links Github : https://github.com/e-XpertSolutions/f5 Related Articles DoS and NTLM Brute force protection for SIP flow Credits This irule is based on NTLM logger Code : when RULE_INIT { array set NTLMFlags { unicode 0x00000001 oem 0x00000002 req_target 0x00000004 unknown1 0x00000008 sign 0x00000010 seal 0x00000020 datagram 0x00000040 lmkey 0x00000080 netware 0x00000100 ntlm 0x00000200 unknown2 0x00000400 unknown3 0x00000800 ntlm_domain 0x00001000 ntlm_server 0x00002000 ntlm_share 0x00004000 NTLM2 0x00008000 targetinfo 0x00800000 128bit 0x20000000 keyexch 0x40000000 56bit 0x80000000 } set static::irule_name "irule-ntlm-bruteforce" set static::email_domain "domain.com" set static::user_domain "DOMAIN" set static::log_server "" set static::log_pri "local0." set static::fail_tab "NTLMfails" set static::blacklist_tab "NTLMblackhole" set static::userfail_tab "NTLMUserfails" set static::userblacklist_tab "NTLMUserblackhole" set static::max_failures 5 set static::fail_memory 300 set static::block_duration 300 } when CLIENT_ACCEPTED { if {[table lookup -subtable $static::blacklist_tab [IP::client_addr]] == 1} { log $static::log_pri "[virtual] - BLACKHOLED IPADDR [IP::client_addr]:[TCP::client_port] (Reputation=[IP::reputation [IP::client_addr]])" reject return } } when HTTP_REQUEST { if {[table lookup -subtable $static::blacklist_tab [IP::client_addr]] == 1} { log $static::log_pri "[virtual] - BLACKHOLED IPADDR [IP::client_addr]:[TCP::client_port] (Reputation=[IP::reputation [IP::client_addr]])" reject return } if {[HTTP::header Authorization] starts_with "NTLM "} { set ntlm_msg [ b64decode [split [lindex [HTTP::header Authorization] 1] ] ] binary scan $ntlm_msg a7ci protocol zero type if { $type eq 3 } { binary scan $ntlm_msg @12ssissississississii \ lmlen lmlen2 lmoff \ ntlen ntlen2 ntoff \ dlen dlen2 doff \ ulen ulen2 uoff \ hlen hlen2 hoff \ slen slen2 soff \ flags set ntlm_domain {}; binary scan $ntlm_msg @${doff}a${dlen} ntlm_domain set ntlm_user {}; binary scan $ntlm_msg @${uoff}a${ulen} ntlm_user set ntlm_host {}; binary scan $ntlm_msg @${hoff}a${hlen} ntlm_host set unicode [expr {$flags & 0x00000001}] if {$unicode} { set ntlm_domain_convert "" foreach i [ split $ntlm_domain ""] { scan $i %c c if {$c>1} { append ntlm_domain_convert $i } elseif {$c<128} { set ntlm_domain_convert $ntlm_domain_convert } else { append ntlm_domain_convert \\u[format %04.4X $c] } } set ntlm_domain $ntlm_domain_convert set ntlm_user_convert "" foreach i [ split $ntlm_user ""] { scan $i %c c if {$c>1} { append ntlm_user_convert $i } elseif {$c<128} { set ntlm_user_convert $ntlm_user_convert } else { append ntlm_user_convert \\u[format %04.4X $c] } } set ntlm_user $ntlm_user_convert set ntlm_host_convert "" foreach i [ split $ntlm_host ""] { scan $i %c c if {$c>1} { append ntlm_host_convert $i } elseif {$c<128} { set ntlm_host_convert $ntlm_host_convert } else { append ntlm_host_convert \\u[format %04.4X $c] } } set ntlm_host $ntlm_host_convert } binary scan $ntlm_msg @${ntoff}a${ntlen} ntdata binary scan $ntlm_msg @${lmoff}a${lmlen} lmdata binary scan $ntdata H* ntdata_h binary scan $lmdata H* lmdata_h set interesting 1 if { ($ntlm_domain equals $static::user_domain or [string tolower $ntlm_user] ends_with $static::email_domain) } { set attack 1 if {[table lookup -subtable $static::userblacklist_tab $ntlm_user] == 1} { # Block ntlm_user exceeding the number of failed logons in the timeout period log $static::log_pri "[virtual] - BLACKHOLED $ntlm_domain\\$ntlm_user from $ntlm_host at [IP::client_addr]:[TCP::client_port] (Reputation=[IP::reputation [IP::client_addr]])" reject return } else { log $static::log_pri "[virtual] - Login attempt by $ntlm_domain\\$ntlm_user from $ntlm_host for [HTTP::uri]." } } else { set attack 0 log $static::log_pri "[virtual] - Not a valid user - Login attempt by $ntlm_domain\\$ntlm_user from $ntlm_host for [HTTP::uri]." } return [list type $type flags [format 0x%08x $flags] \ ntlm_domain $ntlm_domain ntlm_host $ntlm_host ntlm_user $ntlm_user \ lmhash $lmdata nthash $ntdata] } } } when HTTP_RESPONSE { if {[info exists interesting] && $interesting == 1} { set client [IP::client_addr]:[TCP::client_port] set node [IP::server_addr]:[TCP::server_port] set nodeResp [HTTP::status] if { $nodeResp == 401 and ([info exists attack] and $attack == 1)} { log $static::log_pri "[virtual] - invalid credentials detected for $ntlm_user" table set -subtable $static::fail_tab -notouch -excl [IP::client_addr] 0 indef $static::fail_memory table incr -subtable $static::fail_tab [IP::client_addr] if {[table lookup -subtable $static::fail_tab [IP::client_addr]] >= $static::max_failures} { set now [clock seconds] set now_date [split [clock format $now -format {%X %x}] " "] set later [expr {$now + $static::block_duration}] set later_date [split [clock format $later -format {%X %x}] " "] log $static::log_pri "[virtual] - BLACKHOLING IPADDR - [IP::client_addr] (Reputation=[IP::reputation [IP::client_addr]]) at $now_date until $later_date" table set -subtable $static::blacklist_tab -excl [IP::client_addr] 1 indef $static::block_duration } if {[info exists ntlm_user]} { table set -subtable $static::userfail_tab -notouch -excl $ntlm_user 0 indef $static::fail_memory table incr -subtable $static::userfail_tab $ntlm_user if {[table lookup -subtable $static::userfail_tab $ntlm_user] >= $static::max_failures} { set now [clock seconds] set later [expr {$now + $static::block_duration}] log $static::log_pri "[virtual] - BLACKHOLING USER - $ntlm_user at $now_date until $later_date" table set -subtable $static::userblacklist_tab -excl $ntlm_user 1 indef $static::block_duration } } } } } Tested this on version: 11.5
