By David Frazee
The Azure Web Application Firewall (WAF) on Azure Front Door offers centralized protection for your web applications against vulnerabilities and threats. The effectiveness of your Azure WAF in managing traffic can be assessed through WAF logs stored in specified locations such as a Log Analytics Workspace or Storage Accounts. These logs document requests that have been either matched or blocked by WAF rules. This data is crucial for monitoring, auditing, and resolving issues. By default, WAF logs are maintained in a plain text format for user convenience and analysis. However, these client requests might include sensitive personal data, like personally identifiable information (PII), which can include names, addresses, contact details, and financial information. Without proper sanitization, logs containing such PII could be exposed to unauthorized access. To address this, Azure Front Door WAF now offers sensitive data protection through log scrubbing. WAF log scrubbing employs a customizable rules engine to pinpoint and redact sensitive portions within the requests, replacing them with a series of asterisks (******) to prevent data exposure. This blog will explains the log scrubbing process and provides practical examples for a more comprehensive understanding.
Log Scrubbing
The Azure Front Door WAF’s sensitive data protection feature using log scrubbing is compatible with all WAF policy rule sets including Default Rule Set (DRS), Bot Manager Ruleset, and any Custom rules. It utilizes a range of match variables, such as client IP, headers, cookies, and request arguments, to identify data for scrubbing. Rule creation involves selecting a match variable, an operator, and defining a selector, which determines the specific key to be cleansed from the logs. Take a simple login process, which generally involves username and password fields; these are two distinct keys that can be targeted as selectors. Should a dubious login attempt activate the WAF, it records the username and password if they contain the suspect string or code injection. The log scrubber then anonymizes these details, obscuring the malicious content while preserving the attack's characteristics and significantly reducing the risk of personal data exposure.
See below for the full list of Match Variables:
|
Match Variable |
Operator |
Selector |
|
Request IP Address |
Equals any |
<None> |
|
Request URI |
Equals any |
<None> |
|
Request Header Names |
Equals/Equals any |
<Custom> |
|
Request Cookie Names |
Equals/Equals any |
<Custom> |
|
Request Body Post Arg Names |
Equals/Equals any |
<Custom> |
|
Request Body Json Arg Names |
Equals/Equals any |
<Custom> |
|
Query String Arg Names |
Equals/Equals any |
<Custom> |
Request IP, Request URI & Request Header
In our initial scenario, we examine the log scrubbing engine's capability to conceal the requester's IP address, the request URI, and the User-Agent that activated the WAF rule. In this example, the User-Agent is a carrier for a SQL injection string within the User-Agent key's value. The log scrubbing rules are configured so that the selector targets User-Agent within the Request Header Names, ensuring every User-Agent occurrence, including the embedded SQL injection string, is cleansed from the WAF logs. This scenario serves as an example on how to write log scrubbing rules to cleanse potentially sensitive values. It is best practice to specify only those values that contain potential personally identifiable information (PII) or other sensitive data, rather than generic request headers like User-Agent.
Read the full post here: A Closer Look at Azure WAF’s Data Masking Capabilities for Azure Front Door