- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-09-2010 05:38 AM
03-09-2010 09:50 AM
Regarding the brute force signatures, we are working on opening them
up the signatures to allow administrators to change how many attempts
a client needs to do over a customizable period of time to trigger a
brute force signature. Right now, we don't expose those thresholds in
the product. So here they are:
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 100 times in 60 seconds, we will identify
it as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 14 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 100 times in 60 seconds, we will identify
it as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 25 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 7 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 20 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 40 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 20 seconds, we will identify it
as a brute force attack.
Also, I'm not sure I understand question #4 below. If you could
explain a little bit more of what you're looking for, that would be
great.
Thanks,
Alfred
03-09-2010 09:50 AM
Regarding the brute force signatures, we are working on opening them
up the signatures to allow administrators to change how many attempts
a client needs to do over a customizable period of time to trigger a
brute force signature. Right now, we don't expose those thresholds in
the product. So here they are:
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 100 times in 60 seconds, we will identify
it as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 14 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 100 times in 60 seconds, we will identify
it as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 25 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 7 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 20 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 20 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 40 times in 60 seconds, we will identify it
as a brute force attack.
If a session has the same source and destination and triggers a single
login/authentication event 10 times in 20 seconds, we will identify it
as a brute force attack.
Also, I'm not sure I understand question #4 below. If you could
explain a little bit more of what you're looking for, that would be
great.
Thanks,
Alfred
03-10-2010 05:43 AM
Thank you soooo much, I've been looking for these for days !
While we are at it, how does denying such signature will work ? I guess the deny will be triggered after one minute (when the signature will) and starts dropping further attemps. But if the attacks stops and starts again after a few sec (or even just one), will the first attemps be allowed again for a minute ? Or am I totally wrong ?
03-10-2010 09:17 AM
Once the brute force signature threshold is reached will drop all
further attempts for sampling time frame. So if a signature monitors
over 60 seconds, we will drop all further attempts for 60 seconds.
After that, we will start allowing until the threshold is reached again.
Alfred
03-10-2010 02:41 PM
Hi
Thank you for the reply. Im glad you are working on getting the settings into the product
Some clarification for #4
I'm talking about the signatures that are in the product that look for data patterns for example some sort of buffer overflow. In other products like Cisco, Juniper etc etc you are able to view the "matching pattern" (in regular expression format) for some signatures. Some of the signatures are "protected" because the vendors have agreements with Microsoft etc etc so the vendors are not allowed to give the matching patterns out.
What i'm asking for is the ability to view "what a signatures matches" for all signatures except those you need to protect (encrypt). Also the possibility to change the "matching patterns" on a signatures provided by you would be totally awesome!!
The basic use for that function would be to tune the signatures ourself until we have had time to contact you about a signature that generates alot of false positives and you have tuned the signatures and sent out a new update
//Henrik
03-10-2010 02:58 PM
I understand. We have a closed system where we don't show any of the
signatures on our box except for the custom created regex signatures
that are created by administrators. The only method that we have for
fixing signatures is currently through us. So if there are false
positives, please let support know and we will tune the signature and
release a new update. In the meantime, customers can create an
exception for that signature so that it's effectively disabled.
Alfred
03-31-2010 05:59 AM
Thanks for the explanation. I have another related question : currently we are blocking threats from the level high and above as the medium level seems to be a bit to harsh a level to drop packets at. Since all thoses bruteforce attemps are medium, they are allowed. Is there a way to eitherraise the bruteforce vulnerabilities level to high or add them as blocked ?
Thansk alot !
03-31-2010 11:54 PM
You could do this via a custom vulnerability profile, but the drawback
is that you need to manually add newly released signatures.
Alfred
04-01-2010 12:23 AM
Thansk alot, that would indeed be a bit awfull to manage. So I'm left with 2 options :
1. Customize the severity level for a vulnerability (like applications), bit that's not possible, is it ?
2. Block all medium severity vulnerabilites. Would'nt that lead to too many blocked apps ?
Thaks for advises.
04-01-2010 06:03 PM
1. Customized severity for threats is not currently possible.
2. Blocking all medium severity vulnerabilities shouldn't block apps.
If you want to block the brute force attacks, then I would turn on
blocking for medium severity for server side vulnerabilities.
Alfred
04-03-2010 12:11 PM
For me it is a must to be able to at least be able to customize the severity level for a non-custom vulnerability signature. I understand that PA might not want to allow modification of their internal signatures, but modifying the severity is a very important requirement for my organization. I bet it is the same for many other organizations. After all, what it is medium for some it could be high for others, or the other way around. Everybody has a different risk tolerance.
By the other hand, it would be very useful to be able to have the ability of making a copy of an internal signature and be able to modify it to suit the customer's needs. In that way organizations can leverage the work already made by PA.
I strongly request to add the ability to customize the severity level as a feature in next releases of PAN-OS.
Thanks.
05-26-2010 03:59 AM
Any news regarding the ability to view the "matching pattern" or settings for brute force and scanning signatures directly in the GUI ? Will this be available in future versions?
The ability to view the "matching pattern" is very helpful in deciding if the alarm is a false positive or not. If you have pcap active and can see the "matching pattern" you can make up your own mind if its a FP or not.
//Henrik
06-24-2010 06:29 AM
I just ran into the same requirement ... OfficeMax would like the ability to customize the severity level of a threat in our Threat DB. We already allow them to customize the Risk Level of an App ... they want the same ability for the Severity Level of a Threat/Spyware.
Dave Klein
06-24-2010 03:18 PM
Hello Panse,
you can get a hold of your sales contact or call into support and open up an ehancement request regarding this.
thanks,
Stephen
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!