Disk Image security?

The hosts are in commercial grade hosting facilities.

For various older hosts, they are hosted at The Planet, whos description page for their data center is at: http://www.theplanet.com/datacenter.html

Newer hosts are located at Hurricane Electric, whos description page for their data center is at: http://he.net/colocation.html

Seems pretty secure to me.

Bill Clinton

Thanks, "Bill Clinton!"

My host is at HE. I was aware that HE is physically secure. It's at least as secure as I could make it if I hired my own secruity guards, etc., and I'm williing to trust the integrity of HE and of their employees, even though their contractual and legal obligations are to Linode and not directly to me.

As I said earlier, I'm also willing to trust Linode's competence and integrity.

As I imiplied earlier, the weakest link is the system administration of the Linode itself, but this is entirely in my own hands.

This leaves only one unknown: the security policies and procedures associated with the host. Based on the impressions I get by reading the forums and the site in general, Linode is Chris Akers, and Chris is very competent. However, I still do not know where to find a statement about the security of the software and procedures on the host. Sorry to be pedantic.

@dgc:

If someone cracks the host, how easy is it to read a Linode disk image?
In general, you will always be vulnerable to anyone who has hardware access. When the hardware is virtual, as it is for UML, anyone who has root access to the host can monitor or control anything your operating system does. That's just how things work - how else could UML provide all the operating system services in the first place? Reading a disk image should be pretty easy.

If you are worried about this, you can mitigate or eliminate this risk by using encryption on sensitive data. Strong encryption applied elsewhere should be completely secure (from attacks through your Linode); strong encryption applied at receipt on the Linode has only a window of vulnerability with no cleartext on the disk (except possibly in the swap file).

gpg is a good all-purpose tool for encrypting mail and single files. I haven't yet found the ideal client-side encrypted file system, but cfsd works reasonably well on my Linode. Although a cfsd file system is vulnerable while it is mounted (it is designed for quick mounting and can automatically unmount after a period of inactivity), it can't be compromised just by reading the disk.

Thanks rhashimoto.

I'm aware of these considerations. What I am asking is: How hard is to the crack the host? Is Chris the only one with root access and shell access? Can any shell other than the Linode console be run? is the set of executables available on hte host severely restricted, Etc.

Yes, anyonw who can physically access the HW can get control.

Yes the "HW" of a Linode is the host. However this is both quantitatively and qualitatively different from a physicla host. Quantitative: its an additional "HW" vulnerability, not a replacement HW vulnerability. Qualitative: The host is a SW system that can be cracked.

In addition, there is an entire set of new vulnerabilities associated with the iinode system. a cracker could theoretically run a debugger on the host and debug my Linode. This is analagous to someone who could install a hardware debugger on a physical node. Incidentally, this type of attack can defeat the encryption you propose.

To re-emphasize: Chris has almost certainly locked the host down in a way that avoids all this.

Each Linode runs under a different user

Disk Images are owned by root and r/w-group by the Linode user.

There are some other permission restrictions (can't write to home dir), but not really worth mentioning…

root access is restricted to only myself, and in the future any other Linode administrators

There are no shells other than Lish, my user account and the root account

The only process listening to TCP ports on the host is sshd, which I make sure it's up-to-date and vulnerability free

You'd need to be root (or at least the same user) to debug a UML process.

Basically, if the host got rooted, we'd be screwed, just like under a normal environment. So, great care is taken in keeping the hosts up to date. If you have further suggestions, I'm all ears :)

-Chris

Thanks, Chris.

You might consider de-installing all packages you are not using, Worst-case you would need to re-install a package. make everything you can non-readable to anyone except you and root. Then, use an intrusion detection system to periodically scan for any changed exectuables. Since the host is severely locked down, you can probably devise a more rigorous scan.

You can do this in you copious spare time :)

You might also consider making it very difficult to mount on the the Linode "disks" on host file system. Otherwise, a cracker who get root can then mount a linide file system and thereby access all the executables he needs to further expolit the system.

I have no particular reason to thiks we will come under attack. It's just that I got to the "security" section of my "teach yourself to be a system administrator" self-course, and began to think about it.

Whoever has root and/or hardware access theoretically will be able to see your data. Which means the clever thing to do would be to encrypt your data using GnuPG or something similar.

> Then, use an intrusion detection system to periodically scan for any changed exectuables. Since the host is severely locked down, you can probably devise a more rigorous scan.

I believe you're referring to something akin to http://www.Tripwire.org, which is NOT an intrusion detection system (IDS). Tripwire is auditing software. An IDS (http://www.snort.org, for example) is usually a dedicated host (or at the very least, a process) that sniffs traffic for irregularities and patterns. IDSs don't scan or even remotely check for changed executables. There's a huge difference between auditing software and an IDS.

Anyways, I think caker shouldn't need security advice. From what I've seen and observed, things look tight enough. :)

@dgc:

You might consider de-installing all packages you are not using
Probably wouldn't do very much to inhibit someone who's rooted the box already. I suppose this would help to eliminate potential local exploits, if certain binaries are suid.

@dgc:

Then, use an intrusion detection system to periodically scan for any changed exectuables.
Some type of auditing might be useful…

@dgc:

You might also consider making it very difficult to mount on the the Linode "disks" on host file system. Otherwise, a cracker who get root can then mount a linide file system and thereby access all the executables he needs to further expolit the system.
Again, this probably wouldn't stop someone who's already rooted the host.

I've looked at security patches (like grsec), but if someone gets shell access on the host, I already have a problem…

-Chris

Hi Linoders,

Has anybody set up an encryypted filesystem, say with AES? Is it easy to do under UML?

I was thinking of having a separate disk image for holding important files ; ideally it would be encrypted at the filesystem level. (OT: It could also be block copied to another remote site for backup purposes.)

I'd be interested in hearing opinions on this or any alternatives. While a cracker could still gain control of the host, I'd be happy enough if the data was not in clear-text for somebody to casually read.

Thanks.

@ruffnex:

Has anybody set up an encryypted filesystem, say with AES?

I use cfsd on my Debian linode, which works by exporting a directory containing encrypted files over an NFS loopback. It works reasonably well for me.

cfsd is not quite as secure as it could be. Specifically, the root of one of my encrypted directories looks like this:

$ ls -l
total 24
drwxrwx---  11 user user 4096 Sep 16 18:17 0475018383cf3f11/
drwxrwx---  11 user user 4096 Sep 16 18:17 37fd7c96bc4c3834/
drwxrwx---  11 user user 4096 Sep 16 18:17 662b012b720f27dc/
-rwxr-xr-x   1 user user  355 Aug 15  2003 ac961cd559b272b2*
drwxrwx---  11 user user 4096 Sep 16 18:17 af14e73699da8fe2/
drwxrwx---  11 user user 4096 Sep 16 18:17 fd520fa78fa4fd8a/
$

While this does obscure file and directory names and contents, it doesn't hide the directory topology and file attributes.

Even so, I find it useful and consider it adequate for keeping unencrypted information off the physical disk. Backups of the encrypted directory should be mountable on any other system with cfsd, though I have not actually tried this.

I use a loopback encrypted filesystem on my notebook, which basically encrypts everything on any filesystem created on the looped-back partition or file. I briefly looked into doing this on my linode when I first got it, but, at least for the 2.4 kernels, it required a kernel patch and config options that weren't present in the linode kernels, at least at the time. As it wasn't critical, I didn't pursue it, but it might be an option to look into. One disadvantage is that you would need to supply the passphrase on every reboot, meaning that if the host was rebooted for some reason your linode would be down until you went into lish to do so. Also, I don't know enough about the workings of UML but would suspect that if the host was compromised while your linode was active and accessing the encrypted partition, the attacker might well be able to access the data on that partition through your linode somehow. I just like it on my notebook because it eliminates having to consider all the time what info should or should not be secured and just keeps everything on the hard drive encrypted (I use a swap file within the encrypted filesystem instead of a separate swap partition), so any sensitive data is pretty safe should my notebook be stolen or something. Unless it's stolen while it's operating, of course ;-)