Archive for October, 2013|Monthly archive page

A very restricted shell

I was recently asked to set up access for someone so that he could connect from the internet to a machine running on our company network. Securing the machine on the company network was easy enough but I needed to create a route through to it.
The approach I took was to build a CentOS 6 machine running sshd which was accessible via a NAT rule on our outside firewall to act as a gateway to our network. This meant that the computer to which the user wanted to connect wasn’t directly accessible via the internet which made me happier.

The user had to forward a local port to the required port on the computer he wanted to access on our network. In other words, conventional ssh tunnelling and port forwarding. As a further security restriction, on the gateway computer I used the local iptables firewall to restrict not just the inbound traffic, but the outbound as well, only opening the ports that were needed.

I also decided I wanted to restrict the shell that the user was given on the computer he connected to via ssh. The restricted bash option seemed reasonable (i.e. bash -r option) but even that allowed more than was needed. My solution was to write a very simple c program that acted as the most restricted shell I could think of, i.e. it understands one command only – “exit”.

File: smallsh.c

#include <stdio.h>
#include <string.h>

/* Very simple command shell. Only supports one command "exit". */
/* Output is inelegant if the user types more than 60 chars as command */

/* Version 1.0 14/10/2014 */

  const char cmdEXIT[5] = "exit\n";
  char userCmd[60];
  printf ("Type exit when done\n$ ");
  while (fgets(userCmd, sizeof userCmd, stdin)) {
    if ( ! strncmp( cmdEXIT, userCmd, 5 ) ) {
    } else {
      printf ("I only understand 'exit'\n$ ");

When this was compiled, I moved the result (smallsh) to /usr/local/bin. The program is simple, and if the user types more than 60 characters in a single command at the input prompt the output doesn’t look elegant, but I, and he, can live with that!

The suitable user account was created on the gateway machine with:

useradd -m -d /home/<username> -s /usr/local/bin/smallsh <username>

The sshd_config file then needed the following settings changed from the default and the sshd service needed restarting.

PermitTunnel yes
AllowUsers <usernname>
PermitRootLogin no

(OK, I’ll accept that “PermitRootLogin no” is not needed, but as far as I’m concerned it is).


The end of XP

Smugness isn’t an emotion I often feel about my work, but I’m feeling pretty smug today. I took on the job of getting rid of Windows XP a few months ago and I finished yesterday. Compared to a lot of companies, I’m sure I had an easy job but the 80/20 rule certainly applied. The 80% were easy to work out how to upgrade, the last 20% much less so. Everyone in the company is now using Windows 7, mostly 64bit with the odd 32bit installation here and there for historic reasons. (Personally, I’m using CentOS 6.4, 64bit – but that’s another story.)

Mostly, user’s desktops and laptops had been replaced sufficiently recently that they were already on Windows 7. Vista didn’t exist for us. Any machines bought in that short, unpleasant period were downgraded to XP. In those cases a Windows 7 installation was simple enough. Most Windows machines benefit from a fresh installation every so often anyway, although because no two machines were the same, each had to be installed and then updated individually. That’s a dreadful process, even when you start from the most recent service pack. When you add Office as well, it can be over 10 reboots to get the machine fully patched.

The stability and excellence of VMWare was the cause of some of XP machines I had to deal with. A number of physical machines running XP had been sucked into VMWare over the years as the hardware they ran on started to fall apart. Rather than scrapping the machines and moving the software and services they ran elsewhere, it was just so much easier to virtualise them. Of course, this means they would virtually (if you’ll excuse the pun) run for ever, occasionally moving from ESXi host to ESXi host as the hosts themselves got replaced.

I was told something very early on in my working life by a very diligent, hard working colleague. It is that if you put something in your in-tray and leave it for a while, a good number of tasks just go away without you ever having to look at them. As I got to know this particular person, I couldn’t imagine him ever ignoring something in his in tray, but what he said certainly turned out to be true about a number of the old XP machines that had been turned into virtual machines. When I challenged people to explain what they needed a particular machine for, often it turned out the case for keeping them was remarkably thin or in some cases forgotten completely.

I did have to build a new print server but I was able to get rid of a few ancient printers that it turned out no one had used for ages. People might complain about having to walk further to collect a printout but mostly people like to use the printer that prints best. The nearer, rather crusty printer that gives poorer quality printing tends just to get ignored. The “spare/broken” hardware room is quite full now. The print server build turned out to be quite straight forward because the number of desktop O/S variants is as low as it will ever be. This was definitely the time to learn how to build a print server.

As I got down the the last XP virtual machine I knew it was going to a challenge. It ran some software to monitor and manage a particular piece of hardware. The hardware is still a current model (something we had provided, not something we specified). The software was written in Visual Basic, probably version 6, but quite possibly earlier. It uses DAO and an Access version 3.5 database (yeah, really). I contacted the hardware vendor directly and they supplied a Windows 7/8, 64bit version of the software. It took 3 hours and 6 emails each way but we finally got it working. It’s still an awful bit of software but by the time I got to the end of the project I just wanted this stuff to run, pretty didn’t matter.

So what about conclusions? Well everyone will say the same thing – don’t leave this to the last minute. However, I’d say don’t fear it either. For us, it turned out to be a very good clearing out exercise. Very much more so than I imagined it would be. It made me dig into all the quiet corners of our infrastructure and understand just about everything we have running. As of today, the infrastructure is a lot better understood and documented than it has ever been. The challenge now is to keep it that way.