[Info-vax] Using VMS for a web server

Jan-Erik Soderholm jan-erik.soderholm at telia.com
Tue Jun 9 05:40:38 EDT 2015


David Froble skrev den 2015-06-09 03:05:
> Jan-Erik Soderholm wrote:
>> David Froble skrev den 2015-06-08 19:21:
>>> Bill Gunshannon wrote:
>>>
>>>> Exactly.  I would never run a webserver on a machine that was intended
>>>> to do the data processing for the business.
>>>
>>> It would depend, but I'd usually agree with this.
>>
>> David, how many web servers have *you* setup and managed?
>> On VMS or on any platform?
>>
>> There isn't anything magic with a web server, it is just
>> another application out there. You can use it and you can
>> missuse it as much as you like. Just as any application.
>>
>>
>
> I don't have much experience with web servers.  Might remedy that in the
> future.  Might not.

It would at least give you some credibility. If that matters.

>
> If I have an application that does not need to have access to / from the
> internet, many issues no longer exist.
>
> A web server, by definition, is open to access from the internet.

Yes, if you include you own LAN and the clients into the concept
of "the internet". Most does not.

Why do you think that just becuse your VMS application server has
a web server installed it also have to have "all doors open" in
the firewall to the outside? Most places where there are VMS
system in production use also has a large internal network
where web based services can be of a great value.

There is nothing fundamental different between a web server
and any other "server". Telnet, ftp, smtp or whatever.

And yes, of course, you have to be a bit more carefull if you
want to offer web pages to "the world", but that is not anything
different on a VMS system then on any other system.

Right, maybe if you are running an outdated Apache server, but
not if you run an up-to-date WASD server which is usualy well
in line with the latest security bulletines.

And limiting the access frm the VMS box to the outside
also limits some other things like fetching software
kits using tools like FETCH_HTTP.

>
> What I do have experience with is services running on VMS that accept
> connections over the internet.  I'm in control of the design and
> communications in the services.

So you are through the config files in WASD.

> They do not use any known web server that hackers can be familiar with.

The usual take here is that "security by obscurity" is not
a good thing in itself.


> This means I can make them rather secure.  I
> control what happens with the incoming data.

So you are through the config files in WASD.
And WASD only routes the incomming request to the
right application process. You can also in the WASD
config setup "good hosts", authentication and so on.

Your application level doesn't have to deal with any
network related stuff, just the API against WASD.


>
> Now, TCP/IP is in use, and if there is a vulnerability in TCP/IP, it's a
> bit beyond my control.  It then becomes a problem for the people providing
> the TCP/IP software.  So, there are multiple levels involved, some you can
> control, and some outside your control.  Like Steve asks, "are you fully up
> to date with patches?"
>
> But as to the topic of separate systems.  If they are not the same, then
> even if a hacker gets into the system(s) running the web server(s), he's
> still not into your production system(s).  That can add an additional layer
> of security to your production system(s).  Any hacker would have to be able
> to get into the communications between systems, in order to affect your
> production system(s).

You have to weight that perceived extra security against a way more
flexible web integration with your applications.

>
> So yeah, it's something to consider.




More information about the Info-vax mailing list