On 2021-03-02 09:33, oreg...@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.
https://gist.github.com/klepsydra/ecf975984b32b1c8291a
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
