Thin Clients Part II - Security Added

Late last week I took my little thin client computing concept a step further and added some security. My goal was to add at least one layer of security, if not two layers to this process. Like a smart card concept I wanted to have a physical token (the thumb drive itself) as well as a "secret PIN" which the user would need to supply. This might add a bit of time to the login process, but the security would be well worth it.

The New Process
We will still use an autorun.inf file which will allow the user to plug in the thumb drive and simply press enter for the default choice. The default choice, is to run a batch script which I have called "connect.bat". Here are those files.

autorun.inf
[autorun]
open=connect.bat
ACTION = LAB CONNECT

connect.bat
SET STARTRUN=%0
7za.exe e -oC:\TEMP -y RDPPACK.zip
REM COPY %0\..\*.* C:\TEMP
C:
cd C:\TEMP
start /normal ssh.bat
PING -n 8 127.0.0.1>null
start /normal RDP.bat
start /normal WAIT.bat

When connect.bat runs, it launches 7zip, which extracts a zip file to the c:\Temp directory. I used 7zip for a couple reasons: a) it's freely downloadable at http://www.7-zip.org, b) you can create password protected (encrypted) zip files with it, c) I had it installed and I all ready use it in other batch processes.

My zip file, RDPPACK.zip, is an archive which contains several other batch files. One of these batch files contains passwords so we protect the zip file by password protecting it when we create it.

My RDPPACK archive contains the following files:
labconnect.rdp - This is the file which contains RDP details such as IP and port number.
plink.exe - This is a free command line secure shell client for windows.
RDP.bat - Simple batch file to connect to the host using the settings in labconnect.rdp.
ssh.bat - This is a new batch file which uses plink.exe to open a secure shell session with our VirtualBox server.
WAIT.bat - This waits for the thumb drive to be removed, and then cleans up and kills things when that happens.

Once the zip is un-extracted (takes only a split second) we start up three other batch files simultaneously.

Here is the play by play. The user plugs in the thumb drive which runs connect.bat. This starts the file extraction which pauses momentarily and waits for the user to enter their password. In my examples I used a simple four digit "PIN Number". The files are extracted, and "ssh.bat" is launched.

ssh.bat
SET STARTRUN=%0
plink -ssh -L 13390:localhost:3390 -pw password username@10.0.46.55
EXIT

There are two items of bad news to mention here. One is that there is an EIGHT SECOND wait placed after this script runs. This is the unfortunate amount of time it takes for the secure session to be established. The other bad news is that the username and password are exposed here "in the clear". This could be hidden by putting an @ symbol in the batch script in front of that first line (keeping the command from being echoed to the user). But it will sill remain in the Temp directory while this script is running and a bad guy could find it. I would like to think that the user will not share the PIN number which revealed this information, and if their thumb drive was lost or stolen you could simply change this password on the server. So it's "pretty good" security in my book.

The plink syntax works like this: "-ssh" means to use the secure shell protocol, the "-L 13390:localhost:3390" will redirect connections that the host makes to itself on port 13390 to the server on port 3390, the "-pw password" would be this users password on the server, "username@10.0.46.55" would be the users username and the servers IP address. This means that we have created the user on the server, assigned them a password, enabled the secure shell daemon, and we are firewalled to disallow connections on port 3390. Yes, we do NOT want to allow connections to port 3390 from anybody. The only reason our remote users can do it is because they are sending these connections through the secure tunnel we established here. Clever, huh?

Once the secure session is established (we simply waited 8 seconds and assumed it's ready) we then run RDP.bat and WAIT.bat simultaneously.

RDP.bat
mstsc /f labconnect.rdp
EXIT

WAIT.bat
PING -n 10 127.0.0.1>null
GOTO CHECKEXIST

:CHECKEXIST
IF EXIST %STARTRUN% GOTO WAIT
GOTO KILLTASK

:WAIT
PING -n 3 127.0.0.1>null
GOTO CHECKEXIST

:KILLTASK
taskkill /f /im "mstsc.exe"
taskkill /f /im "plink.exe"
DEL /F C:\Temp\autorun.inf C:\Temp\connect.bat C:\Temp\labconnect.rdp C:\Temp\plink.exe C:\Temp\RDP.bat C:\Temp\ssh.bat C:\Temp\7za.exe
EXIT

RDP.bat will connect us up to the server. There were some changes made in the RDP file. That is, the client now connects to localhost:13390 instead of the server IP and port 3390.

WAIT.bat will start pinging itself in a loop, and wait for the drive to come disconnected. When that occurs, it will immediately end task on the terminal services connection, and then the secure shell tunnel. Afterward (and this is new) it does some cleaning up and deletes all that stuff that it left laying around in C:\Temp. The only thing which will remain is the WAIT.bat file itself. Which as you can see, presents no risk as it contains no passwords, etc.

Problems
I probably spent a couple of hours on this process over the span of a week. What was most frustrating was getting VirtualBox to cooperate with me. There are a few known issues with various VRDP elements. One is "authentication". Theoretically you can authenticate your VRDP sessions against a local user database on your VirtualBox server. This didn't work at all for me and after reading through a couple of forums I found that it doesn't work for anyone else either.

I am also having problems with my Windows clients when they connect to a VirtualBox at full screen. It seems that the windows get doubled up and don't display correctly. If you specify an exact window size in your RDP file such as 800x600, you will not have this problem. I went through the trouble of setting up a Windows VirtualBox server and found that the problem exists there as well. I have since opened up a Bug report with VirtualBox which I hope gets some attention.

Lastly, expect VRDP on VirtualBox to provide you with rather slow window refreshes. I would like to think that this is also something that the VirtualBox developers are improving as they have always been aware of this bug.

Hack on, and I hope that someone out there finds this information useful, at some point. ;-)

Thin Client Computing on the Cheap

Many, many years ago I was attending a trade show and I saw something really cool. There was a booth set up with a couple of screens which had card readers attached to them. You could insert one of their sample cards and a screen popped up running Windows and a couple of applications. When you removed the card, it was gone. You could then walk to one of the other terminals and insert the card - and there was what you were last working on (instantly). It was pretty neat, and the concept was simple. Running on the back end was a heavy duty server which was emulating a dozen or so Windows machines. The front end was a dumbed down Linux terminal which just connected the user to the virtual Windows machines by means of a remote connection protocol (RDP). There was a little more to it, such as strong certificate based security, but we won't tackle that just yet.

My plan today was to create a collection of virtual Windows machines, and a USB "key" which could connect me to one simply by inserting it to a workstation.

The Server: In my case, this was easy since I all ready have a Linux box running VirtualBox. If you want to create this environment, go on out to VirtualBox.org and get yourself a copy. Note that it's *FREE* to those who qualify (read the fine print). Also, there is an Open Source Edition which is free to everybody, but it lacks some key features like USB support (so avoid it for this discussion). Once you have VirtualBox you will want to create at least one workstation. This can be anything really. In my case, it was Windows XP. In the settings for that workstation you will want to go into Settings and then Remote Display. Enable remote display and set your port number (default will be 3389).

The Workstation: I am referring here to the "dumb terminal" that you will be using. This should be on the same network as the server (or there should be routing established between them). Nothing needs to be done special on this workstation. It should be running Windows for our discussion. In my case I am using Windows XP boxes.

Prepare an RDP File: This can be done on any Windows machine. Basically we just want to make a settings file that we can put on our Thumb Drive. To create this, get onto a Windows PC and click Start > All Programs > Accessories > Communication > Remote Desktop Connection. Enter your IP and port number like this SERVER:3395. If you used the default port of 3389, just enter the server name. You can specify all sorts of other info here if you want. Many of these settings have no bearing since you are connecting to VirtualBox, and not "Windows itself". When you are done, choose to save your settings. Save this right onto your thumb drive and call the file "connect.rdp".

The Thumb Drive (or Jump Drive): This is where all my work came in. You will need to create a couple of batch files on the root of the thumb drive. Here is what they are named, and what should go inside of them ....

autorun.inf - This will initiate your remote client upon plugging in the Thumb Drive.
[autorun]
open=connect.bat
ACTION = LAB CONNECT

connect.bat - This is required to launch the RDP session, and the "watcher".
SET STARTRUN=%0
COPY %0\..\*.* C:\TEMP
C:
cd C:\TEMP
start /normal RDP.bat
start /normal WAIT.bat

RDP.bat - This will launch the remote window and ultimately quit.
mstsc /f connect.rdp
EXIT

wait.bat - This will watch for the removal of the thumb drive. If it's removed, the remote session is closed within 3 seconds.
GOTO CHECKEXIST

:CHECKEXIST
IF EXIST %STARTRUN% GOTO WAIT
GOTO KILLTASK

:WAIT
PING -n 3 127.0.0.1>null
GOTO CHECKEXIST

:KILLTASK
taskkill /f /im "mstsc.exe"
EXIT

With all this in place, here is how it will work.

When you insert your thumb drive, Windows XP will find the autorun.inf file and use it to launch an "Autorun list" in Windows XP. All you should have to do here is press enter (for security reasons this choice cannot be made automatically). At that point, you should see a remote connection window pop up. This whole process takes a few seconds.

While you are remotely connected, there will be two Command Prompt windows lingering in the background. One is just running the RDP application. The other is running a watch on the thumb drive. If you watch it, you will see that the PC pings itself three times, sending the result to "nowhere". The reasoning behind this is to give the PC something to do to waste time. Windows XP does not have a sleep or wait method that you might use to waste time cycles. Every time it completes it's three pings, it will check for the existence of the drive letter being used by the thumb drive. Through some clever tricks involving the "%0" variable, we are able to determine this drive letter regardless of what was chosen when it was inserted. If the drive letter is gone, the batch process hunts down the RDP task and kills it, then ends that script by exiting. The other script which had been running the RDP task moves to the next line, which tells it to exit also. The result is, the remote connection window and all it's friend vanish almost the instant the the thumb drive is removed.

You will see that my scripts first copy themselves to C:\Temp before running. The reasoning behind this was that if the drive is removed while a batch script is running from it, the script will fail and leave a "Terminate Batch" prompt on the screen. A colleague noted that in a production environment you would probably want yet another batch file in this process which removes all these items from Temp once it's done running. But it's a work in progress.

Next, I will focus on adding some form of security to this process as there presently isn't any.

Poor Mans Low Level Format

On occasion I am asked to "blank out a device" or remove any data it contains. Usually this is because we are disposing of media or we are selling off equipment at the hospital which once may have contained a patients medical records. This seems to be an easy task, with a complicated solution. The goal is to "write zeroes" to the hard drive repeatedly. This is affectionately referred to as a low-level format.

Sure, there are utilities to perform this task. Some are free, while others and get quite expensive. I also seem to run into problems where certain utilities only work with certain drives (a Western Digital utility only works with Western Digital drives).

Enter the simple and free solution: Linux.

I have several different versions of Linux laying around. Old versions of Ubuntu, new versions of Xubuntu, you name it. So here is what I did.

1) Insert your live distribution of Linux, and boot to it (this may require changing BIOS options, or changing boot options).
2) Wait for the desktop to appear, or fail to appear. I was working with some bizarro medical machines today which failed to boot completely and instead dumped me into "BusyBox". BusyBox is like a small shell which can only execute very minimal commands. But this will do.
3) If you boot all the way to a graphical desktop you can either open a Terminal window, or press Ctrl+Alt+F1 to get a virtual terminal.
4) Enter this command: cat /dev/zero > /dev/sda (or /dev/hda for older IDE drives).
5) Wait for the error message, "No space left on device".

The error message is inevitable. We are simply running a contents list of an imaginary device called "zero" which is filled with an infinite amount of zeroes. Then we are redirecting that stream of zeros right into the hard drive device ignoring all boundaries, partitions, master boot records, etc. Eventually we strike the end of the drive and it tries to keep going, hence the error message.

If you want to follow the old "D.O.D. Standards" you will want to repeat this low level format at least 6 more times (if not 9 more). You can run this command repeatedly by separating your commands with semicolons. For example ...

cat /dev/zero > /dev/sda; cat /dev/zero > /dev/sda;cat /dev/zero > /dev/sda

... would perform three consecutive low level formats. Sure, you could write this into a shell script. But then we are talking about something quick and dirty here which you can do simply by booting whatever distribution of Linux you have laying around.

Disclaimer: A purist might say "That's hogwash Steve! That data is still retrievable by using a chemical separation process on the platters". To which I would say, "then take them home and prove me wrong". Yes, data could still theoretically be retrieved from these disks ... if you have a laboratory environment, or the money to pay someone retrieve it. If you are really paranoid, consider alternating between writing zeroes to the device, and writing random data to the device. This can just as easily be performed with ...

cat /dev/urandom > /dev/sda

They say that by alternating and randomizing the data that you write, recovery becomes all the more impossible.

Thinkpad x60 Booting Disaster

A while back one of our doctors at the hospital bought himself a ThinkPad x60. At the time, it was about the most portable model that you could buy without sacrificing speed and extra memory. Yet - it was a ThinkPad. I will spare you the soapbox essay on why I believe that ThinkPads are crap. If you are using a ThinkPad and you you "just love it", good for you. But heed my warning: keep your stuff backed up, because your hard drive will fail in a year (or maybe sooner). And don't even get me started on the "lenovo" brand - which produced this gem. I think lenovo must translate into Chinese as "cheaply manufactured crap".

The good doctor brought me his laptop with a failed hard drive. That was no surprise. It was very well covered under warranty, but I had a hell of a time finding a number to call on the lenovo support site. IBM seemed to have disowned anything that lenovo produced, so they were not offering anything but a redirecting URL. Eventually I called a "paid support line" where I would be expected to put $70 on a credit card for a one-time support request. Knowing full well I wasn't paying a dime for something covered under warranty - I bounced around in their phone system a couple times and eventually found a live person. Lo and behold, this was the right department and they were able to send me a new drive. To their credit - it arrived less than 24 hours later.

All I had to do now was to restore the ghost image I took of the failing drive. I went through the usual process only to find that the PC was not going to boot. This was not all that shocking seeing how I imaged a failing hard drive and probably picked up a few errors along the way. All I really needed to do was to boot the Windows XP SP2 CD, and slip into the Recovery Console. From there you can run a "fixboot" and "fixmbr" to put things in order. There was just one problem ... this model has no CD-ROM drive.

Following what seems like poorly written instructions - I was able to slap together a Windows XP SP2 bootable ThumbDrive image, using this guide. While I was able to boot from the USB stick, I was not able to get past the "Setup is starting Windows" before it would blue-screen on me with a stop message. The problem seemed to be that Windows was losing itself, after having booted from the stick.

The solution to that issue ended up being to go into the BIOS of the x60 and setting the SATA option from "AHCI" to "Compatibility Mode". Not sure what that had to do with the USB boot problem, but it worked. No more blue screens. And I was able to start the Windows XP Recovery Console. But here was the other catch - by performing a "fixboot" and "fixmbr" I actually fixed the boot files of the laptop hard drive, but then BROKE the boot sector of the USB stick!

Lessons learned. Who knew that these old Recovery Console commands had arguments and switches. After rebuilding my thumb drive (there's an hour lost) I was able to get back to the Recovery Console and run both commands with a drive letter. That is, "fixboot c:" and "fixmbr c:".

Now - I am back in business with a booting, working, and updated copy of Windows XP. I went ahead and set the BIOS options back to default for the SATA controls, as I don't know if that really has any effect on how the drive is accessed. You had better believe that I am taking a ghost image of this while it's working. This hard drive will surely fail in another year or so.

Automatic Photo Resizing

Last year we took a family vacation to Hatteras Island. Being the geeky guy I am, I wanted to take all of my digital photos and upload them to an online gallery while I was still vacationing. Then friends and family could see all the beautiful things that we were seeing as the trip went on. This gallery can be found here.

While I enjoyed sharing the pictures, I didn't enjoy all the time it took away from my trip. I had dragged along my old iBook for the trip and it was not very efficient at getting images off of my camera (it took an hour or more). Resizing the pictures was extremely slow due to the low processing power. Uploading the pictures was painful because the beach house had a highly unstable DSL connection which was constantly disconnecting mid-image transfer.

This year will be different! In a few weeks we will be driving out to Beavers Island Michigan on a family getaway. I will be taking along my Asus Eee PC for image transfer. This laptop has an SD Slot in the side which matches the memory card style that our camera uses. So after a long day of hanging out at the beach or taking adventurous hikes - I can take the card out of the camera and stuff it into my laptop. I will use my cell phone, and a USB connection to my laptop to provide myself "modem speed" Internet access so that I can upload my photos.

But wait - I can't upload these pictures in their native resolution (they're too big). So I wrote a script to use. This script requires that you have imagemagick installed, which can be added with "sudo apt-get install imagemagick" if you are running Debian/Ubuntu/etc.

# Image Resizing Made Fun
# http://steveballantyne.blogspot.com
#
# Set this as the path to where your picture card is/gets mounted
cameracard="/media/disk"
# If you want your resized images to have a prefix, set that here
prefix="beavermi_"
# Create a subdirectory in your home directory, which will contain
# folders with the MMDDYY directories beneath it.
subdir="to-post"
# Choose your resize percentage
resizevalue="25%"
# Create a folder under subdir with a date code in this format: MMDDYY
newdir=`date +%m%d%y`
mkdir -p $HOME/$subdir/$newdir
# Perform all the resizing work
for i in `ls $cameracard`; do convert -resize $resizevalue -quality 80 $cameracard/$i $HOME/to-post/$newdir/$prefix_$i; done

In a nutshell, it does a listing of all the pictures on my memory card. Then one by one it resizes the pictures to 25 percent of their original size, at 80 percent the quality. I am using 'convert' and not 'mogrify' here. The difference is that this will not affect the original photos. When done, I will have a folder of pictures that will be small enough to share in my online gallery.

I also wanted to script the process of uploading the pictures ... but this proved to be a bit more difficult. There are scripts out there for uploading to online galleries but none for Blogger/Picassa.

Perhaps I will work on that later.

Green Wallpapers

Do you like green wallpapers? You are not alone. There seems to be an abundance of lovely chloroform laced wallpapers out there. Some of the extreme close-up photography has got me asking "did nature make that?". Whether you are just celebrating the outdoors or you are sick of that ugly field in Windows XP ... here are some green wallpapers that are sure to please.

I have linked all of these thumbnails to their homes on Interfacelift.com which features some of the most stunning photography I've ever seen. And yes, they have wallpaper in your size (including wide screen displays).



Still need more green? Try this search!

*NEW* I will be getting an EEE PC soon to use at work. If you have an EEE PC, and are looking for some nice green wallpaper, look no further. Download this zip package which includes all the above wallpaper which I have scaled and cropped to fit the 800x480 dimensions of the screen.

-Steve Ballantyne

Fun with Screenlets in Ubuntu

If you're not big on eye candy, this software likely won't "do it for you". In the spirit of things that you really don't need cluttering up your desktop - I bring you "Screenlets". The idea is that a Screenlet is a desktop widget. These widgets range from things that you might want to keep at arms length, to silly gadgets that might entertain the duller moments of your day. These widgets can be "locked down" so that they become active elements of your wallpaper (more or less). If you have used Windows Vista or modern versions of OS X you should be familiar with this concept. Most folks keep their widgets floating around the right edge of their screen.

Admittedly this whole concept is growing old but I was impressed with how easy it is to install Screenlets in Ubuntu, add a collection of fun gadgets, and perhaps even create your own. Screenlets are written using the popular Python scripting engine. While I have had bad luck with similar widget engines in the past, it seems that using common libraries and Python elements has allowed the desktop widget concept to become stable and usable. I have played with these same widgets for several days and have yet to crash anything, or suffer through any error messages.

You can install Screenlets in Ubuntu with a single command in terminal:
sudo apt-get install screenlets

The above will also add all the supporting libraries, and the default "base" of Screenlets to begin using. It's likely that whatever you had in mind comes in the default Screenlet collection. If not, there are few hundred more available from http://www.screenlets.org. There's a large community of widget developers and users out there sharing their ideas.

Once you have installed Screenlets, you can begin adding your widgets using the Screenlets Manager. To access the manager, click System > Preferences > Screenlets. You may also use a "Screenlets Daemon" icon which should appear in the upper right hand corner of your display near the time and volume control slider.

Here you can select a Screenlet, and click "Add" to the right. It should immediately appear on your Desktop. From there you should be able to slide them around by clicking and dragging on them. With a right-click you will find options to change the size of the widget, decide if they should linger on top or underneath your windows, and even "lock" them into place to prevent the accidental sliding around of them. I installed a few common Screenlets and took this screen shot.



These widgets are pretty large on my desktop. The only one I really refer to often is the old analog clock. It's nice to have an analog clock, with the correct time displayed on it. We actually have three analog clocks in my department at the office. They are all battery operated, and each keep their own time. One has recently quit all together, and rather fuss with it I have decided that this clock should display "important times in nerd history". This weeks theme was Back to the Future. I'm waiting for the strike of lightning that will take Marty back to 1985.



Now, go get busy cluttering your desktop with stupid eye candy. It's time well wasted.

-Steve Ballantyne