Unit 2: Secure Networking

I. Secure Networking

Secure networking protects communication, workloads, identities, and data while allowing only authorized traffic to reach cloud resources. In Azure, security is implemented through layered controls: network segmentation, traffic filtering, routing, inspection, application protection, and volumetric attack mitigation.

• Defense in depth: Multiple controls operate together; a subnet may use an NSG, a route table, Azure Firewall, and WAF.
• Least privilege: Permit only the protocols, ports, source addresses, and destinations required by a workload.
• Stateful filtering: A stateful control records connection state, so return traffic for an allowed connection is normally permitted automatically.
• Control-plane and data-plane distinction: Management operations use Azure Resource Manager, while application packets travel through virtual networks and security devices.
• Layered protection: NSGs primarily filter network traffic, firewalls inspect and control flows, WAF protects web applications, and DDoS Protection mitigates large-scale attacks.
• Explicit routing: Azure system routes provide defaults; custom routes can force traffic through inspection or connectivity appliances.

II. Azure Virtual Network (AVN)

A. Azure Virtual Network (AVN)

An Azure Virtual Network is a private, software-defined network in Azure that provides IP-based communication between virtual machines, managed services, on-premises networks, and the internet.

• Address space: A VNet uses one or more private CIDR blocks, such as 10.0.0.0/16; overlapping address spaces complicate peering and VPN connectivity.
• Subnetting: A subnet divides the VNet into smaller ranges, such as 10.0.1.0/24 for web servers and 10.0.2.0/24 for databases.
• Isolation: Resources in different VNets are isolated unless connected by VNet peering, VPN Gateway, or ExpressRoute.
• Private communication: VNet resources communicate using private IP addresses; public exposure is separately configured through public IPs, load balancers, or gateways.
• Azure platform addresses: Azure reserves five IP addresses in each subnet, including the first four and the final address. A /24 therefore provides fewer usable addresses than its 256 total addresses.
• Distributed design: VNets are regional resources, while VNet peering can connect networks across regions through global VNet peering.

B. Applications and limitations

A VNet supplies the network foundation, but it does not automatically make applications secure.

• Segmentation: Separate front-end, application, and data subnets to limit lateral movement.
• Connectivity: Use private endpoints for selected Azure services so traffic remains on private addressing rather than using public endpoints.
• Limitation: A VNet alone does not inspect HTTP requests, block malware, or stop DDoS attacks; additional controls are required.
• Example: A three-tier application can place web servers in 10.0.1.0/24, APIs in 10.0.2.0/24, and databases in 10.0.3.0/24, then permit only required flows between tiers.

III. Network Security Groups (NSGs)

A. Network Security Groups (NSGs)

A Network Security Group is a stateful packet-filtering resource containing inbound and outbound security rules for Azure network interfaces and subnets.

• Rule matching: Rules are evaluated by priority from the lowest number upward; priority 100 is processed before priority 300.
• Rule fields: A rule specifies source, source port, destination, destination port, protocol, direction, access action, and priority.
• Default rules: Azure includes default rules such as allowing VNet-to-VNet traffic and denying inbound internet traffic after higher-priority rules are considered.
• Association points: An NSG can be associated with a subnet, a network interface, or both; effective security is the combined result.
• Statefulness: If an outbound connection is permitted, corresponding return traffic is tracked and allowed without a separate manually created return rule.
• Service tags: Names such as Internet, VirtualNetwork, and AzureLoadBalancer represent changing groups of IP prefixes and reduce maintenance.

B. Applications and limitations

NSGs provide efficient segmentation and access control, but they are not full inspection firewalls.

• Allow-listing: Permit TCP 443 from an approved source to a web subnet while denying other inbound internet traffic.
• Deny rules: A high-priority deny rule can block a known hostile address before a broader allow rule.
• Diagnostics: Network Watcher and NSG flow logs help identify whether traffic was allowed or denied.
• Limitation: NSGs do not inspect URL paths, HTTP headers, payload content, or encrypted application meaning.
• Design rule: Avoid broad rules such as Any source to Any destination unless the traffic is deliberately controlled elsewhere.

IV. Security groups

A. Security groups

Security groups are logical collections of access-control rules that group resources by communication role rather than by individual host identity. In Azure, NSGs are the primary implementation of this network security-group model.

• Role-based grouping: A web security group can represent TCP 80 and 443 access, while an application group can represent API traffic from the web tier.
• Network placement: Rules may apply at subnet level for shared protection or network-interface level for workload-specific restrictions.
• Layered policy: Subnet rules establish a baseline; interface rules can add more specific restrictions.
• Source and destination control: Policies should identify both who may initiate traffic and which resource or subnet may receive it.
• Operational consistency: Standardized names such as nsg-web-prod and documented priorities make policies easier to audit.
• Limitation: Logical grouping does not replace identity-based authorization inside applications or databases; network access should be combined with authentication and authorization.

V. User-defined routes

A. User-defined routes

User-defined routes are custom routing entries stored in route tables and associated with subnets to control the next hop for traffic.

• Route components: Each route includes a destination prefix, such as 0.0.0.0/0 or 10.20.0.0/16, and a next-hop type.
• Next-hop types: Common choices include Virtual appliance, Virtual network gateway, VirtualNetwork, Internet, and None.
• Longest-prefix matching: Azure selects the most specific matching route. A route for 10.0.2.0/24 takes precedence over 10.0.0.0/16.
• Forced tunneling: A 0.0.0.0/0 route to a firewall or network virtual appliance can force internet-bound traffic through inspection.
• Blackholing: A None next hop discards traffic, useful for intentionally blocking a destination range.
• Dependency risk: Incorrect routes can create asymmetric paths, routing loops, or unreachable services.

B. Applications and limitations

UDRs are used when default Azure routing does not satisfy inspection, hybrid connectivity, or segmentation requirements.

• Inspection path: A spoke VNet can route 0.0.0.0/0 to an Azure Firewall in a hub VNet, ensuring outbound traffic is evaluated centrally.
• Hybrid routing: A route for 10.50.0.0/16 can send traffic toward a VPN or ExpressRoute gateway.
• Verification: Effective routes on a network interface show the route Azure actually selects.
• Limitation: A route only chooses a path; it does not itself permit or deny traffic. NSGs and firewall policies still determine whether communication is allowed.
• Operational concern: Route changes should be tested because a single incorrect prefix can affect every resource in an associated subnet.

VI. Firewall configuration

A. Firewall configuration

Firewall configuration defines how a firewall permits, denies, translates, logs, and inspects network connections. Azure Firewall is a managed, stateful, highly available service commonly deployed in a hub-and-spoke architecture.

• Network rules: Control IP addresses, protocols, and ports, such as TCP 1433 to a database address.
• Application rules: Control outbound fully qualified domain names and web protocols, such as allowing HTTPS access to approved update domains.
• NAT rules: Translate public destinations to private workloads, enabling controlled inbound publication.
• Threat intelligence: A configured threat-intelligence mode can alert on or deny traffic associated with known malicious sources.
• Centralization: A hub firewall can inspect traffic between spokes, toward on-premises networks, and toward the internet.
• Logging: Diagnostic settings can send firewall logs to Log Analytics, Storage, or Event Hubs for monitoring and investigation.

B. Applications and limitations

Firewall policies should be specific, ordered, observable, and aligned with the intended traffic path.

• Default-deny principle: Start with only required rules, for example permitting application subnet TCP 443 to a specified service.
• Rule collections: Organize related network, application, and NAT rules so ownership and review are clear.
• Routing requirement: UDRs or gateway configuration must direct traffic through the firewall; deploying a firewall without a traffic path does not protect flows.
• Availability: Use the managed service’s zone and scaling capabilities according to workload requirements and regional design.
• Limitation: A network firewall is not a substitute for WAF protection against HTTP-specific attacks or for endpoint security on servers.
• Example: Internet traffic can reach a public load balancer, while outbound traffic from private application subnets is routed through Azure Firewall and restricted to approved destinations.

VII. Web Application Firewall (WAF)

A. Web Application Firewall (WAF)

A Web Application Firewall protects HTTP and HTTPS applications by inspecting requests and responses for attacks at the application layer. Azure WAF is available with services such as Application Gateway and Azure Front Door.

• Attack coverage: Rules commonly address SQL injection, cross-site scripting, protocol violations, and malicious request patterns.
• Managed rules: OWASP-based managed rule sets provide maintained detection logic for widely recognized web threats.
• Detection mode: Detection logs suspicious requests without blocking them, supporting tuning before enforcement.
• Prevention mode: Prevention can block requests that match enabled rules, returning an HTTP error instead of forwarding the request.
• Custom rules: Conditions can match IP addresses, request methods, headers, query strings, or geographic attributes.
• Exclusions: An exclusion can prevent a legitimate parameter or path from triggering a rule, but excessive exclusions reduce protection.

B. Applications and limitations

WAF configuration must balance attack blocking with application compatibility and careful monitoring.

• Placement: Put WAF in front of public web endpoints, such as an Application Gateway listener for https://portal.example.com.
• Tuning: Review rule IDs, matched request fields, and application responses before changing exclusions.
• Rate controls: Custom rate-limit rules can restrict excessive requests from a client pattern, complementing DDoS controls.
• Limitation: WAF does not protect non-HTTP protocols such as SSH or arbitrary database traffic.
• Encrypted traffic: WAF must terminate or otherwise inspect TLS at the protected edge; traffic it cannot decrypt cannot be evaluated by content rules.
• Application responsibility: Secure coding, input validation, authentication, patching, and authorization remain necessary because WAF is a compensating network control, not a complete application defense.

VIII. DDoS Protection Standard

A. DDoS Protection Standard

DDoS Protection Standard is an Azure service that provides enhanced protection, telemetry, and mitigation for public IP resources against distributed denial-of-service attacks.

• Attack objective: DDoS attacks attempt to exhaust bandwidth, connection capacity, protocol resources, or application resources.
• Protection scope: The plan can protect eligible public IP resources across linked VNets in the subscription or configured scope.
• Adaptive tuning: Protection uses traffic baselines to distinguish normal behavior from attack conditions, reducing dependence on fixed thresholds.
• Mitigation: Azure’s platform absorbs and mitigates large volumetric and protocol attacks while legitimate traffic is preserved where possible.
• Telemetry: Metrics and alerts provide visibility into attack state, mitigation activity, and protected resource impact.
• Cost support: DDoS Protection Standard includes DDoS cost protection mechanisms for eligible attack-related resource scaling, subject to Azure terms and conditions.

B. Applications and limitations

DDoS Protection Standard is most effective when combined with resilient architecture and application-aware controls.

• Public exposure: Associate protection with VNets containing public-facing load balancers, Application Gateways, or public IPs.
• Architecture: Use multiple instances, autoscaling, health probes, and zone or regional redundancy so one overwhelmed component does not cause total outage.
• Complementary control: WAF handles malicious HTTP request patterns, while DDoS Protection Standard addresses volumetric and protocol-level attacks.
• Monitoring: Configure Azure Monitor alerts for attack metrics and integrate them with incident-response procedures.
• Limitation: DDoS protection does not fix vulnerable application code, stolen credentials, abusive authenticated users, or ordinary performance bottlenecks.
• Design principle: Minimize direct public IP exposure and place public services behind controlled, monitored entry points.