The Question is:
This question regards securing open TCP/IP ports under OpenVMS Alpha, on both a
DS10L (primary server behind multiple firewalls) and a PWS500a that runs
identical software (development / crash test box, on the internet with no
I have turned off all services I deem unnecessary using TCPIP$CONFIG. However,
when I go to TCPIP> and execute the netstat -an command, I see multiple
CLOSE_WAIT and ESTABLISHED connections on the 500a on TCP port 135. I believe
these connections to be vi
rus-infected Windows machines randomly scanning the Internet, and establishing
a connection to my 500a. On my SNORT IDS box, I see that packets are exchanged
between the 'external' machine and the 500a. Data in these packets is minimal,
however. There is
no 'login', and typically no significant data passed... just a lingering
connection is established in the memory of the 500a. (I have seen a couple of
packets containing data that I would label as "suspicious" as to their
purpose, but was unable to ascert
ain exactly what they were doing.)
I have run SHOW SERVICE under TCPIP> - and I see no services using port 135.
However, the connections are still there.
I would like to know if there is a way under OpenVMS (aside from an external
firewall) to close port 135 - along with any other ports I see that I do not
The Answer is :
Use a firewall.
A firewall is cheap insurance, is effective, and -- due to its
dedicated nature, restricted access, and to the relatively small(er)
numbers of configuration changes likely -- is easier to maintain.
Multi-processing, multi-user general-purpose systems -- and
OpenVMS included here, as DEFCON9 proved -- can be secured.
The effort involved in the initial security configuration and -- and
this is the aspect that is commonly underestimated -- the effort that
is involved in maintaining the configuration security over typical
user activies, over software installations, and host reconfigurations,
is far from trivial. You have undoubtedly learned about the effort of
the first part, but the OpenVMS Wizard has found the on-going
maintenance of host-based security to be equally important, and far
The introduction of security vulnerabilities can be quite subtle,
of course. Vulnerabilities can arise due to user commands, due
to layered product installation, configuration or reconfiguration,
due to malicious or innocent actions of local users, and due to
unpatched vulnerabilities in the various operating system
components or within privileged or trusted product components.
Again, the OpenVMS Wizard recommends a dedicated firewall --
and -- while there are multi-user systems that can be stripped
down and configured as a firewall -- the available dedicated
and purpose-built good-quality (SPI-capable or better) firewall
boxes are supremely economical, particularly in comparison
to the host maintenance efforts on typically-active hosts.
Once you have a firewall, then look at host security, at open
ports, and at host configuration and maintenance requirements,
and at monitoring both the firewall and the host security.
Periodic probes of local security -- whether firewall or
host or a combination - are also recommended -- it is best
to break into your own system(s) first, and before others
gain access and cause direct (data deletion or corruption,
etc) or indirect (DDoS, reputation, exposure of sensitive
information, and the oft-neglected costs of simply verifying
system integrity and operations after a successful break-in)
A firewall is not complete insurance against attacks, of
course -- host-based security, network encryption, out-bound
firewalls and network security monitors can and do have
applications. A firewall is, however, an effective defense
against common threats.
Again, the OpenVMS Wizard recommends the use of a firewall.
Related topics include (4653), (5186), (7931), (8211), and
DECnet firewalls are discussed in (9050) and (9142).