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.
Comments
Please use the forum's search functions next time available here.
Putting seriousness aside, your data is never safe on the internet.
Well, the most secure place ever, to store your data is that old Dell computer that you've seen that other day, featuring a Intel Pentium 3 with a broken network port.
What about KVM + a manual OS installation to setup encrypted partition(s)?
Everything with no encryption is 'unsafe' to me.
Same with a dedicated box. If some one pulls the drives, you'll have basically the same situation as with a KVM based VPS where the node owner can access your virtual drive.
The problem with a dm-crypt encrypted disk(at least in my case) is that you have to go and type your password to unlock the drive via kvm on a dedi.
Which in the case of delimiter has been a pain in the back for me.
Well, if a provider is skilled enough, they can technically retrieve your private key from memory. (For a KVM VPS)
http://rand.pw/howsecure/
There is also the possibility en encrypt only the partition where you store your data, like /data and not the system. You unlock it using ssh. Or to set up full disk encryption with dropbear starting at boot to allow you to type your passphrase with SSH.
That's the exact problem I've encountered as well. In my opinion, the situation is even worse because the VPS console is generally available only over plaintext VNC so anyone can snoop on your password. In addition, password entropy is relatively weak unless you are willing to sit at the console and type in an insanely long password.
There's another approach that I tried implementing recently and it seems to work well. In essence the VPS requests its encryption key from another server via HTTPS at boot time. The key is then used to decrypt the root partition and finish the boot process. As long as the VPS can access the HTTPS server at boot time, the process is automatic and no human interaction is required (see the next paragraph for comment on security). The keyfile is only loaded into RAM during boot and is never stored on the VPS harddrive. Client SSL certificates and IP restrictions ensure that the keyfile can't be maliciously retrieved by other machines on the internet.
In my case I keep the HTTPS keyfile server at home and only connect it to the network when a VPS needs to be rebooted. This prevents the scenario where someone clones the VPS harddrive/IP address and attempts to retrieve the keyfile remotely.
This technique involves a fair amount of initial configuration but afterwards it's smooth sailing.
Of course as others noted, if your adversary is capable of retrieving the key from memory then the whole exercise is pointless.
No, the most of them seems to have for example 6-7x PCI expension slots (Wikipedia), so 6x PCI slots means = 6x times direct memory access. Even with a broken network port, they just grab your Keys throught the direct memory access.
Get some glue and fix that
I don't want to create a new topic, so i'm using this one. I am using my KVM VPS for storing my private files and VPN. I've created a entire encryption, so only dropbear with my SSH key can decrypt the VPS. Im not doing super dodgy stuff, but can the server owner/provider still login into the server. I was with a other provider months ago and had a problem. Openend a ticket and the provider logged into my KVM VPS as root. Root was disabled at my account, so the first question is: how can this be possible? Tought KVM the only way to get information are snapshots? The second question: at my current provider everything is encrypted, even the KVMoIP (SSL): which ways can be used from the provider to go into my VPS?
Serial Console tends to drop you directly to a root prompt. Anyone who gains access to the machine that provides virtual console has root on all of the machines with an active console.
KVM can be encrypted, however a skilled joe could possibly steal the key, therefore decrypting files.
With a dedi, you really don't have to worry. It can be encrypted and there's no other neighbors therefore reducing the chance of any access to your data to 0% unless you suffer from a dictionary attack from the hosting's staff or etc. But everyone around here knows to use a good password.
hunter2 is a great password
The question for me is how likely this is. But when any provider can simply log in into my KVM VPS even when it's encrypted then its not for me
From BuyVM "OpenVZ vs KVM" page here:
root:root11on a NFS server (real example)All I see is ******
@deadbeef http://www.bash.org/?244321
That was hilarious - especially the come back
Did you ever change the root password?
What do you mean by "root was disabled"? Root login disabled via SSH? Which means that you can still login as root as long as it isn't done via SSH (i.e. from the login prompt). If that's the case, then that's your answer.
I thought the serial console just drops you into a login prompt. OpenVZ is different, but that's just OpenVZ.
'0%' is a little extreme, I mean, they can always inject stuff into the boot chain. Then there's more sophisticated attacks like IPMI/USB driver exploits etc.
If the data is just stored, not hosted on server/vm (which seems to be most probable situation for "private data") for me the solution is to create container on local PC and then upload whole container to remote server. If i need this data later - just download whole container and open it on local PC. Never mount it on remote server. This way it can be stored anywhere, even on openvz vps or google drive...
grub has networking capabilities?
The question to ask is first against what and whom you want your data or server to be secure.
One point should be clear: There is no such thing as security with a rented or colocated server, no matter whether a vps or a dedi. Whoever has physical access to the machine can basically do whatever he pleases. That said ...
KVM can be considered more secure in that there is virtually no "bleeding through" unlike in OpenVZ which is basically just a glorified jail. The protection is mainly against cohabitants on the same hardware.
A dedi is more secure in that there are no others on that hardware.
Another point to look at is whether you actually need a secure server (no matter what kind) because usually only certain data of yours are sensible.
Usually the proper way to protect data is to encrypt them. Simple as that. But there is one point where it gets really ugly, namely private keys for SSL/TLS. Whoever can steal those can impersonate you - and you can't encrypt them because the servers needing them (like e.g. apache) are too stupid and need those sensitive data in cleartext.
Final remark: encrypted partitions or disks are almost never a good solution in the context of servers that are hosted somewhere else. As someone here already mentioned it's either a pita or a risk to provide the needed passphrases (plus it makes the box slower).
If you have more precise questions I'll be glad to answer.
Jason. I really wouldn't like Jason to have my data.
Hmmm. I personally think that Kevin and Wanda are more dangerous.
regards - Jason
If it's colo you have more options, e.g. include security hardware and tamper detection gear in your computers, use a locked colo cage with 24/7 cameras watching the equipment, etc. It's harder with rented servers but there's still more possibilities than with vps.
That's why I said that one must first ask "protect against whom or what?"
Against low level intruders or cross container attacks a simple dedicated server is all you need and the fancy fenced off and supervised colo cage doesn't offer much more in practical value.
But that helps next to nothing against intrusions through the wire (alias hacking) nor does it help a lot against a state player.
You see, ITSec is my field and I hear lots of stories again and again. One typical route is perfectionism like fenced off cages, guards with weapons and whatnot. But for 99.99% of us that's simply not the problem. Our adversary isn't a nsa tao or even some fbi agents. Our adversary is script kiddies, buggy and leaky code, careless or unexperienced provider technicians, etc.
Hence my advice is typically more on the side of installing alpine linux or at least debian rather than idio^h^h^h^h ubuntu linux, of configuring that properly, and of carefully chosing - and chosing only - what one needs (and configuring that properly, too).
In case you ask why I, the bsdguy, recommend linux: simple reason. Most have linux experience, quite few know bsd decently well. Hence their chances are better with a poorer OS that, however, is better configured. (Note: That is what I have to say, that's my view. I do not intend to start a religious war. In case someone thinks that linux is the better OS, fine with me, no problem).
I don't see how Ubuntu is inherently less safe than Debian or say Gentoo.
As far as I know, grub doesn't support networking.
My approach was to leave grub and initramfs on an unencrypted partition with all other partitions encrypted (same as a traditional encrypted system).
I then rebuilt the initramfs to include network and SSL support so that the VPS can contact the keyserver while booting and request its decryption key. If an attacker inspects the contents of the initramfs the decryption keys will not be there since they are only stored on disk at the keyserver.
I've been meaning to write up a tutorial for others but it's still on my todo list.