July 28, 2014 5 Comments
I am a big advocate of using Microsoft Azure VMs for lots of uses—many clients don’t have the wherewithal to manage a full scale data center operation, or in other cases they don’t have the budget for a second data center for disaster recovery. Azure is a great use case for those options, as well as quickly spinning up dev environments for testing new releases or doing a proof of concepts. In fact, I’m currently working on a PoC for a client and we are using Azure IaaS and Power BI for Office 365.
The biggest fear most people have around cloud computing is the security aspect—they don’t trust their data not to be in their data center. In general, I think Microsoft (and Amazon) have way better security than most data centers that I’ve ever set foot in, but whenever you are using a cloud provider, you have to have a good understanding of the nuances of their security model. One thing to note about Microsoft Azure is that all virtual machines get their own public IP address (personally, I feel like this a waste of a limited resource, as VMs that are within virtual networks generally have no need for a public facing IP address, but that’s a different blog post) and security is provided by creating endpoints (by default the SQL Server template opens PowerShell, RDP and 1433 for SQL Server). Access to these endpoints can be controlled by ACL—you can define a list of IP addresses (presumably the other machines in your network) that can talk to your VM over that endpoint. However, by default, your new VM is accessible on port 1433 to the entire internet.
I was troubleshooting connectivity from my SharePoint VM to my SQL Server VM this morning, and I went to the SQL Server log, and I found:
Figure 1 Log of Failed Logins
Those IP addresses aren’t on my virtual network, and they aren’t the public IPs of any of the servers in my network. Let’s use an IP lookup service to see where they are from:
Figure 2 Ip Address #1 Nanjing, China
Figure 3 IP Address #2 Walnut, CA
As Denny Cherry (b|t) mentions in Securing SQL Server having an SA account named SA and enabled is a definite security risk. Since SQL Server accounts won’t get locked out from failed password attempts these hackers know half of the battle, and they are hammering my VM trying to guess the SA password. Chred1433 seems like an interesting name for a user (or a hack attempt at SQL Server) and kisadmin shows up in this list of attacks on SQL Server.
Securing Your VM
So what does this mean for you? If you have VMs in Azure (or in your own data center—this is just general security best practices):
- Never expose port 1433 to the internet. There are some scenarios where you have to, but I try to always work around this
- Always disable your SA account—use domain groups for access to SQL Server
- When launching a SQL Server VM in Microsoft Azure either disable the endpoint on 1433 or use ACLs to limit access to specific machines
- Use Azure Virtual Networks and Gateways to connect securely to Azure Infrastructure—when you have a virtual network, you never have to use the public IP address, and all connections can take place over secure VPN connections
No one wants to have their data breached—so make sure to follow these steps!