All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How can providers (and maybe malicious guys) get access to virtual box?
Hi guys,
Recently, from some LET threads, I realize some providers do access their clients virtual boxes without (or maybe with?) clients' passwords.
I don't have experience to run a vps service like kvm or ovz. How can they do this? Are there different methods to access different virtualization techs? Is kvm or Xen more difficult to access than OVZ?
if provider can not access to kvm or xen image directly, they maybe reset the password and get access? But what if I have set up the ssh-key to login and disable root login and password login? Can they still get access after reset?
I did a test on digitalocean, after root password reset, it still requires ssh-key and reject password and root login.
I checked on google, but didn't find more detail, and I don't know how to describe my question properly over google. So I asked here, guys, you may point me to some references or knowledge me here, both appreciate very much. thank you.
I ask this due to my curiosity and would like to know how to prevent this . Nothing other than this.
edit: since dissolution also involved ssh sercurity, so I edit a bit of the title.
original one is How can providers get access to virtual box?
Comments
You can't really prevent unless the server runs with your eyeballs glued to it.
You are cute.
They are virtual computers, run / emulated on a host. Long term it will always be possible to gain access either one way or the other.
Install Proxmox on a KVM to see how easy it is.
good point, but may not answer my curiosity...
thanks anyway
OpenVZ is the easiest:
vzctl enter [container ID]
It gets more complex under real virtualization but anyone with physical access should be considered trustworthy or not hosted with.
what does "real virtualization"? kvm or xen or hyper-V.
@Wolf sure, just as jarland said, any physical access will definitely have chance to do so, just discus this, some of them may not be that easy and time consumption may give a little shield of my data, period :P
checked that a bit. from what you said, it sounds like there should have a simple function to access everything through the node. lol
Real is KVM or Xen.
Container is Docker, LXC or OpenVZ.
Container usually allows direct entrance by design for OpenVZ it's vzctl enter. KVM you can always get access to the machine via VNC (equivalent of plugging a monitor into it) or as previously stated by others you can mount the hard disk and edit it
The disk contents of the VM need to be stored somewhere. It is stored on the host node. If an attacker has access to the host node, all they have to do is find the disk contents, create a block device from it, and mount the filesystem that's on the block device.
If the disk is encrypted, then it is a bit more difficult, since mounting the filesystem will require the encryption key. However, just as the disk contents of the VM need to be stored somewhere, the encryption key also needs to be stored somewhere, otherwise how would the VM be able to write to the disk? It is stored in memory in the VM. The VM's memory is stored in memory on the host node. So attacker can dump the memory of the process where VM is running and search for the encryption key there.
It doesn't matter if you are running KVM/Xen instead of OpenVZ/LXC, maybe you have to run two commands instead of one command to get access but fundamentally it is the same.
On dedicated server in someone else's datacenter it is a bit different. It is still possible to get the disk contents; there are some minor details like they are probably going to need to shutdown the server and copy the hard drive in order to get the data, but more importantly, this requires physical access: so, as long as you trust the datacenter people, it is okay, you don't have to trust that the datacenter systems won't be compromised by a remote attacker. Also, if you do encrypt the filesystem, then it's actually quite difficult to dump the memory contents on the server without power cycle (and power cycle would clear the encryption key). Of course, they could always shutdown the server, install some monitoring system (e.g. check the keystrokes while you type the encryption password over IPMI), and then boot it back up; and remote attacker could do this too.
If you need security it's a case of a dedicated server in your own secured building with 0 Internet access. All ports disabled excluding power and audio
after accessing through VNC, they still need password or my ssh-key to login to get access my contents? right?
Yes but the admin could mount your disk and insert his SSH key into your vps
They get hold of the harddisk and ram is enough to break in even in a dedicated.
mount my disk inside the kvm? or directly change everything from the node disk. thanks
Mount disk from the node. With container/VM, your data is stored on provider's infrastructure and can be readily accessed. With dedicated server, it is isolated from the provider's system but still vulnerable if attacker has physical access to your system. So dedicated server is more secure because you don't have to trust that the provider's software won't be compromised, since even if datacenter software is compromised, your disk contents still can't be read.
(Unless they have rescue mode and stuff that attacker can exploit.)
Well explained and really appreciated!
so basically, even on a dedicated node, it is better to encrypt disk in case of physical access (a thief in datacenter :-).
It's like you deposit some money in the bank. The bank (and staff) always have access to your account.
Similar to a landlord having access to the rental.
I wouldn't say "better", encryption means CPU overhead for disk operations. If you encrypt disk, then it is less likely that an attacker with physical access to your machine can get the disk contents. Of course, like I said, they can trick you into revealing the encryption key passphrase, e.g. by rebooting your server and monitoring IPMI traffic.
>
Just find another question, is it easy that a provider to decrypt my password used for root in a vps by accessing files and analysis them? how linux system store that information? That much more matters to me, cause I use similar "strong" passwords for all vpses I got...
edit: ok, I guess I find it myself this time. XD thanks anyway.
Or just clone a copy and you would never know.
It's stored as a salted hash.
Or at least it's supposed to be...then again...where did your OS template come from? Your provider very likely.
The first problem is that you shouldn't be using passwords...
i use ssh-key to login but sudo needs password to get approved, right. Did I do something wrong (stupid) here by this way?
good point can not be argued XD
No. You really should not think of your passwords, keys, credentials, etc. as giving you any kind of protection against someone who can (virtually or physically) take your hard drive and mount it somewhere else. No difference than someone stealing your hard drive at home.
Now, if you've encrypted the hard drive on your home computer, the thief is out of luck. But on a VPS, a devious and sophisticated host can get your encryption key.
at least to prevent Brute force root passwd attack from internet
Don't leave ssh open on port 22, stops 99% of brute force attempts, and
PermitRootLogin without-password
disables any password from working, until OpenSSH is exploited again.If you are trying to hide from your provider, find another provider. Any reputable provider is not going to waist time rummaging through your files when there is Netflix to watch. But encrypting your drive on KVM/Xen/Windows crap is a semi-good idea, and not to hide from your provider, but your providers Government. Again, any reputable provider will hand over a cloned copy of your drive when presented a valid warrant, but if you encrypted the drive, what good will that clone be? Sure the provider can dump your active memory on the node and probably get your access key, but why when there is Nexflix to solve any free time issue they might have.
I understand you are trying to learn something, but you are also looking like you are trying to figure out how to hide shady activity.
Please if us providers told you how we do this would it be a "secret" anymore?
as you do know not every provider does this unless they have to under certain circumstances like for example abuse notice from their dedi/colo provider, they have logs sent to them from their dedi/colo provider saying one of their clients is hosting something illegal etc. so no the more better hosts on here including me(who is honest) would not just snoop into your stuff unless I am required by law to do.
+1 IMHO I start at the point of 'The provider (or some admin/tech/junior/pissed of staff member) will always have access to my machine(s)'
I'd like to add something to this.
Use a port between 1 to 1024 for SSH but not the default port 22. It is important to use a privileged port for SSH.
Read why here: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/
It is certainly a good idea to move from 22 though to get rid of 99% of all bruteforce attempts but don't use ports above the privileged port range (1 - 1024).
That always gets posted on here and it's a load of rubbish. For that to be a problem a malicious person would already need access to your machine, at which point you're fucked anyway
Come out of your own little world and think of the bigger picture. You won't fall apart for doing that once.