Securing the insecure...

Joshua McDill -

So, you have a legacy device with only unencrypted connection methods over the network. Instead of trying to pass (or renew...yikes!) that risk document, stop and consider the following option to greatly mitigate your risk until the device can be replaced.

First, isolate the device behind something that can run an SSH daemon. Hopefully you've already done something like this, but don't hear what I'm not saying...VPN. I know what your thinking. "Why SSH? Why not a VPN?". I presume if your asking this question you've either not spent a lot of time managing VPN's or you have a TON of experience with VPNs. Either way, a VPN is major overkill for something like this. We aren't establishing point-to-point connections between offices. We're trying to mitigate risk until a full solution can be deployed. In this case, a simple SSH daemon configured to forward connections can function as an easy and cheap secure proxy.

Once your device is isolated behind our SSH server, convert your existing connections for the insecure device to instead go to the SSH server using local port forwarding, making sure nothing can get around your secure 'proxy' by leveraging whatever firewalls you have protecting the network. Anyone that needs access to the old insecure device now talks to the new secure 'proxy' only.

Below are some diagrams for this new architecture. I'm using the Mermaid JavaScript library to render these in the browser which is pretty cool. You should check it out!

First, build the secure tunnel through your SSH server

ssh -L 2323:insecure:23 sshserver

flowchart LR A[localhost] --> |ssh 22| B[sshserver] --> |telnet 23| C[insecure]

Second, connect to the insecure host over your local secure tunnel

telnet localhost 2323

flowchart LR A[localhost] --> |telnet 2323| A[Localhost] A[localhost] -.-> |ssh 22| B[sshserver] -.-> |telnet 23| C[insecure] -.-> |local 2323| A[localhost]

Tips:

  1. If you are using host names, not IP addresses, to forward your ports, make sure the SSH server is aware of the name of your insecure secure server. If DNS is in the mix this shouldn't be an issue, however if there is no DNS you'll probably be better off using IP addresses to avoid having to tweak local host files.
  2. Using SSH keys is a great way to automate these kinds of connections, especially if it's to something you use all the time. You can also leverage your SSH config file (or save your puTTY session)
  3. I take no responsibility for your security team (or auditor) rejecting this mitigation technique...or for someone finding a way through it and pwning you. This is a mitigation technique using some clever tricks, nothing more. Use at your own risk.