[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to push back against repeated login attempts?

On 2021-03-02 09:33, oregano@disroot.org wrote:

Considering running a freedom box or similar, I have a RPi running Buster outside my home router's DMZ. It was discovered within a short time (minutes or hours) of first being setup. It now has fail2ban running with defaults. Over about the last month, fail2ban logs show about 35,000 "unbans" from about 3700 unique IPs. This equates to many more failed login attempts. From auth.log there are many attempts for root login, and a wide variety of other username login or connection attempts, at a slow, steady pace with an attempt at least every minute or two.

I've seen https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html and https://www.fail2ban.org/wiki/index.php/MANUAL_0_8 but... can someone point me towards a TL;DR getting started getting even guide? Fail2ban seems oriented towards individual actions like sending emails to "abuse" contacts, as if they don't already know... I'm looking for things like optimum settings to waste these probers' cycles, how to request NSA to call in a drone strike, or how to join in with "community action" to discourage these probes (partially in jest).

I have been running fail2ban on ssh for about 5 years now (before that I ran ssh on a high numbered port).

1. You are wasting your time reporting anything to abuse@ISP email contacts. I used to do that and never got anywhere. The only time I got a response was when the ssh hack attempt came from another customer of my ISP, and I phone up tech support rather than using the abuse email address.

2. In addition to fail2ban you can download a blocklist, and use that as well. I found this public blocklist with a script on how to automatically block the IPs on the list.


Also there are a small number of mostly east Asian countries that appear to be responsible for a large number of probes. If you don't have any users in places like China, and don't plan to visit there any time soon, you could consider blocking the entire netblock. 

3. As others have said if you don't need to run ssh on port 22, then don't. I used to run it on a high port and hardly ever saw any unauthorised traffic. You could also consider requiring remote users to go via a VPN in order to connect.


David Pottage

Reply to: