We've been noticing that we are getting quite a bit of brute force ssh attempts on our system, so we decided tonight to put in a rule that blocks those attempts. I took one of our existing policies that just logs everything, and added an exception that would block ssh brute forcing. Originally the action we set was block-ip, and we set it to block the ip for 30 minutes. However, when I ran a brute forcer against one of our servers, I saw all my connections coming in (about 3k) and it showed up in the monitor log as a brute force threat. Even though it classified as a threat, it doesn't seem that it blocked my ip at all. I ran the test multiple times and it kept detecting me, but not blocking me.
I then switched the action to drop, and it worked great, it blocked me after about 20 attempts. Anyone know why the block-ip action wouldn't work, but drop would? Also, seems like it took about 5 minutes until I could SSH back in. That time is probably fine, but anyone know how long it's supposed to start accepting packets from an ip address once it has detected a threat?
The security policy is configured to only allow SSH, ping and rsync connections from all destinations. The rule for vulnerabilities is to alert on all medium to critical vulnerabilities. We added an exception for the SSH Brute Force vulnerability, since we were seeing quite a few in the logs. Originally, the action on the exception was block-ip for 30 minutes, which wasn't working. We then set the action to drop, and it worked fine. Is that enough information to make it clearer?
You'll want to check with TAC directly, but I believe there were a few issues specifically with the "block-ip" action that were addressed as part of the 4.1.7 PAN-OS release.
The release notes will contain a section 'Addressed Issues' that will list customer found problems. Release Notes can be found Support site -> Software Updates or in the Device WebUI(Device->Software).
Here are a couple of bugs fixed in 4.1.7 related to block-ip:
41427 – On platforms that contain multiple data planes, aggregate DoS protection rules
do not properly enforce block IP actions if the session is hosted by a dataplane other than
41331 – On platforms that contain multiple dataplanes, block IP actions using custom
vulnerability definitions are not enforced properly unless the session is being processed by
Hope this helps,
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 Live Community as a whole!
The Live Community thanks you for your participation!