Restricting RDP (Remote Desktop) Access to Azure Virtual Machines

By default, every Azure virtual machine has RDP (Remote Desktop Protocol), port 3389 enabled, and allows any RDP connection from any IP in the world. As great as that is, this can be a (huge) security risk.  So, what if we want to change this, and limit who has RDP access to the VM? What if we want only a select range of IPs, or a specific IP to only have access to the VM(s)? For example, your branch office has a static public IP, and we only want RDP access from this IP/location. How can we achieve this?

Restricting RDP access your VMs in Azure isn’t difficult, but does require some knowledge of Azure Network Security. The solution can be achieved by making use of Azure NSG’s (Network Security Groups). Every VM will have an NSG when it is deployed. If you create an NSG beforehand, you can simply apply the same NSG to new VM deployments.

In the example below, we will need to create 2 NSG’s.

  1. Allowing RDP from a specific IP/CIDR
  2. Denying all RDP traffic

Let’s begin, if you go into the property settings of the VM, and select the Networking Settings, and select, “Add inbound port rule“. Click on the wrench, to switch from Basic to Advanced.

The Inbound Security Rule properties, as follows:

Wait, what do all of these fields mean?

  • Source: The source can by any IP Address, or CIDR Range, or a default-service tag.
  • Source IP Address/CIDR Ranges: Any IP Address, or CIDR Range.
  • Source Service Tag: There are a series of options here, but in short:
    • Load Balancer: Any probes in the Azure Load Balancer
    • Virtual Network: The Virtual Network the VM is connected to
    • Internet: All network traffic in the public virtual network, (including all Azure services, such as Azure Traffic Manager, Storage and SQL)
    • Azure Traffic Manager: Denotes the IP address from where the Azure Load Balancer health probes will origiante.
    • Storage.*:  Access to Azure storage services and/or specific Azure regions
    • SQL.*: Access to Azure SQL Database and Warehouse services, and/or specific Azure regions
  • Source Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Destination: The source can by any IP Address, or CIDR Range, or the Virtual Network.
  • Destination Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Protocol: TCP or UDP, or Any, which includes both TCP and UDP, and ICMP.
  • Action: Allow, or Deny access.
  • Priority: A number between 100-4096. The lowest is 100, and the highest we can input is 4096. Lower the number, higher the priority.
  • Name: The name of the rule. Note, once created, it cannot be changed!

So, these are the values/settings I implemented for the Allow Inbound Rule:

  • Source: IP Addresses
  • Source IP Addresses/CIDR Ranges: xxx.xxx.xxx.xxx
  • Source Port Ranges: *
  • Destination: Any
  • Destination Port Ranges: 3389
  • Protocol: TCP
  • Action: Allow
  • Priority: 4095
  • Name: default-allow-rdp

Next are the values/settings I implemented for the Deny all RDP Inbound Rule:

  • Source: ServiceTag
  • Source Service Tag: Intenert
  • Source Port Ranges: *
  • Destination: Virtual Network
  • Destination Port Ranges: 3389
  • Protocol: Any
  • Action: Deny
  • Priority: 4096
  • Name: Deny-RDP-Access

 

The Outbound Port Rules should look something like this now. Why we set Priority the way we did… Well, Rules are checked in the order of priority. Once a rule applies, no more rules are tested for matching.

 

Once the rules has been submitted, and accepted, and if we try to RDP into the VM we should now only be allowed from the IP Range, or IP! Success!!

 

To learn more on Azure NSG (Network Security Groups), visit: https://docs.microsoft.com/en-us/azure/virtual-network/security-overview

Advertisements

Global Azure Bootcamp 2018 – Azure Application Insights

On April 21st, 2018, all (Microsoft user groups) communities throughout the world, will be participating in the Global Azure Bootcamp. This year, I will be speaking on Azure Application Insights, at the Mississauga (GTA) Azure Bootcamp.  This event is free, and open for everyone and anyone to join!

All around the world user groups and communities want to learn about Azure and Cloud Computing!

On April 21, 2018, all communities will come together once again in the sixth great Global Azure Bootcamp event! Each user group will organize their own one day deep dive class on Azure the way they see fit and how it works for their members. The result is that thousands of people get to learn about Azure and join together online under the social hashtag #GlobalAzure!

To find out if Azure Bootcamp is in your area, please visit, https://global.azurebootcamp.net/.

Blocking Internet Access for Azure Virtual Machines

By default, every Azure virtual machine (VM) has access to the Internet. Sometimes this is great, but in most enterprise environments, server’s have Internet access restricted. So, how to restrict Azure VMs gaining access to the Internet?

Restricting Internet access to your VMs in Azure isn’t difficult, but does require some baseline knowledge of Network Security. The solution can be achieved by making use of Azure NSG’s (Network Security Groups). Every VM will have an NSG when it is deployed. If you create an NSG beforehand, you can simply apply the same NSG to new VM deployments.

In the example below, I am going to update the NSG for a specific VM. Of course, once the NSG has been modified, you can apply this NSG to other VMs too and/or future VMs.

Let’s begin, if you go into the property settings of the VM, and select the Networking Settings, and select, “Add outbound port rule“. Click on the wrench, to switch from Basic to Advanced.

The Outbound Security Rule properties, as follows:

Wait, what do all of these fields mean?

  • Source: The source can by any IP Address, or Range, or a default-service tag. CIDR ranges are also accepted.
  • Source Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Destination: The destination can by any IP Address, or Range, or a default-service tag. CIDR ranges are also accepted.
  • Destination Service Tag: There are a series of options here, but in short:
    • Load Balancer: Any probes in the Azure Load Balancer
    • Virtual Network: The Virtual Network the VM is connected to
    • Internet: All network traffic in the public virtual network, (including all Azure services, such as Azure Traffic Manager, Storage and SQL)
    • Azure Traffic Manager: Denotes the IP address from where the Azure Load Balancer health probes will origiante.
    • Storage.*:  Access to Azure storage services and/or specific Azure regions
    • SQL.*: Access to Azure SQL Database and Warehouse services, and/or specific Azure regions
  • Destination Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Protocol: TCP or UDP, or Any, which includes both TCP and UDP, and ICMP.
  • Action: Allow, or Deny access.
  • Priority: A number between 100-4096. The lowest is 100, and the highest we can input is 4096. Lower the number, higher the priority.
  • Name: The name of the rule. Note, once created, it cannot be changed!

So, these are the values/settings I implemented as a result:

  • Source: VirtualNetwork
  • Source Port Ranges: *
  • Destination: Service Tag
  • Destination Service Tag: Internet
  • Destination Port Ranges: *
  • Protocol: Any
  • Action: Deny
  • Priority: 4096
  • Name: Deny-Internet-Access

The Outbound Port Rules should look something like this now:

Once the rule has been submitted, and accepted, if we go to our VM, we will now most definitely be denied Internet access! Success!!

 

To learn more on Azure NSG (Network Security Groups), visit: https://docs.microsoft.com/en-us/azure/virtual-network/security-overview

How to Increase ASR (Azure Site Recovery) Replication and Failback Default Settings

Now that you have deployed ASR (Azure Site Recovery), for Hyper-V and have started to up being replication, you notice the replication process just might take forever, as there are several VMs still queued. That is right, by default, ASR will replicate 4 (four) VMs at a given time. This value can be increased (to a maximum of 32), however, where to change this setting?

In order to increase the number of replication threads from 4 to 32, or whatever in between, you first need to launch the Registry and navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication

From there, you will need to create the key, if the key does not exist (I have never see it by default in any of my deployments…). Create the key, “UploadThreadsPerVM” and set its value to whatever you see fit. Again, the maximum is 32.

Likewise, you can increase the default (4) number of threads used for data transfer during failback. This value represents the maximum number of VMs that will failback from ASR. That path is the same, and the Registry Key is,”DownloadThreadsPerVM“, and again, can be set to a maximum of 32.

After that is completed, your Hyper-V Registry Keys, would look something like this. Please note, this change is fully supported by the ASR/Microsoft team. However, do note, this change can saturate your network due to the increase in uploads to Azure. You can also increase and change the schedule for the bandwidth throttle settings, you can see that previous post here, see Step 10.

 

For additional information on this, please visit, https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-plan-capacity-vmware#control-network-bandwidth.

Azure Update Management – Part II

A little while ago, I blogged on OMS’ (Operations Management Suite) Update Management Solution. As great as this solution was, there were some limitations at the time, such having the ability to exclude specific patches, co-management with SCCM (Configuration Manager), and few others.

Since that post, there have been some great improvements to Update Management, so let’s go over some of the key updates, and do a quick setup walk-through:

  1. Both Windows (2008R2+) and (most) Linux Operating Systems are supported
  2. Can patch any machine in any cloud, Azure, AWS, Google, etc.
  3. Can patch any machine on-premises
  4. Ability to Exclude patches

One of the biggest improvements I want to highlight is, the ability to EXCLUDE patches, perhaps in time there will also be INCLUDE only patches. 😉

First, we need to get into our Azure VM properties.. Scroll down to the Update Management.

  • If the machine belongs to a Log Analytics workspace, and/or does not have an Automation Account, then link it now, and/or link/create the Automation Account
  • If you do not have an Log Analytics workspace and/or an Automation Account, then you have the ability to create it at run-time now.

In this scenario, I kept it clean as possible, so both the Log Analytics workspace needs to be created, and likewise for the Automation Account, and Update Management needs to be linked to the workspace.

Once enabled, it a few minutes to complete the solution deployment….

After Update Management has been enabled, and it has run its discovery on the VM, insights will be populated, like its compliance state.

Now we know this machine is not compliant, as it missing a security update(s), in addition, missing 3 other updates too. Next, we will schedule a patching deployment for the future. So let’s do that now.

Now we can create a deployment schedule with some base settings, name, time, etc. But one thing to note, we can now EXCLUDE specific patches! This is a great feature, as let’s say, we are patching an application server, and a specific version of .NET will break our application, as the application Dev team has not tested the application against the latest .NET framework.

In this demo, I am going to EXCLUDE patch, KB890830.

Next, we need to create a schedule. This can be an ad-hoc schedule, or a recurring schedule.

Once you hit create, we can now see the Deployment Schedule, under Scheduled Update Deployments.

You can also click on the deployment to see it’s properties, and which patches have been excluded.

After the deployment has initiated, you can take a look at its progress.

If we go into the Update Deployment (yes, I got impatient, and deleted the first one, and re-created it…), and click on the Deployment we created, we can see the details.

As you can see, patch, KB890830 was not applied! Awesome.

If we not go back to the Update Management module, we can now see the VM is compliant.

 

Azure Virtual Network (VNet) Peering

In this blog post, I will go over,

  • What is Azure VNet (Virtual Network) Peering,
  • When to use VNet Peering,
  • How to implement VNet Peering.

What is Azure Virtual Network (VNet) Peering?

Azure VNet (Virtual Network) Peering enables resources within two separate virtual networks to communicate with one another. Leveraging Microsoft’s backbone infrastructure, the two peered virtual networks will communicate over its own isolated network.

Below we have two Virtual Networks (VNet01 and 02), that have different IP Address spaces. By implementing VNet Peering, the two networks will be able to communicate with one another, as if all resources are in one network. Some notes, VNet Peering is not transitive, ie. If VNet01 and VNet02 are Peered, and VNet02 and VNet03 are Peered. This means, VNet01 and VNet03 cannot communicate with one another. Another note, inbound and outbound traffic in the VNet Peer are $0.01 per GB. Prices are a bit higher for Global VNet Peering. Get the official numbers here, https://azure.microsoft.com/en-us/pricing/details/virtual-network/.

When to use Azure Virtual Network Peering?

As mentioned above, you want to enable Azure VNet Peering when you have two virtual networks that have resources (VMs) in both networks that need to communicate with one another. For example, let’s say you have exhausted 4,000 VM limit within a VNet…

Some of the benefits of VNet Peering is:

Before you go ahead and implement, there are a few requirements:

Finally, how to implement it!

In this example, both of my virtual networks (VNets) are in the same region, Canada Central.

Select VNet01, and select Peering:

 

Give the Peering a name, “VNet01Peering” and select the other VNet, VNet02.

 

Give it a few seconds, and it should now be connected to VNet02:

Next, we now need to apply the same concepts to VNet02. So let’s do that now.

 

 

Now if we go to the VMs within each of the Virtual Networks, and try to ping another VM in the other VNet, it should now work! Based on the images below, you can see the Ping failed, that was from a previous ping response prior to VNet Peering being implemented.

VM01 in VNet01 trying to Ping VM02 in VNet02; 10.10.10.4 -> 192.168.1.4: 10.10.10.0/24 -> 192.168.1.0/24.

And conversely, the other way around…

VM02 in VNet02 trying to Ping VM01 in VNet01; 192.168.1.4 -> 10.10.10.4 -> : 192.168.1.0/24 -> 10.10.10.0/24.

 

System Center – Operations Manager 1801 is now available!

Yesterday afternoon, Microsoft released Operations Manager (System Center, SCOM) version 1801. This is a major change from previous versions of SCOM/Operations Manager, as it now introduces the same release cycle as Windows Server 2016 and Windows 10, ie. Semi-Annual Channel (SAC).

Like Server 2016, and Windows 10, all new features and updates will be delivered in the Semi-Annual Channel (SAC) manner.

Within the Semi-Annual Channel (SAC) model:

  • Each build, ie. 1801 is supported for a minimum of 18 months from its release date;
  • Consistent updates and features within the 6-months (semi-annual) time frame;

In the Operations Manager 1801 version, some of the new features include:

  • Service Map integration;
  • Linux Kerberos support;
  • Linux Log File monitoring improvements;
  • Improvements to the SDK performance;
  • Telemetry for HTML5 dashboard, plus improvements/performance;
  • 3rd Party Management Pack – Updates and Recommendation;

For more information, have a read at the Microsoft blog post: https://docs.microsoft.com/en-us/system-center/scom/what-is-new-1801?view=sc-om-1801

 

Over the next few days, I will spend some time on deploying Operations Manager 1801, so stay tuned for that post! Until next time.

If you want to deploy Operations Manager 1801, go here for the System Center Evaluations download: https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-release