The purpose of this thread is for everyone to follow the same methodology so we can create a future table, for the benefit of all, that shows how many failed login attempts (hacking) per day per server (and per minute) are happening.
This is not a thread on writing scripts or creating different methods to get the same data; nor it this a thread on how to prevent brute force logins; This thread has a a very simple (not elegant, not interesting) method that everyone can follow and by using the same very simple method, the results will be easy to compare, apples to apples, as follows:
330466 / 22 = 15K ssh login attempts which failed each day, or about 10.4 per minute.
Is that a lot compared to your server?
Please post back your results using the same method:
lastb | head -1
lastb | tail -1
Then take the totals days by comparing the dates in the head and tail, and divide that (the days) into the total number from the lastb | wc -l command and post back (just like I did above)
Thanks.
PS: If all replies use the same method, it will be easy to compare the results in a table or chart later. Please do not use any other method than the very simple one above.
Thanks!
If we get enough replies, I will do a video on the results later.
Difficult to follow precisely without lastb , but grepping ' authentication failure ' in log files, one of my servers has 66,000 failed logins since Sep 22, which is awfully close to your 15,000 a day. Another's log files are too short to be useful for this...
Yes, I find it interesting that when we check for different servers with public Internet access, the number of failed ssh login attempts per minute (FLAPM) converges toward ten per minute.
This is why I think it would be useful to document this using, at least on Linux at the beginning, the same method, which is the simple lastb method I posted, since all major Linux systems use lastb to parse and display the auth log for failed login attempts.
If we use the same methodology, the numbers have more meaning, and if it turns out that there is some convergence to, for example, 10 FLAPM, then it would be interesting to try to understand why.
Yes, my first post was vague and not clear, so I started over and tried to be more clear.
That's what happens when I am multi-tasking many tasks at once and just do a "quick post" without putting my full thoughts down in the post. My bad and sorry for the earlier confusion.
Your script is really great and a strong contribution.
Perhaps in the future we should add a flag each server can be identified if fail2ban is turned on?
What do you think? Is that an important metric to add, do you think?
Same from receiving side. I also only just had a very quick read on your post.
Instead of one car crashing into a wall two cars crashing frontal into each other with the same speed do square damage instead of just double. So square amount of misunderstanding here
It maybe fail2ban is configured properly, up and running. That will definitely explain a rate below average. But f2b can be running without being configured to do blocking at all or not correctly adapted to the system. It may be a weak variable.
What regards the ssh port. From my experience it will make a huge difference if it's running on default port 22 or a custom port. Most attackers are just using the easiest methods because there's still enough to harvest.
Regarding my server list:
I did a quick check and removed the results which might not be plausible(flapm <= 0). There might be a pool of servers not shown because flapm rounded down to zero.
Normally, I do not run automatic banning systems, but after reviewing fail2ban again, I see the ban is configured out-of-the-box to only ban for a short period.
So, am testing fail2ban on all my Linux servers.
However, I agree with you stomp, that changing the sshd port from 22 to another value is one of the best deterrents agains these bots.
The same is also true for web software, for example Word Press. The best way to stop bot registrations, bot logins and spam posts is to change the URL of the registration, log in or posting scripts.
Also, having said that, I was hoping not to quickly get into remediation and risk management; but to get more people to post their FLAPM stats; using our simple method, so we could gather more stats.