Ok would like to help and I DO understand the issue at hand.

It took me with custom programming 5 years of tinkering to get to what i have today.

So a few questions / comments ??

Are you running an sql database or just user-db (local) to do the lookups ?

sql gives you some major flexability on how to track and ignore ip blocks etc etc etc upon logins.

Issues to consider (I will explain the system i wrote for SCOM.CA as I went though a lot to get here and you like most are probably experiencing the same hack attempts.)

Note I am not trying to get off topic but you need to think about stuff like this through a bit.

You also have to consider people trying to send through postfix as it is the same issue in reverse.

Under SCOM I do the following (only meant to be a guideline):

1. i have a common syslogger running that ALL logging goes through.

2. I then have conditions against anything being logged that will trigger an event.

3. The event triggered in your case would be seeing a line like

   auth: sql(tmp@dereilanatureinn.ca,220.194.140.110, <5H72HLPfTp/cwoxu>): unknown user

   pop3-login: Disconnected: Connection closed (auth failed, 1 attempts

   in 3 secs): user=<edriley@scom.ca>, method=PLAIN, rip=110.44.124.224, lip=65.39.148.18

there are other conditions but you get the idea.

Ok from here it starts getting complicated.

The idea is to keep the rift raft out and allow good users in.

Easier said then done.

I track all bad logins from all bad ip addresses and then run a seperate database table that tracks that.

the ip address that gets tracked lands in two places,

the firewall tables (which for me are global)

&

the user in my database.

if a user is unknown (example above) then at least the first condition will catch a bad hack attempt based on ip. Most hack attempts by ip address usually keep sending common login names (like admin, ftp, ftpuser etc etc) hoping to match to a common account.

for the user (which is relative here) i let 30 attempts go by every 30 minutes and 500 per month, after which the user is blocked via auth in sql and will have to call to get unlocked. Usually the ip address is blacklisted before the username is so its not that much of a deal.

afterwhich it becomes part of the user query to lock out the userfrom anywhere as they are obviously getting hacked.

when an ip is doing the hacking then i count using the same formula and then blacklist it internal to all of my servers (thus a database makes it earier to track)

I run freebsd and thus use pf firewall, iptables can do the same with the same info you just need to build the tables and uodate them. (i update mine every 10 minutes, i find pf does this quicker on large lables (like 10,000 blocked) )

Now for the issue at hand that you are asking about:

I am sure that the c programming could be patched along the line to do exactly what you are asking,

However Issues that pop up.

so you hang up on the connection, they will probably just login again anyways which means without tracking the ip & username stats and updating accordingly it will really not change anything at the end of the day.

In my experience I see people / servers etc constantly hacking my side and what i generally described above turned out to be the only real fix, and not even really that guarenteed to work!

I do get ip's that get blacklisted by accident (i do the whole class 'c' as the 'c' block is usually all the same guy) but i get a good one maybe every few months, usually when i block it there are not many complaints after that.

I know the above is complicated, fyi i track postfix's sasl auth's as well but in that case to get a username & ip address on one syslog line i had to patch the sasl auth c file to get a log entry that was useable.

Postfix simply will NOT provide the info on one line.

Between both of the conditions above the server's remain fairly useable and secured.

the CSF firewall option below IS valid but i find you need to track IP address & username or you end up blocking stuff you dont want to

also on another note IPV6 (at least in canada) is becoming a pain for isp's

many cable companies, dsl providers etc are assigning an ipv6 address and then converting it to ipv4 on the way out the door from their networks using double natting ?

Issue is you can have 10,000 people all sharing that same ip address and if you block it then that will prevent other 'good' people from logging in, again back to tracking the username in this case gives you an out if the hacker is just using a list obtained elsewhere on the net.

Food for thought.

Happy Monday !!! 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/23/2022 3:26 PM, dovecot-bounces@dovecot.org wrote:

On 2022-05-23 20:11, Lloyd Zusman wrote:

...

I'm running dovecot 2.2.13 under Debian 8.

I'd like to force an immediate TCP socket disconnect after any imap login attempt that fails.

Right now, if invalid credentials are supplied during an imap login, the client can keep retrying logins with different credentials. However, I want to prevent that from occurring by causing the socket connection to be closed as soon as there is any failed login attempt.

I haven't been able to find any dovecot configuration setting which could control this behavior, but I'm hoping that I just missed something.

Thank you very much for any suggestions.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

Hi there,

Try CSF firewall. Make sure to enable Login Failure Detection and Max Retries Per X Minutes, and notice with such option set, it will permenantly block the IP addresses that exceeds maximum login failures in the specified interval.

Anyhow, my personal recommendation in terms of security, its to use web mail and limit login attempts per minutes and for higher security, setup a VPN and disallow access to the web mail except through the VPN.

Good luck.

Zakaia.

Thank you, but fail2ban doesn't do what I need. Here is why ...

I have used fail2ban and also my own homegrown log monitor program for this purpose. In both cases, I can detect the failed imap logins and then cause the following command to be run ...

iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j DROP

However, this does not drop connections that are existing and already open. It will only drop *future* connections from that IP address to port 143.

This is why I want to kill the existing connection. Even after that "iptables" command is issued, the entity which is connected to the imap port can continue to send more and more imap commands.

If I can drop the TCP connection as soon as an imap login fails and also issue that kind of "iptables" command, then the client would have to reconnect in order to retry other login attempts. Those future connections would then be successfully blocked by that iptables rule.

And even if I issue a "tcpdrop" command instead of just the "iptables" command, it doesn't kill the already-open connection. It just force-blocks future connections.

I'm thinking of patching the dovecot source code to create a personal version which immediately disconnects from the socket after login failure. Of course, I would prefer not to do that, if there is another way to accomplish this.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <jhp@jhprins.org> wrote:

Look at fail2ban. Should be able to do that for you.

Jan Hugo

On 5/23/22 21:11, Lloyd Zusman wrote:

I'm running dovecot 2.2.13 under Debian 8.

I'd like to force an immediate TCP socket disconnect after any imap login attempt that fails.

Right now, if invalid credentials are supplied during an imap login, the client can keep retrying logins with different credentials. However, I want to prevent that from occurring by causing the socket connection to be closed as soon as there is any failed login attempt.

I haven't been able to find any dovecot configuration setting which could control this behavior, but I'm hoping that I just missed something.

Thank you very much for any suggestions.

hippoman@gmail.com Take a hippopotamus to lunch today.

i googled a little, i was just curious about your question.

found a stackoverflow question which, answered, says that using gdb one can close the fd, after using lsof to find it out.

oh, and your iptables command... you have the address aaa. etc with a -d, i think you mean the source ip address of the connection, -s, right ?

if you want, i can provide that link.

On Mon, 2022-05-23 at 17:16 -0400, Hippo Man wrote:

OOPS! I incorrectly copied and pasted the iptables command in my previous message. Here is the correct iptables command:

iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d aaa.bbb.ccc.ddd -j DROP

This command successfully blocks *future* connections to ports 143 and 993 from that IP address, but as I mentioned, it doesn't kill the currently open connection.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman@gmail.com> wrote:

    Thank you, but fail2ban doesn't do what I need. Here is
    why ...
    
    
    I have used fail2ban and also my own homegrown log monitor
    program for this purpose. In both cases, I can detect the
    failed imap logins and then cause the following command to be
    run ...
    
    
    iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j
    DROP
    
    
    However, this does not drop connections that are existing and
    already open. It will only drop *future* connections from that
    IP address to port 143.
    
    
    
    This is why I want to kill the existing connection. Even after
    that "iptables" command is issued, the entity which is
    connected to the imap port can continue to send more and more
    imap commands.
    
    
    If I can drop the TCP connection as soon as an imap login
    fails and also issue that kind of "iptables" command, then the
    client would have to reconnect in order to retry other login
    attempts. Those future connections would then be successfully
    blocked by that iptables rule.
    
    
    And even if I issue a "tcpdrop" command instead of just the
    "iptables" command, it doesn't kill the already-open
    connection. It just force-blocks future connections.
    
    
    I'm thinking of patching the dovecot source code to create a
    personal version which immediately disconnects from the socket
    after login failure. Of course, I would prefer not to do that,
    if there is another way to accomplish this.
    
    
    
    -- 
     hippoman@gmail.com
     Take a hippopotamus to lunch today.
    
    
    
    
    On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins
    <jhp@jhprins.org> wrote:
    
            Look at fail2ban.
            Should be able to do that for you.
            
            Jan Hugo
            
            
            On 5/23/22 21:11, Lloyd Zusman wrote:
            
            > I'm running dovecot 2.2.13 under Debian 8.
            > I'd like to force an immediate TCP socket disconnect
            > after any imap login attempt that fails.
            > 
            > Right now, if invalid credentials are supplied
            > during an imap login, the client can keep retrying
            > logins with different credentials. However, I want
            > to prevent that from occurring by causing the socket
            > connection to be closed as soon as there is any
            > failed login attempt.
            > 
            > I haven't been able to find any dovecot
            > configuration setting which could control this
            > behavior, but I'm hoping that I just missed
            > something.
            > 
            > Thank you very much for any suggestions.
            > 
            > 
            > -- 
            >  hippoman@gmail.com
            >  Take a hippopotamus to lunch today.
            > 
            
            

Thank you very much. Yes, I did some manual tests via gdb to close the fd of a connected socket, and indeed the dovecot behavior is not desirable: this seems to crash dovecot. So I agree that this is not a good approach.

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.

So, this is what I am now planning to do ...

I will get the latest dovecot source code and modify it so that dovecot will disconnect after "N" failed imap or pop3 login attacks, where "N" is some sort of configuration variable (with a default of zero, meaning do not disconnect). I will then use this personal version of dovecot with "N" set to a fairly low value (probably 1!). Furthermore, I will continue to automatically monitor the logs and perform the same iptables DROP actions for the failed login attempts. The combination of these two actions will give me the behavior that I desire.

If this modified, personal version of dovecot actually works the way I am hoping, I will make a patch available here or wherever is appropriate.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Tue, May 24, 2022 at 5:13 AM Paul Kudla (SCOM.CA Internet Services Inc.) <paul@scom.ca> wrote:

closing a socket can leave a process in an undertimed state pending how the code reacts

blocking in the background via iptables would just stop traffic and the process should die cleanly.

programming 101, network connections at best dont like the plug being pulled once they start to talk but if the connection just dies off then it is just a network timeout error with no real harm being done.

just a thought.

Happy Tuesday !!! 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/23/2022 9:25 PM, John Tulp wrote:

...

i googled a little, i was just curious about your question.

found a stackoverflow question which, answered, says that using gdb one can close the fd, after using lsof to find it out.

oh, and your iptables command... you have the address aaa. etc with a -d, i think you mean the source ip address of the connection, -s, right ?

if you want, i can provide that link.

On Mon, 2022-05-23 at 17:16 -0400, Hippo Man wrote:

...

OOPS! I incorrectly copied and pasted the iptables command in my previous message. Here is the correct iptables command:

iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d aaa.bbb.ccc.ddd -j DROP

This command successfully blocks *future* connections to ports 143 and 993 from that IP address, but as I mentioned, it doesn't kill the currently open connection.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman@gmail.com> wrote:

     Thank you, but fail2ban doesn't do what I need. Here is
     why ...


     I have used fail2ban and also my own homegrown log monitor
     program for this purpose. In both cases, I can detect the
     failed imap logins and then cause the following command to be
     run ...


     iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j
     DROP


     However, this does not drop connections that are existing and
     already open. It will only drop *future* connections from that
     IP address to port 143.



     This is why I want to kill the existing connection. Even after
     that "iptables" command is issued, the entity which is
     connected to the imap port can continue to send more and more
     imap commands.


     If I can drop the TCP connection as soon as an imap login
     fails and also issue that kind of "iptables" command, then the
     client would have to reconnect in order to retry other login
     attempts. Those future connections would then be successfully
     blocked by that iptables rule.


     And even if I issue a "tcpdrop" command instead of just the
     "iptables" command, it doesn't kill the already-open
     connection. It just force-blocks future connections.


     I'm thinking of patching the dovecot source code to create a
     personal version which immediately disconnects from the socket
     after login failure. Of course, I would prefer not to do that,
     if there is another way to accomplish this.



     --
      hippoman@gmail.com
      Take a hippopotamus to lunch today.




     On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins
     <jhp@jhprins.org> wrote:

             Look at fail2ban.
             Should be able to do that for you.

             Jan Hugo


             On 5/23/22 21:11, Lloyd Zusman wrote:

             > I'm running dovecot 2.2.13 under Debian 8.
             > I'd like to force an immediate TCP socket disconnect
             > after any imap login attempt that fails.
             >
             > Right now, if invalid credentials are supplied
             > during an imap login, the client can keep retrying
             > logins with different credentials. However, I want
             > to prevent that from occurring by causing the socket
             > connection to be closed as soon as there is any
             > failed login attempt.
             >
             > I haven't been able to find any dovecot
             > configuration setting which could control this
             > behavior, but I'm hoping that I just missed
             > something.
             >
             > Thank you very much for any suggestions.
             >
             >
             > --
             >  hippoman@gmail.com
             >  Take a hippopotamus to lunch today.
             >

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@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.

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-establishe...).

Joseph Tam <jtam.home@gmail.com>

On Tue, 24 May 2022, Hippo Man wrote:

Late to this party.

• 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.

Maybe this settings helps?

auth_failure_delay = 5 secs

I get lots of BFD, and although they have no chance of guessing a password this way, it produces an annoying amount of rubbish in my logs. This slow them down to either reduce the volume of attempts (and logs), but also gives you ample time to enact a countermeasure.

I will get the latest dovecot source code and modify it so that dovecot will disconnect after "N" failed imap or pop3 login attacks, where "N" is some sort of configuration variable (with a default of zero, meaning do not disconnect). I will then use this personal version of dovecot with "N" set to a fairly low value (probably 1!).

1, in my opinion, is really too low. This can lockout a legitimate user with a simple typo, or network hiccough.

It would be better to externalize this, rather than bake it into dovecot. Have you considered

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

Furthermore, I will continue to automatically monitor the logs and perform the same iptables DROP actions for the failed login attempts. The combination of these two actions will give me the behavior that I desire.

You can also preempt many BFD runs without resorting to one-strike-you're-out policy

1) Look up connecting host in RBL and do a prememptive block
e.g. bl.websitewelcome.com, bl.blocklist.de, dnsbl.darklist.de
are some examples of brute force DNSRBLs.  You'll find many of
attacking IPs are represented on one of these lists.

2) Triggerimmediate block against authentication attempts that
can not possibly be real (e.g. "mysql", "testuser", "nagios", etc.)

Joseph Tam <jtam.home@gmail.com>

Follow-up:

I have tested dovecot's auth-policy mechanism, and I got it to work.

However, I see now that even this auth-policy mechanism doesn't give dovecot any way to *kill* an existing connection. It can allow dovecot to reject login attempts, and it can cause external activities to be performed based on the results of authentication, but terminating a connection is not something which can be accomplished via auth-policy.

I also read your other message where you referred to a stackexchange conversation about killing existing connections. That conversation confirms what I have observed in my own environment: that iptables offers no way to terminate an already established connection.

Also, "conntrack" is mentioned in that discussion, but I haven't been able to get conntrack to work on my debian-8 system.

Therefore, I think I will have to go forward with my idea of creating my own, personal version of dovecot which optionally allows the killing of connections after "N" failed login attempts (where "N" is configurable).

But in any case, the auth-policy mechanism allows me to deal with login issues more efficiently than monitoring log messages, and I will now switch some (all?) of my dovecot-based log-monitoring activites to auth-policy.

Thank you again for *all* your suggestions and help!

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Wed, May 25, 2022 at 9:00 PM Hippo Man <hippoman@gmail.com> wrote:

Thank you very much!

I didn't know about auth_policy, and I can see that an auth_policy server would be ideal for me.

I could transfer a lot of the logic to that server and dispense with most (and maybe even all) of my logfile monitoring.

I'm already using RBL with postfix, and it will probably indeed be helpful with dovecot, as well.

As for immediate triggering against impossible auth attempts, I guess I could come up with some sort of dictionary of these kinds of terms.

I very much appreciate all these ideas.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Wed, May 25, 2022 at 6:03 PM Joseph Tam <jtam.home@gmail.com> wrote:

...

On Tue, 24 May 2022, Hippo Man wrote:

Late to this party.

...

• 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.

Maybe this settings helps?

    auth_failure_delay = 5 secs

I get lots of BFD, and although they have no chance of guessing a password this way, it produces an annoying amount of rubbish in my logs. This slow them down to either reduce the volume of attempts (and logs), but also gives you ample time to enact a countermeasure.

...

I will get the latest dovecot source code and modify it so that dovecot will disconnect after "N" failed imap or pop3 login attacks, where "N" is some sort of configuration variable (with a default of zero, meaning do not disconnect). I will then use this personal version of dovecot with "N" set to a fairly low value (probably 1!).

1, in my opinion, is really too low. This can lockout a legitimate user with a simple typo, or network hiccough.

It would be better to externalize this, rather than bake it into dovecot. Have you considered

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

...

Furthermore, I will continue to automatically monitor the logs and perform the same iptables DROP actions for the failed login attempts. The combination of these two actions will give me the behavior that I desire.

You can also preempt many BFD runs without resorting to one-strike-you're-out policy

    1) Look up connecting host in RBL and do a prememptive block
    e.g. bl.websitewelcome.com, bl.blocklist.de, dnsbl.darklist.de
    are some examples of brute force DNSRBLs.  You'll find many of
    attacking IPs are represented on one of these lists.

    2) Triggerimmediate block against authentication attempts that
    can not possibly be real (e.g. "mysql", "testuser", "nagios",

etc.)

Joseph Tam <jtam.home@gmail.com>

I'm sorry, but I am not seeing the behavior that you describe.

My iptables rule which blocks IP addresses is at the highest precedence, and in fact, it is my *only* iptables rule. I repeatedly and regularly see that this rule does not terminate nor block existing connections. It only blocks *future* connections by the IP addresses that it references.

This is my one and only iptables rule (where "drop-list" is an ipset list).

iptables -I INPUT -m set --match-set drop-list src -j DROP

As soon as I detect a "bad" login attempt, I cause the following command to run:

ipset add drop-list aaa.bbb.ccc.ddd -exist (where aaa.bbb.ccc.ddd is the offending IP address)

Perhaps there is a delay before the iptable rule takes effect whenever the ipset list is updated. Or perhaps this is some sort of behavior that only exists on earlier linux versions such as debian-8, which I am running.

In any case, I often see activity on existing connections that continues after this ipset command is invoked for those connections' IP addresses.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Thu, May 26, 2022 at 3:34 PM Bernardo Reino <reinob@bbmk.org> wrote:

On Thu, 26 May 2022, Hippo Man wrote:

...

[...]

I also read your other message where you referred to a stackexchange conversation about killing existing connections. That conversation confirms what I have observed in my own environment: that iptables offers no way to terminate an already established connection.

Also, "conntrack" is mentioned in that discussion, but I haven't been able to get conntrack to work on my debian-8 system.

If you use fail2ban or something which adds a rule to block an ip address using iptables or nftables, it will work.

You have been already told that if you have a rule allowing established/related connections having a higher precedence than the blocking rule, then obviously the blocking will not work.

I use nftables, and have "ct state established,related accept" at the very bottom of my ruleset (just before the default action: drop).

For fail2ban I use a script which adds the ip to a nftables set (aptly named fail2ban), and I have the rule "ip saddr @fail2ban drop" near the top of the ruleset.

I just tested blocking myself (ssh instead of imaps, but there should not be any difference) and the block is immediate.

Good luck!

Just for clarification (this probably won't help achieve your primary goal to reset the connections): Iptables can block future connections _and_ stop existing connections to receive (and send) packets (even the command you posted). What it can't do is closing existing connections (sending a FIN). If the example you show can not block existing connections you have somewhere before the chain a RELATED, ESTABLISHED rule with ACCEPT as target. This is a common mistake. Your fail2ban rules have to come _before_ you check for related and established connections.

I never tested this, but you could try using "-j REJECT --reject-with tcp-reset" instead of DROP. Then at least a RST would be sent.

Hippo Man <hippoman@gmail.com> ezt írta (időpont: 2022. máj. 23., H, 23:17):

OOPS! I incorrectly copied and pasted the iptables command in my previous message. Here is the correct iptables command:

iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d aaa.bbb.ccc.ddd -j DROP

This command successfully blocks *future* connections to ports 143 and 993 from that IP address, but as I mentioned, it doesn't kill the currently open connection.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman@gmail.com> wrote:

...

Thank you, but fail2ban doesn't do what I need. Here is why ...

I have used fail2ban and also my own homegrown log monitor program for this purpose. In both cases, I can detect the failed imap logins and then cause the following command to be run ...

iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j DROP

However, this does not drop connections that are existing and already open. It will only drop *future* connections from that IP address to port 143.

This is why I want to kill the existing connection. Even after that "iptables" command is issued, the entity which is connected to the imap port can continue to send more and more imap commands.

If I can drop the TCP connection as soon as an imap login fails and also issue that kind of "iptables" command, then the client would have to reconnect in order to retry other login attempts. Those future connections would then be successfully blocked by that iptables rule.

And even if I issue a "tcpdrop" command instead of just the "iptables" command, it doesn't kill the already-open connection. It just force-blocks future connections.

I'm thinking of patching the dovecot source code to create a personal version which immediately disconnects from the socket after login failure. Of course, I would prefer not to do that, if there is another way to accomplish this.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <jhp@jhprins.org> wrote:

...

Look at fail2ban. Should be able to do that for you.

Jan Hugo

On 5/23/22 21:11, Lloyd Zusman wrote:

I'm running dovecot 2.2.13 under Debian 8.

I'd like to force an immediate TCP socket disconnect after any imap login attempt that fails.

Right now, if invalid credentials are supplied during an imap login, the client can keep retrying logins with different credentials. However, I want to prevent that from occurring by causing the socket connection to be closed as soon as there is any failed login attempt.

I haven't been able to find any dovecot configuration setting which could control this behavior, but I'm hoping that I just missed something.

Thank you very much for any suggestions.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

Just a few comments.

• The below commands drops ALL future connections to the IMAP ports and not just the one from that specific IP address.
• It all depends on the ordering of the rest of your iptables rules. A lot of iptables setups have an accept related / established in the top of the INPUT chain and then indeed the traffic will continue as long as the connection is established. If you put a correct drop rule in the top of your iptables INPUT chain it will block all traffic including any related/established.

Fail2Ban is able to insert such a drop rule in the top of the INPUT chain and thereby block all further tries. This is exactly how I have setup my fail2ban and it works.

The first few lines of my iptables input chain look like this:

  29M 2249M f2b-dovecot  tcp  --  *      * 0.0.0.0/0            0.0.0.0/0            multiport dports 110,143,993,995 9969K 2545M f2b-sasl   tcp  --  *      *       0.0.0.0/0 0.0.0.0/0            multiport dports 25,465 9691K 2788M ACCEPT     all  --  lo     *       0.0.0.0/0 0.0.0.0/0 134M  257G ACCEPT     all  --  *      *       0.0.0.0/0 0.0.0.0/0            state RELATED,ESTABLISHED

Jan Hugo Prins

On 5/23/22 23:16, Hippo Man wrote:

OOPS! I incorrectly copied and pasted the iptables command in my previous message. Here is the correct iptables command:

iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d aaa.bbb.ccc.ddd -j DROP

This command successfully blocks *future* connections to ports 143 and 993 from that IP address, but as I mentioned, it doesn't kill the currently open connection.

-- hippoman@gmail.com Take a hippopotamus to lunch today.

On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman@gmail.com> wrote:

Thank you, but fail2ban doesn't do what I need. Here is why ...

I have used fail2ban and also my own homegrown log monitor program
for this purpose. In both cases, I can detect the failed imap
logins and then cause the following command to be run ...

iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j DROP

However, this does not drop connections that are existing and
already open. It will only drop *future* connections from that IP
address to port 143.

This is why I want to kill the existing connection. Even after
that "iptables" command is issued, the entity which is connected
to the imap port can continue to send more and more imap commands.

If I can drop the TCP connection as soon as an imap login fails
and also issue that kind of "iptables" command, then the client
would have to reconnect in order to retry other login attempts.
Those future connections would then be successfully blocked by
that iptables rule.

And even if I issue a "tcpdrop" command instead of just the
"iptables" command, it doesn't kill the already-open connection.
It just force-blocks future connections.

I'm thinking of patching the dovecot source code to create a
personal version which immediately disconnects from the socket
after login failure. Of course, I would prefer not to do that, if
there is another way to accomplish this.

-- 
hippoman@gmail.com
 Take a hippopotamus to lunch today.


On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <jhp@jhprins.org>
wrote:

    Look at fail2ban.
    Should be able to do that for you.

    Jan Hugo


    On 5/23/22 21:11, Lloyd Zusman wrote:

...

    I'm running dovecot 2.2.13 under Debian 8.

    I'd like to force an immediate TCP socket disconnect after
    any imap login attempt that fails.

    Right now, if invalid credentials are supplied during an imap
    login, the client can keep retrying logins with different
    credentials. However, I want to prevent that from occurring
    by causing the socket connection to be closed as soon as
    there is any failed login attempt.

    I haven't been able to find any |dovecot| configuration
    setting which could control this behavior, but I'm hoping
    that I just missed something.

    Thank you very much for any suggestions.

    -- 
    hippoman@gmail.com
     Take a hippopotamus to lunch today.

On 24.05.22 09:36, Jan Hugo Prins wrote:

• The below commands drops ALL future connections to the IMAP ports and not just the one from that specific IP address.

On 5/23/22 23:16, Hippo Man wrote:

...

OOPS! I incorrectly copied and pasted the iptables command in my previous message. Here is the correct iptables command:

iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d aaa.bbb.ccc.ddd -j DROP

This command successfully blocks *future* connections to ports 143 and 993 from that IP address, but as I mentioned, it doesn't kill the currently open connection.

That's because the "correct" iptables command still uses "-d" instead of the "-s" that'd match the "*from* that IP address" specification. ;-)

Even if you don't have a tool at hand that can tear down the existing TCP connection, and don't want to give up the ESTABLISHED-ACCEPT rule's priority (it's some additional burden to the CPU to match *all* incoming IMAP(S) packets against the blocklist, after all), you could always render it effectively unusable by setting a (blackhole) host route for the IP.

Regards,

Jochen Bern Systemingenieur

Binect GmbH