For the past few years, I’ve enjoyed the ability to log onto my home system while I’ve been at work. The process was simple: I would launch PuTTY from my USB drive. From there, I’d set up a encrypted tunnel through my router to my primary home system. I would then use a VNC client to tunnel my desktop access through SSH. But all of that changed when I started my new job.
At my new employer, I was no longer able to use SSH to access my home system. I totally understand why port 22 was blocked. But I really didn’t want to start tunneling stuff through DNS. Fortunately, my new phone provided the answer to my need for desktop access. After doing a bunch of research, I decided that I would use ConnectBot and androidVNC on my Android phone.
But there are always hiccups when doing something new. At first, I had trouble with public key encryption to my home system. I would never back down from this requirement. So I let the issue sit until I had a few more hours to fiddle with parameters. And tonight was that time.
I tried to use my existing public keys. But that strategy was fraught with trouble – i.e., I couldn’t get it to work. So I decided to reverse polarity on the device. OK, I’m not Scotty. But I decided to generate the key on the phone (via ConnectBot) and mail the public key component to myself. I then imported the key into WinSSHd. Unfortunately, this didn’t solve the problem.
So more research revealed that WinSSHd only supports ‘xterm’ emulation. So I updated my ConnectBot settings and tried yet again. And voila, my phone could connect to my home system. So I had a command prompt. And everything looked good. But the job wasn’t done yet. I wanted full screen access. So it was time to do more research.
It was easy to set PuTTY up on my desktop. I just needed to find out where the options were in the ConnectBot tool. Enter the work of Wayne Perg. His excellent tutorial pointed me to the port forwarding directives in ConnectBot. Within a few minutes, I reconfigured androidVNC. I am now able control my desktop from my phone.
Folks, technology is fantastic. And it is even more fantastic when you can find the answers to your questions through the previous work of others. If there is one thing I can still teach my kids, I hope that I can help them to use Google (or other search engines) to find real answers. The truth is out there.
-Roo
Tag: SSH
A Maze of Twisty Passages…
I am definitely an old school gamer. My son plays games like Modern Warfare 2 and Left 4 Dead 2. But I started when games required thought and not just lightning-fast reflexes. And one of the very first computer games I remember was Colossal Cave. I first played it on an IBM S/370 that ran MVS and TSO (i.e., Time Sharing Option). But some of my most favorite memories of the game were when I played it on the Heathkit H89 PC that I soldered together with my own hands.
And there was one part of the game that always fascinated me: the maze of passages. Actually, there were two such mazes: one had twisty passages that were all alike and the other had twisty passages that were all different. And in these tunnels, you could either become lost forever or find the pirate’s treasure.
So what does this game have to do with anything? It’s simple: the use of tunnels can lead to frustration or it can lead to treasure. For today, I’m going to talk about tunnels that can be used for treasure.
Most of us know about one form of tunneling or another. Many people use (or know about) SSL tunnels and/or IPSec tunnels. These kinds of tunnels are commonly used by many folks who must use VPN technologies to access resources that are secured behind corporate firewalls. Most people have no real idea of what is going on “behind the scenes” when they use their corporate VPN’s. But the basic premise is simple: one kind of data that is commonly blocked can be “wrapped” within another kind of data that can be allowed to pass. Think of this as the knife in the birthday cake. The guards won’t allow the knife to be given to a prisoner. But the guards can be fooled if the real payload is hidden from sight.
Of course, this analogy is simplistic – and somewhat deceptive. Tunnels are not used just to hide nefarious objects from the prying eyes of the world. They are more commonly used to control the kinds of data that passes the sentry points in a system. Think of it this way: if the cargo hole in a ship is shaped like a square, then valid cargo must also be shaped to accommodate the size and shape of the square entryway.
For those who have a little more knowledge, there are other forms of tunnels that are commonplace. For example, SSH tunnels are de rigeur for most system administrators. SSH tunnels can be associated with commercial tools (like VanDyke’s Secure Shell or BitVise’s Tunnelier). But they can also be used with open and freely available tools (like sshd and PuTTY). I use SSH tunnels for so many things. SSH is used to secure my router. It is also used to securely access my home systems from any location on the Internet.
But amongst those who work with security for a living, there are many other forms of tunneling – some widespread, others obscure. For years, TOR (The Onion Router) has been used as a means of anonymous (and encrypted) browsing. And TOR has often been used with local proxies that ease the burden of tunnel configuration and workload separation. But recently, the use of TOR and local proxies has gotten a whole lot simpler. You can now downlod a single package that will install and configure a browser, a proxy and TOR onto a portable platform (i.e., a USB key). In this kind of configuration, you can insert a USB device into almost any system connected to almost any public hotspot. Once the browser is launched, you can commence anonymous and secure browsing of the Internet.
And these tools can now be combined with all sorts of other tunneling tools. For example, you could tunnel TOR traffic within SSH and then forward it across a DNS tunnel. This would allow you to bypass most content filters established on the networks to which you might be connected.
Is this cool technology? Most definitely it is. Can this technology be used for good things? Of course it can. Consider an evangelist within a repressive country. Such a person can connect and communicate with others within his country or with those who are outside his country.
But can this technology also be used for nefarious purposes? In candor, it certainly could be used for illegitimate purposes. But I think of these kinds of technologies in the same way that I think of freedom of speech. We must allow gross and unseemly speech if we want to have any freedom of speech. Otherwise, our speech (however comely and delightful it might be) could be considered objectionable – and hence, controllable.
So what should we do about the maze of twisty passages? In my narrow view, I must come down on the side of allowing such technologies. They can be used for good or “twisted” into unacceptable uses. Of course, the same thing is true about guns. They can similarly be used for unsavory purposes. But the protection of our liberties will lie in our ability to use tools that allow us to secure and protect individual liberties – even when this means that the state will have a more difficult time dealing with the criminals.
-Roo
Summer of Insecurity
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.
- 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.
- 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.
- 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.
- 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. - 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
Battening Down the Hatches at Home
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