[aklug] Re: My virtual server on Amazon

From: <jonr@destar.net>
Date: Mon May 18 2009 - 10:05:26 AKDT

They would easily be able to log into your VM. They would just change
the root password.

Jon

Quoting Damien Hull <damien@linuxninjas.tv>:

> Hmm... Never thought if it that way... In any case, no data is
> stored on the image. nothing important anyway. When you shut down
> the virtual server all data is lost. Any data you want to save must
> be stored on an EBS.
>
> If the EBS is encrypted an admin at Amazon won't be able to look at
> backup data or mount the EBS. Again, it all depends on how paranoid
> one wants to be. And yes, I know that a running server gives one
> access to the EBS or all my data... Assuming they have a way to
> login to my virtual server...
>
>
> ----- Original Message -----
> From: "Shane R. Spencer" <shane@bogomip.com>
> To: "Damien Hull" <damien@linuxninjas.tv>
> Cc: "Arthur Corliss" <acorliss@nevaeh-linux.org>, aklug@aklug.org
> Sent: Sunday, May 17, 2009 3:19:27 PM GMT -09:00 Alaska
> Subject: Re: [aklug] Re: My virtual server on Amazon
>
> Your X.509 cert determines your authenticity to start the virtual
> machine.. but the machine image itself is not encrypted once it's stored
> @ S3. Not unless they chose to use a crypto loopback device to handle
> your image. Sounds like a waste of cycles since they end up decrypting
> it anyways.
>
> Also.. Amazon gives you your X.509 cert that you generate using their
> servers. Authenticated against their trusted master keys. Sigh.
>
> I have no idea why the images are even encrypted. Anybody? Other than
> marketing and false senses of security can anybody tell me why the
> amazon encryption methods work and how they protect your data, and from
> who? Sure it keeps the stream pretty as it gets uploaded.. lower MITM
> attack rate if it's done that way. That's why I use ssh/scp.
>
> Shane
>
>
> Damien Hull wrote:
>> True... However, so much of what we do is in the cloud. Email and
>> shopping are good examples. There's encryption for email but people
>> don't use it. Our credit card info is encrypted during the
>> transaction process but it's sitting on a server somewhere. That's
>> how the bad guys get it.
>>
>> I think it depends on what kind of data we're talking about. What I
>> post on my blog doesn't need to be encrypted. Documentation about
>> server settings is another story. I might want to keep that safe...
>>
>> Data security will be come a big issue as more and more people use
>> web based applications. Google docs is a good example. How safe are
>> ones doc's on Google?
>>
>> There's no simple answer. I'll watch what I put in the cloud but
>> I'm not taking the paranoid approach.
>>
>> NOTE
>> My Ubuntu server image on Amazon is encrypted. It can't be started
>> with out my X.509 cert.
>>
>> ----- Original Message -----
>> From: "Shane R. Spencer" <shane@bogomip.com>
>> To: "Damien Hull" <damien@linuxninjas.tv>
>> Cc: "Arthur Corliss" <acorliss@nevaeh-linux.org>, aklug@aklug.org
>> Sent: Sunday, May 17, 2009 2:29:38 PM GMT -09:00 Alaska
>> Subject: Re: [aklug] Re: My virtual server on Amazon
>>
>> Somebody somewhere has a funny saying about "Better than nothing".
>>
>> Just remember that your encryption key is in memory on a box somewhere
>> that's out of your control.. And cryptsetup needs to be validated
>> against your package repository before being used. Virtual server
>> environments are fun because of all the security problems they impose.
>>
>> When storing data to an offsite backup system I always back up the
>> result of an encrypted block device, file, or stream. Like when using
>> ecryptfs or encfs, you back up the encrypted directory using tools like
>> rsync since you'll never be able to decypher the names using, say, tab
>> completion. You just have to back up the entire thing.
>>
>> When using duplicity you pipe the output of their stream archive format
>> through GPG running on a local host. This way you control everything
>> assuming you are in control of your own box.
>>
>> Anyways.. it doesn't need to be this tight if the data doesn't require
>> it. But encryption is next to useless if you're doing the processing on
>> a virtual machine on top of a host that you have no control over.
>>
>> Shane
>>
>> Damien Hull wrote:
>>> This is true. Couple of things to remember...
>>> 1. This is all web data...
>>> 2. No different then a real server in some far off data center
>>>
>>> There are exceptions...
>>> 1. Email
>>> 2. Groupware applications that allow users to upload files etc...
>>>
>>> I'm looking at encrypting my data. That doesn't include /etc...
>>> Amazon has a service called the "Elastic Bloc Service" or EBS for
>>> short. Luks Format for block level data encryption... If the EBS
>>> block device is mounted my data is wide open. However, snapshots
>>> would be encrypted...
>>>
>>> It's better then nothing...
>>>
>>>
>>> ----- Original Message -----
>>> From: "Arthur Corliss" <acorliss@nevaeh-linux.org>
>>> To: "Damien Hull" <damien@linuxninjas.tv>
>>> Cc: aklug@aklug.org
>>> Sent: Monday, May 11, 2009 10:12:07 PM GMT -09:00 Alaska
>>> Subject: Re: [aklug] My virtual server on Amazon
>>>
>>> On Mon, 11 May 2009, Damien Hull wrote:
>>>
>>>> I think this is the wave of the future. I don't have to worry
>>>> about hardware... Or fast Internet connections. Very cool!
>>> :-) It sounds interesting, but remember, all things within reason.
>>> Remember, now someone other than you has direct access to any private data
>>> you put on that cloud, whether it be private SSL or SSH keys, your shadow
>>> file, etc.
>>>
>>> Something to think about before you use the same passwords as you
>>> do on your
>>> own systems.
>>>
>>> --Arthur Corliss
>>> Live Free or Die
>>>
>>
>>
>
>
> --
> Damien Hull
> Linux Ninja
> Open Source Assassin
>
> http://linuxninjas.tv
> http://elite.linuxninjas.tv
> http://www.digital-overload.net
>
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon May 18 10:05:38 2009

This archive was generated by hypermail 2.1.8 : Mon May 18 2009 - 10:05:38 AKDT