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

Query, Visualize, & Monitor Data in Azure Sentinel

By Ashwin Venugopal -
Image
  Azure Sentinel Workbooks Several ready for use templates are provided by the Azure Sentinel that can be used to create your own workbook and then modify them as needed for Contoso. Most of the data connectors it uses to ingest data come with their own workbooks, but better insight can be obtained by simply looking into the data that is being ingested by using tables and visualizations, including bar and pie charts. You can also make your own workbook easily by using this data from the beginning instead of using the predefined templates. Workbook Page You can easily access the workbook page from the Azure Sentinel from the navigation pane which consists of the: Workbook header- You can add a new workbook and review the saved workbooks as well as templates that are available on the workbook page. Templates section- You can access existing workbook templates on the Templates tab. You can save some of the workbooks for quick access and they will appear on the My Workbooks tab.  From the
Read more

Planning for Implementing SAP Solutions on Azure (Part 2 of 5)

By Ashwin Venugopal -
Image
  To read part 1 please click  here To read part 3 please click  here To read part 4 please click  here To read part 5 please click  here Load Balancing The load balancer uses probe ports to determine as well as route the traffic to an active DBMS node, but of there's any failover then the most common SAP application architecture can automatically reconnect against the private virtual IP address without the need for the SAP application to reconfigure it, while the load balancer redirect the traffic against the private virtual IP address without any need for the SAP application to reconfigure. The loaf balancer also offers an option of DirectServerReturn which if configured, can help in directing the traffic from the DBMS VM to the SAP application layer directly to the application layer without routing through the load balancer. But, if it isn't configured, then the return traffic to the SAP application layer is routed through the load balancer. You can also use Azure Load Balan
Read more

Work with String Data Using KQL Statements

By Ashwin Venugopal -
Image
  Extract Data from Unstructured String Fields Unstructured string fields often contains the Security log data and requires parsing to extract data. There are multiple ways of pulling information from string fields in KQL and the two primary operators used are extract and parse.  Extract It gets a match for a regular expression from a text string. You can convert the extracted substring to the indicated type.  Arguments regex- A regular expression. captureGroup- A positive int constant indicating the capture group to extract. 0 stands for the entire match, 1 for the value matched by the first '('parenthesis')' in the regular expression, 2 or more for subsequent parenthesis.  text- A string to search. typeLiteral- An optional type literal. If provided, the extracted substring is converted to this type.  Returns If regex finds a match in text- the substring matched against the indicated capture group captureGroup, optionally converted to typeLiteral. If there's no mat
Read more