Force TCP socket disconnect on imap login failure?

Paul Kudla (SCOM.CA Internet Services Inc.) paul at scom.ca
Mon May 23 21:11:13 UTC 2022


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):

1. i have a common syslogger running that ALL logging goes through.

2. I then have conditions against anything being logged that will 
trigger an event.

3. The event triggered in your case would be seeing a line like

    auth: sql(tmp at dereilanatureinn.ca,220.194.140.110,
    <5H72HLPfTp/cwoxu>): unknown user

    pop3-login: Disconnected: Connection closed (auth failed, 1 attempts 

    in 3 secs): user=<edriley at 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 at scom.ca

On 5/23/2022 3:26 PM, dovecot-bounces at 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 at 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.
> 


More information about the dovecot mailing list