Thank you again for your responses!
iptables (linux) & pf firewall (freebsd) do drop the packets immediately as the tables are updated.
In my case, that is not occurring. After issuing the iptables DROP command, the client can continue to send more and more login attempts. Only when the client disconnects does the block of the socket seem to work for that IP address. I continue to see numerous instances of this behavior.
I'm running debian 8. Perhaps the iptables on this nearly obsolete version of linux do not behave in the way that you have experienced.
-- hippoman@gmail.com Take a hippopotamus to lunch today.
On Wed, May 25, 2022 at 5:30 AM Paul Kudla (SCOM.CA Internet Services Inc.) <paul@scom.ca> wrote:
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 (thishappens 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 upperlimit of 15 seconds is reached.
AUTH_PENALTY_MAX_SECS and AUTH_PENALTY_MAX_PENALTY insrc/auth/auth-penalty.h
If the IP is in login_trusted_networks (e.g. webmail), skip anyauthentication penalties
If the username+password combination is the same as one of the last10 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 passwordwrong, it shouldn’t keep increasing the delay.
The username+password is tracked as the CRC32 of them, so thereis a small possibility of hash collisions
Problems:
It is still possible to do multiple auth lookups from the same IPin parallel.
For IPv6 it currently blocks the entire /48 block, which may or maynot be what is wanted.
PENALTY_IPV6_MASK_BITS in auth-penalty.cAuthentication 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@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.