[Dovecot] Limit login attempts per connection?
Dovecot allows a large number of login attempts per connection. I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay, but I can't find anything in /etc/dovecot.conf or by googling. How do I do it? Do I need to patch the source?
dovecot-1.1.10-1.x86_64 on CentOS 5.4
--
TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
Tony Nelson put forth on 3/3/2010 2:39 PM:
Dovecot allows a large number of login attempts per connection. I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay, but I can't find anything in /etc/dovecot.conf or by googling. How do I do it? Do I need to patch the source?
dovecot-1.1.10-1.x86_64 on CentOS 5.4
Can you tell us more about these unwanted login attempts? Are you merely trying to stop Chinese et al hacker woodpeckering on your IMAP/POP port(s) or something else?
-- Stan
On 10-03-03 23:01:58, Stan Hoeppner wrote:
Tony Nelson put forth on 3/3/2010 2:39 PM:
Dovecot allows a large number of login attempts per connection.
I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay, but I can't find anything in /etc/dovecot.conf or by googling. How do I do it? Do I need to patch the source?dovecot-1.1.10-1.x86_64 on CentOS 5.4
Can you tell us more about these unwanted login attempts? Are you merely trying to stop Chinese et al hacker woodpeckering on your IMAP/POP port(s) or something else?
Crackers, yes. They're just the sort one doesn't want getting in to one's system, and the fewer tries they get the better. But the reason is not important.
Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do.
--
TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
On 3/4/10 6:42 PM -0500 Tony Nelson wrote:
Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do.
I think it's a brilliant idea. After one login attempt, all others on the same connection should fail.
-frank
On 10-03-04 20:22:15, Frank Cusack wrote:
On 3/4/10 6:42 PM -0500 Tony Nelson wrote:
Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do.
I think it's a brilliant idea. After one login attempt, all others on the same connection should fail.
A fan! Anyway, there should at least be a choice. Not that I've coded a choice, just a dumb patch -- see attachment. It's a bit of a compromise, with a hard-coded limit of 4 attempts. Maybe I'll lower it to 2.
--
TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
On 05/03/2010 04:43, Tony Nelson wrote:
On 10-03-04 20:22:15, Frank Cusack wrote:
On 3/4/10 6:42 PM -0500 Tony Nelson wrote:
Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do.
I think it's a brilliant idea. After one login attempt, all others on the same connection should fail.
A fan! Anyway, there should at least be a choice. Not that I've coded a choice, just a dumb patch -- see attachment. It's a bit of a compromise, with a hard-coded limit of 4 attempts. Maybe I'll lower it to 2.
I would be all in favour of a setting like this because it's easier to configure than fail2ban...
...but ... At least my public facing servers seem to be receiving trickle scans where there is definite evidence of a slow distributed bruteforcer which uses multiple IPs to try multiple usernames and I probably only see each IP a few times a day... This is quite hard to defend against without some kind of distributed system (and I believe there are such things?)
Good luck
Ed W
Ed W put forth on 3/5/2010 3:44 AM:
...but ... At least my public facing servers seem to be receiving trickle scans where there is definite evidence of a slow distributed bruteforcer which uses multiple IPs to try multiple usernames and I probably only see each IP a few times a day... This is quite hard to defend against without some kind of distributed system (and I believe there are such things?)
It's good policy these days to use ipdeny.com cidr tables and ban all countries from your servers that will never need legitimate access to them. If you're in the US, do you need to allow Chinese or Russian IP space to connect to your IMAP ports? If not, it's pretty simple to add iptables rules on all your servers to ban all the countries where a large amount of unauthorized connection attempts originate.
This usually can't be done with off the shelf firewalls from the likes of Cisco et al as they don't have enough memory. For a large server farm, it would be better to have a Linux or NetBSD box running firewall duty for the farm so you only have to load these rules once and eat cycles on only one machine.
Also keep in mind that iptables load time for huge country files can be pretty substantial. I experimented with this on an old dual 550 MHz machine and it took something like 30 seconds to load just the China cidrs into iptables. If you plan to load up multiple countries, initial iptables loading might take a while.
Once you've got it set up and tuned it can work very well.
-- Stan
Quoting Stan Hoeppner <stan@hardwarefreak.com>:
It's good policy these days to use ipdeny.com cidr tables and ban all countries from your servers that will never need legitimate access to them.
It can be good policy... But not always...
And it is certainly not a cure-all. If the people in those countries use a proxy, or fake/spoof the IP, or use a mobile device where the IP of their mobile device (smart phone, etc) isn't listed as being from their country, they will bypass such checks.
You can try instead to block all spaces, and then allow only from certain IP spaces (say, all US spaces, or all UK space, etc) but this leaves out many legit spaces in that country which ipdeny.com missed, and has the same types of problems as above as far as proxies, spoofing, etc. This sounds good at first, but when you think about it more it may actually be a worse approach (block too much instead of block too little, resource savings aside).
If you're in the US, do you need to allow Chinese or Russian IP space to connect to your IMAP ports?
If you are in Higher Ed, the answer is almost always yes (unless you are a very small school). The use of VPN for students isn't very common, and many faculty/staff hate VPN even though it is available to them. And VPN may not run on their smart-phone, netbook, etc. Or they may want to use it from an internet-cafe, a friend's house, a foreign university they are visiting, airport wireless, etc. (Security questions arising from that aside...)
We _must_ allow access to our e-mail, web, and computation or general purpose machines from all over the world. Even if we provide VPN, HiEd is not like a normal business in that we often can NOT force the users to use the VPN access...
However, even in HiEd, we can still use ipdeny.com rules for our internal-only machines... For example, I use it on my network monitoring machines since an insecure monitoring machine can quickly lead to all the machines you monitor being insecure...
If not, it's pretty simple to add iptables rules on all your servers to ban all the countries where a large amount of unauthorized connection attempts originate.
That can be a lot of rules... As you noted in your post, that can be a performance issue... Plus there is the cost of keeping the rules updated, etc.
I'm sure there are scripts around on the net to convert the ipdeny.com files into iptables rules automatically, but there is still a cost there...
I believe there is also a "geoip" patch for iptables that will do a similar job as the ipdeny.com lists... I've not tried it though...
Once you've got it set up and tuned it can work very well.
It can, in some cases, indeed. But not in all cases...
I think you did a great service by pointing this out on the list, and that many will find this a useful tip. However, I'm not sure I agree with your opening statement that "It's good policy" since that statement is very broad, whereas policies are so site/application specific...
-- Stan
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
Eric Rostetter put forth on 3/5/2010 2:20 PM:
It can, in some cases, indeed. But not in all cases...
I think I was pretty clear in stating each sysadmin needs to evaluate what countries do/don't need to access his/her IMAP ports.
I think you did a great service by pointing this out on the list, and that many will find this a useful tip. However, I'm not sure I agree with your opening statement that "It's good policy" since that statement is very broad, whereas policies are so site/application specific...
Security policy needs to be very broad, does it not? It's good policy to preemptively block service access from netblocks in those parts of the world that a sysop deems will never need legitimate access to systems under his supervision. Is it not?
The key here Eric is the identification and classification process. The U.S. government, large multinationals, and some higher ed institutions will probably identify the fact that they probably can't use a default deny policy for most systems because there are users in potentially every country. For many other organizations, of all sizes, they may never have a legit user in Bhutan, China, Paraguay, or Zaire needing to access their systems. In these orgs, it makes no sense not to ban such IP space. Good security must be proactive, not reactive. Be proactive everywhere you can.
Good security practice is broad by nature, and is applicable to all sites and applications.
-- Stan
Hi,
On Fri, 05.03.2010 at 09:44:35 +0000, Ed W <lists@wildgooses.com> wrote:
I would be all in favour of a setting like this because it's easier to configure than fail2ban...
I'm no fan of fail2ban which fails to ban several things on my server(s), and is Linux only, too. You might want to look at 'sec', which can do similar jobs together with a small script that processes the respective IP numbers.
http://www.estpak.ee/~risto/sec/
Kind regards, --Toni++
On Fri, 05.03.2010 at 09:44:35 +0000, Ed W <lists@wildgooses.com> wrote:
I would be all in favour of a setting like this because it's easier to configure than fail2ban...
There's also denyhosts. <http://denyhosts.sourceforge.net/>
-Terry
On 2010-03-09 21:07:42 -0800, Terry Barnum wrote:
On Fri, 05.03.2010 at 09:44:35 +0000, Ed W <lists@wildgooses.com> wrote:
I would be all in favour of a setting like this because it's easier to configure than fail2ban...
There's also denyhosts. <http://denyhosts.sourceforge.net/>
http://snowman.net/projects/ipt_recent/
for ssh i use: iptables -A input_ext -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force attack " iptables -A input_ext -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP iptables -A input_ext -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
really nice iptables module
darix-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On 10-03-10 07:09:45, Marcus Rueckert wrote:
On 2010-03-09 21:07:42 -0800, Terry Barnum wrote:
On Fri, 05.03.2010 at 09:44:35 +0000, Ed W <lists@wildgooses.com> wrote:
I would be all in favour of a setting like this because it's easier to configure than fail2ban...
There's also denyhosts. <http://denyhosts.sourceforge.net/>
http://snowman.net/projects/ipt_recent/ ... really nice iptables module
Unlike fail2ban and denyhosts, using the recent module needs dovecot to close the connection upon authentication failure, as iptables only (normally) comes in to play for new connections, so it only really works with a patch like mine.
If you are using the recent module, you probably should also get Alexander Zangerl's pam_recent pam module, so that successful logins aren't counted against the IP.
--
TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
On Thu, 2010-03-04 at 23:43 -0500, Tony Nelson wrote:
I think it's a brilliant idea. After one login attempt, all others on the same connection should fail.
A fan! Anyway, there should at least be a choice. Not that I've coded a choice, just a dumb patch -- see attachment. It's a bit of a compromise, with a hard-coded limit of 4 attempts. Maybe I'll lower it to 2.
I think I'll change v2.0 to simply disconnect 3 minutes after the client connected. With the tarpitting doubling the auth failure delay for up to 15 seconds, that allows maybe max. 15 auth attempts before being disconnected. I don't really see why that would be too much, there's not much brute forcing that can be done with 15 attempts..
(And this assumes that something externally blocks that IP by then. If you disconnect without blocking the IP, they'll just reconnect and continue so that won't help much. And banning IP for just 2-4 failed auth attempts seems a bit too early.)
On 10-03-04 23:43:25, Tony Nelson wrote:
On 10-03-04 20:22:15, Frank Cusack wrote:
On 3/4/10 6:42 PM -0500 Tony Nelson wrote:
Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do.
I think it's a brilliant idea. After one login attempt, all others on the same connection should fail.
A fan! Anyway, there should at least be a choice. Not that I've coded a choice, just a dumb patch -- see attachment. It's a bit of a compromise, with a hard-coded limit of 4 attempts. Maybe I'll lower it to 2.
New patch with conf file setting "max_auth_attempts". The default is 0 and means no limit; non-zero disconnects after that many login failures. I put it in the main area of the conf file, but IIUC it should also work in the pop3 or imap sections and only affect that server. It doesn't affect the tarpitting.
When using it with an IPTables "recent" module rule, set it to 1.
--
TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Mar 03, 2010 at 03:39:28PM -0500, Tony Nelson wrote:
Dovecot allows a large number of login attempts per connection. I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay,
If the firewall is the one to do the job, I'd recommend an external application like fail2ban. It watches the logs and bans IP addresses with too many failures -- the nice thing is that it's able to cover all applications listening on external ports. You can define patterns in log files to which it has to react (but it comes with a good set of pre-defined patterns -- at least on popular GNU/Linux distros).
but I can't find anything in /etc/dovecot.conf or bygoogling. How do I do it? Do I need to patch the source?
I don't know about such a setting (but I don't know everything about Dovecot either!). Anyway, then it'd still the Dovecot process dealing with the rouge login attempts -- it seems better to keep them at the firewall level with the approach above.
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFLj0psBcgs9XrR2kYRAnamAJ91pD60iJp8UDz/mwpoFE9cpHpdswCdGCYu Mj5he6OOYtP7wWbBWhUmiXQ= =QCJ2 -----END PGP SIGNATURE-----
On 10-03-04 00:51:40, tomas@tuxteam.de wrote:
On Wed, Mar 03, 2010 at 03:39:28PM -0500, Tony Nelson wrote:
Dovecot allows a large number of login attempts per connection.
I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay,If the firewall is the one to do the job, I'd recommend an external application like fail2ban. It watches the logs and bans IP addresses with too many failures -- the nice thing is that it's able to cover all applications listening on external ports. You can define patterns in log files to which it has to react (but it comes with a good set of pre-defined patterns -- at least on popular GNU/Linux distros).
I already have something that works with any program secure enough not to allow unlimited login attempts. Using fail2ban might work if I configure it enough to sever existing connections.
but I can't find anything in /etc/dovecot.conf or bygoogling. How do I do it? Do I need to patch the source?
I don't know about such a setting (but I don't know everything about Dovecot either!). Anyway, then it'd still the Dovecot process dealing with the rouge login attempts -- it seems better to keep them at the firewall level with the approach above.
Yes, and I'm going to use the firewall -- once I can get Dovecot to limit the number of login attempts per connection.
Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do.
--
TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Mar 04, 2010 at 06:43:21PM -0500, Tony Nelson wrote:
On 10-03-04 00:51:40, tomas@tuxteam.de wrote:
[...fail2ban...]
I already have something that works with any program secure enough not to allow unlimited login attempts. Using fail2ban might work if I configure it enough to sever existing connections.
Understood.
Thanks
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFLkOfPBcgs9XrR2kYRAuztAJ9LJdWEP7LuUOuB6nDHTjVN1Ov7RACeNawb hXuUgpi15dUYNgfVDcMzFJc= =2cDu -----END PGP SIGNATURE-----
participants (10)
-
Ed W
-
Eric Rostetter
-
Frank Cusack
-
Marcus Rueckert
-
Stan Hoeppner
-
Terry Barnum
-
Timo Sirainen
-
tomas＠tuxteam.de
-
Toni Mueller
-
Tony Nelson