Securing Veeam Backup for Microsoft Azure: Password/Certificate Auth & Other Hardening Tips

Password Authentication & Certificate Authentications both have their pros and cons, but one undisputed stance is that certificates are more secure than passwords when used properly. To that end, I prefer to deploy certificate authentication when working with SSH, and when deploying Linux VMs, Azure prefers to as well.

However, Veeam Backup for Microsoft Azure also signs you in with your Ubuntu user account, but doesn’t support certificate authentication. Does this mean you’re stuck with password authentication? Nope! Is it complex to configure? Also, nope!

How does this work?

Simply, we’ll ensure that SSH is configured to only support certificate authentication, whilst configuring a password for authentication against the Veeam Backup for Microsoft Azure portal. For good measure, we’ll also go through how to secure this platform further to reduce your attack risk.

Getting set up with Certificate Authentication

Whilst typically the more difficult part, Azure has done a great job of making this straight forward. Create your Veeam Backup for Microsoft Azure virtual machine within the Azure Marketplace, and then when you get to the ‘Administrator account’ section, leave the authentication type as ‘SSH public key’, specify your username and choose to generate a new key pair, you’ll then be given the ability to save your private key. Signing in with this is outside the scope of this blog post, but typically I use PuTTY with PuTTYgen as a tool to convert the private key to a ‘PuTTY Private Key File’ for authentication.

Image displaying the Azure 'Create a virtual machine' configuration web page. A radio button is selected under authentication type, the selected option is 'SSH public key', the 'Username' field is set to the default value of 'azureuser' and the SSH public key source drop down is set to 'Generate new key pair', the key pair name has not been set yet.

Setting up Password Authentication

With our certificate authentication set up and once successfully authenticated, we need to run the following command.

sudo passwd <Username>

Why is sudo necessary here? This is because if we run the command without sudo, it runs as the currently signed in user. That sounds great in theory, but when we run the command as the currently signed in user, there’s another safety check, it asks for the old password, which we don’t have! By running as sudo, we can instead forcibly reset the password.

By configuring the system this way, SSH is not configured to allow password-based authentication, so although the user account now has a password, it can’t be used for SSH access. However, we can now use this password to sign into the web UI for the Veeam Backup for Microsoft Azure portal.

An image displaying the initial configuration screen for Veeam Backup for Microsoft Azure, having successfully signed in with password based authentication.

How can we protect ourselves further?

There are multiple additional steps that can be taken to protect ourselves further, so let’s go through them now:

Patch & Continue to Patch the OS & Application

Whether you have your own in-house tools for patching Ubuntu, or you choose to use the Veeam web UI to patch the operating system, make sure you frequently patch and maintain the operating system. You can patch the system by going into configuration, then support information, then onto the updates tab and select ‘Check and View updates’.

Believe this could be better? Me too! I created a feature request on the Veeam R&D forums to request an automatic patching process, whether scheduled or otherwise, please add your voice to this here.

Harden Network Security Group Configuration

By default, the Veeam Backup for Microsoft Azure image will configure two inbound rules on the NSG, HTTPS & SSH. These are open from any IP address, but that isn’t necessary, so let’s restrict these.

SSH – This only needed for end-user administration of the underlying VM itself, it isn’t required for the operation of Veeam Backup for Microsoft Azure, so I’d suggest disabling this access completely once you’ve done your initial password setup mentioned above. You can always go back into the NSG and enable the rule, with a scope of a single IP address if you need to access in the future. Always be sure to remove the access again once no longer needed, you never know when another SSH vulnerability will be discovered.

HTTPS – Anyone with genuine need to access Veeam Backup for Microsoft Azure needs to access this via port 443, so this would usually be a corporate IP address, Azure VMs also need to access the backup appliance, as does the Azure Service Bus service. I found that the Veeam helpcenter documentation wasn’t sufficient at identifying this setting as it wouldn’t appear within my portal, but if you run the following within an Azure CLI environment, you can get this output:

az servicebus namespace list --resource-group <RESOURCEGROUPNAME>

Once the Service Bus namespace is identified, the corporate IP addresses required for management, and the IP addresses of the Azure VMs are collected, restrict the inbound access to HTTPS to these ports.

Also consider if you’re going to integrate Veeam Backup for Microsoft Azure into Veeam Backup & Replication as the plugin accesses the server via HTTPS and this IP address will need to be included.

Enable Multi-Factor Authentication (MFA)

You didn’t think I’d skip this one, did you? What’s better than a password? A password with MFA! Once signed into the Veeam web UI, go to configuration, Administration > Accounts, and then the portal users tab. And you can enable MFA for your user accounts. You’ll be presented with a QR code and the secret code if you require manually entering this into your MFA application, then you type in the code generated from your MFA device into the field, and you’re all set!

A note on this, the one account you absolutely must not enable MFA on, is if you have a user account for Veeam Backup & Replication integration into Veeam Backup for Microsoft Azure, frustratingly, there’s no way to limit the IP addresses allowed for authentication with these accounts either.

By micoolpaul

Data Protection Consultant, focusing on Veeam, VMware & Microsoft Productivity and Infrastructure stacks.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: