IMAP/SMTP server security - how to secure account access, MFA, ...?

C

cmoerz

Hi everyone,

I do understand, that by today it's bordering on insanity to spin your own, but please bear with me: if you set up and run your own mailserver - how do you go about securing it in terms of credential stuffing and all that stuff that is going around the internet?

I'd expect some multi factor authentication in the available IMAP and SMTP servers, but so far my research has brought up zero, zip, zilch, nada.

Has email become such an unusual thing to run yourself or am I missing some obvious alternative to secure account access? There are open source options for running OAuth2 (i.e. Keycloak) and they work great. Are we missing an IMAP and SMTP server that properly support modern authentication protocols? Are they so difficult to implement that none have dared to do it yet?

Would love to hear what you think and if you have any recommendations?

thanks!
 
cmoerz said:
Hi everyone,

I do understand, that by today it's bordering on insanity to spin your own, but please bear with me: if you set up and run your own mailserver - how do you go about securing it in terms of credential stuffing and all that stuff that is going around the internet?

I'd expect some multi factor authentication in the available IMAP and SMTP servers, but so far my research has brought up zero, zip, zilch, nada.

Has email become such an unusual thing to run yourself or am I missing some obvious alternative to secure account access? There are open source options for running OAuth2 (i.e. Keycloak) and they work great. Are we missing an IMAP and SMTP server that properly support modern authentication protocols? Are they so difficult to implement that none have dared to do it yet?

Would love to hear what you think and if you have any recommendations?

thanks!
Click to expand...
For my own server I am using security/sshguard to block server access over three failed login attempts to mail/sendmail and mail/dovecot. Although I exclusively use private key for SSH authentication, it is also used to monitor attacks against sshd(8) and blacklist criminal IPs.
 
cmoerz said:
I'd expect some multi factor authentication in the available IMAP and SMTP servers,
Click to expand...
I don't think MFA is a good solution. Oauth was leaking badly recently.

Oh-Auth – Abusing OAuth to take over millions of accounts | Hacker News

news.ycombinator.com news.ycombinator.com

Grammarly's OAuth Mistakes | Hacker News

news.ycombinator.com news.ycombinator.com
www.scmagazine.com

Flaws in OAuth’s social sign-in could have put billions of users at risk

Security researchers advise teams not to allow social sign-ins from accounts such as Facebook and Google, and instead deploy single-sign-on options.
www.scmagazine.com www.scmagazine.com

I like the sounds of encrypted keys where you can choose the strength.
That sounds like a tight setup along with ssh-agent.

SSH Agent Explained

The SSH agent acts behind the scenes to keep you safe. Here's how it works.
smallstep.com smallstep.com
 
cmoerz said:
how do you go about securing it in terms of credential stuffing and all that stuff that is going around the internet?
Click to expand...

1. enforce safe passwords
2. urge the use of UNIQUE passwords per service.
3. promote using password managers to achieve 1. & 2.

Also monitor haveibeenpwned for leaks that include users of your maildomain. You can set up alerts via their domain search feature.
In case some of your users show up in a leak, inform them, and refer to 1. - 3.

Regarding MFA there are some (usually proprietary) ways of adding MFA like e.g. TOTP to IMAP and SMTP/submission, but this is not part of the RFCs and hence would break compatibility with essentially all MUAs and even the webmailers you might run. So in short: don't do that.

From my observations over the years, it seems that mailservers that are already well-protected against accepting crap via SMTP (i.e. receiving spam), also get hit less by botnets trying to authenticate on IMAP and/or SMPT/submission (or any other service like SSH etc).
Those attacks have dropped dramatically since I put mail/spamd in front of postfix on the mail servers I administer, which also reduced the amount of spam hitting mail/rspamd by ~80% and hence saves a lot of system ressources used on 'expensive' filtering. On my private (i.e. relatively low-volume) mail server this even led to the starvation of the rspamd bayes database, so I started to share it between mailservers (as well as several PF tables).
Also consider using blacklistd(5) and/or overload-rules in pf.conf(8) for IMAP and submission ports.
Since I use spamd, the tables fed by blacklistd and overload-rules have become relatively short - i.e. a few dozend to maybe in the low-hundred entries instead of many hundreds or even thousands, except for the occasional peaks when new botnet waves hit the net. I assume (some) scammers/botnets have started to avoid servers that are known to be very strict and well protected, i.e. have a very low chance of success and they only waste time and ressources.
To be clear: you will still see the normal background-noise, but actual *targeted* attacks may be less likely. (of course YMMV)

Overload-rules need *very* careful fine-tuning to not interfere with legitimate MUAs that might connect multiple times (e.g. in parallel) in a short period of time or your corporate network where all users will connect via the same IP or subnet.
Consider using whitelists for those prefixes - the easiest are corporate public prefixes, but if you'd have to whitelist dynamic prefixes from ISPs be aware that this may include a lot of malicious IPs. For mobile this is hardly feasible...
Same goes for geoblocking by maintaining country-based prefix lists. This might work if you have a very well defined user-base from one or very few countries, but gets more and more messy if they connect from all over the world and/or via mobile networks, VPN or even satellite-based services like skylink.

Regarding sshguard or other log-parsers: I don't use them any more as blacklistd is superior in many ways. I only use log-parsing by mail/pflogsumm to get daily/weekly postfix statistics.


In short: there are several means of protecting against such attacks without breaking the services by introducing RFC-violating measurements like MFA. But even the most advanced and sophisticated combination of threat mitigations *will* fail if your users are ignoring points 1 or 2.
 
We are attempting to implement two factor authentication (Google Authenticator) with Dovecot (mandated by our insurance company) and thought I'd share some info. Oddly enough, we are only required to use TFA for retrieving mail, not sending it, so this only applies to IMAP side of things. BTW, If someone has a complete write up on setting up OATH2 with Dovecot, I'd love to see it.

By far the easiest way to do this is just use mail/roundcube with mail/roundcube-twofactor_gauthenticator running on your email server. If it was up to me, this would be our solution (alternative being that we move all employees to gmail/outlook365 accounts).

Unfortunately in our case, this was a no go for management. I was tasked with getting TFA to work with the existing mix of Outlook, Thunderbird, Apple Mail, and other email clients. In theory the setup below works, but there are show stopping issues which we are trying to figure out.

The primary issue with this setup is that different email clients handle IMAP sessions a little differently. Some clients will continually prompt for a new password on every check. Some clients seem to work for a while, but eventually fail authentications. To add insult to injury, the auth failures happen in background and mail client will not prompt for a new password for an excessive amount of time or users sends an email. This gives the user the appearance that everything is working, but email is actually not being retrieved. Basically, a tech support nightmare on top of an existing support mess.

There are provisions in the pam_google_authenticator code for a grace period, but there issues with this implementation regarding various clients. I think we found a proposed solution to the grace period issue in the link below:

github.com

grace_period doesn't honor forward_pass · Issue #181 · google/google-authenticator-libpam

I was trying to implement grace_period with our existing forward_pass option to no avail. While grace_period itself authenticates without issue with the LASTIP option, I believe the full password g...
github.com github.com

Coding this is beyond my skill set, so I am working with a 3rd party to get some kind of patch worked out to get the issue resolved. However, the proposed solution breaks when the user has multiple email clients on the same network (think desktop / phone). In this scenario, user has to take note of the 6 digit code and use it on both clients.

Our test configuration:
Install security/pam_google_authenticator. Edit /etc/pam.d/dovecot to use the pam module. Entries should like something like:
Code: 
auth       required     pam_google_authenticator.so     forward_pass grace_period=43200 debug
auth       required     pam_unix.so     no_warn use_first_pass

Make sure that your dovecot.conf is using the dovecot pam:
Code: 
passwd {
    args= session=yes failure_show_msg=yes dovecot
    driver = pam
}

Create your Authenticator token and code add it to the Google Authenticator App. Authentication with Dovecot will be a combination of your password and the 6 digit authenticator code, so if your password is "mypassword" and the app shows "333 444", the password you will enter will be "mypassword333444".
 
Interesting approach.

So far, I've only seen references for implementing OPIE which could be an improvement, but it's not really a second factor. Clearly, this is a complex issue as you point out.
 
You must log in or register to reply here.
Back
Top