Receiving Many Threat Email Alerts For Same Type Of Event
13534
Created On 12/18/20 21:22 PM - Last Modified 07/21/21 19:08 PM
Symptom
- Receiving many Threat Email Alerts for the same type of event
Environment
- Palo Alto Networks Firewall
- PAN-OS 9.0 or higher
Cause
The firewall is configured to source Email Alerts whenever the threat is identified, and therefore the email alert flood is expected.
The firewall can rate-limit the number of threat detection event repeats to an extent with Log Suppression, however, this is not sufficient to rate-limit the Email alerts.
Resolution
Workaround: Implement a 5 minute re-trigger timer for Email Alerts related to FTP Brute Force attempts. The FTP Brute Force attempts are configured for a 1 minute block-ip action, but only one email alert every 5 minutes is desired.
- Find the Security Policy name matching the event that we want to temporarily suppress from generating additional Email Alerts. In our example we want to suppress Email Alerts for 5 minutes for any brute-force signatures.
- Open the Detailed Log view by clicking the magnifying glass icon at the left of the log entry, and identify the name of the Log Forwarding Profile being used.
- Clone the Log Forwarding Profile that's in use. Concatenate "Cool off" or another descriptive name to identify the clone.
- Go to Objects > Tags > Add. In our example we create a tag named "brute-force"
- Create a Dynamic Address Group under Objects > Address Groups > Click Add. Define a Name, Match condition (should match the Tag name created in Step 2), and also Tag the object using the Tag created in Step 2.
- Clone the current Security Policy being matched to precede it. You can concatenate a descriptive name like Cool-off.
The resulting policies should look like:
- Define the Source Address to use the Dynamic Address Group created in Step 5.
- Go to the Actions tab and define the Forwarding Profile Clone to the Security Policy.
- Edit the original Log Forwarding Profile.
Exclude category-of-threatid brute-force by appending the following to the filter: (category-of-threatid neq brute-force). Note that 'brute-force' is part of the signature metadata and it is case sensitive, use all lower case.
Create a new Log Forwarding Profile Match List named "Tag to Cool Off"
- Create a Built In Action for the newly created Log Forwarding Profile Match List.
Action: Add Tag
Registration: Local User-ID
Timeout (min) to specify for how long new alerts should be suppressed.
Tags: Define the Tag created in Step 4. (brute-force in our example).
- Edit the newly cloned Log Forwarding profile, and configure the appropriate filter to ignore the condition that IP's were tagged for. In our example (category-of-threatid neq brute-force). Note that 'brute-force' is part of the signature metadata and it is case sensitive, use all lower case.
- Commit your configuration.
- Verify that it is working properly
The traffic matches the new Log Forwarding profile which is configured to except Email alerts for category-of-threatid: brute-force.
Note that if the frequency of alerts is too high there may a few alerts that slip through until the IP tagging kicks-in in the MP and the data is propagated to the DP, however this mechanism should suppress the majority of the follow-on alerts.
Once the set time (in this case 5 minutes) has passed, the Tag will be automatically removed from the source IP, moving traffic to match the original Security Policy rule.
Additional Information
You can view the history of tagged IP's in the IP-Tag logs in the WebUI under Monitor > Logs > IP Tag
Alternatively, the logs can be viewed in the CLI using command:
> show log iptag tag_name equal brute-force