Unit 2: Secure Networking - Subjective Questions

An Azure Virtual Network, commonly called an Azure VNet, is a logically isolated network in Microsoft Azure that enables Azure resources to communicate securely with one another, the internet, and on-premises networks.

Its main components include:

• Address space: A private IP address range defined using CIDR notation, such as 10.0.0.0/16.
• Subnets: Smaller address ranges created by dividing the VNet address space.
• Network interfaces: Components that connect virtual machines and other resources to subnets.
• Route tables: Rules that determine where network traffic is forwarded.
• Network Security Groups: Stateful filtering rules that permit or deny traffic.
• DNS settings: Azure-provided or custom DNS servers used for name resolution.
• Connectivity mechanisms: VNet peering, VPN Gateway, and ExpressRoute provide communication with other networks.

A VNet therefore provides the basic network boundary for securely deploying and organizing Azure resources.

Subnetting divides a VNet address space into smaller logical networks. For example, the address space 10.0.0.0/16 can be divided into subnets such as 10.0.1.0/24 for web servers and 10.0.2.0/24 for database servers.

Security benefits include:

• Workload isolation: Resources with different functions can be placed in separate subnets.
• Traffic control: Different NSGs and route tables can be associated with each subnet.
• Reduced attack surface: Direct communication between sensitive and public-facing workloads can be restricted.
• Tiered architecture: Web, application, and database tiers can be protected with distinct policies.
• Simplified monitoring: Traffic can be inspected and logged according to subnet boundaries.

Subnetting does not provide complete security by itself. It should be combined with NSGs, firewalls, private endpoints, and controlled routing.

An Azure VNet can be connected to other networks through several mechanisms:

• VNet peering: Privately connects two Azure VNets using the Microsoft backbone. It supports low-latency communication but does not provide transitive routing by default.
• Site-to-site VPN: Creates an encrypted IPsec/IKE tunnel between an on-premises VPN device and an Azure VPN Gateway.
• Point-to-site VPN: Allows an individual client computer to connect securely to a VNet.
• ExpressRoute: Establishes a private dedicated connection between an organization's network and Microsoft cloud services without sending traffic over the public internet.
• VNet-to-VNet VPN: Connects VNets through Azure VPN Gateways, including VNets in different regions.

The choice depends on bandwidth, cost, latency, encryption, availability, and whether private dedicated connectivity is required.

A Network Security Group is an Azure resource containing stateful rules that allow or deny inbound and outbound network traffic. An NSG can be associated with a subnet, a network interface, or both.

Each NSG rule contains:

• Name: A unique identifier for the rule.
• Priority: A value from 100 to 4096; lower values are evaluated first.
• Direction: Specifies inbound or outbound traffic.
• Source: The originating IP range, service tag, or application security group.
• Source port range: The port used by the traffic source.
• Destination: The target IP range, service tag, or application security group.
• Destination port range: The target service port, such as 443 for HTTPS.
• Protocol: TCP, UDP, ICMP, ESP, AH, or any supported protocol.
• Action: Either allow or deny.

Processing stops when the first matching rule is found.

When NSGs are assigned to both a subnet and a network interface, traffic must be permitted by both NSGs.

For inbound traffic, Azure evaluates the rules in this order:

1. The NSG associated with the subnet is evaluated.
2. If permitted, the NSG associated with the destination network interface is evaluated.
3. The packet reaches the resource only if both evaluations allow it.

For outbound traffic, the order is reversed:

1. The NSG associated with the source network interface is evaluated.
2. If permitted, the subnet NSG is evaluated.
3. The packet leaves the subnet only if both NSGs allow it.

Within each NSG, rules are evaluated in ascending priority order. Because NSGs are stateful, return traffic for an allowed connection is automatically permitted without requiring a separate reverse-direction rule.

These terms represent related but distinct concepts:

• Network Security Group: An Azure packet-filtering resource applied to subnets or network interfaces. Its rules use source, destination, port, protocol, direction, priority, and action.
• Application Security Group: An Azure logical grouping of virtual machine network interfaces. It allows NSG rules to refer to application roles such as WebServers or DatabaseServers instead of maintaining IP address lists.
• Generic security group: A broad cloud-computing term for a virtual firewall that controls traffic to cloud resources. Implementations differ among cloud providers.

NSGs perform the actual filtering in Azure, while Application Security Groups simplify the definition of NSG sources and destinations. Both promote role-based policies and reduce dependence on changing IP addresses.

A secure three-tier design should apply least privilege and allow only required communication.

Web subnet:

• Allow inbound TCP 443 from the internet or an approved frontend service.
• Allow administrative access only from Azure Bastion or a trusted management subnet.
• Deny unnecessary inbound traffic.

Application subnet:

• Allow inbound application traffic only from the web tier on the required service port, such as TCP 8080.
• Deny direct inbound traffic from the internet.
• Permit only required outbound access to the database and approved platform services.

Database subnet:

• Allow inbound database traffic only from the application tier, such as TCP 1433 for Microsoft SQL Server.
• Deny traffic originating directly from the web tier or internet.
• Restrict administrative traffic to a controlled management path.

Application Security Groups can represent each tier. Logging, flow verification, and periodic rule reviews should accompany the design. This architecture limits lateral movement and prevents users from bypassing application tiers.

User-Defined Routes are custom Azure routes created in a route table to override or supplement Azure system routes. A route table is associated with one or more subnets.

Important route properties are:

• Address prefix: The destination IP range in CIDR notation.
• Next-hop type: The target to which matching packets are forwarded.
• Next-hop address: Required when traffic is sent to a virtual appliance.

Common next-hop types include:

• Virtual appliance: Sends traffic to a firewall, router, or other network virtual appliance.
• Virtual network gateway: Sends traffic through a VPN or ExpressRoute gateway in supported scenarios.
• Virtual network: Routes traffic within the VNet.
• Internet: Sends traffic toward the public internet.
• None: Drops the traffic and acts as a blackhole route.

UDRs are commonly used to enforce centralized inspection and control network paths.

Azure first selects the route with the longest matching address prefix, meaning the most specific destination range wins. For example, a route for 10.1.2.0/24 is preferred over a route for 10.1.0.0/16 when the destination is 10.1.2.10.

If multiple routes have the same prefix length, Azure uses route-source precedence. In general, the relevant preference is:

1. User-defined route
2. BGP route
3. System route

Thus, a UDR can override a system route when both describe the same destination prefix. However, a more specific system or BGP route can be selected over a less specific UDR because longest prefix matching occurs first.

Administrators should inspect the network interface's effective routes to verify the actual result after system, BGP, and user-defined routes are combined.

A centralized inspection design places a firewall in a hub VNet or dedicated security subnet. A route table associated with workload subnets contains a default route such as 0.0.0.0/0, with Virtual appliance as the next-hop type and the firewall's private IP address as the next hop.

The traffic flow is:

1. A workload sends a packet to an external destination.
2. The subnet UDR forwards the packet to the firewall.
3. The firewall evaluates policy and may perform source network address translation.
4. Allowed traffic is forwarded to its destination.
5. Return traffic must follow a compatible path through the stateful firewall.

Possible problems include:

• Asymmetric routing, where return traffic bypasses the firewall.
• Missing routes between hub and spoke networks.
• Disabled IP forwarding on a network virtual appliance.
• Route propagation creating an unexpected preferred path.
• A firewall failure becoming a connectivity bottleneck.

Effective routes and packet-flow diagnostics should be used during validation.

Azure Firewall is a managed, stateful network security service used to protect Azure Virtual Network resources. It can provide centralized control for traffic across multiple subnets and spoke VNets.

Major capabilities include:

• Stateful filtering: Tracks connections and automatically handles permitted return traffic.
• Network rules: Filter traffic by source, destination, port, and protocol.
• Application rules: Control outbound HTTP, HTTPS, and supported protocol access using fully qualified domain names.
• DNAT rules: Translate a firewall public endpoint to a private resource.
• Threat intelligence: Alert on or deny traffic involving known malicious IP addresses and domains.
• Logging and metrics: Integrate with Azure Monitor and Log Analytics.
• High availability and scaling: Provided as part of the managed service.
• Premium inspection features: Depending on tier, capabilities can include TLS inspection, URL filtering, and intrusion detection and prevention.

It is commonly deployed as the central enforcement point in a hub-and-spoke network.

An NSG and Azure Firewall operate at different scopes and provide complementary controls.

NSG:

• Distributed across subnets and network interfaces.
• Filters traffic mainly by IP address, port, protocol, and direction.
• Uses priority-based allow and deny rules.
• Provides basic segmentation without a separate processing charge.
• Is suitable for controlling communication between workload tiers.

Azure Firewall:

• Acts as a centralized traffic inspection and policy enforcement service.
• Supports network, application, and destination NAT rules.
• Can filter using fully qualified domain names and threat intelligence.
• Provides centralized logs and advanced inspection features depending on its tier.
• Is suitable for internet egress control and hub-and-spoke architectures.

Both should be used for defense in depth: NSGs enforce local segmentation close to workloads, while Azure Firewall inspects and governs traffic at central ingress, egress, or inter-network boundaries.

A secure firewall configuration procedure includes:

1. Identify traffic requirements: Document approved sources, destinations, ports, protocols, and business owners.
2. Apply least privilege: Permit only required flows and avoid unrestricted rules such as any source to any destination.
3. Organize policies: Use clearly named rule collection groups and separate DNAT, network, and application rules.
4. Set processing order: Place specific and critical policies in the intended priority order.
5. Configure routing: Ensure subnet UDRs direct the required traffic through the firewall.
6. Enable diagnostics: Send firewall logs and metrics to Log Analytics, storage, or another monitoring system.
7. Test connectivity: Verify approved flows and confirm that prohibited flows are denied.
8. Inspect effective routes and logs: Confirm that observed packet paths match the intended architecture.
9. Review regularly: Remove obsolete rules and investigate overly broad or unused permissions.

Configuration should be managed through controlled deployment processes so that changes are reviewable and repeatable.

A Web Application Firewall inspects HTTP and HTTPS traffic to protect web applications from attacks at the application layer. In Azure, WAF is available with services such as Azure Application Gateway and Azure Front Door.

A WAF can help mitigate:

• SQL injection, where malicious database commands are inserted into input fields.
• Cross-site scripting, where hostile scripts are injected into web content.
• Protocol violations and malformed HTTP requests.
• Path traversal and local or remote file inclusion attempts.
• Request smuggling or abnormal request patterns, where supported by the applicable rules.
• Attacks represented in managed rule sets, including many OWASP Top 10 risks.

A WAF complements secure coding, authentication, patching, and vulnerability management. It does not remove vulnerabilities from the application itself.

In detection mode, the WAF evaluates requests and records rule matches but generally does not block them. This mode is useful for understanding normal application behavior and identifying potential false positives.

In prevention mode, requests matching blocking rules are denied. This provides active protection but may interrupt legitimate requests if rules are not tuned.

A safe transition process is:

1. Deploy the WAF in detection mode.
2. Enable diagnostic logging and collect representative production traffic.
3. Analyze matched rules, request details, and false positives.
4. Fix application issues where possible rather than broadly disabling protection.
5. Create narrowly scoped exclusions only for verified legitimate traffic.
6. Enable prevention mode in a controlled environment or phased deployment.
7. Monitor blocked requests, latency, and application errors.
8. Review managed rule-set updates and retest regularly.

This process balances active protection with application availability.

Both platforms can protect HTTP and HTTPS applications, but their deployment scopes differ.

WAF on Application Gateway:

• Operates as a regional Layer 7 load balancer inside or associated with an Azure VNet.
• Is suited to regional applications and private backend resources.
• Supports capabilities such as TLS termination, path-based routing, and backend health probing.
• Protects traffic near the application deployment.

WAF on Azure Front Door:

• Operates at Microsoft's global edge network.
• Is suited to internet-facing, globally distributed applications.
• Routes users to available backends using global entry points.
• Can block malicious requests closer to their source and integrates with edge delivery capabilities.

Application Gateway is typically chosen for regional VNet-integrated control, while Front Door is chosen for global edge protection and routing. Some architectures use both for layered protection.

Azure DDoS Protection Standard, now commonly represented within Azure's enhanced DDoS network protection offerings, is a managed service that protects eligible public IP resources in virtual networks against distributed denial-of-service attacks.

Compared with the automatic basic infrastructure protection of the Azure platform, the enhanced service provides capabilities such as:

• Adaptive tuning: Mitigation policies learn normal traffic patterns for protected resources.
• Attack mitigation: Azure detects and filters malicious volumetric and protocol traffic.
• Monitoring and alerts: Metrics expose attack indicators and mitigation activity.
• Diagnostic information: Detailed reports and flow logs can support investigation.
• Cost protection: Eligible scaling charges incurred during a documented attack may receive protection under applicable service terms.
• Expert support: DDoS response assistance may be available during active attacks, depending on the service plan.

It primarily protects network-layer availability and should be combined with WAF for application-layer attacks.

The three major DDoS categories target different system resources:

• Volumetric attacks: Consume network bandwidth using very large traffic volumes. UDP floods and amplification attacks are examples. Azure DDoS network protection is a primary defense.
• Protocol attacks: Exhaust network devices, connection tables, or protocol-processing capacity. SYN floods are a common example. Azure's DDoS mitigation infrastructure and resilient network design help defend against them.
• Application-layer attacks: Send apparently valid HTTP or HTTPS requests that exhaust web-server or application resources. HTTP request floods are an example. WAF, Azure Front Door, rate limiting, caching, autoscaling, and application-specific monitoring are important defenses.

No single control handles every category. A layered architecture combines network DDoS protection, WAF policies, scalable application design, health monitoring, and an incident-response plan.

A defense-in-depth architecture can be designed as follows:

1. Edge protection: Use Azure Front Door with WAF for global routing, TLS termination where appropriate, and application-layer filtering.
2. DDoS protection: Enable an enhanced Azure DDoS network protection plan for eligible public IP resources and configure alerts.
3. Application ingress: Place Application Gateway with WAF in a dedicated subnet when regional Layer 7 routing and private backends are required.
4. Network segmentation: Divide the VNet into gateway, web, application, database, firewall, and management subnets as needed.
5. NSG controls: Allow only the required traffic between tiers. Prevent direct internet access to application and database tiers.
6. Central firewall: Deploy Azure Firewall in the hub or dedicated firewall subnet for controlled egress and inter-network inspection.
7. User-defined routes: Direct workload internet-bound traffic through Azure Firewall while preserving symmetric routing.
8. Private access: Use private endpoints and private DNS for supported platform services.
9. Monitoring: Centralize WAF, firewall, NSG-related, DDoS, and application logs in a monitoring platform.
10. Operational controls: Use least privilege, managed identities, policy enforcement, patching, backups, and tested incident-response procedures.

Each layer addresses a different threat, reducing reliance on any single security mechanism.

Effective secure-network operations require centralized telemetry and correlation across controls.

• NSGs: Use supported network flow telemetry, connection troubleshooting, and effective security rule inspection to determine whether a flow is allowed or denied.
• Routes: Examine effective routes on network interfaces and use next-hop diagnostics to detect incorrect UDRs or gateway propagation.
• Azure Firewall: Enable network, application, DNAT, threat-intelligence, and intrusion-related logs where applicable. Monitor health, throughput, and rule matches.
• WAF: Review matched and blocked requests, rule identifiers, client addresses, request paths, and false positives. Protect sensitive request data in logs.
• DDoS protection: Monitor attack metrics, mitigation status, traffic anomalies, and available post-attack reports.

Logs should be sent to a central workspace or security information and event management system. Alerts should cover traffic spikes, repeated denies, unexpected outbound connections, WAF blocks, firewall health, and DDoS events. Troubleshooting should correlate timestamps, source and destination addresses, ports, routes, and rule decisions across all layers.