Implement Platform Protection: Azure Firewall (Part 2)

By Ashwin Venugopal -

 


To read part 1 please click here

Azure Firewall

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. By default, Azure Firewall blocks traffic. The Azure Firewall features include:

  • Built-in high availability- As high availability is built in, no additional load balancers are required and there is nothing you need to configure.
  • 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 to a specified list of FQDNs, including wild cards. This feature does not require SSL termination.
  • Network traffic filtering rules- You can centrally create, allow, or deny network filtering rules by source and destination IP address, port, and protocol. Rules are enforced and logged across multiple subscriptions and virtual networks.
  • FQDN tags- Fully qualifies Domain Names (FQDN) tags make it easier for you to allow well known Azure service network traffic through your firewall.
  • Outbound Source Network Address translation (OSNAT) support- All outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP. You can easily identify and allow traffic originating from your virtual network to remote internet destinations.
  • Inbound Destination Network Address Translation (DNAT) support- Inbound network traffic to your firewall public IP address is translated and filtered to the private IP addresses on your virtual networks.
  • Azure Monitor logging- All events are integrated with Azure Monitor, allowing you to archive logs to a storage account, stream events to your Event Hub, or send them to Azure Monitor logs.   

After grouping the features above into logical groups we can determine that Azure Firewall has three rule types- NAT rules, network rules, and application rules.

NAT rules

Inbound connectivity can be configured by configuring DNAT. First of all, filter inbound traffic with Azure Firewall DNAT using the Azure portal. DNAT rules are applied first and if a match is found, an implicit corresponding network rule to allow the translated traffic is added. You can also override this behavior by explicitly adding a network rule collection with deny rules that match the translated traffic. No application rules are applied for these connections.

Firewall rules to secure Azure storage

Azure Storage provides a layered security model, which enables you to secure your storage accounts to a specific set of supported networks. An application that accesses a storage account when network rules are in effect requires proper authorization on the request. By default, storage accounts accept connections from clients on any network and to limit its access to selected networks, you must first change the default action. You should be sure to grant access to any allowed networks using network rules before changing the default rule to deny access.

Azure Firewall Implementation

With the help of Azure Firewall, you can configure:
  • Application rules that define Fully Qualified Domain Names (FQDNs) that can accessed from a subnet.
  • Network rules that define source address, protocol, destination port, and destination address.

Network traffic is subjected to the configured firewall rules when you route your network traffic to the firewall as the subnet default gateway.

Firewall Concepts

Controlling the outbound network access is an important part of an overall network security plan and you can control it with Azure firewall by configuring Application rules that define source address, protocol, destination port, and address. Network traffic is then subjected to the configured firewall rules when you route your network traffic to the firewall as the subnet default gateway.

FQDN Tags

An FQDN tag represents a group of fully qualified domain names associated with well-known Microsoft services. By using FQDN tags, you can create an application rule while including the Windows Updates tag, and now network traffic to Microsoft Windows update endpoint can flow through your firewall.

Infrastructure of FQDN

Azure Firewall includes a built-in rule collection for infrastructure FQDNs that are allowed by default. The following services are included in the built-in rule collection:
  • Compute access to storage Platform Image Repository (PIR).
  • Managed disks status storage access.
  • Azure Diagnostics and Logging (MDS).

Threat intelligence-based filtering

It can be enabled for your firewall to alert and deny traffic from/to known malicious IP addresses and domains. If the threat intelligence-based filtering is enabled, the associated rules are processed before any of the NAT, network, or application rules. You can choose to just log an alert when a rule is triggered, or you can choose alert and deny mode. By default threat an intelligence-based filtering is enabled in alert mode.

Service tags

A service tag represents a group of IP addresses prefixes to help minimize complexity for security rule creation. Microsoft can easily manage the address prefixes encompassed by the service tags, and automatically updates the service tag as and when the addresses change. Azure Firewall Service Tags can be used in the network rules destination field and also in the place of specific IP addresses.

Remote Work Support

VDI
Work from home policies requires many IT organizations to address fundamental changes in capacity, network, security, and governance. Virtual Desktop Infrastructure (VDI) deployments on Azure can immensely help organizations to rapidly respond to this changing environment. You can use Azure Firewall DNAT rules along with its threat intelligence-based filtering capabilities to protect your VDI deployments. However, you will have to find a way to protect inbound/outbound Internet access to and from these VDI deployments.

Vitual Desktop Support
Windows Virtual Desktop is a comprehensive desktop and app visualization service running in Azure. It is the only VDI that provides simplified management, multi-session Windows 10, optimizations for Microsoft 365 ProPlus , and support for Remote Desktop Services (RDS) environments. Although it doesn't require you to open any inbound access to your virtual network, but you must allow a set of outbound network connections for the Windows Virtual Desktop's virtual machines that runs in your virtual network.

VPN Forced Tunneling

Why do some cases require forced tunneling?
A Virtual Private Network (VPN) consists of remote peers sending private data securely to one another over an unsecured network, like the Internet. This is called Internet Tunneling. Site-to-site (S2) VPNs use tunnels to encapsulate data packets within normal IP packets for forwarding over IP-based networks. 
Forced Tunneling allows you to redirect, or force, all internet-bound traffic back to your on-premises location via a site-to-site VPN tunnel for inspection and auditing. The following figure depicts how forced tunneling works:
You can configure forced tunneling in Azure via virtual network User Defined Routes (UDR). Redirecting traffic to an on-premises site is expressed as a default route to the Azure VPN gateway.

Hub and Spoke topology

The Hub is a virtual network in Azure that acts as a central point of connectivity to your on-premises network, while the Spokes are virtual networks that peer with the Hub, and can be used to isolate workloads. The architecture consists of the following components:
  • On-premises network- A private local-area network running within an organization.
  • VPN device- A device or service that provides external connectivity to the on-premises network.
  • VPN virtual network gateway or ExpressRoute gateway- The virtual network gateway enables the virtual network to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network.
  • Hub virtual network- The virtual network used as the hub in the hub-spoke topology.
  • Gateway subnet- The virtual network gateways are held in the same subnet.
  • Spoke virtual networks- One or more virtual networks that are used as spokes in the hub-spoke topology.
  • Virtual network peering- Two virtual networks can be connected using a peering connection.


To read part 1 please click here



















Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more