<div dir="ltr"><div>Thank you again for your responses!</div><div><br></div><div>> iptables (linux) & pf firewall (freebsd) do drop the packets immediately <br>
> as the tables are updated.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br> <a href="mailto:hippoman@gmail.com" target="_blank">hippoman@gmail.com</a><br> Take a hippopotamus to lunch today.<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 25, 2022 at 5:30 AM Paul Kudla (<a href="http://SCOM.CA">SCOM.CA</a> Internet Services Inc.) <<a href="mailto:paul@scom.ca">paul@scom.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
iptables (linux) & pf firewall (freebsd) do drop the packets immediately <br>
as the tables are updated.<br>
<br>
I know this from experience as I use freebsd for the mail system's and <br>
my asterisk voip server use linux<br>
<br>
At the end of the day the logging has to drive the updates, the only way <br>
to protect yourself against a brute force attack while it is happening <br>
is to have the logging trigger a direct ip table update in the background<br>
<br>
It is my experience that this IS extremely system resource extensive <br>
(why i now run a seperate logging server)<br>
<br>
even with dedicated hardware etc I found it impractical to try to do <br>
this in real time because by the time i hit the trigger, then updated <br>
the database and then updated pf firewall / iptables accordingly usually <br>
the connection was over anyways.<br>
<br>
this issue also exists in postfix where their logging does not allow a <br>
signle line in syslog to indicate sasl user & ip address which makes it <br>
near impossible to track bad ip's / user logins. I ended up patching <br>
postfix sasl auth programming to add a combined line to track stuff like <br>
this.<br>
<br>
In ALL cases the attack is usually over before you can do anything about <br>
it anyways.<br>
<br>
Best to just plan for the future.<br>
<br>
Below is a copy of the Auth penalty support which will help curve this <br>
issue but not stop it .<br>
<br>
It seems to be a balanced approach, postfix carries similiar config's to <br>
acomplish the same thing.<br>
<br>
---------------------------------------------------------------------------<br>
from :<br>
<br>
<a href="https://doc.dovecot.org/configuration_manual/authentication/auth_penalty/" rel="noreferrer" target="_blank">https://doc.dovecot.org/configuration_manual/authentication/auth_penalty/</a><br>
<br>
<br>
Authentication penalty support<br>
<br>
Dovecot anvil process tracks authentication penalties for different IPs <br>
to slow down brute force login attempts. The algorithm works by:<br>
<br>
     First auth failure reply will be delayed for 2 seconds (this <br>
happens even without auth penalty)<br>
<br>
         AUTH_PENALTY_INIT_SECS in src/auth/auth-penalty.h<br>
<br>
     The delay will be doubled for 4 -> 8 seconds, and then the upper <br>
limit of 15 seconds is reached.<br>
<br>
         AUTH_PENALTY_MAX_SECS and AUTH_PENALTY_MAX_PENALTY in <br>
src/auth/auth-penalty.h<br>
<br>
     If the IP is in login_trusted_networks (e.g. webmail), skip any <br>
authentication penalties<br>
<br>
     If the username+password combination is the same as one of the last <br>
10 login attempts, skip increasing authentication penalty.<br>
<br>
         CHECKSUM_VALUE_PTR_COUNT in src/anvil/penalty.c<br>
<br>
         The idea is that if a user has simply configured the password <br>
wrong, it shouldn’t keep increasing the delay.<br>
<br>
         The username+password is tracked as the CRC32 of them, so there <br>
is a small possibility of hash collisions<br>
<br>
Problems:<br>
<br>
     It is still possible to do multiple auth lookups from the same IP <br>
in parallel.<br>
<br>
     For IPv6 it currently blocks the entire /48 block, which may or may <br>
not be what is wanted.<br>
<br>
         PENALTY_IPV6_MASK_BITS in auth-penalty.c<br>
<br>
Authentication penalty tracking can be disabled completely with:<br>
<br>
service anvil {<br>
   unix_listener anvil-auth-penalty {<br>
     mode = 0<br>
   }<br>
}<br>
<br>
Also you can have similar functionality with fail2ban.<br>
<br>
----------------------------------------------------------------------------<br>
<br>
<br>
Happy Wednesday !!!<br>
Thanks - paul<br>
<br>
Paul Kudla<br>
<br>
<br>
Scom.ca Internet Services <<a href="http://www.scom.ca" rel="noreferrer" target="_blank">http://www.scom.ca</a>><br>
004-1009 Byron Street South<br>
Whitby, Ontario - Canada<br>
L1N 4S3<br>
<br>
Toronto 416.642.7266<br>
Main 1.866.411.7266<br>
Fax 1.888.892.7266<br>
Email <a href="mailto:paul@scom.ca" target="_blank">paul@scom.ca</a><br>
<br>
On 5/24/2022 9:55 PM, John Hardin wrote:<br>
> <br>
> On Tue, 24 May 2022, Hippo Man wrote:<br>
> <br>
>> I have already been doing the following for the past year or so: as <br>
>> soon as<br>
>> I detect (via my own, homegrown fail2ban-like log monitoring utility) <br>
>> what<br>
>> I deem to be attempts to log in via imap or pop3 with a dictionary <br>
>> password<br>
>> attack, I immediately do a DROP via iptables. Yes, this will block all<br>
>> future connection attemps from the same host, but unfortunately, it <br>
>> doesn't<br>
>> stop the following scenario, which regularly occurs on my server ...<br>
>><br>
>> * Hacker connects via imap or pop3 to my server.<br>
>> * Hacker makes numerous login attempts one after the other with various<br>
>> passwords, and without disconnecting in between attempts. I've seen 10 <br>
>> and<br>
>> more of these repeated attempts rapidly during a single imap or pop3<br>
>> connection.<br>
>><br>
>> Simply using iptables to DROP or REJECT the connection does not prevent<br>
>> those repeated login attempts during the original imap or pop3 session.<br>
>> Again, this only prevents *future* connections via that host.<br>
> <br>
> It should block all subsequent packets received from that IP address, <br>
> immediately. An in-process connection would appear (to the client) to hang.<br>
> <br>
> Either there is an ACCEPT rule for related traffic somewhere in the <br>
> chain before your new DROP rule, which is matching first and allowing <br>
> the existing connection's packets through, or your DROP rule is <br>
> malformed and not actually matching the traffic.<br>
> <br>
> <br>
</blockquote></div></div>