Re: Strategies for protecting IMAP (e.g. MFA)

[Benny Pedersen]

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

Re: Strategies for protecting IMAP (e.g. MFA)

[Benny Pedersen]

On 2021-11-14 16:55, Lefteris Tsintjelis wrote:


And if you need sporadically to use it outside your white listing, VPN
works great.


with own CA yes

if not to being fooled by others

Re: Strategies for protecting IMAP (e.g. MFA)

[Matthew Richardson]

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

Re: Strategies for protecting IMAP (e.g. MFA)

[André Rodier]

On 14/11/2021 18:03, Lefteris Tsintjelis wrote:

On 14/11/2021 14:50, Kees van Vloten wrote:


Apart from a really nice firewall firehol also supplies a good set of 
ip-blacklists.


For public exposure of email ports, I am using the combination of 
firehol-firewall, firehol-blacklist, fail2ban and a whitelist based on 
geo-ip. The mail-client ports exposed are 993 and 465, because 
starttls is considered flawed nowadays: https://nostarttls.secvuln.info/)


Full access from any IP (except firehol-blacklist and fail2ban) is 
possible over VPN (openvpn) with MFA (privacyidea).
Privacyidea also supplies a mobile-app compatible with a.o. TOTP and 
HOTP but it provides a more secure way of enrollment (2-step).


Thanks for pointing at crowdsec.net, will see if it can tighten 
security further in cooperation with the above.


- Kees


The problem I faced over the years, with so many IPs, was that the black 
listing way would reach its limits at some point. Using the classic 
fail2ban expiration dates and method, over time, never actually manages 
to get rid of them as they keep on trying and trying. I needed to expand 
the blacklist expiration time limits way high but that reached firewall 
limitations so I personally switched to a permanent white list 
firewalling, as I could do that, and it really got rid of a lot of my 
headaches with just about all my public services.


Black listing would work in case of central dedicated anf large 
firewalls but for smaller solutions I think country white listing 
firewall is far better method.


What would also be interesting is something similar to the spamcop 
combined with crowdsec reporting system so that it can be used to 
effectively analyze and reduce all those bots.


The Spamhouse DROP list would also be a good permanent black list 
addition to any border routers or stand alone public services.


https://www.spamhaus.org/drop/


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

Re: Strategies for protecting IMAP (e.g. MFA)

[Lefteris Tsintjelis]

On 14/11/2021 14:50, Kees van Vloten wrote:


Apart from a really nice firewall firehol also supplies a good set of 
ip-blacklists.


For public exposure of email ports, I am using the combination of 
firehol-firewall, firehol-blacklist, fail2ban and a whitelist based on 
geo-ip. The mail-client ports exposed are 993 and 465, because starttls 
is considered flawed nowadays: https://nostarttls.secvuln.info/)


Full access from any IP (except firehol-blacklist and fail2ban) is 
possible over VPN (openvpn) with MFA (privacyidea).
Privacyidea also supplies a mobile-app compatible with a.o. TOTP and 
HOTP but it provides a more secure way of enrollment (2-step).


Thanks for pointing at crowdsec.net, will see if it can tighten security 
further in cooperation with the above.


- Kees


The problem I faced over the years, with so many IPs, was that the black 
listing way would reach its limits at some point. Using the classic 
fail2ban expiration dates and method, over time, never actually manages 
to get rid of them as they keep on trying and trying. I needed to expand 
the blacklist expiration time limits way high but that reached firewall 
limitations so I personally switched to a permanent white list 
firewalling, as I could do that, and it really got rid of a lot of my 
headaches with just about all my public services.


Black listing would work in case of central dedicated anf large 
firewalls but for smaller solutions I think country white listing 
firewall is far better method.


What would also be interesting is something similar to the spamcop 
combined with crowdsec reporting system so that it can be used to 
effectively analyze and reduce all those bots.


The Spamhouse DROP list would also be a good permanent black list 
addition to any border routers or stand alone public services.


https://www.spamhaus.org/drop/

Re: Strategies for protecting IMAP (e.g. MFA)

[Michael Peddemors]

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.

Re: Strategies for protecting IMAP (e.g. MFA)

[Lefteris Tsintjelis]

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.

Re: ZFS storage and backup

[William Edwards]

> Op 14 nov. 2021 om 15:15 heeft infoomatic  het volgende 
> geschreven:
> 
> Hi listmembers,
> 
> I am about to migrate our mailservices to FreeBSD + ZFS. Thus, before
> entering the sheer endless  stage of performance testing, I thought I
> would ask here kindly for all kinds of information.
> 
> My setups are nothing special with few users, however, I would like to
> have a nice setup, maybe some of you could contribute to this thread. We
> are using slow spinning disks, but we may consider using ssds in a
> not-so-distant future

If performance is a concern, why not now?

> 
> *) storages: any infos on ZFS options or whether to use mdbox or sdbox,
> and what configs/options regarding compression etc.
> 
> *) backup: what is a best practice regarding backups? - using only the
> dovecot tools or leveraging the great features of ZFS (or both) with
> snapshots etc.?
> 
> Thanks for all sorts of infos, probably saving me quite some time
> evaluating different options!
> 
> Robert
> 
> 

Re: ZFS storage and backup

[Sam Kuper]

On Sun, Nov 14, 2021 at 03:14:44PM +0100, infoomatic wrote:
> I am about to migrate our mailservices to FreeBSD + ZFS. Thus, before
> entering the sheer endless  stage of performance testing, I thought I
> would ask here kindly for all kinds of information.
> 
> [..]
> 
> *) storages: any infos on ZFS options [..]

In addition to FreeBSD's excellent handbook, plus of course man-pages,
you may find the following helpful:

https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/

and

https://jrs-s.net/category/open-source/zfs/

especially

https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/

-- 
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.

ZFS storage and backup

[infoomatic]

Hi listmembers,

I am about to migrate our mailservices to FreeBSD + ZFS. Thus, before
entering the sheer endless  stage of performance testing, I thought I
would ask here kindly for all kinds of information.

My setups are nothing special with few users, however, I would like to
have a nice setup, maybe some of you could contribute to this thread. We
are using slow spinning disks, but we may consider using ssds in a
not-so-distant future.

*) storages: any infos on ZFS options or whether to use mdbox or sdbox,
and what configs/options regarding compression etc.

*) backup: what is a best practice regarding backups? - using only the
dovecot tools or leveraging the great features of ZFS (or both) with
snapshots etc.?

Thanks for all sorts of infos, probably saving me quite some time
evaluating different options!

Robert

Re: Strategies for protecting IMAP (e.g. MFA)

[Sam Kuper]

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=1053509936#Security_issues

For portable hardware security tokens with a better security track
record (to my knowledge, anyway), see:

https://en.wikipedia.org/wiki/Nitrokey

https://www.nitrokey.com/


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.

Re: Strategies for protecting IMAP (e.g. MFA)

[Kees van Vloten]

On 14-11-2021 13:56, Marc wrote:

Full access from any IP (except firehol-blacklist and fail2ban) is
possible over VPN (openvpn) with MFA (privacyidea).
Privacyidea also supplies a mobile-app compatible with a.o. TOTP and
HOTP but it provides a more secure way of enrollment (2-step).

How are you managing dns/clients etc so only the email traffic is goes through 
the vpn and no other traffic?


There are different use-cases:

- Mobile(phone) users will use the externally exposed mail-ports, i.e. 
they have access from the geo-ip whitelist. This way the mail-app on the 
phone can be used easily.


- Home or laptop users will use the VPN to get full-access through the 
VPN. I redirect DNS through the VPN (i.e. all queries) but not all other 
traffic (no default gateway change).


- A last case not mentioned earlier is webmail, which is also hidden 
behind privacyidea MFA.


The policy is to use MFA when you first connect to the network from an 
untrusted location, the one exception is mail over 993/465 but instead 
that is limited by blacklists, geo-ip and fail2ban.


- Kees

Re: Strategies for protecting IMAP (e.g. MFA)

[Ralph Seichter]

* 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

RE: Strategies for protecting IMAP (e.g. MFA)

[Marc]

> Full access from any IP (except firehol-blacklist and fail2ban) is
> possible over VPN (openvpn) with MFA (privacyidea).
> Privacyidea also supplies a mobile-app compatible with a.o. TOTP and
> HOTP but it provides a more secure way of enrollment (2-step).

How are you managing dns/clients etc so only the email traffic is goes through 
the vpn and no other traffic?

Strategies for protecting IMAP (e.g. MFA)

[Kees van Vloten]

Apart from a really nice firewall firehol also supplies a good set of 
ip-blacklists.


For public exposure of email ports, I am using the combination of 
firehol-firewall, firehol-blacklist, fail2ban and a whitelist based on 
geo-ip. The mail-client ports exposed are 993 and 465, because starttls 
is considered flawed nowadays: https://nostarttls.secvuln.info/)


Full access from any IP (except firehol-blacklist and fail2ban) is 
possible over VPN (openvpn) with MFA (privacyidea).
Privacyidea also supplies a mobile-app compatible with a.o. TOTP and 
HOTP but it provides a more secure way of enrollment (2-step).


Thanks for pointing at crowdsec.net, will see if it can tighten security 
further in cooperation with the above.


- Kees


On 14-11-2021 11:33, infoomatic wrote:

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?

Re: Strategies for protecting IMAP (e.g. MFA)

[infoomatic]

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?

RE: Strategies for protecting IMAP (e.g. MFA)

[Marc]

>30(?) years ago the majority of systems were using a user name to access mail. 
>Then the 'I want to track everyone companies' made logging in with email the 
>standard that everyone blindly followed. Now decades later the brute forcing 
>of known passwords etc is a problem, mostly because the login is publicly 
>known, so we have to address this with the 2FA preferably giving even more 
>private information about the user like phone number or high school name, pet 
>name etc.

And this is sort of funny because we had 'a simple' 2fa system where the user 
name and password were not publicly known. (at least to me, because scans on my 
servers are 99%(?) email address login attempts)

> 
> why is this funny ?

Re: Strategies for protecting IMAP (e.g. MFA)

[Benny Pedersen]

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

Re: Strategies for protecting IMAP (e.g. MFA)

[André Rodier]

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:* montneyty...@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 > 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

Re: Strategies for protecting IMAP (e.g. MFA)

[William Edwards]

> Op 13 nov. 2021 om 22:17 heeft Tyler Montney  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.

Re: Strategies for protecting IMAP (e.g. MFA)

[pyh]

He suggested we use should alias as public email? but most providers don't
have aliases such as gmail.


On Sun, Nov 14, 2021 at 4:48 PM Benny Pedersen  wrote:

> On 2021-11-14 09:39, Marc wrote:
> > Don't use email addresses as login ;)
>
> why is this funny ?
>

Re: Strategies for protecting IMAP (e.g. MFA)

[Benny Pedersen]

On 2021-11-14 09:39, Marc wrote:

Don't use email addresses as login ;)


why is this funny ?

Re: Strategies for protecting IMAP (e.g. MFA)

[Marc]

Don't use email addresses as login ;)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -.
F1 Outsourcing Development Sp. z o.o.
Poland

t:  +48 (0)12 4207 835
e:  m...@f1-outsourcing.eu