| | | | August 2015 |  | | Microsoft Security Newsletter | | | | | | | | | | Welcome to August's Security Newsletter! | In this month’s newsletter, we are focusing on network security. We have a great security tip article written by Tom Shinder on “Locking down network access to virtual machines on Azure Virtual Networks.” You’ll also see information about Azure Network Security Groups, the new networking features coming in Windows Server 2016, and networking best practices for Windows Server 2012 R2.
And don’t forget that Windows 10 is now available! Hurry to take advantage of the free Windows 10 Home and Windows 10 Pro upgrade offer for those of you on Windows 7 or Windows 8.1. For enterprise customers looking to evaluate Windows 10, please download the Windows 10 Enterprise Evaluation to try Windows 10 Enterprise free for 90 days.
 | | Best regards,
Tim Rains, Chief Security Advisor
Cybersecurity & Cloud Strategy, Microsoft |
Want to share this newsletter with a friend or colleague? Click here for the online edition and subscription options.
Have feedback on how we can improve this newsletter? Email us at secnlfb@microsoft.com and share your ideas.
| | |  | | Top Stories |  |  | | | | Cloud Security Controls Series: Encrypting Data in Transit
Learn why, whether you store and process data on-premise, in the cloud, or use a combination of both, it is important to protect that data when it is transmitted across networks to information workers, partners and customers.
| | | | | Security Guidance | | | | Security Tip of the Month: Lock Down Network Access to Virtual Machines on Azure Virtual Networks
By Tom Shinder, Program Manager, Microsoft Azure Security Engineering
When you run virtual machines in Azure Infrastructure as a Service (IaaS), there are a number of things you can do from a network perspective to lock down your installation. The good news is that network security on Microsoft Azure has a lot in common with the network security concepts and implementation that you use on premises. The trick is to know the names of the relevant features and services in Azure and map them to what you already know.
Here’s three tips that you might find useful when thinking about network security for your IaaS virtual machines in Azure.
Control endpoint access
Virtual machines located on an Azure Virtual Network can be configured as “endpoints”. When you configure a virtual machine to be an endpoint, you make it possible for devices located on the Internet or on other Azure Virtual Networks to connect to the virtual machine.
For example, if you configured a virtual machine to be a web server and you wanted users located on the Internet to reach that virtual machine, you would configure that virtual machine to be an “endpoint” that’s reachable through HTTP or HTTPS.
When you use the “classic” Azure Portal and create a new virtual machine with the graphical interface, you’ll notice that there are default endpoints offered to you. These allow access to the virtual machine for Remote Desktop, Windows PowerShell Remoting, and Secure Shell (SSH). If you want to allow per virtual machine access using these protocols, that’s fine. But if you don’t, make sure that you disable endpoint access for these protocols.
You can learn a lot about endpoints and how to configure or disable them by reading How to set up endpoints to a virtual machine.
Use point-to-site VPN for management
When you allow endpoint access to virtual machines for the purpose of managing them, you still have to authenticate. You’ll use credentials that are appropriate to the virtual machine you’re connecting to. If the machine is domain joined, you might use domain credentials. If the machine is standalone, then you’ll be using local credentials.
A more secure method for remote management would be remove the management endpoints and use a point-to-site VPN connection from your management workstation to connect to the Azure Virtual Network. While the name “point-to-site” might be new to you if you’re a virtual networking veteran, rest assured that’s it’s nothing more than a remote access client VPN connection to the Azure Virtual Network, no different than the remote access VPN client connections enterprises have been using for years. The VPN protocol uses the Secure Socket Tunneling Protocol (SSTP), which uses HTTPS as its transport and allows the connection to traverse firewalls and web proxies that allow outbound HTTPS (SSL/TLS).
The reason why this is considered more secure is that you have to authenticate to the VPN gateway at the edge of the Azure Virtual Network before you’re allowed access to the virtual machines on that network. For the point-to-site connection, certificate-based authentication is used. This means that in order to reach the VMs for management, you have to authenticate twice, using two different authentication methods:
| • | First, you need to authenticate with the Azure VPN gateway using certificate-based authentication. | | • | After you are authorized and allowed access to the network, you need to authenticate with the virtual machines you want to manage, using your preferred management protocol ( RDP, SSH or Remote PowerShell). |
For more information on Azure point-to-site configuration, check out About secure cross-premises connectivity for virtual networks.
Segment your network based on roles and use Network Security Groups
Network segmentation is standard practice on-premises and you can do the same on Azure Virtual Networks. When you create an Azure Virtual Network, you’re asked for an address space. After you define the address space, you can subnet it. You can reduce your operational overhead and improve security (by reducing complexity) by assigning network-based roles to your subnets.
For example, you might want to put all your web front-ends in the same subnet. This allows you to simplify network access controls by allowing only HTTP/HTTPS to servers on that subnet (although you might want to also allow protocols for management traffic). When you add more front-end virtual machines to the subnet, you don’t need to change your network access controls.
This begs the question “how do I enforce network access controls to and from Azure Virtual Network subnets?”
The answer is Network Security Groups. You can think of a Network Security Group as a type of stateful packet inspection network device, where you can create up to 200 network access control rules. Rules can be created to control inbound and outbound traffic to and from a virtual machine or all virtual machines on an Azure Virtual Network subnet. Using the example in the previous paragraph, you can create a Network Security Group with a rule that allows inbound access to HTTP/HTTPS for your web front-end virtual machine subnet.
The article What is a Network Security Group (NSG)? has a ton of excellent information on how to use Network Security Groups. For a comprehensive view on all things related to security on Azure networks, download the Azure Network Security guide.
Stay up to date with what’s happening in Azure Security by visiting the Azure Security Blog. Thanks! -Tom
What is a Network Security Group (NSG)?
You can use an NSG to control traffic to one or more virtual machine instances in your virtual network. A network security group is a top level object that is associated to your subscription An NSG contains access control rules that allow or deny traffic to virtual machine instances. The rules of an NSG can be changed at any time, and changes are applied to all associated instances. Learn how to associate NSGs, find planning and design considerations, then get PowerShell cmdlets to help you create, configure, and manage your NSGs.
Connect Multiple On-premises Sites to a Virtual Network
Connecting multiple on-premises sites to a single virtual network is especially attractive for building hybrid cloud solutions. In fact, creating a multi-site connection to your Azure virtual network gateway is very similar to creating other site-to-site connections. Get step-by-step instructions on how to create your virtual network and gateway, and verify your connections.
Configure a VNet-to-VNet connection in the Azure Portal
Connecting a virtual network to another virtual network (VNet-to-VNet) is very similar to connecting a virtual network to an on-premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. The VNets you connect can be in different subscriptions and different regions. You can even combine VNet to VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity. Learn how to connect virtual networks together in the classic deployment mode by using a combination of the Azure Portal and Windows PowerShell.
What's New in Networking in Windows Server 2016 Technical Preview
Explore the new networking technologies in Windows Server 2016 Technical Preview, such as GRE tunneling, Network Controller, and the enhancements to DHCP, DNS, IPAM, and Hyper-V Network Virtualization.
Deploy Network Controller using Windows PowerShell
Get instructions on using Windows PowerShell to deploy Network Controller on one computer or virtual machine running Windows Server 2016 Technical Preview.
Windows Server 2012 R2 RRAS Multitenant Gateway Deployment Guide
Learn how to use Windows PowerShell to deploy RRAS as a virtual machine-based software gateway and router that allows cloud service providers (CSPs) and enterprises to enable datacenter and cloud network traffic routing between virtual and physical networks, including the Internet. Looking for more information on Windows Server Gateway? See the Windows Server Gateway documentation in the TechNet Library.
Windows Server 2012 R2 Hyper-V Network Virtualization with System Center 2012 R2 VMM
If you're using System Center Virtual Machine Manager (SC VMM), you can use SC VMM to deploy Windows Server Gateway; however even if you are using SC VMM, you can manage the gateway with the same Windows PowerShell commands that are used for the RRAS Multitenant Gateway. Learn how by downloading this test lab guide.
| | | | | Community Update | | | | Secure Your Network Connection By Using Your Own Private VPNs Hosted In Azure
Walk through the steps necessary to create a virtual machine hosted in one of Azure's data centers so that all your Internet traffic goes through a secure VPN tunnel to the datacenter.
| | | | | This Month's Security Bulletins | | | | | | August 2015 Security Bulletins
| | | August 2015 Security Bulletin Resources:
| | | | | Security Events and Training | | | | | | Networking Fundamentals: Defining Network Infrastructure and Network Security
Once you have a good understanding of local area networking, defining networks with the OSI model, wired and wireless networks, Internet Protocol, implementing TCP/IP in the command line, and working with networking services, and wide area networks, find out how to use your knowledge to build a functional, secure network. This session will also help you understand networking outside the LAN, as well as security devices and zones.
Azure Networking Fundamentals for IT Pros
Need guidance on configuring Azure multi-site virtual private networks (VPNs)? This course provides a general overview of networking in Azure, and cover all the steps required to set up VPNs in Azure. Explore deployment planning, connectivity testing, monitoring, and more.
| | | | | | | | | | | | | | | | | technet.microsoft.com/security | | | | | | | | | This is a monthly newsletter for IT professionals and developers–bringing security news, guidance, updates, and community resources directly to your inbox. If you would like to receive less technical security news, guidance, and updates, please subscribe to the Microsoft Security for Home Computer Users Newsletter.
© 2015 Microsoft Corporation Terms of Use | Trademarks
Microsoft respects your privacy. To learn more please read our online Privacy Statement.
If you would prefer not to receive the Microsoft Security Newsletter from Microsoft and its family of companies please click here. These settings will not affect any other newsletters you've requested or any mandatory service communications that are considered part of certain Microsoft services.
To set your contact preferences for other Microsoft communications click here.
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA | | | | | | | | |
