Re: dovecot-lmtp crashing when setting lmtp_proxy=yes
> On 15/07/2021 18:37 Camilo Sperberg wrote: > > > Hi all: > > We are currently in the process of setting up dovecot proxy so that we can > deploy multiple machines in order to keep growing. > > We are trying now to create an entry point, and from there send the traffic > to either the same machine or another node. > For this, we are using a MySQL database with information about which server > hosts which mailboxes, which turns out to be working great for sending out > mail and general authentification. This was really simple to set up, kudos > for that! > > > However, whenever I want to *receive* email, I just have to enable the > lmtp_proxy setting which makes the lmtp process segfault. > > This happens everytime as I can reliable reproduce it + get a stack trace of > it. The process will crash on every incoming email. > > > I have attached: > - Complete output of dovecot-sysreport > - A core dump of the crashed process > > Main information: > Using dovecot v2.3.14 (cee3cbc0d) on Ubuntu 18.04 LTS: Linux 5.4.0-1046-gcp > x86_64 Ubuntu 18.04.5 LTS. Our MTA is postfix. > > Logs around the crashed process: > Jul 15 14:53:21 server postfix/postscreen[19402]: CONNECT from > > > Am I missing something in the conf? Did I encounter a bug? If you need more > information, please let me know. > > Greetings, > Camilo Sperberg > Hi! Try returning port for the LMTP connection in your passdb query. Aki
Re: function for whitelisting IPs
On 15/07/2021 20.03, Gerald Galster wrote: I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. You could do that with fail2ban. eg https://www.the-art-of-web.com/system/fail2ban-action-whitelist/ P.
Re: Sv: 2FA/MFA with IMAP & postfix/submission
I think it's only 12 steps. There are people who need to sober up On July 15, 2021 8:54:16 AM AKDT, Sebastian wrote: >The thing is, that people must stop expecting "being able to access >mail whenever you are" without extra steps. > >Best solution is to offer a webmail with TOTP or SQRL or similiar >secure auth method. > >Then have that webmail adds IP or country into trusted list, so if you >want to access IMAP mail or SMTP mail from hotel wifi, you have to >simply do one single login to webmail, and then your IMAP/SMTP will >work as usual. > >The problem with certificates, is as I said, not many clients support >them. Outlook support them natively, I don't know if Windows Mail >support them, and I don't know if Samsung Mail do support them (maybe >they do support client certificates in Enterprise mode, but then you >need a license for that), K9 mail I know support them, other built-in >email clients I don't know if they support client certificates. > >The solution I have on my email is a OpenVPN connection to my server, >which is protected. My phone has a 24/7 connection to that VPN server, >and thus im able to lock out all logins outside from VPN. > >-Ursprungligt meddelande- >Från: dovecot-boun...@dovecot.org För >@lbutlr >Skickat: den 15 juli 2021 18:37 >Till: dovecot mailing list >Ämne: Re: 2FA/MFA with IMAP & postfix/submission > >On 2021 Jul 15, at 08:52, Alex wrote: >> Client certs appears to be a good solution. > >A solution, certainly. A GOOD solution? Not really. > >> What's the process for managing them with more than a hundred client >accounts? > >And that's the first issue. > >The second issue is "my primary device is not available, I need to >login from this other computer or use my phone which is unsuitable for >this task. Too bad I have no choice but to use the phone because this >computer doesn’t have the cert." > >And then you have the "now that I've installed this cert, theis >computer is considered trusted" which is another issue. > >2FA is a lot more flexible and robust. > >OATH works well. SQRL looks promising though it requires a web UI I to >do the authentication (and SQRL does away with passwords as well). > >> I believe the problem they are trying to solve is hacked accounts >from >> compromised passwords. Does client certs solve that problem? > >Maybe. Depends on if the hacker can get access to the user's machine or >not. > >> Perhaps there are dovecot (and postfix submission) options to at >least >> restrict access by IP? > >It is certainly possible in Postfix, but that opens up its own issues. >It may be acceptable in some corporate environs, but in most situations >being able to access your email wherever you are is a requirement. > >-- >The wages of sin is death, but so is the salary of virtue, and at > least the evil get to go home early on Fridays. --Witches Abroad -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Sv: Sv: function for whitelisting IPs
You can get away with a lot for a personal server that wouldn't be acceptable for a general purpose email server such as the need to move the fence. In my case, I don't allow anything on the email server to be altered with a browser interface. It is either ssh or nothing. Browsers get more complicated as time goes on and security is inversely related to complexity. I use MUAs for all my email. Less is more. I totally get why 2FA is useful. But if you are practicing good security hygiene, the advantage is less than you think. All my passwords are 20 characters randomly generated and unique for everything, not just email. So there is no risk from password reuse. 2FA is really only useful if your personal devices have been breached and the plain text passwords are exposed. So to be totally effective the 2FA should come from a hardware device like a Ubikey or similar. What I have done is to use the 2FA with financial institutions. So I block the hackers where it matters. I can't stop attempts at my accounts being spoofed, but I can stop the hackers where is matters. Use DKIM and hope those getting your email check it. But if there was a friction free means of adding 2FA to email, I would do it. But it would have to be in the MUA and be supported by postfix and dovecot. The OTP code is done. I have played with FreeOTP and associated Linux program to recognize the token. (Name escapes me.) You just need everyone to agree on how to glue it all together. Original Message From: sebast...@sebbe.eu Sent: July 15, 2021 11:26 AM To: dovecot@dovecot.org Reply-to: dovecot@dovecot.org Subject: Sv: Sv: function for whitelisting IPs Yeah the idea was to use roundcube or other web service to add kind of "auth service" or "unlock service" where you can auth with 2FA to move the geofence or permit additional IPs in geofence. For example, if you are travelling or otherwise need to enable your account for a "outsider IP". This could be a simple webpage asking for username and 2FA code, and all it does it adds the IP to auth list. But could be a full roundcube or other webmail solution too, to give more usefullness to the web login solution if you don't have a imap/smtp client for now. I don't use 587 myself, but instead, I have set so auth is only permitted on port 25 for authorized IPs (auth_advertise_hosts in exim), thus the server will refuse to allow outsiders to authenticate. In combination with some other policies, my server is practically rock solid. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För lists Skickat: den 15 juli 2021 20:09 Till: 'Mailing List' Ämne: Re: Sv: function for whitelisting IPs I run a personal email server. I can't emphasize enough how geofencing has reduced the useless hacking on my email server. I only leave port 25 open to the world. I use port 587. I maintain a list of hosting companies that I block from using my web server since they are just going to scrape anyway. I also keep that IP space off of my email other than port 25. Firewalls use memory but tend to be very light on the CPU other than when you first start up the firewall. I assume they take the deny list and create a table in RAM to efficiently block IPs. I have found that dynamic IP blocking programs such as sshguard or fail2ban are a CPU burden since that table needs to be refreshed as new IPs are added or removed so I have stopped using them. Not that the programs themselves are CPU intensive, but they cause the firewall to be CPU intensive. I am considering using sshguard again but with a very high threshold to add an IP to the deny list. Regarding attempts to add 2FA by using RoundCube or similar web based email, I think those programs just increase the attack surface. When I used a hosting service I was hacked by an unpatched exploit in RoundCube. Original Message From: sebast...@sebbe.eu Sent: July 15, 2021 3:55 AM To: dovecot@dovecot.org Reply-to: dovecot@dovecot.org Subject: Sv: function for whitelisting IPs Most such functions would need to be custom. You need to write a custom login script, which also accepts the user's IP as input to a function, which then checks if password is right. And then it returns that password is invalid if IP isn't approved. Then you just need to write some custom functions in roundcube or similiar to have the webmail insert the IP into a database. Or just match it against a GeoIP database and save the latest country the webmail was logged in from, and then SMTP/IMAP is only approved for that country. That reduces the attack surface greatly. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För White, Daniel E. (GSFC-770.0)[NICS] Skickat: den 15 juli 2021 12:21 Till: Dovecot Mailing List Ämne: function for whitelisting IPs Sebastian, Do you have any examples of such a function and how/where it is used ? -Original Message- From: dovecot on behal
Re: Sv: 2FA/MFA with IMAP & postfix/submission
> Perhaps there are dovecot (and postfix submission) options to at least > restrict access by IP? Restricting by IP is soon going to become very tedious, especially if you are dealing with more than a small number of users, and especially once post-COVID travel comes back and people start connecting from random hotels and airport lounges. If you don't fancy the idea of client certs, the alternative I would suggest instead of IP limiting would be a Wireguard VPN instead of IP limiting. Wireguard VPN servers run very quiet and won't respond to anything unless a client sends the right parameters. Of course the downside of a VPN compared to certificates is that the user will have to be aware and know how to manage a VPN, whilst with certificates it can all be quietly done in the background.
Re: Sv: 2FA/MFA with IMAP & postfix/submission
> Client certs appears to be a good solution. > > What's the process for managing them with more than a hundred client accounts? If you've got the budget ... MDM. If you don't, you can probably hack together some sort of self-service system. > > I believe the problem they are trying to solve is hacked accounts from > > compromised passwords. Does client certs solve that problem? > Well yes. If you make client certs mandatory, unless the client can present a valid cert, the server will kill the connection before the client has a chance to try out a compromised password.
Re: function for whitelisting IPs
> I run a personal email server. I can't emphasize enough how geofencing has > reduced the useless hacking on my email server. I only leave port 25 open to > the world. I use port 587. Unfortunately that's not an option for commercial mailservers. You have to be open to communicate with the world. Geofencing might be inaccurate. Often this data is extracted from ip-net registrations - the country where the company resides that registered that net might not be where the servers are located. There are services like maxmind that are more accurate but are not free. > Firewalls use memory but tend to be very light on the CPU other than when you > first start up the firewall. I assume they take the deny list and create a > table in RAM to efficiently block IPs. I have found that This depends on how your firewall works. A standard linux firewall processes iptables rules one after another. With a lot of rules and high traffic this can cause very high cpu usage. In case you're using ipsets (like a hashmap) that is not the case. There's also a difference if you block single ips or whole subnets. > dynamic IP blocking programs such as sshguard or fail2ban are a CPU burden > since that table needs to be refreshed as new IPs are added or removed so I > have stopped using them. Not that the programs themselves are CPU intensive, > but they cause the firewall to be CPU intensive. I am considering using > sshguard again but with a very high threshold to add an IP to the deny list. It's not that cpu intensive when using ipsets. On the other hand fail2ban itself uses quite some cpu and memory (sqlite databases can get large). I haven't been using fail2ban because of that, so I don't know if the situation has improved. > Regarding attempts to add 2FA by using RoundCube or similar web based email, > I think those programs just increase the attack surface. When I used a > hosting service I was hacked by an unpatched exploit in RoundCube. Programs like fail2ban do not increase the attack surface under normal circumstances. They just scan logs and add firewall rules, which does not cost very much when using ipsets. I'm very interested which roundcube bug that was, using roundcube myself. Can you have a look at the cve list, please: https://www.cvedetails.com/vulnerability-list/vendor_id-8905/Roundcube.html Best regards Gerald
Sv: Sv: function for whitelisting IPs
Yeah the idea was to use roundcube or other web service to add kind of "auth service" or "unlock service" where you can auth with 2FA to move the geofence or permit additional IPs in geofence. For example, if you are travelling or otherwise need to enable your account for a "outsider IP". This could be a simple webpage asking for username and 2FA code, and all it does it adds the IP to auth list. But could be a full roundcube or other webmail solution too, to give more usefullness to the web login solution if you don't have a imap/smtp client for now. I don't use 587 myself, but instead, I have set so auth is only permitted on port 25 for authorized IPs (auth_advertise_hosts in exim), thus the server will refuse to allow outsiders to authenticate. In combination with some other policies, my server is practically rock solid. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För lists Skickat: den 15 juli 2021 20:09 Till: 'Mailing List' Ämne: Re: Sv: function for whitelisting IPs I run a personal email server. I can't emphasize enough how geofencing has reduced the useless hacking on my email server. I only leave port 25 open to the world. I use port 587. I maintain a list of hosting companies that I block from using my web server since they are just going to scrape anyway. I also keep that IP space off of my email other than port 25. Firewalls use memory but tend to be very light on the CPU other than when you first start up the firewall. I assume they take the deny list and create a table in RAM to efficiently block IPs. I have found that dynamic IP blocking programs such as sshguard or fail2ban are a CPU burden since that table needs to be refreshed as new IPs are added or removed so I have stopped using them. Not that the programs themselves are CPU intensive, but they cause the firewall to be CPU intensive. I am considering using sshguard again but with a very high threshold to add an IP to the deny list. Regarding attempts to add 2FA by using RoundCube or similar web based email, I think those programs just increase the attack surface. When I used a hosting service I was hacked by an unpatched exploit in RoundCube. Original Message From: sebast...@sebbe.eu Sent: July 15, 2021 3:55 AM To: dovecot@dovecot.org Reply-to: dovecot@dovecot.org Subject: Sv: function for whitelisting IPs Most such functions would need to be custom. You need to write a custom login script, which also accepts the user's IP as input to a function, which then checks if password is right. And then it returns that password is invalid if IP isn't approved. Then you just need to write some custom functions in roundcube or similiar to have the webmail insert the IP into a database. Or just match it against a GeoIP database and save the latest country the webmail was logged in from, and then SMTP/IMAP is only approved for that country. That reduces the attack surface greatly. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För White, Daniel E. (GSFC-770.0)[NICS] Skickat: den 15 juli 2021 12:21 Till: Dovecot Mailing List Ämne: function for whitelisting IPs Sebastian, Do you have any examples of such a function and how/where it is used ? -Original Message- From: dovecot on behalf of Sebastian Reply-To: Dovecot Mailing List Date: Thursday, July 15, 2021 at 01:19 To: 'Mailing List' Subject: [EXTERNAL] Sv: 2FA/MFA with IMAP & postfix/submission Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection. So no, it cannot be relied upon. I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP. When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not. The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot@dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail. Are there multi-fact
Re: Sv: function for whitelisting IPs
I have found that dynamic IP blocking programs such as sshguard or fail2ban are a CPU burden since that table needs to be refreshed as new IPs are added or removed so I have stopped using them. Have you seen ipset? https://ipset.netfilter.org/ It is built for dynamically adding/remove IP's from a firewall without changing a table or rules or reloading the firewall. It holds a hashmap in memory of what IP's to block and integrates into the kernel. However you have to build your own mouse trap to use it. I don't know of anything out of the box that would automatically add IP's to it, i wrote my own script that gets fed log lines from rsyslog to do it.
Re: Sv: function for whitelisting IPs
I run a personal email server. I can't emphasize enough how geofencing has reduced the useless hacking on my email server. I only leave port 25 open to the world. I use port 587. I maintain a list of hosting companies that I block from using my web server since they are just going to scrape anyway. I also keep that IP space off of my email other than port 25. Firewalls use memory but tend to be very light on the CPU other than when you first start up the firewall. I assume they take the deny list and create a table in RAM to efficiently block IPs. I have found that dynamic IP blocking programs such as sshguard or fail2ban are a CPU burden since that table needs to be refreshed as new IPs are added or removed so I have stopped using them. Not that the programs themselves are CPU intensive, but they cause the firewall to be CPU intensive. I am considering using sshguard again but with a very high threshold to add an IP to the deny list. Regarding attempts to add 2FA by using RoundCube or similar web based email, I think those programs just increase the attack surface. When I used a hosting service I was hacked by an unpatched exploit in RoundCube. Original Message From: sebast...@sebbe.eu Sent: July 15, 2021 3:55 AM To: dovecot@dovecot.org Reply-to: dovecot@dovecot.org Subject: Sv: function for whitelisting IPs Most such functions would need to be custom. You need to write a custom login script, which also accepts the user's IP as input to a function, which then checks if password is right. And then it returns that password is invalid if IP isn't approved. Then you just need to write some custom functions in roundcube or similiar to have the webmail insert the IP into a database. Or just match it against a GeoIP database and save the latest country the webmail was logged in from, and then SMTP/IMAP is only approved for that country. That reduces the attack surface greatly. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För White, Daniel E. (GSFC-770.0)[NICS] Skickat: den 15 juli 2021 12:21 Till: Dovecot Mailing List Ämne: function for whitelisting IPs Sebastian, Do you have any examples of such a function and how/where it is used ? -Original Message- From: dovecot on behalf of Sebastian Reply-To: Dovecot Mailing List Date: Thursday, July 15, 2021 at 01:19 To: 'Mailing List' Subject: [EXTERNAL] Sv: 2FA/MFA with IMAP & postfix/submission Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection. So no, it cannot be relied upon. I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP. When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not. The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot@dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail. Are there multi-factor options available? If it is not available, do you have any recommendations on where I should look to do this? All of the links related to this topic appear to be very old, or limited to Linux PAM users.
Re: Sv: 2FA/MFA with IMAP & postfix/submission
Quoting Benny Pedersen : On 2021-07-15 16:49, Alex wrote: What about something like what we used to do with pop-b4-smtp to at least restrict by IP address? no, pop was not handle million of users share one single nat ip, weekforce cant handle that either, so allow_net cant do any better there Well no, but I thought the problem to be solved was 'prevent compromised credentials from abusing SMTP'. Certs do that, but with high overhead. OTOH, going off Alex's suggestion, you could tie the IMAP or POP Auth into an iptables rule that allows that IP to use SMTP for x minutes. Basically, the opposite of fail2ban - 'auth2allow' :) You could probably use fail2ban, just adjust the log regex's and the action appled. The odds of an abuser coming from the same IP are pretty slim, and if the system itself is compromised, they're going to have the cert anyways. In my experience, most clients do SMTP after the POP or IMAP check.. I'd expect issues to be minimal. Rick
Sv: 2FA/MFA with IMAP & postfix/submission
The thing is, that people must stop expecting "being able to access mail whenever you are" without extra steps. Best solution is to offer a webmail with TOTP or SQRL or similiar secure auth method. Then have that webmail adds IP or country into trusted list, so if you want to access IMAP mail or SMTP mail from hotel wifi, you have to simply do one single login to webmail, and then your IMAP/SMTP will work as usual. The problem with certificates, is as I said, not many clients support them. Outlook support them natively, I don't know if Windows Mail support them, and I don't know if Samsung Mail do support them (maybe they do support client certificates in Enterprise mode, but then you need a license for that), K9 mail I know support them, other built-in email clients I don't know if they support client certificates. The solution I have on my email is a OpenVPN connection to my server, which is protected. My phone has a 24/7 connection to that VPN server, and thus im able to lock out all logins outside from VPN. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För @lbutlr Skickat: den 15 juli 2021 18:37 Till: dovecot mailing list Ämne: Re: 2FA/MFA with IMAP & postfix/submission On 2021 Jul 15, at 08:52, Alex wrote: > Client certs appears to be a good solution. A solution, certainly. A GOOD solution? Not really. > What's the process for managing them with more than a hundred client accounts? And that's the first issue. The second issue is "my primary device is not available, I need to login from this other computer or use my phone which is unsuitable for this task. Too bad I have no choice but to use the phone because this computer doesn’t have the cert." And then you have the "now that I've installed this cert, theis computer is considered trusted" which is another issue. 2FA is a lot more flexible and robust. OATH works well. SQRL looks promising though it requires a web UI I to do the authentication (and SQRL does away with passwords as well). > I believe the problem they are trying to solve is hacked accounts from > compromised passwords. Does client certs solve that problem? Maybe. Depends on if the hacker can get access to the user's machine or not. > Perhaps there are dovecot (and postfix submission) options to at least > restrict access by IP? It is certainly possible in Postfix, but that opens up its own issues. It may be acceptable in some corporate environs, but in most situations being able to access your email wherever you are is a requirement. -- The wages of sin is death, but so is the salary of virtue, and at least the evil get to go home early on Fridays. --Witches Abroad smime.p7s Description: S/MIME Cryptographic Signature
Re: Sv: 2FA/MFA with IMAP & postfix/submission
On 2021-07-15 16:49, Alex wrote: What about something like what we used to do with pop-b4-smtp to at least restrict by IP address? no, pop was not handle million of users share one single nat ip, weekforce cant handle that either, so allow_net cant do any better there all i think is possible is to make 2fa updated with users login to weekforce, and thats it, then weekforce can do the allow_net with that login, there mail/mua still is just enforeced with allow_nets only all should be pretty simple for all kind of mail programs not knowing how to use oauth2 or 2fa then who will make the weekforce policy server for exact that ?, i am willing to test it, but not code it
Re: 2FA/MFA with IMAP & postfix/submission
On 2021 Jul 15, at 08:52, Alex wrote: > Client certs appears to be a good solution. A solution, certainly. A GOOD solution? Not really. > What's the process for managing them with more than a hundred client accounts? And that's the first issue. The second issue is "my primary device is not available, I need to login from this other computer or use my phone which is unsuitable for this task. Too bad I have no choice but to use the phone because this computer doesn’t have the cert." And then you have the "now that I've installed this cert, theis computer is considered trusted" which is another issue. 2FA is a lot more flexible and robust. OATH works well. SQRL looks promising though it requires a web UI I to do the authentication (and SQRL does away with passwords as well). > I believe the problem they are trying to solve is hacked accounts from > compromised passwords. Does client certs solve that problem? Maybe. Depends on if the hacker can get access to the user's machine or not. > Perhaps there are dovecot (and postfix submission) options to at least > restrict access by IP? It is certainly possible in Postfix, but that opens up its own issues. It may be acceptable in some corporate environs, but in most situations being able to access your email wherever you are is a requirement. -- The wages of sin is death, but so is the salary of virtue, and at least the evil get to go home early on Fridays. --Witches Abroad
Re: Sv: 2FA/MFA with IMAP & postfix/submission
Problem is that not many client support it - especially mobile ones.So wireguard VPN is the way to go, much simpler for the users. Originalmeddelande Från: Rick Romero Datum: 2021-07-15 17:04 (GMT+01:00) Till: dovecot@dovecot.org Ämne: Re: Sv: 2FA/MFA with IMAP & postfix/submission Quoting Alex : Hi, Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs. If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords. Client certs appears to be a good solution. What's the process for managing them with more than a hundred client accounts? I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem? Client certs would solve that - but you'll need some management around it (creation/deployment/renewal/device changes/etc). The easiest method is to run MDM and PKI infrastructure, but with 100 clients I kinda doubt that's in place and I wonder if they have the budget for it. Another option, not open source, but if you engage Recorded Future, you can get a report and notifications of password compromises, and then take action on that info (ie, force affected user to change password). Alternatively, and free, don't use the email address as the username for authenticaiton, use some other generic ID. Rick smime.p7s Description: S/MIME Cryptographic Signature
Re: Sv: 2FA/MFA with IMAP & postfix/submission
On 2021-07-15 8:07 a.m., Laura Smith wrote:
Perhaps there are dovecot (and postfix submission) options to at least restrict
access by IP?
Restricting by IP is soon going to become very tedious, especially if you are
dealing with more than a small number of users, and especially once post-COVID
travel comes back and people start connecting from random hotels and airport
lounges.
If you don't fancy the idea of client certs, the alternative I would suggest
instead of IP limiting would be a Wireguard VPN instead of IP limiting.
Wireguard VPN servers run very quiet and won't respond to anything unless a
client sends the right parameters.
Of course the downside of a VPN compared to certificates is that the user will
have to be aware and know how to manage a VPN, whilst with certificates it can
all be quietly done in the background.
And of course, you can always do..
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 }
Pick your favourite RBL's.. And do suggest that based on our threat
teams' research, block AUTH from many of the cloud providers IP Space,
several RBL's out there make it easy..
And/or, you can create your own lists, Amazon/Google/Azure all list
their IP space publicly..
Just remember, use your own DNS servers, or upstream DNS servers, and
NOT open resolvers such as Google's 8.8.8.8, as most RBL's block queries
from those..
--
"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: 2FA/MFA with IMAP & postfix/submission
On 2021-07-15 7:54 a.m., Laura Smith wrote: Are there multi-factor options available? Mandating good old-fashioned client-certificates is most likely your best bet in terms of delivering the best user-experience. Or, you can use the CLIENT_ID SMTP extension for dovecot/postfix.. For the record, still seeing 50-1 attempts against SMTP AUTH vs IMAP/POP AUTH attacks.. Completely transparent to the user.. Still need to see upstream implement the variable capabilities patch.. so that plugins can modify it.. But reach out if you want more details.. -- "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: Sv: 2FA/MFA with IMAP & postfix/submission
Quoting Alex : Hi, Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs. If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords. Client certs appears to be a good solution. What's the process for managing them with more than a hundred client accounts? I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem? Client certs would solve that - but you'll need some management around it (creation/deployment/renewal/device changes/etc). The easiest method is to run MDM and PKI infrastructure, but with 100 clients I kinda doubt that's in place and I wonder if they have the budget for it. Another option, not open source, but if you engage Recorded Future, you can get a report and notifications of password compromises, and then take action on that info (ie, force affected user to change password). Alternatively, and free, don't use the email address as the username for authenticaiton, use some other generic ID. Rick
Re: 2FA/MFA with IMAP & postfix/submission
> Are there multi-factor options available? Mandating good old-fashioned client-certificates is most likely your best bet in terms of delivering the best user-experience.
Re: Sv: 2FA/MFA with IMAP & postfix/submission
Hi, > Unfortunately the best way to do multifactor authentication today is to use > OAUTH2, which isn't currently supported for own installations. Or you can use > client certs. > > If you want to use some kind of MFA with tokens, you end up having to feed > your token all the time. So the best option, for now, is device passwords. Client certs appears to be a good solution. What's the process for managing them with more than a hundred client accounts? I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem? Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
Re: Sv: 2FA/MFA with IMAP & postfix/submission
Hi, > > Unfortunately the best way to do multifactor authentication today is > > to use OAUTH2, which isn't currently supported for own installations. > > Or you can use client certs. > > > > If you want to use some kind of MFA with tokens, you end up having to > > feed your token all the time. So the best option, for now, is device > > passwords. > > speculating :=) > > weekforce policy server with 2fa, that just update allow_nets in dovecot > user dict table, so all dovecot do is to check allow nets pr user from > dict, i dont know if that is possible so imap / pop3 / lmtp and other > service in dovecot dont need to mess with oauth2 or other complicated > login system not supported everywhere Yeah, I'm not sure we can use something that appears to be so experimental. What about client certs? Wouldn't that solve the problem? Does Outlook for Windows include any type of MFA? It appears inextricably linked to Office 365. What about something like what we used to do with pop-b4-smtp to at least restrict by IP address?
Re: AW: TLS Security
https://testssl.sh/
Aki
> On 15/07/2021 16:51 Stefan Schumacher wrote:
>
>
> Hi Aki,
>
>
> Where do I get testssh.sl? If the script is of your design could you mail it
> to me?
>
>
> Yours
> Stefan
>
> --
> Von: Aki Tuomi
> Gesendet: Mittwoch, 14. Juli 2021 19:34
> An: Stefan Schumacher ; dovecot@dovecot.org
>
> Betreff: Re: TLS Security
>
> > On 14/07/2021 17:55 Stefan Schumacher
> wrote:
> >
> >
> > Hi,
> >
> >
> > I wish to build a new secure email server. It seems I am on the right way
> – at least I get no more error messages for Postfix – but Dovecot is still
> making trouble.
> >
> >
> > I am using Dovecot 1:2.3.4.1-5+deb10u6 and I am using ISPconfig 3.25 to do
> the rough configuring and nano and whats left of my brain to do the finer
> details. Lets start with what I added to conf.d/10-ssl.conf
> >
> >
> > ssl_cert = > ssl_key = >
> >
> > ssl_cipher_list =
> EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aR$
> > ssl_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
> > ssl_min_protocol = TLSv1.2
> >
> >
> > As you can see, I clearly do not want to use TLS before v1.2. I think this
> is not unreasonable in the year 2021.
> >
> >
> > Now, after the changes I ran Kali (I use it to verify the results of my
> experiments)
> > and - this is a mailing list, so no screenshots:
> > It says:
> >
> >
> > SSL/TLS Deprecated TLS v1.0 and TLS v1.1 Detection. I get this for the
> ports 143, 110, 993 and 995.
> >
> >
> > I thought I had done everything one could to disable old TLS-Versions.
> What am I doing wrong?
> >
> >
> > Yours sincerely
> > Stefan Schumacher
> >
> >
>
> Hi!
>
> First of all, 2.3.4.1 is bit old, and has no proper support for TLSv1.3,
> which is supported better on a later version. Now, I installed 2.3.4.1 from
> debian 10, and tested with testssl.sh and got
>
> SSLv2 not offered (OK)
> SSLv3 not offered (OK)
> TLS 1 not offered
> TLS 1.1 not offered
> TLS 1.2 offered (OK)
> TLS 1.3 offered (OK): final
> NPN/SPDY not offered
> ALPN/HTTP2 not offered
>
> TLSv1.2 (no server order, thus listed by strength)
> xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> xc028 ECDHE-RSA-AES256-SHA384 ECDH 521 AES 256
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 521 ChaCha20 256
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> xc077 ECDHE-RSA-CAMELLIA256-SHA384 ECDH 521 Camellia 256
> TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
> xc061 ECDHE-ARIA256-GCM-SHA384 ECDH 521 ARIAGCM 256
> TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
> xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> xc027 ECDHE-RSA-AES128-SHA256 ECDH 521 AES 128
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> xc076 ECDHE-RSA-CAMELLIA128-SHA256 ECDH 521 Camellia 128
> TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
> xc060 ECDHE-ARIA128-GCM-SHA256 ECDH 521 ARIAGCM 128
> TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256
> TLSv1.3 (no server order, thus listed by strength)
> x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384
> x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256
> TLS_CHACHA20_POLY1305_SHA256
> x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256
>
> I used:
>
> listen = *
> mail_attribute_dict = file:%h/Mail/dovecot-attributes
> mail_gid = vmail
> mail_home = /home/vmail/%Lu
> mail_location = sdbox:~/Mail
> mail_uid = vmail
> passdb {
> args = password=#hidden_use-P_to_show#
> driver = static
> }
> protocols = imap
> ssl_cert = ssl_cipher_list =
> EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA
> ssl_dh = # hidden, use -P to show it
> ssl_key = # hidden, use -P to show it
> ssl_min_protocol = TLSv1.2
>
> Aki
>
AW: TLS Security
Hi Aki,
Where do I get testssh.sl? If the script is of your design could you mail it to
me?
Yours
Stefan
Von: Aki Tuomi
Gesendet: Mittwoch, 14. Juli 2021 19:34
An: Stefan Schumacher ; dovecot@dovecot.org
Betreff: Re: TLS Security
> On 14/07/2021 17:55 Stefan Schumacher wrote:
>
>
> Hi,
>
>
> I wish to build a new secure email server. It seems I am on the right way –
> at least I get no more error messages for Postfix – but Dovecot is still
> making trouble.
>
>
> I am using Dovecot 1:2.3.4.1-5+deb10u6 and I am using ISPconfig 3.25 to do
> the rough configuring and nano and whats left of my brain to do the finer
> details. Lets start with what I added to conf.d/10-ssl.conf
>
>
> ssl_cert = ssl_key =
>
> ssl_cipher_list =
> EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aR$
> ssl_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
> ssl_min_protocol = TLSv1.2
>
>
> As you can see, I clearly do not want to use TLS before v1.2. I think this is
> not unreasonable in the year 2021.
>
>
> Now, after the changes I ran Kali (I use it to verify the results of my
> experiments)
> and - this is a mailing list, so no screenshots:
> It says:
>
>
> SSL/TLS Deprecated TLS v1.0 and TLS v1.1 Detection. I get this for the ports
> 143, 110, 993 and 995.
>
>
> I thought I had done everything one could to disable old TLS-Versions. What
> am I doing wrong?
>
>
> Yours sincerely
> Stefan Schumacher
>
>
Hi!
First of all, 2.3.4.1 is bit old, and has no proper support for TLSv1.3, which
is supported better on a later version. Now, I installed 2.3.4.1 from debian
10, and tested with testssl.sh and got
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 not offered
TLS 1.1not offered
TLS 1.2offered (OK)
TLS 1.3offered (OK): final
NPN/SPDY not offered
ALPN/HTTP2 not offered
TLSv1.2 (no server order, thus listed by strength)
xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 521 AESGCM 256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
xc028 ECDHE-RSA-AES256-SHA384 ECDH 521 AES 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
xc014 ECDHE-RSA-AES256-SHA ECDH 521 AES 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 521 ChaCha20256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
xc077 ECDHE-RSA-CAMELLIA256-SHA384 ECDH 521 Camellia256
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
xc061 ECDHE-ARIA256-GCM-SHA384 ECDH 521 ARIAGCM 256
TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 521 AESGCM 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
xc027 ECDHE-RSA-AES128-SHA256 ECDH 521 AES 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
xc013 ECDHE-RSA-AES128-SHA ECDH 521 AES 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
xc076 ECDHE-RSA-CAMELLIA128-SHA256 ECDH 521 Camellia128
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
xc060 ECDHE-ARIA128-GCM-SHA256 ECDH 521 ARIAGCM 128
TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256
TLSv1.3 (no server order, thus listed by strength)
x1302 TLS_AES_256_GCM_SHA384ECDH 253 AESGCM 256
TLS_AES_256_GCM_SHA384
x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20256
TLS_CHACHA20_POLY1305_SHA256
x1301 TLS_AES_128_GCM_SHA256ECDH 253 AESGCM 128
TLS_AES_128_GCM_SHA256
I used:
listen = *
mail_attribute_dict = file:%h/Mail/dovecot-attributes
mail_gid = vmail
mail_home = /home/vmail/%Lu
mail_location = sdbox:~/Mail
mail_uid = vmail
passdb {
args = password=#hidden_use-P_to_show#
driver = static
}
protocols = imap
ssl_cert =
AW: TLS Security
Hi Justina,
Kali tools is of course extremly unprecise. Excuse me, I had a long stressful
day and wanted to get this out before the end of the Day. Kali is a rolling
release, which I update regularly. By Kali Tools I of course meant the
Greenbone Community Edition, of which the former and more well-known OpenVAS is
now only one possibly multiple scanners.
The mailserver itself is based on Debian which currently 10.10 (11.0 is going
to be released in a few days). I upgraded the dovecot components from backports
but this caused no change. I am currently considering getting the Bullseye RC2
and then testing on it but I am of course open for any other suggestions. Maybe
someone with more knowledge of postfix can add or point out advisable changes
to these settings.
Yours sincerely
Stefan
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_eecdh_grade = strong
smtpd_tls_protocols= !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols= !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level=may
smtpd_tls_ciphers = high
tls_preempt_cipherlist = yes
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , DES, ADH, RC4, PSD, SRP,
3DES, eNULL
smtpd_tls_exclude_ciphers = aNULL, MD5 , DES, ADH, RC4, PSD, SRP, 3DES, eNULL
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
Von: justina colmena ~biz
Gesendet: Mittwoch, 14. Juli 2021 18:50
An: dovecot@dovecot.org ; Stefan Schumacher
Betreff: Re: TLS Security
Interesting.
Assuming your "Kali" tools are in fact up to date to test with newer protocols
TLS1.2+, is Dovecot compiled against a recent version of the OpenSSL or GnuTLS
library or whatever it uses to support the newer TLS protocols?
Definitely an outdated cipher issue, on Postfix as well as Dovecot
On July 14, 2021 6:55:19 AM AKDT, Stefan Schumacher
wrote:
Hi,
I wish to build a new secure email server. It seems I am on the right way – at
least I get no more error messages for Postfix – but Dovecot is still making
trouble.
I am using Dovecot 1:2.3.4.1-5+deb10u6 and I am using ISPconfig 3.25 to do the
rough configuring and nano and whats left of my brain to do the finer details.
Lets start with what I added to conf.d/10-ssl.conf
ssl_cert =
AW: TLS Security
Hi Justina,
Kali tools is of course extremly unprecise. Excuse me, I had a long stressful
day and wanted to get this out before the end of the Day. Kali is a rolling
release and I keep it up to date by upgrading every few days. I also update the
feeds. What I actually use for security scans is the former OpenVAS, which now
has been relegated to being a part of the Community Edition of the Greenbone
suite. You have seen the values I have in Dovecot. What follows now are my
settings in the postfix main.cf. As you can clearly see it, it should prevent
connections from TLS below 1.2. Dovecot is of course not very fresh because
it's Debian 10 and Debian 11 is just around the corner (a few days). These are
the settings of my postfix main.cf. I am very tempted to grab an Image of
Debian 11 and install ISPConfig and my Dovecot and Postfix settings there. I am
of course open to any other suggestions. A the moment I consider to install a
new Bullseye RC2 and then put my configuration on it. I am of course open for
any other suggestions.
Yours sincerely
Stefan
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_eecdh_grade = strong
smtpd_tls_protocols= !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols= !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level=may
smtpd_tls_ciphers = high
tls_preempt_cipherlist = yes
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , DES, ADH, RC4, PSD, SRP,
3DES, eNULL
smtpd_tls_exclude_ciphers = aNULL, MD5 , DES, ADH, RC4, PSD, SRP, 3DES, eNULL
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
Von: justina colmena ~biz
Gesendet: Mittwoch, 14. Juli 2021 18:50
An: dovecot@dovecot.org ; Stefan Schumacher
Betreff: Re: TLS Security
Interesting.
Assuming your "Kali" tools are in fact up to date to test with newer protocols
TLS1.2+, is Dovecot compiled against a recent version of the OpenSSL or GnuTLS
library or whatever it uses to support the newer TLS protocols?
Definitely an outdated cipher issue, on Postfix as well as Dovecot
On July 14, 2021 6:55:19 AM AKDT, Stefan Schumacher
wrote:
Hi,
I wish to build a new secure email server. It seems I am on the right way – at
least I get no more error messages for Postfix – but Dovecot is still making
trouble.
I am using Dovecot 1:2.3.4.1-5+deb10u6 and I am using ISPconfig 3.25 to do the
rough configuring and nano and whats left of my brain to do the finer details.
Lets start with what I added to conf.d/10-ssl.conf
ssl_cert =
Re: Sv: 2FA/MFA with IMAP & postfix/submission
On 2021-07-15 07:26, Aki Tuomi wrote: Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs. If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords. speculating :=) weekforce policy server with 2fa, that just update allow_nets in dovecot user dict table, so all dovecot do is to check allow nets pr user from dict, i dont know if that is possible so imap / pop3 / lmtp and other service in dovecot dont need to mess with oauth2 or other complicated login system not supported everywhere hope to see more stable security in dovecot with this, and certenly hope weekforce is not the only opensoure solution that is half dokumented :/ currently i just use ip2location in shorewall with asn numbers where i have known custommers, i got tired of blacklist random ips, bad idea hackers just could use another ip for free no more fails here, it just remain to update microsoft servers with use port 465, 587, 993 without know passwords, who did dokument that ports is password less, shame on them
Re: function for whitelisting IPs
> Do you have any examples of such a function and how/where it is used ? >I have a better idea: >Have a function for whitelisting IPs, possible /24's or similiar, where a > login to roundcube or other webmail client (with 2FA) will add the IP onto a > whitelist for that account. For some it might be sufficient to just return the allow_nets field: https://doc.dovecot.org/configuration_manual/authentication/allow_nets/ Best regards Gerald
Re: [EXTERNAL] Sv: function for whitelisting IPs
On 15/07/2021 12:05, White, Daniel E. (GSFC-770.0)[NICS] wrote: The custom login script -- in Dovecot or Roundcube or … ? Is there any documentation for such scripting ? https://doc.dovecot.org/configuration_manual/authentication/auth_policy/ It uses an http interface so it is easy to implement with existing http toolkits. I wrote my own policy server in Java Jakarta EE9 because I can. You might prefer an existing policy server or write your own in your favourite http implementation language.
Re: [EXTERNAL] Sv: function for whitelisting IPs
The custom login script -- in Dovecot or Roundcube or … ? Is there any documentation for such scripting ? -Original Message- From: dovecot on behalf of Sebastian Reply-To: Dovecot Mailing List Date: Thursday, July 15, 2021 at 06:56 To: 'Mailing List' Subject: [EXTERNAL] Sv: function for whitelisting IPs Most such functions would need to be custom. You need to write a custom login script, which also accepts the user's IP as input to a function, which then checks if password is right. And then it returns that password is invalid if IP isn't approved. Then you just need to write some custom functions in roundcube or similiar to have the webmail insert the IP into a database. Or just match it against a GeoIP database and save the latest country the webmail was logged in from, and then SMTP/IMAP is only approved for that country. That reduces the attack surface greatly. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För White, Daniel E. (GSFC-770.0)[NICS] Skickat: den 15 juli 2021 12:21 Till: Dovecot Mailing List Ämne: function for whitelisting IPs Sebastian, Do you have any examples of such a function and how/where it is used ? -Original Message- From: dovecot on behalf of Sebastian Reply-To: Dovecot Mailing List Date: Thursday, July 15, 2021 at 01:19 To: 'Mailing List' Subject: [EXTERNAL] Sv: 2FA/MFA with IMAP & postfix/submission Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection. So no, it cannot be relied upon. I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP. When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not. The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot@dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail. Are there multi-factor options available? If it is not available, do you have any recommendations on where I should look to do this? All of the links related to this topic appear to be very old, or limited to Linux PAM users.
Sv: function for whitelisting IPs
Most such functions would need to be custom. You need to write a custom login script, which also accepts the user's IP as input to a function, which then checks if password is right. And then it returns that password is invalid if IP isn't approved. Then you just need to write some custom functions in roundcube or similiar to have the webmail insert the IP into a database. Or just match it against a GeoIP database and save the latest country the webmail was logged in from, and then SMTP/IMAP is only approved for that country. That reduces the attack surface greatly. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För White, Daniel E. (GSFC-770.0)[NICS] Skickat: den 15 juli 2021 12:21 Till: Dovecot Mailing List Ämne: function for whitelisting IPs Sebastian, Do you have any examples of such a function and how/where it is used ? -Original Message- From: dovecot on behalf of Sebastian Reply-To: Dovecot Mailing List Date: Thursday, July 15, 2021 at 01:19 To: 'Mailing List' Subject: [EXTERNAL] Sv: 2FA/MFA with IMAP & postfix/submission Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection. So no, it cannot be relied upon. I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP. When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not. The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot@dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail. Are there multi-factor options available? If it is not available, do you have any recommendations on where I should look to do this? All of the links related to this topic appear to be very old, or limited to Linux PAM users. smime.p7s Description: S/MIME Cryptographic Signature
function for whitelisting IPs
Sebastian, Do you have any examples of such a function and how/where it is used ? -Original Message- From: dovecot on behalf of Sebastian Reply-To: Dovecot Mailing List Date: Thursday, July 15, 2021 at 01:19 To: 'Mailing List' Subject: [EXTERNAL] Sv: 2FA/MFA with IMAP & postfix/submission Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection. So no, it cannot be relied upon. I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP. When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not. The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot@dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail. Are there multi-factor options available? If it is not available, do you have any recommendations on where I should look to do this? All of the links related to this topic appear to be very old, or limited to Linux PAM users.
Re: Verifying replication
> > > I'm trying to get some more confidence as to whether replication is > actually working properly and whether I'm not missing anything that will > burn me if I ever have to 'fallback'. Has anyone ever done some > verification outside of simply watching doveadm replication stats, to see > if they are missing anything ? > For anyone who needs this in the future, the approach I came up with was to count messages and compare sizes for each account. Won't protect me against data corruption but gives me reasonable confidence that the sync is working. Two server scripts: list-users.sh: #!/bin/bash doveadm user "*" get-mailbox-hashes.sh: #!/bin/bash while read account; do echo "$account $(doveadm -f flow fetch -u "$account" "mailbox-guid uid size.virtual" ALL|sort|md5sum)" done and a script that drives this, looping until the list of differing accounts is back to 0 #!/bin/bash PRIMARY=$1 FALLBACK=$2 echo "$(date +%H:%M:%S) Requesting initial userlist" ssh $PRIMARY /opt/container/list-users.sh | sort | tee /tmp/initialuserlist > /tmp/userlist while true; do NUMENTRIES=$(echo $(cat /tmp/userlist|wc -l)) echo "$(date +%H:%M:%S) Userlist is now $NUMENTRIES entries long (see /tmp/userlist)" if [ "$NUMENTRIES" == "0" ]; then echo "$(date +%H:%M:%S) DONE! All are (finally?) in sync" exit 0 fi echo "$(date +%H:%M:%S) Hashing users..." cat /tmp/userlist | ssh $PRIMARY /opt/container/get-mailbox-hashes.sh | sort > /tmp/accounthashes-primary & cat /tmp/userlist | ssh $FALLBACK /opt/container/get-mailbox-hashes.sh | sort > /tmp/accounthashes-fallback & wait %1 %2 echo "$(date +%H:%M:%S) Comparing users..." comm -3 /tmp/accounthashes-primary /tmp/accounthashes-fallback|sed -e 's/^\t*//'|cut -d' ' -f1|sort -u> /tmp/userlist done
Forcing replication - difference is a 0x0D 0x0D 0xA sequence?
I've found a few mailboxes on my system that were being replicated where the mailboxes are not in sync. On server 1 I see: dovecot1:/# doveadm fetch -u s000 "size.physical size.virtual" mailbox-guid c92f64f79f0d1ed01e6d5b314f04886c uid 115 size.physical: 1815 size.virtual: 1843 On server 2 I see: dovecot2:/# doveadm fetch -u s000 "size.physical size.virtual" mailbox-guid c92f64f79f0d1ed01e6d5b314f04886c uid 115 size.physical: 1805 size.virtual: 1833 Running ' doveadm replicator replicate -f s000 "*" ' does not fix the issue. I've compared the mails and the difference appears to be that the primary server (where the mail comes in) has a few occurences of "0D 0D 0A" (hex) which on the replicated server looks like "0D 0A". (ie, \r\r\n was replicated as \r\n ?) Is there a way to force these two messages to be in sync again ? Is the \r\r\n being replicated as \r\n a known issue ? (I'm not sure if I could replicate this, this message dates back to 2007 so probably wasn't even received originally on this server. Replication was configured much later than 2007)
