spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Cole" <sausers-20150...@billmail.scconsult.com>
Subject Re: Question on early detection for relay spam
Date Tue, 03 Mar 2020 17:05:39 GMT
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 
username@mailhostname.scconsult.com. Their primary email addresses are 
somthingelse@scconsult.com. somethingelse@mailhostname.scconsult.com is 
non-existent in any sense, as is username@scconsult.com. The 
authentication name (username@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)

Mime
View raw message