my customer had a problem with this threat. They have a internal app which was failing when palo alto updates changed the action to reset-both. Customer told me that this problem started last 15/06 but i went to the PA updates mails and i didnt see anything about changing the action for this threat (SMB: User Password Brute-force Attempt ID 40004)
In default action we can see alert but PA is doing "reset both"
did you make sure the rule is set to action 'default'? If it is set to anything else, the default action of the threat will be ignored.
My appologies, I didn't look at the threat-id very close and mistook it for a error that we were having earlier.
1) Make sure that your Vulnerability Protection Profile isn't changed from the default action.
2) In the meantime you might want to setup a rule that allows the application connection from Trust users to that specific IP address with everything except a Vulnerability Protection Profile to mediate the issue for the time being. If I would have to guess though your Protection Profile is set to something other then default.
It might be a good idea to have your programmers look at the application though. It sounds like if someone enters in the wrong password then the application is rapidly trying to login without a pre-defined wait period between authentification tries. Unless this is happening everytime a user logs in but I imagine it would be a more pressing issue if they physically could not access the application.
the action of your rule "deny high" is set to 'block' instead of 'default', this will override all default actions and will block every high and critical (even if the default action is alert)
additionally, the 'enable' checkbox for threat exceptions is checked for threat 40004 which means it would need to override the policy action with it's own action. in this case allow
can you make sure that policy has been properly committed and verify the logs the customer is seeing are being interpreted correctly ?
because threat 40004 is set to 'allow' it should be totally ignored and not logged. if you do see this threat in the logs, they may be hitting a different vulnerability profile (the default one maybe?) or the policy may not have been committed properly (try commit force)
hope this helps
The profile they use is IPS_ALERT_ALL. You can see the config above. They changed the action alert fot the threat "SMS Brute force" to allow, because firewall was dropping the packets in a internal app.We dont know why suddenly FW started to detect this threat in a normal traffic. What "SMB BRUTE force" detects), how many tries per time in order to detect it as threat???
I'm not sure what the exact parameters are but this signature should be unchanged since 2010 (check out threatvault )
Maybe some software was updated on the customer's network that caused a certain event to increase in frequency, triggering the signature? you could try setting up a packetcapture to see what is going on exactly
@s.williams1 you can't
packetcapture is enabled|disabled on the profile level
If you create a security policy exclusively for application 'smb' and give it it's own security profile with packetcapture enabled, you'd only capture packets related to smb
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!