Over on the Unix/Linux Stackexchange someone asked if ssh’ing to the wrong machine could cause their password to be exposed. I answered “yes”… and was surprised to see the answer get over 140 upvotes. Demonstration So it seems as if there’s some interest in this. I decided to demonstrate this risk in a short practical session. Let’s start with a generic CentOS 7 install. It’s got nothing special on it.
What is a HSM? A HSM is a hardware device that can perform cryptographic functions in a “secure” manner. The idea is that you can load your private key into a HSM and be sure that it’s safe from theft. Anyone tries to physical access the device and it’ll wipe (or literally burn) the data. So encryption or signing of data can be trusted because only the HSM has the key needed to do the crypto.
SSH is probably the most common method of logging into Unix machines over a network connection. It has pretty much replaced the older telnet and rlogin protocols because it encrypts data over the network and has other “goodness”. However one of the “good” parts of ssh is probably the least well managed; ssh keys. What is an ssh key? When attempting to login to a server, ssh will attempt multiple different authenticators.
Something I’ve been pushing (and this is pretty much a truism amongst anyone who’s looked at “Cloud”) is the idea of automation. It doesn’t matter if you’re just treating the cloud as an outsourced datacenter or if you’re doing full 12-factor dynamically scalable apps. Automation is the key to consitency and control. So, ideally, this means your automation system is the “single point of truth” for your estate. Whether you use ansible or chef or (saints preserve us) cfengine, your configuration file explicitly defines your target state.
In a previous blog entry I described some of the controls that are needed if you want to use a container as a VM. Essentially, if you want to use it as a VM then you must treat it as a VM. This means that all your containers should have the same baseline as your VM OS, the same configuration, the same security policies. Fortunately we can take a VM and convert it into a container.
In a lot of this blog I have been pushing for the use of containers as an “application execution environment”. You only put the minimal necessary stuff inside the container, treat them as immutable images, never login to them… the sort of thing that’s perfect for 12 factor application. However there are other ways of using containers. The other main version is to treat a container as a light-weight VM.
A phrase you might hear around cloud computing is lift and shift. In this model you effectively take your existing application and move it, wholesale, into a cloud environment such as Amazon EC2. There’s no re-architecting of the application; there’s no application redesign. This make it very quick and very easy to move into the cloud. It’s not much different to a previous p2v (physical to virtual) activity that companies performed when migration to virtual servers (eg VMware ESX).
In this glorious new world I’ve been writing about, applications are non persistent. They spin up and are destroyed at will. They have no state in them. They can be rebuilt, scaled out, migrated, replaced and your application shouldn’t notice… if written properly! But applications are pointless if they don’t have data to work on. In traditional compute an app is associated with a machine (or set of machines). These machines have filesystems.
A fair number of security advisories mention Man In The Middle (MITM) attacks. It’s quite an evocative phrase, but it’s a phrase meant mainly for the infosec community; it doesn’t help your typical end user understand the risks. So what is a MITM attack, and how can I avoid becoming a victim? Before we get into technology let’s look at something we all know about; the boring snail mail postal system.
In my spare time I’ve been playing on Unix StackExchange. And I’ve found the old song There’s a Hole In My Bucket going through my head. It’s a conversation between Henry and Liza; Henry has a problem and is asking Liza for help. In summary: H: There's a hole in my bucket L: Mend it! H: How? L: With straw. H: But it's too long L: So cut it H: How?
