On 12/18/22 8:21 AM, Marc Haber wrote:
> "Carlos E. R." <robin_listas@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.

On 12/17/22 7:59 AM, Robert Heller wrote:
> At Sat, 17 Dec 2022 02:31:12 -0500 "26C.Z969" <26C.Z969@noaada.net> wrote:
>
>>
>> On 12/16/22 3:44 PM, Marc Haber wrote:
>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> The Natural Philosopher <tnp@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.
>
> 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?

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.

On Sun, 18 Dec 2022 21:08:12 -0500, 26C.Z969 <26C.Z969@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

26C.Z969 <26C.Z969@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!

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

"26C.Z969" <26C.Z969@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/

"26C.Z969" <26C.Z969@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/

On 19/12/2022 00:12, Roger Blake wrote:
> On 2022-12-16, The Natural Philosopher <tnp@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

On 19/12/2022 01:57, 26C.Z969 wrote:
> On 12/18/22 7:02 AM, The Natural Philosopher wrote:
>> On 18/12/2022 11:16, Richard Kettlewell wrote:
>>> "Carlos E. R." <robin_listas@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.
>>>
>> 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.
>
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.

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

Gospel of St. Mathew 15:14

On 19/12/2022 11.05, Richard Kettlewell wrote:
> "26C.Z969" <26C.Z969@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.

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.

On 19/12/2022 10:05, Richard Kettlewell wrote:
> "26C.Z969" <26C.Z969@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.
>
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.

On 19/12/2022 05:30, David W. Hodgins wrote:
> On Sun, 18 Dec 2022 21:08:12 -0500, 26C.Z969 <26C.Z969@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

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

On 19/12/2022 03.08, 26C.Z969 wrote:
> On 12/18/22 8:21 AM, Marc Haber wrote:
>> "Carlos E. R." <robin_listas@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.

On 16/12/2022 18:21, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@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.

On 19/12/2022 15:46, Pancho wrote:
> On 16/12/2022 18:21, Richard Kettlewell wrote:
>> The Natural Philosopher <tnp@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

On 12/19/22 12:30 AM, David W. Hodgins wrote:
> On Sun, 18 Dec 2022 21:08:12 -0500, 26C.Z969 <26C.Z969@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.

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.

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_listas@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.

On 12/19/22 6:26 AM, The Natural Philosopher wrote:
> On 19/12/2022 05:30, David W. Hodgins wrote:
>> On Sun, 18 Dec 2022 21:08:12 -0500, 26C.Z969 <26C.Z969@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
>
> And it doesn't need an sshd on the far end to be effective, In fact not
> responding to it wont change the denial.

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

"Carlos E. R." <robin_listas@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/

Pancho <Pancho.Jones@proton.me> writes:
> On 16/12/2022 18:21, Richard Kettlewell wrote:
>> The Natural Philosopher <tnp@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 <invalid@invalid.invalid> writes:
> Pancho <Pancho.Jones@proton.me> writes:
>> On 16/12/2022 18:21, Richard Kettlewell wrote:
>>> The Natural Philosopher <tnp@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.

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/

The Natural Philosopher <tnp@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/

On Sat, 17 Dec 2022 08:58:58 +0000,
Richard Kettlewell <invalid@invalid.invalid> wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
> > Richard Kettlewell <invalid@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 <theise@panix.com> West Lafayette, IN, USA

Ted Heise <theise@panix.com> writes:
> Richard Kettlewell <invalid@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/

On Tue, 20 Dec 2022 16:14:51 +0000,
Richard Kettlewell <invalid@invalid.invalid> wrote:
> Ted Heise <theise@panix.com> writes:
> > Richard Kettlewell <invalid@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

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

On 12/19/22 5:05 AM, Richard Kettlewell wrote:
> "26C.Z969" <26C.Z969@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.