New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
New Server setup help
Has anyone setup remote unlock over ssh on CentOs7? There are some guides to use dropbear but it's for Ubuntu.
I am trying to setup full disk encryption via LUKS on a Kimsufi box.
I am simply trying to protect some important scanned documents and saved on the cloud as a backup.
I understand nothing is safe on the cloud, but I feel making the disk encrypted will at least not make it easy for anyone to sniff through my data should someone get a hold of it.
Since LUKS requires one to enter boot time password, how can I do something similar when Kimsufi or Online.net provides a simple rescue mode without any type of gui (novnc).
I'd like to see if this is possible and someone tried it...
Any suggestions?
Thanks
Comments
have use this before https://wiki.recompile.se/wiki/Mandos .
Thanks. I am looking out for centos
this one's for a centos VPS, not sure if that's going to be much different for the kimsufi bare metal setup, but might be a place to start:
https://www.vultr.com/docs/install-and-setup-centos-7-to-remotely-unlock-lvm-on-luks-disk-encryption-using-ssh
Thanks. But not sure how can I add the parameters like text it refers to. I did locate this link earlier but was unsure how to begin for an environment like Kimsufi or online.net
Thanks
ok ...
while I would also prefer the "full-disk" encryption, it's also possible to use LUKS to encrypt just a single partition (ie, containing your /home filesystem) - which may be a reasonable tradeoff if there's just too much hackery involved to get all the moving parts to mesh for
seems like 2 of the 3 above might be doable by following or adapting existing guides such as for full-disk LUKS on Debian or Ubuntu on kimsufi:
https://jkraemer.net/2018/04/fully-encrypted-headless-debian-stretch-setup
https://medium.com/@kernelfail/setting-up-server-with-encrypted-lvm-without-kvm-293ade4fcb06
https://blog.tincho.org/posts/Setting_up_my_server:_re-installing_on_an_encripted_LVM/
I can't really tell you what wrinkles CentOS is going to add to the procedures but maybe you'll be able to synthesize a workable process for CentOS based on some study and analysis.
While I wouldn't take it for granted that there's an easy, practical way to splice CentOS into the process using nothing but good old fashioned gumption, ingenuity, stick-to-it-tiveness, time, patience, and whatever else it takes to muddle through this stuff - I'd say it might be worth a try just to see how it goes.
Otherwise - I'd ask how much do I really need CentOS to be in the mix?
If it's a "must have" then would consider more options:
maybe someone's already done this on kimsufi + CentOS, but it seems like a long shot that they'll find this thread to help figure it out right now, I dunno. Anyway, here's hoping someone else might have better suggestions for you.
(I'm generally interested in this myself, but tend to just do the most straighforward thing that works reasonably well - then come back to it later to improve the setup if possible. If it needs to be uber-secure then that's a whole 'nother ball game which sort of requires knowing what you're doing from soup to nuts - random recipes from LET might be a place to start, but probably wouldn't be the end of the story.)
I have LUKS setup on a couple of small VPS, running Centos 7. The encryption, however is only on the /home partition and it is automatically unlocked during boot via a key on a different partition. Not strictly secure, I know but was just a Proof Of Concept. If the VPS gets decommissioned then a dd of the partition(s) will thwart all but the most determined.
With regards to kimsufi specifically, due to the lack of a console, things get really messy; broadly speaking..
cryptsetup luksAddKey /dev/mapper/data-home /root/.home
I did manage to do something similar with a different provider and a rescuecd but it wasn't easy.
Why not encrypt before backing up? This is the easiest solution and the most secure.
My approach is installing Proxmox then set up a KVM inside that with the LUKS. Use the VNC in Proxmox to enter key manually.
I can't think of a way to automate that to be secure.
Your LUKS key is stored in memory and if the data center staff have access to the host (easily obtained for most OSes out there) they can pull the key from the VPS's memory.
Targeted determination required, I'd say. CSF could alert to console access. :-|
Alerting only lets you know that you're screwed. My advice is to protect yourself so any alerts you get just tell you it's time to move to a different data center.
^ love the solution!
That's true, but I'm thinking if someone has the means and motivation to do that then they are welcome to my data - it's really not going to be worth it to them anyway, anything like passport is in an encrypted tar so just another obstacle for this attacker.
Yes, I agree, I am also open to keeping boot open and then mount everything else including swap (thats what I have gathered so far). So, if something like this is achieved, how easy would it be for anyone to snoop around and digg for the luks key for the other encrypted partitions?
Sure. Its worth a shot. Appreciate your view point.
Its not the end of world to use centos. Its just that from getgo, I was using centos as a true server os. Others, probably have come a long way, but, I just have not got comfortable with the others. If nothing works, I am open to switch, but, want to still give a shot for centos
Yes, I like this to start off with something and improve upon that. I have servers with other providers where they provide a noVNC console that allows me to add unlocks as time needed. But, I want to utilize the Kimsufi/ Online.net servers for storing personal effects.
Thanks again for the detailed response and effort.
absolutely true. but, I really feel keeping my disk encrypted will alteast deter normal person to read data on my disk. thnx
well - as @KuJoe pointed out - if your stuff is hanging out at EvilMaidHosting, or is subject to a warrant or whatever, then all bets are off once your system is online with LUKS disk (or partition or loopback file) - as the system is keeping the key in memory for someone with access to the box to dump. (Also see the "cold boot" attack for a more extreme example of how a key can be obtained from traces in memory.) If possible, it's best to do the encryption/decryption only on a system that no one but you can access, physically and otherwise (aka "air gapped" for whatever that's worth).
The "key" concept here (har har) regarding the benefit of LUKS would be "encryption at rest" - that is, how difficult is it to for a snoop to get your key or data from an offline copy of your disk. If for some reason you have the key sitting unencrypted somewhere on an unencrypted portion of your disk (as @AlwaysSkint described) then you would be vulnerable to anyone able to scan the disk image for that key. So don't do that (unless you want to trade ease of use for security of your "data at rest").
I guess another benefit to doing full-disk encryption when using LUKS is that it would otherwise be easier for an attacker to compromise your OS (think key logger etc) if the boot partition is left unencrypted - even as your sensitive data is encrypted. (Maybe somewhat analagous to taking pains to lock the door but leaving a window open). Extra steps to verify system integrity after booting might help a bit but only go so far (see "trusting trust" to go down that rabbit hole if you dare).
(I have taken that extra step to have GRUB2 handle an encrypted boot partition when setting up a bootable thumb drive for an offline system - it's tricky but doable. Seems like it's more common to leave the boot partition unencrypted though.)
Anyway - beyond that, best advice I can give would be to not to take too much advice from me (without at least double checking it elsewhere.) I haven't had the need to do much more than "best guess at best practice" so as just not to be too wide open on the systems I spin up mostly for entertainment purposes only. If I can't easily do full-disk LUKS (usually by installing Debian from ISO) but still want to protect something specific (such as ssh keys) then I'll often use a simpler file-based loopback setup (without LUKS) on a smaller ramdisk - so at least I don't have unencrypted goodies on the persistent disk itself. (It's maybe a bit janky and I haven't put much thought into it and really don't trust it tooo much, but it should be better than nothing I think.)
Hoping to learn more better wisdom about all this stuff as well.
As @uptime eluded to, my methodology is really only for "data at rest" i.e. what happens to the disc data when a server is decommissioned. Without a locally stored key, it also may safeguard (to some extent) if/when a provider goes deadpool. I'm convinced that it isn't bulletproof but will stimy the next user of that disc space.
Ultimately, if you purchase the services of a 3rd party, there's always going to be some level of trust involved. Server@home is still a much safer option (stashed in an air-conditioned heavy safe), albeit much less practical for 'net purposes and adds to your domestic leccy bills ;-)
Totally agree. Again, I want to dissuade simple prying eyes. Thanks for your insight