Ok would like to help and I DO understand the issue at hand.
It took me with custom programming 5 years of tinkering to get to what i have today.
So a few questions / comments ??
Are you running an sql database or just user-db (local) to do the lookups ?
sql gives you some major flexability on how to track and ignore ip blocks etc etc etc upon logins.
Issues to consider (I will explain the system i wrote for SCOM.CA as I went though a lot to get here and you like most are probably experiencing the same hack attempts.)
Note I am not trying to get off topic but you need to think about stuff like this through a bit.
You also have to consider people trying to send through postfix as it is the same issue in reverse.
Under SCOM I do the following (only meant to be a guideline):
i have a common syslogger running that ALL logging goes through.
I then have conditions against anything being logged that will trigger an event.
The event triggered in your case would be seeing a line like
auth: sql(tmp@dereilanatureinn.ca,220.194.140.110, <5H72HLPfTp/cwoxu>): unknown user
pop3-login: Disconnected: Connection closed (auth failed, 1 attempts
in 3 secs): user=<edriley@scom.ca>, method=PLAIN, rip=110.44.124.224, lip=65.39.148.18
there are other conditions but you get the idea.
Ok from here it starts getting complicated.
The idea is to keep the rift raft out and allow good users in.
Easier said then done.
I track all bad logins from all bad ip addresses and then run a seperate database table that tracks that.
the ip address that gets tracked lands in two places,
the firewall tables (which for me are global)
&
the user in my database.
if a user is unknown (example above) then at least the first condition will catch a bad hack attempt based on ip. Most hack attempts by ip address usually keep sending common login names (like admin, ftp, ftpuser etc etc) hoping to match to a common account.
for the user (which is relative here) i let 30 attempts go by every 30 minutes and 500 per month, after which the user is blocked via auth in sql and will have to call to get unlocked. Usually the ip address is blacklisted before the username is so its not that much of a deal.
afterwhich it becomes part of the user query to lock out the userfrom anywhere as they are obviously getting hacked.
when an ip is doing the hacking then i count using the same formula and then blacklist it internal to all of my servers (thus a database makes it earier to track)
I run freebsd and thus use pf firewall, iptables can do the same with the same info you just need to build the tables and uodate them. (i update mine every 10 minutes, i find pf does this quicker on large lables (like 10,000 blocked) )
Now for the issue at hand that you are asking about:
I am sure that the c programming could be patched along the line to do exactly what you are asking,
However Issues that pop up.
so you hang up on the connection, they will probably just login again anyways which means without tracking the ip & username stats and updating accordingly it will really not change anything at the end of the day.
In my experience I see people / servers etc constantly hacking my side and what i generally described above turned out to be the only real fix, and not even really that guarenteed to work!
I do get ip's that get blacklisted by accident (i do the whole class 'c' as the 'c' block is usually all the same guy) but i get a good one maybe every few months, usually when i block it there are not many complaints after that.
I know the above is complicated, fyi i track postfix's sasl auth's as well but in that case to get a username & ip address on one syslog line i had to patch the sasl auth c file to get a log entry that was useable.
Postfix simply will NOT provide the info on one line.
Between both of the conditions above the server's remain fairly useable and secured.
the CSF firewall option below IS valid but i find you need to track IP address & username or you end up blocking stuff you dont want to
also on another note IPV6 (at least in canada) is becoming a pain for isp's
many cable companies, dsl providers etc are assigning an ipv6 address and then converting it to ipv4 on the way out the door from their networks using double natting ?
Issue is you can have 10,000 people all sharing that same ip address and if you block it then that will prevent other 'good' people from logging in, again back to tracking the username in this case gives you an out if the hacker is just using a list obtained elsewhere on the net.
Food for thought.
Happy Monday !!! Thanks - paul
Paul Kudla
Scom.ca Internet Services <http://www.scom.ca> 004-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3
Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul@scom.ca
On 5/23/2022 3:26 PM, dovecot-bounces@dovecot.org wrote:
On 2022-05-23 20: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.
-- hippoman@gmail.com Take a hippopotamus to lunch today.
Hi there,
Try CSF firewall. Make sure to enable Login Failure Detection and Max Retries Per X Minutes, and notice with such option set, it will permenantly block the IP addresses that exceeds maximum login failures in the specified interval.
Anyhow, my personal recommendation in terms of security, its to use web mail and limit login attempts per minutes and for higher security, setup a VPN and disallow access to the web mail except through the VPN.
Good luck.
Zakaia.