On 19 Feb 2019, at 5:56, Admin Beckspaced wrote:
Dear Postfix Users,
just recently the computer of a client got infected with malware and
the email password was compromised.
The bad guys immediately started sending out spam emails via our mail
servers.
We got notified by our monitoring system a bit later ... and fixed
things
But lots and lots of spam emails have been sent via out mail server.
How do you protect your mail system against a compromised password and
mass spam mail sending?
Nothing is absolutely perfect but there are useful approaches, some
external to Postfix proper:
1. Rate limiting. Postfix has some of this (smtpd_client_*_limit
parameters) but you may be able to get more effective and subtle limits
via external tools (e.g. I have some custom code in MIMEDefang.)
2. Only offer SASL authentication on submission services (ports 587 and
465,) for port 587 only after STARTTLS, and require TLS (i.e.
smtpd_tls_security_level=encrypt on submission)
3. Apply the same spam filtering to your outbound mail as your inbound
mail. If you use something like SpamAssassin which treats your
locally-originated mail as special (e.g. a significant negative score
for ALL_TRUSTED and/or ALL_INTERNAL in SpamAssassin) you should reduce
or eliminate that special treatment.
4. Restrict access to your submission ports. This is best done outside
of Postfix, either in a host-resident packet filter or a discrete
firewall/router. It also requires that you know your users to some
degree, at least enough to know whether they travel widely or pass their
mail through cloud servers. Do you need to accept submissions from
China? From Vietnam? Random AWS, Azure, OVH, or Digital Ocean IPs? If
your users are world travelers who might need to come in via a Kazakh
mobile network, consider adding a separate submission service on a
non-standard port just for those users, so that your 587 service can be
tightly limited. Or just set up a webmail service for them and tell them
they just can't do direct submission from Tashkent.
5. Separate individual identities for authentication and email. This is
probably the least common trick but it is extremely effective against
both brute-force password guessing attacks AND most forms of "credential
stuffing" using compromised user+password pairs from other sites. For
example, the email address I'm using for this mailing list cannot be
used as a username for authentication anywhere: not on the mail server
where I submit mail for it, my inbound MX (which doesn't do AUTH
anyway,) or my IMAP server. Where I pick up and submit mail for this
address, I authenticate with a username that I use nowhere else and
which cannot be directly translated to an email address that accepts
mail from the world at large. This sort of approach demands some user
training but it essentially eliminates account cracking that isn't
grounded in the compromise of personal devices.
6. Enforce strong password rules & encourage users to use a password
manager so that they can follow those rules more easily.
7. Prohibit the use of Windows, Android, jailbroken iOS, or macOS with
SIP disbled on client devices. I'm only half kidding...
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
