Is It Time To Replace SSH ???

[26C.Z969]

SSH is a good oldie for sure. However, it seems to
be increasingly unfit for the modern realities. There
are not many straight-up ways to detect/intercept
aggressive attackers. It was writ for a "kinder,
gentler" IP universe where distributed attacks did
not exist. Coping with such threats really, badly,
needs to be very straight-up and incorporate at least
a little "AI" sensibility that can maybe "just tell"
an aggressor from an ordinary client.

And no, I don't mean "add a few features to SSH",
I mean REPLACE it entirely with a clean new
solution. Too much feature-creep on old apps
is never a good idea.

[Richard Kettlewell]

"26C.Z969" <26C....@noaada.net> writes:
> SSH is a good oldie for sure. However, it seems to be increasingly
> unfit for the modern realities. There are not many straight-up ways to
> detect/intercept aggressive attackers.

What do you think it’s failing to do? Disable password authentication
and nobody’s getting in without an authorized private key.

> It was writ for a "kinder, gentler" IP universe where distributed
> attacks did not exist. Coping with such threats really, badly, needs
> to be very straight-up and incorporate at least a little "AI"
> sensibility that can maybe "just tell" an aggressor from an ordinary
> client.

Not much intelligence needed, anything that gets more than a handful of
password authentication error is an attacker and gets added to my
‘block’ ipset.

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

[The Natural Philosopher]

Just hope it wasn't from some public wifi dynamic address that you might
want to use in future :-)


--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

[Lew Pitcher]

On Thu, 15 Dec 2022 01:52:41 -0500, 26C.Z969 wrote:

> SSH is a good oldie for sure. However, it seems to be increasingly unfit
> for the modern realities.

[snip]

> I mean REPLACE it entirely with a clean new solution. Too much
> feature-creep on old apps is never a good idea.

While I don't agree with you (I think that your observed problems
are likely caused more by operator error than aged software), I
have no problems with YOU attempting to replace ssh with something
better. Have at it, my friend.

Once YOU write a stable and featurefull replacement for ssh, please
let us know.

Luck be with you




--
Lew Pitcher
"In Skills, We Trust"

[Marco Moock]

Am 15.12.2022 um 01:52:41 Uhr schrieb 26C.Z969:

> SSH is a good oldie for sure. However, it seems to
> be increasingly unfit for the modern realities. There
> are not many straight-up ways to detect/intercept
> aggressive attackers. It was writ for a "kinder,
> gentler" IP universe where distributed attacks did
> not exist. Coping with such threats really, badly,
> needs to be very straight-up and incorporate at least
> a little "AI" sensibility that can maybe "just tell"
> an aggressor from an ordinary client.

I don't see any alternative. What would you change in the "new"
protocol?

Attacks on SSH on IPv4 networks exist (mostly brute-force), but just
let it run on an IPv6 address, almost nobody will find it and try to
log in.

[26C.Z969]

On 12/15/22 3:39 AM, Richard Kettlewell wrote:
> "26C.Z969" <26C....@noaada.net> writes:
>> SSH is a good oldie for sure. However, it seems to be increasingly
>> unfit for the modern realities. There are not many straight-up ways to
>> detect/intercept aggressive attackers.
>
> What do you think it’s failing to do? Disable password authentication
> and nobody’s getting in without an authorized private key.

Good for SOME users, preferably FEW, but what
about when you need to accommodate mass logins,
often from idiots ? If you make it too complex
they'll shop elsewhere.

>> It was writ for a "kinder, gentler" IP universe where distributed
>> attacks did not exist. Coping with such threats really, badly, needs
>> to be very straight-up and incorporate at least a little "AI"
>> sensibility that can maybe "just tell" an aggressor from an ordinary
>> client.
>
> Not much intelligence needed, anything that gets more than a handful of
> password authentication error is an attacker and gets added to my
> ‘block’ ipset.

You make it sound SO easy :-)

Which doesn't cover serious breeches, even at
large tech-centric corps for some reason ....

[26C.Z969]

In the end I may HAVE to ... but not my idea
of fun. Replacing SSH really needs to be a
"community effort" drawing from a lot of
expertise and experience with broad agreement
involved.

Or is all this already behind the curve ? SO much
access is now via browser-based apps.

SolarWinds will sell you some great stuff ....

[26C.Z969]

On 12/15/22 6:36 PM, Andreas Kohlbach wrote:

> On Thu, 15 Dec 2022 18:03:48 +0100, Marco Moock wrote:
>>
>> Am 15.12.2022 um 01:52:41 Uhr schrieb 26C.Z969:
>>
>>> SSH is a good oldie for sure. However, it seems to
>>> be increasingly unfit for the modern realities. There
>>> are not many straight-up ways to detect/intercept
>>> aggressive attackers. It was writ for a "kinder,
>>> gentler" IP universe where distributed attacks did
>>> not exist. Coping with such threats really, badly,
>>> needs to be very straight-up and incorporate at least
>>> a little "AI" sensibility that can maybe "just tell"
>>> an aggressor from an ordinary client.
>>
>> I don't see any alternative. What would you change in the "new"
>> protocol?
>

> More colorful interface may be. ;-)

Hey ... ! :-)

But, really, more "smarts" need to be built it.
HUMANS can spot an aggressor quite easily, but
try explaining that to software .......

>> Attacks on SSH on IPv4 networks exist (mostly brute-force), but just
>> let it run on an IPv6 address, almost nobody will find it and try to
>> log in.
>

> Also depends on how long an IP is advertising SSH (or other services). I
> have mine since two years now, and scammers getting busier to get into my
> SSH. Not that I care or block any of the IPs involved, as they change
> frequently anyway.

Strictly IP-centric defenses won't cut it anymore.
Attackers tend to use distributed attacks - hundreds,
thousands, of addresses. IP-centric defenses can
slow-down at least some attackers, which can be good,
but hardly all.

IPV6 does have some potential ... but a lot of big
providers, even Comcast, only offer IPV4 to most
customers.

Sometimes the "best" defense is obfuscation ...
run SSH on an obscure port. If you look at yer
firewall logs you'll see shitloads of probes
to the standard port. Attackers are mostly bots
these days and go for the low-hanging fruit.

[Carlos E. R.]

On 16/12/2022 06.11, 26C.Z969 wrote:
> On 12/15/22 3:39 AM, Richard Kettlewell wrote:
>> "26C.Z969" <26C....@noaada.net> writes:
>>> SSH is a good oldie for sure. However, it seems to be increasingly
>>> unfit for the modern realities. There are not many straight-up ways to
>>> detect/intercept aggressive attackers.
>>
>> What do you think it’s failing to do? Disable password authentication
>> and nobody’s getting in without an authorized private key.
>
>   Good for SOME users, preferably FEW, but what
>   about when you need to accommodate mass logins,
>   often from idiots ? If you make it too complex
>   they'll shop elsewhere.

If a mass of idiots go elsewhere, good riddance.

Now, if they want to go shopping, with money, that money of them can
create whatever software they want...

>>> It was writ for a "kinder, gentler" IP universe where distributed
>>> attacks did not exist. Coping with such threats really, badly, needs
>>> to be very straight-up and incorporate at least a little "AI"
>>> sensibility that can maybe "just tell" an aggressor from an ordinary
>>> client.
>>
>> Not much intelligence needed, anything that gets more than a handful of
>> password authentication error is an attacker and gets added to my
>> ‘block’ ipset.
>
>   You make it sound SO easy  :-)
>
>   Which doesn't cover serious breeches, even at
>   large tech-centric corps for some reason ....

Links?

--
Cheers,
Carlos E.R.

[The Natural Philosopher]

On 15/12/2022 23:33, Andreas Kohlbach wrote:

> Those are private IPs (like your personal WIFI net). Unlikely your SSH is
> being tried to accessed from there.

Er no. Grandmother, eggs, suck. How can you access anything other than
via a valid public IP address proxy? Either a direct proxy or NAT.

Block that proxy's public IP address, you block yourself from using it
ever again.

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

[The Natural Philosopher]

On 15/12/2022 23:36, Andreas Kohlbach wrote:
> On Thu, 15 Dec 2022 18:03:48 +0100, Marco Moock wrote:
>>

>> Am 15.12.2022 um 01:52:41 Uhr schrieb 26C.Z969:
>>
>>> SSH is a good oldie for sure. However, it seems to
>>> be increasingly unfit for the modern realities. There
>>> are not many straight-up ways to detect/intercept
>>> aggressive attackers. It was writ for a "kinder,
>>> gentler" IP universe where distributed attacks did
>>> not exist. Coping with such threats really, badly,
>>> needs to be very straight-up and incorporate at least
>>> a little "AI" sensibility that can maybe "just tell"
>>> an aggressor from an ordinary client.
>>
>> I don't see any alternative. What would you change in the "new"
>> protocol?
>

> More colorful interface may be. ;-)
>

>> Attacks on SSH on IPv4 networks exist (mostly brute-force), but just
>> let it run on an IPv6 address, almost nobody will find it and try to
>> log in.
>

> Also depends on how long an IP is advertising SSH (or other services). I
> have mine since two years now, and scammers getting busier to get into my
> SSH. Not that I care or block any of the IPs involved, as they change
> frequently anyway.

I've had open SSH for years on backbone hosted kit. everybody tries to
login as root.

I let them. Root is not allowed to log in.

[The Natural Philosopher]

On 16/12/2022 05:28, 26C.Z969 wrote:
> Sometimes the "best" defense is obfuscation ...
>   run SSH on an obscure port. If you look at yer
>   firewall logs you'll see shitloads of probes
>   to the standard port. Attackers are mostly bots
>   these days and go for the low-hanging fruit.

Yup. Very few people bother to scan all 64k ports
--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

[The Natural Philosopher]

On 16/12/2022 05:11, 26C.Z969 wrote:
> Which doesn't cover serious breeches

You need gaiters for that...

[The Natural Philosopher]

Just build a wrapper - a sort of modern inetd - that requires
simultaneous access on three ports to open one of them to any service.

Proper packaged port knocker. Might already be one.

SSH is a perfectly adequate protocol that only purists find inadequate.


--
It is the folly of too many to mistake the echo of a London coffee-house
for the voice of the kingdom.

Jonathan Swift

[Carlos E. R.]

One idea would be to automatically block the IPs that try to login as
root or other typical names used by bots.

That's something a human operator would do.

--
Cheers,
Carlos E.R.

[The Natural Philosopher]

Why bother? they would then go on to bother someone else, possibly with
less bandwidth than I.

If they want to spend an hour trying every single password in their
dictionary, its no skin off my nose.

--
"Nature does not give up the winter because people dislike the cold."

― Confucius

[Richard Kettlewell]

Pretty unlikely. But my VPN will get me past it in the event that
happens.

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

[Richard Kettlewell]

"26C.Z969" <26C....@noaada.net> writes:
> On 12/15/22 3:39 AM, Richard Kettlewell wrote:
>> "26C.Z969" <26C....@noaada.net> writes:
>>> SSH is a good oldie for sure. However, it seems to be increasingly
>>> unfit for the modern realities. There are not many straight-up ways to
>>> detect/intercept aggressive attackers.
>> What do you think it’s failing to do? Disable password authentication
>> and nobody’s getting in without an authorized private key.
>
> Good for SOME users, preferably FEW, but what about when you need to
> accommodate mass logins, often from idiots ? If you make it too
> complex they'll shop elsewhere.

Sounds like a self-solving problem.

>>> It was writ for a "kinder, gentler" IP universe where distributed
>>> attacks did not exist. Coping with such threats really, badly, needs
>>> to be very straight-up and incorporate at least a little "AI"
>>> sensibility that can maybe "just tell" an aggressor from an ordinary
>>> client.
>> Not much intelligence needed, anything that gets more than a handful
>> of password authentication error is an attacker and gets added to my
>> ‘block’ ipset.
>
> You make it sound SO easy :-) Which doesn't cover serious breeches,
> even at large tech-centric corps for some reason ....

Blocking persistent probes is indeed easy. I don’t think I claimed it
had anything to do with other classes of attack, but you don’t seem to
have explained what you think the issues are with SSH anyway.

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

[Richard Kettlewell]

The Natural Philosopher <t...@invalid.invalid> writes:

I’ve got better uses for my CPU[1] than key agreement with low-rent
attackers, and better uses for my logs than background error noise.

[1] and in the summer, the waste heat

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

[Marc Haber]

Richard Kettlewell <inv...@invalid.invalid> wrote:
>The Natural Philosopher <t...@invalid.invalid> writes:
>> On 16/12/2022 09:30, Carlos E. R. wrote:
>>> One idea would be to automatically block the IPs that try to login
>>> as root or other typical names used by bots.
>>> That's something a human operator would do.
>>>
>> Why bother? they would then go on to bother someone else, possibly
>> with less bandwidth than I.
>>
>> If they want to spend an hour trying every single password in their
>> dictionary, its no skin off my nose.
>
>I’ve got better uses for my CPU[1] than key agreement with low-rent
>attackers, and better uses for my logs than background error noise.

It's matter of style, both ways to do it have their advantages and
their disadvantages. It's nothing to get missionary over.

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Computer Nerd Kev]

Ha! I'd end up getting myself blocked that way. I tend to mix up
hostnames from time to time and get hopelessly confused about why I
can't log in, or why all the files are missing (not ideal, I know).

I fail to see how a human watching logs could reliably improve
security over automated methods, let alone AI (which would
presumably consume more system resources than a trickle of SSH
connections anyway).

That said, I do think there's room for usability improvements over
current SSH implementations. Many of the more technical OpenSSH
options are messy and hard to understand. There are lots of (or at
least three, that I've had to deal with) different, incompatible,
private key formats. When a connection fails it's often unclear
whether there's a bug/connection-error or it's due to a
client/server not meeting the other's encryption/authentication
requirements. Mosh also improves on some speed/reliability issues
with connections over slow/unreliable networks.

But it seems that's not what the OP is talking about. On the topic
of security, rather than usability, I don't see any obvious way to
improve things.

--
__ __
#_ < |\| |< _#

[The Natural Philosopher]

Well there you are. The classic 'wrapper' that allows you secure access
anywhere. With that you could probably use 'telnet'....
--
Climate Change: Socialism wearing a lab coat.

[David W. Hodgins]

On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach <a...@spamfence.net> wrote:

> Nah, don't. Have them have their fun. They don't know root won't get in
> and waste their own resources. Although today it won't matter either. But
> not letting them know they cannot login as root they keep trying instead
> of wandering off and try other servers where they might be successful.

>
>> That's something a human operator would do.
>

> I don't think so. Unless being DDoSed. But then you have to take a
> completely different approach to mitigate the traffic.

I don't block, but I use a non-standard port. Otherwise failed attempts
can fill the filesystem where the logs are stored. I had that happen before
I switched ports.

Regards, Dave Hodgins

[The Natural Philosopher]

On 16/12/2022 20:44, Marc Haber wrote:
> Richard Kettlewell <inv...@invalid.invalid> wrote:
>> The Natural Philosopher <t...@invalid.invalid> writes:
>>> On 16/12/2022 09:30, Carlos E. R. wrote:
>>>> One idea would be to automatically block the IPs that try to login
>>>> as root or other typical names used by bots.
>>>> That's something a human operator would do.
>>>>
>>> Why bother? they would then go on to bother someone else, possibly
>>> with less bandwidth than I.
>>>
>>> If they want to spend an hour trying every single password in their
>>> dictionary, its no skin off my nose.
>>
>> I’ve got better uses for my CPU[1] than key agreement with low-rent
>> attackers, and better uses for my logs than background error noise.
>
> It's matter of style, both ways to do it have their advantages and
> their disadvantages. It's nothing to get missionary over.
>

Its not my CPU. I only rent it, and its bandwidth is taken up with other
stuff so that this is lost on the noise/

I don't rig my car up with complicated shields to stop the mud splashing
the wings (fenders) either.

On the server, the log files get rotated, on my car, it gets pressure
washed.

--
"First, find out who are the people you can not criticise. They are your
oppressors."
- George Orwell

[26C.Z969]

On 12/16/22 1:33 AM, Andreas Kohlbach wrote:

> On Fri, 16 Dec 2022 00:28:57 -0500, 26C.Z969 wrote:
>>
>> On 12/15/22 6:36 PM, Andreas Kohlbach wrote:
>>> On Thu, 15 Dec 2022 18:03:48 +0100, Marco Moock wrote:
>>
>>>> Attacks on SSH on IPv4 networks exist (mostly brute-force), but just
>>>> let it run on an IPv6 address, almost nobody will find it and try to
>>>> log in.
>>> Also depends on how long an IP is advertising SSH (or other
>>> services). I
>>> have mine since two years now, and scammers getting busier to get into my
>>> SSH. Not that I care or block any of the IPs involved, as they change
>>> frequently anyway.
>>
>> Strictly IP-centric defenses won't cut it anymore.
>> Attackers tend to use distributed attacks - hundreds,
>> thousands, of addresses. IP-centric defenses can
>> slow-down at least some attackers, which can be good,
>> but hardly all.
>

> I know I'll only access mine via WIFI. Although it listens to the world
> on port 22 I actually don't allow any connection other than from
> 192.168.0.0/24 .
>

Helps.

But I might need to access from a number of random
IP addresses. VPNs can help, but not totally solve
maybe even if you pay for the VPN equiv of a static IP.

Not so long ago, I was working on the weekend and
watched one of these attacks take shape. First it
was one IP address showing up in the firewall logs.
Did a simple conservative /24 block on it. Half an
hour later MORE probes showed up - first from a
few addresses, then dozens, then hundreds banging
at it as fast as they could. Even looking at the
detailed connection info revealed no common factors
you could filter. Dunno if this was one bot or the
"hot" address was shared around. So, as I was pretty
much the only one using it (and it was NOT p22 -
never use that !) I just changed the external port
number. However for TEN MONTHS there were literally
a thousand+ probes a day on that old, dead, port.

This is where I concluded that SSH was not fit for
the modern world. It's not "smart" enough.

>> IPV6 does have some potential ... but a lot of big
>> providers, even Comcast, only offer IPV4 to most
>> customers.
>>
>> Sometimes the "best" defense is obfuscation ...
>> run SSH on an obscure port. If you look at yer
>> firewall logs you'll see shitloads of probes
>> to the standard port. Attackers are mostly bots
>> these days and go for the low-hanging fruit.
>

> May be just let everybody in without password or host key auth. Well no
> seriously.

Some DO make it THAT easy - because, well, it's EASY.
And if you do use a password ... well ... "password"
or "12345678" ought to be good, right ?

> But just for the fun I once set my FTP server for anonymous login (any
> email address and any password allowed to gain access) and looked ever so
> often if someone uploads some crap (I didn't offer any downloads). Still
> nothing after hours, so I looked into the logs. Many people trying many
> different IDs and passwords, which were refused. But none tried anonymous
> access which would had let them in. *g*
>
> I ran this test for eight hours, but no one tried anonymous access.

24 hours, 24 days, 24 months ... not LONG enough. Thing is
the little probe bots WILL eventually find you - and then
POUNCE like a thousand rabid weasels.

[26C.Z969]

On 12/16/22 3:44 PM, Marc Haber wrote:
> Richard Kettlewell <inv...@invalid.invalid> wrote:
>> The Natural Philosopher <t...@invalid.invalid> writes:
>>> On 16/12/2022 09:30, Carlos E. R. wrote:
>>>> One idea would be to automatically block the IPs that try to login
>>>> as root or other typical names used by bots.
>>>> That's something a human operator would do.
>>>>
>>> Why bother? they would then go on to bother someone else, possibly
>>> with less bandwidth than I.
>>>
>>> If they want to spend an hour trying every single password in their
>>> dictionary, its no skin off my nose.
>>
>> I’ve got better uses for my CPU[1] than key agreement with low-rent
>> attackers, and better uses for my logs than background error noise.
>
> It's matter of style, both ways to do it have their advantages and
> their disadvantages. It's nothing to get missionary over.

Strictly "human" attackers are pretty much a historical
artifact at this point - unless you're a bank or govt
letter agency or some similar high-profile/high-return
target. For the rest of the world it's all BOTS - busy
busy little bots. They WILL try every password in their
book and then start on the random shit. They will come
at you from a hundred, a thousand, ten thousand IP
ripped-off addresses. They will keep at it for days,
months. Just one of a thousand little bot processes
running on a few boxes in Romania or Russia that link
through "friendly"-looking address ranges (DigitalOcean
seems to be the most popular route, the Netherlands
seems to be THE path Russians use to APPEAR to be
"EU").

Been there, see it.

SSH isn't "smart" enough to see what a human can
plainly see - an attack. We need some "AI" sort
of adjunct at this point.

Yea, there ARE other tricks - narrow the IP range that
the firewall will even let GET at yer SSH port - but
that's not a solution for all.

A smarter SSH, one intentionally designed for this
bot-ridden world, is needed.

The OTHER, growing, part of the security equation
isn't "hacking" anymore - even by bots - but
"human factors". Idiots in the company or even
spies planted as interns, looking over shoulders.

The favorite ploy the past few months has been
fake invoices - seemingly from respectable corps,
maybe even ones you do biz with. The link to the
detailed invoice will be bad - so you'll wanna
click the "help" link. SOME are obvious ploys,
others are pretty damned good ... might have to
dissect the source/html to spot the fraud. Few
smaller outfits have people who can DO that and
big "computer service providers" are, well, they
collect money and then never DO much. Even they
don't have the people-power or interest to cope.
SOMEWHERE in the service agreement you signed
your rights away ..........

[Richard Kettlewell]

Marc Haber <mh+usene...@zugschl.us> writes:

> Richard Kettlewell <inv...@invalid.invalid> wrote:
>>I’ve got better uses for my CPU[1] than key agreement with low-rent
>>attackers, and better uses for my logs than background error noise.
>
> It's matter of style, both ways to do it have their advantages and
> their disadvantages. It's nothing to get missionary over.

I don’t disagree. Although, when I started, the probes were literally
audible, in my environment: syslog defaults to writing logs
synchronously and my server’s hard disk was rather on the loud side. A
persistent prober produce a gentle ‘bonk ... bonk ... bonk’ noise. That
had to go l-)

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

[Carlos E. R.]

On 17/12/2022 08.03, David W. Hodgins wrote:
> On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach <a...@spamfence.net>
> wrote:
>
>> On Fri, 16 Dec 2022 10:30:17 +0100, Carlos E. R. wrote:
>>>
>>> On 16/12/2022 10.20, The Natural Philosopher wrote:
>>>
>>>> I've had open SSH for years on backbone hosted kit. everybody tries
>>>> to login as root.
>>>> I let them. Root is not allowed to log in.
>>>
>>> One idea would be to automatically block the IPs that try to login as
>>> root or other typical names used by bots.
>>
>> Nah, don't. Have them have their fun. They don't know root won't get in
>> and waste their own resources. Although today it won't matter either. But
>> not letting them know they cannot login as root they keep trying instead
>> of wandering off and try other servers where they might be successful.

They fill the logs.

>>
>>> That's something a human operator would do.
>>
>> I don't think so. Unless being DDoSed. But then you have to take a
>> completely different approach to mitigate the traffic.
>
> I don't block, but I use a non-standard port. Otherwise failed attempts
> can fill the filesystem where the logs are stored. I had that happen before
> I switched ports.

Yes, that's what I do. Works wonderfully, not a hit in months.

>
> Regards, Dave Hodgins

--
Cheers,
Carlos E.R.

[Carlos E. R.]

On 17/12/2022 09.47, Andreas Kohlbach wrote:

> There's logrotate to take care of logfile sizes.

That's not the issue.

The issue is so much noise that something important will be missed.

>
> ~$ ls -lrt /var/log/auth*
> -rw-r----- 1 root adm 78358 Nov 19 23:39 /var/log/auth.log.4.gz
> -rw-r----- 1 root adm 83875 Nov 26 23:57 /var/log/auth.log.3.gz
> -rw-r----- 1 root adm 44726 Dec 3 23:46 /var/log/auth.log.2.gz
> -rw-r----- 1 root adm 449644 Dec 10 23:51 /var/log/auth.log.1
> -rw-r----- 1 root adm 987377 Dec 17 03:45 /var/log/auth.log

--
Cheers,
Carlos E.R.

[Robert Heller]

At Sat, 17 Dec 2022 02:31:12 -0500 "26C.Z969" <26C....@noaada.net> wrote:

>
> On 12/16/22 3:44 PM, Marc Haber wrote:
> > Richard Kettlewell <inv...@invalid.invalid> wrote:
> >> The Natural Philosopher <t...@invalid.invalid> writes:
> >>> On 16/12/2022 09:30, Carlos E. R. wrote:
> >>>> One idea would be to automatically block the IPs that try to login
> >>>> as root or other typical names used by bots.
> >>>> That's something a human operator would do.
> >>>>
> >>> Why bother? they would then go on to bother someone else, possibly
> >>> with less bandwidth than I.
> >>>
> >>> If they want to spend an hour trying every single password in their
> >>> dictionary, its no skin off my nose.
> >>

> >> I’ve got better uses for my CPU[1] than key agreement with low-rent

Not really, a program that analyses SSH's log file can do that. Oh, wait, it
already exists: fail2ban. Hmm... Maybe just a smarter fail2ban?

>
> The OTHER, growing, part of the security equation
> isn't "hacking" anymore - even by bots - but
> "human factors". Idiots in the company or even
> spies planted as interns, looking over shoulders.
>
> The favorite ploy the past few months has been
> fake invoices - seemingly from respectable corps,
> maybe even ones you do biz with. The link to the
> detailed invoice will be bad - so you'll wanna
> click the "help" link. SOME are obvious ploys,
> others are pretty damned good ... might have to
> dissect the source/html to spot the fraud. Few
> smaller outfits have people who can DO that and
> big "computer service providers" are, well, they
> collect money and then never DO much. Even they
> don't have the people-power or interest to cope.
> SOMEWHERE in the service agreement you signed
> your rights away ..........
>
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Rich]

26C.Z969 <26C....@noaada.net> wrote:
> Not so long ago, I was working on the weekend and watched one of
> these attacks take shape. First it was one IP address showing up
> in the firewall logs. Did a simple conservative /24 block on it.
> Half an hour later MORE probes showed up - first from a few
> addresses, then dozens, then hundreds banging at it as fast as they
> could. Even looking at the detailed connection info revealed no
> common factors you could filter. Dunno if this was one bot or the
> "hot" address was shared around. So, as I was pretty much the only
> one using it (and it was NOT p22 - never use that !) I just changed
> the external port number. However for TEN MONTHS there were
> literally a thousand+ probes a day on that old, dead, port.
>
> This is where I concluded that SSH was not fit for the modern
> world. It's not "smart" enough.

Please enlighten us then as to how your proposed "replacement", given
the same situation as you detail above, was to be somehow 'smarter'
and be able to control the actions of actors elsewhere on the internet.

What would this 'smarter' replacement do, given what happened "not so
long ago"?

[Rich]

26C.Z969 <26C....@noaada.net> wrote:
> Strictly "human" attackers are pretty much a historical artifact at
> this point - unless you're a bank or govt letter agency or some
> similar high-profile/high-return target. For the rest of the world
> it's all BOTS - busy busy little bots. They WILL try every
> password in their book and then start on the random shit. They
> will come at you from a hundred, a thousand, ten thousand IP
> ripped-off addresses. They will keep at it for days, months. Just
> one of a thousand little bot processes running on a few boxes in
> Romania or Russia that link through "friendly"-looking address
> ranges (DigitalOcean seems to be the most popular route, the
> Netherlands seems to be THE path Russians use to APPEAR to be
> "EU").
>
> Been there, see it.
>
> SSH isn't "smart" enough to see what a human can plainly see - an
> attack. We need some "AI" sort of adjunct at this point.

Please detail what your proposed 'smarter' ssh would do given this
situation.

And, while you are at it, please explain why this should be an activity
that ssh concerns itself with (thereby adding significant complexity)
as opposed to this being a network monitoring layer, separate from ssh,
that monitors and remediates things on behalf of ssh and any other
services.

> A smarter SSH, one intentionally designed for this
> bot-ridden world, is needed.

Please explain what additional activities your new-ssh would perform,
given the situation you have described above.

[David W. Hodgins]

On Sat, 17 Dec 2022 03:47:12 -0500, Andreas Kohlbach <a...@spamfence.net> wrote:

> There's logrotate to take care of logfile sizes.
>

> ~$ ls -lrt /var/log/auth*
> -rw-r----- 1 root adm 78358 Nov 19 23:39 /var/log/auth.log.4.gz
> -rw-r----- 1 root adm 83875 Nov 26 23:57 /var/log/auth.log.3.gz
> -rw-r----- 1 root adm 44726 Dec 3 23:46 /var/log/auth.log.2.gz
> -rw-r----- 1 root adm 449644 Dec 10 23:51 /var/log/auth.log.1
> -rw-r----- 1 root adm 987377 Dec 17 03:45 /var/log/auth.log

When you get a few dozen hits per minute, it doesn't take a week to use a lot
of log space. Rotating more often will mean info will be removed sooner too.

Granted, disk drive space has come down in price a lot since I ran into the
issue and switched to using a custom port, but there are also new systems
such as raspberry pi, that normally run from an sd card, which limits the
drive size.

Regards, Dave Hodgins

[Carlos E. R.]

On 17/12/2022 15.25, Rich wrote:
> 26C.Z969 <26C....@noaada.net> wrote:
>> Strictly "human" attackers are pretty much a historical artifact at
>> this point - unless you're a bank or govt letter agency or some
>> similar high-profile/high-return target. For the rest of the world
>> it's all BOTS - busy busy little bots. They WILL try every
>> password in their book and then start on the random shit. They
>> will come at you from a hundred, a thousand, ten thousand IP
>> ripped-off addresses. They will keep at it for days, months. Just
>> one of a thousand little bot processes running on a few boxes in
>> Romania or Russia that link through "friendly"-looking address
>> ranges (DigitalOcean seems to be the most popular route, the
>> Netherlands seems to be THE path Russians use to APPEAR to be
>> "EU").
>>
>> Been there, see it.
>>
>> SSH isn't "smart" enough to see what a human can plainly see - an
>> attack. We need some "AI" sort of adjunct at this point.
>
> Please detail what your proposed 'smarter' ssh would do given this
> situation.
>
> And, while you are at it, please explain why this should be an activity
> that ssh concerns itself with (thereby adding significant complexity)
> as opposed to this being a network monitoring layer, separate from ssh,
> that monitors and remediates things on behalf of ssh and any other
> services.

Monitoring logs is a kludge.

>
>> A smarter SSH, one intentionally designed for this
>> bot-ridden world, is needed.
>
> Please explain what additional activities your new-ssh would perform,
> given the situation you have described above.

--
Cheers,
Carlos E.R.

[26C.Z969]

"Port knocking" and relatives are nothing new.
And yes, they WILL keep out the rabble, unless
the rabble is motivated to monitor every packet
coming in and out for days/weeks and the spend
a lot longer in analysis.

But every layer also adds "inconvenience" for
the legit users. They also need custom software
to, for example, light up the correct other
ports so they can access the real one.

Thing is, any human can, looking at the usual
kinds of logs, immediately spot an aggressor.
Computers normally don't see that however -
so perhaps a broader solution is to make it
so they CAN ... apply a little "AI" ... what
does an attack "look like" ?

> Proper packaged port knocker. Might already be one.

There are.

> SSH is a perfectly adequate protocol that only purists find inadequate.

Ten years ago I'd have agreed ... but now with massive
distributed attacks becoming the norm even for the script
kiddies ........

The inbuilt defenses of SSH just weren't made for those
sorts of attacks. You can add wrappers, then more wrappers,
until you have a fragile mess - but a ground-up replacement
seems "better" somehow.

And "security" is never "purist" ... it's VITAL.

[Richard Kettlewell]

"Carlos E. R." <robin_...@es.invalid> writes:
> On 17/12/2022 15.25, Rich wrote:
>> Please detail what your proposed 'smarter' ssh would do given this
>> situation.
>> And, while you are at it, please explain why this should be an
>> activity
>> that ssh concerns itself with (thereby adding significant complexity)
>> as opposed to this being a network monitoring layer, separate from ssh,
>> that monitors and remediates things on behalf of ssh and any other
>> services.
>
> Monitoring logs is a kludge.

If you want SSH to block attackers directly that would be a fairly
simple change to an SSH server. Designing a new secure remote login
protocol just for that would be a bizarre choice.

Personally I think the current architecture is a good example of
decoupling.

I can see a better argument for using PAM to trigger the blocking
(perhaps already possible with pam_exec). That would (in principle)
allow for uniform reporting from SSH, mosh, RDP, etc. Again, though, it
wouldn’t justify the OP’s requirement for a completely new protocol,
which still seems to lack any coherent motivation.

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

[The Natural Philosopher]

He just likes 'new shiny thing, make everything better'
Creeping featurism as a substitute for genuine progress.

--
"Corbyn talks about equality, justice, opportunity, health care, peace,
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"

"Jeremy Corbyn?"

[Marc Haber]

"Carlos E. R." <robin_...@es.invalid> wrote:

>Monitoring logs is a kludge.

Right, ssh and services should have hooks for that. Sadly, for ssh,
this is regularly bludgeoned down by upstream if requested.

Greetings
Marc

[Carlos E. R.]

On 18/12/2022 02.13, Andreas Kohlbach wrote:

> On Sat, 17 Dec 2022 12:43:12 +0100, Carlos E. R. wrote:
>>
>> On 17/12/2022 09.47, Andreas Kohlbach wrote:
>>> On Sat, 17 Dec 2022 02:03:27 -0500, David W. Hodgins wrote:
>>>>
>>>>> I don't think so. Unless being DDoSed. But then you have to take a
>>>>> completely different approach to mitigate the traffic.
>>>>
>>>> I don't block, but I use a non-standard port. Otherwise failed attempts
>>>> can fill the filesystem where the logs are stored. I had that happen before
>>>> I switched ports.
>>> There's logrotate to take care of logfile sizes.
>>
>> That's not the issue.
>>
>> The issue is so much noise that something important will be missed.
>

> I was referring to "can fill the filesystem".

Yes, rotating logs takes care of that. But the issue of too much noise
remains.

--
Cheers,
Carlos E.R.

[Roger Blake]

On 2022-12-16, The Natural Philosopher <t...@invalid.invalid> wrote:
> Block that proxy's public IP address, you block yourself from using it
> ever again.

There are programs such as fail2ban which let you set a timeout after
which a blocked IP address will be unblocked.

--
------------------------------------------------------------------------------
18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
There is no "climate crisis" -- https://climatedepot.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

[26C.Z969]

Ain't gonna be any "genuine progress" using todays
SSH.

All I did here was ASK A QUESTION ... "Is SSH good
enough anymore ?".

And I still don't think so.

World's changed. Change with it or be eaten.

There are MUCH better programmers out there than
myself with a LOT more nuanced experience dealing
with net security problems. Time for some of them
to cast an eye on this. Sure, I can break out the
'C' compiler and write an internet service BUT
there are so many facets to writing a "better SSH"
that'll cope with all the challenges ... I just
ain't the guy. This will take a little "AI" and
that's not my strong suite.

Even the stupidist, brute force, distributed attack
amounts to "denial of service". All yer password
and port-knocking trix won't help much there. Not
entirely sure if that can be dealt with ON *YOUR* BOX,
but maybe. I'm hoping distributed attacks show a
*pattern* that 'AI' can recognize and filter ... and
pass "likely-abused IP addresses" to an online DB in
the same fashion as e-mail blacklists. That's IQ
which grows.

[26C.Z969]

On 12/18/22 8:21 AM, Marc Haber wrote:
> "Carlos E. R." <robin_...@es.invalid> wrote:
>> Monitoring logs is a kludge.
>
> Right, ssh and services should have hooks for that. Sadly, for ssh,
> this is regularly bludgeoned down by upstream if requested.

Ah, so you DO see a little of what I'm talking about ...

And "hooks" are a kludge in and of themselves ... how
about building what those hooks do INTO the SSH app
in the first place, integrated ?

I get the impression that distributed attacks kinda
re-use a lot of the same IP addresses. They likely
drift over a span of weeks or months but to be most
effective they've gotta be relatively "unused" and
"poorly monitored" addresses. This is where a little
"AI" could be useful, SPOT the patterns, BLACKLIST
those "likely evil" IPs in a dynamic fashion.

[26C.Z969]

On 12/17/22 7:59 AM, Robert Heller wrote:
> At Sat, 17 Dec 2022 02:31:12 -0500 "26C.Z969" <26C....@noaada.net> wrote:
>
>>
>> On 12/16/22 3:44 PM, Marc Haber wrote:
>>> Richard Kettlewell <inv...@invalid.invalid> wrote:
>>>> The Natural Philosopher <t...@invalid.invalid> writes:
>>>>> On 16/12/2022 09:30, Carlos E. R. wrote:
>>>>>> One idea would be to automatically block the IPs that try to login
>>>>>> as root or other typical names used by bots.
>>>>>> That's something a human operator would do.
>>>>>>
>>>>> Why bother? they would then go on to bother someone else, possibly
>>>>> with less bandwidth than I.
>>>>>
>>>>> If they want to spend an hour trying every single password in their
>>>>> dictionary, its no skin off my nose.
>>>>

>>>> I’ve got better uses for my CPU[1] than key agreement with low-rent

fail2ban is NOT a bad thing. COULD be smartened-up
a bit, everything can.

SSH is mostly just a protocol, a port, a few
sets of rules. I can write one - but I just
do not have the skills and nuance to fully
grasp all the ways the Bad Guys (or idiots)
can abuse the service these days. That's
kinda a specialty area.

I've mentioned "AI" ... in that I mean mechanisms
to detect a *pattern* that indicates attacks -vs-
the usual traffic. HUMANS can spot it pretty easily
but not software at this juncture. HUMANS can decide
to make dynamic adjustments, but the software is
kinda oblivious.

One thing especially I am wondering about ... the
distributed attacks, are they likely to be using
a subset of IP addresses in certain ways ? If so,
"AI" might be able to pick them out - and, like
with anti-spam services - upload the findings to
some general DBs so the intelligence level keeps
increasing.

[David W. Hodgins]

On Sun, 18 Dec 2022 21:08:12 -0500, 26C.Z969 <26C....@noaada.net> wrote:
<snip>

> I get the impression that distributed attacks kinda
> re-use a lot of the same IP addresses. They likely
> drift over a span of weeks or months but to be most
> effective they've gotta be relatively "unused" and
> "poorly monitored" addresses. This is where a little
> "AI" could be useful, SPOT the patterns, BLACKLIST
> those "likely evil" IPs in a dynamic fashion.

Most of the systems used for ddos attacks are windows systems infected with
malware that allows the ddos operator to use them to launch the attacks. Some
are now linux systems, but most are windows. Each of the infected systems sends
only enough traffic not to make it obvious to the system's owner that their
system is infected, but there are so many infected systems the volume of
traffic can be massive.

Regards, Dave Hodgins

[Computer Nerd Kev]

26C.Z969 <26C....@noaada.net> wrote:
>
> One thing especially I am wondering about ... the
> distributed attacks, are they likely to be using
> a subset of IP addresses in certain ways ? If so,
> "AI" might be able to pick them out - and, like
> with anti-spam services - upload the findings to
> some general DBs so the intelligence level keeps
> increasing.

Anti-spam services... intelligent?! Yeah right!

[Richard Kettlewell]

"26C.Z969" <26C....@noaada.net> writes:
> On 12/18/22 7:02 AM, The Natural Philosopher wrote:
>> He just likes 'new shiny thing, make everything better'
>> Creeping featurism as a substitute for genuine progress.
>
> Ain't gonna be any "genuine progress" using todays
> SSH.
>
> All I did here was ASK A QUESTION ... "Is SSH good
> enough anymore ?".

Well, no, you said it needed to be replaced with something else, but
then completely failed to explain what that something else would do any
differently. At most you’ve made some vague statements about using AI
but nowhere explained why feeding information about failed logins into a
statistical model would need a new secure remote login protocol. You
could do it perfectly well with the log tailing strategy that fail2ban
and its workalikes use.

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

[Richard Kettlewell]

"26C.Z969" <26C....@noaada.net> writes:
> One thing especially I am wondering about ... the distributed
> attacks, are they likely to be using a subset of IP addresses in
> certain ways ? If so, "AI" might be able to pick them out - and,
> like with anti-spam services - upload the findings to some general
> DBs so the intelligence level keeps increasing.

You seem to have reinvented IP address reputation services, which have
existed since the last century, and didn’t require anyone to reinvent
the services they protect.

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

[The Natural Philosopher]

On 19/12/2022 00:12, Roger Blake wrote:
> On 2022-12-16, The Natural Philosopher <t...@invalid.invalid> wrote:
>> Block that proxy's public IP address, you block yourself from using it
>> ever again.
>
> There are programs such as fail2ban which let you set a timeout after
> which a blocked IP address will be unblocked.
>

Fair point.

I like Richards VPN idea too, if you are that paranoid. I am not.

I've nothing to hide and nothing worth stealing.
If some government wants to spend time reading my emails, well its
taxpayer money down the drain. But that's what governments are for, innit?


--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14

[The Natural Philosopher]

No profress is needed

>   All I did here was ASK A QUESTION ... "Is SSH good
>   enough anymore ?".
>

Yes, its well good enough, especially when wrapped with port knockers or
fail2ban or a VPN

>   And I still don't think so.

You are entitled to your lone opinion

>
>   World's changed. Change with it or be eaten.
>

World hasn't changed. Just a fresh crop of bright eyed bushy tailed know
it all ignoramuses who think they are the first people to think of anything.

>   There are MUCH better programmers out there than
>   myself

Gosh. No kidding

> with a LOT more nuanced experience dealing
>   with net security problems. Time for some of them
>   to cast an eye on this. Sure, I can break out the
>   'C' compiler and write an internet service BUT
>   there are so many facets to writing a "better SSH"
>   that'll cope with all the challenges ... I just
>   ain't the guy. This will take a little "AI" and
>   that's not my strong suite.
>
>   Even the stupidist, brute force, distributed attack
>   amounts to "denial of service". All yer password
>   and port-knocking trix won't help much there. Not
>   entirely sure if that can be dealt with ON *YOUR* BOX,
>   but maybe. I'm hoping distributed attacks show a
>   *pattern* that 'AI' can recognize and filter ... and
>   pass "likely-abused IP addresses" to an online DB in
>   the same fashion as e-mail blacklists. That's IQ
>   which grows.

Silly boy. All traffic is a potential denial of service. Move a firewall
off your linux to your boundary router and it still takes up bandwidth
*to* the router.
Unless you move your filter to your ISP, any personal, or small business
link can be flooded by a DDOS attack whether you have blocked the
source IP or not. Or have anything listening to its port destination.
Rewritng ssh wont make any difference to any of that

Older wiser people are concerned with doing risk cost benefit analysis
and have more important things to do than wheel reinvention.

The reality , stripped of your rhetoric, is that ssh is configurable
enough to only work for specific users at specific targets equipped with
the right cryptokey.

The overhead to run it against attacks that are logged is much smaller
than other issues, and does not result in any serious DOS.

Changing it would not improve the situation for a mass DDOS attack
anyway, which would not be targetted at ssh anyway.

[Carlos E. R.]

Log scanning is a kludge. There should be a better way, maybe the ssh
daemon having an API to get/push that information to another daemon.

--
Cheers,
Carlos E.R.

[The Natural Philosopher]

Another way of saying in your inimitable conciseness, what I said.
1/. Its more than good enough, especially with wrappers
2/. Its hard to see how any hypothetical vulnerabilities would be fixed
by a rewrite.

In short the whole suggestion reeks of *creeping featurism*, the weed of
desire to change something that works perfectly well , simply because it
hasn't been made shiny enough, complicated enough, or sufficiently
bug-filled, and you want to be noticed as a programmer.

You are Lennart Poettering, and I claim my $50m


--
To ban Christmas, simply give turkeys the vote.

[The Natural Philosopher]

And it doesn't need an sshd on the far end to be effective, In fact not
responding to it wont change the denial.

--
Climate is what you expect but weather is what you get.
Mark Twain

[Carlos E. R.]

On 19/12/2022 03.08, 26C.Z969 wrote:
> On 12/18/22 8:21 AM, Marc Haber wrote:
>> "Carlos E. R." <robin_...@es.invalid> wrote:
>>> Monitoring logs is a kludge.
>>
>> Right, ssh and services should have hooks for that. Sadly, for ssh,
>> this is regularly bludgeoned down by upstream if requested.
>
>   Ah, so you DO see a little of what I'm talking about ...
>
>   And "hooks" are a kludge in and of themselves ... how
>   about building what those hooks do INTO the SSH app
>   in the first place, integrated ?

Because that adds bloat, and makes sshd more difficult to analyze and
maintain. More failure points.

Keep to the unix principle of small programs tht do some task well.

--
Cheers,
Carlos E.R.

[Pancho]

On 16/12/2022 18:21, Richard Kettlewell wrote:
> The Natural Philosopher <t...@invalid.invalid> writes:

>> On 15/12/2022 08:39, Richard Kettlewell wrote:
>>> Not much intelligence needed, anything that gets more than a handful
>>> of password authentication error is an attacker and gets added to my
>>> ‘block’ ipset.
>>>
>> Just hope it wasn't from some public wifi dynamic address that you
>> might want to use in future :-)
>
> Pretty unlikely. But my VPN will get me past it in the event that
> happens.
>

How do you protect your VPN from attack? :-)

I've never thought much about SSH, apart from I should be more diligent
with respect to private key protection, but I have long wanted a
replacement for OpenVPN, due to poor performance, and am currently
trying out Wireguard.

[The Natural Philosopher]

On 19/12/2022 15:46, Pancho wrote:
> On 16/12/2022 18:21, Richard Kettlewell wrote:
>> The Natural Philosopher <t...@invalid.invalid> writes:
>>> On 15/12/2022 08:39, Richard Kettlewell wrote:
>>>> Not much intelligence needed, anything that gets more than a handful
>>>> of password authentication error is an attacker and gets added to my
>>>> ‘block’ ipset.
>>>>
>>> Just hope it wasn't from some public wifi dynamic address that you
>>> might want to use in future :-)
>>
>> Pretty unlikely. But my VPN will get me past it in the event that
>> happens.
>>
>
> How do you protect your VPN from attack? :-)

Actually Richard, if you are listening, some of us never bothered with
VPNS. Care to post an overview?

--
“The ultimate result of shielding men from the effects of folly is to
fill the world with fools.”

Herbert Spencer

[26C.Z969]

You are largely correct, but I've looked at these
attacks before, tried to track-down the sources.
Rather a lot of the addresses used are not "legit",
and "active" - but come from the unused pool and/or
from nations and 2nd/3rd-world corps that have been
allocated addresses but hardly use any of them
(especially Pacific islands).

With Linux/Unix you can pretend to be any IP you want,
any MAC address you want. Do-able in Winders too of
course, but not quite so transparently. Winders still
makes the better bots IMHO, so many utterly oblivious
potential hosts. The phone OS's may be largely based
on Linux/Unix but 99.999% of the users are the same
oblivious ones who also own Winders PCs.

So yes, they may (lightly) use thousands of Winders
PCs, but I think they try to preserve the anonymity
of those PCs just a bit too - so they can be a
continuing resource instead of simply, easily, blocked.

[26C.Z969]

On 12/19/22 6:27 AM, Carlos E. R. wrote:
> On 19/12/2022 03.08, 26C.Z969 wrote:
>> On 12/18/22 8:21 AM, Marc Haber wrote:
>>> "Carlos E. R." <robin_...@es.invalid> wrote:
>>>> Monitoring logs is a kludge.
>>>
>>> Right, ssh and services should have hooks for that. Sadly, for ssh,
>>> this is regularly bludgeoned down by upstream if requested.
>>
>>    Ah, so you DO see a little of what I'm talking about ...
>>
>>    And "hooks" are a kludge in and of themselves ... how
>>    about building what those hooks do INTO the SSH app
>>    in the first place, integrated ?
>
> Because that adds bloat, and makes sshd more difficult to analyze and
> maintain. More failure points.

Doesn't matter where "bloat" comes from - ONE app or
half a dozen others you hook to. Same rolly-polly,
just not so neat.

> Keep to the unix principle of small programs tht do some task well.

But what's "well" - today ?

Good ole' SSH was "well" a decade+ ago, but things
have changed radically on the security front since.

[26C.Z969]

D.O.S. attacks CAN be a big, almost impossible,
problem. You really can't deal with those at the
afflicted end of the equation - the SOURCES need
to be detected and blocked almost at the first node
they use so they can't SEND anything.

On the lucky side, while such attacks happen, they're
not generally a problem of the "smaller users" - but
giant corporate/govt instead ... things perps will
feel it's WORTH burning their distributed resources
doing. DOS is almost always "political" or "revenge",
occasionally an attempt to swing markets/customer-bases.

Alas DOS is only a small part of my overall concern
here. We've got creaky old "simple" SSH. Sure, you
can hook in a lot of other protective mechanisms
but that's kludgy and amounts to the same degree
of "bloat".

A lot of us have written services that do pretty
much the same things - and it doesn't take THAT
much coding these days with all the wunnerful libraries.
Thing is the security equation has changed considerably
in the past decade or so, with distributed attack
methods now the norm. Even the script kiddies can
tap into bot-nets and command their own 'army'.
There's only so much we can do at OUR end, but
that doesn't mean we shouldn't do it.

Got 10,000+ probes from ONE UK address recorded in
my firewall log last night. They probed everything,
TCP/UDP. I can block that address (well, a little
range of them) with a few keystrokes. But when they
come from 10,000 different IPs, 10,000 different
directions .....

[Richard Kettlewell]

"Carlos E. R." <robin_...@es.invalid> writes:

> Log scanning is a kludge. There should be a better way, maybe the ssh
> daemon having an API to get/push that information to another daemon.

The question of how login failure information gets from SSH to somewhere
else is the least interesting part of the whole question. Try focusing
on something that actually matters.

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

[Richard Kettlewell]

Pancho <Pancho...@proton.me> writes:
> On 16/12/2022 18:21, Richard Kettlewell wrote:
>> The Natural Philosopher <t...@invalid.invalid> writes:
>>> On 15/12/2022 08:39, Richard Kettlewell wrote:
>>>> Not much intelligence needed, anything that gets more than a handful
>>>> of password authentication error is an attacker and gets added to my
>>>> ‘block’ ipset.
>>>>
>>> Just hope it wasn't from some public wifi dynamic address that you
>>> might want to use in future :-)
>> Pretty unlikely. But my VPN will get me past it in the event that
>> happens.
>
> How do you protect your VPN from attack? :-)

Same way as SSH, with public key cryptography.

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

[Richard Kettlewell]

Sorry, I misremembered; I didn’t get around to setting that up for the
clients, so it’s EAP with randomly generated passwords (albeit over a
secure channel established with public key cryptography).

(But note that the scanner blocking is not about stopping breakins, just
about resource consumption, where the resources are CPU, and my
attention when looking at logs for whatever reason.)

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

[Richard Kettlewell]

The Natural Philosopher <t...@invalid.invalid> writes:
> Actually Richard, if you are listening, some of us never bothered with
> VPNS. Care to post an overview?

I will try to write it up sometime but there’s a lot to get through -
strongSwan (which I used on the Linux endpoints) is flexible and
complex, and its pre-cooked recipes only cover a small set of use cases.

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

[Ted Heise]

On Sat, 17 Dec 2022 08:58:58 +0000,
Richard Kettlewell <inv...@invalid.invalid> wrote:
> Marc Haber <mh+usene...@zugschl.us> writes:
> > Richard Kettlewell <inv...@invalid.invalid> wrote:
> >>I???ve got better uses for my CPU[1] than key agreement with

> >>low-rent attackers, and better uses for my logs than
> >>background error noise.
> >
> > It's matter of style, both ways to do it have their advantages
> > and their disadvantages. It's nothing to get missionary over.
>

> I don???t disagree. Although, when I started, the probes were
> literally audible, in my environment: syslog defaults to
> writing logs synchronously and my server???s hard disk was
> rather on the loud side. A persistent prober produce a gentle
> ???bonk ... bonk ... bonk??? noise. That had to go l-)

Oh, I thought you were going to say the printer would take off.

In the old days, I piped a copy of some log messages to my old dot
matrix printer so as to have evidence if someone broke in and
covered all their tracks. Silly waste of time, but the whole
setup was a hobby.

--
Ted Heise <the...@panix.com> West Lafayette, IN, USA

[Richard Kettlewell]

Ted Heise <the...@panix.com> writes:
> Richard Kettlewell <inv...@invalid.invalid> wrote:

>> I don’t disagree. Although, when I started, the probes were

>> literally audible, in my environment: syslog defaults to

>> writing logs synchronously and my server’s hard disk was

>> rather on the loud side. A persistent prober produce a gentle

>> ’bonk ... bonk ... bonk’ noise. That had to go l-)

>
> Oh, I thought you were going to say the printer would take off.
>
> In the old days, I piped a copy of some log messages to my old dot
> matrix printer so as to have evidence if someone broke in and
> covered all their tracks. Silly waste of time, but the whole
> setup was a hobby.

Reminds me of the Bangladesh central bank heist. The attackers’ first
move was to disable the printer used to log SWIFT transactions.

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

[Ted Heise]

On Tue, 20 Dec 2022 16:14:51 +0000,
Richard Kettlewell <inv...@invalid.invalid> wrote:
> Ted Heise <the...@panix.com> writes:
> > Richard Kettlewell <inv...@invalid.invalid> wrote:

> >> I don???t disagree. Although, when I started, the probes were

> >> literally audible, in my environment: syslog defaults to

> >> writing logs synchronously and my server???s hard disk was

> >> rather on the loud side. A persistent prober produce a gentle

> >> ???bonk ... bonk ... bonk??? noise. That had to go l-)

> >
> > Oh, I thought you were going to say the printer would take
> > off.
> >
> > In the old days, I piped a copy of some log messages to my old
> > dot matrix printer so as to have evidence if someone broke in
> > and covered all their tracks. Silly waste of time, but the
> > whole setup was a hobby.
>
> Reminds me of the Bangladesh central bank heist. The

> attackers??? first move was to disable the printer used to log
> SWIFT transactions.


HAHaha. That was a great escapade. Here's a good recountng of
it...

https://www.npr.org/2022/02/09/1079528331/a-swift-getaway

[26C.Z969]

On 12/19/22 5:05 AM, Richard Kettlewell wrote:
> "26C.Z969" <26C....@noaada.net> writes:
>> On 12/18/22 7:02 AM, The Natural Philosopher wrote:
>>> He just likes 'new shiny thing, make everything better'
>>> Creeping featurism as a substitute for genuine progress.
>>
>> Ain't gonna be any "genuine progress" using todays
>> SSH.
>>
>> All I did here was ASK A QUESTION ... "Is SSH good
>> enough anymore ?".
>
> Well, no, you said it needed to be replaced with something else,

I suggested that as the "cleanest" option - not like
I'm in a position to DEMAND anything. And no, I'm
not the guy to spend the next five years writing a
replacement .......

> but
> then completely failed to explain what that something else would do any
> differently. At most you’ve made some vague statements about using AI
> but nowhere explained why feeding information about failed logins into a
> statistical model would need a new secure remote login protocol. You
> could do it perfectly well with the log tailing strategy that fail2ban
> and its workalikes use.

I explained what I saw as weaknesses quite well, IMHO.

And the standard answer was "Hook more external utilities
to it", which equals A MESS.

How about something you DON'T have to hook lots of
external utilities into ?

The other angle was in *detecting* attacks and doing
smart things if those are found. HUMANS can spot them
pretty damned easily just by looking at a log file
or two - but not PCs. "AI" pattern-detection seems
to be the modern answer.

[Richard Kettlewell]

"26C.Z969" <26C....@noaada.net> writes:
> On 12/19/22 5:05 AM, Richard Kettlewell wrote:
>> "26C.Z969" <26C....@noaada.net> writes:
>>> On 12/18/22 7:02 AM, The Natural Philosopher wrote:
>>>> He just likes 'new shiny thing, make everything better'
>>>> Creeping featurism as a substitute for genuine progress.
>>>
>>> Ain't gonna be any "genuine progress" using todays
>>> SSH.
>>>
>>> All I did here was ASK A QUESTION ... "Is SSH good
>>> enough anymore ?".
>> Well, no, you said it needed to be replaced with something else,
>
> I suggested that as the "cleanest" option - not like I'm in a position
> to DEMAND anything. And no, I'm not the guy to spend the next five
> years writing a replacement .......

It’s a ridiculous option, given your apparent requirements. Nothing
about the SSH protocol stops you treating scans/probes in any way you
like. Replacing it would be a large amount of pointless work unrelated
to your goals, and sacrifice the interoperability we currently have with
SSH.

>> but then completely failed to explain what that something else would
>> do any differently. At most you’ve made some vague statements about
>> using AI but nowhere explained why feeding information about failed
>> logins into a statistical model would need a new secure remote login
>> protocol. You could do it perfectly well with the log tailing
>> strategy that fail2ban and its workalikes use.
>
> I explained what I saw as weaknesses quite well, IMHO.

The quality of your explanation is measured by how well the audience
understand it, not your opinion.

> And the standard answer was "Hook more external utilities
> to it", which equals A MESS.
>
> How about something you DON'T have to hook lots of
> external utilities into ?

You (or someone) can write an SSH server with any feature set you like,
if time and effort are available, and people do. Some start from OpenSSH
and other start from scratch. But that’s not replacing SSH as you asked
for, that’s just a new server; you’ve said nothing that explains why SSH
is the problem you care about rather than any particular server
implementation. (If there’s really something you don’t like about the
SSH protocol then an RFC reference would make it clearer.)

But since the scanning we’re talking about happens with many other
protocols (e.g. HTTP, IMAP, SMTP) it’d be a bizarre choice to build your
scanner management tools into the server implementation; it prevents
re-use of the work in related contexts. As we’ve already discussed, a
common thing to do is share address reputation information (with DNSBLs
etc) and to do that, you’re definitely going to have external
interfaces, whether you like them or not.

The tight integration you’re asking for also makes it harder for the
different concerns to evolve independently. ECDHC key exchange and
statistical models of attacker behavior are rather different domains and
there’s no inherent reason the people who are good at each should have
to be brought into the same project, work to the same timelines, etc.

> The other angle was in *detecting* attacks and doing smart things if
> those are found. HUMANS can spot them pretty damned easily just by
> looking at a log file or two - but not PCs. "AI" pattern-detection
> seems to be the modern answer.

If you want to do that then nothing about SSH or its implementations is
stopping you. Maybe the lack of an AI model that does what you want is
stopping you or maybe just your own arbitrary constraint about not using
a component model is stopping you, but replacing SSH won’t get you any
closer to your goal.

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

[26C.Z969]

On 12/17/22 10:30 AM, David W. Hodgins wrote:
> On Sat, 17 Dec 2022 03:47:12 -0500, Andreas Kohlbach <a...@spamfence.net>
> wrote:
>
>> On Sat, 17 Dec 2022 02:03:27 -0500, David W. Hodgins wrote:
>>>
>>> On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach
>>> <a...@spamfence.net> wrote:
>>>
>>>> On Fri, 16 Dec 2022 10:30:17 +0100, Carlos E. R. wrote:
>>>>>
>>>> Nah, don't. Have them have their fun. They don't know root won't get in
>>>> and waste their own resources. Although today it won't matter
>>>> either. But
>>>> not letting them know they cannot login as root they keep trying
>>>> instead
>>>> of wandering off and try other servers where they might be successful.

>>>>
>>>>> That's something a human operator would do.
>>>>

>>>> I don't think so. Unless being DDoSed. But then you have to take a
>>>> completely different approach to mitigate the traffic.
>>>
>>> I don't block, but I use a non-standard port. Otherwise failed attempts
>>> can fill the filesystem where the logs are stored. I had that happen
>>> before
>>> I switched ports.
>>
>> There's logrotate to take care of logfile sizes.
>>
>> ~$ ls -lrt /var/log/auth*
>> -rw-r----- 1 root adm  78358 Nov 19 23:39 /var/log/auth.log.4.gz
>> -rw-r----- 1 root adm  83875 Nov 26 23:57 /var/log/auth.log.3.gz
>> -rw-r----- 1 root adm  44726 Dec  3 23:46 /var/log/auth.log.2.gz
>> -rw-r----- 1 root adm 449644 Dec 10 23:51 /var/log/auth.log.1
>> -rw-r----- 1 root adm 987377 Dec 17 03:45 /var/log/auth.log
>
> When you get a few dozen hits per minute, it doesn't take a week to use
> a lot
> of log space. Rotating more often will mean info will be removed sooner
> too.
>
> Granted, disk drive space has come down in price a lot since I ran into the
> issue and switched to using a custom port, but there are also new systems
> such as raspberry pi, that normally run from an sd card, which limits the
> drive size.

I've writ a number of special-purpose apps for PIs, but
yes, the space issue requires a lot of thought. You CAN
attach a USB SSD or even an efficient USB HD (have a 3tb
one attached to one Pi)

Another work around, if available, is to use an SMB share
on an NAS or something.

The sad thing about PI's isn't their capabilities, but
the POWER CONSUMPTION. That severely limits them for
"off grid" uses. Less impressive units like BeagleBone's
and esp Arduino's let you turn off basically every
peripherial until it's needed, and then cut it off again.
You can even tweak the CPU speed dynamically. You can
run an Ard off a mere 3-watt solar cell - though 5w is
safer - (use Seeed's LipoRider Pro to charge the battery !)
so long as you are taking samples at intervals (data-logger
type use).

Now as for SSH logs ... yea ... if possible NEVER expose
the standard port. I don't even use it on local networks.

The downside is that while the logs will tell you a lot
of things you have to FIGURE OUT what they're trying to
tell you. Various kinds of attacks (and simple faults)
don't always stand out very well.

Again another place where "AI"-style pattern detection
might be of use. Yer PC should *tell YOU* when there
might be a problem. If you routinely deal with a lot
of boxes, lots of net-connected boxes esp, you can
blow the entire day trying to dig though those logs
in search of a "something".

[Computer Nerd Kev]

26C.Z969 <26C....@noaada.net> wrote:
>
> The sad thing about PI's isn't their capabilities, but
> the POWER CONSUMPTION. That severely limits them for
> "off grid" uses. Less impressive units like BeagleBone's
> and esp Arduino's let you turn off basically every
> peripherial until it's needed, and then cut it off again.

You can do a bit of that with the Pis, though it doesn't save much.

> You can even tweak the CPU speed dynamically.

That's done by default with a Pi running Linux.

> You can
> run an Ard off a mere 3-watt solar cell - though 5w is
> safer - (use Seeed's LipoRider Pro to charge the battery !)
> so long as you are taking samples at intervals (data-logger
> type use).

I measured the power consumption of an original Pi Zero at 90mA
while doing nothing, peaking at 190mA during boot-up. So if it's
usually idling then that's only 0.45W from the 5V power supply, and
at worst it'll peak at about 1W.

Also if you set code running on the GPU, it continues going after
the CPU is shut down (with access to GPIO signals), at which
time the board only pulls 50mA (0.25W). If you worked really hard
you could probably get the GPU to "wake up" the CPU roughly like
microcontroller sleep-modes, based on the (incomplete) open-source
GPU firmware for the Pis which needs to start up the CPU at
power-on anyway.

The RPi Zero 2 is more power hungry than the original Zero.

[The Natural Philosopher]

My Pi has 2TB of NFS attached storage ;-)

--
"I guess a rattlesnake ain't risponsible fer bein' a rattlesnake, but ah
puts mah heel on um jess the same if'n I catches him around mah chillun".

[26C.Z969]

Nevermind, I will just write my own.

[26C.Z969]

On 12/23/22 11:26 PM, Andreas Kohlbach wrote:

> On Fri, 23 Dec 2022 22:36:50 -0500, 26C.Z969 wrote:
>>
>> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>>
>>> When you get a few dozen hits per minute, it doesn't take a week to
>>> use a lot
>>> of log space. Rotating more often will mean info will be removed
>>> sooner too.
>>> Granted, disk drive space has come down in price a lot since I ran
>>> into the
>>> issue and switched to using a custom port, but there are also new systems
>>> such as raspberry pi, that normally run from an sd card, which limits the
>>> drive size.
>>
>> I've writ a number of special-purpose apps for PIs, but
>> yes, the space issue requires a lot of thought. You CAN
>> attach a USB SSD or even an efficient USB HD (have a 3tb
>> one attached to one Pi)
>

> "pi" also seems to be a famous username for trying to get into a
> computer, as I can see in my logs.

The recent Raspbian incarnations allow you to set the
default user name during install, even encourage you NOT
to use "pi".

Of course "pi" is perfectly good IF you use a decent PW.
For SSH, set very low limits on tries from one IP and on
parallel login threads. I doubt you need to use a PI
to handle all commercial internet traffic so you can
be very anal about that stuff.


> | 2022-12-23T03:06:33.815375-05:00 localhost sshd[22509]: Failed password for invalid user pi from 89.109.32.143 port 24603 ssh2
>
> Got tons of these, next to "admin".
>
> Recently I allowed the scammers "SSH access" again. Not limiting it to
> 192.168.0.0 anymore, to get some log entries.

Experiments CAN be enlightening :-)

Every so often I set firewall rule #1 to allow all - and
log it. Just for five minutes or so of course. The results
can be, well, "interesting" ...

> Btw. the IP attempting from in this extract is from Russia. Could be a
> hacked computer though.

"admin" is the other common 'default' (sometimes irreplacable)
user name on zillions of devices and apps.

Again, use a decent PW or even more and you'll be OK.

[26C.Z969]

I use one PI as a 3rd-tier backup device - and it has
a 3tb USB HDD as space - almost exactly the same physical
size as the Pi.It's been doing its thing for a few years
now. The newer USB SSDs are also moving into an attractive
price/capacity range now (though supply issues do seem to
be a damper there).

The device duplicates compressed backups prepped by
the main backup box the night before - so it doesn't
matter if the Pi is notably slower.

I'd strongly rec the Samsung Evo's - top quality and
you can get 1tb for like $89 on Amazon lately. The
"quads" ... um ... OK I guess, more TB/$ ... but they
are slower and the tech is alleged to be a bit less
reliable. The original "single density" "Pro" 860 line
seems to have disappeared.

There are also rather large ordinary USB sticks these
days ... but their reliability is ... well .......

In any case, you CAN attach quite a lot of storage to
a Pi at a fair price. DO write yer apps so they CHECK
to see if the device is ACTUALLY mounted though. Linux
can be a bit stupid in that respect and you'll just
overwhelm your primary almost instantly as all yer
files get moved to your mountPOINT instead of the
actual larger mount. Mounting of USBs should always
be CONFIRMED. Even a simple size check will provide
the needed info.

[26C.Z969]

On 12/23/22 11:37 PM, Computer Nerd Kev wrote:
> 26C.Z969 <26C....@noaada.net> wrote:
>>
>> The sad thing about PI's isn't their capabilities, but
>> the POWER CONSUMPTION. That severely limits them for
>> "off grid" uses. Less impressive units like BeagleBone's
>> and esp Arduino's let you turn off basically every
>> peripherial until it's needed, and then cut it off again.
>
> You can do a bit of that with the Pis, though it doesn't save much.

No, not much at all. I also do "embedded" and field
datalogger apps - and unless you want a rather large
solar panel and battery the Pi's are totally unsuitable
Microcontroller-based is MUCH better - but they're
normally not gonna be Linux ... dedicated 'C' app instead.

>
>> You can even tweak the CPU speed dynamically.
>
> That's done by default with a Pi running Linux.

Um ... not nearly enough.

Some microcontrollers can go fully static - just
waiting for an interrupt to spring into action.

>> You can
>> run an Ard off a mere 3-watt solar cell - though 5w is
>> safer - (use Seeed's LipoRider Pro to charge the battery !)
>> so long as you are taking samples at intervals (data-logger
>> type use).
>
> I measured the power consumption of an original Pi Zero at 90mA
> while doing nothing, peaking at 190mA during boot-up. So if it's
> usually idling then that's only 0.45W from the 5V power supply, and
> at worst it'll peak at about 1W.

Arduino's can be shut down to micro-watt levels between
bursts of activity. Some PICs can theoretically do
nano-watts and they're not even cutting edge anymore.
I did a bunch of field dataloggers based on the Ard Mega -
with a flash-drive shield attached. Do yer collection
every 15 or 30 minutes, write it to the flash, then set
the thing stone cold until the next timer-chip pulse.
You can cut out the 3.3v regulator and dump the I2C
resistor in favor of a pin you power-up yerself at
the correct time. Smash the power LED too :-)

Those WOULD run from a mere 3w solar panel and lipo
battery ... UNLESS the skies were cloudy too often.
So, I changed to a 5w panel and that fixed it.

> Also if you set code running on the GPU, it continues going after
> the CPU is shut down (with access to GPIO signals), at which
> time the board only pulls 50mA (0.25W). If you worked really hard
> you could probably get the GPU to "wake up" the CPU roughly like
> microcontroller sleep-modes, based on the (incomplete) open-source
> GPU firmware for the Pis which needs to start up the CPU at
> power-on anyway.

I had considered using a microcontroller to wake up a Pi
when needed - and for some kinds of apps that might be
reasonable. What I was doing, no, just stick with
microcontroller-based hardware in the first place.

> The RPi Zero 2 is more power hungry than the original Zero.

Well, faster ... there IS a price.

[26C.Z969]

Oh, there's a REASON I said to use the Seeed Lipo-Rider Pro ...

CHECK what voltage you're getting from some of the other
lipo chargers (at low consumption levels) and you'll find
they go WAY out of spec when the sun comes up really bright,
enough to do damage. The Lipo-Rider Pro HOLDS its 5.5v
rock steady though.

[The Natural Philosopher]

On 26/12/2022 06:14, 26C.Z969 wrote:
> On 12/23/22 11:26 PM, Andreas Kohlbach wrote:
>> On Fri, 23 Dec 2022 22:36:50 -0500, 26C.Z969 wrote:
>>>
>>> On 12/17/22 10:30 AM, David W. Hodgins wrote:
>>>
>>>> When you get a few dozen hits per minute, it doesn't take a week to
>>>> use a lot
>>>> of log space. Rotating more often will mean info will be removed
>>>> sooner too.
>>>> Granted, disk drive space has come down in price a lot since I ran
>>>> into the
>>>> issue and switched to using a custom port, but there are also new
>>>> systems
>>>> such as raspberry pi, that normally run from an sd card, which
>>>> limits the
>>>> drive size.
>>>
>>>    I've writ a number of special-purpose apps for PIs, but
>>>    yes, the space issue requires a lot of thought. You CAN
>>>    attach a USB SSD or even an efficient USB HD (have a 3tb
>>>    one attached to one Pi)
>>
>> "pi" also seems to be a famous username for trying to get into a
>> computer, as I can see in my logs.
>
>   The recent Raspbian incarnations allow you to set the
>   default user name during install, even encourage you NOT
>   to use "pi".
>

I have an older one, but I edited (as root) the /etc/passwd file and set
user 1000 to my name.
And set it up with a different password

>   Of course "pi" is perfectly good IF you use a decent PW.
>   For SSH, set very low limits on tries from one IP and on
>   parallel login threads. I doubt you need to use a PI
>   to handle all commercial internet traffic so you can
>   be very anal about that stuff.

--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.

[26C.Z969]

Easiest way if you're paranoid about "pi". You can
also just create a new user and then move the various
permissions from 'pi' to that and disable/hide "pi".

I don't think the usual full-number upgrade procedure
will give you the op to change user 1000, just a from-
scratch.

I still think 'Raspbian' is the best for the Pi. It
is best attuned to the board. Sure, you can run a bunch
of different systems on it - most any 'buntu derivative,
I've run OpenSUSE Tweed, and a few odd ones (even BSDs) -
but with Raspbian you are sure to get all the needed
libraries and utilities and such plus it IS Debian/LX
under the hood and thus a damned good system. Do NOT
like the shift to LXQT however ... it has weird problems.
XFCE is the logical replacement, or bite it and force LXDE
back in there.

Oh, not long back I discovered a Pi v1 'B' (256mb with fewer
pins than the newer ones) was still doing its one little
service in the back of the IT cave with its ancient Wheezy
release (kernel 3.6). It's not online so security updates
are irrelevant. Installed the Buster (all platform) Raspbian
Lite out of pity on a fresh flash card and it worked just
perfectly. Good for another decade probably. I like that kind
of backwards compatibility ... kinda like if you could install
Win11 on a PC-XT :-)

[Computer Nerd Kev]

26C.Z969 <26C....@noaada.net> wrote:
> On 12/23/22 11:37 PM, Computer Nerd Kev wrote:
>> 26C.Z969 <26C....@noaada.net> wrote:
>>>
>>> The sad thing about PI's isn't their capabilities, but
>>> the POWER CONSUMPTION. That severely limits them for
>>> "off grid" uses. Less impressive units like BeagleBone's
>>> and esp Arduino's let you turn off basically every
>>> peripherial until it's needed, and then cut it off again.

[snip]

>> Also if you set code running on the GPU, it continues going after
>> the CPU is shut down (with access to GPIO signals), at which
>> time the board only pulls 50mA (0.25W). If you worked really hard
>> you could probably get the GPU to "wake up" the CPU roughly like
>> microcontroller sleep-modes, based on the (incomplete) open-source
>> GPU firmware for the Pis which needs to start up the CPU at
>> power-on anyway.
>
> I had considered using a microcontroller to wake up a Pi
> when needed - and for some kinds of apps that might be
> reasonable. What I was doing, no, just stick with
> microcontroller-based hardware in the first place.

For what you were doing you didn't need any of the Pi's features
anyway, so I'm not sure why you were sad that you couldn't use one.

[26C.Z969]

Lusted for periodic photos of the environment ... and
few microcontrollers have enough RAM or speed to cope.
They will work OK with a cellular modem though.

These days you can buy all that and more off the $helf ;
try the smart ag or environmental-management suppliers.
Much more fun wiring yer own though :-)

[Popping Mad]

On 12/15/22 01:52, 26C.Z969 wrote:
> SSH is a good oldie for sure. However, it seems to
> be increasingly unfit for the modern realities.


what bullshit

[Popping Mad]

On 12/16/22 00:16, 26C.Z969 wrote:
> In the end I may HAVE to


Good! Let us know when you have it released under the GPL

[26C.Z969]

Thank you for your constructive input.

Nevermind ... SSH beyond perfect even in a
world of mass distributed attacks ... just
keep repeating that ......... :-)

Decided to write my own replacement. It won't
be freeware ...

[26C.Z969]

No, not GPL ... $$$ :-)

[26C.Z969]

On 12/17/22 9:21 AM, Rich wrote:
> 26C.Z969 <26C....@noaada.net> wrote:
>> Not so long ago, I was working on the weekend and watched one of
>> these attacks take shape. First it was one IP address showing up
>> in the firewall logs. Did a simple conservative /24 block on it.
>> Half an hour later MORE probes showed up - first from a few
>> addresses, then dozens, then hundreds banging at it as fast as they
>> could. Even looking at the detailed connection info revealed no
>> common factors you could filter. Dunno if this was one bot or the
>> "hot" address was shared around. So, as I was pretty much the only
>> one using it (and it was NOT p22 - never use that !) I just changed
>> the external port number. However for TEN MONTHS there were
>> literally a thousand+ probes a day on that old, dead, port.
>>
>> This is where I concluded that SSH was not fit for the modern
>> world. It's not "smart" enough.
>
> Please enlighten us then as to how your proposed "replacement", given
> the same situation as you detail above, was to be somehow 'smarter'
> and be able to control the actions of actors elsewhere on the internet.
>
> What would this 'smarter' replacement do, given what happened "not so
> long ago"?

I am currently studying "AI" pattern-recognition techniques.
So far as I can surmise, distributed attacks seem to follow
certain *patterns*, also tend to re-use undefended IP addresses.
These are things an "AI" can be trained to detect - and then
train itself to do even better.

Any human can look at a log or two and say "Attack !" - IMHO
The System ought to be able to do that by itself, and learn
and educate other systems.

This is NOT far from the existing concept of SPAM blacklists
but I want slightly more general, and evolving, rules.

But you don't have to worry about any of this ... everything's
cool ... that 50 year old interface is Just Fine ...........

[Richard Kettlewell]

"26C.Z969" <26C....@noaada.net> writes:
> Nevermind, I will just write my own.

Perhaps you can explain how it will differ from SSH. To make it a
concrete question: how will the key exchange process differ?

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

[Computer Nerd Kev]

26C.Z969 <26C....@noaada.net> wrote:
> On 12/17/22 9:21 AM, Rich wrote:
>> What would this 'smarter' replacement do, given what happened "not so
>> long ago"?
>
> I am currently studying "AI" pattern-recognition techniques.
> So far as I can surmise, distributed attacks seem to follow
> certain *patterns*, also tend to re-use undefended IP addresses.
> These are things an "AI" can be trained to detect - and then
> train itself to do even better.
>
> Any human can look at a log or two and say "Attack !" - IMHO
> The System ought to be able to do that by itself, and learn
> and educate other systems.

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. But I don't see how those ways can be reliable - it can
only end up blocking genuine users who happen to pop up in an IP
range that's also used by attackers, or who'se software
configuration happens to look like an attacker's. That in turn is
likely to cause more trouble than a brute-force attack would have.

I don't see how a human looking at logs is supposed to solve this
problem, let alone an AI.

> This is NOT far from the existing concept of SPAM blacklists
> but I want slightly more general, and evolving, rules.

Yeah exactly, it would make SSH log-in as hopelessly unreliable as
email delivery. Oh wait, you think SPAM blacklists _are_ actually
smart...

[26C.Z969]

On 12/28/22 4:37 PM, Computer Nerd Kev wrote:
> 26C.Z969 <26C....@noaada.net> wrote:
>> On 12/17/22 9:21 AM, Rich wrote:
>>> What would this 'smarter' replacement do, given what happened "not so
>>> long ago"?
>>
>> I am currently studying "AI" pattern-recognition techniques.
>> So far as I can surmise, distributed attacks seem to follow
>> certain *patterns*, also tend to re-use undefended IP addresses.
>> These are things an "AI" can be trained to detect - and then
>> train itself to do even better.
>>
>> Any human can look at a log or two and say "Attack !" - IMHO
>> The System ought to be able to do that by itself, and learn
>> and educate other systems.
>
> 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.

For LOW-traffic use, stuff like port-knocking might suffice.
But when you HAVE to make room for a lot of users then the
situation becomes rather grim.

As noted early on however, access via SSH is maybe no
longer the most popular way to access a remote system.
LOTS of "server management" apps using https for
encryption - inc SolarWinds - takes a far more web-based
approach. Others use rather standard alternative ports -
and the little bots know all about them.

Hmmm ... maybe the thread should have been titled
"Is SSH Even Worth It Anymore ?" :-)

> But I don't see how those ways can be reliable - it can
> only end up blocking genuine users who happen to pop up in an IP
> range that's also used by attackers, or who'se software
> configuration happens to look like an attacker's. That in turn is
> likely to cause more trouble than a brute-force attack would have.
>
> I don't see how a human looking at logs is supposed to solve this
> problem, let alone an AI.

A human can SEE it ... "solving" it is something else entirely.

My HOPE is that there are patterns to such attacks, and "AI"
at this juncture is very good at spotting patterns. What
IP addresses are used, what frequency are they used, what
quirks in the auth process, any geo-relevant aspects ???

>> This is NOT far from the existing concept of SPAM blacklists
>> but I want slightly more general, and evolving, rules.
>
> Yeah exactly, it would make SSH log-in as hopelessly unreliable as
> email delivery. Oh wait, you think SPAM blacklists _are_ actually
> smart...

I rarely have problems logging into mail servers ...

SPAM blacklists are "quasi-smart" - and DO block rather
a lot of SPAM sources. I see this in the mail server logs
every day. However I'm not sure how AUTOMATED they are
behind the scenes. Who/how-many update the databases
and say "THESE people are SPAMMERS" ? I've even seen
those blacklists ABUSED ... fake reports designed to
hurt Company-X. Getting yourself OFF those blacklists
can be a chore ... and if VadeSecure hates you then
you're in deep shit.

I'm looking into finding the abovementioned kinds of
patterns to big bot attacks - and that "intelligence"
COULD be dynamically updated, shared to all. Even
the web-based remote-access methods can be afflicted
by a zillion-bot attack, so this isn't JUST an SSH thing.

But I'm not gonna have it by the end of the week.

MAYBE this thread will prompt OTHERS to look into
this stuff ? "AI" is not my strong suite and it's
gonna take awhile. OTHERS are really into it though.

[26C.Z969]

On 12/18/22 6:59 PM, Carlos E. R. wrote:
> On 19/12/2022 00.47, Andreas Kohlbach wrote:
>> On Sun, 18 Dec 2022 23:35:23 +0100, Carlos E. R. wrote:
>>>
>>> On 18/12/2022 02.13, Andreas Kohlbach wrote:
>>>>
>>>> I was referring to "can fill the filesystem".
>>>
>>> Yes, rotating logs takes care of that. But the issue of too much noise
>>> remains.
>>
>> The typical Linux user of today can ignore the noise. Ignore your logs,
>> unless you feel something is not right.
>
> I work the other way:
> I check the logs to see if there is something wrong :-)

Indeed ! :-)

The "Everything *SEEMS* OK" approach is the short path
to disaster.

All the while the little termites are chewing-away at
yer foundations .......

Every day, sometimes twice a day, I look at the mail
server logs, the firewall logs and SSH logs. Very
often things are NOT as safe and secure as they *seem*.

Checked the firewall logs Xmas evening - and yep, over
4000 tries from a (fortunately narrow) range of addresses
(DigitalOcean, of course, meaning "probably Russians")
running linearly up the port spectrum with multiple kinds
of login protocols to maybe figure out what was there.
Probably an nmap or related sort of scan. Even included
RTSP. They got a /16 scale block. But everything *seemed ok* -
until you LOOKED. Once they'd found what they wanted they'd
have proceeded with the brute-force attacks on the 'hot'
ports for hours/days/weeks/months ...... it ain't humans,
it's bots - they are legion and they never need to sleep.

SSH can do a "login message" - point to a file. Mine
delivers a 8k long "message" including all sorts of
words that you'd kinda expect if you were trying to
log in. MAYbe it confuses bots, makes 'em send their
auth tries too soon ... maybe. Doesn't hurt anything.

[26C.Z969]

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 ?

[Robert Riches]

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
spamt...@jacob21819.net
(Yes, that is one of my email addresses.)

[The Natural Philosopher]

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

[The Natural Philosopher]

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

[Charlie Gibbs]

On 2022-12-30, The Natural Philosopher <t...@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.
\ / <cgi...@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.

[The Natural Philosopher]

On 30/12/2022 19:09, Charlie Gibbs wrote:
> On 2022-12-30, The Natural Philosopher <t...@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)

[26C.Z969]

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

[26C.Z969]

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.

[26C.Z969]

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

[26C.Z969]

On 12/30/22 2:09 PM, Charlie Gibbs wrote:
> On 2022-12-30, The Natural Philosopher <t...@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.

[Charlie Gibbs]

On 2022-12-31, 26C.Z969 <26C....@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.