Abstract

Public cloud environments require system administrators access the cloud hosts for system level activities over untrusted networks. In order to maintain perimeter security so-called jump or bastions hosts are used to reduce the attack surface. This paper discusses a mechanism to provide very strong bastion host through the use of shared SSH keys with planned obsolescence in combination with individual SSH key. The result is a bastion that is secure, with minimal burden to administrators for user access maintenance.

High Level Concepts

Barbican

A barbican is a fortified outpost or gateway, such as an outer defense to a city or castle,
or any tower situated over a gate or bridge, which was used for defensive purposes. Usually barbicans were situated outside the main line of defenses and connected to the city walls with a walled road called the neck. Deployment of two bastion hosts straddling a firewall can serve the function and neck to allow controlled access to the protected cloud environment.

 

Bastions

The external bastion, being outside the firewall, is exposed to the world. The internal bastion, being inside the firewall, is only accessible by the external bastion. Each bastion host provides the door while the firewall enforcement creates the neck of the barbican.  Entities wanting to transit the barbican must authenticate against both bastion checkpoints.

Authentication Domains

Going through the trouble of creating a two-bastion barbican is all for naught if there is only one set of tokens that will allow transit through both checkpoints.  Consequently it is beneficial to require two sets of authentication tokens to successfully transit the barbican.

Just like the concentric walls of a castle have outer walls that are lower than the inner walls, so should the stringency of the authentication tokens mimic the strength of the walls. The outer authentication domain token may be shared amongst all authorized users of the cloud environment, while the inner authentication domain token should be individualized to each user.  The outer authentication domain token could be further divided by role, eg sysadmin, netadmin, appadmin, dba, etc.

Tokens

SSH’s key-based authentication is used as the mechanism for exchanging authentication tokens with each of the bastion hosts. The tokens are configured to behave differentially in each of the domains.  The table below summarizes the differences.

Property of Token	Outer domain	Inner domain
Scope	Shared	Individual
Lifetime	Ephemeral	Persistent
Generation	Automated by Service	User-generated
Server-side Enablement	Periodically by Service	Once at creation time
Client-side Enablement	Periodically by User	Once at creation time

Implementation

Service Key Generation and Distribution

Cron-based, PGP encoded, upload to FTP or webserver for distribution.  Once
for each role.

Service Key Installation and enablement

Cron-based, build the authorized_keys file with n-many generations, upload to the external bastion. Once for each role.

External Bastion

Simple host. No end-user accounts. Provide no services. Guard against escalation of privilege Provide command for accessing the internal bastion for convenience. Routinely clean shared user’s home directory. Use IPTables to control inbound access to ports

Internal Bastion

No shared accounts. Provide limited services. Guard against
escalation of privileges.

Firewall

Use a firewall to enforce no sideways access to the internal bastion. This is the equivalent of the neck in the barbican.

Syslog

Without monitoring all systems succumb. Simple syslog receiver to listen in on the comings and goings of the barbican.

Operations

Initial setup

User provides own public key to service for installation as part of initial procurement of authorized user access. User downloads and installs the service’s ephemeral/service key onto their workstation. The ephemeral key must be renewed periodically by the user.

Day-to-day Use

User initiates SSH session with external bastion using the service’s ephemeral key. User initiates second SSH session with internal bastion using their own persistent key through SSH Agent forwarding methods.