Why A Bastion Host Is Necessary For Remote VM Administration (Including Azure)

This post will explain why you should use a “Bastion Host” or a “Jump Box” to securely remote into Linux (SSH) or Windows (Remote Desktop) virtual machines. And this advice also includes machines that you run in a cloud, such as Microsoft Azure.

For the Fundamentalists on Social Media

Some people are going to make some comments like:

“This is why you should use remote Bash|PowerShell scripting”

Or maybe:

“You should be using Windows Admin Center”.

Windows Admin Center – great! Genuinely. But it does not do everything.

There are still many times when you need to directly log into a machine and do something; that’s real life, and not some blogger’s lab life.

Security Center JIT VM Access?

I was a fan of this feature. That was until they changed how the allow (RDP, SSH, etc) rules were added to an NSG. In my work, every subnet is micro-segmented. That means that the last user-defined NSG rule is Deny All from * to *. Since JIT VM Access was changed, it moves the last rule (if necessary) and puts in the allow-RDP or all-SSH (or whatever) rule after the DenyAll rule which is useless. Feedback on this has been ignored.

Why Are SSH and RDP Insecure?

I can’t comment too much on SSH because I’m allergic to penguins. But I can comment on RDP. Over the last few months, I can think of 3 security alerts that have been released about pre-authentication vulnerabilities that have been found in Remote Desktop. What does that mean?

Let’s say that you have a PC on your WAN that is infected by malware that leverages a known or zero-day pre-authentication remote desktop vulnerability. If that PC has the ability to communicate with a remote VM, such as an Azure Windows/Linux VM, via SSH or RDP then that remote machine is vulnerable to a pre-authentication attack. That means that if malware gets onto your network, and that malware scans the network for open TCP 22 or TCP 3389 ports, it will attempt to use the vulnerability to compromise the remote VM. It does not require the user of the PC to SSH or RDP into the remote VM, or to even have any guest OS access! You can put a firewall in front of the remote virtual machines, but it will do no good; it’s still allowing TCP 3389 or TCP 22 directly into the virtual machines and all it will offer is logging of the attack.

A Bastion Host

You might have heard the term “bastion” in the Azure world recently. However, the terms Bastion Host or Jump Box are far from new. They’re an old concept that allows you to isolate valuable machines and services behind a firewall but still have a way to remote into them.

The valuable remote virtual machines are placed behind a firewall. In Azure, that could be a firewall appliance, such as Azure Firewall, and/or Network Security Groups. Now to connect to the remote VMs, you must first remote into the Bastion Host. And from that machine, you will remote further into the network through the isolation of the firewall/NSGs.

But that’s still not perfect, is it? If we do simple SSH or RDP to the Bastion Host, then it is vulnerable to pre-authentication attacks. And that means once that machine is compromised, it can attack further into the remote network. What we need is some kind of transformation.

Remote Desktop Gateway

My preferred solution is to deploy a Remote Desktop Gateway (RDGW) as the bastion host – this does not require RDP licensing for administrative access to the remote virtual machines! The Bastion Host is deployed as one virtual machine or 2+ load-balanced virtual machines that allow in HTTPS connections via firewall/NSG rules. When an administrator/developer/operator needs to log into a remote VM, their Remote Desktop client is configured to connect to this gateway using HTTPS instead of RDP. Once the connection is authenticated by the RDGW, it reverse proxies the connection through to the desired virtual machine, further protected by firewall/NSG rules. Now the malware that is on the WAN cannot probe any machines in the remote network; there is no opening across the network to TCP 3389 or TCP 22. Instead, the only port open for remote connections is HTTPS which requires authentication. And internally, that transforms to connections from the RDGW to the remote VMs via TCP 3389.

Some sharp-eyed observers might notice that the recently announced CVE-2020-0609  is a pre-authentication attack on RDGW! Yes, unpatched RDGW deployments are vulnerable, but they are smaller in number and easier to manage patches for than a larger number of other machines. Best practice for any secure network is to limit all external ports. Transforming the protocol in some way, like an RDGW, further reduces the threat of that single opening to a single service that forwards the connection.

If you want to add bells and whistles, you can deploy Network Policy Server(s) to centrally manage RDGW policy and even add multi-factor authentication (MFA) via Azure AD.

This is great for Windows, but what about Linux? I’m told that Guacamole does a nice job there. However, Guacamole is not suitable for recent releases of Windows because of how it must have hardcoded admin credentials for Network Layer Authentication (NLA).

Azure Bastion

Azure Bastion made lots of noise in IT news sites, and on blogs and social media when it went into preview last year, and eventually it went GA at Ignite in November of last year. Azure Bastion is a platform-based RDGW. Today (January 2020), I find it way too limited to use in anything but the simplest of Azure deployments:

  • The remote desktop authentication/connection are both driven via the Azure Portal, which assumes that the person connecting into the guest OS even has rights to the Azure resources.
  • It does not support desktop Remote Desktop/SSH clients.
  • It does not offer MFA support for the guest OS login, only for the Azure Portal login (see above).
  • VNet peering is not supported, limiting Azure Bastion to pretty simple Virtual Network designs.

If Azure Bastion adds VNet peering, it will make it usable for many more customers. If it understands that guest OS/Azure resource rights OS/Azure Portal logins can be different, then it will be ready for mid-large enterprise.

 

Please follow and like us:

6 Replies to “Why A Bastion Host Is Necessary For Remote VM Administration (Including Azure)”

  1. Hi Aidan,
    Excellent post like all the time. 🙂
    But what about GPO to allow RemoteManagement/RemoteShell only by some restricted IPs like the PAWs (Privilegied Access Workstations) ? Some words about this ?

    Regards
    Olivier

      • A PAW is a computer
        – without any Internet connection
        – where only users accounts members of a specific AD group can looged to.
        – that could be on a specific/dedicated VLAN (like a bastion)
        – … and also a computer with hardening (by diffrents ways like specific GPO …)

        It’s one solution for On-premises or Cloud. But, i agree, it’s easier to deploy a bastion with Azure.

        In one of my customers : 4 accounts in a domain.
        – All nominatives
        – All with good password policies.
        – A White account like the other users (Mail, Internet, access resources, etc) : can log on “White workstations”
        – A Green account can log only on Green PAW, to manage servers classified Green. No access to the Net with this account
        – A Yellow account. Same thing for Yellow PAW and Yellow servers (more sensibles)
        – and Red Account : cans only log on to Red PAW, and only to manage Red Servers (DCs only).
        After that, If i plug a USB Key on a PAW with malware or some other bad things, it’s not good … for my customer … and for me. A lots of things are logged and send to differents S.I.E.M. like Splunk or MS ATA. And the customer SOC team is very reactive, trust me (one day i show to a colleague how, with a simple nslookup i could do a DNS transfert zone if the DNS Server was misconfigured. Less that 1h, i was contacted by the SOC.).

        As we always hear : 90% of the problems are located between the chair and the keyboard.
        As I always say : if something should not be done, it must be technically difficult, or better, impossible to do. 🙂

        To return to the initial subject, a bastion is the only end-point allowed to give acces to servers. A PAW could be exactly the same … but if, from a simple workstation, a admin account is allow to exec Remote Shell command, perform Remote Management, or open direct RDP sessions to servers, this is a security problem (i.e. : computer compromise, PtH or PtT method to privileges elevation, lateral deplacment, … and do very bad things finally). A Bastion or a PAW offer this security. Only allowed accounts (admins) can used them.

        P.S. : Sorry if my english is not so perfect that i would, it’s not my mother tongue. Not a justification, I know that, just an explanation. 🙂

  2. Hi Aidan,

    Can you clarify what you mean by RDGW – “this does not require RDP licensing for administrative access to the remote virtual machines!”

    Do you mean the 2 admin connections you can have by default?

    • Correct. If you are only using the 2 admin connections on each VM that you are logging into sessions on, then you do not need RDP licenses. Remember – you are not logging into sessions on the RDGW machines. But as soon as you decide to use VDI or RDS Session Hosts, you need the licenses.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.