Mail account brute force / harassment
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.
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 jtam.home@gmail.com
Le 11 avr. 2019 à 12:23, Marc Roos via dovecot dovecot@dovecot.org 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).
participants (3)
-
Jean-Daniel Dupas
-
Joseph Tam
-
Marc Roos