Re: How to push back against repeated login attempts?
On Wed, 03 Mar 2021 01:09:35 +0000
oregano@disroot.org wrote:
>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?
Very wrong. Do not do this. Most of these IPs are some poor schmuck
whose box has been compromised, and they are utterly clueless it's
being used in this way. Punishing them may /feel/ good, but it's not
really helping.
>
>Wasting more of their time and energy if they can't be taken down also
>has appeal.
exactly. goo up the works.
>
>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?
>
Unless you need to provide access to the planet, seriously consider
the ban all, allow specific model. It is by far the simplest, and most
effective solution.
Reply to: