IT security administrators are often called on to troubleshoot network issues. For instance, a critical application may exhibit latency or disconnections, frustrating end users. These issues may be caused by a recent routing update or changes in security. In some cases, the cause may be due to a sudden burst in network traffic—overwhelming the network resources.
Microsoft Azure Firewall now offers new logging and metric enhancements designed to increase visibility and provide more insights into traffic processed by the firewall. IT security administrators may use a combination of the following to root cause application performance issues:
o Latency Probe metric is now in preview.
o Flow Trace Log is now in preview.
o Fat Flows Log is now in preview.
Azure Firewall is a cloud-native firewall as a service offering that enables customers to centrally govern and log all their traffic flows using a DevOps approach. The service supports both application and network-level filtering rules and is integrated with the Microsoft Defender Threat Intelligence feed to filter known malicious IP addresses and domains. Azure Firewall is highly available with built-in auto-scaling.
Latency Probe metric—now in preview
In a network infrastructure, one may observe increases in latency depending on various factors. The ability to monitor the latency of the firewall is essential for proactively engaging in any potential issues with traffic or services in the infrastructure.
The Latency Probe metric is designed to measure the overall latency of Azure Firewall and provide insight into the health of the service. IT administrators can use the metric for monitoring and alerting if there is observable latency and diagnosing if the Azure Firewall is the cause of latency in a network.
In the case that Azure Firewall is experiencing latency, this can be due to various reasons, such as high CPU utilization, traffic throughput, or networking issues. As an important note, this tool is powered by Pingmesh technology, which means that the metric measures the average latency of the firewall itself. The metric does not measure end-to-end latency or the latency of individual packets.
Figure 1: Dashboard view of healthy firewall latency measured by the Latency Probe (Preview) metric.
Flow Trace logs—now in preview
Azure Firewall logging provides logs for various traffic—such as network, application, and threat intelligence traffic. Today, these logs show traffic through the firewall in the first attempt at a Transmission Control Protocol (TCP) connection, also known as the SYN packet. However, this fails to show the full journey of the packet in the TCP handshake. The ability to monitor and track every packet through the firewall is paramount for identifying packet drops or asymmetric routes.
To dive further into an asymmetric routing example, Azure Firewall—as a stateful firewall—maintains state connections and automatically and dynamically allows traffic to successfully come back to the firewall. However, asymmetric routing can occur when a packet takes one path to the destination through the firewall and takes a different path when attempting to return to the source. This can be due to user misconfiguration, such as adding an unnecessary route in the path of the firewall.
As a result, one can verify if a packet has successfully flowed through the firewall or if there is asymmetric routing by viewing the additional TCP handshake logs in Flow Trace.
To do so, you can monitor network logs to view the first SYN packet and click "enable Flow Trace" to see the additional flags for verification:
o SYN-ACK
o FIN
o FIN-ACK
o RST
o INVALID
By adding these additional flags in Flow Trace logs, IT administrators can now see the return packet, if there was a failed connection, or an unrecognized packet. To enable these logs, please read the documentation linked below.
Figure 2: Flow Trace logs displaying SYN-ACK and FIN packets.
Top Flows—now in preview
Today, Microsoft Azure Firewall Standard can support up to 30 Gbps and Azure Firewall Premium can support up to 100 Gbps of traffic processing. However, in any case, sometimes traffic flows can either be unintentionally or intentionally “heavy” depending on the size, duration, and other factors of the packets. Since these flows can potentially impact other flows and the processing of the firewall, it’s important to monitor these traffic flows, to ensure that the firewall can perform optimally.
The Top Flows log—or industry-known as Fat Flows—log shows the top connections that are contributing to the highest bandwidth in a given time frame through the firewall.
This visibility provides the following benefits for IT administrators:
o Identifying the top traffic flows traversing through the firewall.
o Identifying any unexpected or anomaly traffic.
o Deciding what traffic should be allowed or denied, based on results and goals.
To enable these logs, please read the documentation linked below.
Figure 3: Top Flow logs displaying traffic with the top flow rates.
Source: microsoft.com
Posts
0 comments:
Post a Comment