Re: How to push back against repeated login attempts?
March 2, 2021 6:59 PM, "Christopher Barry" <cbarry@symbiaudix.com> wrote:
> On Tue, 02 Mar 2021 09:33:38 +0000
> 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).
>
> 1. disable password auth and allow high-bit-count keys /only/.
> 2. put daemon on a non-standard high port.
> 3. know who /needs/ to connect, allow /only/ their IP addresses, then
> either drop, or keep the connection hanging for every other address.
>
> Keeping /their/ connection hanging reduces the speed in which they can
> scan, and this will eventually get you off of their lists.
Thanks for all the experiences and suggestions!
Paul Wise:
> Switch the SSH daemon to another port than 22, then switch again when the next botnet finds that, repeat.
In about a month, they've tried about half the ports from 1024 to 65534 anyway, so this sounds like a tedious whack-a-port game.
> CrowdSec
Sounds good! Not quite what I was hoping for, but it's a start.
> Tor onion service
Fun!
Luke Kenneth Casson Leighton:
> instant 2 week ban.
I see the simplicity and benefit of putting up walls, but pushing back somehow has appeal.
Alan Corey:
> dictionary or random attacks will be drastically hampered if you limit how often they can fail.
Yes, default fail2ban settings do that. It would be interesting to see the list of failed passwords, to know how close they are getting. Remind me to make mine even longer and weirder. :D
David Pottage:
> download a blocklist,
> VPN
Noah Meyerhans:
> +1 to using blocklists.
Christopher Barry:
> Keeping /their/ connection hanging reduces the speed in which they can scan, and this will eventually get you off of their lists.
This sounds perfect, except just slow enough to stay on the lists. Now how to set it up...
Something like CrowdSec and firehol using all their participants to DDOS-back instead of just blocking would be wrong?
Wasting more of their time and energy if they can't be taken down also has appeal.
So honeypot or tarpit seems like something to try. Endlessh sounds good, but labrea and iisemulator have debian packages. Any suggestions or warnings to consider?
Reply to: