From Newsgroup: comp.os.vms

Hello,

I am doing investigation about security for "latecomers" VMS users (Vax, Alpha, Itanium on HP licence).

It seems being a not-so-little number of users. And for them, to adapt
to the fast cycles about security (SSH, SSL for example) is a challenge.

I know the Process Software offer for that, able to work with everything
on VMS. Are there other offers, methods, Open Source initiatives...?

Every idea, information welcomed.

G|-rard Calliet
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-02-06, gcalliet <gerard.calliet@pia-sofer.fr> wrote:

Hello,

I am doing investigation about security for "latecomers" VMS users (Vax, Alpha, Itanium on HP licence).

It seems being a not-so-little number of users. And for them, to adapt
to the fast cycles about security (SSH, SSL for example) is a challenge.

I know the Process Software offer for that, able to work with everything
on VMS. Are there other offers, methods, Open Source initiatives...?

Every idea, information welcomed.

Security is a process and a mindset, not a tool.

Tools are required, but they cannot be used as a replacement for a security-driven process and mindset.

For example, how do these sites handle security internally at the moment ? Strong passwords, only allow encrypted communications on the local network, auditing, disabling of old accounts, keeping up to date on patches, etc ?

That last one is a good example: you can't just install a tool and then
call it "job done". You have to continually keep things up to date.
For one specific example, it might be interesting to see if the patch
for my DCL CVE has been installed on these sites or that a suitable
workaround has been implemented.

To repeat: security is a process and a mindset, not a tool. Tools are
only a part of the overall process.

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

From Newsgroup: comp.os.vms


On 2/6/26 3:31 AM, gcalliet wrote:

Hello,

I am doing investigation about security for "latecomers" VMS users (Vax, Alpha, Itanium on HP licence).

It seems being a not-so-little number of users. And for them, to adapt
to the fast cycles about security (SSH, SSL for example) is a challenge.

I know the Process Software offer for that, able to work with everything
on VMS. Are there other offers, methods, Open Source initiatives...?

Every idea, information welcomed.

If they are on recent enough Alpha or Itanium, they can probably build
current OpenSSL from source. No, I don't know what "recent enough"
would be exactly.

They could approach VSI and ask them to offer their port of OpenSSH as a separate product for HP versions of VMS. But it's probably easier just
going to Process Software, who already has the capability.

Since not touching the systems seems to be a priority (otherwise why run
VAX or pre-VSI releases?), it might be easier to change what's around
the systems, such as with a hardware proxy. It could be as simple as a Raspberry Pi with two NICs, one on the company network and configured to
allow only SSH with modern ciphers, the other connected to the VMS
system using Telnet. The VMS connection could just as easily be
something other than ethernet, such as serial. At which point you've
got a home-grown terminal server. Surely someone already sells terminal servers that do this, but I don't know the market.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2/6/2026 4:31 AM, gcalliet wrote:

I am doing investigation about security for "latecomers" VMS users (Vax, Alpha, Itanium on HP licence).

It seems being a not-so-little number of users. And for them, to adapt
to the fast cycles about security (SSH, SSL for example) is a challenge.

I know the Process Software offer for that, able to work with everything
on VMS. Are there other offers, methods, Open Source initiatives...?

Every idea, information welcomed.

That challenge is due to having an inconsistent system
strategy.

VMS VAX is 25+ years old. HP VMS Alpha and HP VMS Itanium
is 10+ years old.

I would assume that relative few recent software packages
supports those old OS versions.

An old OS with old software packages is likely to have
vulnerabilities.

There are two consistent approaches to that:

A) Always update to supported version. For VMS that
means VSI VMS On Alpha, Itanium or x86-64. And expect
VSI to close vulnerabilities when they are found.

B) Live by the "If it ain't broke, don't fix it" mantra.
Old OS, old TCP/IP, old everything. Security is not
provided by the system but around the system. Network
security, physical security etc. mitigate the risk from
the old stuff. This is not a great solution, but it may
be possible to achieve an acceptable security level. Not
all servers are running internet web servers.

But it sounds like they are asking for the inconsistent:

C) Keep the old OS as is without updating it, but always
update the software packages on it.

Difficult to provide. Many/most software packages will
not support very old VMS versions. For business reasons:
too few customers to make a business case. For technical
reasons: the software package need newer C RTL or
newer system services or something else new.

The right recommendation is: upgrade to VMS 9.x on x86-64.

The alternative somewhat questionable recommendation is:
keep what you have and build security around the systems.

If the reason for not upgrading is the issue of needing
to run on supported physical HW not a VM, then contact
VSI.

I know VSI has been presented with the issue many times
before. But there is a huge difference between "we think
it would be nice if VSI supported a few physical HW servers"
and "we are ready to buy N VMS license if you can support
physical HW servers".

If enough customers come with the latter, then VSI can
do the math and that there are extra money in supporting
physical HW servers.

Arne



--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2/6/2026 10:46 PM, Arne Vajh|+j wrote:

There are two consistent approaches to that:

A) Always update to supported version. For VMS that
-a-a means VSI VMS On Alpha, Itanium or x86-64. And expect
-a-a VSI to close vulnerabilities when they are found.

B) Live by the "If it ain't broke, don't fix it" mantra.
-a-a Old OS, old TCP/IP, old everything. Security is not
-a-a provided by the system but around the system. Network
-a-a security, physical security etc. mitigate the risk from
-a-a the old stuff. This is not a great solution, but it may
-a-a be possible to achieve an acceptable security level. Not
-a-a all servers are running internet web servers.

But it sounds like they are asking for the inconsistent:

C) Keep the old OS as is without updating it, but always
-a-a update the software packages on it.

Difficult to provide. Many/most software packages will
not support very old VMS versions. For business reasons:
too few customers to make a business case. For technical
reasons: the software package need newer C RTL or
newer system services or something else new.

For illustration let me show the same options for
desktop Windows and web browser.

A) Windows 11 with latest Edge/Chrome/FF.

B) Windows XP with some old IE or some old FF. Not
connected to internet - only used to access
intranet. Isolated network wise.

C) Windows XP with latest Edge/Chrome/FF.

Arne

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 6 Feb 2026 22:59:05 -0500, Arne Vajh|+j wrote:

A) Windows 11 with latest Edge/Chrome/FF.

Unfortunately, this scenario is having its own problems, what with the deteriorating quality of MicrosoftrCOs current software updates.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 06/02/2026 |a 17:38, Craig A. Berry a |-crit-a:

It could be as simple as a
Raspberry Pi with two NICs, one on the company network and configured to allow only SSH with modern ciphers, the other connected to the VMS
system using Telnet.

Thanks a lot for all your advice.

And now, because of the IA which makes prices increasingly expensive, I
have to make soon a stock of Rasperry PI :)

G|-rard Calliet
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-02-06 09:31:59 +0000, gcalliet said:

I am doing investigation about security for "latecomers" VMS users
(Vax, Alpha, Itanium on HP licence).

What are configurations coasting with un- or semi-maintained servers.

Yes, I am aware of industrial and SCADA environments, and regulatory environments, etc., and those typically don't get the sorts of security changes being discussed here. They get isolated.

Or they get upgraded to VSI OpenVMS x86-64, or get incrementally ported
over to Linux servers or such.

It seems being a not-so-little number of users. And for them, to adapt
to the fast cycles about security (SSH, SSL for example) is a challenge.

It's much less of a challenge when the gear is not locked onto old
hardware and old software versions.

The overhead of adding (backporting) and maintaining security increases
as time passes too, and the site usually attempts to isolate the older
and more vulnerable servers.

Or starts a modernization plan.

I know the Process Software offer for that, able to work with
everything on VMS.

I'd not want to try implementing modern security particularly with a
VAX, if performance is a consideration. VAX gear is ~35 years old, and
slow. Usual approach is isolation, locked-down firewalls, and ongoing
reviews.

Alpha and Itanium are less bad here, performance wise.

Are there other offers, methods, Open Source initiatives...?

Basically, no.

OpenSSL does have a recent / current port to OpenVMS, there are the WASD-related pieces, but pragmatically most things available on OpenVMS
are usually just very dated. Porting the code gets harder the further
back, too. There's other fun waiting too, probably including Xpdf and
JBIG2, and the ever-popular CVE-2013-4786 for iLO:

rCLHPSBHF02981 rev.4 - HPE Integrated Lights-Out 2, 3, 4, 5 (iLO 2, iLO
3, iLO 4, and iLO 5) and HPE Superdome Flex RMC - IPMI 2.0 RCMP+ Authentication Remote Password Hash Vulnerability (RAKP)rCY

TL;DR: ask the iLO nicely for a weakly-hashed IPMI password, then crack
it offline.

On at least some of these boxes, the iLO command that blocks this
particular access:

MP:CM> sa -lanipmi d

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04197764

If you have HPE OneView around, also check: CVE-2025-37164

There are other vulnerabilities in some of the older versions of some
HP/HPE apps for OpenVMS, too. Fixes never got ported. Some I've
verified vulnerable from proof-of-concepts.

Usual recommendation: Segment and restrict access to these OpenVMS
boxes ("don't expose OpenVMS to the internet", etc), disable IPMI iLO
access, set up a bastion host, etc. Get going on a modernization or
migration plan.

I've done some app retrofits here too, such as removing telnet
connections that had failed audits, replacing those with TLS
connections. But that was not on VAX.
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 12/02/2026 |a 02:10, Stephen Hoffman a |-crit-a:

On 2026-02-06 09:31:59 +0000, gcalliet said:

I am doing investigation about security for "latecomers" VMS users
(Vax, Alpha, Itanium on HP licence).

What are configurations coasting with un- or semi-maintained servers.

Yes, I am aware of industrial and SCADA environments, and regulatory environments, etc., and those typically don't get the sorts of security changes being discussed here. They get isolated.

Or they get upgraded to VSI OpenVMS x86-64, or get incrementally ported
over to Linux servers or such.

It seems being a not-so-little number of users. And for them, to adapt
to the fast cycles about security (SSH, SSL for example) is a challenge.

It's much less of a challenge when the gear is not locked onto old
hardware and old software versions.

The overhead of adding (backporting) and maintaining security increases
as time passes too, and the site usually attempts to isolate the older
and more vulnerable servers.

Or starts a modernization plan.

I know the Process Software offer for that, able to work with
everything on VMS.

I'd not want to try implementing modern security particularly with a
VAX, if performance is a consideration. VAX gear is ~35 years old, and
slow. Usual approach is isolation, locked-down firewalls, and ongoing reviews.

Alpha and Itanium are less bad here, performance wise.

Are there other offers, methods, Open Source initiatives...?

Basically, no.

OpenSSL does have a recent / current port to OpenVMS, there are the WASD-related pieces, but pragmatically most things available on OpenVMS
are usually just very dated.-a Porting the code gets harder the further back, too. There's other fun waiting too, probably including Xpdf and
JBIG2, and the ever-popular CVE-2013-4786 for iLO:

rCLHPSBHF02981 rev.4 - HPE Integrated Lights-Out 2, 3, 4, 5 (iLO 2, iLO 3, iLO 4, and iLO 5) and HPE Superdome Flex RMC - IPMI 2.0 RCMP+
Authentication Remote Password Hash Vulnerability (RAKP)rCY

TL;DR: ask the iLO nicely for a weakly-hashed IPMI password, then crack
it offline.

On at least some of these boxes, the iLO command that blocks this
particular access:

MP:CM> sa -lanipmi d

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04197764

If you have HPE OneView around, also check: CVE-2025-37164

There are other vulnerabilities in some of the older versions of some
HP/HPE apps for OpenVMS, too. Fixes never got ported. Some I've verified vulnerable from proof-of-concepts.

Usual recommendation: Segment and restrict access to these OpenVMS boxes ("don't expose OpenVMS to the internet", etc), disable IPMI iLO access,
set up a bastion host, etc. Get going on a modernization or migration plan.

I've done some app retrofits here too, such as removing telnet
connections that had failed audits, replacing those with TLS
connections. But that was not on VAX.

Great thanks for these ideas.

And as usual, the issue is between the "must" and the "can".

G|-rard Calliet
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 06/02/2026 |a 17:38, Craig A. Berry a |-crit-a:

On 2/6/26 3:31 AM, gcalliet wrote:

Hello,

I am doing investigation about security for "latecomers" VMS users
(Vax, Alpha, Itanium on HP licence).

It seems being a not-so-little number of users. And for them, to adapt
to the fast cycles about security (SSH, SSL for example) is a challenge.

I know the Process Software offer for that, able to work with
everything on VMS. Are there other offers, methods, Open Source
initiatives...?

Every idea, information welcomed.

If they are on recent enough Alpha or Itanium, they can probably build current OpenSSL from source.-a No, I don't know what "recent enough"
would be exactly.

They could approach VSI and ask them to offer their port of OpenSSH as a separate product for HP versions of VMS. But it's probably easier just
going to Process Software, who already has the capability.

Since not touching the systems seems to be a priority (otherwise why run
VAX or pre-VSI releases?), it might be easier to change what's around
the systems, such as with a hardware proxy.-a It could be as simple as a Raspberry Pi with two NICs, one on the company network and configured to allow only SSH with modern ciphers, the other connected to the VMS
system using Telnet.-a The VMS connection could just as easily be
something other than ethernet, such as serial.-a At which point you've
got a home-grown terminal server.-a Surely someone already sells terminal servers that do this, but I don't know the market.

Hello,

I am not at all a good programmer for internet. I was specialized on
internal programmation, and I don't know why, I have always ignored
everything about the network.

So: """La Cigale, ayant chant|-
Tout l'|et|-,
Se trouva fort d|-pourvue
Quand la bise fut venue."""
Jean de La Fontaine La cigale et la fourmi. (https://www.frenchtoday.com/french-poetry-reading/poem-la-cigale-et-la-fourmi-la-fontaine-audio/)

Have you some tracks for me doing this home-grown terminal server with
Raspery Pi. I do like the idea, and getting the hardware is simple. But
except for the term proxy, of wich I have some idea - but it is worth
only for web access - I'm very far from just the beginning of the operation.

Some questions from an ignorant: how transfering a ssh (external)
session to a telnet or serial (VMS) session? how the ssh session on the
Pi knows about the login/password on VMS?

On all that I think you have much more intuition than me, and perhaps
some way to get documentation or even contacts.

Everything you could explain me should be very interesting for me. If I
get some tracks, I'll invest energy and become less ignorant about the network.

If you have some time for that I should be very gratefull.

Best regards, and thanks again,

G|-rard Calliet
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 12 Feb 2026 18:34:19 +0100, gcalliet wrote:

Some questions from an ignorant: how transfering a ssh (external)
session to a telnet or serial (VMS) session? how the ssh session on
the Pi knows about the login/password on VMS?

You need an SSH server on the remote host to accept connections from
an SSH client.

SSH can authenticate two ways: by a regular username/password login,
or by setting up a public/private key pair. On a *nix host, each user
can have a file ~/.ssh/authorized_keys, which contains one or more
public keys. Any client using a private key matching one of these
public keys is allowed to connect without a password.

I assume the VMS folks have worked out an equivalent to per-user
dotfiles, for holding config information like this.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-02-12 12:40:56 +0000, gcalliet said:

And as usual, the issue is between the "must" and the "can".

Rock versus Hard Place.

If you can't maintain your tools, you're headed for increasing costs
and increasing trouble.

Sooner or later the management strategy of deny, delay, deceive, and
distract enters remission and updates and migrations can ensue, or the
project implodes, or the business implodes.

When management seeks assignment of blame, best avoid being obviously
culpable when (when, not if) things go sideways. Paper trails,
retirement, prosecutorial cooperation, wealth, various ways to reduce
or avoid blame.

This having witnessed management deciding to fix problems, and projects
that went from inconceivable and impossible going into production
deployment with alacrity. And having witnessed breaches. And management firings. And insider crimes.

Here? Bastion hosts, network isolation, ongoing network scans for
shenanigans. And plans for and budgets for maintenance and upgrades. Otherwise, the scheduled downtime becomes unscheduled downtime.
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-02-12 17:34:19 +0000, gcalliet said:

I am not at all a good programmer for internet. I was specialized on internal programmation, and I don't know why, I have always ignored everything about the network.

These days, data security, encryption, debugging, telemetry, and
networking are at the core of most every major app, and the rest of the
app is built around that. Retrofitting is rCo as you are well aware rCo a
far larger project.

Have you some tracks for me doing this home-grown terminal server with Raspery Pi. I do like the idea, and getting the hardware is simple. But except for the term proxy, of wich I have some idea - but it is worth
only for web access - I'm very far from just the beginning of the
operation.

This would be the bastion host I'd mentioned. It can be running tmux or minicom or whatever other apps are minimally necessary. The connection
to the interior might be a network, or might be a serial connection.

https://en.wikipedia.org/wiki/Bastion_host

Some questions from an ignorant: how transfering a ssh (external)
session to a telnet or serial (VMS) session? how the ssh session on the
Pi knows about the login/password on VMS?

VPN or ssh to the bastion host, then telnet or DECnet SET HOST or SET
HOST /DTE or xmodem or cu or whatever from there into the interior.

On all that I think you have much more intuition than me, and perhaps
some way to get documentation or even contacts.

There are businesses that provide security services for SCADA
environments, as well as digital forensics and incident response and
related.

I've been doing training on OpenVMS and related custom topics, such as covering how an experienced C programmer can program C on OpenVMS, or networking- or security-related topics.
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 12 Feb 2026 15:05:12 -0500, Stephen Hoffman wrote:

If you can't maintain your tools, you're headed for increasing costs
and increasing trouble.

Sooner or later the management strategy of deny, delay, deceive, and distract enters remission and updates and migrations can ensue, or the project implodes, or the business implodes.

Technical debt demands payback, sooner or later, one way or another.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Le 12/02/2026 |a 21:21, Stephen Hoffman a |-crit-a:

I've been doing training on OpenVMS and related custom topics, such as covering how an experienced C programmer can program C on OpenVMS, or networking- or security-related topics.

(Not any real project now, not any personal found, not very fluent in
engish, but)

Do you go giving theses trainings? How do you do it?

G|-rard Calliet
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-02-13 09:45:42 +0000, gcalliet said:

Le 12/02/2026 a 21:21, Stephen Hoffman a ocrita:

I've been doing training on OpenVMS and related custom topics, such as
covering how an experienced C programmer can program C on OpenVMS, or
networking- or security-related topics.

(Not any real project now, not any personal found, not very fluent in engish, but)

Do you go giving theses trainings? How do you do it?

I've provided on-site training, and less commonly remote training.

The training contents are customized to or are written specific to
customer requirements.

The OpenVMS C class (usually) doesn't teach C programming for instance,
but comprises a several-hours session for a few experienced C
developers needing to know where and why and how OpenVMS diverges from
common C patterns and practices, as well as platform-specific wrinkles
such as TLS networking support. The sorts of details that might or will confuse a UNIX or Linux developer.

Or the pieces and parts of and how to manage your particular
newly-installed AlphaServer or whatever box, for that matter.
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2/15/2026 11:17 AM, Stephen Hoffman wrote:

Or the pieces and parts of and how to manage your particular newly- installed AlphaServer or whatever box, for that matter.

"newly-installed AlphaServer" - sounds like a few days has gone
by since then ....

:-)

Arne

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-02-15 17:01:41 +0000, Arne Vajhoj said:

On 2/15/2026 11:17 AM, Stephen Hoffman wrote:

Or the pieces and parts of and how to manage your particular newly-
installed AlphaServer or whatever box, for that matter.

"newly-installed AlphaServer" - sounds like a few days has gone by
since then ....

:-)

Arne

Nope.
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10mlbpo$1ohf1$1@dont-email.me>,
Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:

On 2026-02-12 12:40:56 +0000, gcalliet said:

And as usual, the issue is between the "must" and the "can".

Rock versus Hard Place.

If you can't maintain your tools, you're headed for increasing costs
and increasing trouble.

It's always interesting how those policies designed to increase
stability tend to degrade it over time. Excessive caution about
upgrades and ongoing maintenance of software environments is the
clear cause of many problems.

I get regulatory issues and so on, and that "IT" is an immature
field with widely varying adherence to best practices. But
progress has been made, while much in the way of policy was
written in an earlier time, and written to the lowest common
denominator.

[snip]
Here? Bastion hosts, network isolation, ongoing network scans for >shenanigans. And plans for and budgets for maintenance and upgrades. >Otherwise, the scheduled downtime becomes unscheduled downtime.

Yup. Logging and auditing, too.

- Dan C.

--- Synchronet 3.21b-Linux NewsLink 1.2