Azure Virtual Networking
Azure Virtual Network is a construct that allows you to connect virtual network interface cards to a virtual network to allow TCP/IP-based communications between network enabled devices. Azure Virtual Machines connected to an Azure Virtual Network are able to connect to devices on the same Azure Virtual Network, different Azure Virtual Networks, on the Internet or even on your own on-premises networks.
Azure Network security best practices
1. Logically segment subnets
The idea behind an Azure Virtual Network is that you create a single private IP address space-based network on which you can place all your Azure Virtual Machines. The idea behind an Azure Virtual Network is that you create a single private IP address space-based network on which you can place all your Azure Virtual Machines.
We segment the larger address space into subnets using CIDR based subnetting principles to create your subnets. Routing between subnets will happen automatically and you do not need to manually configure routing tables. In order to create network access controls between subnets, you’ll need to put Network Security Group(NSG)between the subnets.
NSGs are simple stateful packet inspection devices that use the 5-tuple (the source IP, source port, destination IP, destination port, and layer 4 protocol) approach to create allow/deny rules for network traffic.
For example, think of a simple 3-tier application that has a web tier, an application logic tier and a database tier. You put virtual machines that belong to each of these tiers into their own subnets. Then you use NSGs to control traffic between the subnets:
- Web tier virtual machines can only initiate connections to the application logic machines and can only accept connections from the Internet
- Application logic virtual machines can only initiate connections with database tier and can only accept connections from the web tier
- Database tier virtual machines cannot initiate connection with anything outside of their own subnet and can only accept connections from the application logic tier
2. Control routing behavior
When you put a virtual machine on an Azure Virtual Network, you’ll notice that the virtual machine can connect to any other virtual machine on the same Azure Virtual Network, even if the other virtual machines are on different subnets. The reason why this is possible is that there is a collection of system routes that are enabled by default that allow this type of communication.
3. Enable Forced Tunneling
Imagine that you establish a VPN connection from your hotel room to your corporate network. This connection allows you to access corporate resources and all communications to your corporate network go through the VPN tunnel. When split tunneling is enabled, those connections go directly to the Internet and not through the VPN tunnel. Some security experts consider this to be a potential risk and therefore recommend that split tunneling be disabled and all connections, those destined for the Internet and those destined for corporate resources, go through the VPN tunnel.
The default routes for an Azure Virtual Network allow virtual machines to initiate traffic to the Internet. This too can represent a security risk, as these outbound connections could increase the attack surface of a virtual machine and be leveraged by attackers. For this reason, we recommend that you enable forced tunneling on your virtual machines when you have cross-premises connectivity between your Azure Virtual Network and your on-premises network.
If you do not have a cross premises connection, make sure you take advantage of Network Security Groups or Azure virtual network security appliances to prevent outbound connections to the Internet from your Azure Virtual Machines.
4. Use virtual network appliances
While Network Security Groups and User Defined Routing can provide a certain measure of network security at the network and transport layers of the OSI model, there are going to be situations where you’ll want or need to enable security at high levels of the stack by using virtual network security appliances provided by Azure partners.
Some of the network security capabilities provided by virtual network security appliances include:
- Intrusion detection/Intrusion Prevention
- Vulnerability management
- Application control
- Network-based anomaly detection
- Web filtering
- Botnet protection
5. Deploy DMZs for security zoning
A DMZ or “perimeter network” is a physical or logical network segment that is designed to provide an additional layer of security between your assets and the Internet. The intent of the DMZ is to place specialized network access control devices on the edge of the DMZ network so that only desired traffic is allowed past the network security device and into your Azure Virtual Network.
DMZs are useful because you can focus your network access control management, monitoring, logging and reporting on the devices at the edge of your Azure Virtual Network. Here you would typically enable DDoS prevention, Intrusion Detection/Intrusion Prevention systems (IDS/IPS), firewall rules and policies, web filtering, network antimalware and more.
6. Avoid exposure to the Internet with dedicated WAN links
In the hybrid IT scenario, there is usually some type of cross-premises connectivity. This cross-premises connectivity allows the company to connect their on-premises networks to Azure Virtual Networks. There are two cross-premises connectivity solutions available:
- Site-to-site VPN
Site-to-site VPN represents a virtual private connection between your on-premises network and an Azure Virtual Network. This connection takes place over the Internet and allows you to “tunnel” information inside an encrypted link between your network and Azure. While site-to-site VPN is a trusted, reliable, and established technology, traffic within the tunnel does traverse the Internet. In addition, bandwidth is relatively constrained to a maximum of about 200Mbps.
If you require an exceptional level of security or performance for your cross-premises connections, we recommend that you use Azure ExpressRoute for your cross-premises connectivity. ExpressRoute is a dedicated WAN link between your on-premises location or an Exchange hosting provider. Because this is a telco connection, your data doesn’t travel over the Internet and therefore is not exposed to the potential risks inherent in Internet communications.
Optimize uptime and performance
Load balancing is a method of distributing network traffic across servers that are part of a service. For example, if you have front-end web servers as part of your service, you can use load balancing to distribute the traffic across your multiple front-end web servers.
At the Azure Virtual Network level, Azure provides you with three primary load balancing options:
- HTTP-based load balancing
- External load balancing
- Internal load balancing
HTTP-based Load Balancing
HTTP-based load balancing bases decisions about what server to send connections using characteristics of the HTTP protocol. Azure has an HTTP load balancer that goes by the name of Application Gateway.
- Applications that require requests from the same user/client session to reach the same back-end virtual machine. Examples of this would be shopping cart apps and web mail servers.
- Applications that want to free web server farms from SSL termination overhead by taking advantage of Application Gateway’s SSL offload feature.
- Applications, such as a content delivery network, that require multiple HTTP requests on the same long-running TCP connection to be routed or load balanced to different back-end servers.
External Load Balancing
Azure External Load balancer is used when incoming connections from the Internet are load balanced among your servers located in an Azure Virtual Network and we recommend that you use it when you don’t require the sticky sessions or SSL offload.
Internal Load Balancing
Internal load balancer(similar to external LB but) accepts connections from virtual machines that are not on the Internet. Use internal load balancing for scenarios that benefit from this capability, such as when you need to load balance connections to SQL Servers or internal web servers.