Encryption FS on the Cloud and Remote SSH
-
So you want to Encrypt the FileSystems of VM on the cloud like Vultr.
But on reboot it asks for password to decrypt the OS FS. Which prior than the SSH server.
How do you manage this with Centos 7 ?
I tried many guidelines but nothing seems up to date and with detailed steps.
I kinda know the answer which you should not encrypt the OS, how about partition with the important date, but it would be interesting if you solved the problem with detailed easy steps.
-
Automount encrypted partition on boot
https://evilshit.wordpress.com/2012/10/22/how-to-mount-a-luks-encrypted-partition-on-boot/
https://blog.tinned-software.net/automount-a-luks-encrypted-volume-on-system-start/Unlocking a LUKS encrypted root partition remotely via SSH
http://blog.neutrino.es/2011/unlocking-a-luks-encrypted-root-partition-remotely-via-ssh/ -
@emad-r said in Encryption FS on the Cloud and Remote SSH:
I tried many guidelines but nothing seems up to date and with detailed steps.
I kinda know the answer which you should not encrypt the OS, how about partition with the important date, but it would be interesting if you solved the problem with detailed easy steps.
There are two choices...
Use OOB to do it (use the Vultr console) or don't encrypt the OS. That's it.
-
@black3dynamite said in Encryption FS on the Cloud and Remote SSH:
Automount encrypted partition on boot
https://evilshit.wordpress.com/2012/10/22/how-to-mount-a-luks-encrypted-partition-on-boot/
https://blog.tinned-software.net/automount-a-luks-encrypted-volume-on-system-start/While this works, it's a loophole. It also totally defeats the encryption. For all intents and purposes, it's the same as not having any encryption because all you do it power it on, and it is unencrypted. In a cloud, there's no plausible risk of hardware theft.
-
With CentOS you could use NBDE. Just run a Tang server somewhere and have the Clevis client on the Vultr box authenticate that way. However, if the Tang server isn't available (it will need to not be behind NAT) then you'll need your LUKS password.
-
No VNC option?
-
This post is deleted! -
@emad-r @all
Hmm interesting answers...
I tried many guides but will try its not that I dont trust the Cloud, I was thinking of ways to make it yours and with LUKS + Geo IP firewall filtering (only allow 1 country to access the server)+ SSH password less login = it gets interesting.
worst case scenarios lets say imaginary ones, Cloud provider closes, gets raided / theft ... etc. I know 99% Cloud folks will do better job that us but lets be paranoid abit. Thats the point of this exercise. Ofcourse I can use VNC from Vultr but wanted something more to be honest, something I can input faster, and I prefer not to save the password as that will defeat the purpose. I heard of small SSH servers that can be loaded at boot time and stuff.
Any way will research this more and see.
-
@emad-r said in Encryption FS on the Cloud and Remote SSH:
@emad-r @all
Hmm interesting answers...
I tried many guides but will try its not that I dont trust the Cloud, I was thinking of ways to make it yours and with LUKS + Geo IP firewall filtering (only allow 1 country to access the server)+ SSH password less login = it gets interesting.
You realize that Geo-IP is completely worthless, right? You don't even have to "hack" it yourself, just get a warranty replacement router. I had a warrantied router showing my Geo-IP location as Washington state when it was in Ohio (as far away from the actual location as is possible to be and still be in the same country). It is so trivial for bad actors to bypass a Geo-IP block that they have it automated now, so you're time is better spent on real security concerns.
-
@emad-r said in Encryption FS on the Cloud and Remote SSH:
@emad-r @all
worst case scenarios lets say imaginary ones, Cloud provider closes, gets raided / theft ... etc. I know 99% Cloud folks will do better job that us but lets be paranoid abit. Thats the point of this exercise. Ofcourse I can use VNC from Vultr but wanted something more to be honest, something I can input faster, and I prefer not to save the password as that will defeat the purpose. I heard of small SSH servers that can be loaded at boot time and stuff.
What is secret about the standard operating system and software being run on any given system? Encrypt by default, yes, but only the parts that need to be. IE: Nextcloud data directory, or a file server /home directory.
-
@travisdh1 said in Encryption FS on the Cloud and Remote SSH:
@emad-r said in Encryption FS on the Cloud and Remote SSH:
@emad-r @all
Hmm interesting answers...
I tried many guides but will try its not that I dont trust the Cloud, I was thinking of ways to make it yours and with LUKS + Geo IP firewall filtering (only allow 1 country to access the server)+ SSH password less login = it gets interesting.
You realize that Geo-IP is completely worthless, right? You don't even have to "hack" it yourself, just get a warranty replacement router. I had a warrantied router showing my Geo-IP location as Washington state when it was in Ohio (as far away from the actual location as is possible to be and still be in the same country). It is so trivial for bad actors to bypass a Geo-IP block that they have it automated now, so you're time is better spent on real security concerns.
Most Geo-IP stuff shows me as being in Toronto, when I'm in Dallas. And I am doing nothing, and attempting to do nothing to make it do that. The systems just aren't reliable. Sometimes they are right, sometimes they are wrong. But they are wrong so often, and by so much, you can't use them as a security mechanism.
When I worked at a bank in NY, we always showed up as being in Germany!
-
@emad-r said in Encryption FS on the Cloud and Remote SSH:
I heard of small SSH servers that can be loaded at boot time and stuff.
If SSH can be loaded, your disk isn't encrypted. Period. It's one or the other.
-
@emad-r said in Encryption FS on the Cloud and Remote SSH:
worst case scenarios lets say imaginary ones, Cloud provider closes, gets raided / theft ... etc.
This would require the theft of the ENTIRE data center. This is like a meteor fear. It's irrational and good security always comes from rational thinking. What you are doing is wasting time on a non-threat for something that makes no difference. Put this effort into something that matters, instead of something that doesn't.
This is what I call the "what if" mistake. Using scary sounding scenarios, instead of logic and math, to determine what risk really exists. Same mistake that causes people to avoid commercial airplanes, but happily drive dangerous cars. The "what if" the plane crashes sounds so scary that they ignore that you are so much more likely to die while driving because it doesn't "sound" so scary.
-
@scottalanmiller said in Encryption FS on the Cloud and Remote SSH:
@emad-r said in Encryption FS on the Cloud and Remote SSH:
I heard of small SSH servers that can be loaded at boot time and stuff.
If SSH can be loaded, your disk isn't encrypted. Period. It's one or the other.
Not necessarily. If it's built into the initramfs it will run before the OS is loaded. That's how Clevis works. Its built with dracut and gets an IP via DHCP which it uses to contact the Tang server.
-
@stacksofplates said in Encryption FS on the Cloud and Remote SSH:
@scottalanmiller said in Encryption FS on the Cloud and Remote SSH:
@emad-r said in Encryption FS on the Cloud and Remote SSH:
I heard of small SSH servers that can be loaded at boot time and stuff.
If SSH can be loaded, your disk isn't encrypted. Period. It's one or the other.
Not necessarily. If it's built into the initramfs it will run before the OS is loaded. That's how Clevis works. Its built with dracut and gets an IP via DHCP which it uses to contact the Tang server.
But that means you have an application framework up and running from an unencrypted disk. It's more than a boot loader, it's playing a lean OS function at that point.
-
@scottalanmiller said in Encryption FS on the Cloud and Remote SSH:
@stacksofplates said in Encryption FS on the Cloud and Remote SSH:
@scottalanmiller said in Encryption FS on the Cloud and Remote SSH:
@emad-r said in Encryption FS on the Cloud and Remote SSH:
I heard of small SSH servers that can be loaded at boot time and stuff.
If SSH can be loaded, your disk isn't encrypted. Period. It's one or the other.
Not necessarily. If it's built into the initramfs it will run before the OS is loaded. That's how Clevis works. Its built with dracut and gets an IP via DHCP which it uses to contact the Tang server.
But that means you have an application framework up and running from an unencrypted disk. It's more than a boot loader, it's playing a lean OS function at that point.
That's pretty much what it is anyway. There's a ton that happens in there. Video hardware needs initialized (if menus are displayed), LVM utilities need initialized, etc. Even with LUKS, something has to prompt you for the password. Dracut just uses udev for the helper programs.
-
Here's a section from Gentoo's site on it:
-
Also, I'm not arguing that starting a minimal SSH server (like tinyssh or dropbear) is a bad idea. Just that it's completely possible.
-
@stacksofplates said in Encryption FS on the Cloud and Remote SSH:
@scottalanmiller said in Encryption FS on the Cloud and Remote SSH:
@stacksofplates said in Encryption FS on the Cloud and Remote SSH:
@scottalanmiller said in Encryption FS on the Cloud and Remote SSH:
@emad-r said in Encryption FS on the Cloud and Remote SSH:
I heard of small SSH servers that can be loaded at boot time and stuff.
If SSH can be loaded, your disk isn't encrypted. Period. It's one or the other.
Not necessarily. If it's built into the initramfs it will run before the OS is loaded. That's how Clevis works. Its built with dracut and gets an IP via DHCP which it uses to contact the Tang server.
But that means you have an application framework up and running from an unencrypted disk. It's more than a boot loader, it's playing a lean OS function at that point.
That's pretty much what it is anyway. There's a ton that happens in there. Video hardware needs initialized (if menus are displayed), LVM utilities need initialized, etc. Even with LUKS, something has to prompt you for the password. Dracut just uses udev for the helper programs.
true, it's like UEFI, too much for its own good.
-
Yh your both right, I just thought if there was an easy way to do implement this then maybe I will add it as an extra hardening step, and I know the more security layer you add the more complexity, and sometimes it becomes more unusable/unreliable.