The Risks of Internet-accessible email servers
Is your mailserver in "Da Cloud!" (tm) or is it accessible from insecure networks without decent 2-factor authentication? Do you monitor your logs to look for login failures? Do you monitor your DNS query logs or outbound email logs for surges in activity? No? Then this article is for you.
At previous jobs and consulting gigs I've always urged that they require a VPN connection with strong 2-factor authentication in order to access email. (gasp) But that's so inconvenient! Most people seem blissfully unaware that if they can get to their email from any device connected to any network anywhere in the world with nothing more than a username and password that also means that anyone can connect to their email account from anywhere at any time also. These days it's considered trivial to trick most users into handing over the keys to their email account. Take a look at what happened to John Podesta. Yup, his email wasn't "hacked" by Russian Hackers (tm), he was tricked by a phish into entering in his email credentials into some website - he gave up the keys to his email account which was accessible from anywhere by anyone with those credentials. Sad, really. And what other cloud apps use the same password as a user's email password?
Another risk is that spammers, phishers, and other bad actors will often use your exposed mail server to try to brute-force accounts. They'll repeatedly try different passwords for various accounts unti they crack one. Once in, they might use that account to phish your own users (the phish email will then be coming from one of their co-workers' email accounts after all) or they might use it to send spam. This risk can be mitigated, a little, if you at least monitor your access logs. You do monitor your logs, right? (wink)
For example, I've recently been skimming my logs for a "weight loss pill" spammer, updating my filters to block the IP addresses and accounts sending his spam, hopefully before it gets to too many of my users. And we recently found out that this particular spammer is using compromised email accounts to send his spam. Yay cloud. And it just so happens that someone started trying pretty hard to brute-force our email accounts too. Take a look at what showed up in one of my log server dashboards:
What first caught my eye was the big increase in blocked and deferred emails (the bottom two line charts). When I filter out "allowed" and "whitelisted" emails then the pie chart in the upper left corner becomes "interesting" and shows that almost all of the IP addresses connecting to one of our three barracuda spam firewalls are being rejected due to rate-limiting (pink in the outer ring) or due to authentication failures (green). Basically, they're trying to brute force email accounts and the cudas are rate-limiting them. Not to mention, we don't allow access to email accounts via the cudas anyway. So while I won't lose any sleep worrying about if they brute force an account (they can't since none of my users can authenticate directly like this), it does give me another list of IP addresses that are probably compromised systems participating in one botnet or another.
Anyway, the bottom line here is, don't expose your mail servers to the internet unless you really, absitively, posolutely must and preferably require strong 2-factor authentication and a VPN connection to gain access to things like email. I'd even go so far these days as to recommend that any cloud app should require 2-factor authentication also if it contains anything remotely sensitive that you would rather not find posted on wikileaks or reddit or 4chan or anywhere else in public. Yeah, it's a little less convenient, but most smart-phones can be made to connect to a VPN these days.
And if you must expose services like email to the internet, log everything and monitor those logs often for strange behavior. For instance, if the admins of the users whose email accounts are being used to send pill spam were monitoring DNS query logs, or SMTP traffic (email) they'd see a giant spike in MX record queries and/or outbound email traffic. If the spam was being sent by a spambot (also called "direct to mx" spam), they'd see giant spikes in MX record queries in their DNS logs by systems that don't normally query for MX records. If you log things like this and just as importantly if you monitor those logs you're more likely to be able detect and stop this activity before you find your mail server or domain has been blocked by half the internet for sending spam.