How to push back against repeated login attempts?

[o***@disroot.org]

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).

[Paul Wise]

How to push back against repeated login attempts?

This isn't specific to ARM devices so it is a bit off-topic here, but...

The first thing to do is to ensure password authentication to SSH is
disabled and replaced with key or certificate authentication.

To avoid (some of) the entries in the system logs there are a few
different options:

Just disable or uninstall the SSH daemon.

Ban access to the SSH daemon except from authorised IP addresses.

Switch the SSH daemon to another port than 22, then switch again when
the next botnet finds that, repeat.

Use the CrowdSec alternative to fail2ban, which shares the behavior of
malicious IPs with a community and in return receives a list of
malicious IPs other folks have shared.

https://crowdsec.net/
https://news.ycombinator.com/item?id=24826792

Move the SSH daemon to a Tor onion service so that only those who know
the address can access it and you can still access it if
fail2ban/crowdsec block your own IP address.

Some combination of the above.

[Luke Kenneth Casson Leighton]

Post by o***@disroot.org
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.

ahh yes. welcome to the discovery that there are people running
extremely sophisticated long-running break-in attempts, world-wide.

Post by o***@disroot.org
It now has fail2ban running with defaults. Over about the last month, fail2ban logs show about 35,000 "unbans" from about 3700 unique IPs.

if you want to do something "gradual", use fail2ban recidive.

i decided 3 years ago that enough was enough, and simply set all and
any failed password attempts at an instant 2 week ban. by running
OpenVPN i can at least get in if i happen to make a mistake.

l.

[Alan Corey]

Of course, dictionary or random attacks will be drastically hampered
if you limit how often they can fail. 3 failures or so causes a
lockout for some hours is the usual. Failed attempts can constitute a
denial of service attack under some circumstances though due to
network chatter.

Post by Luke Kenneth Casson Leighton

Post by o***@disroot.org
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.

ahh yes. welcome to the discovery that there are people running
extremely sophisticated long-running break-in attempts, world-wide.

Post by o***@disroot.org
It now has fail2ban running with defaults. Over about the last month,
fail2ban logs show about 35,000 "unbans" from about 3700 unique IPs.

if you want to do something "gradual", use fail2ban recidive.
i decided 3 years ago that enough was enough, and simply set all and
any failed password attempts at an instant 2 week ban. by running
OpenVPN i can at least get in if i happen to make a mistake.
l.

[David Pottage]

Post by o***@disroot.org
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 ***@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.

[Noah Meyerhans]

Post by David Pottage
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.
[2]https://gist.github.com/klepsydra/ecf975984b32b1c8291a

+1 to using blocklists. I have been using firehol blocklists in a few
places for some time and been quite happy. https://github.com/firehol
They aggregate IP lists from a number of different sources and make them
available in a standard format for easy consumption. You can pick and
choose exactly which blocklists to deploy based on whatever criteria you
come up with.

You can choose to use firehol itself as your firewall framework, or not.
I built a custom system that manages my firewall, so I can't speak to
how well it works. If you do deploy a blocklist, make sure you are
keeping its content up-to-date so you don't end up miscategorizing
incoming traffic. Some of the blocklists are pretty stable and don't
change much, but others change hourly.

noah

[David Pottage]

Post by Noah Meyerhans

Post by David Pottage
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.
[2]https://gist.github.com/klepsydra/ecf975984b32b1c8291a

+1 to using blocklists. I have been using firehol blocklists in a few
places for some time and been quite happy. https://github.com/firehol
They aggregate IP lists from a number of different sources and make them
available in a standard format for easy consumption. You can pick and
choose exactly which blocklists to deploy based on whatever criteria you
come up with.
You can choose to use firehol itself as your firewall framework, or not.
I built a custom system that manages my firewall, so I can't speak to
how well it works. If you do deploy a blocklist, make sure you are
keeping its content up-to-date so you don't end up miscategorizing
incoming traffic. Some of the blocklists are pretty stable and don't
change much, but others change hourly.

Thanks for the tip on FireHOL, and all their block lists. I was using
just the blocklist.de list and updating it nightly. It looks like I
should be able to get better coverage by using more block lists.

You say that you chose not to use FireHOL itself, but instead chose to
roll your own. Could I ask why? are there problems or downsides to
FireHOL?

Thanks.

[Noah Meyerhans]

Thanks for the tip on FireHOL, and all their block lists. I was using just
the blocklist.de list and updating it nightly. It looks like I should be
able to get better coverage by using more block lists.
You say that you chose not to use FireHOL itself, but instead chose to roll
your own. Could I ask why? are there problems or downsides to FireHOL?

I don't have anything bad to say about their tooling. My quick glance
at it, a couple of years ago, gave me the impression that it wanted to
own more of the firewall configuration than I wanted to hand it. In
particular, my goal was to build something usable both on Debian and on
OpenWRT, the latter of which already has a fairly involved iptables
configuration. So I built my own automation, and I'm entirely open to
the possibility that this was a mistake. ;)

You should probably start with the firehol tooling and stick with it
until you have reason to switch.

noah

[Christopher Barry]

On Tue, 02 Mar 2021 09:33:38 +0000

Post by o***@disroot.org
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.

[o***@disroot.org]

Post by Christopher Barry
On Tue, 02 Mar 2021 09:33:38 +0000

Post by o***@disroot.org
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!

Post by Christopher Barry
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.

Post by Christopher Barry
CrowdSec

Sounds good! Not quite what I was hoping for, but it's a start.

Post by Christopher Barry
Tor onion service

Fun!

Post by Christopher Barry
instant 2 week ban.

I see the simplicity and benefit of putting up walls, but pushing back somehow has appeal.

Post by Christopher Barry
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

Post by Christopher Barry
download a blocklist,
VPN
+1 to using blocklists.
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?

[Christopher Barry]

On Wed, 03 Mar 2021 01:09:35 +0000

Post by o***@disroot.org

Post by Christopher Barry
On Tue, 02 Mar 2021 09:33:38 +0000

Post by o***@disroot.org
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!

Post by Christopher Barry
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.

Post by Christopher Barry
CrowdSec

Sounds good! Not quite what I was hoping for, but it's a start.

Post by Christopher Barry
Tor onion service

Fun!

Post by Christopher Barry
instant 2 week ban.

I see the simplicity and benefit of putting up walls, but pushing back somehow has appeal.

Post by Christopher Barry
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

Post by Christopher Barry
download a blocklist,
VPN
+1 to using blocklists.
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.

Post by o***@disroot.org
Wasting more of their time and energy if they can't be taken down also has appeal.

exactly. goo up the works.

Post by o***@disroot.org
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.

[Luke Kenneth Casson Leighton]

Post by o***@disroot.org
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?

if you run exim4 and live spamassassin mta-time the teergrube config is a
lot of fun (teergrube: german for tarpit).

unfortunately, running mta-time spamassassin takes a MENTAL amount of
server-side resources esp. if you enable clamav, pyzor and razor like i
used to.

after a couple years i went "this is nuts" and left greylistd running but
did forwarding-only.

btw the other one to watch out for is the Iranian attack against OpenVPN.
i had repeated attempts to break in on OpenVPN come up and had to add that
to recidive as well, with some custom pattern matching.

a week later the slashdot announcement came up, "Iran sponsored hackers
break in to somethingorother by turning OpenVPN servers into botnets".

keeping an eye on your fail2ban logs you get a fairly good advance
indication of massive govt sponsored hacking attempts.

l.