ok, more to the details.
I. SSH auth. forwarding
=================
on my PC, I have my private SSH key, encrypted with a good password. As I control this environment, I make sure this is the only copy of my private key, and all backup copies are encrypted with other passwords.
On my VPS that I use as a jumphost, I have my public key in .ssh/authorized_keys. So my login does not even have a password on that server.
When I'm logged in to the VPS, I can do
ssh -A ssinyagin@1.2.3.4
with this command, the server 1.2.3.4 authenticates me through my
public key, and the VPS acts as the SSH agent proxy. So, if that server has my public key in .ssh/authorized_keys, I'm easily in, and no security breach on the VPS would affect my security.
II. Secure data on a foreign machine
==========================
so, your VPS is in an untrusted environment, and you need to store sensitive data on it (e.g. VPN configuration and keys).
You create a cryptfs folder, mount it with a manually entered password, and store your sensitive data on it. As long as the server is running, your processes can access the data. If the server reboots, it needs to notify the operator via email or SMS, and the operator logs in and mounts the cryptfs again.
Of course depending on the virtualization technology, your provider may log in from the VM console and see your data. So, you
either trust your provider, or use a physical machine like pcengines. On the latest DENOG meeting, there was an interesting report that offline RAM chips still hold traces of your data for few hours, so be careful with that too :)
As an alternative to cryptfs, you can mount a RAM disk and initialize its content from your home location via an SSH tunnel. If you use Git, you can also do incremental updates to the running system.
III. Off-site backups
==============
what I do is let my home NAS pack the data directory, encrypt it with AES256, and push towards the VPS server. So, nightly I transfer a few hundred megabytes. It works fine as long as I keep the footprint within reasonable limits.
As an alternative, there was somewhere a project that modifies rsync in a way that it can work with encrypted data on
the remote site.
did I miss something?
From: Silvan Gebhardt <gebhardt@openfactory.ch>
To: swinog@lists.swinog.ch
Sent: Saturday, June 2, 2012 11:50 AM
Subject: Re: [swinog] hosting for 1 powersupply with lan port
Good Morning!
The cloud is completely anonymous, that makes the feeling to do
something (as a provider) much lower in my opinion. Knowing someone,
even the face, is much better. Since I know this point I did not
call it "physical security" but "security through obscurity" on
purpose. Since such a plug PC makes extraction of data a bit more
complex - possible always - I gain time. Time when the box is
offline to revoke my keys ;)
I do have to trust the people I will be hosting it with, there is a
reason I do it in switzerland. (Yes, I belive after beeing the
nation of money we will be the *data bankers* soon)
@Stanislav: Interesting flag with SSH -A - I will have to read there
futher, is this something like PFS with IPSEC? never heard about
that flag.
I think we are creating a topic for next swinog here. "Networking
for Mobile workers (Mosh) with paranoia"
Am 02.06.2012 08:57, schrieb Viktor Steinmann:
Interesting topic, especially looking at the current cloud trends.
We've been discussing this internally and came to the conclusion,
that as long as someone has physical access to a server, he will
always be capable of reading the data on that server with more or
less effort.
Even using a high level of physical security to ensure, nobody has
physical access to the box can be broken with enough time and
effort, especially from the people housing the box.
In the end, all you need is trust. If you trust the people housing
your box and if you trust their ability to keep the bad guys
physically away, everything is fine. If you can't trust them you
are lost in any case.
Kind regards,
Viktor
Am 02.06.2012 01:05, schrieb Stanislav Sinyagin:
security by obscurity?
you know, with a JTAG adapter and a bit of
knowledge, one can read the onboard flash from those plugs
too.
so, probably a better approach is to have a system
which doesn't expose your data when the disk is
compromised. The simplest example is SSH with public key
authentication and authentication forwarding (-A flag).
_______________________________________________
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
_______________________________________________
swinog mailing list
swinog@lists.swinog.chhttp://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog