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. -- John Hardin KA7OHZ http://www.impsec.org/~jhardin/ jhardin at impsec.org pgpk -a jhardin at impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 ----------------------------------------------------------------------- 724 days since the first private commercial manned orbital mission (SpaceX)
Paul Kudla (SCOM.CA Internet Services Inc.)
2022-May-25 09:29 UTC
Force TCP socket disconnect on imap login failure?
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.
>
>