Linux – Client Technology Solutions & Consulting

Efficient Data Replication with ZFS

This year, I have been working with one of our clients on a typical research-oriented server setup, including a few compute servers mounting a single shared storage over NFS, which is a common and well-tested configuration. The main difference for this project was the size of the storage. At the time when our team became engaged with this client, they were using ten assorted storage servers based on Linux and FreeNAS. In order to replicate the data between these servers, rsync was being used. Additionally, an elaborate scheme was in place to make sure that each dataset is housed on at least two different servers. All of the storage servers were outdated and out of warranty, so the client agreed to procure new hardware and build a new setup from scratch.

Following the example of Research Computing team, Ubuntu was selected as a base operating system for both compute and storage servers deployed on commodity Supermicro hardware resold by Colfax. Cost-effectiveness of the deployment was deemed as a decisive factor by the client. To achieve the maximum storage density, a client opted for a single 60-drive primary storage server with ZFS file system. ZFS brings with it all the advantages of a copy-on-write file system with features, such as instant copy, snapshots, flexible volume management, built-in NFS sharing, error resilience and correction.

Below I am going to discuss SEND/RECEIVE feature of ZFS, which allows to easily and efficiently replicate large volumes of data.

Shibboleth on Apache 2.4 Using Mixed Authentication Methods

by Jonathan Lent

Like many developers, application maintainers, and system administrators at Stanford, I’ve been focussing a lot of time lately on migrating legacy web applications to using Shibboleth (from WebAuth). Also like many, I’ve found Alex Tayts’ article Migrating away from WebAuth: practical steps very useful during this process. However, as straight-forward as that writeup is, it doesn’t account for one thing: the Shibboleth SP software is not perfect.

During a recent deployment, I found that by simply enabling the shib2 Apache module on systems with Apache 2.4 running, applications using multiple AuthTypes (e.g. WebAuth and basic authentication) were suddenly presenting a 401 (Unauthorized) error message. This was before adding any directives to use Shibboleth as the AuthType.

Continue reading “Shibboleth on Apache 2.4 Using Mixed Authentication Methods”

Using Shibboleth with nginx

Unlike Apache, nginx does not have a module like mod_shib interacting directly with Shibboleth daemon shibd. I will use a module ngx_http_shibboleth_module, which uses FastCGI protocol to talk to Shibboleth daemon through sockets. Shibboleth comes with two FastCGI modules:

FastCGI responder (shibresponder) that handles the HandlerURL
FastCGI authorizer (shibauthorizer) that acts as a filter and does the usual (authN, export assertions and authZ).

Of course, these modules have to be running alongside the shibd daemon. Let’s start with Shibboleth setup and configuration. I used Ubuntu 16.04 LTS (Xenial) for the setup described in the article, but it can be easily ported to other versions of Linux.

There are some guides around on how to get such configuration working, but all of them seem to be missing one or more crucial steps. This is the drawback which I tried to remedy with this article.

Avoiding a Faux-PAW: Ditching my Beloved Jump Host

by Jonathan Lent

Background

The Information Security Office (ISO) has created a set of Minimum Security Standards (MinSec), broken down with a matrix of applicability depending on the risk classification of a given system (low, medium, or high) [1]. Of these standards for high-risk systems, one requires the use of a dedicated admin workstation for administration (also known as a Privileged Access Workstation (PAW), or Personal Bastion Host (PBH)) [2]. Unlike many of the MinSec requirements, this standard doesn’t hinge so much on a technical implementation detail; rather, it requires a simple set of technical changes (firewall rules), along with a drastic change in daily workflows for folks like me.

Before I go into why shared jump hosts can be a source of risk, it’s important to maintain an open mind and reiterate why these setups can be useful. To be clear, by “jump host”, I mean a hardened server that is used to gain access to other resources. Without going into any implementation-specific details, jump hosts are often on the short list of machines (or the sole source) that can connect to various ports on endpoints. The machine ideally would be locked down to restrict authentication access (e.g. not only a carefully scrutinized list of users, but additional tweaks requiring specific protocols for access (e.g. Kerberos, rather than password authentication)). This is indeed more secure than some of the alternatives (e.g. world or domain-wide access to individual endpoints). With proper planning these hosts can be hardened to eliminate the potential for many issues outlined below. However, the weakest link in computer security often lies with the human element, and that’s one aspect of the shared model that cannot be ignored. Continue reading “Avoiding a Faux-PAW: Ditching my Beloved Jump Host”

Migrating away from WebAuth, practical steps

Stanford University is in the process of migrating from its homegrown authentication system, WebAuth, to the widely deployed and feature-rich SAML-based authentication. This brings a lot of benefits, like better compatibility, wider application support and easy federation with other institutions.

There are multiple SAML (Security Assertion Markup Language) implementations, but this article is focuses on two of them, Shibboleth and SimpleSAMLphp.

Shibboleth is well-documented and there are Stanford UIT documentation pages with high level descriptions of how it fits into the Stanford infrastructure. In this article I will talk about the practical steps one has to take to migrate from WebAuth to Shibboleth or SimpleSAMLphp, how to set them up and what adjustments have to be made to the configuration files on the SP (Service Provider) side.

Parts of the article are a rehash of the official UIT Shibboleth documentation with some corrections and explanations of the steps pertinent to the topic of migration from WebAuth. The content is based on our client’s questions and the issues we encountered while performing these migrations for our clients. Continue reading “Migrating away from WebAuth, practical steps”