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.
-
@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.
-
@emad-r said in Encryption FS on the Cloud and Remote SSH:
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.
Is it REALLY added security, though? In what way does it add protection?
-
@scottalanmiller said in Encryption FS on the Cloud and Remote SSH:
@emad-r said in Encryption FS on the Cloud and Remote SSH:
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.
Is it REALLY added security, though? In what way does it add protection?
Between you and the cloud Provider. Adds additional layer of no eaves dropping if there is such an act, that said I know that your much better handled with cloud provider than self hosted
-
@emad-r 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:
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.
Is it REALLY added security, though? In what way does it add protection?
Between you and the cloud Provider. Adds additional layer of no eaves dropping if there is such an act, that said I know that your much better handled with cloud provider than self hosted
How? How can encryption of the OS protect you in any way? Everything in the OS is public data that they can pull down anyway? And once your system is up and running, it's not encrypted. The cloud provider can turn it on anytime that they want.
I think this protection is complete myth. People hear "encryption" and assume it implies more security, but it does not. I see absolutely no protection. First, it's not something you would rationally want to protect. But secondly, even if it was, this does literally nothing to protect it.
-
Encrypting data has a small value in a situation like this, very small. Only when worried about physical theft, which is a "meteor-like risk" in a cloud datacenter. But at least it is real, if nominal (WELL into tin foil hat territory.) Unless you are a military or government, and even then, it's pretty remote.
But the OS is not a risk. It's that simple. As it is not a risk, nothing you do to it can increase security. There is nothing to secure.
-
Your server will rarely be turned off. In a rare case that it's off, yeah it asks for your unencryption password, but as Scott said it it'll normally be on and it won't matter.
-
To play devil's advocate, if you're using LUKS the data is encrypted in transit also. So it's not just at rest.
-
But, most likely the provider is already doing both at rest and in transit encryption. So there isn't much here to help. Also, using ephemeral systems takes care of this issue.
-
@stacksofplates said in Encryption FS on the Cloud and Remote SSH:
To play devil's advocate, if you're using LUKS the data is encrypted in transit also. So it's not just at rest.
I can't remember off of the top of my head, but you might need FIPS mode enabled for dm-crypt to encrypt in motion as well. I'm lazy and don't feel like looking it up.
