How many times have you heard the phrase “batten down the hatches?”  But do you know what it means?  Well, it’s a nautical term referring to sealing ship hatches with strips of wood and caulk.  This is done to prevent water from penetrating the hatches of the ship.
Well, I’ve been battening down the computing hatches here at Chez Roo.  As most of you know, I’m focused on security – but not obsessed by it.  I have a wireless network that is fairly well protected with WPA2/AES encryption, strong  passkeys and strong credentials/passwords on all of the systems in the network.  I use MAC filtering.  And I try not to broadcast my SSID.
But nothing is totally secure.  And every measure or counter-measure should be periodically reviewed.  So when I added both a Wii and a new LCD TV to the wireless network, I figured that it was time to start doing a network review as sone of the new devices requred that I enable SSID broadcasting on my main access point.
At the same time, I had finally gotten around to addressing some remote access problems.  Specifically, I had finally been able to successfully configure my Windows 7 test system to allow remote mamangement via either VNC or Windows Remote Desktop.  Up until this week, I had tried to open all of the various ports needed for both products.  But I really hate having lots of ports open to the Internet.  So I reconfigured everything to tunnel through SSH.  BTW, I’m using WinSSH in a non-commercial role – and it is working fantastically well.
Of course, nothing is nearly as simple as it would at first appear.  I do use DynDNS to manage/publish the dynamic address that my cable provider doles out to me.  So I installed update to my DynDNS “updater” tool.  I also switched over to OpenDNS in order to improve performance and in order to get some rudimentary namespace management tools.
So once I changed three or four things at the same time, things stopped working – of course.  It turns out that as I cleaned up the router to eliminate the now unnecessary port forwarding, I could no longer connect to the UltraVNC server on my main system.  It was a simple problem.  I had used the FQDN name (in DynDNS) in the tunnel definitions I had put into PuTTY.  So once I established a tunnel, it would try and connect to the external name (i.e., the router) on the real VNC and RDP ports.  Of course, this wouldn’t work once I removed the port forwarding rules.  How did I correct it?  I decided to use the blunt force trauma approach: I updated my hosts file to point the external DynDNS name to localhost.  Once done, things started working again.
And now was the time to call a friend and ask for a favor.  While I trust my skills, I always want a set of unbiased eyes.  So I called @ax0n and had him do a Nessus scan on my network.  So what did he find?  First, he found my wireless IP cameras.  [Note: We put these in so that we could monitor the house while we were away.]  And he also saw the other ports that I expected.
But when he saw the cameras, I decided that these were the weakest link in my security chain.  You see, I run two different wireless networks.  One supports the main systems in the house while the other supports the wireless cameras that we installed.  The camera network is not nearly as secure as the main wireless router.  That’s because the camera network is over five years old.  And when it was first designed, WEP-128 was still the standard encryption model.  But I didn’t want my whole household to be limited to WEP-128.  So I set up an access point just for the cameras.  That network uses WEP.   I ran a separate network cable from the router to the camera AP so I could physically separate the traffic.
But I never took the next logical step.  This weekend, I took that step.  I set up a series of virtual LAN’s in the house.  And the cameras are now on their own VLAN.  Of course, this meant that I needed to reconfigure all of the cameras to provide them with new IP addresses.  And that took quite a while as I had to directly attach them to my laptop in order to reconfigure them.  It’s a simple process, but it does take time.
Then I had to set up the VLAN’s on the router.  The good news is that I use DD-WRT.  So VLAN setup is relatively easy.  But in addition to adding the VLAN, I had to set up new autostart options in order to relate the VLAN to a specific physical port on the router.  Finally, I had to update the builtin firewall to ensure that the VLAN for the cameras couldn’t access the other systems behind the router.  Yeah, this was the whole reason to reconfigure everything; I didn’t want someone to be able to connect to the camera network and then launch an assault against the more secured portions of my network.
So the annual security review is drawing o a close.  Yes, I expect that I may see a few more minor changes.  But the major re-designs and major changes are done.  And I sure am glad for that.  I sure hope that the next minor project is as fun as this one has been!
-Roo