I don't see any attempts for VMS.

I like working with it on Linux. What are some VMS alternatives?

On 4/7/2023 10:01 AM, plugh wrote:
> I don't see any attempts for VMS.
>
> I like working with it on Linux. What are some VMS alternatives?

You mean https://github.com/ossec/ossec-hids ?

For VMS itself then I suspect most people just use the
audit log directly.

It would probably be interesting to integrate that (audit log)
into ossec, because ossec already know how to process some
log files that are not VMS specific but may exist on VMS
like Apache logs and combining information could be
valuable.

Arne

On Friday, April 7, 2023 at 3:32:31 PM UTC-7, Arne Vajhøj wrote:
> On 4/7/2023 10:01 AM, plugh wrote:
> > I don't see any attempts for VMS.
> >
> > I like working with it on Linux. What are some VMS alternatives?
> You mean https://github.com/ossec/ossec-hids ?
Yes.

> For VMS itself then I suspect most people just use the
> audit log directly.
.... which probably doesn't include the "active response" component. Without automation, issuing such responses manually is probably a non-starter. ossec's response subsystem is what I'm looking at for VMS. I think all that's necessary for the "hids" subsystem is to mount a VMS log directory in *nix. The parser is available now under the ossec server subsystem.

> It would probably be interesting to integrate that (audit log)
> into ossec, because ossec already know how to process some
> log files that are not VMS specific but may exist on VMS
> like Apache logs and combining information could be
> valuable.
I'm not going to underestimate the work to build an ossec agent. I'd like think it would mesh well with VMS customer needs. It would involve the usual pain porting *nix code to VMS; which would be the ossec agent code.

The server/agent model works in that architecture's favor. The spin-offs from ossec-hids seem well on their way, but basically iterations on the same theme. I don't see an advantage to porting anything but the agent; which /should/ work with the various forks,

Right now, I'm just poking around. I saw some FT notice; which milestone piqued my interest.

On 4/7/2023 8:37 PM, plugh wrote:
> On Friday, April 7, 2023 at 3:32:31 PM UTC-7, Arne Vajhøj wrote:
>> On 4/7/2023 10:01 AM, plugh wrote:
>>> I don't see any attempts for VMS.
>>>
>>> I like working with it on Linux. What are some VMS alternatives?
>> You mean https://github.com/ossec/ossec-hids ?
> Yes.
>
>> For VMS itself then I suspect most people just use the
>> audit log directly.
>
> ... which probably doesn't include the "active response" component.
> Without automation, issuing such responses manually is probably a
> non-starter. ossec's response subsystem is what I'm looking at for
> VMS.

So ossec does not just detect intrusion but take action?

What would the actions be?

(I don't know the product)

VMS already block access if its intrusion detection get triggered.

> I think all that's necessary for the "hids" subsystem is to
> mount a VMS log directory in *nix. The parser is available now under
> the ossec server subsystem.
I am not sure that NFS mounting the directories where the critical
log files on VMS reside would be improving security.

>> It would probably be interesting to integrate that (audit log)
>> into ossec, because ossec already know how to process some
>> log files that are not VMS specific but may exist on VMS
>> like Apache logs and combining information could be
>> valuable.

> I'm not going to underestimate the work to build an ossec agent. I'd
> like think it would mesh well with VMS customer needs. It would
> involve the usual pain porting *nix code to VMS; which would be the
> ossec agent code.
>
> The server/agent model works in that architecture's favor. The
> spin-offs from ossec-hids seem well on their way, but basically
> iterations on the same theme. I don't see an advantage to porting
> anything but the agent; which /should/ work with the various forks,
As usual with open source in the end it will depend on whether
there are people willing to put in some hours.

Arne

On Saturday, April 8, 2023 at 9:55:49 AM UTC-7, Arne Vajhøj wrote:
> On 4/7/2023 8:37 PM, plugh wrote:
> > On Friday, April 7, 2023 at 3:32:31 PM UTC-7, Arne Vajhøj wrote:
> >> On 4/7/2023 10:01 AM, plugh wrote:
> >>> I don't see any attempts for VMS.
> >>>
> >>> I like working with it on Linux. What are some VMS alternatives?
> >> You mean https://github.com/ossec/ossec-hids ?
> > Yes.
> >
> >> For VMS itself then I suspect most people just use the
> >> audit log directly.
> >
> > ... which probably doesn't include the "active response" component.
> > Without automation, issuing such responses manually is probably a
> > non-starter. ossec's response subsystem is what I'm looking at for
> > VMS.
> So ossec does not just detect intrusion but take action?
>
> What would the actions be?
>
> (I don't know the product)
>
> VMS already block access if its intrusion detection get triggered.

Agreed. I'd forgotten about VMS intrusion detection and response; which works for login sessions and is one aspect. You can probably work out other intrusions: email, web... There's also file monitoring which is probably there as well. You'd mentioned them earlier.
The ossec actions include the equivalent blocking of unauthorized login attempts (via nft or iptables) as well as blocks for unauthorized URL access and unauthorized email access. The list of intrusions and responses is limited by what you can log and your imagination.
> > I think all that's necessary for the "hids" subsystem is to
> > mount a VMS log directory in *nix. The parser is available now under
> > the ossec server subsystem.
> I am not sure that NFS mounting the directories where the critical
> log files on VMS reside would be improving security.

I disagree. I'm sure there's a way to safely mount disks R/O remotely even under VMS; which techniques depend on your definition of "secure". If that's what you're proposing for not researching porting the server architecture, fine. If VMS is too spavined to handle connections from a *nix server than this topic isn't worth discussing.

On 4/8/2023 1:52 PM, plugh wrote:
> On Saturday, April 8, 2023 at 9:55:49 AM UTC-7, Arne Vajhøj wrote:
>> On 4/7/2023 8:37 PM, plugh wrote:
>>> I think all that's necessary for the "hids" subsystem is to
>>> mount a VMS log directory in *nix. The parser is available now under
>>> the ossec server subsystem.
>> I am not sure that NFS mounting the directories where the critical
>> log files on VMS reside would be improving security.
>
> I disagree. I'm sure there's a way to safely mount disks R/O remotely
> even under VMS; which techniques depend on your definition of
> "secure". If that's what you're proposing for not researching porting
> the server architecture, fine. If VMS is too spavined to handle
> connections from a *nix server than this topic isn't worth
> discussing.
security.audit$journal, accountng.dat and various log files
are in sys$manager. RDB put a log file in SYS$SYSTEM.
Apache log files are in APACHE$SPECIFIC:[LOGS], which is
disk:[SYS0.SYSCOMMON.APACHE.SPECIFIC.node.LOGS].

I do not like the idea of NFS mounting those directories
not even readonly with appropriate access control - too risky
that some critical information could leak out that way.

Another way to to get information over to ossec has to be found.
IMHO.

Arne

On Saturday, April 8, 2023 at 11:35:17 AM UTC-7, Arne Vajhøj wrote:
> On 4/8/2023 1:52 PM, plugh wrote:
> > On Saturday, April 8, 2023 at 9:55:49 AM UTC-7, Arne Vajhøj wrote:
> >> On 4/7/2023 8:37 PM, plugh wrote:
> >>> I think all that's necessary for the "hids" subsystem is to
> >>> mount a VMS log directory in *nix. The parser is available now under
> >>> the ossec server subsystem.
> >> I am not sure that NFS mounting the directories where the critical
> >> log files on VMS reside would be improving security.
> >
> > I disagree. I'm sure there's a way to safely mount disks R/O remotely
> > even under VMS; which techniques depend on your definition of
> > "secure". If that's what you're proposing for not researching porting
> > the server architecture, fine. If VMS is too spavined to handle
> > connections from a *nix server than this topic isn't worth
> > discussing.
> security.audit$journal, accountng.dat and various log files
> are in sys$manager. RDB put a log file in SYS$SYSTEM.
> Apache log files are in APACHE$SPECIFIC:[LOGS], which is
> disk:[SYS0.SYSCOMMON.APACHE.SPECIFIC.node.LOGS].
>
> I do not like the idea of NFS mounting those directories
> not even readonly with appropriate access control - too risky
> that some critical information could leak out that way.
>
> Another way to to get information over to ossec has to be found.
> IMHO.
>
> Arne

Can we limn that fear?

On Saturday, April 8, 2023 at 12:28:04 PM UTC-7, plugh wrote:
> On Saturday, April 8, 2023 at 11:35:17 AM UTC-7, Arne Vajhøj wrote:
> > On 4/8/2023 1:52 PM, plugh wrote:
> > > On Saturday, April 8, 2023 at 9:55:49 AM UTC-7, Arne Vajhøj wrote:
> > >> On 4/7/2023 8:37 PM, plugh wrote:
> > >>> I think all that's necessary for the "hids" subsystem is to
> > >>> mount a VMS log directory in *nix. The parser is available now under
> > >>> the ossec server subsystem.
> > >> I am not sure that NFS mounting the directories where the critical
> > >> log files on VMS reside would be improving security.
> > >
> > > I disagree. I'm sure there's a way to safely mount disks R/O remotely
> > > even under VMS; which techniques depend on your definition of
> > > "secure". If that's what you're proposing for not researching porting
> > > the server architecture, fine. If VMS is too spavined to handle
> > > connections from a *nix server than this topic isn't worth
> > > discussing.
> > security.audit$journal, accountng.dat and various log files
> > are in sys$manager. RDB put a log file in SYS$SYSTEM.
> > Apache log files are in APACHE$SPECIFIC:[LOGS], which is
> > disk:[SYS0.SYSCOMMON.APACHE.SPECIFIC.node.LOGS].
> >
> > I do not like the idea of NFS mounting those directories
> > not even readonly with appropriate access control - too risky
> > that some critical information could leak out that way.
> >
> > Another way to to get information over to ossec has to be found.
> > IMHO.
> >
> > Arne
> Can we limn that fear?

I retract that question. I have a misunderstanding of the architecture.
The server does not need access to the agent's alert sources.