Re: Force TCP socket disconnect on imap login failure?
Just for clarification (this probably won't help achieve your primary goal to reset the connections): Iptables can block future connections _and_ stop existing connections to receive (and send) packets (even the command you posted). What it can't do is closing existing connections (sending a FIN). If the example you show can not block existing connections you have somewhere before the chain a RELATED, ESTABLISHED rule with ACCEPT as target. This is a common mistake. Your fail2ban rules have to come _before_ you check for related and established connections. I never tested this, but you could try using "-j REJECT --reject-with tcp-reset" instead of DROP. Then at least a RST would be sent. Hippo Man ezt írta (időpont: 2022. máj. 23., H, 23:17): > > OOPS! I incorrectly copied and pasted the iptables command in my previous > message. Here is the correct iptables command: > > iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d > aaa.bbb.ccc.ddd -j DROP > > This command successfully blocks *future* connections to ports 143 and 993 > from that IP address, but as I mentioned, it doesn't kill the currently open > connection. > > -- > hippo...@gmail.com > Take a hippopotamus to lunch today. > > > On Mon, May 23, 2022 at 4:54 PM Hippo Man wrote: >> >> Thank you, but fail2ban doesn't do what I need. Here is why ... >> >> I have used fail2ban and also my own homegrown log monitor program for this >> purpose. In both cases, I can detect the failed imap logins and then cause >> the following command to be run ... >> >> iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j DROP >> >> However, this does not drop connections that are existing and already open. >> It will only drop *future* connections from that IP address to port 143. >> >> This is why I want to kill the existing connection. Even after that >> "iptables" command is issued, the entity which is connected to the imap port >> can continue to send more and more imap commands. >> >> If I can drop the TCP connection as soon as an imap login fails and also >> issue that kind of "iptables" command, then the client would have to >> reconnect in order to retry other login attempts. Those future connections >> would then be successfully blocked by that iptables rule. >> >> And even if I issue a "tcpdrop" command instead of just the "iptables" >> command, it doesn't kill the already-open connection. It just force-blocks >> future connections. >> >> I'm thinking of patching the dovecot source code to create a personal >> version which immediately disconnects from the socket after login failure. >> Of course, I would prefer not to do that, if there is another way to >> accomplish this. >> >> -- >> hippo...@gmail.com >> Take a hippopotamus to lunch today. >> >> >> On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins wrote: >>> >>> Look at fail2ban. >>> Should be able to do that for you. >>> >>> Jan Hugo >>> >>> >>> On 5/23/22 21:11, Lloyd Zusman wrote: >>> >>> I'm running dovecot 2.2.13 under Debian 8. >>> >>> I'd like to force an immediate TCP socket disconnect after any imap login >>> attempt that fails. >>> >>> Right now, if invalid credentials are supplied during an imap login, the >>> client can keep retrying logins with different credentials. However, I want >>> to prevent that from occurring by causing the socket connection to be >>> closed as soon as there is any failed login attempt. >>> >>> I haven't been able to find any dovecot configuration setting which could >>> control this behavior, but I'm hoping that I just missed something. >>> >>> Thank you very much for any suggestions. >>> >>> -- >>> hippo...@gmail.com >>> Take a hippopotamus to lunch today. >>> >>>
Re: userdb username change ignored when using (My)SQL was: Re: userdb username changed
On Mon, Dec 7, 2015 at 8:13 PM, Timo Sirainen wrote: > http://dovecot.org/releases/2.2/dovecot-2.2.20.tar.gz > http://dovecot.org/releases/2.2/dovecot-2.2.20.tar.gz.sig > > This could be (one of) the last v2.2.x release. We're starting v2.3 > development soon. > (...) - auth: userdb lookups via auth-worker couldn't change username > (...) Thanks for that Timo! I will test it. Regards, Peter
Re: quota_over_flag examples?
>> That's not the same. Strange but I never found quota-status docs on >> Dovecot wiki nowhere!Anyway, I think quota_over_flag is new and >> possibly Timo replacing quota-status with this flag now? > > Can anyone confirm this is true? I don't want to speak in the name of others, but I think that quota-status doesn't fit in the Dovecot "world". It contradicts the tenet of "Dovecot don't have to know about email addresses", because Postfix sends email addresses with Policy-requests. And yes, you can make it work somehow even if your mailbox names are not email addresses, but IMHO it won't be as fast (or as secure) as a db query by Postfix. Peter
Re: userdb username change ignored when using (My)SQL was: Re: userdb username changed
Hi! Can someone please tell me what is the difference between "auth" and "auth-worker"? I mean the entries in the log. For me it looks like "auth" would be a master process for authdb and userdb lookups. But quota-status, and even lmtp are calling auth-worker directly. Or? Imap auth with mysql: Apr 22 12:35:16 imap21 dovecot: auth-worker(21529): Debug: sql(p...@example.net,195.202.128.25): username changed p...@example.net -> uppp Apr 22 12:35:16 imap21 dovecot: auth: Debug: sql(p...@example.net,195.202.128.25,): username changed p...@example.net -> uppp Both processes(?) loop through the returned variables (with request.c auth_request_set_userdb_field) , but only "auth" sets the "username" successfully. Imap auth with ldap: Apr 22 13:17:55 imap21 dovecot: auth: Debug: ldap(m2500j6,127.0.0.1,): username changed m2500j6 -> uppp Apr 22 13:17:55 imap21 dovecot: auth: Debug: ldap(uppp,127.0.0.1,): result: gidNumber=168 homeDirectory=/tmp mailHost=uppp Only "auth", and username is successfully changed. quota-status with mysql: Apr 22 12:35:59 imap21 dovecot: auth-worker(21529): Debug: sql(p...@kabsi.at): username changed p...@kabsi.at -> uppp Apr 22 12:35:59 imap21 dovecot: auth: Debug: userdb out: USER#0111#011...@kabsi.at#011home=/home/ppp#011uid=500#011gid=500#011quota_rule=*:storage=3100b:messages=1024#011login_user=uppp Apr 22 12:35:59 imap21 dovecot: quota-status(p...@kabsi.at): Debug: auth input: p...@kabsi.at home=/home/ppp uid=500 gid=500 quota_rule=*:storage=3100b:messages=1024 login_user=uppp Only auth-worker is looping through the returned fields (single "username changed" entry), and the username isn't changed. quota-status with ldap: Apr 22 13:25:14 imap21 dovecot: auth: Debug: ldap(m2500j6): user search: base=ou=Users,ou=Mail,dc=bnet,dc=at scope=subtree filter=(uid=m2500j6) fields=mailHost,gidNumber,homeDirectory Apr 22 13:25:14 imap21 dovecot: auth: Debug: ldap(m2500j6): result: gidNumber=168 homeDirectory=/tmp mailHost=uppp; homeDirectory,mailHost,gidNumber unused Apr 22 13:25:14 imap21 dovecot: auth: Debug: ldap(m2500j6): username changed m2500j6 -> uppp Apr 22 13:25:14 imap21 dovecot: auth: Debug: ldap(localhost): result: gidNumber=168 homeDirectory=/tmp mailHost=uppp Apr 22 13:25:14 imap21 dovecot: auth: Debug: userdb out: USER#0111#011localhost#011gid=168#011home=/tmp Apr 22 13:25:14 imap21 dovecot: quota-status(m2500j6): Debug: auth input: uppp gid=168 home=/tmp Apr 22 13:25:14 imap21 dovecot: quota-status(m2500j6): Debug: changed username to uppp Again! Only "auth", but username is changed. Even quota-status logs the username change. Thanks! Peter
Re: userdb username change ignored when using (My)SQL was: Re: userdb username changed
>> And the answer is of course yes. Just the userdb out string has the wrong >> value. >> The right value is lost somewhere. But where? > > Your messages to this list seem to miss a feature that is very welcome > on this kind of mailing lists: an actual problem or an issue you want to > fix. I'm sorry that i wasn't able to formulate my problem correctly. :) I try to elaborate: If you read the config in my original message, and read the logs (line by line), then you will notice the following facts: 1. The username change is intended. 2. The log says, that the username change is happening as it should. 3. The log says, that the "userdb out" contains the original (not changed) username. 4. With passdb it works correctly: "passdb out" contains the right (changed) username. Outcome 1.: Fact 3 means, that any service which calls for userdb lookup will get a wrong username. Wrong means here that it's not the username intended for userdb lookup callers. Outcome 2.: For me, fact 4 says that it was the developers intention to be able to change the username. Eg.: to give *db lookup callers a changed username, not the original as entered by the user. But outcome 1. and 2. contradicts each other. That gave me three possible conclusions: a. I made some mistake b. my assumption(s) was/were wrong c. Someone else made a mistake (it's a bug) But i couldn't find out which is the correct, s i sent my original message to the list. And while i tried to confute "conclusion b." i tried the whole process with LDAP. With success. LDAP userdb lookup returns the changed username. Here we are now. :) Thank you, if you read it until here. My only excuse for not writing all that in my original message is that i wanted to keep my problem description clean and simple. In my 23 years of history on technical electronic messaging boards, i've been told many many times that i write irrelevant informations in my messages. (like this) :) And i assumed i couldn't change... :) > > When users can login and the username change is intended (as can be > concluded from your comments), then what is the problem you're reporting? > > Are you trying to reporting the fact that the auth debug output has the > wrong username value? If not, what is it you're to tell us? :) I hope that the debug output is a trustful source of information. But who knows? It would be my third assumption proved wrong - today. And all my struggle just to be able to use quota-status service with postfix. With unauthenticated senders, postfix only sends the recipient address (beside many irrelevant data) to the policy service (quota-status). So userdb has to use the email address to lookup up the quota rule, and to give a username to quota-dict for lookup. My usernames are sadly not email addresses, thats why i had to make query which resolves addresses to usernames. The whole problem started here. Regards, Peter
userdb username change ignored when using (My)SQL was: Re: userdb username changed
Hi! It works when using LDAP. I've duplicated the "username change" debug line, just to see that the variables are really updated: Apr 20 14:30:27 imap21 dovecot: auth-worker(27127): Debug: sql(p...@example.net): username changed p...@example.net -> uppp Apr 20 14:30:27 imap21 dovecot: auth-worker(27127): Debug: sql(uppp): username changed uppp -> uppp Apr 20 14:30:27 imap21 dovecot: auth: Debug: userdb out: USER#0111#011...@example.net#011home=/home/ppp#011uid=500#011gid=500#011quota_rule=*:storage=3100b:messages=1024 And the answer is of course yes. Just the userdb out string has the wrong value. The right value is lost somewhere. But where? Regards, Peter Log of the (for me unusable) LDAP query: Apr 20 14:28:07 imap21 dovecot: auth: Debug: master in: USER#0111#011m2500j6#011service=doveadm Apr 20 14:28:07 imap21 dovecot: auth: Debug: ldap(m2500j6): user search: base=ou=Users,ou=Mail,dc=bnet,dc=at scope=subtree filter=(uid=m2500j6) fields=mailHost Apr 20 14:28:07 imap21 dovecot: auth: Debug: ldap(m2500j6): result: mailHost=localhost; mailHost unused Apr 20 14:28:07 imap21 dovecot: auth: Debug: ldap(m2500j6): username changed m2500j6 -> localhost Apr 20 14:28:07 imap21 dovecot: auth: Debug: ldap(localhost): username changed localhost -> localhost Apr 20 14:28:07 imap21 dovecot: auth: Debug: ldap(localhost): result: mailHost=localhost Apr 20 14:28:07 imap21 dovecot: auth: Debug: userdb out: USER#0111#011localhost#011
Re: userdb username changed
> something strange. It seems that despite the "username changed" line, > auth returns the original username: > sql(p...@example.net): username changed p...@example.net -> uppp > Apr 17 09:27:34 imap21 dovecot: auth: Debug: userdb out: > USER#0111#011...@example.net#011home=/home/ppp#011uid=500#011gid=500#011quota_rule=*:storage=3100b:messages=1024 > # 2.2.15: /etc/dovecot/dovecot.conf Hi! 2.2.16 produces the same. :( Regards, Peter
userdb username changed
Hi!
I'm playing with a postfix + dovecot + mysql test setup, and noticed
something strange. It seems that despite the "username changed" line,
auth returns the original username:
Apr 17 09:27:34 imap21 dovecot: quota-status: Debug: Loading modules
from directory: /usr/lib64/dovecot
(...)
Apr 17 09:27:34 imap21 dovecot: auth-worker(27661): Debug:
sql(p...@example.net): SELECT at.userid AS user, at.home AS home,
at.uid AS uid, at.gid AS gid, concat('*:storage=', at.quotabytes,
'b:messages=', at.quotamessages) AS quota_rule FROM auth at INNER JOIN
mailaddr mt ON at.userid = mt.userid WHERE mt.mailaddress =
'p...@example.net' OR at.userid = 'p...@example.net'
Apr 17 09:27:34 imap21 dovecot: auth-worker(27661): Debug:
sql(p...@example.net): username changed p...@example.net -> uppp
Apr 17 09:27:34 imap21 dovecot: auth: Debug: userdb out:
USER#0111#011...@example.net#011home=/home/ppp#011uid=500#011gid=500#011quota_rule=*:storage=3100b:messages=1024
Apr 17 09:27:34 imap21 dovecot: quota-status: Debug: auth input:
p...@example.net home=/home/ppp uid=500 gid=500
quota_rule=*:storage=3100b:messages=1024
Apr 17 09:27:34 imap21 dovecot: quota-status: Debug: Added userdb
setting: plugin/quota_rule=*:storage=3100b:messages=1024
Apr 17 09:27:34 imap21 dovecot: quota-status(p...@example.net): Debug:
Effective uid=500, gid=500, home=/home/ppp
Apr 17 09:27:34 imap21 dovecot: quota-status(p...@example.net): Debug:
Quota root: name=User quota backend=dict args=:proxy::quota
Apr 17 09:27:34 imap21 dovecot: quota-status(p...@example.net): Debug:
Quota rule: root=User quota mailbox=* bytes=3100 messages=1024
Apr 17 09:27:34 imap21 dovecot: quota-status(p...@example.net): Debug:
Quota grace: root=User quota bytes=310 (10%)
Apr 17 09:27:34 imap21 dovecot: quota-status(p...@example.net): Debug:
dict quota: user=p...@example.net, uri=proxy::quota, noenforcing=0
I've checked this with the LMTP service (i know, normally it wouldn't
get mail addresses) and it produces the same:
Apr 17 09:30:35 imap21 dovecot: auth-worker(27730): Debug:
sql(p...@example.net,127.0.0.1): SELECT at.userid AS user, at.home AS
home, at.uid AS uid, at.gid AS gid, concat('*:storage=',
at.quotabytes, 'b:messages=', at.quotamessages) AS quota_rule FROM
auth at INNER JOIN mailaddr mt ON at.userid = mt.userid WHERE
mt.mailaddress = 'p...@example.net' OR at.userid = 'p...@example.net'
Apr 17 09:30:35 imap21 dovecot: auth-worker(27730): Debug:
sql(p...@example.net,127.0.0.1): username changed p...@example.net ->
uppp
Apr 17 09:30:35 imap21 dovecot: auth: Debug: userdb out:
USER#0111#011...@example.net#011home=/home/ppp#011uid=500#011gid=500#011quota_rule=*:storage=3100b:messages=1024
Apr 17 09:30:35 imap21 dovecot: lmtp(27728): Debug: auth input:
p...@example.net home=/home/ppp uid=500 gid=500
quota_rule=*:storage=3100b:messages=1024
Apr 17 09:30:35 imap21 dovecot: lmtp(27728): Debug: Added userdb
setting: plugin/quota_rule=*:storage=3100b:messages=1024
Apr 17 09:30:35 imap21 dovecot: lmtp(27728, p...@example.net): Debug:
Effective uid=500, gid=500, home=/home/ppp
Passdb works as it should. IMAP test:
Apr 17 09:36:21 imap21 dovecot: auth-worker(27849): Debug:
sql(p...@example.net,10.10.128.25): query: SELECT at.userid AS user,
at.password AS password, at.home AS userdb_home, at.uid AS userdb_uid,
at.gid AS userdb_gid, concat('*:storage=', at.quotabytes,
'b:messages=', at.quotamessages) AS userdb_quota_rule FROM auth at
INNER JOIN mailaddr mt ON at.userid = mt.userid WHERE mt.mailaddress =
'p...@example.net' OR at.userid = 'p...@example.net'
Apr 17 09:36:21 imap21 dovecot: auth-worker(27849): Debug:
sql(p...@example.net,10.10.128.25): username changed p...@example.net ->
uppp
Apr 17 09:36:21 imap21 dovecot: auth: Debug:
sql(p...@example.net,10.10.128.25,): username changed
p...@example.net -> uppp
Apr 17 09:36:21 imap21 dovecot: auth: Debug: client passdb out:
OK#0111#011user=uppp#011original_user=p...@example.net
Apr 17 09:36:21 imap21 dovecot: auth: Debug: master in:
REQUEST#0113358588929#01127844#0111#011dbf373ba260f9990e1ea6b688924d513#011session_pid=27850#011request_auth_token
Apr 17 09:36:21 imap21 dovecot: auth: Debug:
prefetch(uppp,10.10.128.25,): success
Apr 17 09:36:21 imap21 dovecot: auth: Debug: master userdb out:
USER#0113358588929#011uppp#011home=/home/ppp#011uid=500#011gid=500#011quota_rule=*:storage=3100b:messages=1024#011auth_token=737d315a5c0e388a0b3dc2bea3c9e57696d8#011auth_user=p...@example.net
Apr 17 09:36:21 imap21 dovecot: imap-login: Login: user=,
method=PLAIN, rip=10.10.128.25, lip=10.10.97.201, mpid=27850, TLS,
session=
Apr 17 09:36:21 imap21 dovecot: imap: Debug: Loading modules from
directory: /usr/lib64/dovecot
Apr 17 09:36:21 imap21 dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib10_quota_plugin.so
Apr 17 09:36:21 imap21 dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib11_imap_quota_plugin.so
Apr 17 09:36:21 imap21 dovecot: imap: Debug: Added userdb setting:
plugin/quota_rule=*:storage=3100b:messages=1024
