New Blog | Validating FTP traffic scenarios with Azure Firewall
Written by Gopikrishna Kannan (Head of Products: Azure Firewall and Firewall Manager) The Azure Firewall is a cloud-native and intelligent network firewall security service that can be integrated into many different use cases. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability that provides both east-west and north-south traffic inspection. This blog will discuss FTP scenario with Azure Firewall. FTP or File Transfer Protocol is the most common use case for enterprise customers. FTP may be configured to run in active or passive mode, which determines how the data connection is established. Azure Firewall supports both Active and Passive FTP scenarios. Passive FTP mode requires FTP client to initiate connection to the server on a specified port range. Passive FTP is the recommended approach for East - West (E-W) scenarios. In Active FTP mode, the server initiates connection to the client. This approach is typically deployed to support internet clients connecting to the FTP server running behind Azure Firewall and requires more than 250 DNAT ports (Azure Firewall DNAT rule limits) to be opened hitting load balancer limits. By default, Passive FTP is enabled, and Active FTP support is disabled to protect against FTP bounce attacks using the FTP PORT command. Read the blog: Validating FTP traffic scenarios with Azure Firewall - Microsoft Community Hub
New Azure Network Security and Azure Sentinel Blog Posts | Integrating Azure Sentinel/Azure Firewall
We’re excited to announce a seamless integration between Azure Firewall and Azure Sentinel. Now, you can get both detection, prevention and response automation in the form of an easy-to-deploy Azure Firewall solution for Azure Sentinel. Combining these capabilities allow you to ensure that you both prevent sophisticated threats when you can, while also maintaining an “assume breach mentality” to detect and quickly/automatically respond to cyberattacks. The Azure Firewall Solution for Azure Sentinel is now available. Please see the security community blog to learn about the new threat detections, hunting queries and automation for Azure Firewall that are included in this new solution <Optimize security with Azure Firewall solution for Azure Sentinel - Microsoft Security>. The automation capability for Azure Firewall with Azure Sentinel is provided with the new Logic App Connector and Playbook Templates. With this integration, you can automate response to Azure Sentinel incidents which contains IP addresses (IP entity), in Azure Firewall. The new Connector and Playbook templates allow security teams to get threat detection alerts directly in a Microsoft Teams Channel when one of the Playbooks attached to an Automation Rule triggers based on a Sentinel detection rule. Security incident response teams can then triage, perform one click response and remediation in Azure Firewall to block or allow IP address sources and destinations based on these alerts. To learn more about deploying, configuring and using the automation for Azure Firewall with the new Custom Logic App connector and Playbooks, please review the instructions in the blog here <Automated Detection and Response for Azure Firewall with the New Logic App Connector and Playbooks (microsoft.com)>. Original Post: New Azure Network Security and Azure Sentinel Blog Posts | Integrating Azure Sentinel/Azure Firewall - Microsoft Tech CommunityAzure WAF Security Protection and Detection Lab now Available
Azure Web Application Firewall Security Protection and Detection Lab is now available. The intent of this lab is to allow customers to easily test and validate the security capabilities of Azure WAF against common web application vulnerabilities/attacks. A significant amount of work has been put into developing the lab environment and the playbooks for our customers, and we are incredibly proud of the teamwork, collaboration, and support throughout the various stages of the process. The lab is now available on Azure Tech Community blog space and is organized in 5 sections. The step by step instructions in the lab allows anyone to rapidly deploy the lab environment and test Azure WAF’s protection capabilities against common web application attacks such as Reconnaissance, Cross-Site Scripting, and SQL Injection with no or minimal know-how of offensive security testing methodology. The lab also demonstrates how to use Azure WAF Workbook to understand how WAF handles malicious traffic and payloads. Click here for a Tutorial Overview an introduction to the testing framework used in the lab, and the four-part instructions one the lab setup.
New Blog | Loop DDoS Attacks: Understanding the Threat and Azure's Defense
By Amir Dahan In the realm of cybersecurity, Distributed Denial-of-Service (DDoS) attacks are a significant concern. The recent holiday season has unveiled a complex and evolving threat landscape, marked by sophisticated tactics and diversification. From botnet delivery via misconfigured Docker API endpoints to the NKAbuse malware's exploitation of blockchain technology for DDoS attacks, the tactics and scale of these attacks have shown significant sophistication and diversification. Understanding and staying abreast of recent DDoS trends and attack vectors is crucial for maintaining robust network security and ensuring the availability of services. One such example is the recent HTTP/2 Rapid Reset Attack, where Microsoft promptly provided fixes and recommendations to safeguard web applications. This vulnerability exploits the HTTP/2 protocol, allowing attackers to disrupt server connections by rapidly opening and closing connection streams. This can lead to denial of service (DoS) conditions, severely impacting the availability of critical services and potentially leading to significant downtime and financial losses. Another example we wrote about were reflected TCP attack vectors that recently emerged in ways that were not believed possible before. By closely monitoring these emerging threats, security professionals can develop and implement timely and effective countermeasures to protect their networks. This proactive approach is essential for anticipating potential vulnerabilities and mitigating risks before they can be exploited by malicious actors. Furthermore, understanding the evolving landscape of DDoS attacks enables the development of more resilient security architectures and the enhancement of existing defense mechanisms, ensuring that networks remain secure against both current and future threats. In this blog, we focus on the newly revealed Application Loop DDoS attack vector. Microsoft hasn’t witnessed this vulnerability translated to actual DDoS attacks yet. However, we believe it’s important to highlight the threat landscape we see in Azure for UDP reflected attacks, as they present a prevalent attack vector with similar base pattern as Loop attacks. We then discuss what protection strategies Microsoft employs to protect Azure platform, our online services, and customers from newly emerging threats. The Emergence of Loop DDoS Attacks The Loop attack vulnerability was disclosed last month by CISPA. The attack exploits application-layer protocols relying on User Datagram Protocol (UDP). CISPA researchers found ~300,000 application servers that may be vulnerable to this attack vector. The published advisory describes Loop attacks as a sophisticated DDoS vector, exploiting the interaction between application servers to create a never-ending (hence the term Loop) cycle of communication that can severely degrade or completely halt their functionality. This attack method uses spoofed attack sources to create a situation where two or more application servers get stuck in a continuous loop of messages, usually error responses, because each server is programmed to react to incoming error messages with an error message. Amongst the vulnerable applications, TFTP, DNS, NTP as well as legacy protocols, such as Echo, Chargen, QOTD, are at risk. The researchers provided a practical example of this, when two DNS resolvers automatically reply to error messages with their own errors. An attacker can start a loop by sending one fake spoofed DNS error to one resolver. This makes it send an error to the spoofed resolver, which does the same, creating an endless cycle of errors between them. This wastes the DNS servers' resources and fills up the network links between them, with the potential to cause serious problems in service and network quality. Depending on the exact attack topology, Loop attacks may generate excessive amounts of traffic like other volumetric DDoS floods (e.g. DNS reflected amplified attacks). How Loop DDoS differs from other volumetric DDoS attacks The Loop attack is a kind of DDoS attack vector that targets applications and may manifest as a large-scale flood at the network layer as well. The cause is that attackers can set up multiple attack loops among multiple servers in a network or across networks in the peering links, overwhelming the servers and networks with traffic floods. Like UDP reflected attacks, Loop attacks use a basic UDP weakness – the possibility to fake a source IP address to initiate the attack Loop. One of the most common attack vectors nowadays is the reflected UDP-based floods. It’s similar to Loop attack in that the malicious actor sends spoofed-source packets to an application server that replies to the spoofed IP, i.e. the victim. By generating many of these requests to an application server, the victim gets many of the responses they didn’t ask for. The impact of the reflected attack may be significantly more disastrous if the attacked application generates more traffic in response that it receives in the request. When this happens, it becomes a reflected amplified attack. Amplification is the secret sauce of why these attacks are dangerous. Loop attack is different than reflected amplified attacks in that the response may not necessarily be amplified. That is, for each spoofed packet sent to the application server, there may be a single response. However, Loop attacks are way more dangerous when the victim server who gets the response replies with its own response, which in turn is answered with another response in a loop that never ceases. For the malicious actor, it takes only a single well-crafted packet to create a Loop attack. If the attack is sent between multiple application servers, it is becoming a volumetric DDoS flood that may risk not only the application, but also the underline networks. Another interesting difference between reflected amplified UDP attacks and the Loop attack is that with Loop attack the malicious actor doesn’t control the attack lifecycle. Once the first packet is generated the Loop starts, and there’s no way for the attacker to stop it. Reflected Amplified Attack Landscape in Azure Since reflected amplified UDP attacks are similar to Loop attacks in their basic reflection pattern and their volumetric nature, we provide recent reflected attack landscape in Azure. As we see in the figure, UDP reflected amplification attacks account for 7% of all attacks in the first quarter of 2024. Figure 1 - distribution of main attack vectors in Azure, January-March 2024 Read the full post here: Loop DDoS Attacks: Understanding the Threat and Azure's DefenseNew blog post | Illumio for Azure Firewall
Illumio for Azure Firewall - Combines Benefits of Zero Trust Segmentation and Cloud-Native Firewall - Microsoft Community Hub Illumio for Azure Firewall enables organizations to understand application traffic and dependencies and apply consistent protection across environments - limiting exposure, containing breaches, and improving efficiency. Cloud environments are dynamic in nature with applications commonly deployed as code and continuously scaling up and down. This makes it more challenging for organizations to secure their applications and gain visibility into application traffic. Organizations need a holistic view of their environment and granular controls to be able to understand risk exposure and protect against emerging threats.New Blog Post | Hunting Queries and Response Automation in Azure Firewall Solution for Sentinel
New Detections, Hunting Queries and Response Automation in Azure Firewall Solution for Azure Sentinel (microsoft.com) Recent breaches surface the need for all organizations to adopt an assume breach mindset to security. While organizations continue to invest heavily in the products and technology to prevent breaches, having automated threat detection and response capabilities to identify malicious actors and actions in your environment has become the need of the hour. To enable these capabilities at scale, organizations need to have cutting-edge monitoring and response tools along with the detection logic to identify threats. The cloud native Azure Firewall provides protection against network-based threats. Azure Sentinel is the cloud native SIEM and SOAR solution which provides threat detection, hunting, and automated response capabilities for Azure Firewall. While this is great, customers must go through multiple blades and steps in Azure Sentinel to deploy and configure all the detections, hunting queries, workbooks, and automation, which can be an overhead. Readers of this post will hopefully be aware of the ever-growing integration between Azure Firewall and Azure Sentinel 1 . At Microsoft, we continue to innovate best security detection and response experiences for you, and we are excited to present the Azure Firewall Solution for Azure Sentinel, as announced in the blog post Optimize security with Azure Firewall solution for Azure Sentinel 2 . The Azure Firewall Solution provides Azure Firewall specific net new detections and hunting queries. The solution also contains a new firewall workbook and automation components, which can now be deployed in a single, streamlined method. Original Post: New Blog Post | Hunting Queries and Response Automation in Azure Firewall Solution for Sentinel - Microsoft Tech Community
