Limiting number of failed login attempts
Hi All,
Greetings for the day!
I am currently using mailman package from debian repository. I use mailman for a number of private mailing lists. The archives of these mailing lists is also private.
Most of the members of these mailing lists do not change their default mailman passwords, which in my installation means 8 characters of a-z.
Is there a way in which I can limit the number of failed login attempts to the archive to prevent a brute force attempt?
Thanks & Regards Aditya Jain
On 10/2/15 3:00 PM, Aditya Jain wrote:
Is there a way in which I can limit the number of failed login attempts to the archive to prevent a brute force attempt?
In recent Mailman, both the private CGI and the options CGI return a 401 Unauthorized status for a failed login. This makes it easy to use something like fail2ban to block an IP after a number of failed attempts.
Also, You can generate more secure passwords by setting
USER_FRIENDLY_PASSWORDS = No
in mm_cfg.py, and you can make them longer by setting MEMBER_PASSWORD_LENGTH = a number > 8.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
Thanks! At the moment I don't have a separate IP for mailman. Therefore I cannot use fail2ban. But hopefully, a really long password should be enough to discourage a simple brute force.
Thanks & Regards Aditya Jain
On Saturday 03 October 2015 06:44 PM, Mark Sapiro wrote:
On 10/2/15 3:00 PM, Aditya Jain wrote:
Is there a way in which I can limit the number of failed login attempts to the archive to prevent a brute force attempt?
In recent Mailman, both the private CGI and the options CGI return a 401 Unauthorized status for a failed login. This makes it easy to use something like fail2ban to block an IP after a number of failed attempts.
Also, You can generate more secure passwords by setting
USER_FRIENDLY_PASSWORDS = No
in mm_cfg.py, and you can make them longer by setting MEMBER_PASSWORD_LENGTH = a number > 8.
On 10/3/15 11:51 AM, Aditya Jain wrote:
Thanks! At the moment I don't have a separate IP for mailman. Therefore I cannot use fail2ban. But hopefully, a really long password should be enough to discourage a simple brute force.
I'm not sure if you understand fail2ban. See <http://www.fail2ban.org/wiki/index.php/Main_Page>.
fail2ban runs on (in this case) the machine on which Mailman's web interface runs. It monitors the web server logs and looks for (in this case) a minimum number of 401 errors within a given time window from a single IP and if found uses iptables or similar to block access from that IP for a defined time.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
Thanks for pointing me to the manual.
On Sunday 04 October 2015 07:28 AM, Mark Sapiro wrote:
I'm not sure if you understand fail2ban. See <http://www.fail2ban.org/wiki/index.php/Main_Page>.
fail2ban runs on (in this case) the machine on which Mailman's web interface runs. It monitors the web server logs and looks for (in this case) a minimum number of 401 errors within a given time window from a single IP and if found uses iptables or similar to block access from that IP for a defined time.
I run multiple websites on the same IP and same port. Therefore I was looking for something that is inside mailman so that access to other websites is not blocked in case the attempts were genuine. For now I think I can manage with long passwords.
Thanks & Regards Aditya Jain
On Sun, Oct 04, 2015 at 11:43:55AM +0530, Aditya Jain wrote:
On Sunday 04 October 2015 07:28 AM, Mark Sapiro wrote:
fail2ban runs on (in this case) the machine on which Mailman's web interface runs. It monitors the web server logs and looks for (in this case) a minimum number of 401 errors within a given time window from a single IP and if found uses iptables or similar to block access from that IP for a defined time.
I run multiple websites on the same IP and same port. Therefore I was looking for something that is inside mailman so that access to other websites is not blocked in case the attempts were genuine. For now I think I can manage with long passwords.
From the Subject: line, I was going to suggest use of fail2ban…
It doesn't matter if there are other sites/services hosted on the same machine/address; fail2ban works on patterns matching in logfiles; if you only want to look at Mailman errors, only configure fail2ban to look at the Mailman (vhost) logs.
If you've got (brute force attempt) issues from one host / botnet, preventing access to other things, is surely an added win?
-- "To save the world requires faith and courage: faith in reason, and courage to proclaim what reason shows to be true." -- Bertrand Russell
I think that Aditya Jain's problem is that he (she?) doesn't understand that fail2ban takes a look at where the attackers are coming from and bans _their_ Host from connecting. He thought it worked by making his host unconnectable, which of course will not work.
But I could be wrong ..
Laura
Hi,
On Monday 05 October 2015 04:19 PM, Laura Creighton wrote:
I think that Aditya Jain's problem is that he (she?) He :) doesn't understand that fail2ban takes a look at where the attackers are coming from and bans _their_ Host from connecting. He thought it worked by making his host unconnectable, which of course will not work. I know how it works, I also use it in some places. The concern that I have is that most of the requests that my list receives come from very few organizations. This leaves me with a very small number of client IP addresses.
If I block a particular IP address because some disgruntled person from the organization is trying to brute force, it will block access for other legitimate users from that organization (because they have only one IP dedicated to browsing traffic). That is why I was looking for something that can look at the username/email and block request or show captcha if number of failed attempts cross a certain limit, at application(mailman) level.
I think this is sounding more like a feature request.
Thanks & Regards Aditya Jain
Aditya Jain writes:
If I block a particular IP address because some disgruntled person from the organization is trying to brute force, it will block access for other legitimate users from that organization (because they have only one IP dedicated to browsing traffic).
This is a social problem that Mailman ultimately can't solve, and probably shouldn't try.
That is why I was looking for something that can look at the username/email and block request or show captcha if number of failed attempts cross a certain limit, at application(mailman) level.
I think this is sounding more like a feature request.
I think this is sounding like a denial-of-service attack on the legitimate users no matter how you try to defend them. My experience with such "disgruntled users" is that they don't hesitate to abuse others' accounts for this purpose. They also are often willing to go to the trouble of acquiring software to automate captcha-breaking.
Perhaps a per-user login attempt limit would work for you. Each (ab)user is different. But I don't think it's a good idea for a supported feature of Mailman, it's too fragile and it would be an invitation to an endless series of "improvements" as the admins get in arms races with the rogues.
It might be possible to revisit this in Mailman 3 (when we get a unified authn/authz story) using a token-based approach where the token is acquired somewhere that already has a stronger authentication story. But that will require serious coding.
On Tue, Oct 06, 2015 at 12:07:25AM +0900, Stephen J. Turnbull wrote:
Perhaps a per-user login attempt limit would work for you. Each (ab)user is different. But I don't think it's a good idea for a supported feature of Mailman, it's too fragile and it would be an invitation to an endless series of "improvements" as the admins get in arms races with the rogues.
Very much a +1, especially if we're looking at modern design, then this could (for those wanting it) be a plugin, or shocker, using something already out there.
It might be possible to revisit this in Mailman 3 (when we get a unified authn/authz story) using a token-based approach where the token is acquired somewhere that already has a stronger authentication story. But that will require serious coding.
I think I'd prefer the ability to void/regenerate tokens, rather than anything else. Although with sophisticated API management tools, shaping may be an option…
I'm not an advocate for "fixing" things in the application, rather than at say, transport/network layer; to setup Mailman, one's in(evit|vari)ably going to need root access anyhow, so one might as well do things properly.
-- "Opera, next to Gothic architecture, is one of the strangest inventions of Western man. It could not have been foreseen by any logical process." -- Kenneth Clark
participants (5)
-
Adam McGreggor -
Aditya Jain -
Laura Creighton -
Mark Sapiro -
Stephen J. Turnbull