Protecting Azure VM from unwanted attempted access with ACLs

For about the past two weeks, I’ve been noticing that my server has been running a little slow. It’s a tiny server and I was just chalking it up to that – small server = not great response, no biggie right? Yesterday however, My server was down for good, which actually turned out be unrelated… but what I found was a little unsettling. While I was looking through my servers Event Viewer I noticed a lot of failed log ins going to MSSQL… and I mean, 4-5 a minute failed log ins… for over a week. Needless to say, somebody was trying to get access to the data in my SQL via some sort of Brute-Force or Dictionary attack.

Here what Event Viewer looked like (x10000)

2015-04-14_UnderAttack

There were tons of different IPs being used to attempt these log ins

222.186.51.165, 219.235.1.82, 111.73.45.18, 107.160.9.212 — the list goes on

this means someone’s also spoofing their IP address like anyone trying this sort of thing would. The one in the above image for example is supposedly from the city of Nanjin in Jangsu, China… another one identified as being from California. You can easily find out where an IP address is located by using free services like whatismyip.com, however, it doesn’t mean much when your attacking is spoofing their IP address to throw you off the trail.

This could have been easily avoided had I taken the necessary preventative measures. Azure’s VM management allows for the easy control of an ACL over each VM you may have. ACL, if you don’t already know, stands for Access Control List. What it does, is exactly like what it sounds like it does, it’s a list that controls access to your machine. This is done by permitting and/or denying selected ranges of IP addresses.

When you choose a VM from from your list of Azure items, you’re brought that VM’s dashboard.

2015-04-14_TheDashboard

The third item on the row of tabs for your VM are your endpoints which are used for connecting to that VM via Remote Desktop, PowerShell, and SQL. Each endpoint is allowed to have to have it’s own ACL in order to provide access from whomever may need that resource and deny everyone else that shouldn’t have access. When you choose one of the endpoints, in the footer menu of the page, the option for ‘MANAGE ACL’ will appear.

2015-04-14_MANAGE_ACL

Once MANAGE ACL has been selected, a window will appear

2015-04-14_ACL_LIST

This is where you’ll actually provide the permitted IP ranges as well as the denied IP ranges. ACLs work top to bottom, if you deny an address up top, then permit it lower down, that address will be denied. If you do the opposite and permit an address up top then deny that address lower down the list, that address will be permitted. The remote subnet requires a CIRDR address which uses a {ipAddress}/{subnetBits} notation – you may need to do some research on this to permit or deny the correct ranges of addresses. The best way to ensure that no one but you want to permit access to the endpoint is allowed in is by putting the permitted address in then on the bottom of the list, enter the CIDR address 0.0.0.0/0 — this will deny everyone who was not approved before this point. Any address afterwards will not be permitted.

2015-04-14_ACL_LIST_MODIFIED

Addresses beginning in 192.168 area addresses reserved for interfaces that aren’t actually connected to the internet – so this address isn’t actually viable. You can use WhatIsMyIP.com here as well to discover what your actual Public IP address is. Once your ACL list is finished, click the checkbox on the bottom and Azure will set the rest up for you in a matter of seconds.

Advertisements

2 thoughts on “Protecting Azure VM from unwanted attempted access with ACLs”

  1. Another good idea is to set up a virtual network and a gateway and only expose actual public endpoints. By connecting to the vnet, your computer gets direct access to the VMs as if they were local on your own network. It takes a little while to read up on, but the security you gain is great.

Leave a Reply

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 )

Google+ photo

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

Connecting to %s