Force TCP socket disconnect on imap login failure?

[Paul Kudla (SCOM.CA Internet Services Inc.)]

iptables (linux) & pf firewall (freebsd) do drop the packets immediately 
as the tables are updated.

I know this from experience as I use freebsd for the mail system's and 
my asterisk voip server use linux

At the end of the day the logging has to drive the updates, the only way 
to protect yourself against a brute force attack while it is happening 
is to have the logging trigger a direct ip table update in the background

It is my experience that this IS extremely system resource extensive 
(why i now run a seperate logging server)

even with dedicated hardware etc I found it impractical to try to do 
this in real time because by the time i hit the trigger, then updated 
the database and then updated pf firewall / iptables accordingly usually 
the connection was over anyways.

this issue also exists in postfix where their logging does not allow a 
signle line in syslog to indicate sasl user & ip address which makes it 
near impossible to track bad ip's / user logins. I ended up patching 
postfix sasl auth programming to add a combined line to track stuff like 
this.

In ALL cases the attack is usually over before you can do anything about 
it anyways.

Best to just plan for the future.

Below is a copy of the Auth penalty support which will help curve this 
issue but not stop it .

It seems to be a balanced approach, postfix carries similiar config's to 
acomplish the same thing.

---------------------------------------------------------------------------
from :

https://doc.dovecot.org/configuration_manual/authentication/auth_penalty/


Authentication penalty support

Dovecot anvil process tracks authentication penalties for different IPs 
to slow down brute force login attempts. The algorithm works by:

     First auth failure reply will be delayed for 2 seconds (this 
happens even without auth penalty)

         AUTH_PENALTY_INIT_SECS in src/auth/auth-penalty.h

     The delay will be doubled for 4 -> 8 seconds, and then the upper 
limit of 15 seconds is reached.

         AUTH_PENALTY_MAX_SECS and AUTH_PENALTY_MAX_PENALTY in 
src/auth/auth-penalty.h

     If the IP is in login_trusted_networks (e.g. webmail), skip any 
authentication penalties

     If the username+password combination is the same as one of the last 
10 login attempts, skip increasing authentication penalty.

         CHECKSUM_VALUE_PTR_COUNT in src/anvil/penalty.c

         The idea is that if a user has simply configured the password 
wrong, it shouldn’t keep increasing the delay.

         The username+password is tracked as the CRC32 of them, so there 
is a small possibility of hash collisions

Problems:

     It is still possible to do multiple auth lookups from the same IP 
in parallel.

     For IPv6 it currently blocks the entire /48 block, which may or may 
not be what is wanted.

         PENALTY_IPV6_MASK_BITS in auth-penalty.c

Authentication penalty tracking can be disabled completely with:

service anvil {
   unix_listener anvil-auth-penalty {
     mode = 0
   }
}

Also you can have similar functionality with fail2ban.

----------------------------------------------------------------------------


Happy Wednesday !!!
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/24/2022 9:55 PM, John Hardin wrote:
> 
> On Tue, 24 May 2022, Hippo Man wrote:
> 
>> I have already been doing the following for the past year or so: as 
>> soon as
>> I detect (via my own, homegrown fail2ban-like log monitoring utility) 
>> what
>> I deem to be attempts to log in via imap or pop3 with a dictionary 
>> password
>> attack, I immediately do a DROP via iptables. Yes, this will block all
>> future connection attemps from the same host, but unfortunately, it 
>> doesn't
>> stop the following scenario, which regularly occurs on my server ...
>>
>> * Hacker connects via imap or pop3 to my server.
>> * Hacker makes numerous login attempts one after the other with various
>> passwords, and without disconnecting in between attempts. I've seen 10 
>> and
>> more of these repeated attempts rapidly during a single imap or pop3
>> connection.
>>
>> Simply using iptables to DROP or REJECT the connection does not prevent
>> those repeated login attempts during the original imap or pop3 session.
>> Again, this only prevents *future* connections via that host.
> 
> It should block all subsequent packets received from that IP address, 
> immediately. An in-process connection would appear (to the client) to hang.
> 
> Either there is an ACCEPT rule for related traffic somewhere in the 
> chain before your new DROP rule, which is matching first and allowing 
> the existing connection's packets through, or your DROP rule is 
> malformed and not actually matching the traffic.
> 
>