Securing Telnet with SSL
ibm.com
ibm.com
You can find "sortof ssh" solutions for AS/400's and z/OS, but they create a tunnel and it's still telnet underneath. Or solutions that are ssh, but are interacting with a linux partition, or posix subsystem, and can't do the 3270/5250 stuff.
Despite assurances of using encryption to clients, we were taking no security measures. Connections to servers were possible with UUCP and Telnet over the internet and modem.
We "upgraded" to SCO OpenServer 6 because we were already grandfathered in to it and three servers had died.
We also had a zero password policy. If you could find the port or the phone number and you could guess a username, such as oh I don't know: "root", then you could get in.
And people were. We were regularly getting modem calls after hours. We had medical records, private financial data, social insurance numbers, ...
It was such a painful work environment. I switched us over by claiming that OpenServer 6 did not have a telnet server and that we were going to have to switch to SSH. I also lied and said that passwordless SSH sessions weren't a configurable option.
My point? This sort of half-assed mitigation of people stuck in their ways doesn't accomplish much. Best to just lie to them, if they were educated they would have already made the change of their own volition.
You are a brokerage and your Setup with IBM is a mature system that would cost you lots of capital to overhaul to SSH. Your already have a plan to do this and it will take 1 or 2 years to roll out and justify the cost to the board of directors. This answers the question : What do I do now to secure this system.
They are just doing it within the 5250 emulator instead of setting up a separate tunnel with a VPN or SSH port forwarding scenario.
So... do brokerages use telnet in the wild?
If you're using a stack dependent on 3270/5250 connectivity, you're better off using stuff like this. IBM supports it end to end, and it will support all of the functions in the terminal without code changes or other workarounds. Nowadays increasingly fewer people actually know what they are talking about with these technologies, and you're better off touching as few things as possible!
Sometimes you don't want to change... Much. :)
Vax, for example, had functional clusters, versioned filesystems, and other goodies, many years ago.
Just the nature of a proprietary system...controlling everything means some functionality is easier to implement, more elegant, etc. Apple still takes advantage of this.
The hardware and OS licensing costs are high, as you suspect.
I think that's a stretch. It had file-name;rev where each time you wrote the file it bumped $rev. As an SCM guy, that's not versioning, that's automatic backups. And you have to run purge all the time to free up disk space.
I don't mean to be pedantic but this is the second time I've seen this claim in the last few days.
To me, a versioning file system has a dag, the OS creates a node everytime you close it with modifications; if two people close at the same time then just like BK or Git you fork the graph, which means the next time someone opens it it has to be merged.
As I said elsewhere, it would be super cool to have such a thing for /etc, if you wack a config, debian wacks it, you upgrade, you then get all the features that an SCM system give you for merging. I dunno what Git gives you but BitKeeper does a kickass job of automerging and has a complicated but pleasant graphical file merge.
Etckeeper [1] does this. There's also etcd, but that seems to be more akin to Puppet and Chef. Disclaimer: I've never used any of the mentioned software.