Strategies for protecting IMAP (e.g. MFA)
With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work.
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
- Tyler Montney:
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) passwords which are used only once (!) and kept either in the user's brain or in an encrypted password store. Ensure that authentication data can only be transmitted over encrypted connections.
These measures cover a lot of ground, if the users are sufficiently disciplined. Users are usually the weakest link.
-Ralph
"Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) password"
Again, since it's just me, this is do-able. But I'm looking for something practical as well. I'm getting the feeling that people don't have an MFA implementation.
"if the users are sufficiently discipline"
As a Sysadmin, I can tell you they genuinely are not and they likely never will be. Hope for the best, plan for the worst.
I also want to clarify that I'm not rejecting any of these suggestions, they're all good.
On Sat, Nov 13, 2021 at 4:42 PM Ralph Seichter <ralph@ml.seichter.de> wrote:
- Tyler Montney:
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) passwords which are used only once (!) and kept either in the user's brain or in an encrypted password store. Ensure that authentication data can only be transmitted over encrypted connections.
These measures cover a lot of ground, if the users are sufficiently disciplined. Users are usually the weakest link.
-Ralph
On 13/11/2021 23:34, lists wrote:
The thing I don't like is most 2FA token generators. Ultimately you need to transfer the polynomial that generates the code. Most do that with a QR image. Well so much for security! Others have a one time emergency code. Of course we are talking evil maid attacks, which granted is an unacceptable term these days.
Now Yubikey at least has my attention. But people often leave the key plugged into their notebook. Very true with the Google equivalent which I have heard from Google employees. The keys themselves aren't exactly transferable, but when you have physical access then all bets are off.
If someone fool actually paid me to be sysadmin, I would use a Yubikey.
Note Freeotp let's you input the code but also has the QR code fallback. The phone app however hasn't been updated in years. It does allow you to test out a TOTP scheme. It took me no time to write a script to accept the token on Linux. The tricky part if I recall correctly was setting up the script to accept the token that just expired. You would want to do that to minimize user friction.
Not to get too far off track but I don't allow any web control over my email server. There is no control panel to hack. I ssh into the server and that uses PKI. I do everything via CLI. If ssh is compromised then nothing else will be secure so email would be the last of my problems.
Companies such as Last pass (not an endorsement but an example) supposedly incorporate password generators. If you are going to allow users to set let alone change their own password, you might be able to write a script that generates the password.
If I were to go up to the next level of security I would use mail-crypt. It is just that I see so much chatter about getting it to work. *From:* montneytyler@gmail.com *Sent:* November 13, 2021 3:03 PM *To:* dovecot@dovecot.org *Subject:* Re: Strategies for protecting IMAP (e.g. MFA)
"Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) password"
Again, since it's just me, this is do-able. But I'm looking for something practical as well. I'm getting the feeling that people don't have an MFA implementation.
"if the users are sufficiently discipline"
As a Sysadmin, I can tell you they genuinely are not and they likely never will be. Hope for the best, plan for the worst.
I also want to clarify that I'm not rejecting any of these suggestions, they're all good.
On Sat, Nov 13, 2021 at 4:42 PM Ralph Seichter <ralph@ml.seichter.de <mailto:ralph@ml.seichter.de>> wrote:
* Tyler Montney: > Since this is getting increasingly complicated, I wanted to ask before > going further. What do you all do? Any recommendations? Use strong (as in long and/or randomised and impossible to break using rainbow table attacks) passwords which are used only once (!) and kept either in the user's brain or in an encrypted password store. Ensure that authentication data can only be transmitted over encrypted connections. These measures cover a lot of ground, if the users are sufficiently disciplined. Users are usually the weakest link. -Ralph
I almost reached this stage with a personal / open source project I am working on.
It is based on Dovecot login scripts, and ejabberd to send alerts in XMPP, from the postmaster account.
The details:
Custom dovecot login scripts compute a "confidence" score, with two thresholds. The first lower threshold raises a warning sent by xmpp with some details, while the second threshold simply deny the connection.
A few of us have been using it for a while, both on mobile and desktop.
The current stable version is based on Stretch, as Buster has too many issues, We are now working on the bullseye version.
It is perfectly valid to extend the Dovecot custom script to include for instance Duo authentication.
Another option would be to extend a Dovecot custom login script to wait for an answer on xmpp message sent by postmaster, or even something crazier like a HOTP / TOTP code.
Good luck.
Homebox: https://github.com/progmaticltd/homebox
-- 𝓐𝓡 - André Rodier
-- 𝓐𝓡 - André Rodier
On Sat, Nov 13, 2021 at 03:34:12PM -0800, lists wrote:
[..] Now Yubikey at least has my attention. But people often leave the key plugged into their notebook. Very true with the Google equivalent which I have heard from Google employees. The keys themselves aren't exactly transferable, but when you have physical access then all bets are off.
Yubikeys are available in several form factors. Not all of them can readily be left plugged in - at least, not into a portable device. The larger Yubikeys stick out too far and would likely fall out or get broken if left plugged in.
So, if you don't want laptop users leaving their keys in their devices, give them larger format Yubikeys. (Or Nitrokeys, see below.)
If someone fool actually paid me to be sysadmin, I would use a Yubikey. [..]
Yubikeys are decent in many respects, but not entirely unproblematic:
https://en.wikipedia.org/w/index.php?title=YubiKey&oldid=1053509936#Security...
For portable hardware security tokens with a better security track record (to my knowledge, anyway), see:
https://en.wikipedia.org/wiki/Nitrokey
Also possibly of interest:
https://www.gniibe.org/category/fst-01.html
-- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
- Tyler Montney:
I'm getting the feeling that people don't have an MFA implementation.
Probably because it can be complex to set up and maintain, and more would be gained by educating users and in particular by users actually giving a damn about password-discipline and -quality.
On a tangent: I personally find your style of quoting a bit irritating, especially because you leave the whole original message intact. Why not quote in a manner we have successfully used for a couple of decades? Thanks!
-Ralph
Probably because it can be complex to set up and maintain
Such is mail and many other things, which falls on the admins. I see no harm in exploring what's what before deciding.
and more would be gained by educating users
Yes, users are the weakest link. Users are also the biggest challenge. Making them use 2FA on their phone? Easy. Retraining them to think more like me? Very difficult (assuming you get management buy-in).
Again, I'm trying to explore deploying an all "bells and whistles" mail stack that can cater to both an enthusiast environment (like myself) and one in a commercial/enterprise environment. Not having 2FA like I could get from cloud offerings may be a deal breaker for me.
I personally find your style of quoting a bit irritating, especially because you leave the whole original message intac
Gmail loves hiding the previous text with an ellipsis, making me not realize.
Why not quote in a manner we have successfully used for a couple of decades?
I've just recently started using mailing lists, so replying is still a bit awkward to me. (Probably be easier if we'd use forums.)
On Mon, Nov 15, 2021 at 02:14:31PM -0600, Tyler Montney wrote:
I've just recently started using mailing lists, so replying is still a bit awkward to me. (Probably be easier if we'd use forums.)
Forums are a mixed bag. Some love them, some hate them.
I previously ran a forum for LedgerSMB. It had some usage, but people mostly preferred the mailing lists.
I was also running an add-on by the forum author that allowed posting incoming emails to boards. I never setup an outgoing to the mailing list. I wanted to. No time.
However, reading and searching emails from a mailing list in a forum is *nice*. Really nice. You can see the entire thread at once.
If any mailing list I'm part of wants to do a read-only posting of email only messages like that, I would put up a forum for that only, for free.
I would only make something like that public if the mailing list owners wanted it done.
As far as 2FA over a phone, I hate it. When traveling, my phone only works in USA, Canada and Mexico. If I were in Guatemala, I'd have no access to my DNS server company. Ugh!
-- Chris Bennett
Op 13 nov. 2021 om 22:17 heeft Tyler Montney <montneytyler@gmail.com> het volgende geschreven:
With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work.
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
If I remember correctly, Dovecot is able to do IP whitelisting in the userdb or passdb. That way, you don’t have to close your mail ports, but you can add an additional layer of protection with an IP whitelist per mailbox.
On 2021-11-13 22:16, Tyler Montney wrote:
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
in the end we all know how to play ludo
passwords is hard to guess if its odd number of chars, and random selected chars filled with 6 digest as must please confirm your mobil phone numbers is already :)
worst case is when sites dont allow more then 12 chars as the password, hmm
dont share how many chars used could be part of the game
if password used can be divided by 7 will it be a even or odd number ?
its still sunday here
I will throw in a few interesting projects which have kept my small servers safe:
*) firehol.org
*) crowdsec.net
*) www.fail2ban.org
Have a look at those interesting projects!
On 13.11.21 22:16, Tyler Montney wrote:
With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work.
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
On 13/11/2021 23:16, Tyler Montney wrote:
With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work.
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
May also consider black listing, or even better, white listing country IPs. A white list firewall, if you only have to deal with certain country for example, will also work extremely well and it is quite easy to maintain and update as well as simple and fast and very effective.
And if you need sporadically to use it outside your white listing, VPN works great.
On 2021-11-14 7:55 a.m., Lefteris Tsintjelis wrote:
On 13/11/2021 23:16, Tyler Montney wrote:
With the world of ransomware as it is today (aka attacks seem more vicious and commonplace), anything I expose to WAN must have additional protection. I've seen a few posts to this list on it. The only thing that helped was that Dovecot supports OAuth. Through OAuth I figure I could implement MFA. However, I'd have to host my own identity server. From there, Thunderbird supports OAuth so that should work.
Since this is getting increasingly complicated, I wanted to ask before going further. What do you all do? Any recommendations?
May also consider black listing, or even better, white listing country IPs. A white list firewall, if you only have to deal with certain country for example, will also work extremely well and it is quite easy to maintain and update as well as simple and fast and very effective.
And if you need sporadically to use it outside your white listing, VPN works great.
Our threat teams do a lot of work around IMAP threats, and a couple of things to note.. there is a marked increase of IMAP attackers using cloud infrastructure for IMAP hacks..
You might ask the question, do you need to allow IMAP access from the cloud, or do you expect only email clients to access them.
If the later, consider blocking AWS, GoogleCloud, Azure from connecting to your IMAP. Note, it may affect certain VPN anonymizers, or Desk Top in the Cloud, but in general given the predilection of certain hacking groups for those, you might like to control that.
And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks.
And for 'some' IMAP operators, country AUTH blocking might be valuable. Of course, you have to consider your users, and what they can do when traveling or vacationing. A step forward, is to do country AUTH blocking, and insist they use a email client which supports MFA when traveling, or force them to use webmail.
Of course, transparent 2FA is the way to go in the long run. Time to update that pull request, so that plugins can dynamically control CAPABILITY advertisements.
-- "Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP connections from listed IPs?
-- Best wishes, Matthew
On 2021-11-14 20:26, Matthew Richardson wrote:
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP connections from listed IPs?
submission inet n - y - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=no -o { smtpd_client_restrictions = reject_rbl_client auth.spamrats.com=127.0.0.39, permit } -o { smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject }
openRelay, dont do it
resolved version
submission inet n - y - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=no -o { smtpd_relay_restrictions = reject_rbl_client auth.spamrats.com=127.0.0.39, permit_mynetworks, permit_sasl_authenticated, reject }
order do matter
for dovecot use allow_nets or weekforce policy server, 3dr party, if dovecot is the submission it would imho be a winner
i still consider external service as a insecure help
Citeren Benny Pedersen <me@junc.eu>:
On 2021-11-14 20:26, Matthew Richardson wrote:
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP connections from listed IPs?
submission inet n - y - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=no -o { smtpd_client_restrictions = reject_rbl_client
auth.spamrats.com=127.0.0.39, permit } -o { smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject }
This is not an answer to the question, this is Postfix syntax.
openRelay, dont do it
In what way would this create an open relay exactly? The 'permit' at
the end of the 'smtpd_client_restrictions' only means that the client
is accepted, not that other smtpd restrictions are lifted.
resolved version
submission inet n - y - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=no -o { smtpd_relay_restrictions = reject_rbl_client
auth.spamrats.com=127.0.0.39, permit_mynetworks,
permit_sasl_authenticated, reject }
Although syntactically correct, it is confusing at best to put client
restrictions in another place than smtpd_client_restrictions.
Especially with 'smtpd_delay_reject=no' in effect you'd only reject
after receiving 'RCPT TO', which is evaluated after
'smtpd_client_restrictions' and 'smtpd_helo_restrictions' during the
SMTP transfer.
order do matter
Indeed.
On 15/11/2021 11:52, Arjen de Korte wrote:
Citeren Benny Pedersen <me@junc.eu>:
On 2021-11-14 20:26, Matthew Richardson wrote:
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP connections from listed IPs?
submission inet n - y - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=no -o { smtpd_client_restrictions = reject_rbl_client auth.spamrats.com=127.0.0.39, permit } -o { smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject }
This is not an answer to the question, this is Postfix syntax.
openRelay, dont do it
In what way would this create an open relay exactly? The 'permit' at the end of the 'smtpd_client_restrictions' only means that the client is accepted, not that other smtpd restrictions are lifted.
resolved version
submission inet n - y - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=no -o { smtpd_relay_restrictions = reject_rbl_client auth.spamrats.com=127.0.0.39, permit_mynetworks, permit_sasl_authenticated, reject }
Although syntactically correct, it is confusing at best to put client restrictions in another place than smtpd_client_restrictions. Especially with 'smtpd_delay_reject=no' in effect you'd only reject after receiving 'RCPT TO', which is evaluated after 'smtpd_client_restrictions' and 'smtpd_helo_restrictions' during the SMTP transfer.
order do matter
Indeed.
Perhaps I was not clear in my last message. Have a look to this documentation:
https://homebox.readthedocs.io/en/latest/email-access-monitoring/
I am available if you have any question to implement something similar yourself. Extending the system to add a second factor authentication is probably easy enough.
Kind regards, André
-- 𝓐𝓡 - André Rodier
On Sun, 14 Nov 2021, Michael Peddemors wrote:
And there are RBL's now for know IP(s) used by IMAP hackers, including SpamRats RATS-AUTH that can assist in reducing those attacks.
These guys also lists brute forcers:
http://www.blocklist.de/en/rbldns.htmlI don't know how well they catch IMAP hackers, but they list 95%+ of our ssh brute forcing attacks.
Joseph Tam <jtam.home@gmail.com>
participants (14)
-
André Rodier
-
Arjen de Korte
-
Benny Pedersen
-
Chris Bennett
-
infoomatic
-
Joseph Tam
-
Lefteris Tsintjelis
-
lists
-
Matthew Richardson
-
Michael Peddemors
-
Ralph Seichter
-
Sam Kuper
-
Tyler Montney
-
William Edwards