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 at 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 at 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 (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. > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20220525/85e21928/attachment-0001.htm>
dovecot at ptld.com
2022-May-25 15:44 UTC
Force TCP socket disconnect on imap login failure?
> On 05-25-2022 11:28 am, Hippo Man wrote: > 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.Having this rule -A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT before the drop would have that behavior
On Wed, 25 May 2022, Hippo Man wrote:>> 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.Many firewall keep a side cache of estalished connection. Either implicitly or explicitly, an established TCP session will do an end-run around your rules. conntrack seems to be the iptables utility you need to flush a connection cache: https://www.systutorials.com/docs/linux/man/8-conntrack/ e.g. conntrack -D -s x.x.x.x However, even this may not be enough as dovecot may send an outgoing packet (being oblivious to firewall rules), which could re-establish a connection as firewall rules typically allow free egress, and can automatically create missing state entries. I'm not sure how this is typically handled -- maybe an outbound block rule is required to handle this niche case to finally drive a stake through a BFD connection's heart. (more stuff: https://unix.stackexchange.com/questions/646663/iptables-how-kill-established-connection-except-for-an-ip). Joseph Tam <jtam.home at gmail.com>