Episode Transcript:
John:
Hello, and welcome back to PANCast™. In today's episode, we will talk about detecting Brute Force Attacks with Palo Alto Networks Firewalls. Jithu joins us again to talk about this. Before we start Jithu, could you remind our listeners about yourself?
Jithu:
Jithu is a Principal Cybersecurity Specialist in the GCS threat team, he is passionate about Cybersecurity and has a special interest in handling Cyber Incidents and breaches. He has been with Palo Alto Networks for around 7 years.
Hey John, glad to be back. I’m a Principal Cybersecurity Specialist in the Threat team and have been with Palo Alto networks for about 7.5 years now. Our team mainly deals with issues associated with the Threat prevention features of the Palo Alto Networks firewall.
John:
Thanks Jithu, so to start with, what is a Brute Force Attack?
What is a Brute Force Attack?
Jithu:
A brute force attack uses a large volume of requests/responses to break into a system. The attacker employs a trial-and-error method to guess the response to a challenge or a request.
One of the basic examples for a brute force attack is the attacker attempting multiple passwords against a user account with the hopes of guessing the correct password. This is called a Dictionary attack, it’s automated and attackers use a list of commonly used words, phrases, and number combinations to guess the password.
John:
Great, so what coverage do we have in Palo Alto Networks Firewalls?
Coverage in Palo Alto Network Firewalls
Jithu:
Brute force signatures are delivered to the firewall and Prisma Access as a part of content updates and enforced as a part of Vulnerability Profiles. The firewall includes two types of predefined brute force signatures which are parent signatures and child signatures. A child signature is a single occurrence of a traffic pattern that matches the signature. A parent signature is associated with a child signature and is triggered when multiple events occur within a specified time interval and that matches the traffic pattern defined in the child signature.
For example, there is a signature called “SSH User Authentication Brute-Force Attempt” and this has a threat ID of 40015. As the name indicates, this high severity signature detects a brute force attack through multiple login attempts to an SSH server. This is the parent signature and it’s related to a child signature, threat ID 31914 named “SSH2 Login Attempt” which is an informational severity signature.
The child signature 31914 detects every connection to an ssh server and 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 and this is our default trigger criteria.
Typically, the default action for a child signature is “allow” because a single event is not indicative of an attack. This ensures that legitimate traffic is not blocked and avoids generating threat logs for non-noteworthy events. Palo Alto Networks recommends that you do not change the default action without careful consideration. To effectively mitigate an attack, specify the block-ip address action instead of the drop or reset action for most brute force signatures.
Now you may have a question regarding how to find these default trigger conditions and the associated parent and child signatures. We have a Knowledge Base article titled “Brute Force Signature and Related Trigger Conditions” that explains exactly this and I’ll share this in the transcript. Doing a google search with this title name will also give you the link to our knowledge base article, I strongly recommend bookmarking this KB.
John:
How can we change these default trigger criteria?
Changing the Default Trigger Criteria
Jithu:
The default trigger criteria can be modified from Vulnerability profile > Exceptions. Search for the threat ID first after checking “Show All Signatures” and click on the pencil icon next to the Signature name to modify the number of hits and the number of seconds within which that criteria has to be met. Make sure to check the check mark below the “Enable” option to make sure that this modification has been enabled.
The important point to note here is that the action configured under “Exceptions” will take precedence over the action configured under “Rules” in the Vulnerability protection profile. So make sure that the right action is configured for the Threat ID under “Exceptions”.
I’ll also add a link to the KB article for creating exceptions.
John:
How do we deal with False Positives?
False Positive Events?
Jithu:
Now that we understand the logic behind these signatures, try to assess the situation and understand if it’s False Positives. As I mentioned, these default values that we provide could sometimes hit the production traffic for customers if there is a use-case in their end that fits the criteria. Always discuss with the relevant teams that manage the associated traffic to confirm the expected traffic criteria and tweak the trigger criteria like I mentioned before.
If you are not able to confirm that this is a false positive or not, the best action is to continue blocking to be on the safe side. You can also open a ticket with all the details so that we can assess the situation as well.
John:
Great, looks like we have strategies to detect and block Brute Force Attacks
Jithu - what would be the key takeaways for today?
Episode Key Takeaways
Jithu:
The key takeaway is to leverage these Brute Force Signatures, understand the logic behind each signature and harden it as required.
John:
Thanks, Jithu, great info on some of our threat prevention features. You can find the transcript and some valuable links on live.paloaltonetworks.com under PANCast™. Thanks again Jithu.
Jithu:
Thank you for having me, talk to you later.
John:
Hope you have learnt something today PANCasters and remember to subscribe on all popular podcast platforms. Bye for now.
