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?
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!