Bad Password Loggin attempts ban entire site --- !!!
Problem reported by Bryant Zimmerman - March 2 at 8:31 AM
Submitted
Ok we have had multiple reports now of users failing to login correctly from a site that it bans all users from that site even logged in users.... 
 
Worse yet it does not so the admins in the interface any ban has occurred nor does it allow us to raise that ban when this occurs. 
 
ONE USER SCREWING UP THEIR PASSWORD 6 TIMES CAN BAN A WHOLE SITE....!!!
I need a fix now. This happened last week 3 times and this week twice now.  I have customers pulling services. It happened to us yesterday a new employee banned the entire office and we could not help any clients as we could not get in from our corporate...
 
This is beyond negligent...  
 
How do I shut off password banning in the interim I have not found any thing under the Admin, Settings, Security that looks like I can shut off webmail login banning? I look at the IDS 

11 Replies

Reply to Thread
0
Ronald Raley Replied
We have seen this as well. One person from a local firehouse tried their password over and over and over again. Eventually, it killed everyone from the firehouse to login to SmarterMail. I have read somewhere here it is a setting in an XML file, but not available in SmarterMail Admin.
0
Bryant Zimmerman Replied
LIST ADMINS where is the setting in the XML that Ronald is referencing? When will they get this fixed so a ban only occurs for a single user and not a full IP? How can we white list IP's so customers don't get whole sites banned... Very bad design.
1
Scarab Replied
You can edit the Webmail Brute Force Detection in the \SmarterMail\MRS\Web.config file. There should be the following lines:
 
    <add key="ForgotPassword.BruteForceDetection.TriesBeforeBlock" value="10" />
    <add key="ForgotPassword.BruteForceDetection.BlockTime" value="5" />
    <add key="Login.BruteForceDetection.TriesBeforeBlock" value="10" />
    <add key="Login.BruteForceDetection.BlockTime" value="5" />
 
Change these values according to your needs. There is no need to restart SmarterMail or the site in IIS after making those changes.
 
If a valid IP still gets blocked you can remove the block under MANAGE > IDS BLOCKS > WEBMAIL by selecting the blocked IP Address and clicking on ACTIONS > UNBLOCK.
 
It would be nice if this setting was contained under SETTINGS > SECURITY > IDS RULES but as it is controlled by IIS rather than SmarterMail I suspect that is why it is located in the Web.config and not the MailConfig.xml, and thus why it isn't a setting that is configurable within the SmarterMail interface.
 
0
Ronald Raley Replied
Scarab, thanks for the info!
0
Bryant Zimmerman Replied
The interesting thing is NO IP is showing up in the MANAGE > IDS BLOCKS > WEBMAIL ​ when a block is occurring. That is part of the issue. 
0
Bryant Zimmerman Replied
If we put zeros in these places does this disable the blocking? Also how can we whitelist IP addresses that should never be blocked?
0
Ronald Raley Replied
Surprise! This behavior was built by SmarterTools out-of-the-box.

We must find these things out the hard way :(
1
Ronald Raley Replied
This kind of crap should just be left out of the default install.
 
Then those who want a more restrictive solution can choose a more restrictive solution.
0
Ronald Raley Replied
Bryant, this is a good question. Does a 0 value disable the block? I hope that SmarterTools will give this thread the respect it deserves and clarify this for us.
1
Bryant Zimmerman Replied
From SmarterTools Support.
 
You can adjust the threshold in which the brute force detection kicks off, or disable it completely by modifying the mailconfig.xml file located under C:\Program Files (x86)\SmarterTools\SmarterMail\Service. Here you'll want to locate the following XML:
 
  <BruteForceSettings>
        <LoginIsEnabled>True</LoginIsEnabled>
        <LoginRetries>5</LoginRetries>
        <LoginTimeout>10</LoginTimeout>
        <PasswordRetrievalIsEnabled>True</PasswordRetrievalIsEnabled>
        <PasswordRetrievalRetries>5</PasswordRetrievalRetries>
        <PasswordRetrievalTimeout>10</PasswordRetrievalTimeout>
  </BruteForceSettings>
 
They have stated that in a future release that a whitelist IP will be honored around brute force blocks in the near future. For now you can disable the ability LoginIsEnabled to False. 
0
Ionel Aurelian Rau Replied
Happened to us as well, but it was fixed easily by rebooting the server. But it`s definitely a problem.

Reply to Thread