Someone is presumably harvesting email addresses from the SMTP traffic to my VPS

[2b]

I have personally operated a mail server for several years now, hosted on a VPS by Vultr.com with my domain attached. I recently started transitioning from my Gmail address to a personal one on different web services, using the [e-mail] template to know, which one leaked my email address, if that ever happens.

Just a week after this change, I received a Logwatch report with incorrect authentication attempts for these new email addresses:

dovecot: auth: passwd-file([e-mail]): unknown user : 17 Time(s) dovecot: auth: passwd-file([e-mail]): unknown user : 68 Time(s) dovecot: auth: passwd-file([e-mail]): unknown user : 16 Time(s) dovecot: auth: passwd-file([e-mail]): unknown user : 68 Time(s) dovecot: auth: passwd-file([e-mail]): unknown user : 17 Time(s)

1. The VPS is 100% not compromised (besides, why would anyone brute-force a password to something they already have access to?).

2. All software on the VPS is FOSS and is almost always kept up-to-date; the logs are not shared anywhere (e.g., they're not uploaded to a third-party SaaS for analysis).

3. The listed web services do not provide any public profiles that contain these email addresses.

4. All listed services sent confirmation emails upon the change of email address.

5. Services that did not send confirmation messages are not mentioned in the logs with the authentication attempts.

6. I found no evidence that those services have the same ISP, hosting/cloud provider, or even backbone provider (this was analyzed by tracking SMTP client source IP addresses and network traces to them).

7. All this suggests that the email addresses were harvested from the SMTP traffic to my VPS, either at Vultr's infra level or through one of their network providers in the Amsterdam location.

P.S.: My mail server is configured with STARTTLS support, but for some reason, the SMTP clients of those web services chose to use plain SMTP for the confirmation messages.

[tuga]

I'm just speculating, but it's possible that one of the services you utilized with your catch-all account attempted to check if the same password was used for other services. Alternatively, the VPS network might be inadequately configured, enabling tools like tcpdump or Wireshark to intercept network traffic.

[2b]

Interesting points, thank you. Both seem quite possible.

[cookiengineer]

How is your dovecot and mta (assuming postfix?) setup in regards to client and sender verification?

Is it an open relay? If so, you should deactivate it because your server is spamming then.

Most bots also go through dictionaries and try to send dummy emails to specific account names first, so verifying that the domain is the only one accepting emails helps a lot to mitigate against the noise. Any email not containing an FQDN should be blocked

I'd also recommend to create a local block list (e.g. /etc/hosts.deny for ssh or a postmap file for postfix) so that you can block those actors.

If you don't know how to do that, I included a short howto in my postfix-spamdb [1] project where I maintain spammers targeting my email addresses.

Regarding ssh pw auth, I wouldn't recommend fail2ban because it's a very very buggy software and a lot of RCEs have been discovered in the past, but I would recommend a tool that blocks auths from at least other countries where you are not connecting from. If you want to be safe, use TOR and a hidden domain to connect to your ssh daemon, and make ssh listen only on localhost. Careful though, it's not beginner friendly in case tor can't connect and you need to know what you are doing.

As my startup's EDR agent overlaps with those features I'm biased and not gonna recommend tools here. Don't wanna spam.

For private use there's the sshpwauth block list from dataplane which you can use to generate a good enough block list [2].

[1] https://github.com/cookiengineer/postfix-spamdb

[2] https://dataplane.org/sshpwauth.txt

[2b]

Thank you for your suggestions. The MTA is not configured as an open relay. Rspamd is handling the spam. I'm only using public-key authentication for SSH.

[elmerfud]

Of course anyone could be monitoring SMTP that's not encrypted. It possibly could be your VPS provider but that would be quite obvious if they then started a dictionary attack against your accounts. Now on the other hand these service email addresses you're using for different places, keep in mind every place is terms of service says they can share your information with select partners. Or some verbage like that. That means that it could be any number of spam partners that they provide your addresses too, of which there's only a handful in the world. You may have unwittingly stumbled upon all of these entities using the same back end marketing partner service and that service has been compromised in some way.

[DamonHD]

Be aware that some bad actors try to brute-force probe various common username variations.

[2b]

Yeah, except that I obscure the service names in these email addresses, so they definitely aren't dictionary words.

[markstos]

I agree. Looks like a common automated attack and probably not targeted.