Knock, knock, knockin' on ssh-session's door...
The internet has become a war zone!As soon as a new system is connected to the internet, the nefarious types will discover it and start banging away with port scanners and password crackers hoping to find a vulnerability. Rest assured that if you are using OpenVMS with only secure login (ssh) and your accounts have strong passwords, your system is fairly safe. However, this doesn't mean that these nafarious types won't try; they will! If you are using HP TCP/IP Services for OpenVMS, these port scans and password crack attacks can yield some undesirable consequences — the creation of gazillions of TCPIP$SSH processes.
The simplest and often the most effective way to thwart these port scan attacks on ssh is to move its port. ssh, by default, has been assigned to port 22. These nefarious types know this and, once they've discovered you have ssh configured on your system, they will try brute-force password attacks. Of course, most of these I have discovered are banging away with either root or administrator as the username. The first line of defense should be u>not to create accounts with either of the aforementioned as a username.
The problem here is not that they may get in, it is that they are trying to get in and, as a consequence, your system is now rife with TCPIP$SSH processes. These are consuming resources: memory for PCBs (process control blocks), UCBs (unit control blocks) and myriad other associated kernel structures, as well as consuming your process entry slots. The latter is a real concern as it poses a form of DoS (denial of service) should these TCPIP$SSH processes consume all of your system's process entry slots.
Whenever I configure an OpenVMS system, I take two steps to avoid these problems which the default TCPIP Services configuration presents. The first is to stop the attacks on port 22. How? Simple! Don't start ssh on port 22! ssh can run on any port; there is nothing sacred to ssh that requires it to be on port 22, so don't put it there. This is like the old anecdote of the patient saying, "Doctor, it hurts when I do this." and the doctor's reply, "Then, don't do it!" I'm the doctor and I'm telling you, "Don't do it!!!"
As the first line of defense, I usually pick a port number up in the high end of the ephemeral port region. This won't necessarily keep a port scanner from finding it. Trust me, it will; however, the scanner may not know what is running on this port. These nefarious types running the port scanner will have to look at their port scanner's logs to see the ssh server's response. Typically, they don't. They look for such servers on the well-known ports. Those, such as ssh, running on alternate ports seem to be deemed as running on system's where someone has taken some effort to secure them. Most of the nefarious types won't bother going after ssh on an alternate port.
The second line of defense is to limit the number of TCPIP$SSH processes (sessions) that can be instantiated with an ssh connection. If you have only one user that will log in using ssh, it doesn't make sense to leave ssh configured with unlimited connections. Limit the ssh server and you limit the number of runaway TCPIP$SSH processes which can be created if someone attempts to use a brute-force password attack against your system. The processes created in this fashion eventually die off in a brief while allowing any real users to access the system. What will typically happen is that the brute-password attack will hit up against the limit set on ssh sessions and give up. It may resume but empirical observation seem to be in favor of concluding that it will not, at least, not from the same source.
The following commands will change the default behavior of ssh as it comes configured out-of-th-box in HP TCPIP Services for OpenVMS. This example will move ssh to port 22000 and establishes a limit of 25 ssh sessions.
$ TCPIP DISABLE SERVICE SSH
$ DEFINE SYS$INPUT SYS$COMMAND
$ TCPIP SET NOSERVICE SSH
$ TCPIP SET SERVICE SSH /PORT=22000 /PROCESS=TCPIP$SSH /USER=TCPIP$SSH -
/FILE=TCPIP$SYSTEM:TCPIP$SSH_RUN.COM /PROTOCOL=TCP /LIMIT=25
$ TCPIP ENABLE SERVICE SSH
To access the OpenVMS system after this set of commands has been issued, the user will need to specify the port you have moved the ssh server to in the ssh command. This is typically done with the command line option
-p such as:
$ ssh -p 22000 myUsername@myVMShost.myDomain.com
All other command line switches, such as those for tunneling, will continue to function as long as the ssh command specified the new port.
If you use ssh, you're probably also aware that sftp comes along for the ride. If you move the ssh server port, you must also specify the new port when using sftp. A typical command construct for sftp with the remote ssh server operating on a non-standard port is: (assuming port 22000 as in the prior example)
$ sftp -oPort=22000 myUsername@myVMShost.myDomain.com
Frontpage
