Re: Mail account brute force / harassment

[Odhiambo Washington via dovecot]

On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot 
wrote:

>
>
> Say for instance you have some one trying to constantly access an
> account
>
>
> Has any of you made something creative like this:
>
> * configure that account to allow to login with any password
> * link that account to something like /dev/zero that generates infinite
> amount of messages
>   (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
>
> I think it would be interesting to be able to do such a thing.
>
>
Instead of being evil, just use fail2ban to address this problem :-)

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[Gerald Galster via dovecot]

> Am 11.04.2019 um 12:28 schrieb Odhiambo Washington via dovecot 
> :
> 
> 
> 
> On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot  > wrote:
> 
> 
> Say for instance you have some one trying to constantly access an 
> account
> 
> 
> Has any of you made something creative like this:
> 
> * configure that account to allow to login with any password
> * link that account to something like /dev/zero that generates infinite 
> amount of messages
>   (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
> 
> I think it would be interesting to be able to do such a thing.
> 
> 
> Instead of being evil, just use fail2ban to address this problem :-)  


fail2ban is a good solution. I don't see any benefits in granting access to 
pop/imap as well.
On the other hand if you to this with smtp, your service is probably abused for 
sending spam
which you could use to train your spam filters :-)

Best regards
Gerald

RE: Mail account brute force / harassment

[Marc Roos via dovecot]

Please do not assume anything other than what is written, it is a 
hypothetical situation

 
A. With the fail2ban solution
   - you 'solve' that the current ip is not able to access you
   - it will continue bothering other servers and admins
   - you get the next abuse host to give a try.

B. With 500GB dump
 - the owner of the attacking server (probably hacked) will notice it 
will be forced to take action.


If abuse clouds are smart (most are) they would notice that attacking my 
servers, will result in the loss of abuse nodes, hence they will not 
bother me anymore. 

If every one would apply strategy B, the abuse problem would get less. 
Don't you agree??






-Original Message-
From: Odhiambo Washington  
Sent: donderdag 11 april 2019 12:28
To: Marc Roos
Cc: dovecot
Subject: Re: Mail account brute force / harassment



On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot 
 wrote:




Say for instance you have some one trying to constantly access an 
account


Has any of you made something creative like this:

* configure that account to allow to login with any password
* link that account to something like /dev/zero that generates 
infinite 
amount of messages
  (maybe send an archive of virusses?)
* transferring TB's of data to this harassing client.

I think it would be interesting to be able to do such a thing.




Instead of being evil, just use fail2ban to address this problem :-)  

-- 

Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[Odhiambo Washington via dovecot]

Marc,

There is a strategy loosely referred to as "choose your battles well" :-)
Let the others bother with their own problems.
If you can, hack the server and dump the 500GB - you'll be using resources
transferring the 500GB as the
other server receives it. Two servers wasting resources because you think
you are punishing an offender!


On Thu, 11 Apr 2019 at 13:43, Marc Roos  wrote:

> Please do not assume anything other than what is written, it is a
> hypothetical situation
>
>
> A. With the fail2ban solution
>- you 'solve' that the current ip is not able to access you
>- it will continue bothering other servers and admins
>- you get the next abuse host to give a try.
>
> B. With 500GB dump
>  - the owner of the attacking server (probably hacked) will notice it
> will be forced to take action.
>
>
> If abuse clouds are smart (most are) they would notice that attacking my
> servers, will result in the loss of abuse nodes, hence they will not
> bother me anymore.
>
> If every one would apply strategy B, the abuse problem would get less.
> Don't you agree??
>
>
>
>
>
>
> -Original Message-----
> From: Odhiambo Washington
> Sent: donderdag 11 april 2019 12:28
> To: Marc Roos
> Cc: dovecot
> Subject: Re: Mail account brute force / harassment
>
>
>
> On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot
>  wrote:
>
>
>
>
> Say for instance you have some one trying to constantly access an
> account
>
>
> Has any of you made something creative like this:
>
> * configure that account to allow to login with any password
> * link that account to something like /dev/zero that generates
> infinite
> amount of messages
>   (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
>
> I think it would be interesting to be able to do such a thing.
>
>
>
>
> Instead of being evil, just use fail2ban to address this problem :-)
>
> --
>
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
>
>
>

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[Gerald Galster via dovecot]

> Am 11.04.2019 um 12:43 schrieb Marc Roos via dovecot :
> 
> Please do not assume anything other than what is written, it is a 
> hypothetical situation
> 
> 
> A. With the fail2ban solution
>   - you 'solve' that the current ip is not able to access you
>   - it will continue bothering other servers and admins
>   - you get the next abuse host to give a try.
> 
> B. With 500GB dump
> - the owner of the attacking server (probably hacked) will notice it 
> will be forced to take action.
> 
> 
> If abuse clouds are smart (most are) they would notice that attacking my 
> servers, will result in the loss of abuse nodes, hence they will not 
> bother me anymore. 
> 
> If every one would apply strategy B, the abuse problem would get less. 
> Don't you agree??

I disagree. If 100 servers "hack" your imap account and fetch 500GB then
most likely your server is unreachable. If this is done over many servers
then your rack switches become the bottleneck and uninvolved servers are
affected too.

Your solution may work if traffic is expensive and limited but we're heading
in the other direction: you can rent a server for 50 bucks with 1gbit bandwidth
and unmetered traffic e.g. at hetzner.de <http://hetzner.de/>

Maybe you want to look into a solution like weakforced:

https://github.com/PowerDNS/weakforced <https://github.com/PowerDNS/weakforced>
Wforce is a project by Dovecot, PowerDNS and Open-Xchange

Best regards
Gerald



> 
> 
> 
> 
> 
> 
> -Original Message-----
> From: Odhiambo Washington  
> Sent: donderdag 11 april 2019 12:28
> To: Marc Roos
> Cc: dovecot
> Subject: Re: Mail account brute force / harassment
> 
> 
> 
> On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot 
>  wrote:
> 
> 
> 
> 
>   Say for instance you have some one trying to constantly access an 
>   account
>   
>   
>   Has any of you made something creative like this:
>   
>   * configure that account to allow to login with any password
>   * link that account to something like /dev/zero that generates 
> infinite 
>   amount of messages
> (maybe send an archive of virusses?)
>   * transferring TB's of data to this harassing client.
>   
>   I think it would be interesting to be able to do such a thing.
>   
>   
> 
> 
> Instead of being evil, just use fail2ban to address this problem :-)  
> 
> -- 
> 
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
> 
> 

RE: Mail account brute force / harassment

[Marc Roos via dovecot]

 
If I am not mistaken dovecot has already limited concurrent 
accounts/ips. Furthermore I thought it would be obvious of course to 
utilize for this only unused resources and don't jeopardize a production 
environment. 

Furthermore it is logical to assume that one abuse host is not dedicated 
to me. So it probably has 50? other connections for every one of mine. 
So if it would be common practice to dump abuse to /dev/zero, the abuse 
host would be the first to 'die'. 


-Original Message-
From: Gerald Galster via dovecot [mailto:dovecot@dovecot.org] 
Sent: donderdag 11 april 2019 12:57
To: dovecot@dovecot.org
Subject: Re: Mail account brute force / harassment



Am 11.04.2019 um 12:43 schrieb Marc Roos via dovecot 
:

Please do not assume anything other than what is written, it is a 
hypothetical situation


A. With the fail2ban solution
  - you 'solve' that the current ip is not able to access you
  - it will continue bothering other servers and admins
  - you get the next abuse host to give a try.

B. With 500GB dump
- the owner of the attacking server (probably hacked) will notice 
it 
will be forced to take action.


If abuse clouds are smart (most are) they would notice that 
attacking my 
servers, will result in the loss of abuse nodes, hence they will 
not 
bother me anymore. 

If every one would apply strategy B, the abuse problem would get 
less. 
Don't you agree??



I disagree. If 100 servers "hack" your imap account and fetch 500GB then 
most likely your server is unreachable. If this is done over many 
servers then your rack switches become the bottleneck and uninvolved 
servers are affected too.

Your solution may work if traffic is expensive and limited but we're 
heading in the other direction: you can rent a server for 50 bucks with 
1gbit bandwidth and unmetered traffic e.g. at hetzner.de

Maybe you want to look into a solution like weakforced:

https://github.com/PowerDNS/weakforced
Wforce is a project by Dovecot, PowerDNS and Open-Xchange

Best regards
Gerald










-Original Message-
From: Odhiambo Washington  
Sent: donderdag 11 april 2019 12:28
To: Marc Roos
    Cc: dovecot
    Subject: Re: Mail account brute force / harassment



On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot 
 wrote:




Say for instance you have some one trying to constantly access an 
account


Has any of you made something creative like this:

* configure that account to allow to login with any password
* link that account to something like /dev/zero that generates 
infinite 
amount of messages
 (maybe send an archive of virusses?)
* transferring TB's of data to this harassing client.

I think it would be interesting to be able to do such a thing.




Instead of being evil, just use fail2ban to address this problem 
:-)  

-- 

Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[James via dovecot]

On 11/04/2019 11:43, Marc Roos via dovecot wrote:


A. With the fail2ban solution
   - you 'solve' that the current ip is not able to access you


It is only a solution if there are subsequent attempts from the same 
address.  I currently have several thousand addresses blocked due to 
dovecot login failures.  My firewall is set to log these so I can see 
that few repeat, those that do repeat have intervals of >1 week. 
Blocking these has minimal effect (other than to clog fail12ban and the 
firewall).



   - it will continue bothering other servers and admins


Which is why a dnsbl for dovecot is a good idea.  I do not believe the 
agents behind these login attempts are only targeting me, hence the 
addresses should be shared via a dnsbl.

RE: Mail account brute force / harassment

[Marc Roos via dovecot]

Yes indeed, we have already own dnsbl's for smtp and ssh/ftp access. How 
do you have one setup for dovecot connections?


-Original Message-
From: James via dovecot [mailto:dovecot@dovecot.org] 
Sent: donderdag 11 april 2019 13:25
To: dovecot@dovecot.org
Subject: Re: Mail account brute force / harassment

On 11/04/2019 11:43, Marc Roos via dovecot wrote:

> A. With the fail2ban solution
>- you 'solve' that the current ip is not able to access you

It is only a solution if there are subsequent attempts from the same 
address.  I currently have several thousand addresses blocked due to 
dovecot login failures.  My firewall is set to log these so I can see 
that few repeat, those that do repeat have intervals of >1 week. 
Blocking these has minimal effect (other than to clog fail12ban and the 
firewall).

>- it will continue bothering other servers and admins

Which is why a dnsbl for dovecot is a good idea.  I do not believe the 
agents behind these login attempts are only targeting me, hence the 
addresses should be shared via a dnsbl.

RE: Mail account brute force / harassment

[Marc Roos via dovecot]

 
How long have we been using the current strategy? Do we have less or 
more abuse clouds operating? 

"Let the others bother with their own problems." is a bit narrow minded 
view. If every one on this mailing list would have this attitude, there 
would be no single answer to your question.


-Original Message-
From: Odhiambo Washington [mailto:odhia...@gmail.com] 
Sent: donderdag 11 april 2019 12:54
To: Marc Roos
Cc: dovecot
Subject: Re: Mail account brute force / harassment

Marc,

There is a strategy loosely referred to as "choose your battles well" 
:-) 
If you can, hack the server and dump the 500GB - you'll be using 
resources transferring the 500GB as the other server receives it. Two 
servers wasting resources because you think you are punishing an 
offender!


On Thu, 11 Apr 2019 at 13:43,  wrote:


Please do not assume anything other than what is written, it is a 
hypothetical situation


A. With the fail2ban solution
   - you 'solve' that the current ip is not able to access you
   - it will continue bothering other servers and admins
   - you get the next abuse host to give a try.

B. With 500GB dump
 - the owner of the attacking server (probably hacked) will notice 
it 
will be forced to take action.


If abuse clouds are smart (most are) they would notice that 
attacking my 
servers, will result in the loss of abuse nodes, hence they will 
not 
bother me anymore. 

If every one would apply strategy B, the abuse problem would get 
less. 
Don't you agree??






-Original Message-
From: Odhiambo Washington  
Sent: donderdag 11 april 2019 12:28
To: Marc Roos
    Cc: dovecot
    Subject: Re: Mail account brute force / harassment



On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot 
 wrote:




Say for instance you have some one trying to constantly 
access an 
account


Has any of you made something creative like this:

* configure that account to allow to login with any 
password
* link that account to something like /dev/zero that 
generates 
infinite 
amount of messages
  (maybe send an archive of virusses?)
* transferring TB's of data to this harassing client.

I think it would be interesting to be able to do such a 
thing.




Instead of being evil, just use fail2ban to address this problem 
:-)  

-- 

Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)






-- 

Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[Odhiambo Washington via dovecot]

All your approaches are not well thought out.
The best solutions are always the simplest ones.
KISS principle dictates so.

On Thu, 11 Apr 2019 at 15:01, Marc Roos  wrote:

>
> How long have we been using the current strategy? Do we have less or
> more abuse clouds operating?
>
> "Let the others bother with their own problems." is a bit narrow minded
> view. If every one on this mailing list would have this attitude, there
> would be no single answer to your question.
>
>
> -Original Message-
> From: Odhiambo Washington [mailto:odhia...@gmail.com]
> Sent: donderdag 11 april 2019 12:54
> To: Marc Roos
> Cc: dovecot
> Subject: Re: Mail account brute force / harassment
>
> Marc,
>
> There is a strategy loosely referred to as "choose your battles well"
> :-)
> If you can, hack the server and dump the 500GB - you'll be using
> resources transferring the 500GB as the other server receives it. Two
> servers wasting resources because you think you are punishing an
> offender!
>
>
> On Thu, 11 Apr 2019 at 13:43,  wrote:
>
>
> Please do not assume anything other than what is written, it is a
> hypothetical situation
>
>
> A. With the fail2ban solution
>- you 'solve' that the current ip is not able to access you
>- it will continue bothering other servers and admins
>- you get the next abuse host to give a try.
>
> B. With 500GB dump
>  - the owner of the attacking server (probably hacked) will notice
> it
> will be forced to take action.
>
>
> If abuse clouds are smart (most are) they would notice that
> attacking my
> servers, will result in the loss of abuse nodes, hence they will
> not
> bother me anymore.
>
> If every one would apply strategy B, the abuse problem would get
> less.
> Don't you agree??
>
>
>
>
>
>
> -Original Message-
> From: Odhiambo Washington
> Sent: donderdag 11 april 2019 12:28
> To: Marc Roos
> Cc: dovecot
> Subject: Re: Mail account brute force / harassment
>
>
>
> On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot
>  wrote:
>
>
>
>
> Say for instance you have some one trying to constantly
> access an
> account
>
>
> Has any of you made something creative like this:
>
> * configure that account to allow to login with any
> password
> * link that account to something like /dev/zero that
> generates
> infinite
> amount of messages
>   (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
>
> I think it would be interesting to be able to do such a
> thing.
>
>
>
>
> Instead of being evil, just use fail2ban to address this problem
> :-)
>
> --
>
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
>
>
>
>
>
>
> --
>
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
>
>
>

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)

Re: Mail account brute force / harassment

[James via dovecot]

On 11/04/2019 12:49, Marc Roos via dovecot wrote:

Yes indeed, we have already own dnsbl's for smtp and ssh/ftp access. How
do you have one setup for dovecot connections?


Two answers:

1. I wrote my own very simple implementation but it does not share other 
people's data.  Sharing the key to viability so it is/was a pointless 
exercise.  Without sharing a hacker gets at least one free shot per 
server per address.  With sharing it is closer to one per address and 
less with honeypots.



2. I said "dnsbl for dovecot is a good idea", an idea.  When this was 
raised previously we were told it was not needed and it can all be done 
with tcp wrappers, fail2ban and allow_nets.


https://dovecot.org/list/dovecot/2013-July/091236.html
https://dovecot.org/list/dovecot/2014-June/096662.html

Re: Mail account brute force / harassment

[Anton Dollmaier via dovecot]

On 11.04.2019 13:25, James via dovecot wrote:

On 11/04/2019 11:43, Marc Roos via dovecot wrote:


A. With the fail2ban solution
   - you 'solve' that the current ip is not able to access you


It is only a solution if there are subsequent attempts from the same 
address.  I currently have several thousand addresses blocked due to 
dovecot login failures.  My firewall is set to log these so I can see 
that few repeat, those that do repeat have intervals of >1 week. 
Blocking these has minimal effect (other than to clog fail12ban and the 
firewall).



   - it will continue bothering other servers and admins


Which is why a dnsbl for dovecot is a good idea.  I do not believe the 
agents behind these login attempts are only targeting me, hence the 
addresses should be shared via a dnsbl.


Probably there's an existing solution for both problems (subsequent 
attempts and dnsbl):



https://github.com/PowerDNS/weakforced


It was also discussed recently on this list:


https://www.dovecot.org/list/dovecot/2019-March/114921.html



Has already been on my personal todo list for some time, so I have no 
experience how (good) it actually works.



Best,
Anton

Re: Mail account brute force / harassment

[@lbutlr via dovecot]

On 11 Apr 2019, at 04:43, Marc Roos via dovecot  wrote:
> B. With 500GB dump
> - the owner of the attacking server (probably hacked) will notice it 
> will be forced to take action.

Unlikely. What is very likely is that your ISP shuts you don for network abuse.

> If abuse clouds are smart (most are) they would notice that attacking my 
> servers, will result in the loss of abuse nodes, hence they will not 
> bother me anymore. 

Not at all the case.

> If every one would apply strategy B, the abuse problem would get less. 

No. The abuse problem wold be far worse.


-- 
I thank my lucky stars I'm not superstitious.

RE: Mail account brute force / harassment

[Marc Roos via dovecot]

 


 >
 >> B. With 500GB dump
 >> - the owner of the attacking server (probably hacked) will notice it 

 >> will be forced to take action.
 >
 >Unlikely. What is very likely is that your ISP shuts you don for 
network abuse.

If you not block the request, but allow it, and redirect to a /dev/zero 
device that
generates 500GB of messages. How can I ever be accused of network abuse.

Since your logics is not correct on this, how can I assume anything you 
write 
is correct?


 >> If abuse clouds are smart (most are) they would notice that 
attacking 
 >> my servers, will result in the loss of abuse nodes, hence they will 
 >> not bother me anymore.
 >
 >Not at all the case.
 >
 >> If every one would apply strategy B, the abuse problem would get 
less. 
 >
 >No. The abuse problem wold be far worse.
 >



-Original Message-
From: @lbutlr via dovecot [mailto:dovecot@dovecot.org] 
Sent: donderdag 11 april 2019 19:11
To: Peter via dovecot
Subject: Re: Mail account brute force / harassment

On 11 Apr 2019, at 04:43, Marc Roos via dovecot  
wrote:
> B. With 500GB dump
> - the owner of the attacking server (probably hacked) will notice it 
> will be forced to take action.

Unlikely. What is very likely is that your ISP shuts you don for network 
abuse.

> If abuse clouds are smart (most are) they would notice that attacking 
> my servers, will result in the loss of abuse nodes, hence they will 
> not bother me anymore.

Not at all the case.

> If every one would apply strategy B, the abuse problem would get less. 


No. The abuse problem wold be far worse.


--
I thank my lucky stars I'm not superstitious.

Re: Mail account brute force / harassment

[Joseph Tam via dovecot]

On Thu, 11 Apr 2019, Marc Roos wrote:


Say for instance you have some one trying to constantly access an
account

Has any of you made something creative like this:

* configure that account to allow to login with any password
* link that account to something like /dev/zero that generates infinite
amount of messages
 (maybe send an archive of virusses?)
* transferring TB's of data to this harassing client.

I think it would be interesting to be able to do such a thing.


As would finding the person responsible and outing them in public --
both are fantasies that do not scale to practice.

It's a costly countermeasure, and do you really want to engage in
an internet fistfight where your opponent has anonymity, access to
compromised servers or botnet, and no scruples against launching a DDoS
attacks against you?

Block them and move on.

Joseph Tam 

Re: Mail account brute force / harassment

[James via dovecot]

On 11/04/2019 14:33, Anton Dollmaier via dovecot wrote:


Which is why a dnsbl for dovecot is a good idea.  I do not believe the
agents behind these login attempts are only targeting me, hence the
addresses should be shared via a dnsbl.


Probably there's an existing solution for both problems (subsequent
attempts and dnsbl):


https://github.com/PowerDNS/weakforced


"The goal of 'wforce' is to detect brute forcing of passwords across 
many servers"


The problem is not detecting but blocking.  Dovecot has no mechanism for 
using the data; Dovecot needs DNSBL capability.


I tested a small sample of my IMAP hackers using the lists I use for 
SMTP blocking [1] and enough are in these list to make them worth using. 
 Extra detection is not needed as many of these addresses are already 
known - maybe even by using weakforced.




James.


1. exim dnsblist:
https://www.exim.org/howto/rbl.html
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html

Re: Mail account brute force / harassment

[Aki Tuomi via dovecot]

On 12.4.2019 10.21, James via dovecot wrote:
> On 11/04/2019 14:33, Anton Dollmaier via dovecot wrote:
>
>>> Which is why a dnsbl for dovecot is a good idea.  I do not believe the
>>> agents behind these login attempts are only targeting me, hence the
>>> addresses should be shared via a dnsbl.
>>
>> Probably there's an existing solution for both problems (subsequent
>> attempts and dnsbl):
>>
>>> https://github.com/PowerDNS/weakforced
>
> "The goal of 'wforce' is to detect brute forcing of passwords across
> many servers"
>
> The problem is not detecting but blocking.  Dovecot has no mechanism
> for using the data; Dovecot needs DNSBL capability.
>
> I tested a small sample of my IMAP hackers using the lists I use for
> SMTP blocking [1] and enough are in these list to make them worth
> using.  Extra detection is not needed as many of these addresses are
> already known - maybe even by using weakforced.
>
>
>
> James.
>
>
> 1. exim dnsblist:
> https://www.exim.org/howto/rbl.html
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html
>
>

Weakforced uses Lua so you can easily integrate DNSBL support into it.
We will not add DNSBL support to dovecot at this time.


Aki

Re: Mail account brute force / harassment

[James via dovecot]

On 12/04/2019 08:24, Aki Tuomi via dovecot wrote:


Weakforced uses Lua so you can easily integrate DNSBL support into it.


How does this help Dovecot block?
A link to some documentation or example perhaps?



We will not add DNSBL support to dovecot at this time.


Is there a reason why you will not support this RFE?

Re: Mail account brute force / harassment

[Aki Tuomi via dovecot]

On 12.4.2019 10.34, James via dovecot wrote:
> On 12/04/2019 08:24, Aki Tuomi via dovecot wrote:
>
>> Weakforced uses Lua so you can easily integrate DNSBL support into it.
>
> How does this help Dovecot block?
> A link to some documentation or example perhaps?
>
>
https://wiki.dovecot.org/Authentication/Policy

You can configure weakforced to return status -1 when DNSBL matches,
which causes the user authentication to fail before any other processing
happens.


>> We will not add DNSBL support to dovecot at this time.
>
> Is there a reason why you will not support this RFE?
>
It's not a priority.

Aki

Re: Mail account brute force / harassment

[James via dovecot]

On 12/04/2019 08:42, Aki Tuomi via dovecot wrote:

On 12.4.2019 10.34, James via dovecot wrote:

On 12/04/2019 08:24, Aki Tuomi via dovecot wrote:


Weakforced uses Lua so you can easily integrate DNSBL support into it.

How does this help Dovecot block?
A link to some documentation or example perhaps?



https://wiki.dovecot.org/Authentication/Policy

You can configure weakforced to return status -1 when DNSBL matches,
which causes the user authentication to fail before any other processing
happens.


Thank you.  I will study this - although I dispute your "easily"!



James.

Re: Mail account brute force / harassment

[mj via dovecot]

Hi,

What we do is: use https://github.com/trick77/ipset-blacklist to block 
IPs (from various existing blacklists) at the iptables level using an ipset.


That way, the known bad IPs never even talk to dovecot, but are dropped 
immediately. We have the feeling it helps a lot.


MJ

On 4/12/19 10:27 AM, James via dovecot wrote:

On 12/04/2019 08:42, Aki Tuomi via dovecot wrote:

On 12.4.2019 10.34, James via dovecot wrote:

On 12/04/2019 08:24, Aki Tuomi via dovecot wrote:


Weakforced uses Lua so you can easily integrate DNSBL support into it.

How does this help Dovecot block?
A link to some documentation or example perhaps?



https://wiki.dovecot.org/Authentication/Policy

You can configure weakforced to return status -1 when DNSBL matches,
which causes the user authentication to fail before any other processing
happens.


Thank you.  I will study this - although I dispute your "easily"!



James.

Re: Mail account brute force / harassment

[Jean-Daniel Dupas via dovecot]

> Le 11 avr. 2019 à 12:23, Marc Roos via dovecot  a écrit :
> 
> 
> 
> Say for instance you have some one trying to constantly access an 
> account
> 
> 
> Has any of you made something creative like this:
> 
> * configure that account to allow to login with any password
> * link that account to something like /dev/zero that generates infinite 
> amount of messages
>  (maybe send an archive of virusses?)
> * transferring TB's of data to this harassing client.
> 
> I think it would be interesting to be able to do such a thing.

As long as you have infinite bandwidth, that may be fun, but it is not the case 
for most people operating a mail server I think.

For theses clients, I simply have fail2ban and DROP packages of blocked IP (I 
prefer to DROP because I don't want to waste resources responding that the 
connection is refused).

Re: Mail account brute force / harassment

[Robert Kudyba via dovecot]

>
> Probably there's an existing solution for both problems (subsequent
> attempts and dnsbl):
>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PowerDNS_weakforced&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=stCCTTs65S9mjT4ITx-MfXyqnP1M0FoOlvIsEA-iwdQ&e=
>
> It was also discussed recently on this list:
>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dovecot.org_list_dovecot_2019-2DMarch_114921.html&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=F_MZgSGFbhEPpQAsxd5uZPK_fbOBWgG4SIvzIXCWC1U&e=
>
>
> Has already been on my personal todo list for some time, so I have no
> experience how (good) it actually works.
>

That was a thread I started. I got wforce to work. However the "reporting
IP" in the logs always shows as 127.0.0.1, so I risk banning myself. Here's
the log entry:
Apr 12 10:06:12 auth: Debug: policy(ouruser,127.0.0.1,):
Policy server request JSON:
{"device_id":"","login":"ouruser","protocol":"imap","pwhash":"2a","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}

I've tried setting auth_policy_server_url to examples such as:

   - auth_policy_server_url = http://localhost:8084/
   - auth_policy_server_url = http://0.0.0.0:8084/
   - auth_policy_server_url = https://ourdomain.edu:8084/

in the custom config file for wforce and the rip (reporting IP, e.g., Apr
12 10:06:10 auth: Debug: client in: AUTH1   PLAIN   service=imap
secured session=OWoLzlWGDrh/AAABlip=127.0.0.1   rip=127.0.0.1
 lport=143   rport=47118 resp=) is either 127.0.0.1 or
ourdomain.edu.

Re: Mail account brute force / harassment

[Aki Tuomi via dovecot]

> On 12 April 2019 18:11 Robert Kudyba via dovecot  wrote:
> 
> 
> > Probably there's an existing solution for both problems (subsequent 
> >  attempts and dnsbl):
> >  
> >  > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PowerDNS_weakforced&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=stCCTTs65S9mjT4ITx-MfXyqnP1M0FoOlvIsEA-iwdQ&e=
> >  
> >  It was also discussed recently on this list:
> >  
> >  > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dovecot.org_list_dovecot_2019-2DMarch_114921.html&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=F_MZgSGFbhEPpQAsxd5uZPK_fbOBWgG4SIvzIXCWC1U&e=
> >  
> >  
> >  Has already been on my personal todo list for some time, so I have no 
> >  experience how (good) it actually works.
> 
> That was a thread I started. I got wforce to work. However the "reporting IP" 
> in the logs always shows as 127.0.0.1, so I risk banning myself. Here's the 
> log entry:
> Apr 12 10:06:12 auth: Debug: policy(ouruser,127.0.0.1,): 
> Policy server request JSON: 
> {"device_id":"","login":"ouruser","protocol":"imap","pwhash":"2a","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}
> 
> I've tried setting auth_policy_server_url to examples such as:
>   * auth_policy_server_url = http://localhost:8084/
>   * auth_policy_server_url = http://0.0.0.0:8084/
>   * auth_policy_server_url = https://ourdomain.edu:8084/
> in the custom config file for wforce and the rip (reporting IP, e.g., Apr 12 
> 10:06:10 auth: Debug: client in: AUTH 1 PLAIN service=imap secured 
> session=OWoLzlWGDrh/AAAB lip=127.0.0.1 rip=127.0.0.1 lport=143 rport=47118 
> resp=) is either 127.0.0.1 or ourdomain.edu (http://ourdomain.edu).

You are running some kind of proxy in front of it. If you want it to show real 
client IP, you need to enable forwarding of said data. With dovecot it's done 
by setting

login_trusted_networks = your-upstream-host-or-net

in backend config file.

For webmails, this requires both login_trusted_networks and also support from 
the webmail software to forward client IP.

Aki

Re: Mail account brute force / harassment

[Robert Kudyba via dovecot]

>
> You are running some kind of proxy in front of it.


No proxy. Just sendmail with users using emacs/Rmail or
Webmail/Squirrelmail.


> If you want it to show real client IP, you need to enable forwarding of
> said data. With dovecot it's done by setting
>
> login_trusted_networks = your-upstream-host-or-net
>
> in backend config file.
>

OK I changed it and restarted wforce and dovecot. Still seeing this:
Apr 12 14:38:55 auth: Debug: policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>):
Policy server request JSON: {"device_id":"","login":"
ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}


> For webmails, this requires both login_trusted_networks and also support
> from the webmail software to forward client IP.
>

I did get a reply from the Squirrelmail list:
"Well, I've had code sitting around for a while that implements RFC2971 (ID
command), so I just committed it.  You can use it for this purpose by
putting something like this into your config/config_local.php
$imap_id_command_args = array('remote-host' => '###REMOTE ADDRESS###');"

Which I also added previously. But that doesn't address emacs/RMail users.

Could there be a setting in sendmail.mc/cf file that I'm missing?

Re: Mail account brute force / harassment

[Aki Tuomi via dovecot]

> On 12 April 2019 21:45 Robert Kudyba via dovecot  wrote:
> 
> 
> > You are running some kind of proxy in front of it.
> 
> No proxy. Just sendmail with users using emacs/Rmail or Webmail/Squirrelmail.
> 
> > If you want it to show real client IP, you need to enable forwarding of 
> > said data. With dovecot it's done by setting
> >  
> >  login_trusted_networks = your-upstream-host-or-net
> >  
> >  in backend config file.
> 
> OK I changed it and restarted wforce and dovecot. Still seeing this:
> Apr 12 14:38:55 auth: Debug: policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>): 
> Policy server request JSON: {"device_id":"","login":" 
> ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}
> 
> > For webmails, this requires both login_trusted_networks and also support 
> > from the webmail software to forward client IP.
> 
> I did get a reply from the Squirrelmail list:
> "Well, I've had code sitting around for a while that implements RFC2971 (ID 
> command), so I just committed it. You can use it for this purpose by putting 
> something like this into your config/config_local.php
> $imap_id_command_args = array('remote-host' => '###REMOTE ADDRESS###');"
> 
> Which I also added previously. But that doesn't address emacs/RMail users.
> 
> Could there be a setting in sendmail.mc/cf (http://sendmail.mc/cf) file that 
> I'm missing?


Can you verify following?

doveconf auth_policy_request_attributes

auth_policy_request_attributes = login=%{requested_username} 
pwhash=%{hashed_password} remote=%{rip} device_id=%{client_id} protocol=%s

On some versions remote is mistakenly %{real_rip} which expands into where the 
connection came from instead of client IP.

If it's wrong just feel free to copypaste the setting above into dovecot config.

Aki

Aki

Re: Mail account brute force / harassment

[Robert Kudyba via dovecot]

>
> > On 12 April 2019 21:45 Robert Kudyba via dovecot 
> wrote:
> >
> >
> > > You are running some kind of proxy in front of it.
> >
> > No proxy. Just sendmail with users using emacs/Rmail or
> Webmail/Squirrelmail.
> >
> > > If you want it to show real client IP, you need to enable forwarding
> of said data. With dovecot it's done by setting
> > >
> > >  login_trusted_networks = your-upstream-host-or-net
> > >
> > >  in backend config file.
> >
> > OK I changed it and restarted wforce and dovecot. Still seeing this:
> > Apr 12 14:38:55 auth: Debug:
> policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>): Policy server request JSON:
> {"device_id":"","login":"
> ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}
> >
> > > For webmails, this requires both login_trusted_networks and also
> support from the webmail software to forward client IP.
> >
> > I did get a reply from the Squirrelmail list:
> > "Well, I've had code sitting around for a while that implements RFC2971
> (ID command), so I just committed it. You can use it for this purpose by
> putting something like this into your config/config_local.php
> > $imap_id_command_args = array('remote-host' => '###REMOTE ADDRESS###');"
> >
> > Which I also added previously. But that doesn't address emacs/RMail
> users.
> >
> > Could there be a setting in sendmail.mc/cf (
> https://urldefense.proofpoint.com/v2/url?u=http-3A__sendmail.mc_cf&d=DwICaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=CsaMqvBelGXz-_ClT0RDzwqz0tH3cTGNItJktQeULLs&s=JnUd5ej3Twniz2q3fiWUrV_qOFlAwvFHquFjfgsoQJ0&e=)
> file that I'm missing?
>
> Can you verify following?
>
> doveconf auth_policy_request_attributes
>
> auth_policy_request_attributes = login=%{requested_username}
> pwhash=%{hashed_password} remote=%{rip} device_id=%{client_id} protocol=%s
>
> On some versions remote is mistakenly %{real_rip} which expands into where
> the connection came from instead of client IP.
>
> If it's wrong just feel free to copypaste the setting above into dovecot
> config.
>

Verified. I believe you told me that on the other thread and I made that
change a while back.

Re: Mail account brute force / harassment

[Aki Tuomi via dovecot]

 
 
  
   
  
  
   
On 12 April 2019 at 22:01 Robert Kudyba via dovecot <
dovecot@dovecot.org> wrote:
   
   

   
   

   
   
>
   
   

 
  On 12 April 2019 21:45 Robert Kudyba via dovecot <
  dovecot@dovecot.org>
 


 wrote:


 >


 >


 
  
   You are running some kind of proxy in front of it.
  
 


 
  No proxy. Just sendmail with users using emacs/Rmail or
 


 Webmail/Squirrelmail.


 >


 
  
   If you want it to show real client IP, you need to enable forwarding
  
 


 of said data. With dovecot it's done by setting


 
 
  
   login_trusted_networks = your-upstream-host-or-net
  
 
 
  
   in backend config file.
  
 


 
  OK I changed it and restarted wforce and dovecot. Still seeing this:
 
 
  Apr 12 14:38:55 auth: Debug:
 


 policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>): Policy server request JSON:


 {"device_id":"","login":"


 ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}


 >


 
  
   For webmails, this requires both login_trusted_networks and also
  
 


 support from the webmail software to forward client IP.


 >


 
  I did get a reply from the Squirrelmail list:
 
 
  "Well, I've had code sitting around for a while that implements RFC2971
 


 (ID command), so I just committed it. You can use it for this purpose by


 putting something like this into your config/config_local.php


 
  $imap_id_command_args = array('remote-host' => '###REMOTE ADDRESS###');"
 


 
  Which I also added previously. But that doesn't address emacs/RMail
 


 users.


 >


 
  Could there be a setting in sendmail.mc/cf (
 


 https://urldefense.proofpoint.com/v2/url?u=http-3A__sendmail.mc_cf&d=DwICaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=CsaMqvBelGXz-_ClT0RDzwqz0tH3cTGNItJktQeULLs&s=JnUd5ej3Twniz2q3fiWUrV_qOFlAwvFHquFjfgsoQJ0&e=)


 file that I'm missing?

   
   

 Can you verify following?

   
   

 doveconf auth_policy_request_attributes

   
   

 auth_policy_request_attributes = login=%{requested_username}


 pwhash=%{hashed_password} remote=%{rip} device_id=%{client_id} protocol=%s

   
   

 On some versions remote is mistakenly %{real_rip} which expands into where


 the connection came from instead of client IP.

   
   

 If it's wrong just feel free to copypaste the setting above into dovecot


 config.

   
   

   
   
Verified. I believe you told me that on the other thread and I made that
   
   
change a while back.
   
  
  
   
  
  
   
  
  
   Fot the webmail array you probably need https://wiki2.dovecot.org/Design/ParameterForwarding so you can configure it correctly.
  
  
   
  
  
   No idea how to configure sendmail.
  
  
   ---
   Aki Tuomi
   
 

Re: Mail account brute force / harassment

[Joseph Tam via dovecot]

On Fri, 12 Apr 2019, mj wrote:

What we do is: use https://github.com/trick77/ipset-blacklist to block IPs 
(from various existing blacklists) at the iptables level using an ipset.


"www.blocklist.de" is a nifty source.  Could you suggest other publically
available blacklists?

That way, the known bad IPs never even talk to dovecot, but are dropped 
immediately. We have the feeling it helps a lot.


Really helps with uber-stupid BFD attacks that pound our plaintext ports
even though Dovecot repeatedly responds with

-ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) 
connections.
* BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but 
your client did it anyway. If anyone was listening, the password was exposed.
xx NO [PRIVACYREQUIRED] Plaintext authentication disallowed on 
non-secure (SSL/TLS) connections.

The irony is that even if it blunders onto a usable password, they wouldn't
know it.

Joseph Tam 

Re: Mail account brute force / harassment

[mj via dovecot]

Hi,

On 4/12/19 11:05 PM, Joseph Tam via dovecot wrote:

"www.blocklist.de" is a nifty source.  Could you suggest other publically
available blacklists?



The ones we are using are:


"file:///etc/ipset-blacklist/ip-blacklist-custom.list" # optional, for your 
personal nemeses (no typo, plural)


In this file we have our own manual additions


"https://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1"; # Project Honey 
Pot Directory of Dictionary Attacker IPs
"https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1";  # TOR 
Exit Nodes
"https://www.maxmind.com/en/high-risk-ip-sample-list"; # MaxMind GeoIP 
Anonymous Proxies
"http://danger.rulez.sk/projects/bruteforceblocker/blist.php"; # 
BruteForceBlocker IP List
"https://www.spamhaus.org/drop/drop.lasso"; # Spamhaus Don't Route Or Peer 
List (DROP)
"http://cinsscore.com/list/ci-badguys.txt"; # C.I. Army Malicious IP List
"https://lists.blocklist.de/lists/all.txt"; # blocklist.de attackers
"http://blocklist.greensnow.co/greensnow.txt"; # GreenSnow

"https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level1.netset";
 # Firehol Level 1

"https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/stopforumspam_7d.ipset";
 # Stopforumspam via Firehol


MJ