One afternoon, not so long ago, I received a phone call from one of our clients asking LightCube to investigate why a web application hosted on an internal Linux server was so unresponsive. After a little bit of poking around it became apparent what was happening: someone had managed to break into the system and create a rogue account for themselves and was using this account to continually attack other machines! How had this intruder gained access? One word: VNC.

Before I explain further how this happened, let’s step back for a second. Our client is a fairly large company, with skilled IT professionals managing their network infrastructure and services, mostly hailing from the Windows world. When they set about developing an internal web application, however, the low cost of Linux and Open Source was too attractive to ignore. So they grabbed a distro, set it up on a machine and got to work.┬áComing from a Windows world, the technicians incorrectly (but perhaps understandably) expected an item labeled “Remote Administration” would configure a service that behave like Windows Remote Desktop Connection. Instead, what they configured was a very insecure VNC service on a publicly available machine.

(As a sidenote, to me this well illustrates a very important point. The known stability, reliability and low-to-nil licensing cost of Open Source software means that a lot of people are looking to use it, and these days, basic services can be implemented fairly easily. However, getting secure, reliable, optimized use out of your Open Source still requires someone who knows what they’re doing.)

Back to the story, here’s what happened: One of their administrators logged in remotely to the machine through the VNC connection. As root. (That’s the first mistake, but I won’t really address that too much here. Keep in mind they’re coming from Windows, eh?) Then, when the administrator was done doing what he was doing, he simply closed the VNC window. In the Windows world, that wouldn’t be much of a problem. When connecting again, the Windows server would require that you authenticate. With VNC, not so much. Unless you log out of the remote system, whoever next comes and tries a VNC connection on the default ’0′ session – they get whatever you left open. If you were logged in as root, as was the case here, a full root desktop is what you get. “Come right inside, make yourself at home! Here’s the keys, change anything you like.”

Don’t misunderstand me. This isn’t a case of “Windows has better security than Linux”. I think someone would have a hard time arguing that point. This is a case of someone enabling an insecure protocol on a Linux system without really investigating how it works. To be fair, this particular distro did make it seem like this was a pretty standard way of remotely administering the machine. A little note from the distro about VNC being unencrypted and using poor session handling methods would have been more helpful, though.

We closed up the security holes on their system and ran a full audit. Fortunately, the damage was minimal. Afterwards, we needed to find an alternative for remote desktop management. What we found was NoMachine NX. All the communication takes place over an encrypted SSH connection, so it is secure (well, as secure as your password or public key, but that’s another article). But it’s also fast. NoMachine has taken a different approach to data transmission, such that it outperforms VNC any day. The server currently only runs on Linux or Solaris, but they have clients for all major desktops. If you absolutely must have a GUI running on your remote Linux server, I highly recommend NoMachine NX as a better way to achieve it.

Since I wrote the post ‘Clonezilla‘ in January, our blog has been getting a lot of hits, apparently from people looking for advice on how to set up Clonezilla. This is understandable, since DRBL (of which Clonezilla is just a piece) is a complex piece of work, with loads of possibilities. So I decided to write up a small HOWTO, a quick and dirty method of getting Clonezilla up and running.

Before I go on, a bit of a disclaimer: Following the instructions below may not provide you with results that fit your particular needs. If you have specific and detailed requirements, see the DRBL documentation. If you would like to hire LightCube Solutions to provide assistance in setting up a Clonezilla solution for your organization, send an email to info@lightcubesolutions.com.

The Steps

1. Install Linux

You’ll need a Linux machine to run your Clonezilla services. These instructions were successfully tested on Ubuntu 9.04 and 9.10 and Debian 5. DRBL will also run on Fedora.

2. Install DRBL

First off, open up a Terminal. In Ubuntu and Debian, this is located in ‘Applications -> Accessories -> Terminal’. If you have sudo configured, you can change to super-user access by typing:

sudo -i

Otherwise, use the root password with the following:

su -

Next, add DRBL’s GPG key to your system:

wget http://drbl.sourceforge.net/GPG-KEY-DRBL
apt-key add GPG-KEY-DRBL

Update your apt configuration so that you can install software from the DRBL guys:

cp /etc/apt/sources.list{,.bak}
echo "deb http://drbl.sourceforge.net/drbl-core drbl stable" \
  >> /etc/apt/sources.list

Finally, install DRBL:

apt-get update
apt-get install drbl

3. Configure a Network Alias

DRBL requires that you have two network interfaces. We can get around this by adding a virtual interface:

cat >> /etc/network/interfaces << "EOF"
auto eth0:1
iface eth0:1 inet static
   address 192.168.222.1
   netmask 255.255.255.0
EOF
ifup eth0:1

To verify that you have set up the alias properly, type:

ip addr show eth0 | grep eth0:1

You should see something like this:
inet 192.168.222.1/24 brd 192.168.222.255 scope global eth0:1

4. Configure Your New DRBL Server

Run the following two interactive commands (note that this will require an internet connection and may take some time):

/opt/drbl/sbin/drblsrv -i
/opt/drbl/sbin/drblpush -i

Congratulations! That’s it, you have a DRBL/Clonezilla server ready to create and deploy custom images. All you need to do to start cloning is run:

/opt/drbl/sbin/dcs

Then, boot up your client machines using PXE. See, that wasn’t too painful…

If you have a Unix or Linux background, scripting should be second nature to you. Even ‘Windows Gurus’ usually do some little bit of automation with custom scripts. The power and flexibility that comes with the command line is hard to ignore, once you’ve tasted it. Still, those who have tasted both a Unix-type shell and the Windows command line will generally agree, Unix has the advantage here.

Although there are ways to do in Windows some of the things possible with Unix tools, it’s quite a bit more cumbersome. By taking advantage of Cygwin, you can bring that power and flexibility to Windows. A simple example of how I have used Cygwin alongside Windows tools involves Active Directory user creation, deletion and modification. The tools provided in Cygwin allow you to do advanced pattern matching and generate a list of users, file paths, etc., and then using the Bash shell, it is simple to create the logic necessary to call the Windows command line tools for modification of Active Directory. With the arsenal of useful tools that become available to Windows by using Cygwin, the possibilities for better automation grow considerably.

The Advanced Bash-Scripting Guide offers a great starting place for increasing your ability to write useful and powerful scripts.

No blog of mine would be complete without a reference of some sort to Linux From Scratch. If you’ve never heard of it before, Linux From Scratch (LFS) is an online community that produces a book containing instructions on how to create your own complete, functioning and customized Linux system by hand. As you follow the instructions in the book, you compile all the software from source code and manually create nearly every configuration file within your system.

Apart from creating a lightweight, reasonably secure, custom system and the pride of knowing that you made it all happen, as you go through the book you also get a good picture of what makes a Linux system tick.

Personally, because of the LFS project, my abilities in shell scripting and the Unix command line increased dramatically. This, in turn, led to my being able to contribute back to the project. I initiated the LFS LiveCD subproject, created and introduced to the community a program called jhalfs that automates the LFS building process (it has since been revised by a few talented individuals), and even helped develop the actual LFS book (a copy with some personal changes lives here). It was a fun ride.

LFS continues to receive good reviews as there appears to be many who enjoy the experience of customizing completely their own personal Linux system. Here’s a recent article that contains a fairly thorough review. The section on LFS begins on page 3.

If you’re a system admin, charged with deploying workstations, likely you have need of a cloning system. In the Windows world, that system is predominantly Symantec Ghost. Perhaps you’re like me and have noticed how much a pain in the backside Ghost is. Specifically, it can be difficult to set up a bootable image with the right network drivers for your hardware. Also, Ghost is notorious at hanging when one client fails to participate properly in the multicast deployment.

In walks DRBL (Diskless Remote Boot in Linux). Essentially, DRBL allows you to remotely boot an entire Linux OS across the network. The useful possibilities that offers are quite extensive. But the use I’m highlighting here is what DRBL calls “Clonezilla”. Using open source NTFS tools, DRBL in Clonezilla mode allows you to take a snapshot of a partition or entire disk and then multicast that out to many clients. The advantage of doing this in Linux is the modularity of its kernel and support for a wide range of hardware, all in one easily distributable system.

It can take a bit of skill to get DRBL set up correctly, but once you do, the advantages over such a narrow and closed piece of software as Ghost make the effort well worthwhile.


JH