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
So, we are pwnt? XD
I asked about this in the #openvz channel on freenode.... no one gave a crap about it, and someone said "SolusVM doesn't strike me as particularly trustworthy", and ignored me when I asked why he thought that.
LOL
CMIIW, but aren't all OpenVZ containers' "filesystems" simply subdirectories of the host node's filesystem? In that case, there's no need to login to the container if it's just to read or modify a file, and there's absolutely nothing you can do inside your VPS's process space to control file access, except maybe watching a file's atime, if atime is enabled on your host's filesystem, and if they don't just reset it.
I think it's best to assume that from a security/privacy POV, OpenVZ is shared hosting.
Hehe, I can see why he didn't answer. Not an issue with SolusVM as you said "vzctl enter" can be done just the same from the command line...Solus is just passing along the functionality.
OVZ is basically a jailed root, if your host is untrustworthy/un-ethical, you have problems.
If the node is logged onto your VPS from vzctl, you're have a process like the following in your VPS.
Someone on the node simply has to use vzctl enter and bam, they have a root shell on your VPS. (However screen bugs)
SolusVM Console also uses vzctl, it simply logs you onto a shell on the node that executes vzctl enter and locks you into it.
Where do admins apply for the time needed to mess around with customers data?
That depends on the client.
@Daniel
Yes, we know that about the vzctl process, but we are talking about logging that events
@miTgiB
Strange. Seems like that's all I do. That and updates and fixes to the softwares that they run.
What I find hard to set aside time for is checking the spam data. I try to at least send notices on the top 25 problem IP addresses and the domains that they're advertising.
Of course many of those are ev1/theplanet/softlayer so I know it'll just be a waste of time so I don't even bother any more. China too.
I mean not at their request, but just for the fun of rifling through their draws like a curious girlfriend.
We've done it a couple of times in the past. We got hit with 2 child porn rings on our social networking sites that we host a few years back and we went searching for similarly named files across over all of the servers. edit: We made it public that we were doing so. Got some grief over it but considering our mostly soccer mom client base, I think they understood the situation. I don't recall anyone canceling their account for what we did.
Besides that I can't think of any. I know with some of the social networking sites that we host, we have provided plugins/modules/whatever where those admins (our clients) can pull up a list of recently uploaded files. Not sure how many of those folks actually use that option. I don't recall anyone bringing it up for discussion.
As I've said, I'm not too concerned with my host messing around with my data, I'm concerned with someone using SolusVM's PowerConsole to break into my VPSes, which, right now, is completely undetectable unless you catch them in the act of doing so.
Maybe you could setup a cron to watch out for vzctl?
This is an old thread, but maybe this will help someone:
Regarding the solution madbuda had above for putting in /root/.bashrc the line:
Yes, that would change the default HISTFILE=/dev/null that
vzctl enter(and PowerConsole) set, but even if you used HISTFILE=~/.bash_history in your .bashrc, all the admin (or whoever) would have to do after logging in is anunset HISTFILEto bypass it.A better way to do it using .bashrc would be:
$SSH_CLIENT is an environment variable that OpenSSH sets, so if you only want to be able to login via SSH then the above might be a solution. Could also use $SSH_CONNECTION or $SSH_TTY.
But instead of just kicking out the person with
exit, you could replaceexitwith something that sends you an email, or a message to (a remote!) syslog, or whatever. Could changeecho "Console login detected."to a big fat warning for your hoster (or an attacker who rooted the hoster) so they know they're being logged.Just tested it with the SolusVM PowerConsole my VPS provider offers for console access, I'm assuming it works basically the same as if the admin would have done
vzctl enter.Here's what I get after adding the above code to my .bashrc:
Of course, this isn't completely foolproof. If the admin has access to the disc image containing your VPS, I'm sure there's a way for that image to be mounted somewhere (like you would an ISO). From there the admin could just delete your .bashrc, restart your VM, and login via
vzctl.@dfc I've never seen such a useful necromancering before.
Actually as a host you could probably just edit the file without entering, by editting /path/to/storage/CTID/root/.bashrc
OpenVZ is not like KVM/Xen where you have to shutdown and mount the guests filesystem
Edit: If you did send yourself a notification/log externally or whatnot, you'd atleast know, but its not like it prevents anyone from accessing.
A malicious host can easily 'cd' into /var/lib/vz/private/your-container-id/ and snoop around your files as he/she pleases.
Or, just clone the container, then block off outgoing ports of the new container to avoid remote logging or emails, after that power it on, and inspect your running system at his/her will.
This is also possible for KVM: 1. Clone your VM 2. Mount the cloned VM 3. Reset its root PW 4. Block outgoing ports from host node 5. Power on cloned VM 6. Login as root 7. ???
No legitimate host would do this though. With that said there is NO privacy in OpenVZ at all.
Get a dedi, or colocation, or host your important files in your basement/attics.
/var/lib is only debian. Trust me I have sworn enough at my personal node.
I did in the end haha.
Answer to the thread: You can't.
praying that a 'respectable percentage' of the forum's OVZ providers have not fallen into some sort of bizarro NSA meets 'Revenge of the Nerds' locker room scene treatment of /vz/private rn
In all seriousness, it is called Open VZ. Clearly it's geared toward a particular sensibility re: engagement/conduct/trust/the observer effect/whatever. I like how it resembles an 'honour system' and involves conscience in a way that is more decisive than other virtualization technologies.
It's not like Xen and KVM are impenetrable fortresses of solitude either, as recent events have shown.
All fairness trying a few of these methods on my own node then a couple shady providers
Ah, right. Everyone who suggested just CDing to the directory is right. I'm thinking of non-OpenVZ based VPSes. But even then, my silly .bashrc addition will detect (or prevent) PowerConsole logins. That'll at least prevent attackers who gain access to your SolusVM (or whatever) from getting to the console. Though if they've got that kinda access, I'm sure they could change some other stuff around to gain access.
I really wouldn't suggest using OpenVZ for anything serious (game servers, etc. would be ideal). Plus OpenVZ isn't technically a real VM. See https://wiki.openvz.org/WP/Containers_vs_VMs
If you're looking for more security, a KVM or Xen-based VPS would be better.
At least then you could compile your own Linux kernel with grsecurity support, or do a BSD-variant that's locked down... or Windows ME.
Just look at the different OS types Xen and KVM support:
http://www.linux-kvm.org/page/Guest_Support_Status (better Windows and Solaris support)
http://wiki.xen.org/wiki/DomU_Support_for_Xen
Or course, that still won't prevent the admin from grabbing your VPS' image file and mounting it elsewhere to look through your stuff.
@TinyTunnel_Tom that is true. Although I think that, on the whole, it may be a bit more difficult than scapegoating a couple obvious things. But yes, cutting out a shady provider or two may save you some money down the line if you ever need to upgrade your tinfoil mechwarrior's exoskeleton to become more resilient when considering 'trust' at venerable infrastructure level and so on.