30 Nov
2017
30 Nov
'17
12:26 p.m.
I have a microvax set up with VMS 5, running MULTINET (and decnet
locally). The server has a FQDN and after a while being exposed to the
WWW someone out there started using the server as an SMTP relay. I can
disable and clear the queue, but I'd like to block entirely this from
happening in the first place. I'd like to learn more about how this
happens in VMS.
Anyone have had this same problem before? I realize back when VMS 5 was
current it was not so much of an issue, but today it is. I am working on a
solution. I can envision a few ways including blocking the smtp relay port
from the firewall, but if possible I'd like to set
up a VMS Multinet
solution as a learning exercise.
I am open to suggestions, and once I find the solution I'll post it.
I understand that this kind of thing is not cookie cutter, there are
different levels one could address something like this. I have a comcast
business router, and one of the 5 IPs I have is NAT assigned to the
internal 10.1.10 port of the microvax.
This is the same machine I wrote about previously as with then, thanks for
your help. I find the best way to learn is on the actual hardware warts
and all.
Bill
30 Nov
30 Nov
3:28 p.m.
I have a microvax set up with VMS 5, running MULTINET (and decnet
locally). The server has a FQDN and after a while being exposed to the
WWW someone out there started using the server as an SMTP relay. I can
disable and clear the queue, but I'd like to block entirely this from
happening in the first place. I'd like to learn more about how this
happens in VMS.
Anyone have had this same problem before? I realize back when VMS 5 was
current it was not so much of an issue, but today it is. I am working on a
solution. I can envision a few ways including blocking the smtp relay port
from the firewall, but if possible I'd like to set up a VMS Multinet
solution as a learning exercise.
I had this problem about 25 years ago. I suspect lots of people did.
In the VMS world, networking stacks are separately packaged from the base
operating system and it is possible to install one or more of DECnet, TCP/IP,
X25 and various other networking products and have them all running
simultaneously.
VMS doesn't know or care about SMTP, the issue here is with Multinet which
seems to be what was installed to provide TCP/IP networking on your machine.
Multinet includes a basic SMTP server which can be used to move mail between
VMS MAIL and the internet. Very old versions of Multinet came with SMTP
relaying enabled because this is what the standards required at the time.
Later versions came with easy ways to disable SMTP relaying. Later still
versions shipped with SMTP relaying disabled out of the box when spammers
targetting open relays became a serious problem. More recently still,
Multinet comes with pretty much all of the TCP/IP servers it provides disabled
and requires the installer to enable the services they want, leaving less
opportunity for surprises when servers are running that nobody knew existed,
except the bad guys targetting them.
The Multinet SMTP server is pretty basic and people who are serious about
doing SMTP on VMS typically disable it and install a proper mailserver like
PMDF. That's my excuse for not knowing how to disable SMTP relaying in
Multinet. That and because it probably varies for different versions of
Multinet and you haven't said what version of Multinet you have. I used to
be one of the people supporting Multinet in this part of the world and I
seem to have inherited a stack of Multinet documentation for different old
versions so if I knew what version, I could probably look it up. I think the
documentation for the most recent couple of Multinet versions is on the
Multinet website:
http://www.process.com/psc/service-support/multinet-support/
Try the Adminstrator's guide or Adminstrator's reference.
I do however know how to disable the SMTP server in Multinet completely:
$ MULTINET CONFIGURE /SERVERS
SERVER-CONFIG> DISABLE SMTP
SERVER-CONFIG> RESTART
Configuration modified, do you want to save it first ? [YES]
Regards,
Peter Coghlan
1 Dec
1 Dec
5:44 a.m.
Off the cuff, I'd probably stand something else up and have it relay mail
to the VAX (I suspect you've already got machines available for this
purpose, ping me off-list if not). Have the VAX only accept connections
from whatever's doing the relaying. If you
can't get VMS or the smtpd to
restrict incoming connections, add a transparent
hardware firewall in
between. This is what I typically do when something old and probably
insecure has to be connected to the Internet -- proxy, relay, or otherwise
hide the actual server behind something modern.
Thanks,
Jonathan
On Thu, Nov 30, 2017 at 6:28 PM, Peter Coghlan via cctalk <
cctalk at classiccmp.org> wrote:
I have a microvax set up with VMS 5, running MULTINET (and decnet
locally). The server has a FQDN and after a while being exposed to the
WWW someone out there started using the server as an SMTP relay. I can
disable and clear the queue, but I'd like to block entirely this from
happening in the first place. I'd like to learn more about how this
happens in VMS.
Anyone have had this same problem before? I realize back when VMS 5 was
current it was not so much of an issue, but today it is. I am working
on a
solution. I can envision a few ways including
blocking the smtp relay
port
from the firewall, but if possible I'd like
to set up a VMS Multinet
solution as a learning exercise.
I had this problem about 25 years ago. I suspect lots of people did.
In the VMS world, networking stacks are separately packaged from the base
operating system and it is possible to install one or more of DECnet,
TCP/IP,
X25 and various other networking products and have them all running
simultaneously.
VMS doesn't know or care about SMTP, the issue here is with Multinet which
seems to be what was installed to provide TCP/IP networking on your
machine.
Multinet includes a basic SMTP server which can be used to move mail
between
VMS MAIL and the internet. Very old versions of Multinet came with SMTP
relaying enabled because this is what the standards required at the time.
Later versions came with easy ways to disable SMTP relaying. Later still
versions shipped with SMTP relaying disabled out of the box when spammers
targetting open relays became a serious problem. More recently still,
Multinet comes with pretty much all of the TCP/IP servers it provides
disabled
and requires the installer to enable the services they want, leaving less
opportunity for surprises when servers are running that nobody knew
existed,
except the bad guys targetting them.
The Multinet SMTP server is pretty basic and people who are serious about
doing SMTP on VMS typically disable it and install a proper mailserver like
PMDF. That's my excuse for not knowing how to disable SMTP relaying in
Multinet. That and because it probably varies for different versions of
Multinet and you haven't said what version of Multinet you have. I used to
be one of the people supporting Multinet in this part of the world and I
seem to have inherited a stack of Multinet documentation for different old
versions so if I knew what version, I could probably look it up. I think
the
documentation for the most recent couple of Multinet versions is on the
Multinet website:
http://www.process.com/psc/service-support/multinet-support/
Try the Adminstrator's guide or Adminstrator's reference.
I do however know how to disable the SMTP server in Multinet completely:
$ MULTINET CONFIGURE /SERVERS
SERVER-CONFIG> DISABLE SMTP
SERVER-CONFIG> RESTART
Configuration modified, do you want to save it first ? [YES]
Regards,
Peter Coghlan
5:39 p.m.
>
> The Multinet SMTP server is pretty basic and people who are serious
about
> doing SMTP on VMS typically disable it and
install a proper mailserver
like
> PMDF. That's my excuse for not knowing how
to disable SMTP relaying in
> Multinet. That and because it probably varies for different versions of
> Multinet and you haven't said what version of Multinet you have. I
used
to
> be one of the people supporting Multinet in this
part of the world and I
> seem to have inherited a stack of Multinet documentation for different
old
> versions so if I knew what version, I could
probably look it up. I
think
> the
> documentation for the most recent couple of Multinet versions is on the
> Multinet website:
>
> http://www.process.com/psc/service-support/multinet-support/
>
> Try the Adminstrator's guide or Adminstrator's reference.
>
> I do however know how to disable the SMTP server in Multinet completely:
>
> $ MULTINET CONFIGURE /SERVERS
> SERVER-CONFIG> DISABLE SMTP
> SERVER-CONFIG> RESTART
> Configuration modified, do you want to save it first ? [YES]
>
> Regards,
> Peter Coghlan
>
Peter,
Thanks I think this is what I need, just disable smtp within MULTINET. As
I said in my OP I prefer a VMS or MULTINET solution free of modern hardware
if possible, now that I know what is possible. I was curious to learn
what others did back in the day.
I have a script I run to clear the queue, but that's a pain and it lets
some relaying through.
Bill
30 Nov
30 Nov
10:20 p.m.
New subject: Nova 50 year celebration...
G'day fellow Nova'holics -
Next year the Nova computer will be 50 years old, and we am organizing a
celebration of this important part of minicomputer history. Nova
hardware and software designers, users and admirers can get initial
information at:
http://www.Nova-At-50.org
The celebration of a half-century will come around only once, so check
it out and sign up soon...
Bruce
-----
Bruce Ray
Wild Hare Computer Systems, Inc.
Boulder, Colorado USA
bkr at WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.org
1 Dec
1 Dec
5:48 p.m.
New subject: Nova 50 year celebration...
On 11/30/2017 10:20 PM, Bruce Ray via cctalk wrote:
G'day fellow Nova'holics -
Next year the Nova computer will be 50 years old, and we am organizing a
celebration of this important part of minicomputer history.? Nova
hardware and software designers, users and admirers can get initial
information at:
? http://www.Nova-At-50.org
The celebration of a half-century will come around only once, so check
it out and sign up soon...
Hey Bruce,
Did you invite Ed de Castro? He's still around.
Cheers,
Chuck
11:18 p.m.
New subject: Nova 50 year celebration...
Of course he was invited!
-----
Bruce Ray
Wild Hare Computer Systems, Inc.
Boulder, Colorado USA
bkr at WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.org
On 12/1/2017 6:48 PM, Chuck Guzis via cctalk wrote:
On 11/30/2017 10:20 PM, Bruce Ray via cctalk wrote:
G'day fellow Nova'holics -
Next year the Nova computer will be 50 years old, and we am organizing a
celebration of this important part of minicomputer history.? Nova
hardware and software designers, users and admirers can get initial
information at:
? http://www.Nova-At-50.org
The celebration of a half-century will come around only once, so check
it out and sign up soon...
Hey Bruce,
Did you invite Ed de Castro? He's still around.
Cheers,
Chuck
2 Dec
2 Dec
5:04 a.m.
New subject: Nova 50 year celebration...
On 2 December 2017 at 02:48, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
Did you invite Ed de Castro? He's still around.
What about Tracy Kidder? :-)
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Talk/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 ? ?R/WhatsApp/Telegram/Signal: +420 702 829 053
8:58 a.m.
New subject: Nova 50 year celebration...
Yup (again) - a personal invitation has been sent to Mr. Kidder.
Note that his book was about the MV, 10 years and 2 DG computer
generations after the Nova.
-----
Bruce Ray
Wild Hare Computer Systems, Inc.
Boulder, Colorado USA
bkr at WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.org
On 12/2/2017 6:04 AM, Liam Proven via cctalk wrote:
On 2 December 2017 at 02:48, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
Did you invite Ed de Castro? He's still around.
What about Tracy Kidder? :-)
9:10 a.m.
New subject: Nova 50 year celebration...
On 2 December 2017 at 17:58, Bruce Ray via cctalk <cctalk at classiccmp.org> wrote:
Yup (again) - a personal invitation has been sent to
Mr. Kidder.
Note that his book was about the MV, 10 years and 2 DG computer generations
after the Nova.
Aha, fair enough. My apologies -- I can only blame brain-fade. I
thought it was the Nova.
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Talk/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 ? ?R/WhatsApp/Telegram/Signal: +420 702 829 053
1:33 a.m.
On 11/30/17, 9:26 PM, "cctech on behalf of william degnan via cctech"
<cctech-bounces at classiccmp.org on behalf of cctech at classiccmp.org> wrote:
I have a microvax set up with VMS 5, running MULTINET
(and decnet
locally). The server has a FQDN and after a while being exposed to the
WWW someone out there started using the server as an SMTP relay. I can
disable and clear the queue, but I'd like to block entirely this from
happening in the first place. I'd like to learn more about how this
happens in VMS.
Anyone have had this same problem before? I realize back when VMS 5 was
current it was not so much of an issue, but today it is. I am working on
a
solution. I can envision a few ways including blocking the smtp relay
port
from the firewall, but if possible I'd like to set up a VMS Multinet
solution as a learning exercise.
I am open to suggestions, and once I find the solution I'll post it.
I understand that this kind of thing is not cookie cutter, there are
different levels one could address something like this. I have a comcast
business router, and one of the 5 IPs I have is NAT assigned to the
internal 10.1.10 port of the microvax.
This is the same machine I wrote about previously as with then, thanks for
your help. I find the best way to learn is on the actual hardware warts
and all.
Bill
Look at the SMTP_SERVER_REJECT file example here:
http://www.process.com/docs/multinet5_4/admin_guide/Ch15.htm.
It?s a set of rules that decide whether a message gets rejected (rule
ending in ?y?) or let through (rule ending in ?n?). You?d normally set
this up to first let through those emails you want, then reject everything
else at the end of the rules file.
1:50 a.m.
On 11/30/17, 9:26 PM, "cctech on behalf of william degnan via cctech"
<cctech-bounces at classiccmp.org on behalf of cctech at classiccmp.org> wrote:
I am not sure whether this method will work on the clearly elderly but
unspecified version of Multinet in use here.
I should also have suggested checking whether there are other TCP/IP services
running that may have issues. DNS in particular would be open to very serious
abuse affecting lots of innocent third parties on the internet if not brought
up to current patchlevels. NTP also springs to mind.
The easiest way to deal with all these issues comprehensively would probably
be to update the machine to the current version of Multinet (5.5). This is
not hard to do and is covered by the Multinet hobbyist license.
Regards,
Peter Coghlan.
I have a microvax set up with VMS 5, running
MULTINET (and decnet
locally). The server has a FQDN and after a while being exposed to the
WWW someone out there started using the server as an SMTP relay. I can
disable and clear the queue, but I'd like to block entirely this from
happening in the first place. I'd like to learn more about how this
happens in VMS.
Anyone have had this same problem before? I realize back when VMS 5 was
current it was not so much of an issue, but today it is. I am working on
a
solution. I can envision a few ways including blocking the smtp relay
port
from the firewall, but if possible I'd like to set up a VMS Multinet
solution as a learning exercise.
I am open to suggestions, and once I find the solution I'll post it.
I understand that this kind of thing is not cookie cutter, there are
different levels one could address something like this. I have a comcast
business router, and one of the 5 IPs I have is NAT assigned to the
internal 10.1.10 port of the microvax.
This is the same machine I wrote about previously as with then, thanks for
your help. I find the best way to learn is on the actual hardware warts
and all.
Bill
Look at the SMTP_SERVER_REJECT file example here:
http://www.process.com/docs/multinet5_4/admin_guide/Ch15.htm.
It?s a set of rules that decide whether a message gets rejected (rule
ending in ?y?) or let through (rule ending in ?n?). You?d normally set
this up to first let through those emails you want, then reject everything
else at the end of the rules file.
2:48 a.m.
Camiel,
Without sounding super negative (my day job as a security consultant let's
me do that enough...) I would be especially wary of connecting anything
with a 10 year old stack to the modern internet. The range of automatic
attacks based on what the state of the OS was when it was last patched is
staggering.
Can you NAT it behind something to not expose it directly? Can you run
proxies in front of it?
Doug
On 2 Dec. 2017 8:34 pm, "Camiel Vanderhoeven via cctech" <
cctech at classiccmp.org> wrote:
On 11/30/17, 9:26 PM, "cctech on behalf of
william degnan via cctech"
<cctech-bounces at classiccmp.org on behalf of cctech at classiccmp.org> wrote:
I have a microvax set up with VMS 5, running
MULTINET (and decnet
locally). The server has a FQDN and after a while being exposed to the
WWW someone out there started using the server as an SMTP relay. I can
disable and clear the queue, but I'd like to block entirely this from
happening in the first place. I'd like to learn more about how this
happens in VMS.
Anyone have had this same problem before? I realize back when VMS 5 was
current it was not so much of an issue, but today it is. I am working on
a
solution. I can envision a few ways including blocking the smtp relay
port
from the firewall, but if possible I'd like to set up a VMS Multinet
solution as a learning exercise.
I am open to suggestions, and once I find the solution I'll post it.
I understand that this kind of thing is not cookie cutter, there are
different levels one could address something like this. I have a comcast
business router, and one of the 5 IPs I have is NAT assigned to the
internal 10.1.10 port of the microvax.
This is the same machine I wrote about previously as with then, thanks for
your help. I find the best way to learn is on the actual hardware warts
and all.
Bill
Look at the SMTP_SERVER_REJECT file example here:
http://www.process.com/docs/multinet5_4/admin_guide/Ch15.htm.
It?s a set of rules that decide whether a message gets rejected (rule
ending in ?y?) or let through (rule ending in ?n?). You?d normally set
this up to first let through those emails you want, then reject everything
else at the end of the rules file.
6 Dec
6 Dec
10:34 a.m.
On Dec 2, 2017, at 5:48 AM, Doug Jackson via cctech
<cctech at classiccmp.org> wrote:
Camiel,
Without sounding super negative (my day job as a security consultant let's
me do that enough...) I would be especially wary of connecting anything
with a 10 year old stack to the modern internet. The range of automatic
attacks based on what the state of the OS was when it was last patched is
staggering.
That's true to a point. On the other hand, many attacks require that the machine is
running on Intel instruction set hardware, and most of them also depend on the OS being
Windows.
While bugs happen, the level of security competence applied by VMS engineering is quite
high compared to the usual "hack it till it no longer crashes" practice seen all
too often nowadays. That applies especially to network protocol implementations.
If the issue is design defects in the protocol specifications, such as may be found in
various revisions of SSL, then having a good OS is not a complete answer. Even there, it
can help; for example, I suspect that the "heartbreak" attack on older SSL
stacks, if it were operable on VMS, wouldn't get you very far because of OS and
instruction set differences. Certainly script kiddy attacks would not work.
paul
7 Dec
7 Dec
3:12 a.m.
Paul Koning wrote:
Security is very good on VMS, however, the Bind DNS server code for example
is dropped more or less as-is into products like TCP/IP Services for VMS and
Multinet. This brings in a bunch of vulnerabilities common to all other
platforms running this code. Attempting to exploit these vulnerabilities is
unlikely to gain any access to the host VMS system they are running on but
there is no defence against vulnerabilities which target systems other than
the host system over the network with denial of service attacks and there are
lots of these vulnerabilities. They are only fixed, worked around or whatever
in relatively recent versions of Bind and therefore only in relatively recent
versions of TCP/IP Services for VMS and Multinet. Similar issues may well
exist with other TCP/IP servers running on VMS.
There is no use in thinking that the bad guys will never find my one little old
server which runs only occasionally and is tucked away in my corner of the
internet either. They can and they will, just like the spammers can sniff out
the most obscure open mail relays and they continue to look for them long
after any sane person would persist. I see attempts to exploit various kinds
of vulnerability all the time on my VMS systems and many would succeed in
causing grief to others on the internet if I did not keep an eye on recent
vulnerabilities in the TCP/IP software I am running and keep patchlevels up to
date.
Whatever about vulnerabilities of our classic computer systems themselves,
can we please ensure that what is just a hobby for most of us is not
inadvertently causing problems for others on the internet?
Regards,
Peter Coghlan.
On Dec 2, 2017, at 5:48 AM, Doug Jackson via
cctech <cctech at classiccmp.org> wrote:
Camiel,
Without sounding super negative (my day job as a security consultant let's
me do that enough...) I would be especially wary of connecting anything
with a 10 year old stack to the modern internet. The range of automatic
attacks based on what the state of the OS was when it was last patched is
staggering.
That's true to a point. On the other hand, many attacks require that the
machine is running on Intel instruction set hardware, and most of them also
depend on the OS being Windows.
While bugs happen, the level of security competence applied by VMS
engineering is quite high compared to the usual "hack it till it no longer
crashes" practice seen all too often nowadays. That applies especially to
network protocol implementations.
If the issue is design defects in the protocol specifications, such as may
be found in various revisions of SSL, then having a good OS is not a
complete answer. Even there, it can help; for example, I suspect that the
"heartbreak" attack on older SSL stacks, if it were operable on VMS,
wouldn't get you very far because of OS and instruction set differences.
Certainly script kiddy attacks would not work.
paul
3 Dec
3 Dec
6:32 p.m.
I have a microvax set up with VMS 5, running MULTINET
(and decnet
locally). The server has a FQDN and after a while being exposed to the
WWW someone out there started using the server as an SMTP relay. I can
disable and clear the queue, but I'd like to block entirely this from
happening in the first place. I'd like to learn more about how this
happens in VMS.
Anyone have had this same problem before? I realize back when VMS 5 was
current it was not so much of an issue, but today it is. I am working on
a
solution. I can envision a few ways including blocking the smtp relay
port
from the firewall, but if possible I'd like to set up a VMS Multinet
solution as a learning exercise.
I am open to suggestions, and once I find the solution I'll post it.
I understand that this kind of thing is not cookie cutter, there are
different levels one could address something like this. I have a comcast
business router, and one of the 5 IPs I have is NAT assigned to the
internal 10.1.10 port of the microvax.
This is the same machine I wrote about previously as with then, thanks for
your help. I find the best way to learn is on the actual hardware warts
and all.
Bill
You should never use one-to-one NAT like that. You should only forward the
ports you need from the firewall to your server. In this case, I assume
you only need tcp/23 for telnet from the outside?
--
Pete Rittwage
6 Dec
6 Dec
7:26 a.m.
On Sun, Dec 03, 2017 at 09:32:35PM -0500, Pete Rittwage via cctech wrote:
[...]
You should never use one-to-one NAT like that. You should only forward the
ports you need from the firewall to your server. In this case, I assume
you only need tcp/23 for telnet from the outside?
Just in case: myself, I would rather ssh to firewall, and only from
there telnet to VAX. Unless all your computers behind firewall are
only for fun and you are ok to have any kind of stuff installed there
from anywhere in a world. Some could say to this that
VMS is hard to
get in because ... (fill in your preferred reaason) ... , and I
would
answer that one more fence does not hurt, whereas one less might.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola at bigfoot.com **
2338
days inactive
2345
days old
16 comments
11 participants
participants (11)
-
billdegnan＠gmail.com -
Bruce＠Wild-Hare.com -
camiel.vanderhoeven＠vmssoftware.com -
cclist＠sydex.com -
cctalk＠beyondthepale.ie -
dougatdoughq＠gmail.com -
lproven＠gmail.com -
paulkoning＠comcast.net -
peter＠rittwage.com -
rtomek＠ceti.pl -
systems.glitch＠gmail.com