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:
On 13/11/2021 23:34, lists wrote:
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:
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
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
On 13/11/2021 23:16, Tyler Montney wrote:
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:
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:
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>:
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.
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:
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.html
I 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