On 2022-12-30, 26C.Z969 <26C.Z969@noaada.net> wrote:
> On 12/29/22 1:33 AM, Andreas Kohlbach wrote:
>> On Thu, 29 Dec 2022 00:02:46 -0500, 26C.Z969 wrote:
>>>
>>> On 12/28/22 4:37 PM, Computer Nerd Kev wrote:
>>>>
>>>> The most effective response to a distributed attack will just be
>>>> for it to block _all_ SSH connections, with effectiveness
>>>> decreasing from that point as it invents ways to try and ID real
>>>> humans.
>>>
>>> I've personal experience with such attacks lasting MONTHS -
>>> even AFTER I changed SSH to a new net-facing port. Once one
>>> bot finds an interesting port it passes the info along.
>>> Such is the modern world. So ... blocking all traffic
>>> is in NO way a viable defense.
>>
>> There is no real threat in my opinion, unless you use weak passwords. And
>> a little hardening might take away the paranoia: Allow only specific
>> users. Then no one gets in even if he guesses the right account name
>> (like "pi" as discussed earlier) and password. Unless you have an account
>> id "pi" and a weak password.
>
> You mean "123" isn't good ??? :-)
>
> In my current groove I *can* restrict users a fair bit.
> That's just ME though - others need to deal with lots
> of users who may be connecting through almost any IP
> address that day.
>
>> Or use host-keys. No one gets in, unless s/he has the right key
> The "tighter" things are the HARDER for the regular
> users things become too. Pretty quick they petition
> a know-nothing boss to cut the crap, or find sneaky
> bypasses.
>
> But I'm not sure if there's a good way to make it easy
> for the good guys and hell for the others. Everyone
> from the giant tech corps on down have been looking,
> but so far ......
>
>> The traffic will persist, so what. It's like you wish to sush people on
>> the streets from chatting, because you don't like the noise. Won't
>> happen. Just ignore it.
>
> Not wise to take that tact TOO far .......
>
> In any event, I asked a question somewhere upstream
> about whether SSH might be kinda *obsolete* at this
> point. SO much access is now via browser-based apps.
> They are as vulnerable in their ways as SSH, but they
> are the *preferred* access method now. MAYbe the solution
> to SSH is to just turn it OFF forever ?

Have you considered the solution-for-you of pretending it has
ceased to exist? Just uninstall both client and server software
from all machines you control, and as far as you're concerned it
has been turned off forever.

For many/most of the rest of us, browser-based stuff does not fly
for many or most of the use cases for which we use ssh.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 30/12/2022 02:06, 26C.Z969 wrote:
> But I'm not sure if there's a good way to make it easy
>   for the good guys and hell for the others. Everyone
>   from the giant tech corps on down have been looking,
>   but so far ......

There is.

Its simple, and its well known.
Its called a 'shared secret'
Passwords that are your birthday can be shared but they are not secret.
Passwords that are the numberplate of your first car, are pretty secure.
As are long but memorable phrases like
"My.horses.a$$.is.full.of.hovercraft!"
Stupid people confuse easily remembered with easily crackable.

I have had passwords from my pet cats name to the first thing I saw
looking out of the window in a London data centre. Red.Bus! is
memorable, but quite tough to brute force or dictionary attack

--
Labour - a bunch of rich people convincing poor people to vote for rich
people by telling poor people that "other" rich people are the reason
they are poor.

Peter Thompson

On 30/12/2022 04:16, Robert Riches wrote:
> For many/most of the rest of us, browser-based stuff does not fly
> for many or most of the use cases for which we use ssh.

I was trying to allow a family member to upload info to my server.
Somehow HTTPS stuff wasn't working (browser incompatibility?) but he
found an sshfs client and that worked a treat.

--
You can get much farther with a kind word and a gun than you can with a
kind word alone.

Al Capone

On 2022-12-30, The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 30/12/2022 02:06, 26C.Z969 wrote:
>
>> But I'm not sure if there's a good way to make it easy
>>   for the good guys and hell for the others. Everyone
>>   from the giant tech corps on down have been looking,
>>   but so far ......

All too many people punt on this one. Because they don't
have any bad guys handy to run tests, they measure security
by how much it inconveniences legitimate users instead.
For such people, security consists of giving yourself the
warm fuzzies, rather than actually accomplishing anything.

> There is.
>
> Its simple, and its well known.
> Its called a 'shared secret'
> Passwords that are your birthday can be shared but they are not secret.
> Passwords that are the numberplate of your first car, are pretty secure.
> As are long but memorable phrases like
> "My.horses.a$$.is.full.of.hovercraft!"
> Stupid people confuse easily remembered with easily crackable.
>
> I have had passwords from my pet cats name to the first thing I saw
> looking out of the window in a London data centre. Red.Bus! is
> memorable, but quite tough to brute force or dictionary attack

https://xkcd.com/936/

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 30/12/2022 19:09, Charlie Gibbs wrote:
> On 2022-12-30, The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 30/12/2022 02:06, 26C.Z969 wrote:
>>
>>> But I'm not sure if there's a good way to make it easy
>>>   for the good guys and hell for the others. Everyone
>>>   from the giant tech corps on down have been looking,
>>>   but so far ......
>
> All too many people punt on this one. Because they don't
> have any bad guys handy to run tests, they measure security
> by how much it inconveniences legitimate users instead.
> For such people, security consists of giving yourself the
> warm fuzzies, rather than actually accomplishing anything.
>
>> There is.
>>
>> Its simple, and its well known.
>> Its called a 'shared secret'
>> Passwords that are your birthday can be shared but they are not secret.
>> Passwords that are the numberplate of your first car, are pretty secure.
>> As are long but memorable phrases like
>> "My.horses.a$$.is.full.of.hovercraft!"
>> Stupid people confuse easily remembered with easily crackable.
>>
>> I have had passwords from my pet cats name to the first thing I saw
>> looking out of the window in a London data centre. Red.Bus! is
>> memorable, but quite tough to brute force or dictionary attack
>
> https://xkcd.com/936/
>
In a nutshell

--
If I had all the money I've spent on drink...
...I'd spend it on drink.

Sir Henry (at Rawlinson's End)

On 12/29/22 11:16 PM, Robert Riches wrote:
> On 2022-12-30, 26C.Z969 <26C.Z969@noaada.net> wrote:
>> On 12/29/22 1:33 AM, Andreas Kohlbach wrote:
>>> On Thu, 29 Dec 2022 00:02:46 -0500, 26C.Z969 wrote:
>>>>
>>>> On 12/28/22 4:37 PM, Computer Nerd Kev wrote:
>>>>>
>>>>> The most effective response to a distributed attack will just be
>>>>> for it to block _all_ SSH connections, with effectiveness
>>>>> decreasing from that point as it invents ways to try and ID real
>>>>> humans.
>>>>
>>>> I've personal experience with such attacks lasting MONTHS -
>>>> even AFTER I changed SSH to a new net-facing port. Once one
>>>> bot finds an interesting port it passes the info along.
>>>> Such is the modern world. So ... blocking all traffic
>>>> is in NO way a viable defense.
>>>
>>> There is no real threat in my opinion, unless you use weak passwords. And
>>> a little hardening might take away the paranoia: Allow only specific
>>> users. Then no one gets in even if he guesses the right account name
>>> (like "pi" as discussed earlier) and password. Unless you have an account
>>> id "pi" and a weak password.
>>
>> You mean "123" isn't good ??? :-)
>>
>> In my current groove I *can* restrict users a fair bit.
>> That's just ME though - others need to deal with lots
>> of users who may be connecting through almost any IP
>> address that day.
>>
>>> Or use host-keys. No one gets in, unless s/he has the right key
>> The "tighter" things are the HARDER for the regular
>> users things become too. Pretty quick they petition
>> a know-nothing boss to cut the crap, or find sneaky
>> bypasses.
>>
>> But I'm not sure if there's a good way to make it easy
>> for the good guys and hell for the others. Everyone
>> from the giant tech corps on down have been looking,
>> but so far ......
>>
>>> The traffic will persist, so what. It's like you wish to sush people on
>>> the streets from chatting, because you don't like the noise. Won't
>>> happen. Just ignore it.
>>
>> Not wise to take that tact TOO far .......
>>
>> In any event, I asked a question somewhere upstream
>> about whether SSH might be kinda *obsolete* at this
>> point. SO much access is now via browser-based apps.
>> They are as vulnerable in their ways as SSH, but they
>> are the *preferred* access method now. MAYbe the solution
>> to SSH is to just turn it OFF forever ?
>
> Have you considered the solution-for-you of pretending it has
> ceased to exist? Just uninstall both client and server software
> from all machines you control, and as far as you're concerned it
> has been turned off forever.

Already did that on several boxes ....

But one net-facing one remains ... mostly
for VNC-Over-SSH tunneling - obscure, changing,
port of course.

> For many/most of the rest of us, browser-based stuff does not fly
> for many or most of the use cases for which we use ssh.

Well, browser-based CAN do the deed. Some would
argue "better". Indeed they'll charge you big $$$
for "better" .......

On 12/30/22 9:33 AM, The Natural Philosopher wrote:
> On 30/12/2022 04:16, Robert Riches wrote:
>> For many/most of the rest of us, browser-based stuff does not fly
>> for many or most of the use cases for which we use ssh.
>
> I was trying to allow a family member to upload info to my server.
> Somehow HTTPS stuff wasn't working (browser incompatibility?) but he
> found an sshfs client and that worked a treat.

Depending, a free DropBox account can suffice without
requiring a user have actual access to your prime box.
If you don't like 3rd-party then there are plenty of
good free SFTP servers/clients out there - and you
can conveniently "systemctl disable <sftp-daemon>"
between needs.

On 12/30/22 3:38 PM, The Natural Philosopher wrote:
> On 30/12/2022 19:09, Charlie Gibbs wrote:
>> On 2022-12-30, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>> On 30/12/2022 02:06, 26C.Z969 wrote:
>>>
>>>> But I'm not sure if there's a good way to make it easy
>>>>     for the good guys and hell for the others. Everyone
>>>>     from the giant tech corps on down have been looking,
>>>>     but so far ......
>>
>> All too many people punt on this one.  Because they don't
>> have any bad guys handy to run tests, they measure security
>> by how much it inconveniences legitimate users instead.
>> For such people, security consists of giving yourself the
>> warm fuzzies, rather than actually accomplishing anything.
>>
>>> There is.
>>>
>>> Its simple, and its well known.
>>> Its called a 'shared secret'
>>> Passwords that are your birthday can be shared but they are not secret.
>>> Passwords that are the numberplate of your first car, are pretty secure.
>>> As are long but memorable phrases like
>>> "My.horses.a$$.is.full.of.hovercraft!"
>>> Stupid people confuse easily remembered with easily crackable.
>>>
>>> I have had passwords from my pet cats name to the first thing I saw
>>> looking out of the window in a London data centre. Red.Bus! is
>>> memorable, but quite tough to brute force or dictionary attack
>>
>> https://xkcd.com/936/
>>
> In a nutshell

Using pure "dictionary words" is a bit risky. If you
wanna go that way it should be a "nonsense phrase"
of some kind, preferably with weird capitalization
like "PooPyForKs" or something.

A couple of years ago I watched a dictionary attack
on a mail server in action for a few DAYS. You'd be
surprised what words/phrases they tried. Somewhere I
have a record of everything they attempted ... it's
like 700 pages of small print.

(thing is, they had an obsolete USER NAME and 'admin'
was only for local-network logins :-)

On 12/30/22 2:09 PM, Charlie Gibbs wrote:
> On 2022-12-30, The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 30/12/2022 02:06, 26C.Z969 wrote:
>>
>>> But I'm not sure if there's a good way to make it easy
>>>   for the good guys and hell for the others. Everyone
>>>   from the giant tech corps on down have been looking,
>>>   but so far ......
>
> All too many people punt on this one. Because they don't
> have any bad guys handy to run tests, they measure security
> by how much it inconveniences legitimate users instead.

There is some truth to that. It SEEMS secure, they can
sell it to their bosses and collect their paychecks.

But "security" is ALWAYS more illusion than fact :-)

And the only thing you can expect from the Bad Guys
is that they'll go at it from an unexpected angle.

Even the tech giants (and us govt letter agencies) have
been cracked more than once. "Security" goes beyond just
login-control.

THE greatest threat - and it amplifies exponentially
depending on how "important" the corp/agency is - seems
to be "Human Factors" stuff these days. Why waste time
with clever hacks when you can bamboozle a stupid
employee - or PLANT your own agent inside their org ?

The other day I got a SNAIL MAIL from some corp with
a weird GMail address that wanted to register one of
my "expiring" domains - for about TEN TIMES what I
actually pay for all that with the legit provider (and
the domain doesn't need re-registration anytime soon).
*I* know that, but the person the letter CAME too
had no clue ... fortunately I've trained 'em all to
be VERY skeptical. That's kinda the best you can do
these days, train 'em to *punt* on anything that
even maybe has a funny smell to it. When a bad
phishing mail or fake invoice arrives I always
reply (to a group) breaking down just how/why the
thing was fake.

Got some really GOOD phishing mails of late - looked
great/legit - even including links to logos and stuff
from the legit company - UNTIL you googled the PHONE
NUMBER ... which was in TURKEY. The scam was a fake
invoice number from a real company, which, of course,
won't work - so the next logical step is to call the
800-looking "help" number .... :-)

> For such people, security consists of giving yourself the
> warm fuzzies, rather than actually accomplishing anything.

Basically, most play to the pointy-haired know-nothing
boss and that's "good enough". Just use enough tech-
sounding jargon and phrases they probably heard in a
meeting or management mag and ..........

Well, MASSIVE *RUSSIAN GOVT* hack ! Nothing WE could
do about it boss ! Comprehensive BACKUPS of data and
boxes ? Well, that was supposed to be approved on
NEXT YEAR'S BUDGET boss !!!

Too much "game" ... not enough gain.

On 2022-12-31, 26C.Z969 <26C.Z969@noaada.net> wrote:

> Got some really GOOD phishing mails of late - looked
> great/legit - even including links to logos and stuff
> from the legit company - UNTIL you googled the PHONE
> NUMBER ... which was in TURKEY. The scam was a fake
> invoice number from a real company, which, of course,
> won't work - so the next logical step is to call the
> 800-looking "help" number .... :-)

For a while I was getting fake traffic tickets. They were
always missing bits of information like where the infraction
supposedly took place. My favourite included a photo of a
street I'd never seen before - and the time stamp in the
lower right corner said GMT+3. Given that my time zone
is GMT-8, it was pretty obviously bogus.

> Too much "game" ... not enough gain.

For many people, the game is everything.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 12/31/22 3:14 PM, Charlie Gibbs wrote:
> On 2022-12-31, 26C.Z969 <26C.Z969@noaada.net> wrote:
>
>> Got some really GOOD phishing mails of late - looked
>> great/legit - even including links to logos and stuff
>> from the legit company - UNTIL you googled the PHONE
>> NUMBER ... which was in TURKEY. The scam was a fake
>> invoice number from a real company, which, of course,
>> won't work - so the next logical step is to call the
>> 800-looking "help" number .... :-)
>
> For a while I was getting fake traffic tickets. They were
> always missing bits of information like where the infraction
> supposedly took place. My favourite included a photo of a
> street I'd never seen before - and the time stamp in the
> lower right corner said GMT+3. Given that my time zone
> is GMT-8, it was pretty obviously bogus.

Oh, they're getting better and better at it. Baiting
people with the bad invoice numbers is pretty clever,
so they'll call the bogus number - which DOES look a
lot like a US 1-800 prefix.

The Cops are NOT gonna be sending you traffic ticket
e-mails and such. If anything it'll be tangible snail
mail. I'd even check THAT. NEXT phisher will get the
timezone right on the pix and add a few fake details,
btw.

Anyway, "hacking" really IS becoming less of a cyber-crime
threat than "human factors" for most. I don't see many hits
on anti-virus software anymore - crime has Moved On.

>> Too much "game" ... not enough gain.
>
> For many people, the game is everything.

Yea ... and I see why. BUT, eventually, it
all falls down go boom.

Russia, China, even NK, could just STOP the
USA/EU within hours given our sloppy net
security methods and what you can GET at
once you get past the 'security'. Remember
what the USA did to an Iranian enrichment
facility some years back - wrecked it by
getting at the industrial-devices. Think
about that on a large scale, including
somewhere near YOU. Banking screwed,
scheduling for deliveries screwed, fuel
supplies screwed, big chemical/power/nuke
plants all screwed, communications screwed,
transport screwed.

1st-world is mostly 1st-world because
everything is so well ORGANIZED, mutually-
supporting. Damage the organization and you
collapse it all. Never have to drop a
single bomb ......

"War" is not like cyber-crime - we're talking
State assets and funding here and the will to
actually get at "infrastructure". They WILL
have top-notch hackers and agents planted in
the target industries. Oh, do you REALLY know
those Chinese chips embedded in EVERYTHING you
and govt and everybody uses ? How many trick
circuits, mystery cpu commands, subtle flaws
in the microcode ?

On 12/27/22 00:20, 26C.Z969 wrote:
> Decided to write my own replacement. It won't
>   be freeware ...

good luck

In article <tpl19c$dad$1@reader2.panix.com>,
Popping Mad <rainbow@colition.gov> wrote:
>On 12/27/22 00:20, 26C.Z969 wrote:
>> Decided to write my own replacement. It won't
>> be freeware ...
>
>good luck
>

Was it ever established just what OP's complaint against ssh was (is)?

--
Rich people pay Fox people to convince middle class people to blame poor people.

(John Fugelsang)

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <tpl19c$dad$1@reader2.panix.com>,
> Popping Mad <rainbow@colition.gov> wrote:
>>On 12/27/22 00:20, 26C.Z969 wrote:
>>> Decided to write my own replacement. It won't
>>> be freeware ...
>>
>>good luck
>
> Was it ever established just what OP's complaint against ssh was (is)?

Not really.

The closest it seemed the group got was that the complaint was that
/sbin/sshd itself did not incorporate an AI version of fail2ban that
would /somehow/ be able to block DDOS attacks against port 22.

It was not ever clear why adding an equivalent to fail2ban *into* sshd
was necessary (other than OP's view that such *was* necessary for
unstated reasons).

It was also not ever made clear how the added fail2ban functionality
was going to stop others, on remote networks, from attacking OP's sshd
running on port 22. If the added fail2ban simply inserted Linux (or
BSD) firewall rules into the localhost firewall to block misbehaving
IP's then it was not at all clear why "combining two into one" was
better than simply using fail2ban with the existing sshd, nor what was
added, beyond this AI.

At best, the only visible addition over fail2ban was this mystical, as
yet non-existant, Artificial Intelligence module that could,
presumably, make better ban decisions than fail2ban's current
algorithm. In which case OP's wish to throw away ssh made no sense at
all. The better angle for OP would have been to add an AI monitoring
module to fail2ban to give it this mystical abililty that OP felt an AI
could provide.

All in all, after everything, it looked like someone who drank some AI
kool-aid, and then went running around with a solution in search of a
problem, followed by crediting the 'found problem' to the wrong item.

On Fri, 13 Jan 2023 23:03:45 -0000 (UTC), Rich wrote:
>
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <tpl19c$dad$1@reader2.panix.com>,
>> Popping Mad <rainbow@colition.gov> wrote:
>>>On 12/27/22 00:20, 26C.Z969 wrote:
>>>> Decided to write my own replacement. It won't
>>>> be freeware ...
>>>
>>>good luck
>>
>> Was it ever established just what OP's complaint against ssh was (is)?
>
> Not really.
>
> The closest it seemed the group got was that the complaint was that
> /sbin/sshd itself did not incorporate an AI version of fail2ban that
> would /somehow/ be able to block DDOS attacks against port 22.

The OP apparently didn't understood the "one job one tool" idea in Linux.
--
Andreas

On 13/01/2023 21:21, Kenny McCormack wrote:
> In article <tpl19c$dad$1@reader2.panix.com>,
> Popping Mad <rainbow@colition.gov> wrote:
>> On 12/27/22 00:20, 26C.Z969 wrote:
>>> Decided to write my own replacement. It won't
>>> be freeware ...
>>
>> good luck
>>
>
> Was it ever established just what OP's complaint against ssh was (is)?
>
I think the problem was that it wasn't 'modern'

Like round wheels, it's simply intolerably old fashioned.

--
“Progress is precisely that which rules and regulations did not foresee,”

– Ludwig von Mises

On 13/01/2023 23:03, Rich wrote:
> All in all, after everything, it looked like someone who drank some AI
> kool-aid, and then went running around with a solution in search of a
> problem, followed by crediting the 'found problem' to the wrong item.

Sound like he belonga in da gummint...

--
“Progress is precisely that which rules and regulations did not foresee,”

– Ludwig von Mises

On 1/13/23 10:38 PM, The Natural Philosopher wrote:
> On 13/01/2023 21:21, Kenny McCormack wrote:
>> In article <tpl19c$dad$1@reader2.panix.com>,
>> Popping Mad  <rainbow@colition.gov> wrote:
>>> On 12/27/22 00:20, 26C.Z969 wrote:
>>>> Decided to write my own replacement. It won't
>>>>   be freeware ...
>>>
>>> good luck
>>>
>>
>> Was it ever established just what OP's complaint against ssh was (is)?
>>
> I think the problem was that it wasn't 'modern'
>
> Like round wheels, it's simply intolerably old fashioned.

Absolutely ! Square wheels are the NEW COOL THING !!!
When you bounce you eliminate ground friction and
thus cut CO2 emissions :-)

The QUESTION was whether SSH was modern enough to cope
with modern kinds of THREATS.

I still think it ISN'T. SSH is from a kinder-and-gentler
era, before mass distributed attacks. Yea, yea ... you
can add lots and lots of add-ons and hooks - but that
just makes it all the more messy and hard to administer
and monitor.

However I also raised the question of whether SSH is
even RELEVANT anymore. SO much remote access is now
done using browser-based apps - and THEY have kind
of a bad track record so far.

Also see my post on advances in quantum-computing ...
the 's' in "https" may not MEAN anything in just
two or three years .........

Rich <rich@example.invalid> writes:
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> Was it ever established just what OP's complaint against ssh was (is)?
>
> Not really.
>
> The closest it seemed the group got was that the complaint was that
> /sbin/sshd itself did not incorporate an AI version of fail2ban that
> would /somehow/ be able to block DDOS attacks against port 22.
>
> It was not ever clear why adding an equivalent to fail2ban *into* sshd
> was necessary (other than OP's view that such *was* necessary for
> unstated reasons).

AFAICT they are not quite asking for ‘an AI fail2ban in OpenSSH’, so
much as a complete new protocol which, for some secret reason, will be
more amenable to AI-based threat intelligence (and maybe some other
contemporary buzzwords). I did ask what concrete things they didn’t like
about the current protocol but didn’t get an answer.

--
https://www.greenend.org.uk/rjk/

On 13/01/2023 23:03, Rich wrote:
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <tpl19c$dad$1@reader2.panix.com>,
>> Popping Mad <rainbow@colition.gov> wrote:
>>> On 12/27/22 00:20, 26C.Z969 wrote:
>>>> Decided to write my own replacement. It won't
>>>> be freeware ...
>>>
>>> good luck
>>
>> Was it ever established just what OP's complaint against ssh was (is)?
>
> Not really.
>
> The closest it seemed the group got was that the complaint was that
> /sbin/sshd itself did not incorporate an AI version of fail2ban that
> would /somehow/ be able to block DDOS attacks against port 22.
>
I thought the way to cope with DDOS was upstream filtering. i.e.
decoupling at the physical hardware level.

fail2ban seems more suited to preventing attempts at password cracking.
A simple connection attempt rate limiter would be enough to prevent high
cpu from SSH negotiations. Even then, when using a good authentication
technique, public key rather than password, fail2ban seems unnecessary,
a simple connection attempt rate limiter should be enough, without the
downside of locking yourself out.

It's like people have been presented with a problem and are suggesting a
solution that they don't really believe in, to placate the person
raising the problem?

Pancho <Pancho.Jones@proton.me> writes:
> fail2ban seems more suited to preventing attempts at password
> cracking. A simple connection attempt rate limiter would be enough to
> prevent high cpu from SSH negotiations. Even then, when using a good
> authentication technique, public key rather than password, fail2ban
> seems unnecessary, a simple connection attempt rate limiter should be
> enough, without the downside of locking yourself out.

A rate limiter already exists in OpenSSH, and is on by default. Look for
MaxStartups in ‘man sshd_config’. However, the rate it limits is _all_
connections: even if you disable password authentication, each
connection which attempts to use password authentication still
counts. So with the current implementation you still end up deploying
something like fail2ban to block persistent probers.

--
https://www.greenend.org.uk/rjk/

On 14/01/2023 11:39, Richard Kettlewell wrote:
> Pancho <Pancho.Jones@proton.me> writes:
>> fail2ban seems more suited to preventing attempts at password
>> cracking. A simple connection attempt rate limiter would be enough to
>> prevent high cpu from SSH negotiations. Even then, when using a good
>> authentication technique, public key rather than password, fail2ban
>> seems unnecessary, a simple connection attempt rate limiter should be
>> enough, without the downside of locking yourself out.
>
> A rate limiter already exists in OpenSSH, and is on by default. Look for
> MaxStartups in ‘man sshd_config’. However, the rate it limits is _all_
> connections: even if you disable password authentication, each
> connection which attempts to use password authentication still
> counts. So with the current implementation you still end up deploying
> something like fail2ban to block persistent probers.
>

Ok, maybe I'm missing something. There are a couple of bad things that I
can see happening. Firstly, persistent bad connection attempts may
consume CPU and other system resources. Secondly, multiple bad
connection attempts may crack a password.

With the OpenSSH rate limiter, I presume the maximum CPU/resource cost
is low, not worth worrying about. Particularly in typical servers (my
servers) which have a low expected rate of ssh connections, so the rate
limit can be strict. Without passwords, there isn't a crack risk.

So what problem does fail2ban solve? Particularly as DDOS attacks will
get around it.

Pancho <Pancho.Jones@proton.me> writes:
> On 14/01/2023 11:39, Richard Kettlewell wrote:
>> Pancho <Pancho.Jones@proton.me> writes:
>>> fail2ban seems more suited to preventing attempts at password
>>> cracking. A simple connection attempt rate limiter would be enough to
>>> prevent high cpu from SSH negotiations. Even then, when using a good
>>> authentication technique, public key rather than password, fail2ban
>>> seems unnecessary, a simple connection attempt rate limiter should be
>>> enough, without the downside of locking yourself out.
>> A rate limiter already exists in OpenSSH, and is on by default. Look
>> for
>> MaxStartups in ‘man sshd_config’. However, the rate it limits is _all_
>> connections: even if you disable password authentication, each
>> connection which attempts to use password authentication still
>> counts. So with the current implementation you still end up deploying
>> something like fail2ban to block persistent probers.
>
> Ok, maybe I'm missing something. There are a couple of bad things that
> I can see happening. Firstly, persistent bad connection attempts may
> consume CPU and other system resources. Secondly, multiple bad
> connection attempts may crack a password.
>
> With the OpenSSH rate limiter, I presume the maximum CPU/resource cost
> is low, not worth worrying about. Particularly in typical servers (my
> servers) which have a low expected rate of ssh connections, so the
> rate limit can be strict. Without passwords, there isn't a crack risk.

If the probes arrive at rate that triggers the rate limiter, then
legitimate connections will be rejected by the rate limiter.

> So what problem does fail2ban solve? Particularly as DDOS attacks will
> get around it.

It rejects persistent probers before they can trigger the rate limiter.

The probes aren’t a denial of service attack, they’re attempted
breakins.

--
https://www.greenend.org.uk/rjk/

On 14/01/2023 14:04, Pancho wrote:
> On 14/01/2023 11:39, Richard Kettlewell wrote:
>> Pancho <Pancho.Jones@proton.me> writes:
>>> fail2ban seems more suited to preventing attempts at password
>>> cracking. A simple connection attempt rate limiter would be enough to
>>> prevent high cpu from SSH negotiations. Even then, when using a good
>>> authentication technique, public key rather than password, fail2ban
>>> seems unnecessary, a simple connection attempt rate limiter should be
>>> enough, without the downside of locking yourself out.
>>
>> A rate limiter already exists in OpenSSH, and is on by default. Look for
>> MaxStartups in ‘man sshd_config’. However, the rate it limits is _all_
>> connections: even if you disable password authentication, each
>> connection which attempts to use password authentication still
>> counts. So with the current implementation you still end up deploying
>> something like fail2ban to block persistent probers.
>>
>
> Ok, maybe I'm missing something. There are a couple of bad things that I
> can see happening. Firstly, persistent bad connection attempts may
> consume CPU and other system resources. Secondly, multiple bad
> connection attempts may crack a password.
>
> With the OpenSSH rate limiter, I presume the maximum CPU/resource cost
> is low, not worth worrying about. Particularly in typical servers (my
> servers) which have a low expected rate of ssh connections, so the rate
> limit can be strict. Without passwords, there isn't a crack risk.
>
> So what problem does fail2ban solve? Particularly as DDOS attacks will
> get around it.

Well, exactly.

What fail2ban does is move the firewall out of SSH into the linux
firewall itself.

Whether that is more CPU effiecient in terms of blocking arseholes is
hard to say..probably, if you silently drop packets it is.
But is CPU the real bottleneck? In most situations it is not. It is the
pipe to the internet and DOS or DDOS will saturate that long before
packets even reach the host machine.

--
When plunder becomes a way of life for a group of men in a society, over
the course of time they create for themselves a legal system that
authorizes it and a moral code that glorifies it.

Frédéric Bastiat

"26C.Z968" <26C.Z968@noaada.net> writes:

> On 1/13/23 10:38 PM, The Natural Philosopher wrote:
>> On 13/01/2023 21:21, Kenny McCormack wrote:
>>> In article <tpl19c$dad$1@reader2.panix.com>,
>>> Popping Mad  <rainbow@colition.gov> wrote:
>>>> On 12/27/22 00:20, 26C.Z969 wrote:
>>>>> Decided to write my own replacement. It won't
>>>>>   be freeware ...
>>>>
>>>> good luck
>>>>
>>>
>>> Was it ever established just what OP's complaint against ssh was (is)?
>>>
>> I think the problem was that it wasn't 'modern'
>> Like round wheels, it's simply intolerably old fashioned.
>
>
> Absolutely ! Square wheels are the NEW COOL THING !!!
> When you bounce you eliminate ground friction and
> thus cut CO2 emissions :-)
>
> The QUESTION was whether SSH was modern enough to cope
> with modern kinds of THREATS.
>
> I still think it ISN'T. SSH is from a kinder-and-gentler
> era, before mass distributed attacks. Yea, yea ... you
> can add lots and lots of add-ons and hooks - but that
> just makes it all the more messy and hard to administer
> and monitor.

You really should stop criticizing things you apparently don't
understand. I makes you seem like even more of an idiot.

Or, you can keep throwing out meaningless buzz words like
"modern threats", and continue proving the above.

--
Dan Espen