How to submit a brute force signature false positive
2640
Created On 06/27/22 16:44 PM - Last Modified 10/22/24 09:58 AM
Objective
This article will explain how to do basic troubleshooting and investigation on the triggered brute force signature and what to collect when reporting possible false positive on the brute force signatures.
Environment
All PAN-OS version
Procedure
Details about brute force signatures, triggering conditions and matching logic can be found in below link:
Brute force signature and related trigger conditions
Note:
When dealing with brute force signatures the most important thing is to understand nature and the concept of the brute force signatures in the PAN-OS. Each brute force signature has its own associated child signature and they are forming logical and functional pairs in related brute force events. Child signature is the brain in the pair and is looking for its own defined matching logic in the network traffic. Parent brute force signature is only the counter in the pair and should trigger only if it matches against own configured attributes thresholds - number of hits of the child signature in defined time range and per aggregation criteria.
For example below signatures are forming one pair.
31914 SSH2 Login Attempt The child signature, 31914 is alert on every connection on the ssh server. 40015 SSH User Authentication Brute-force Attempt If a session has the same source and destination but triggers our child signature, 31914, 20 times in 60 seconds, we call it a brute force attack. Brute force signature's attributes are delivered with predefined default values and can be changed to reflect desired conditions in your network.
How to investigate triggers on a brute force signature?
In order to investigate possible brute force events usually only threat captures on the related signatures are required and sufficient regarding certainty around an event and false positive nature of the trigger. If relevant threat captures are not already seen in your environment for desired signatures you have details how to enable it for specific signature below:
How to enable threat packet capture for a specific anti-spyware signature?
Most common brute force triggers seen in the threat logs can be summed up in below four scenarios:
Scenario 1:
Only brute force signature (parent signature) is seen in the threat logs - no related child signature seen in the threat logs.
Action to be taken for further investigation:
Find matching police and vulnerability profile for brute force/parent signature (UTID 40015) and enable logging and threat capture for corresponding child signature (UTID 31914) by creating threat exception for the child signature configuring action to ALERT and configuring packet capture part from "disable" to "single-packet".
How to do this?
From threat logs find a matching rule if a "Rule name" column is added in the logs or from a detailed log view clicking on the magnifier. From there you can find associated vulnerability profiles.
Once this is done next time when conditions are matched for child signature you should see logging entry and threat capture information in the threat log for the child signature. If you know triggering conditions which led to the trigger of the parent signature in the log you can replicate it and see the child signature. If the issue is not reproducible per requirement, neither you know what led to the trigger or you are simple not controlling client machine, you will have to wait for the next brute force event.
What next?
Export threat capture (green arrow) and see if the logic is matched against a child signature.
If the logic is matched next check if configured attributes are matched for the parent/ brute force signature.
Threat captures of interest for later reporting and collection part marked in red rectangles.
Attribute values are changed from default values for parent signature UTID 40015 and we can see it triggered correctly as before trigger on the parent signature we do see 10 times trigger on the child signature in 60 seconds.
Note: It is possible to see different number of child signature before parent is triggered and it is explain in following article:
Threat log generation criteria for brute force parent/child signatures
How to deal with situation when legit traffic is correctly hit brute force signature?
In above example since both child and parent signatures triggered correctly and as per configuration this is not a case of the false positive on brute force. Firewall is only looking at network traffic and parent signature configured attributes. Firewall does not take into consideration possibility neither it is aware that your client seen in threat logs (source IP) for brute force signatures is maybe your local/remote scanner and someone performed planned scanning activity. Firewall does not take in consideration possibility neither it is aware of your network topology and that NAT is performed for the subnet where your network admins are located and all traffic due nature of their operations is visible to Firewall as a single IP hence 10 different SSH connection from 10 different admins in 60 seconds would be trigger UTID 40015 with modified values as in example above.
Depending on the context and depending on your security requirements and depending on your wishes there are different approaches to deal with this kind of legit and expected situation possible applicable in your environment and network. You can consider creating threat exceptions in different forms like, threat exception with different action, threat exception for specific IP, threat exception with or without logging in the threat logs, fine tuning threshold values for parent signature, etc. There are enough different configuration changes you can do in order to fit your desired and preferred adjustment for the observed and investigated brute force event..
Important note: Support can not make final decision on your behalf in this kind of situation.
How to report true false positives on brute force signatures?
If you do not see matching logic for a child signature or you see an incorrect counter for parent signature you can collect following data set and report to us.
What to collect?
1. Collect the output of "show system info" from the CLI of your firewall, or copy the "General Information" pane from the Dashboard of your WebGUI.
2. Collect first 3 threat captures of child signature seen in sequence (counter of parent signature is counting these as first, second and third hit) and 3 threat captures before parent signature triggered in related and relevant investigation time frame of brute force event. We do not need all seen threat captures for child signature.
For clarification look at picture above Threat captures of interest for later reporting and collection part marked in red rectangles.
3. Threat logs: Please export only relevant brute force threat logs in the CSV format by placing required filter to narrow down the export and upload it to the case. Log should contain entries from first triggered child signature till triggered parent signature and they should correspond to collected threat captures.
For clarification sufficient threat logs are seen as well in the same picture Threat captures of interest for later reporting and collection part marked in red rectangles.
Note: Threat captures are required and must have for any initial investigation.
Place all required data in one password protected ZIP file, name it per your preference and place prefix in the front of the chosen name like 20220627-FP-SSH User Authentication Brute-force Attempt.zip, upload only ZIP file and share the password. In case that additional data set is required this will help us to keep things in clear manner and clear order under the same ticket with different uploaded data sets.
Scenario 2:
Child signature is seen in a threat log with action reset-both and no associated threat captures.
Action to be taken for further investigation:
Find matching police and vulnerability profile for child signature (UTID 31914) and enable logging and threat capture for child signature by creating threat exception for the child signature configuring action to RESET-BOTH and configuring packet capture part from "disable" to "single-packet".
Next action?
Follow the same procedure detailed explained under Scenario 1.
Note: You might notice same source/destination IP, same rule and same matched profile under threat logs for same signatures with different action like seen for Scenario 1. How is this possible? There are different situations which can lead to these situations and usually they are reflecting configuration on the Firewall. Here, the root cause of the difference for the action on the child signature is due configuration changes done on the profile "TAC KB" before data collection is done for scenario 2. Configured action on all signatures with informational severity in "TAC KB" profile is changed from "default" to "reset-both" and there was no configured exception in modified profile yet hence above behavior is correctly reflecting what has been configured.
Scenario 3:
Child signature is seen in a threat log with action ALERT and no associated threat captures.
Action to be taken for investigation:
Find matching police and vulnerability profile for child signature (UTID 31914) and enable logging and threat capture for child signature (UTID 31914) by creating threat exception for the child signature configuring action to ALERT and configuring packet capture part from "disable" to "single-packet".
Next action?
Follow the same procedure detailed explained under Scenario 1.
Scenario 4:
Child signature is seen in a threat log and there is already an associated threat capture.
Next action?
Follow the same procedure detailed explained under Scenario 1.