|
HP OpenVMS Systemsask the wizard |
|
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 firewalling). 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 want open. Thanks, Andrew 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 more involved. 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) costs. 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 (9142). DECnet firewalls are discussed in (9050) and (9142).
|