MST400-M04.pdf

MST400: Introduction to Microsoft Azure Administration Module 4: Virtual Networking Hooshang Kazemi, Ph.D. Module 4: Topics • Azure Virtual Networks • Azure Network Security Groups • Azure Firewall • Azure DNS MST400 Azure Networking Components • Azure networking components offer a range of fu...

MST400: Introduction to Microsoft Azure Administration Module 4: Virtual Networking Hooshang Kazemi, Ph.D. Module 4: Topics • Azure Virtual Networks • Azure Network Security Groups • Azure Firewall • Azure DNS MST400 Azure Networking Components • Azure networking components offer a range of functionalities and services. MST400 Azure Virtual Network (VNet) • VNet is a representation of your network in the cloud • VNet is a logical isolation of the Azure cloud dedicated to your subscription • VNets can be used to provision and manage virtual private networks (VPNs) in Azure • You can link VNets with other VNets in Azure, or with on-premises IT infrastructure to create hybrid or cross-premises solutions MST400 VNet Implementation types Virtual networks can be created in many ways. • Create a dedicated private cloud-only VNet. When you create a VNet, your services and VMs within your VNet can communicate directly and securely with each other in the cloud. You can still configure endpoint connections for the VMs and services that require internet communication, as part of your solution. • Securely extend your data center With VNets. You can build traditional site-to-site (S2S) VPNs to securely scale your datacenter capacity. S2S VPNs use IPSEC to provide a secure connection between your corporate VPN gateway and Azure. • Enable hybrid cloud scenarios. VNets give you the flexibility to support a range of hybrid cloud scenarios. You can securely connect cloud-based applications to any type of on-premises system such as mainframes and Unix systems. MST400 VNet Subnets • A virtual network can be segmented into one or more subnets for better security and management • Subnets provide logical divisions within your network • Each subnet contains a range of IP addresses that fall within the virtual network address space MST400 VNet Considerations • Service requirements. A service may require, to create its own subnet, so there must be enough unallocated IP address space. • Virtual appliances. Azure routes network traffic between all subnets in a virtual network, by default. You can override Azure's default routing through a network virtual appliance. • Service endpoints. You can limit access to Azure resources in specific subnets with a service endpoint. You may create multiple subnets, and enable a service endpoint for some subnets, but not others. • Network security groups. Each network security group contains rules, which allow or deny traffic to and from sources and destinations. You can associate zero or one network security group to each subnet in a virtual network. • Azure reserves five IP addresses within each subnet. • • • • x.x.x.0: Network address x.x.x.1: Reserved by Azure for the default gateway x.x.x.2, x.x.x.3: Reserved by Azure to map the Azure DNS IPs to the VNet space x.x.x.255: Network broadcast address MST400 Implementing Virtual Networks • By default, you can create up to 50 virtual networks per subscription per region. • You can increase this limit to 500 by contacting Azure support. MST400 Virtual Network tasks using PowerShell • 1. Create a virtual network using PowerShell • Create a virtual network. Use values as appropriate. • $myVNet2 = New-AzVirtualNetwork -ResourceGroupName demo-RG -Location EastUS -Name myVNet2 -AddressPrefix 10.0.0.0/16 • 2. Verify your new virtual network information. • Get-AzVirtualNetwork -Name myVNet2 • 3. Create a subnet. Use values as appropriate. • $mySubnet2 = Add-AzVirtualNetworkSubnetConfig -Name mySubnet2 -AddressPrefix 10.0.0.0/24 -VirtualNetwork $myVNet2 • 4. Verify your new subnet information. • Get-AzVirtualNetworkSubnetConfig -Name mySubnet2 -VirtualNetwork $myVNet2 • 5. Associate the subnet to the virtual network. • $mySubnet2 | Set-AzVirtualNetwork IP Addressing Private IP addresses - used within an Azure virtual network (VNet), and on-premises networks, when a VPN gateway or ExpressRoute circuit is used to extend local site network to Azure. Public IP addresses - used for communication with the Internet, including Azure public-facing services ✔ IP addresses can be statically assigned or dynamically (DHCP) assigned. ✔ It is better to separate dynamically and statically assigned IP resources into different subnets. ✔ IP Addresses are never managed from within a virtual machine. MST400 Public IP Addresses * Static IP addresses only available on certain SKUs. MST400 Private IP Addresses MST400 • Create a virtual network in the portal • Create a virtual network with PowerShell MST400 Azure Network Security Groups (NSG)  A network security group contains a list of security rules that allow or deny inbound or outbound network traffic.  To prevent unwanted or unsecured network traffic from being able to reach key systems, NSG rules must be defined and implemented.  An NSG can be associated to a subnet or a network interface.  A network security group can be associated multiple times. MST400 Assigning NSGs to Subnets • NSGs can be assigned to subnets to create protected screened subnets (also called a DMZ). • These NSGs can restrict traffic flow to all the machines that reside within that subnet. • Each subnet can have zero, or one NSG associated to its NIC or NICs. MST400 NSG Rules • Security rules in NSGs enable you to filter the type of network traffic that can flow in and out of virtual network subnets and network interfaces. • You can create rules by specifying: • Name • Priority • Port • Protocol (Any, TCP, UDP) • Source (Any, IP Addresses, Service tag) • Destination (Any, IP Addresses, Virtual Network) • Action (Allow or Deny). MST400 Inbound Rules • The default inbound security rules deny all inbound traffic except from the virtual network and Azure load balancers. MST400 Outbound rules • The three default outbound security rules only allow outbound traffic to the Internet and the virtual network. MST400 NSG Effective Rules • NSGs are evaluated independently, and an “allow” rule must exist at both levels. • For incoming traffic, the NSG set at the subnet level is evaluated first, then the NSG set at the NIC level is evaluated. • For outgoing traffic, it is the reverse. • To verify the security rules being applied to a network interface use the Effective security rules link MST400 Creating NSG Rules Service specifies the destination protocol and port range for the rule. Port ranges designate the ports that traffic will be allowed or denied by this rule. An asterisk (*) means any port. Priority. Rules are processed in priority order. The lower the number, the higher the priority. MST400 • Create a new NSG • Examine Inbound and Outbound Rules MST400 Azure Firewall  Azure Firewall uses a static public IP address for virtual network resources allowing outside firewalls to identify traffic originating from a virtual network.  Azure Firewall is fully integrated with Azure Monitor for logging and analytics. MST400 Azure Firewall features • Built-in high availability. High availability is built in, so additional load balancers aren't required. There's nothing you need to configure. • Availability Zones. Azure Firewall can be configured during deployment to span multiple Availability Zones for increased availability. • Unrestricted cloud scalability. Azure Firewall can scale up as much as you need to accommodate changing network traffic flows, so you don't need to budget for your peak traffic. • Application FQDN filtering rules. You can limit outbound HTTP/S traffic or Azure SQL traffic to a specified list of fully qualified domain names (FQDN) including wild cards. • Network traffic filtering rules. You can centrally create allow or deny network filtering rules by source and destination IP address, port, and protocol. Azure Firewall is fully stateful, so it can distinguish legitimate packets for different types of connections. Rules are enforced and logged across multiple subscriptions and virtual networks. • Threat intelligence. Threat intelligence-based filtering can be enabled for your firewall to alert and deny traffic from/to known malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed. • Multiple public IP addresses. You can associate multiple public IP addresses (up to 100) with your firewall. MST400 Implementing Azure Firewall • It's recommended to use a hub-spoke network topology when deploying a firewall. The benefits of this topology include: • Cost savings by centralizing services that can be shared by multiple workloads. • Overcome subscriptions limits by peering virtual networks from different subscriptions to the central hub. • Separation of workloads like SecOps and InfraOps from DevOps traffic. MST400 Firewall Rules • By default, Azure Firewall blocks all traffic. • There are three kinds of rules Rule Processing: The rules are processed in this order: • Network Rules • Application Rules (network and application) Once a rule is found that allows the traffic through, no more rules are checked. MST400 NAT Rules • Azure Firewall Destination Network Address Translation (DNAT) translates and filters inbound traffic to Azure subnets. • NAT rules are used to translate firewall public IP and port to a private IP and port. • A Nat rule must be matched by a Network Rule to allow traffic to pass. • Configuration settings; Name: A label for the rule. Protocol: TCP or UDP. Source Address: * (Internet), a specific Internet address, or a CIDR block. Destination Address: The external address of the firewall that the rule will inspect. Destination Ports: The TCP or UDP ports that the rule will listen to on the external IP address of the firewall. Translated Address: The IP address of the service (virtual machine, internal load balancer, and so on) that privately hosts or presents the service. • Translated Port: The port that the inbound traffic will be routed to by the Azure Firewall. • • • • • • MST400 Network Rules • Any non-HTTP/S in order to be allowed to flow through the firewall must have a network rule. • If resources in one subnet must communicate with resources in another subnet, then a network rule from the source to the destination is needed. • Configuration settings include: • • • • • Name: A friendly label for the rule. Protocol: TCP, UDP, ICMP (ping and traceroute) or Any. Source Address: The address or CIDR block of the source. Destination Addresses: The addresses or CIDR blocks of the destination(s). Destination Ports: The destination port of the traffic. MST400 Application Rules • Application rules define fully qualified domain names (FQDNs) that can be accessed from a subnet. • Configuration settings include: • • • • Name: A friendly label for the rule. Source Addresses: The IP address of the source. Protocol: Port: HTTP/HTTPS and the port that the web server is listening on. Target FQDNs: The domain name of the service, such as www.contoso.com. Wildcards can be used. An FQDN tag represents a group of FQDNs associated with well known Microsoft services. Example FQDN tags include Windows Update, App Service Environment, and Azure Backup. MST400 Azure DNS  Azure DNS enables you to host your DNS records for your domains on Azure infrastructure.  With Azure DNS, you can use the same credentials, APIs, tools, and billing as your other Azure services. MST400 Azure DNS: Domains and Custom Domains      With every Azure subscription, an Azure AD domain is automatically created. It has an initial domain name in the form of domainname.onmicrosoft.com. The initial domain name is used until a custom domain name is defined. The initial domain name can't be changed or deleted. You can add a routable custom domain name so you can control it. MST400 Azure DNS: Verifying Custom Domain Names • • • • Custom domain name is initially in an unverified state and must be verified before it can be used. Only one directory can use a domain name, the organization that owns the domain name. Verification is performed by adding a DNS record. The DNS record can be MX or TXT. When Azure verifies the presence of the DNS record, it will then add the domain name to the subscription. MST400 Azure DNS Zones • DNS zone hosts DNS records for a domain. • The name of the zone must be unique within the resource group. • The same zone name can be reused in a different resource group • Where multiple zones share the same name, each instance is assigned different name server addresses. • Root/Parent domain is registered at the registrar and pointed to Azure NS. • Child domains are registered in AzureDNS directly. MST400 DNS Delegation • To delegate your domain to Azure DNS, you first need to know the name server names for your zone. • Once the Name Servers are assigned, Azure DNS automatically creates authoritative NS records in your zone. • The easiest way to locate the name servers assigned to your zone is through the Azure portal. MST400 DNS Record Sets • A record set is a collection of records in a zone that have the same name and are the same type. • A record set cannot contain two identical records. • Depending on the Type of record set selected, page info changes. MST400 DNS for Private Domain Names • When using private DNS zones, you can use your own custom domain names rather than the Azureprovided names. • It provides name resolution for virtual machines (VMs) within a virtual network and between virtual networks. Additionally, you can configure zones names with a split-horizon view, which allows a private and a public DNS zone to share the name. MST400 • Explore DNS in Azure MST400 Thank you! MST400