Continuing the Azure Security Center posts, today we will see a new feature of the Security Center, called Just in Time VM Access.

As best security practice, all the management ports of a Virtual Machine should be closed using Network Security Groups. Only the ports required for any published services should be opened, if any.

However there are many occasions that we are requested to open a management port for administration or a service port for some tests for short time. This action has two major problems, first it requires a lot of administration time, because the administrator must go to the Azure Portal and add a rule at the VM’s NSG. The second problem is that many time the port is forgotten open and this is a major vulnerability since the majority of the Brute Force attacks are performed to the management ports, 22 and 3389.

Here comes the Azure Security Center, with the Just in Time VM Access feature. With this feature we can use the RBAC of the azure Portal and allow specific users to Request a predefined port to be opened for a short time frame.

JIT Configuration

Lets see how we configure the JIT.  First we need to go to the Azure Security Center. Scroll down to the ADVANCED CLOUD DEFENSE and click the “Just in time VM Access”. Since it is at a Preview you need to press the “Try Just in time VM access”

After we enable JIT, the window displays tree tabs, the Configured, the Recommended and the No recommendation. The Configured tab displays the Virtual Machines that we have already enabled JIT. The recommended are VMs that have NSGs and are recommended to be enabled for JIT. The No recommendation are Classic VMs or VMs that don’t have attached NSG.

To enable JIT for a VM, go to the Recommended tab, select one or more VMs and press “Enable JIT on x VMs”

At the “JIT VM access configuration” the Security Center proposes rule with the default management ports. We can add other ports that we need and also remove any of them that are unnecessary.

At each rule we can configure the Port, the Protocol, the Source IP and the Maximum request time.

If we leave the “Allowed source IPs” to “Per request” then we allow the requester to decide. One very interesting setting here is that when a user requests access it has the option to allow only the Public IP that he is using at that time automatically.

With the last option, the “Max request time” we narrow down the maximum time that we will allow a port to be opened.

After we configure all the parameters we click Save and the VM moves to the Configured tab. At any time we can change the configuration by selecting the VM, press the three dots at the end of the line (…) and click Edit.

The Propertied button opens the VM’s blade, the Activity log shows all the users that requested access and the Remove of course disabled the JIT.

Behind the scene

What really happens to the VM? if you browse to the NSG that is attached to the VM you will see that all the port rules configured at the JIT are added as NSG Rules with lower priority than all the other rules. All other rules automatically changed priority to higher.

Lets see how we request access and what happens in the background. To request access go to the Security Center / JIT , select the VM and press “Request Access”

At the “Request access” blade switch on the desired port, select “My IP” or “IP Range” and the Timerange, all according to the JIT configuration of the VM. Finally press “Open Ports”

At the above example I select “My IP” so if you go to the VM’s NSG you will see that the 3389 port rule changed to “Allow” and for Source has my current Public IP. Also it moved at first priority.

After the expiration of the time rage the port will change to “Deny” and move back to its prior priority.

At this series of posts we will make a walk along the Azure Security Center, to see some common usage scenarios. Like how we can use it to protect from a Virtual Machine to a whole Data Center.

To make it easier to understand we will start with a typical Azure IaaS scenario. A Virtual Machine with IIS role to act as Web Server. The steps to create the VM is out this post’s scope. I will simply describe the process. First we create a Windows Server 2016 Virtual Machine. Second we log in and add the Web Server (IIS) role. Third we open the port 80 at the VM’s Network Security Group (NSG) and voila we can browse at the Azure DNS name of the VM and see the IIS default landing page.

At this point the security of the Web Server is relying on the Network Security Rule, a layer 3 firewall that allows access to the port 80 and of course the Windows Firewall that does exactly the same.

Lets browse to the Azure Security Center from the Azure Portal. There we see an overview of security settings for the whole subscription.

First, click the “Compute”. I will skip the overview and go directly to the “VMs and computers” tab. There we see the name of the VM and the five points of interest. Our VM is not monitored, it doesn’t have endpoint protection and it reports some vulnerabilities.

Recommendation: Enable data collection for subscriptions

To start resolving the issues click the VM to go to the Recommendations blade. The first recommendation says to enable data collection for the subscription. Of course this is the Log Analytics, OMS (Operations Management Suite) integration. This will enable the subscription resources to report to log analytics.

Press the “Enable data collection for subscription”. The Data Collection blade will open. There we can enable or disable the automatic provision of the monitoring agent. This is the Microsoft Monitoring Agent that connects a Virtual Machine to Log Analytics and also we can use it for connecting to SCOM.

The second option is to chose a workspace. IF you have already created an OMS workspace you can choose it. If not let it create a new one automatically. Finally press save.

Returning to the previous blade you will see that the “Turn on data collection” recommendation, is now in Resolved state.

Although this recommendation is resolved instantly, the Microsoft Monitoring Agent is not yet installed. Go back to the Compute / Data collection installation status to see the agent installation status.

Stay tuned for the next Azure Security Center post to resolve more recommendations.