Wednesday, February 11, 2009

Lock down MS Terminal Services remote access with OpenSSH

I needed a way to reduce the internet exposure of a MS Terminal Server that about 5 people use on a regular basis. It was behind a firewall with only port 3389 forwarded to it, and anyone who connected to the internet domain name was greeted with a Windows login prompt with no further ado. That meant that any mis-configured or forgotten domain account that was allowed logon to the T.S. could potentially be used to compromise the server. With turnover and layoffs it's pretty hard to make sure all Windows domain accounts are properly updated for login rights to that Terminal Server.
I wanted a solution that reduced the number of accounts I needed to manage in order to control access to my network from the internet, and reduced the attack exposure of the Windows box. This accomplishes both of those while giving the huge benefit of easy encryption and minimum steps involved.

Primary Goals Accomplished:
  • No direct exposure of the T.S. to the internet. Only authenticated connections should reach the server.
  • Easy to setup new users and disable old ones.
  • Easy for the remote users. No complex state-of-connections knowledge required.
Upsides of this solution:
  • The only hardware requirement is an available box to run Debian and OpenSSH. Which believe me, is damn near any hardware you can reasonably call a computer. If you already have an existing Linux server, cool.
  • Required software is FLOSS (Free/Libre/Open Source Software). An important consideration for any security solution. Mature FLOSS security solutions can be trusted.
  • Required software is free, an important consideration in business today.
  • Can be used for connection to almost any service on your network that does simple port communication over TCP/IP.
  • Can be used as a HTTP proxy for browsing intranet web servers , including DNS lookups. (This works on Firefox, I have no idea about IE, I don't use it).
  • End-to-end encryption of traffic, including the login credentials.
  • Works for any client OS that supports SSH (Linux, Windows, Mac, BSD, and others).
  • I already had an SSH server, and the remaining setup took about an hour and a half, including configuring 3 users and training them. A majority of that time was creating an installer for the users, so that it would be a point-and-click install. That wasn't really necessary.
Downside(s) of this solution:
  • If you limit connections to services inside your network based on the IP Addresses of your clients, that might kill the deal for you. Do you mind if the remote accounts have the same set of privileges as each other? Their connections will all come from the SSH server (i.e. same IP).
  • Feel free to comment if you know of others.
The quick and dirty overview of what it takes:
  1. Setup a Linux box with OpenSSH and configure your firewall to forward port 22 to it. [30 minutes - 2 hours, depending on your experience and your internet connection]
  2. Setup users on the Linux box and configure them to not get a shell when they successfully login (This limits the users from full access to the power of Linux). :) [15 minutes]
  3. Next give your remote users a copy of portaPuTTY and create a link to run it with some options (I created an installer for this), then copy their existing rdp connection and tweak a couple settings. [15 minutes, or the time it takes to create an installer]
  4. Train users to start the SSH connection, then connect to the Terminal Server, and close them in reverse order. [5 minutes per user]
Ready to get started? Find yourself an old computer and download Debian, you'll probably want this one. Burn the ISO you downloaded to a CD, and you'll be ready to get started.

My next post will have detailed instructions for setting it all up.

No comments:

Post a Comment