[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dovecot configuration issues for IMAP/POP3 (squeeze)

(This accidentally went directly to mouss instead of back to the list -

mouss grabbed a keyboard and wrote:
> Le 18/11/2012 16:34, David Guntner a écrit :
>> I've discovered, somewhat to my dismay, that Dovecot will just sit
>> there and cheerfully let you keep making attempts to login - even
>> after I had put in 7 bad entries, it still left the connection open
>> to keep on trying.  That really doesn't help legitimate mail
>> programs that had a bad password put in by mistake, but it does
>> help scripts/bots that are trying a brute-force attack.  So for
>> part one of my current problem, is there an option that can be put
>> into the config file to tell it to disconnect after {x} bad login
>> attempts?
> auth_failure_delay
> see http://wiki.dovecot.org/MainConfig
> http://www.dovecot.org/list/dovecot/2009-November/044262.html
> the value is doubled after every bad attempt (from a given IP), until
> a limit is reached (15 seconds).

According to the text on that wiki page:

"Number of seconds to delay before replying to failed authentications."

That seems to coincide with what I've observed about how long it takes
to come back to you with a "that ain't right" reply when you put in the
wrong information.  I read the message posted at the list archive you
reference above, and that confirms it as well - basically it will keep
increasing how long it will send back the "wrong" message after each bad
attempt (up to a given limit).

That's not what I want - I need a way to have it CLOSE the connection
after {x} number of bad attempts (three is usually a good number).  In
other words (for example), you put in a bad username/password three
times, and it closes the connection and logs it.

Assuming I could get a meaningful log entry with each bad attempt, I
could have fail2ban act - but that's still pretty useless since as far
as I understand it; telling iptables to DROP a given IP address doesn't
do anything to a connection that's already open.  Someone please feel
free to correct me if my understanding on that is not correct. :-)

>> Part 2 of my current problem has to do with the actual logging of
>> the bad login attempts.  It wasn't doing it at first, but then I
>> did find the auth_verbose option to allow for the logging of bad
>> attempts.  I turned that on - and to my dismay, found that the log
>> entry it produces is pretty much useless for something that
>> fail2ban can hook into.  If you login successfully or log  out
>> yourself after bad attempts, it says "imap-login" or "pop3-login"
>> (which *would* be something that fail2ban can use).  However, with
>> auth_verbose=yes, the bad attempts are all prefaced with
>> "auth-worker(default)" for either type of connection. This is
>> useless for fail2ban purposes, for reasons which should be pretty
>> obvious. :-)  So - is there a way to get auth_verbose to show which
>> service (IMAP/POP3) is being accessed?
> why care? why not consider that {pop3+imap} is a single service group?
> after all, they're using the same logins/passwords, no?

That may be the case, but the access comes in on different ports.
Fail2ban works by setting up filtering rules through iptables, and will
route traffic on a given port from a badly-behaving IP address to a DROP
instruction in the firewall.  The filters that you set up within
fail2ban is for one service (port) for each filter.  So for that reason,
it needs to "care" about which service is being abused.

I've noticed that when I issue a "quit" after putting in bad information
when trying either port, it does log the entry with pop3-login: or
imap-login: and an abort message complaining about an auth failure.  I
could use a string like that to trigger a fail2ban action - but only if
Dovecot itself closes the connection after a certain number of bad
attempts.  I'm not real comfortable with Dovecot at the moment, since as
it currently stand, the silly thing will just stand there with the door
wide open, allowing you to just keep trying.  That's not good from a
security standpoint.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: