Koozali.org: home of the SME Server

9->10 migrating via console backup/restore: issues with let's encrypt?

Offline Michail Pappas

  • *
  • 339
  • +1/-0
I'm about to upgrade to 10 from 9.2. Not a lot of contribs, lat-tools and smeserver-letsencrypt-0.5-15.noarch come to mind. I don't know if I can produce a list of packages that were not included in 9.2...

Do you foresee any issues, especially with letsencrypt? Does 10 include letsencrypt functionality by default?

EDIT: Setup will be made to an ESXi VM, on a cluster. Any advice regarding choice of filesystems, whether LVM should be enabled etc would be appreciated.

EDIT2: Any way to disable LVM via boot option or something? If I need more size for the users' mailboxes I believe I can just increase the VM disk size from ESXi and then do some XFS extend magic to increase it, correct?

EDIT3: Any recommendations regarding boot type (normal/UEFI), when running as a VM under ESXi 7.0u2?
« Last Edit: November 18, 2021, 10:58:32 AM by Michail Pappas »

Offline Jean-Philippe Pialasse

  • *
  • 2,747
  • +11/-0
  • aka Unnilennium
    • http://smeserver.pialasse.com
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #1 on: November 18, 2021, 04:51:11 PM »
/sbin/e-smith/audittools/newrpms

no it is still a contrib

see wiki and boot menu for options, but yes you can.
further more you can use the gui interface to format as you want. be carefull if you set default within the gui partitioning tool it its the centos default not ours, so no raid, a boot partition and all disks available under a single lvm group.


edit: fixed typo in command
« Last Edit: November 19, 2021, 03:11:49 PM by Jean-Philippe Pialasse »

Offline Michail Pappas

  • *
  • 339
  • +1/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #2 on: November 19, 2021, 06:56:47 AM »
/sbin/e-smith/audittols/newrpms

Can't find this.

EDIT: Was misspelled, got it thanks!

Quote
no it is still a contrib
Ok thanks.

Quote
see wiki and boot menu for options, but yes you can.
Found them at https://wiki.koozali.org/SME_Server:Documentation:Administration_Manual:Chapter5#Installing_the_Software thank you.

Someone could perhaps answer whether LVM is recommended or not in my case (using the system for mail, my old server went for years with a 30Gb hdd). The way I see it, it just adds a complexity in case I have to recover the system, plus a performance overhead.

What's basic to ask here is how can I enable encryption for the drive. The installer seemed to be buggy regarding this feature, that is I enabled encryption and pressed done but was not asked for a key. Installer returned me to the main screen to setup networking, time/date etc. It was when I pressed installation destination for a 2nd time that I got asked for a password. Could this be perhaps due to the fact I'm booting from EFI?

What's the simplest way I could setup the disk to be encrypted?
« Last Edit: November 19, 2021, 07:22:28 AM by Michail Pappas »

Offline ReetP

  • *
  • 3,722
  • +5/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #3 on: November 19, 2021, 09:59:46 AM »
You want to reduce complexity and ease system recovery, but want to encrypt the disk?

Hmmm. Really?

On a  VM I believe the recommendation has always been use Raw, forget LVM, and forget Raid, and let the underlying system deal with it.

I'd also have a long hard think about whether encryption on your server is worth it.

Fine on a laptop that might get stolen.

But likely attack vector on your server is hacked while it is running (24/7), and encrytion won't save you then.

It's only really efffective with the machine off. Same with encrypted dbs.

Plenty of articles around that highlight the drawbacks.

...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions of software
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline ReetP

  • *
  • 3,722
  • +5/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #4 on: November 19, 2021, 10:00:38 AM »
Remember your Shakespeare.

"All that glisters is not gold"
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions of software
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline Michail Pappas

  • *
  • 339
  • +1/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #5 on: November 19, 2021, 01:15:24 PM »
You want to reduce complexity and ease system recovery, but want to encrypt the disk?

Hmmm. Really?

Well, under the constrain that email messages might contain sensitive personal data and GDPR is in effect, I should take at least some reasonable precautions in case there is a breach.

Quote
On a  VM I believe the recommendation has always been use Raw, forget LVM, and forget Raid, and let the underlying system deal with it.
That's why I'm dropping LVM/RAID etc. But...

Quote
I'd also have a long hard think about whether encryption on your server is worth it.

Fine on a laptop that might get stolen.

But likely attack vector on your server is hacked while it is running (24/7), and encrytion won't save you then.

I must take some measures to minimize my attack surface. Having data encrypted is one of them and can decrease the judicial damage our organization will take if we are sued for sensitive data loss/alteration etc.

Now, how one goes about encrypting is another story altogether. I'd definitely prefer that part to be done in hardware, on the storage system of our cluster or on the storage media themselves. That would increase the expenditure. A lot. Another alternative would be for the hypervisor (ESXi on our case) to do it. More $$$ to shell to upgrade our essentials plus license to an enterprise one...

Having SME do the encryption dance might be feasible. Furthermore, daily backups from my SME VM will be taken, to an encrypted medium over an encrypted channel, in case the VM goes kaput.

Quote
Remember your Shakespeare.

"All that glisters is not gold"
Not read Shakespeare, sorry. Being Greek though I can counter that with "το μη χείρον, βέλτιστον" (roughly, I'm taking the better of two evils ;) )

Offline ReetP

  • *
  • 3,722
  • +5/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #6 on: November 19, 2021, 02:21:19 PM »
Well, under the constrain that email messages might contain sensitive personal data and GDPR is in effect, I should take at least some reasonable precautions in case there is a breach.

So you use PGP in every mail then? Because if you don't then your emails can easily be sent via an unencrypted server without you realising, or being able to control it, because you cannot control whether your server talks directly to the remote server via an encrypted connection - one of the big flaws with email.

eg this can easily happen and you have zero control over it.

SME > encrypted -> mail server -> unencrypted -> mail server- > encrypted -> Destination server

Disk encryption will only prevent data loss in the event your server is stolen. What is the likelihood of that?

As far as GDPR you can show you have assessed the risk etc etc. Far better to invest your resources in not getting hacked IMHO. And making sure your server does not get stolen :-)

Quote
I must take some measures to minimize my attack surface. Having data encrypted is one of them and can decrease the judicial damage our organization will take if we are sued for sensitive data loss/alteration etc.

Assess the risks properly and then address them accordingly. Much more likely for a laptop to be stolen, so encrypt the disk. Much more likely for the server to be hacked - so address the entry points. Do you use 2FA (yuck damn thing) on everything, every login etc?

Quote
Now, how one goes about encrypting is another story altogether. I'd definitely prefer that part to be done in hardware, on the storage system of our cluster or on the storage media themselves. That would increase the expenditure. A lot. Another alternative would be for the hypervisor (ESXi on our case) to do it. More $$$ to shell to upgrade our essentials plus license to an enterprise one...


Or change hypervisor ;-)

But better at hardware or hypervisor level I would think. It will then encrypt ALL your VMs in one go.

Quote
Furthermore, daily backups from my SME VM will be taken, to an encrypted medium over an encrypted channel, in case the VM goes kaput.

You aren't using encrypted channel already...?? Hmmmm.


Quote
Not read Shakespeare, sorry. Being Greek though I can counter that with "το μη χείρον, βέλτιστον" (roughly, I'm taking the better of two evils ;) )

:-)

All that glisters - It means don't be fooled by flashing signs, neon lights, and all the other things that distract you from making sensible decisions based on facts vs irrational decisions based on scaremongering by companies who who want to sell you extremely expensive 'solutions' to problems that do not really exist.

A I said - encryption is only effective when the machine is stopped. And how often do you stop your server?

I'm not saying don't do this, but think carefully about what is really important.
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions of software
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline Jean-Philippe Pialasse

  • *
  • 2,747
  • +11/-0
  • aka Unnilennium
    • http://smeserver.pialasse.com
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #7 on: November 19, 2021, 03:17:23 PM »
and encryption is also a really think about it when it comes about backups:

- remote cloud, no choice have to be encrypted

- local in a safe, where will you store the decryption key? right on the disk in same safe ? so just do not encrypt.  elsewhere in another building? is it safe enough? would you be able yo retrieve it in case of need?
then again probably not worth to encrypt unless tou are at high risk to get robbed at your location.

Offline Michail Pappas

  • *
  • 339
  • +1/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #8 on: November 23, 2021, 07:07:40 AM »
You're giving me hell here, trying to respond :) Couldn't do so, weekend was hellish. But here we go.

So you use PGP in every mail then? Because if you don't then your emails can easily be sent via an unencrypted server without you realising, or being able to control it, because you cannot control whether your server talks directly to the remote server via an encrypted connection - one of the big flaws with email.

eg this can easily happen and you have zero control over it.

Because PGP is not used by others out of our organization. Sensitive mails directed to other organizations within our WAN are encrypted by default anyways.

Quote
Disk encryption will only prevent data loss in the event your server is stolen.
1) judicially it will also trim the financial damage in case one is sued for data leaks (GDPR)
2) data end up in cluster storage, so another compromised VM might be able to access and control the hypervisor and/or view data for the SME VM directly

Quote
Far better to invest your resources in not getting hacked IMHO.
Trying to encompass as many aspects of security I can, we as much resources and know how I have TBH. Not much, but I have had no issues for almost 20 years of operation. It's tiresome though; constant supervision is needed and I definitely need someone to take over this job soon...

Quote
And making sure your server does not get stolen :-)
You've nailed it here. I could use some significant physical security upgrade.

Quote
Assess the risks properly and then address them accordingly. Much more likely for a laptop to be stolen, so encrypt the disk. Much more likely for the server to be hacked - so address the entry points. Do you use 2FA (yuck damn thing) on everything, every login etc?
No, not enough time for anything... 10.0 has been released months ago and I'll be doing the upgrade from 9.2 right now not because the latter is EOL and possibly heavily exploitable, but because ClamAV has stopped updating the signatures. That's pitiful being said from me considering my statements about me valuing security etc etc. But I don't have time to do all the things that must be done, so I'm heavily cutting corners.
 
Quote
Or change hypervisor ;-)
Have been using proxmox but took the jump to esxi mainly because all vendors sweared that storage for the cluster would not be guaranteed to play nicely with pve. I'm still using it for single hypervisor installations though, very satisfied with it.

Quote
All that glisters - It means don't be fooled by flashing signs, neon lights, and all the other things that distract you from making sensible decisions based on facts vs irrational decisions based on scaremongering by companies who who want to sell you extremely expensive 'solutions' to problems that do not really exist.

A I said - encryption is only effective when the machine is stopped. And how often do you stop your server?

I'm not saying don't do this, but think carefully about what is really important.
Thanks buddy, advice well taken :)

and encryption is also a really think about it when it comes about backups:

[...]

- local in a safe, where will you store the decryption key? right on the disk in same safe ? so just do not encrypt.  elsewhere in another building? is it safe enough? would you be able yo retrieve it in case of need?
then again probably not worth to encrypt unless tou are at high risk to get robbed at your location.

Excellent points! As for example where to storage the (ridiculously long) root/admin passwords for ESXi, the storage etc. I'm attacking this by storing these passwords on Bitlocker-guarded volumes which reside on and off of our main site.

With all those said though, you've still not told me how to enable encryption during setup on SME :) Any information will  be appreciated.

Offline ReetP

  • *
  • 3,722
  • +5/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #9 on: November 23, 2021, 12:27:14 PM »
Quote
You're giving me hell here

We're trying to stop you wasting time on things that are inconsequential when you have much bigger problems that you have ignored. And this is a variation on the XY Problem.

You have asked a question, we have answered it, but unfortunately it isn't the answer you want to hear.

Disk encryption will only be of any use if the disk/machine is off/physically stolen. You have much bigger issues to address.

Quote
Sensitive mails directed to other organizations within our WAN are encrypted by default anyways.

But are you confusing a secure connection with an encrypted email? They are not the same thing. If a hacker gets into your server can they cd to the mail store and read mails?

So you use PGP internally then? You don't cache any unencrypted mails in your mail program on your client computers like laptops & desktops (eg Thunderbird has Message Synchronisation set to off etc) or you exclusively use webmail? And all of your client desktops have disk encryption enabled? If so that's good......

Quote
1) judicially it will also trim the financial damage in case one is sued for data leaks (GDPR)

You are going to get your butt spanked far more quickly if you don't fix some of your other issues. Disk encryption is so low down your list of potential GDPR fails you can essentially forget it right now. (I also fall under GDPR - Disk encryption doesn't lose me any sleep)

Quote
2) data end up in cluster storage, so another compromised VM might be able to access and control the hypervisor and/or view data for the SME VM directly

Protection is ONLY true if the SME VM is stopped, but as it is a server I guess it will be running pretty well 24/7 ? So 99.999999999% of the time your disk encryption is useless. Prioritise.

Quote
But I don't have time to do all the things that must be done, so I'm heavily cutting corners.

XY Problem in the making then. Disk encryption is NOT your solution. Careful planning is - you have already delayed upgrades far too long. Migrating immediately is your top priority. Implementing something you don't really understand will not help. Cutting corners will just make everything a whole lot worse.

Quote
That's pitiful being said from me considering my statements about me valuing security etc etc

Exactly. The core of the problem. So stop RIGHT NOW. Focus your time on the essentials. Stop wasting it on trivia.

Quote
With all those said though, you've still not told me how to enable encryption during setup on SME :) Any information will  be appreciated.

Well, you are wasting valuable time on this and not the important stuff like getting upgraded.

First - it may  be easier to to use the hypervisor for encryption of the VM. Please have a read online about it.

Next - why haven't you tried the v10 installer yet? Look under Installation Destination. Look in the Partitioner. However, I am not sure whether this actually works with v10..... You will have to test it and see. Note you will also need to insert the password for every boot......

An alternative is to install a CentOS 7 minimal, sort out the encryption, and then use https://wiki.koozali.org/Centos2sme

Or another is install, and then create an encrypted volume and mount it in the place of a ibay, and or user directories/mail stores

Whatever you do, be careful. You can just as easily lose your data or prevent user access if you get things wrong.

I'd really spend some time looking at the different methods of encryption and understand them and the pros and cons.

Then run a proper risk assessment of all your systems and carefully weigh up the real dangers, because currently you seem to have your priorities a little skewed.

I'm not trying to be unkind but to try and get you to realise you have far bigger headaches to fix NOW than messing with disk encryption.

...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions of software
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline Michail Pappas

  • *
  • 339
  • +1/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #10 on: November 23, 2021, 01:41:13 PM »
First - it may  be easier to to use the hypervisor for encryption of the VM. Please have a read online about it.
First thing I looked at, but needs an enterprise grade VMware license, plus a separate vsphere key management cluster etc...

Quote
Next - why haven't you tried the v10 installer yet? Look under Installation Destination. Look in the Partitioner. However, I am not sure whether this actually works with v10..... You will have to test it and see. Note you will also need to insert the password for every boot......
Unfortunately, as I've described in my second post, I've tried and failed miserably :) :
What's basic to ask here is how can I enable encryption for the drive. The installer seemed to be buggy regarding this feature, that is I enabled encryption and pressed done but was not asked for a key. Installer returned me to the main screen to setup networking, time/date etc. It was when I pressed installation destination for a 2nd time that I got asked for a password. Could this be perhaps due to the fact I'm booting from EFI?

What's the simplest way I could setup the disk to be encrypted?

Might be that possibly, as you've stated, this does not play well with 10. I wanted to check the ease of use of inserting the password, since I won't be around (consider that I'm the Linux proficient guy here for heaven's sake :) ).

Quote
An alternative is to install a CentOS 7 minimal, sort out the encryption, and then use https://wiki.koozali.org/Centos2sme

Or another is install, and then create an encrypted volume and mount it in the place of a ibay, and or user directories/mail stores

Whatever you do, be careful. You can just as easily lose your data or prevent user access if you get things wrong.

Quote
I'm not trying to be unkind but to try and get you to realise you have far bigger headaches to fix NOW than messing with disk encryption.
Thanks for taking the time to try and help here mate. I REALLY appreciate it, hope I can return the favor sometime :)

Offline ReetP

  • *
  • 3,722
  • +5/-0
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #11 on: November 23, 2021, 02:00:18 PM »
:lol:

Quote
First thing I looked at, but needs an enterprise grade VMware license, plus a separate vsphere key management cluster etc...

Quelle surprise.... :-)

Quote
It was when I pressed installation destination for a 2nd time that I got asked for a password

OK I missed this. I can blame old age....

I think that is because once you have set it encrypted you will need to set a password, and then use a password every time you open access to it.

*Probably* nothing to do with EFI but I won't swear to it. The whole thing probably needs testing more but again, it isn't top of the list of priorities for reasons previously explained.

Note from my brief look you can get to Encrypt Disk or whatever on the FIRST bit of the disk set up, but you can then encrypt each partition on the Manual configuration part. How well this works I have no idea.

Personally I'd strongly favour a straight forward install, and then mounting an encrypted volume at a later date if required. At least the server will boot....

But your biggest priority is just to get moved.

Quote
I wanted to check the ease of use of inserting the password, since I won't be around

And quite frankly, apart from all the other things that need fixing, that is the reason to forget it entirely..... You need to be available 24/7/365 in case your server restarts :-)

Quote
Thanks for taking the time to try and help here mate. I REALLY appreciate it, hope I can return the favor sometime :)

No worries. Just stay involved and please help test. I'd suggest you just get migrated first and then try testing the whole encrypted thing at your leisure later - you can give us some proper feedback.

You've got a Rocket account - so do please talk to us there.

...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions of software
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation

Offline Jean-Philippe Pialasse

  • *
  • 2,747
  • +11/-0
  • aka Unnilennium
    • http://smeserver.pialasse.com
Re: 9->10 migrating via console backup/restore: issues with let's encrypt?
« Reply #12 on: November 23, 2021, 02:20:21 PM »
there are multiple way to encrypt fs, folder and so on under linux.

nothing special about sme

just read about rhel7 and centos7. 

here is the red hat way.  so you still have a system able to boot but home is secure.  but yes you might want to do the same for db or to configure mysql to store encrypted. . 



https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-encryption


as it is not really kiss, potentially more armful than helpfull this is not part of what we provide, but one familliar with it can do it at  its own risks.

you speak about compromised vm taking control of hypervisor to access the row data on the disk, if you get there, it will be easy to compromise the other vm to acces it from the inside while running.  you have access to the hupervisor memory…,,