First, I need to apologize to many of my faithful readers.  I think I’ve finally succumbed to the Twitter disease.  As many of you know, I’ve been using Twitter for over two years.  Indeed, I’m one of those technology saps that picked it up, set it down, and picked it up again.
And I really love Twitter.  You can connect with others at the same time that you post your thoughts on any subject.  And for me, it has the added value that you only have to edit a 140 character posting.
I state all of this for one reason: I must apologize to my readers as I have forsaken the “long form” for the micro-blog.  It has been almost a month since my last post to this blog.  And that is thoughtless of me.  If I want you to continue to read the things that I write, I must continue to write them.  In the meantime, I’m trying to work out an adequate penance.  Please leave me a comment with your ideas on how I can attone for the sin of neglecting my readers.
Now, on to the meat of today’s missive…
Last month, I started a security voyage.  Much of the reason for being so concerned about security is that Noah has challenged me.  He didn’t even realize that he had challenged me.  But those pesky Starbucks conversations have a way of provoking an immune response reflex. He would tell me about going to Defcon and how thrilled he was to meet with his friends in the hacker community.  His joy at being able to “crack” technology barriers perked my concerns.  So it was time to convert concern into action.
Last month, I knew I needed to address some chronic architectural flaws.  Think of last month as stiffening and strengthening the girders.  I put a VLAN in place to isolate the most insecure aspects of my infrastructure from the most valuable jewels in the collection.  I turned off all but the most necessary of protocols.  I began utilizing a lot of tunneling.  This allowed me to lessen the surface area of my risk. But it just put all of my “risk” into one basket.  In effect, I had one basket of very dense risk.
As I type these words, I think of the last scene in Terry Gilliam’s “Time Bandits” movie.  In the last scene, the totality of evil t be found in the movie is condensed down to a single charred briquette of absolute evil.  That’s what I unintentionally had created last month.
As of yesterday, I started to address some of that evil by working on the doors and the locks that protect my house.  I’ll start by noting that I do have a few web servers that are relatively open.  These are the webcams I referred to last month.  They are older and inherently less secure.  But they are now “isolated” and provide rather limited value to an intruder – unless you want to watch me typing on the computer or loading my new panniers.
But I’m wandering off topic…
Yesterday morning, my biggest “door” was the cable modem connection and the wireless router that I use at home.  I’ve been pretty good about securing the wireless.  And last month, I closed a whole bunch of windows on the facade (i.e., open ports for unneeded services).  But the locks on my front door weren’t very solid.  Yes, I use a custom firmware build.  And yes, I use ssh  for the majority of my access needs.  But it wasn’t a strong enough lock.  So I set to work on replacing the locks on the front door.

1. I started by using Steve Gibson’s “Shields Up” service.  I quickly noted that while port 22 was open, there was still a remnant of port 80 that was still visible.  After stumbling through some documentation, I realized that there are a couple of “options” in the DD-WRT firmware that I needed to tweak.  In order to really lock down the leakages, I had to set some nvram options as well.
2. I then improved the locks by switching from a password-based authentication approach to a PKI approach.  Using PuTTYgen, I created a 1024-bit public/private key pair for myself.  [No, I haven’t posted my public key on a keyserver yet.]  I then generated a horribly long passphrase tat I would remember.  Now I had to get the public key onto the router.This proved to be quite a challenge.  After editing the generated keyfile, and using cut/paste operations (from Notepad into the router’s web GUI), all I had to show for it was a series of failures – on many levels.  After what seemed like hours (but was actually just a few hours), I finally noticed that PuTTYgen places the public key component it generates into a portion of its key generation window.  And the output was quite a bit different than the output PuTTYgen places into the keyfile.  Every security wonk reading this must be saying, “Gosh, you’re kinda slow, eh.”  Well, I guess I am.  I took the text (in OpenSSH key format) and pasted it into the DD-WRT ssh public key segment of the DD-WRT -> Services dialog.  And voila, things began to work.
3. After adding the key through the GUI, I realized that I didn’t even want the management GUI (for DD-WRT) to be generally available – even from the LAN side of the router.  So I set nvram parms so that the web GUI would not start at all.  And if/when I needed it, I could start it via the command-line.At this point, I had locked down ssh in my environment, right?  The answer wasn’t quite that simple.
4. Since I was still routing port 22 from the WAN interface to the WinSSHd instance on my main system, I still had a problem: ssh needed to be hardened on my Windows 7 device.I use WinSSHd.  It is free for personal use.  And since I’m a person, I felt I can take advantage of their generosity.  From a personal viewpoint, I’ve used a variety of Windows SSH tools (including the full-featured Tunnelier product).  And I think that the personal version of this tool is excellent.I set up the  server to utilize my public key.  I then went to my laptop.  After setting up some additional session profile in PuTTY, I had a serviceable session established for testing.  But for the life of me, I couldn’t get the crazy thing to work.  I started to assume that it was a public key  problem as was the case with DD-WRT.  But after a few hours of fumbling and trying a number of things, I started to get frustrated.
   I finally noticed an inconspicuous link on the main WinSSHd server management page.  It pointed me to the server management log folders.  Well, I had been through the session management logs.  But I figured I’d give this a try.  In a few moments, I was treated with a rich feast of information.  And I casually noted that the key exchange was failing because the client was offering a 2048-bit key while the server was expecting a 1024-bit key.
   It dawned on me that I had trouble copying the public keys to this machine many hours earlier.  Earlier in the day, I couldn’t find my USB key.  So I had used one of the Sandisk Cruzer drives my wife had squirreled away.  And amidst all of the trouble associated with the U3 drivers for the USB device, I had probably copied the wrong version of the key that I had generated many hours earlier.
   The solution was simple: I took the right key and loaded it onto my laptop.  Once corrected, the ssh tunnel sprang into life.  Here’s a reminder.  When doing a multi-step project, write down what you do and when you do it.  It may prove helpful at a later point in time.
5. Once I got the tunnels working, I realized that I really didn’t want a 1024-bit key.  So I regenerated new keys and deployed the public key component to both ssh servers (Dropbear in DD-WRT and WinSSHd on Windows).  It only took a few minutes – now that I had solved the earlier issues.

So after ten hours of security tinkering, I had installed stronger and more tamper-resistant locks onto the one door I have onto the Internet. I am effectively tunneling all of the valuable protocls through ssh.  So I’m feeling a lot better.
But after doing all of this, am I any safer?
That’s such a tough question to answer.  I am smarter than I was a few hours ago.  I know a lot more about PKI.  And I know that having 2048-bit asymmetric keys is better than a weaker alternative.  And I know that even longer keys may not be worth the effort.  And I remember that if you want to stop casual hacking, you only have to have a stronger door than your neighbor.
But am I safer?
All the windows are shut.  And I’ve got better locks on the door.  But if someone wants to get in, there is precious little that I can do to stop them.  So we need to remind ourselves that multiple layers may be the best defense.  Even though the door is locked, put your valuables in a secure place.  Some of my most sensitive data is not stored on my online systems.  Indeed, that data may be in the form of offline media that I have in my desk or in a filing cabinet.  But such distribution of data is not the only defense.  Make sure that your computers are secured with strong passwords.
And try not to leave the keys near the locks.   Some folks write down their passwords and leave them on a sticky note – just like the idiot office clerk in “Wargames.”  If you must have  a repository for passwords, use a secure password manager tool.
And always remember that security is a perpetual process of improving what you already have in place.
-Roo