Friday, June 24, 2011

Lockdown!

EDIT: I've added links to some walk-throughs here to make this a simple 1-2-3 process. See the end of the post for these.

One thing I don't discuss enough is security in relation to mobility, and it's funny that I don't because I'm entirely mobile and strongly advocate anything that promotes telecommuting and working from unconventional locations. While I don't profess to be a security expert, it is my understanding that this configuration is more than adequate for most Road/Code Warriors.  (That has to be an existing term, I'm sure.  If not, I hereby lay claim to coining it.)

So the point is to have access to your home office network while you're out on the road (or at the park with the kids, for fellow domesticated types).  You want to see your office desktop from your smartphone screen so you can make a couple quick edits, start a long download, and start compiling your latest spaghetti code so that everything's ready to tinker with when you get back.  But you don't want to leave the front door unlocked so that any 14 year old with a port scanner and a brute force password generator can take down all your hard work.  Here's what I do.

First is to close off all inbound ports except one: SSH.  I have a dedicated machine serving as my SSH server, and that's all it does.  It's an ancient PII-400 machine that I had laying around, loaded with a trimmed down Linux install.  It might not seem like much, but it does what it needs to do very well, which is to accept inbound SSH connections and route the remote connection.  [Update: This is now done with a virtualized machine on the primary server.]

With the SSH port open, you'll need a server to listen and process your login information.  In Linux, sshd is typically part of the standard distribution, and there are numerous walk-throughs available around the web to get you set up.  In Windows, the most painless setup I've found is freeSSHd.  Specific configuration is beyond the scope of this article, as there are numerous howto documents for each package floating in various places all over the web.

Once your SSH server is configured, you'll set up your terminal client.  In Linux, the standard terminal will suffice just fine.  In Windows, I prefer PuTTY, but there are others available.  Create a connection to your server, and log in with your username and password.

Here's where things get fun.  Port tunneling.  Set up your SSH client to tunnel any required ports for things like RDP, VNC, or what have you, to the machine address you want to connect to, then point your portable client to connect to localhost on those ports.  The ports get forwarded through your secure connection to the appropriate destination machine, and have the benefit of 128-bit encryption from point to point.

Step 1: Install your SSH daemon. Since the original writing of this post, I've found that freeSSHd has some packet overrun issues when dealing with RDP, so I've switched to the Cygwin OpenSSH package. There are numerous benefits to this approach, not the least of which are standards compliance, no-cost use, and 256-bit AES encryption if you want it. Follow HowToGeek's OpenSSH howto to get it running.

Step 2: Install PuTTY and configure it, which includes setting up your port tunnel.

Step 3: Close off all external ports except your SSH port, which will typically be port 22. If you have other services which require open ports, go ahead and leave those open, but the essential bit here is that you do NOT leave your RDP port (3389) open to the universe. That's the whole point of port tunneling, after all.

If you set up your SSH server to use RSA key access rather than simple password authentication, you can pretty much rest assured that you (or those you've provided your key to) will be the only one ever connecting to your SSH server.

I hope this has you on your merry way. Feel free to leave questions or comments below.

Is Virtualization the Answer?

As many of you know, I spend a lot of time hassling with the many machines on my network.  It has long passed the point of me being a full-time network administrator just to manage my home network.  I have a web server, a mail server, a home theater media server, a primary development desktop, two additional desktops in the bedrooms, two portable PCs, two additional floating desktops, and all that doesn't even take into account the mobile devices, media extenders, access points, and spaghetti nightmare of network line that has to be maintained.  That's 10 PCs, plus extra devices.

It's far too much.  Is this what the connected house of tomorrow will become?  No, there has to be a better answer.  And there is definitely a way to minimize the extraneous hardware.  Enter virtualization.

Virtualized machines are rapidly gaining in popularity and practicality, and while I've been tinkering with them over the past few years, I've only just truly realized the full effects of utilizing the technology.  When my primary development/gaming PC failed a few months ago, I spent a lot of time assessing my options.  I went without until I could put a practical plan in place.  And the result surprised me.

Typically, I like to have the power of my primary machine within arm's reach, but in this case, it just wasn't worth the hassle anymore.  My recent lifestyle push toward minimalization steered me toward condensing functionality.

The overhead up front was rather large (compared to what I normally invest in a machine).  I built an AMD 6-core PC with 8 GB RAM (which I will expand later) and installed Windows 7 64-bit so that it could be used as the home theater centerpiece.  Here's where the magic happens: using Oracle VirtualBox, I created virtual machines that would take over the duties of other  machines throughout the network.

I have one dedicated mail server, one web server, and a third (new) virtual machine that is a dedicated remote access interface.  It has only a minimal compliment of software, but is locked down tight so as to be the only interface between my home network and the outside world.  I also have this new server pulling double duty as both the entertainment centerpiece (HTPC) and primary gaming machine, figuring that the most gaming we do is in the living room (alongside the other entertainment devices, such as the XBox).

Now, using a separate login, I can RDP into that main machine from another desktop and utilize the processing power to handle all my development needs, and can do so without interfering with the people watching a recorded show on the media center downstairs.

I've condensed 4 machines into 1, and under typical operation, the CPU utilization of this new machine is well under 10%.  It seems to me that I have more than enough room to handle the majority of my computing needs in this one box.  Granted, a virtual machine still has administrative needs, but it certainly cuts down on the hardware maintenance, and eliminates a lot of the network requirements as well.  It seems to me that if the few people in the house would use portable PCs exclusively, my unpaid job here would be much easier.