I recently had a security assessment / internal pentest project, and one of the findings was "I found an AS/400 running telnet services" (actually unencrypted tn5250, but it comes to the same thing)
The client's response was that this host was up for history purposes only, it was not longer production system.  So it was only used occassionally when they needed transaction history from before their migration to the current system.  Which doesn't really address risk around their client's information on that host.

We've all been there.  We've found a telnet service that should be migrated to SSH, but the affected device either doesn't support SSH, or the client for one reason or another can't put resources into enabling encrypted services.  In the case of the AS400 above, they'd need to do an OS update, which would require an application update to an app they had retired, on a system that isn't production anymore.

We see this in legacy systems, but in Industrial Control Systems (ICS) that control factories, water or hydro utilities we see this all the time in production - and the answer there is "the gear doesn't support ssh, and in some cases doesn't support credentials".  In ICS systems in particular, gear like this is often on the same 5,7 or 10 year depreciation cycle as might be seen on an industrial press or other manufacturing equipment, so upgrades are really a long-term thing, there are no quick fixes.  Even finding where all the vulnerable gear is (physically, not on the network) can be a challenge

So what to do?

In some cases, I've front-ended the problem child gear with a cheap SSH gateway.  A Raspberry Pi does  a decent job here for less than $100 per node. The Pi runs "real" linux, so you can secure it.  The solution looks like this:

Physically, it looks like this - often we'll just velcro the Pi to the host it's protecting, the "Unencrypted DMZ" ends up being a 1 ft ethernet cable:

The linux account that the user will use gets a ".profile" file, which lookslike this:

telnet x.x.x.x (the target host)
exit (which logs out the SSH session when the telnet session ends)

When the user logs in, their session immediately telnets to the back-end device.  You can expand this with NAT and port forwarding to expose other services in either direction, depending on your "appetite for complexity".  In most cases I do this for, all we're shooting for is an SSH gateway solution - backups and other services go out via another path.

Of course, there are limits to this:

• A Pi is not the most reliable solution - they boot off of SD cards, and those do fail.  Keep some spare, imaged SD cards
• It's not the fastest solution - the Pi only supports 100mbps ethernet, and the ethernet NICs are  USB based so you won't ever see it reach 100, but for telnet that's fine.
• Disable the Pi's wireless if you're not using it as one of the NICs.
• If the client doesn't have Linux skills in-house, keeping things patched and properly maintained can be a challenge.  If they've got linux chops, this'll plug right into their ansible/puppet/chef or whatever infrastructure.
• More on the above, no Linux distro is secure out of the gate, least of all the Pi which comes out of the box with default or no credentials (or no password more like).  You'll want to secure the device with something like the CIS Hardening Guide for whatever comes close to your distro (My Pi runs Raspian, so I used the CIS Debian guide, but there are Redhat or Ubuntu distros for the Pi as well). 
• Using NISTR 7966 to further address SSH can also be a huge help (http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf ) - if you can simplify things so that the client uses SSH keys for the SSH session, then only has to login once to the telnet back-end, that can keep everyone a lot happier (and more secure to boot)
• If you need more reliability or speed, you can keep the same approach with something like an Intel NUC or one step up (something with 2 NICs) - a cheap, compact SSD based computer with 2 NICs.  Using a "real" host allows you to go with an easier to manage, more full featured solution - I'll often use pfSense or even OpenWRT instead of a self-secured Linux distro for something like this.

Other approaches?
The ICS / SCADA approach I often see at client sites is to put all the problem devices in one VLAN, then segregate that VLAN.  That works well, and you likely still want to do that even with the SSH approach above.  Often we'll require a VPN session to get to that VLAN, which is pretty easy if that VLAN is off the same firewall that already has an internet VPN configured on it.  This works well in hospital situations as well.

The risk in this approach is that if an attacker does get access to that VLAN, it's just too easy to pivot or spread out, all the vulnerable hosts are in one place - it's really a "wolf amongs the chickens" situation.  So we'll try to further segregate or secure services as much as possible within that VLAN, or split it up into smaller pieces at least.  Anything you can do to reduce the "splatter zone" after the security incident is a good thing!

What have you done to secure "unsecurable" (for whatever reason) services?  Please, use our comment form to tell us the neat and "free or almost free" approach you've adopted!

===============
Rob VandenBrink
Compugen