Blocklist for username phishing attempts

Chatmail Relays
1

Hi all, was inspecting the relay VPS after a provider maintenance (forced reboot) and noticed that someone has been phishing the endpoints for 9 character deterministic logins; the attempt created the directories in /home/vmail/… with an enforceE2EEincoming cookie and a password file w/SHA256.

Is there a handy way to drop in a blocklist of usernames somewhere on the relay to automatically reject their attempted use? Here’s what I see from the last few days:

newletter@punkero.org
marketing@punkero.org
webmaster@punkero.org

Of course they don’t work as the proper process to set them up wasn’t followed, but I’d like to somehow prevent anyone from trying to use a handle which misrepresents my relay (I’m sure this was just spammers or something innocuous, no tin foil hats here). We could probably crowdsource a list of 9-char names to block given they’re so commonly attacked.

2

I found these, but I don’t think either one is extensive:

Be advised that such blocklist-based solution will never catch all attempts at hacking. Just think of an abuser doubling the word, prefixing it with the or adding a neutral ending (e.g., 1).

Also note that the random generator might actually produce some identifier on the list by chance and then the user could be surprised.

Anyway, if we wanted to ensure no possibility for clash, chatmail might standardize on an allowlist-kind of scheme such as by always beginning or ending with some uncommon and visibly distinct character, such as a number.

Related:

3

Someone out there is still fishing webmaster@ and I suspect mine is not the only relay; what I’ve done this time after seeing a bunch of IMAP indexes (etc.):sitting there from 5 days ago:

  • removed all content from the user directory except enforceE2EEincoming and password
  • manually edit password and corrupted the hash (inject garbage), chattr +i password
  • ran a chattr +i webmaster@… on the parent directory to prevent new writes[1]

At some point logs will complain when daemons can’t write (when it’s attacked again) which might be interesting to glance at later, but of no great importance if they fail their tasks.

[1] trivia, metadata is stored in the inode, not dirent, except ext4 cheats a little → 4.1. Index Nodes — The Linux Kernel documentation so blocking write to a dir (it’s inode) prevents the system from changing it’s content