On 3 Mar 2020, at 2:26, Ted Mittelstaedt wrote:
I know this is probably off topic but I'm getting desperate enough to
ask.
I run a commercial mailserver that regularly seems to have spammers
relay mail through it that have obtained stolen credentials for a
user. Many years ago I stopped allowing users to change passwords on
it and I setup passwords for all users added to it, and the passwords
are random strings of 8 characters or more.
The problem is of course that since the passwords are difficult to
remember, once the users do remember them they merrily proceed to use
this "highly secure password that I can now remember" on every stupid
website out on the Internet that they care to login to. The problem
isn't really the people using Thunderbird or Outlook or their cell
phones or whatever, because they save the password in the email client
and then immediately forget it, which is what I want. It is the
people who use the webmail interface on multiple different systems,
kiosk
computers and the like, who are the problem.
The standard answer for this is to require some form of 2-step/2-factor
authentication. If you have users actually entering their usernames and
passwords in to random computers they will never see again, the only
sound practice is some form of 2FA where the 2nd step is ephemeral: OTP
of some variety, one-time codes via SMS, etc.
However, there's another useful tactic that doesn't require you to
deploy all-new services, although it will require some user training.
Decouple authentication identities from email address deliverability.
There is no intrinsic reason that a username must be a deliverable email
address, even if it looks like one. I originally did this almost
accidentally on my oldest surviving mail system, which has now hit 25
years (across multiple platforms, of course) without a single account
hijack. It's absurdly simple. My users all have real user accounts on
the mail server. They authenticate using
usern...@mailhostname.scconsult.com. Their primary email addresses are
somthinge...@scconsult.com. somethinge...@mailhostname.scconsult.com is
non-existent in any sense, as is usern...@scconsult.com. The
authentication name (usern...@mailhostname.scconsult.com) is only
deliverable locally: Postfix only accepts mail via SMTP for virtual
domains (e.g. scconsult.com, billmail.scconsult.com, grumpybozo.us,
etc.) Usable email addresses are not authentication identities and
authentication identities are not usable email addresses. Before I
started firewalling them as noisy nuisances, I had a constant flow of
auth attempts for various names that could never succeed against IMAP,
POP, both submission ports, SMTP (where I don't even allow AUTH!) and a
private website with an entirely distinct user namespace. HIBP tells me
that some miscreants probably have once-valid email+password combos for
some of my users at random breached websites, and I've seen auth
attempts for those email addresses from credential-stuffer bots, but
even if the owners of those addresses used the same passwords for the
breached sites as for their email, those attempts cannot succeed because
their email accounts do not use their email addresses as usernames.
That DOES NOT solve the Evil Kiosk Operator problem, of course. For
that, you need the aforementioned 2FA with one-use second factors.
[...]
What I am wondering is how to tighten up my monitoring on my servers
to
more rapidly identify when this starts happening. What I'm doing now
is
a kludge but I run mailq (this is a sendmail system) and when I see
the
number of pending mail mesages in there exceed a threshold I send an
alert to my cell. It is a kludge and the problem is that
the mailq doesn't start filling up until my server gets blacklisted.
That's particularly bad with low-flow/snowshoe spammers who route one
message every 10 minutes through each of 300 compromised accounts spread
across 20 different servers, most of them on megaproviders. You won't
notice anything until the particular spam content has been fingerprinted
in shared systems like DCC, Pyzor, Razor, and Cloudmark.
I've considered several ideas like running a script out of cron that
checks the number of authid's per hour but all of these seem like even
worse kludges. The only idea that I have come up with that I really
like is taking an AK-47 to the spammers but unfortunately spammers
know that they are unloved and cowardly hide away in Russia and
scummier
places and I can't reach 'em. (maybe I could offer a bounty? A
nickle a head? That would pay for the bullet at least. I don't think
those people are worth even that, though)
There's a seed of a useful idea in that paragraph...
Why do you allow access to IMAP, POP, or either mail submission port
(465 or 587) from random Russian IPs? Do you allow AUTH at all on port
25 and if so, why?
What I've done is that I have a log watcher (akin to fail2ban, but
built-to-purpose) on my Postfix and Dovecot logs, looking for failed
auth attempts. With some guardrails around it, this triggers an
automatic packet filter block on the surrounding registered route
against accessing mail client ports. On an irregular basis I consolidate
those blocks both programmatically and by eyeballing rational
megablocks. So on my mail server, 'ipfw list' includes 610 rules
blocking ports 110, 143, 465, 587, 993, and 995 for network ranges as
small as /24 and as large as /4. I can do that because my users are not
world travelers, but even on systems where a policy of "no mail
submission from RIPE or APNIC blocks" isn't possible, one can generally
be safe with rules like "no mail submission from AWS, GCP, Azure, OVH,
or Linode" and successfully shed a large fraction of the credential
stuffers.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
