DoS vs. SSH EAK

[James Becker]

Numerous invalid connection attempts to SSH are resulting in denials of service. Is there anything I can do about this, short of blocking all access to SSH?

First, here's the version info:
Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
on a Compaq AlphaServer ES45 Model 2 running OpenVMS V7.3-1

We're running the SSH EAK. The images identify their version as T5.4-11E.

Next, here are the losses of service, and the bits and pieces that suggest SSH has something to do with it...

The Alpha bugchecked at 23:12 Tuesday evening with INVEXCEPTN, Exception while above ASTDEL. It was in FGEDRIVER at the time, and the current image was TCPIP$NTP. A SHOW SUMMARY while examining the crash dump shows a few strange things. There were 64 processes running under the username TCPIP$SSH, 59 of them computable, 5 in LEF. I was expecting only one SSH session at that time. In addition, there were 45 other processes in COM state, including CONFIGURE, IPCACP, ERRFMT, OPCOM, AUDIT_SERVER, JOB_CONTROL, QUEUE_MANAGER, SECURITY_SERVER, SMISERVER, SMHANDLER, MEDIA_SERVER, and assorted in-house processes that normally wouldn't be compute-intensive.

On advice from HP tech support, I applied UPDATE V4.0 -- no bugchecks since.

However, since that time, my operator log has shown several occurrences of the following:
INTERnet ACP Error Status = %SYSTEM-F-NOSLOT
and
%QMAN-E-CREPRCSTOP, failed to create a batch process, queue will be stopped
-SYSTEM-F-NOSLOT, no PCB available
... in the midst of a large number of OPCOM messages about accepting SSH requests from external IP addresses.

Even if these SSH connection attempts are just random fishing expeditions, they seem to be causing me real problems.

Any suggestions?

[John Gillings]

James,

You can limit the number of SSH connections by setting the service limit. For example:

$ TCPIP SET SERVICE SSH/LIMIT=20

now stop and restart the service:

$ @SYS$STARTUP:TCPIP$SSH_SHUTDOWN
$ @SSY$STARTUP:TCPIP$SSH_STARTUP

This will prevent the connection attempts from consuming all your free PCBs. The downside is if you have a constant stream of probes, you may block legitimate accesses. Maybe you need a firewall that can blackhole any addresses from which you see persistant breakin attempts?

[Willem Grooters]

I'm not at all surprised. This is actually unixware which, IMHO, lacks the internal security required for secure environments like VMS.
Actually, last bootcamp we did have a session about SSH and all attendees were surprised by the security leaks that come with the use of SSH. Some decided to ban SSH from their systems just because of these issues. It has been discussed how to get over these issues, but that may (will?) require a full overhaul of the whole code. Not only that: it requires quite another attitude of the developers.
I agree with John (I thought you were in that session as well?) that a firewall _can_ be your first line of defence, to ban access to notorious attempters. But that does not mean SSH is safe enough to use. It should be able to use it - safely - on a non-firewalled system.

Willem

[Ian Miller.]

problems where fixed in the V5.4 release of SSH (and the EAK is no longer supported). Could you upgrade tcpip?

[Rick Dyson]

Just an FYI. I use the free SSH (from Dave Jones), the Process Software/Multinet SSH for OpenVMS, and the one in TCPIP v5.4 and have had various problems/issues with all of them. Though the free OSU one has worked the best... It just doesn't do SSH2. :(

Recently, the Multinet version (for Multinet and TCPIP/UCX) suffered from a DoS when they were hit by some MyDoom-infected PCs trying brute force password attacks. It kicks the server into a CPU saturation (as many as you have!) for 5-15 minutes. Bringing your system to it's knees. To get through the day, my Network gods had to apply an ACL to disallow *ALL* external access, even cutting off my external access. Harsh, but effective for this simple case. NOTE: Process does now have a patch out for their products and it seems to be working for me at another site that did not have the luxury of the network isolation.

I mention this simply because it might be a source of your incoming SSH problems. Also, just for my $0.02 in this SSH-bashing tread. :)

Rick

[James Becker]

Relatively speaking, I've got a solution. My first reaction to the suggestion about setting a limit on the SSH service was, "Yes, but that just opens the door for a different DoS attack." But that really turns out to be the solution.

The SSH behavior of creating a process with each connection attempt is just like telnet. It's not really a problem introduced by SSH, except that the original limit was 10000.

I can set the limit to a value that would normally be plenty for my expected SSH connections, and then I can set MAXPROCESSCNT to a substantially higher value (without being grotesquely overlarge). I'm still at some risk of a major barrage of connection attempts, but at least it won't run me out of process slots.

Thanks for the advice!