Dovecot configuration issues for IMAP/POP3 (squeeze)
Thanks to those who pointed me in that direction, I've now got Dovecot
running on my test system. However, I've got some issues that I'm
hoping someone here can help out with. I did a bunch of googling to
find some of what I needed, but I'm not sure how to adjust things at
this point (and some stuff I couldn't find).
For anti-abuse purposes on a number of services, I use fail2ban, which
needs to read from log files. So far, so good.
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?
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?
--Dave
signature.asc
Description: OpenPGP digital signature
Re: Dovecot configuration issues for IMAP/POP3 (squeeze)
Le 18/11/2012 16:34, David Guntner a écrit :
Thanks to those who pointed me in that direction, I've now got
Dovecot running on my test system. However, I've got some issues
that I'm hoping someone here can help out with. I did a bunch of
googling to find some of what I needed, but I'm not sure how to
adjust things at this point (and some stuff I couldn't find).
For anti-abuse purposes on a number of services, I use fail2ban,
which needs to read from log files. So far, so good.
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).
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?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a93b14.2030...@ml.netoyen.net
Re: Dovecot configuration issues for IMAP/POP3 (squeeze)
(This accidentally went directly to mouss instead of back to the list -
resending)
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.
--Dave
signature.asc
Description: OpenPGP digital signature
Re: Dovecot configuration issues for IMAP/POP3 (squeeze)
On Nov 18, 2012, at 2:00 PM, David Guntner wrote:
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. :-)
I use Linux and IPtables and fail2ban, and the way it seems to work here is:
There's an IPtables rule that checks for and accepts established connection
packets, but fail2ban inserts its block chain in front of that, at the very top
of the Input chain. So a packet from a wayward IP is blocked/dropped if
fail2ban doesn't like it, before the fact that this is an established
connection is discovered. So if you had f2b watching for bad logins, I think
you'd get exactly what you want, assuming you could get meaningful log entries.
(I wrote my IPtables packet filter, though, so others are almost certainly
different.)
OTOH, some of the bad attempts I get don't log the remote IP, so they aren't
meaningful to f2b and don't get blocked...
--
Glenn English
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/173642db-5f05-489c-8c84-c4db49cbe...@slsware.com
Re: Dovecot configuration issues for IMAP/POP3 (squeeze)
David Guntner dav...@akamail.net wrote: 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. it needs to care about which service is being abused. I'm pretty sure my version (or maybe it's just my configuration) takes the attitude that it doesn't really matter what port is being poked, fail2ban just blocks that IP address. Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b63on9xvpm@news.roaima.co.uk
Re: Dovecot configuration issues for IMAP/POP3 (squeeze)
Glenn English grabbed a keyboard and wrote: On Nov 18, 2012, at 2:00 PM, David Guntner wrote: 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. :-) I use Linux and IPtables and fail2ban, and the way it seems to work here is: There's an IPtables rule that checks for and accepts established connection packets, but fail2ban inserts its block chain in front of that, at the very top of the Input chain. So a packet from a wayward IP is blocked/dropped if fail2ban doesn't like it, before the fact that this is an established connection is discovered. So if you had f2b watching for bad logins, I think you'd get exactly what you want, assuming you could get meaningful log entries. (I wrote my IPtables packet filter, though, so others are almost certainly different.) Without seeing your config files, I have no idea how you have it set up. I've been running it for years on my existing system and set it up according to the instructions. Filters config files are set up for particular ports like this, and fail2ban injects its own chains into the main INPUT chain in iptables when it starts. On that existing system, my iptables currently looks like this: # iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-ftp tcp -- anywhere anywhere tcp dpt:ftp fail2ban-postfix tcp -- anywhere anywhere tcp dpt:smtp fail2ban-pop3 tcp -- anywhere anywhere tcp dpt:pop3 fail2ban-imap tcp -- anywhere anywhere tcp dpt:imap2 fail2ban-sasl tcp -- anywhere anywhere tcp dpt:smtp fail2ban-SSH tcp -- anywhere anywhere tcp dpt:ssh Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain fail2ban-SSH (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-ftp (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-imap (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-pop3 (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-postfix (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain fail2ban-sasl (1 references) target prot opt source destination DROP all -- rrcs-50-84-168-222.sw.biz.rr.com anywhere DROP all -- firstt3.lnk.telstra.net anywhere DROP all -- wsip-24-249-159-209.tu.ok.cox.net anywhere DROP all -- 64.52.155.10 anywhere DROP all -- mail.ifsi.comanywhere DROP all -- c-98-211-191-10.hsd1.fl.comcast.net anywhere DROP all -- 23-25-216-129-static.hfc.comcastbusiness.net anywhere DROP all -- host18-100-static.241-95-b.business.telecomitalia.it anywhere DROP all -- static-149-136-145-212.ipcom.comunitel.net anywhere DROP all -- 173-162-251-81-NewEngland.hfc.comcastbusiness.net anywhere DROP all -- 9.Red-80-39-125.staticIP.rima-tde.net anywhere DROP all -- 74.11.126.243anywhere DROP all -- adsl-068-213-103-027.sip.jan.bellsouth.net anywhere DROP all -- mail.jccyofrockland.org anywhere DROP all -- adsl-108-71-19-30.dsl.hstntx.sbcglobal.net anywhere DROP all -- 50.121.152.110 anywhere DROP all -- 208-53-75-36.static.chico.ca.digitalpath.net anywhere DROP all -- wsip-98-189-122-23.oc.oc.cox.net anywhere DROP all -- tollgate123.demon.co.uk anywhere DROP all -- static-31-84-61-95.ipcom.comunitel.net anywhere DROP all -- net-93-64-210-123.cust.dsl.vodafone.it anywhere DROP all -- 75-149-2-246-Pennsylvania.hfc.comcastbusiness.net anywhere DROP all -- 39.Red-79-144-62.dynamicIP.rima-tde.net anywhere DROP all -- mail2.servicesfuneraires.fr anywhere DROP all -- 75-151-109-166-Washington.hfc.comcastbusiness.net anywhere DROP all -- 72.Red-80-37-10.staticIP.rima-tde.net anywhere DROP all -- sacrtt6.lnk.telstra.net anywhere DROP all -- 70.43.109.131.nw.nuvox.net anywhere DROP all -- 74-84-111-214.client.mchsi.com anywhere DROP all --
Re: Dovecot configuration issues for IMAP/POP3 (squeeze)
David Guntner grabbed a keyboard and wrote: [Lots of fail2ban stuff] Well, holy cow! That's what I get for starting a conversation. :-) I'm not the type to just ask a question or answer replies and just sit there waiting, I start mucking around and googling more and stuff. Just discovered that fail2ban has *multiport* support for iptables - it can be set up to filter chains control more than one port with a single filter command. I further discovered that the Dovecot website itself has filter and jail rules for fail2ban to work with its log entries. So yea, if I can set up a filter rule that says something along the lines of if you see this, block traffic for that IP address on the following ports..., that will do the trick! Yay! :-) Now, if I can just figure out a way to get Dovecot to close the connection when there's too many bad attempts I'll have to do some more testing; maybe the fail2ban chain through iptables will close an existing connection as was suggested might be the case in another reply Ooooh, the possibilities! :-D --Dave signature.asc Description: OpenPGP digital signature
Re: (SOLVED) Dovecot configuration issues for IMAP/POP3 (squeeze)
David Guntner grabbed a keyboard and wrote: David Guntner grabbed a keyboard and wrote: [Lots of fail2ban stuff] Well, holy cow! That's what I get for starting a conversation. :-) I'm not the type to just ask a question or answer replies and just sit there waiting, I start mucking around and googling more and stuff. Just discovered that fail2ban has *multiport* support for iptables - it can be set up to filter chains control more than one port with a single filter command. I further discovered that the Dovecot website itself has filter and jail rules for fail2ban to work with its log entries. So yea, if I can set up a filter rule that says something along the lines of if you see this, block traffic for that IP address on the following ports..., that will do the trick! Yay! :-) Now, if I can just figure out a way to get Dovecot to close the connection when there's too many bad attempts I'll have to do some more testing; maybe the fail2ban chain through iptables will close an existing connection as was suggested might be the case in another reply Ooooh, the possibilities! :-D Well, waa hoo! :-) Upon further testing, it seems that when fail2ban decides you're gone and adds an iptables DROP for you, you drop. grin I added the filter on the page I found for Dovecot fail2ban that I mentioned above, and then added an extra failregexp entry that looks for the auth-worker(default) log entry, and presto - after I put in a few bad attempts, fail2ban kicked in and all of a sudden I found myself kicked out. Success! :-) Thanks again to those who helped out! --Dave signature.asc Description: OpenPGP digital signature
