This article is contributed. See the original author and article here.
This post will detail how to create enriched DDoS Protection alerts that will provide the information needed to triage and respond.
When Azure DDoS Protection Standard is enabled, the expectation is that any potential attack will be mitigated, and no additional response will be needed. However, like any security control, security teams often require visibility into the process of DDoS mitigation. For this reason, it is highly recommended that you enable diagnostic logging for Public IP Address resources to ensure valuable data is generated.
In the event of an ongoing attack, security teams have access to DDoS Mitigation flow logs, which record all traffic observed during a mitigation event, including whether it was allowed or dropped, the drop reason if applicable, and the source IP address. All this data allows teams to investigate the sources, tactics, and techniques of an attack, even if the actual mitigation is handled by Azure. In the event that support is needed during an attack, DDoS Protection Standard allows access to Rapid Response support.
Since many security teams are concerned with alert fatigue, false positives, and generally not wanting to have to waste time investigating low priority alerts, it is important for these alerts to be truly actionable. We have received requests from customers to allow the owners of the resources being attacked to help determine whether intervention is required by the security team.
An ARM template recently posted to the Azure network security GitHub repository was created for the purposes detailed above. The template will create all components necessary for a detailed DDoS Protection alert that gets sent to the resource owner in addition to the security team, and even performs a basic availability check against the resource under attack.
Azure Monitor Alert
The first stage in the process is to detect the DDoS attack, which is done here by an Azure Monitor alert rule. This can also be done using Azure Security Center or Azure Sentinel, and our plan is to create samples of the same logic described in this post for both Sentinel and Security Center (look for more upcoming blog posts).
The query defined in the alert rule uses the DDoSMitigationNotifications category in the AzureDiagnostics table, which is written to as part of the diagnostic settings of Public IP Addresses. This event is the first data written when a DDoS mitigation event starts, so it is the perfect event to use for an alert.
AzureDiagnostics
| where Category == "DDoSProtectionNotifications"
| where type_s == "MitigationStarted"
| project ResourceId, SubscriptionId, Message, publicIpAddress_s
By default, the rule runs every 5 minutes, but the template or alert can be edited if you have different requirements. Notice that the query projects 4 fields; those will be very important for the Logic App to use.
An action group is also created by the template and attached to the alert rule. The action group consists of only a webhook action, which is pre-populated by the webhook address of the Logic App trigger. If other actions are needed, such as direct email or SMS, those can be added later.
Logic App Alert Enrichment
The Logic App deployed by the ARM template is triggered by a webhook request, which is expected to pass Azure Monitor alert data using the default schema. The fields projected by the alert query will be passed to the Logic App for reuse.
The raw JSON sent to the webhook looks like the following, with the projected query results contained in a row object at the bottom:
After receiving the webhook request, the first step of the Logic App is to query the Azure Resource Graph using fields parsed from the from the alert JSON. The basis of the query being run is one that can be found on our GitHub repo. The query will return more information about the resource behind the Public IP Address, which is information not readily available in the standard diagnostic logs or even Security Center. For example, a public IP address can be associated to Application Gateways, Load Balancers, VMs, or Network Virtual Appliances (NVAs).
In addition to the resource type and name, an important piece of metadata returned by the query is tag information. Specifically, the owner tag is parsed to determine who to email in the event of an attack against the IP address. If it is not standard policy to populate this tag in your environment, there are Azure Policies available to do this automatically. Alternatively, the Logic App can be edited to use some other tag to determine the recipient of the alert.
DDoS attacks commonly target web applications as the most visible and valuable assets, but other publicly facing resources can and do get attacked. The Logic App will initiate a test, a simple HTTP GET on port 80, against the IP address being attacked. This is of course making an assumption that there is a web application running behind the IP address and listening on port 80. This assumption is meant to provide extra information about the status of the asset under attack, which will be surfaced in the alert.
Based on both the query results and the results of the HTTP request, an email alert is finally sent to both the security team, as identified in the ARM template parameters, and the owner of the attacked resource.
In the example email, actionable information is provided about the resource being attacked, including the status of the HTTP test. In this case, the resource associated to the Public IP Address is an Application Gateway, and the availability test returned a 502 Bad Gateway, which can indicate that the backend resources are unavailable. If this is the case, both the resource owner and the security team can work together to respond with the help of Microsoft Support.
When deployed in your environment, the ARM template for enriched alerting will provide an excellent starting point for you to customize to the needs of your environment and response procedures.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments