Jump Boxes of the Future, Now – Azure Bastion

Introduction

Everyone uses jump boxes. A server / service on your network that serves as a gateway for gaining remote desktop access (SSH and/or RDP) to your servers for administration.

A protective barrier to hide your servers behind when remote desktop access is required. Jump boxes are generally used to limit this special and privileged access to your servers. They prevent direct access and can protect them from exposure to the internet.

However, they also represent a significant hole in the security perimeter of your network for two reasons.

They need a significant level of protection, monitoring and administration
RDP / SSH are two of the most prolifically attacked ports for both source and destination.

RDP and SSH need both a client and a server configured to accept these connections.

Typical jump box configuration from on-premises to Azure for support and admin staff

You can see from the above diagram that the jump box(es) in question require a considered design that is likely to include logging, monitoring, backup, site recovery and security compliance.

So what’s the answer? There are several depending on the services you use and what you need to access. This post discusses Azure Bastion.

Azure Bastion Service

This is a new service currently in preview. It allows you to “remote” onto you servers via HTML5 without an RDP or SSH client. Fully PaaS, it’s a service hosted within your Azure tenant.

You get the advantages of Microsoft managing the underlying infrastructure and protecting it with state of the art security.

Currently only available in a limited number of regions the service is created within a VNet in your Azure fabric deployment using a dedicated subnet with an attached public IP.

So, instead of launching your remote client and making a connection, you log into the Azure portal (which allows MFA and has granular built-in RBAC), and use the Bastion connection function. Your remote session is then launched using HTML 5 over port 443 in a browser window.

There is a public IP attached to the service inside that dedicated subnet, however, you can factor that into your overall VNet design.

Graphical representation of Azure Bastion

Continue reading to see how to create an Azure Bastion host and use it to connect to your VMs.

Creating the Bastion Service

As it is a preview service you’ll need to use the preview URL. Bastion Preview. Then click “Create”. Fill out the requisite parts of the form. It is key that you create a new subnet called AzureBastionSubnet. Bear in mind that this subnet will need to be able to route to the servers you want to connect to.

Add tags as desired.

Review your configuration…

…and create.

You can see from the screenshot below that the public IP is attached to the Bastion.

I’ve created my bastion host service. Now I need some VMs to test with. Crucially I didn’t need to set any inbound port rules as part of VM creation.

VM created.

Connections need to be made through the portal as its is a portal service. Navigate to your VM and click on it to get to the properties page, then “Connect” at the top of the page.

You’ll notice a new tab on the remote connection type, Bastion. Select it and then enter the credentials to remote onto the VM.

And now you’re remoting onto your VM over SSL 443 without using an SSH or RDP client, and without spending hours/days/weeks designing/deploying/managing your own bastion service.