Re: Force TCP socket disconnect on imap login failure?

[dovecot]

> My iptables rule which blocks IP addresses is at the highest precedence, and 
> in fact, it is my *only* iptables rule. 

To verify there aren't any rules being applied that you might not be aware of, 
try:

iptables -n -L

Re: Force TCP socket disconnect on imap login failure?

[Hippo Man]

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.

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




On Thu, May 26, 2022 at 3:34 PM Bernardo Reino  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!
>
>

Re: Force TCP socket disconnect on imap login failure?

[Bernardo Reino]

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!

Re: Force TCP socket disconnect on imap login failure?

[Hippo Man]

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!

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


On Wed, May 25, 2022 at 9:00 PM Hippo Man  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.
>
>
>
>
> --
>  hippo...@gmail.com
>  Take a hippopotamus to lunch today.
>
>
> On Wed, May 25, 2022 at 6:03 PM Joseph Tam  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 
>>
>

Re: Force TCP socket disconnect on imap login failure?

[Hippo Man]

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.




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


On Wed, May 25, 2022 at 6:03 PM Joseph Tam  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 
>

Re: Force TCP socket disconnect on imap login failure?

[Joseph Tam]

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 

Re: Force TCP socket disconnect on imap login failure?

[Joseph Tam]

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 

Re: Force TCP socket disconnect on imap login failure?

[dovecot]

> 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

Re: Force TCP socket disconnect on imap login failure?

[Hippo Man]

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.

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


On Wed, May 25, 2022 at 5:30 AM Paul Kudla (SCOM.CA Internet Services Inc.)
 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 
> 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 p...@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, 

Re: Force TCP socket disconnect on imap login failure?

[Paul Kudla (SCOM.CA Internet Services Inc.)]

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

Re: Force TCP socket disconnect on imap login failure?

[Stuart Henderson]

On 2022-05-24, Hippo Man  wrote:
> * 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.

"numerous" and "rapidly" sounds wrong; between auth_failure_delay (in a single
connection) and the penalty mechanism for all connections from an IP address
(https://doc.dovecot.org/configuration_manual/authentication/auth_penalty/)
it should soon get beyond "rapidly".

Is there something in your config that disables this? Or is your idea of
"rapidly" just different to mine?

Re: Force TCP socket disconnect on imap login failure?

[John Hardin]

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 KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@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)

Re: Force TCP socket disconnect on imap login failure?

[Hippo Man]

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.

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


On Tue, May 24, 2022 at 5:13 AM Paul Kudla (SCOM.CA Internet Services Inc.)
 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 
> 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 p...@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.
> >>
> >>
> >>
> >> --
> >>   hippo...@gmail.com
> >>   Take a hippopotamus to lunch today.
> >>
> >>
> >>
> >>
> >> On Mon, May 23, 2022 at 4:54 PM Hippo Man  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 

Re: Force TCP socket disconnect on imap login failure?

[didar]

On Mon, May 23, 2022 at 03:11:46PM -0400, 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.
> -- 
>  hippo...@gmail.com
>  Take a hippopotamus to lunch today.

I read the whole thread and other's suggestion.

On Linux using ipsets with iptables; sets/maps with nftables is more efficient.

Paul Kudla's response is pretty much on the mark and his solution is quiet
thorough.

Your requirement of closing the socket on bad auth attempt is always best done
from the application in question rather than using other tools like - it works, 
but
it is a workaround. Your suggestion of making changes to dovecot itself will
only create extra work for you, you will have to patch upstream every time there
is a new release. Out of tree customizations should really be maintained only
under extreme situations.

Instead you can look at nginx imap proxy which will allow you to close the
connection on bad auth before it even reaches over to dovecot. However, you will
have to write some code to make it work. I have not tried doing it myself, but,
I can think of using perl mojolicious + redis which re-uses Paul's ideas to do
the job.

And finally my personal opinion about blocking, I do not believe in them
anymore. A decade ago I used to use iptables "recent" module to restrict SSH
access. Now, brute force login attempts are so ubiquitous and distributed
against all availables services that it just isn't worth indulging in the
cat-and-mouse game. Instead I go with the belief that users will get
cracked/hacked eventually, so what can I do to minimize the pain when that
happens? How fast can I recover their emails from backup? How can I segregate
the compromised account from affecting other systems? These are the questions
that I ponder upon, but that's just me.

I hope this helps some how.

Take care,
Didar

-- 
Demand the establishment of the government in its rightful home at Disneyland.

Re: Force TCP socket disconnect on imap login failure?

[Paul Kudla (SCOM.CA Internet Services Inc.)]

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



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




On Mon, May 23, 2022 at 4:54 PM Hippo Man  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.
 
 
 
 --

  hippo...@gmail.com
  Take a hippopotamus to lunch today.
 
 
 
 
 On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins

  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.
 >
 >
 > --
 >  hippo...@gmail.com
 >  Take a hippopotamus to lunch today.
 >
 
 

Re: Force TCP socket disconnect on imap login failure?

[Paul Kudla (SCOM.CA Internet Services Inc.)]

"-j REJECT --reject-with
tcp-reset" instead of DROP

are valid ideas

consider that if you update (in the background) and block the connection 
then dovecot (or any other process) should just block the traffic and 
timeout to close the connection anyways


fyi ??



Happy Tuesday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
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 p...@scom.ca

On 5/24/2022 12:18 AM, Péter Márton wrote:


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

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


On Mon, May 23, 2022 at 4:54 PM Hippo Man  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.

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


On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins  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.

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

Re: Force TCP socket disconnect on imap login failure?

[Jochen Bern]

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Force TCP socket disconnect on imap login failure?

[Paul Kudla (SCOM.CA Internet Services Inc.)]

for what its worth this is a python script that i use for the database 
driven iptables updater for my asterisk server


again same ideas but it gets the job done.

It's a lot of work to get stuff like this going but may help point 
someone in the right directions balance wise pending on there system / 
network setup.


The django script is intelligent as it looks at the ip addresses already 
blacklisted and updates the list adding or subtracting ip address 
changes within the database


can answer in more detail, mainly for reference.

example iptables output :

# /sbin/iptables -L INPUT -n | more
Chain INPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  92.204.135.144   0.0.0.0/0
ACCEPT all  --  104.205.0.0/16   0.0.0.0/0
ACCEPT all  --  174.95.0.0/160.0.0.0/0
ACCEPT all  --  174.94.0.0/160.0.0.0/0
ACCEPT all  --  174.93.0.0/160.0.0.0/0
ACCEPT all  --  174.92.0.0/160.0.0.0/0
ACCEPT all  --  174.91.0.0/160.0.0.0/0
ACCEPT all  --  174.90.0.0/160.0.0.0/0
ACCEPT all  --  174.89.0.0/160.0.0.0/0
ACCEPT all  --  174.88.0.0/160.0.0.0/0
ACCEPT all  --  209.171.88.0/24  0.0.0.0/0
ACCEPT all  --  72.12.174.2300.0.0.0/0
ACCEPT all  --  72.136.0.0/160.0.0.0/0
ACCEPT all  --  10.0.0.0/8   0.0.0.0/0
ACCEPT all  --  67.171.153.140   0.0.0.0/0
ACCEPT all  --  99.235.148.110   0.0.0.0/0
ACCEPT all  --  67.69.69.0/240.0.0.0/0
ACCEPT all  --  204.237.0.0/16   0.0.0.0/0
ACCEPT all  --  65.39.148.0/25   0.0.0.0/0
ACCEPT all  --  72.143.119.178   0.0.0.0/0
ACCEPT all  --  99.244.67.2440.0.0.0/0
ACCEPT all  --  69.60.225.80 0.0.0.0/0
ACCEPT all  --  198.200.68.0/24  0.0.0.0/0
ACCEPT all  --  185.58.85.0/24   0.0.0.0/0
ACCEPT all  --  172.97.0.0/160.0.0.0/0
ACCEPT all  --  184.151.0.0/16   0.0.0.0/0
DROP   tcp  --  0.0.0.0/00.0.0.0/0   tcp dpt:5038
DROP   tcp  --  0.0.0.0/00.0.0.0/0   tcp dpt:80
DROP   all  --  213.175.208.0/24 0.0.0.0/0
DROP   all  --  50.24.0.0/24 0.0.0.0/0
DROP   all  --  20.98.78.0/240.0.0.0/0
DROP   all  --  116.106.197.0/24 0.0.0.0/0
DROP   all  --  45.95.169.0/24   0.0.0.0/0
DROP   all  --  193.253.211.0/24 0.0.0.0/0
DROP   all  --  65.49.20.0/240.0.0.0/0
DROP   all  --  107.189.1.0/24   0.0.0.0/0
DROP   all  --  107.189.3.0/24   0.0.0.0/0
DROP   all  --  209.141.51.0/24  0.0.0.0/0
DROP   all  --  75.119.155.0/24  0.0.0.0/0
DROP   all  --  45.133.1.0/240.0.0.0/0
DROP   all  --  185.166.84.0/24  0.0.0.0/0
DROP   all  --  116.105.218.0/24 0.0.0.0/0
DROP   all  --  216.37.36.0/24   0.0.0.0/0
DROP   all  --  216.245.220.0/24 0.0.0.0/0
DROP   all  --  205.185.121.0/24 0.0.0.0/0


based on django model(s)

#IP Blacklistings   
class IpBlock(models.Model):
id  = models.AutoField(primary_key=True)
	ipaddress 		= models.CharField(verbose_name='IP Address', 
max_length=40, null=True, blank=False,unique=False)
	action  	= models.CharField(max_length=15, 
choices=ip_action_choices, verbose_name='Firewall', default = 'D', 
null=True, blank=True)
	syslog			= models.TextField(verbose_name='Last Syslog', 
max_length=1000, null=True, blank=True, default = '')
	whois			= models.TextField(verbose_name='Whois', max_length=1500, 
null=True, blank=True, default = '')

asterisk= models.BooleanField('Asterisk', default = 
False )
	last_datetime	= models.DateTimeField(verbose_name='Date Last Updated 
Server', null=True, blank=True, default = timezone.now)
	accountid	= models.ForeignKey(Contacts,verbose_name='Reference', 
default = '2594',null=False, blank=True,related_name = 'blacklist_soldto')
	syslog2			= models.TextField(verbose_name='Last Syslog', 
max_length=1000, null=True, blank=True, default = 'Denied due to 
Unauthorized Use')
	last_program	= models.CharField(verbose_name='Last Program', 
max_length=20, null=True, blank=True, default = '')




class Meta:
ordering = ['ipaddress',]
db_table = u'blocked_ip'
verbose_name = u"Currently Blocked IP's"
verbose_name_plural = u"Currently Blocked Ip's"

class IpCount(models.Model):
	ipaddress = models.GenericIPAddressField(verbose_name='IP Address', 
max_length=17,blank=False,primary_key=True, unique=True)
	counthour   			= models.IntegerField(verbose_name='Current IP Count 
This Hour', null=True, blank=True, default='0')
	counttotal  			= models.IntegerField(verbose_name='Total IP Count This 
Month', null=True, blank=True, default='0')
	asterisk_counthour   	= models.IntegerField(verbose_name='Asterisk 

Re: Force TCP socket disconnect on imap login failure?

[Jan Hugo Prins]

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.


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


On Mon, May 23, 2022 at 4:54 PM Hippo Man  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.

-- 
hippo...@gmail.com

 Take a hippopotamus to lunch today.


On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins 
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.

-- 
hippo...@gmail.com

 Take a hippopotamus to lunch today.

Re: Force TCP socket disconnect on imap login failure?

[Thomas Zajic]

* Hippo Man, 23.05.22 22:54


[...] 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 your version of 'ss' is recent anough, you can use 'ss -k' to
instantly kill an open connection. Other tools you could try are
'killcx' and 'tcpkill' (part of the 'dsniff' toolkit):

http://killcx.sourceforge.net/
https://www.monkey.org/~dugsong/dsniff/

HTH
Thomas

Re: Force TCP socket disconnect on imap login failure?

[Péter Márton]

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  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.
>
> --
>  hippo...@gmail.com
>  Take a hippopotamus to lunch today.
>
>
> On Mon, May 23, 2022 at 4:54 PM Hippo Man  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.
>>
>> --
>>  hippo...@gmail.com
>>  Take a hippopotamus to lunch today.
>>
>>
>> On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins  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.
>>>
>>> --
>>>  hippo...@gmail.com
>>>  Take a hippopotamus to lunch today.
>>>
>>>

Re: Force TCP socket disconnect on imap login failure?

[John Tulp]

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.
> 
> 
> 
> -- 
>  hippo...@gmail.com
>  Take a hippopotamus to lunch today.
> 
> 
> 
> 
> On Mon, May 23, 2022 at 4:54 PM Hippo Man  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.
> 
> 
> 
> -- 
>  hippo...@gmail.com
>  Take a hippopotamus to lunch today.
> 
> 
> 
> 
> On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins
>  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.
> > 
> > 
> > -- 
> >  hippo...@gmail.com
> >  Take a hippopotamus to lunch today.
> > 
> 
> 

Re: Force TCP socket disconnect on imap login failure?

[Hippo Man]

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.

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


On Mon, May 23, 2022 at 4:54 PM Hippo Man  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.
>
> --
>  hippo...@gmail.com
>  Take a hippopotamus to lunch today.
>
>
> On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins  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.
>> --
>>  hippo...@gmail.com
>>  Take a hippopotamus to lunch today.
>>
>>
>>

Re: Force TCP socket disconnect on imap login failure?

[Paul Kudla (SCOM.CA Internet Services Inc.)]

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(t...@dereilanatureinn.ca,220.194.140.110,
   <5H72HLPfTp/cwoxu>): unknown user

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


   in 3 secs): user=, 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 
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 p...@scom.ca

On 5/23/2022 3:26 PM, dovecot-boun...@dovecot.org wrote:


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

Re: Force TCP socket disconnect on imap login failure?

[Hippo Man]

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.

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


On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins  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.
> --
>  hippo...@gmail.com
>  Take a hippopotamus to lunch today.
>
>
>

Re: Force TCP socket disconnect on imap login failure?

[Jan Hugo Prins]

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.

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