Microsoft Certified Azure Security Engineer: Part 2 - Protect Virtual Networks.

Everything we learned to pass the Microsoft Certified Azure Security Engineer exam (AZ-500). Study Guide, as well as downloadable PDF here - https://www.blackchili.co.uk/training/azure-security-engineer/. Probably about an hour to read, and making your own notes is recommended. MP3 of each chapter, as well as the full course also available!

Protect Virtual Networks.

Each virtual network has an IP address range, using CIDR address formats. Private and Public IP address spaces available. DNS defaults to Azure DNS, and a default route to the Internet is configured, though this can be overwritten.

VNets contain subnets, usually a frontend (10.10.1.0/24 for example) and a backend (10.10.2.0/24). Microsoft reserves addresses in each subnet, much like AWS. .0 is the network address, the last address in the subnet is the broadcast address, and .1, .2 and .3 (or the first 3 usable addresses in a subnet) are reserved for Azure services.

The smallest supported subnet is a /29 with the largest being a /8. Custom routing tables can be associated, and service endpoints provide routes to Azure PaaS services.

VNet Peering connects two VNets. You must ensure address spaces do not overlap. VNets can be in different subscriptions, and peering must be created in the context of each VNet. Configure forwarding settings as required, and cross region peering is supported. All peered traffic passes across the MS Backbone, and data transfer charges may apply.

NSGs

A network security group is a stateful packet-filtering firewall to protect virtual machines. Uses source, port, destination, port, and protocol.

Each rule can be set inbound or outbound, given a priority value between 100 & 4096. The lower the value, the earlier it is evaluated in order.

A rule must be given a unique name and given a source address / service tag / Application Security Group (ASG) and source port value / list or range. Destination also expressed as an IP address, service tag, ASG. \destination port expressed as a value, list, or range. Protocol set as TCP/UDP/ICMP or Any. Action will be either allow or deny and the description is textual. Microsoft default NGG rules cannot be deleted but create rules with lower priority number to override. Default rules in NSGs will allow all traffic in and out of a VNet, so create lower priority numbered rules to prevent unwanted ingress/egress.

NSGs can be assigned to a NIC, subnet or both. NIC NSGs are assigned to a specific VM NIC. Subnet NSGs are assigned to all VMs in the subnet, with the actual filtering happening at the VM NICs. IF a VM has both NIC and Subnet NSGs, both rule sets apply. For inbound rules, Subnet is processed before NIC, for outbound NIC is processed before subnet.

Service tags can be used to access Azure PaaS services. They are groups of IPs managed by Microsoft and simplify NSG rule management. The service tags can be downloaded programmatically for use in on-prem firewall rules.

Application security groups are used to simplify NSG management, they are effectively labelling for virtual machines. A rule only applies if a VM NIC has an associated ASG. If possible, avoid using NIC NSGs, and use Subnet NSG and ASGs to simplify management. Create an ASG within a resource group, use that ASG to create suitable subnet NSG rules, and associate the ASG with VM NICs as required. Multiple ASGs can be associated with a VM NIC. ASGs, NSGs and the VM must all be in the same subscription and region.

Remote Access Management

Microsoft recommend a dedicated workstation for privileged activities, which should have no productivity applications installed (email). Internet access should also be limited. Local permissions should be restricted, servers should be joined to the domain and have Group Policy applied. MFA should be enforced, and anti-malware software installed. All Azure activity should be monitored.

It is common to configure a bastion server — a single server to access, from which you can RDP or SSH to other systems. You can connect to the bastion over a private connection from on-prem, either site to site IPsec VPN or ExpressRoute — this is the most secure option. It is also possible to connect via a public IP assigned to the bastion and limit access via NSG. This is not recommended as it makes the Bastion Internet facing, and it is too easy to misconfigure the NSG, resulting in Internet wide access. The third option is client connection via Azure VPN for a point to site (P2S) VPN. This can be achieved via OpenVPN SSL, Secure Socket Tunnelling Protocol (SSTP), or IKEv2. This is a good option but can become difficult to manage at scale owing to the need to distribute and manage certificates.

Azure Bastion also available as PaaS to RDP and SSH to Azure VMs. It is provisioned inside the VNet and uses SSL via the Azure Portal

Azure Hybrid Networks

Connect on-prem to Azure via Azure VPN or ExpressRoute. ExpressRoute can also be setup with a VPN backup. It is also possible to set up an IPsec VPN using a Network Virtual Appliance (NVA)

Azure VPN gateway is installed in a dedicated subnet within the Azure VNet.

– Azure VPN Basic — not recommended for production use (supports IKEv1, though v2 is recommended). 100Mbps bandwidth, 1 policy-based and 10 route-based site to site tunnels and 128 point to site tunnels SSTP.

– Azure VPN VpnGw1 — recommended for production use, 650Mbps bandwidth, 30 site to site tunnels and 125 SSTP and 250 IKEv2 point to site tunnels.

– Azure VPN VpnGw2 — recommended for production use, 1Gbps bandwidth, 30 site to site tunnels and 125 SSTP and 500 IKEv2 point to site tunnels.

– Azure VPN VpnGw3 — recommended for production use, 1.25Gbps bandwidth, 30 site to site tunnels and 125 SSTP and 1000 IKEv2 point to site tunnels.

Add ‘AZ’ to the end of each (aside from basic) for the multi-AZ version for redundancy.

Why use an NVA? IPsec with certificate authentication rather than shared secret — often a Government requirement. Also allows fully featured VPN clients ad advanced security features such as web category filtering, application and identity awareness, web anti-malware and threat intelligence feeds. May also fit better with existing infrastructure since many network security companies provide virtual appliances.

NVA can be purchased from the Azure Marketplace, deployed using an ARM template to the VNet in a DMZ subnet with a private and a public IP. Then create a custom route table with a default route to NVA private IP, and apply to all VM subnets

Azure Firewall

Azure Firewall is a managed stateful firewall which protects Azure virtual networks and includes NAT, network, and application rule types. Microsoft threat intelligence feeds are integrated with known malicious IPs and FDQNs included. Azure firewall is highly available and full scalable. An Azure firewall should sit in its own VNet in a hub and spoke arrangement with other VNets connected to it.

Azure Front Door

Application delivery network. Global HTTP load balancer with SSL offload and app acceleration. WAF and DDoS protection. Enables the definition, management and monitoring of global web traffic and rapid failover for availability. Works at layer 7 and uses anycast with split TCP. A front door backend can be azure storage, an app service, VM, Kubernetes or any other Internet facing HTTP endpoint. Azure front door uses health checks and http 200 responses from destination systems to determine health a no reply or 503 will result in no traffic being sent to that host until it passes a health check.

Traffic can be routed based on latency, priority, weighting (1 being highest priority and 5 the lowest) or session affinity. Each must have a unique name, can also use custom domain names. to use SSL, certificates are required for the custom domains — can be Azure front door managed certificates which are free but cannot be wildcard or apex, and are not exportable, or you can bring your own certificate which must be stored in Azure key vault. URL based routing is also possible.

WAF provides centralised protection against common exploits and vulnerabilities whilst maximising availability. Deployed on Azure network edge locations globally. After traffic is inspected, it can be forwarded to Azure services, other cloud platforms or on-prem systems or services. WAF policy can be added to any front door profile in your subscription, with new rules deployed quickly. Global WAF policy is built either from custom rules that are within customer control, or managed rules which are defined by Microsoft and cannot be changed. Custom rules are always processed first. When using WAF with custom domains and Azure front door, be sure to also create rules for the backend systems, as a WAF policy against a front door will not have any effect on the backend service until directly associated.

Custom rules can include IP allow or block lists, geographic access controls, custom HTTP requests — request URi, header or body. Also, on http request method. Custom rules can also limit request rates from specific IPs and combine with match conditions. The managed rules protect against known attack signatures for cross site scripting, SQL injection, remote code execution, local file inclusion or protocol attacks. There is also a bot rule set to control bad bots, good bots, or unknown bots. Managed rules are dynamically updated.

DDoS protection provides a defence against distributed attacks> Available in basic and standard. Basic is free but limited in scope, standard has a monthly plus usage fees but provides an SLA, metrics and alerts, logging and reporting, access to a DDoS response team and service credits for app scale out due to DDoS. Azure DDoS protection can mitigate volumetric attacks such as UDP or application floods, Protocol attacks such as SYN flood or reflection and application layer attacks like SQL injection or cross-site scripting.

Network Watcher

Network watcher allows the monitoring of network performance and health. Gives information at packet level without a need to log in to VMs in real-time, gaining insights in to network traffic using NSG flow logs and diagnose VPN issues. NSG diagnostic logs can also be gathered for permitted and blocked traffic.

IP Flow verify allows you to check whether a traffic flow will be successful based on evaluation of NSG rules. Helpful for troubleshooting connectivity issues. Packet capture can inspect every network packet for potential issues. Effective security rules can give you a rundown of which NSGs apply once provided with a VM and interface, with detailed inbound and outbound rules. Network watcher is enabled automatically.

Read the rest of the Series at Black Chili -hhttps://www.blackchili.co.uk/training/azure-security-engineer/.