similar to: Mail account brute force / harassment

On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot <dovecot at dovecot.org> 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

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

> Am 11.04.2019 um 12:43 schrieb Marc Roos via dovecot <dovecot at dovecot.org>: > > 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

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

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 <M.Roos at f1-outsourcing.eu> 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

On 11 Apr 2019, at 04:43, Marc Roos via dovecot <dovecot at dovecot.org> 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

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

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 at dovecot.org] Sent: donderdag 11 april 2019 13:25 To: dovecot at dovecot.org Subject: Re: Mail account brute force / harassment On 11/04/2019 11:43, Marc Roos via dovecot wrote: > A. With the

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

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

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?

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

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

> On 12 April 2019 18:11 Robert Kudyba via dovecot <dovecot at dovecot.org> wrote: > > > > Probably there's an existing solution for both problems (subsequent > > attempts and dnsbl): > > > > >

> On 12 April 2019 21:45 Robert Kudyba via dovecot <dovecot at 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 > >

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

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

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): > >>

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

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