I recently bought a decTOP small form factor (SFF) computer. My goal was to build a cheap, fanless, quiet, and low power consumption Linux server. For $99 plus the cheapest available shipping, $40, my machine arrived 11 days after I placed the order.

This is a tiny computer, about the size of a Mac Mini. But, because it has no fan, it runs a bit quieter and, with the help of a 1-watt, 366 MHz CPU, consumes only 8 watts. For comparison, the G4 Mac Mini consumes about 20-30 watts, depending on load.

The decTOP comes with 128 MB of RAM in its sole SO-DIMM slot and a 10 GB 3.5 inch hard drive. I understand that it's a simple matter to replace the drive and to upgrade the memory to a maximum of 512MB.

It also comes with no operating system and the ability to boot only from a USB drive. This article details the steps I used to build the USB boot/installation drive and install Ubuntu 6.06 on the decTOP.

There is another article -- with additional decTOP links -- here on installing Ubuntu 6.06 on the decTOP with the aid of a Windows system. Fortunately ;), I run Mac OS X and Linux (Ubuntu 7.04), so that article didn't work for me. I did the installation of the Ubuntu 6.06 LTS Server Edition using my Ubuntu Linux box and a 1 GB USB flash drive -- although a 512 MB USB drive should work as well.

1. Download the Ubuntu 6.06 server ISO image from the Ubuntu download page. Depending on your plans for the decTOP, you might want to choose the desktop version. Unless you have already upgraded your decTOP's memory, however, you'll want to stick with the 6.06 releases.
   
   
2. Install the mbr, mtools, and syslinux packages on the Linux system you'll be using to prepare the USB drive. If you run Ubuntu or some other Debian-derived system, the following commands may do the work for you.

   apt-get install mbr
   apt-get install mtools
   apt-get install syslinux

3. Partition the USB drive with a single FAT-16 partition. I used the fdisk 'n' command to make the new primary partition 1. The fdisk 't' command can be used to change the partition type to FAT-16. My device name was /dev/sda.

   fdisk /dev/sda

4. Make the FAT-16 partition the active partition. I used the fdisk 'a' command.
   
   
5. Install a master boot record on the USB drive.

   install-mbr /dev/sda

6. Install syslinux on the USB drive. Note that the USB drive should not be mounted when you do this.

   syslinux -s /dev/sda1

7. Create a mountpoint and mount the ubuntu ISO image using the loopback device.

   mkdir /iso
   mount -o loop -t iso9660 ubuntu.iso /iso

8. Create a mountpoint and mount the USB flash drive.

   mkdir /usb
   mount /dev/sda1 /usb

9. Copy the contents of the ISO image to the USB drive. This will take some time.

   cd /iso
   cp -r . /usb/

10. Copy the /usb/dists/dapper directory into a new /usb/dists/stable directory.

    cd /usb/dists/
    cp -r dapper/* stable

11. Copy several files from /usb/install to the /usb root directory.

    cp /usb/install/vmlinuz /usb/
    cp /usb/install/mt86plus /usb/
    cp /usb/install/initrd.gz /usb/

12. Install the following text into a file named syslinux.cfg in the /usb root directory.

    default vmlinuz
    append initrd=initrd.gz ramdisk_size=24000 root=/dev/ram rw

13. Flush all writes, unmount, and remove the USB drive. After the sync step, wait for all of the data to be written to the USB drive.

    sync;sync
    umount /usb

14. Connect the ethernet adapter to the decTOP and connect it to your network to allow automatic configuration of the network interface.
    
    
15. Insert the USB drive into the decTOP and power it up. The decTOP should automatically boot from the USB drive and start the Ubuntu installation.
    
    
16. Answer only the first two questions concerning language selection and go to the next step, below.
    
    
17. Press Alt-F2 (hold down the Alt key and press the F2 function key) to open a shell. Then press enter to start the shell.
    
    
18. Create a /cdrom and a /dev/cdroms directory in the installation ramdisk

    mkdir /cdrom /dev/cdroms

19. Go to the /dev/cdroms directory and build a symlink from /dev/sda1 (that is likely the device name of your USB boot partition) to /dev/cdroms/cdrom0.

    cd /dev/cdroms
    ln -s ../sda1/cdrom0

20. While still in the shell, mount the USB drive to mimic an installation CD-ROM.

    mount -t vfat /dev/cdroms/cdrom0 /cdrom

21. Return to the installation program with Alt-F1 and continue the installation.

From this point, the process should be identical to a routine CD-ROM installation.

For a grand total of $140 and 8 watts of power consumption, I now have a near-silent Linux server running 24/7. You can telnet to it here and marvel at its blinding speed running a 250,000-sector Space Tyrant game.

tar xzvf axigen-2.0.4.i386.rpm.gcc4.tar.gz

rpm -ivh axigen-2.0.4.gcc4-1.i386.rpm

/opt/axigen/bin/axigen-cfg-wizard

/etc/init.d/axigen start

Connecting to ClamAV

yum install clamav-server

cp /usr/share/doc/clamav-server-*/clamd.conf /etc/clamd.d/axigen.conf

# comment out the Example line 
# Example 
# insert/modify the following lines: 
LogFile /var/log/clamd.axigen 
PidFile /var/run/clamd.axigen/clamd.pid 
LocalSocket /var/run/clamd.axigen/clamd.sock 
User axigen 

ln -s /usr/sbin/clamd /usr/sbin/clamd.axigen

mkdir -p /var/run/clamd.axigen chown axigen:axigen /var/run/clamd.axigen

cp /usr/share/doc/clamav-server-*/clamd.init /etc/init.d/clamd.axigen 
chmod 755 /etc/init.d/clamd.axigen /sbin/chkconfig clamd.axigen on

# description: The clamd server running for axigen CLAMD_SERVICE=axigen

/etc/init.d/clamd.axigen

Connecting to SpamAssasin

yum install spamassassin

• Enter a different priority value for the SpamAssasin filter (if you have chosen 10 for ClamAV, choose a higher value for SpamAssassin in order to apply this filter after ClamAV in the filtering chain)
• Select the corresponding filter name, spamassassin in the Filter name list

Access AXIGEN WebMail

SquirrelMail Installation

1. A PHP enabled web server (Apache 1.3/Apache 2.0 are commonly used).
2. PHP version 4.1.2 or higher.
3. Perl installed and running for the initial configuration.

SquirrelMail Configuration

Different set-up configurations for AXIGEN WebMail

Conclusion

SSL Encrypting Syslog with Stunnel

Written by Rainer Gerhards (2005-07-22)

Abstract

In this paper, I describe how to encrypt syslog messages on the network. Encryption is vital to keep the confidiental content of syslog messages secure. I describe the overall approach and provide an HOWTO do it with the help of rsyslogd and stunnel.

Background

Syslog is a clear-text protocol. That means anyone with a sniffer can have a peek at your data. In some environments, this is no problem at all. In others, it is a huge setback, probably even preventing deployment of syslog solutions. Thankfully, there is an easy way to encrypt syslog communication. I will describe one approach in this paper.

The most straigthforward solution would be that the syslogd itself encrypts messages. Unfortuantely, encryption is only standardized in RFC 3195. But there is currently no syslogd that implements RFC 3195's encryption features, so this route leads to nothing. Another approach would be to use vendor- or project-specific syslog extensions. There are a few around, but the problem here is that they have compatibility issues. However, there is one surprisingly easy and interoperable solution: though not standardized, many vendors and projects implement plain tcp syslog. In a nutshell, plain tcp syslog is a mode where standard syslog messages are transmitted via tcp and records are separated by newline characters. This mode is supported by all major syslogd's (both on Linux/Unix and Windows) as well as log sources (for example, EventReporter for Windows Event Log forwarding). Plain tcp syslog offers reliability, but it does not offer encryption in itself. However, since it operates on a tcp stream, it is now easy to add encryption. There are various ways to do that. In this paper, I will describe how it is done with stunnel (another alternative would be IPSec, for example).

Stunnel is open source and it is available both for Unix/Linux and Windows. It provides a way to use ssl communication for any non-ssl aware client and server - in this case, our syslogd.

Stunnel works much like a wrapper. Both on the client and on the server machine, tunnel portals are created. The non-ssl aware client and server software is configured to not directly talk to the remote partner, but to the local (s)tunnel portal instead. Stunnel, in turn, takes the data received from the client, encrypts it via ssl, sends it to the remote tunnel portal and that remote portal sends it to the recipient process on the remote machine. The transfer to the portals is done via unencrypted communication. As such, it is vital that the portal and the respective program that is talking to it are on the same machine, otherwise data would travel partly unencrypted. Tunneling, as done by stunnel, requires connection oriented communication. This is why you need to use tcp-based syslog. As a side-note, you can also encrypt a plain-text RFC 3195 session via stunnel, though this definitely is not what the protocol designers had on their mind ;)

In the rest of this document, I assume that you use rsyslog on both the client and the server. For the samples, I use Debian. Interestingly, there are some annoying differences between stunnel implementations. For example, on Debian a comment line starts with a semicolon (';'). On Red Hat, it starts with a hash sign ('#'). So you need to watch out for subtle issues when setting up your system.

Overall System Setup

In ths paper, I assume two machines, one named "client" and the other named "server". It is obvious that, in practice, you will probably have multiple clients but only one server. Syslog traffic shall be transmitted via stunnel over the network. Port 60514 is to be used for that purpose. The machines are set up as follows:

Client

• rsyslog forwards  message to stunnel local portal at port 61514
• local stunnel forwards data via the network to port 60514 to its remote peer

Server

• stunnel listens on port 60514 to connections from its client peers
• all connections are forwarded to the locally-running rsyslog listening at port 61514

Setting up the system

For Debian, you need the "stunnel4" package. The "stunnel" package is the older 3.x release, which will not support the configuration I describe below. Other distributions might have other names. For example, on Red Hat it is just "stunnel". Make sure that you install the appropriate package on both the client and the server. It is also a good idea to check if there are updates for either stunnel or openssl (which stunnel uses) - there are often security fixes available and often the latest fixes are not included in the default package.

In my sample setup, I use only the bare minimum of options. For example, I do not make the server check client cerficiates. Also, I do not talk much about certificates at all. If you intend to really secure your system, you should probably learn about certificates and how to manage and deploy them. This is beyond the scope of this paper. For additional information, http://www.stunnel.org/faq/certs.html is a good starting point.

You also need to install rsyslogd on both machines. Do this before starting with the configuration. You should also familarize yourself with its configuration file syntax, so that you know which actions you can trigger with it. Rsyslogd can work as a drop-in replacement for stock sysklogd. So if you know the standard syslog.conf syntax, you do not need to learn any more to follow this paper.

Server Setup

At the server, you need to have a digital certificate. That certificate enables SSL operation, as it provides the necessary crypto keys being used to secure the connection. Many versions of stunnel come with a default certificate, often found in /etc/stunnel/stunnel.pem. If you have it, it is good for testing only. If you use it in production, it is very easy to break into your secure channel as everybody is able to get hold of your private key. I didn't find an stunnel.pem on my Debian machine. I guess the Debian folks removed it because of its insecurity.

You can create your own certificate with a simple openssl tool - you need to do it if you have none and I highly recommend to create one in any case. To create it, cd to /etc/stunnel and type:

openssl req -new -x509 -days 3650
-nodes -out stunnel.pem -keyout stunnel.pem

That command will ask you a number of questions. Provide some answer for them. If you are unsure, read http://www.stunnel.org/faq/certs.html. After the command has finished, you should have a usable stunnel.pem in your working directory.

Next is to create a configuration file for stunnel. It will direct stunnel what to do. You can used the following basic file:

; Certificate/key is needed in server mode
cert = /etc/stunnel/stunnel.pem

; Some debugging stuff useful 
; for troubleshooting
debug = 7 foreground=yes

[ssyslog]
accept  = 60514
connect = 61514

Save this file to e.g. /etc/stunnel/syslog-server.conf. Please note that the settings in italics are for debugging only. They run stunnel with a lot of debug information in the foreground. This is very valuable while you setup the system - and very useless once everything works well. So be sure to remove these lines when going to production.

Finally, you need to start the stunnel daemon. Under Debian, this is done via "stunnel /etc/stunnel/syslog.server.conf". If you have enabled the debug settings, you will immediately see a lot of nice messages.

Now you have stunnel running, but it obviously unable to talk to rsyslog - because it is not yet running. If not already done, configure it so that it does everything you want. If in doubt, you can simply copy /etc/syslog.conf to /etc/rsyslog.conf and you probably have what you want. The really important thing in rsyslogd configuration is that you must make it listen to tcp port 61514 (remember: this is where stunnel send the messages to). Thankfully, this is easy to achive: just add "-t 61514" to the rsyslogd startup options in your system startup script. After done so, start (or restart) rsyslogd.

The server should now be fully operational.

Client Setup

The client setup is simpler. Most importantly, you do not need a certificate (of course, you can use one if you would like to authenticate the client, but this is beyond the scope of this paper). So the basic thing you need to do is create the stunnel configuration file.

; Some debugging stuff 
; useful for troubleshooting
debug = 7
foreground=yes

client=yes

[ssyslog]
accept  = 127.0.0.1:61514
connect = 192.0.2.1:60514
 

Again, the text in italics is for debugging purposes only. I suggest you leave it in during your initial testing and then remove it. The most important difference to the server configuration outlined above is the "client=yes" directive. It is what makes this stunnel behave like a client. The accept directive binds stunnel only to the local host, so that it is protected from receiving messages from the network (somebody might fake to be the local sender). The address "192.0.2.1" is the address of the server machine. You must change it to match your configuration. Save this file to /etc/stunnel/syslog-client.conf.

Then, start stunnel via "stunnel4 /etc/stunnel/syslog-client.conf".  Now you should see some startup messages. If no errors appear, you have a running client stunnel instance.

Finally, you need to tell rsyslogd to send data to the remote host. In stock syslogd, you do this via the "@host" forwarding directive. The same works with rsyslog, but it suppports extensions to use tcp. Add the following line to your /etc/rsyslog.conf:

*.*  @@127.0.0.1:61514 

Please note the double at-sign (@@). This is no typo. It tells rsyslog to use tcp instead of udp delivery. In this sample, all messages are forwarded to the remote host. Obviously, you may want to limit this via the usual rsyslog.conf settings (if in doubt, use man rsyslog.con).

You do not need to add any special startup settings to rsyslog on the client. Start or restart rsyslog so that the new configuration setting takes place.

Done

After following these steps, you should have a working secure syslog forwarding system. To verify, you can type "logger test" or a similar smart command on the client. It should show up in the respective server log file. If you dig out you sniffer, you should see that the traffic on the wire is actually protected. In the configuration use above, the two stunnel endpoints should be quite chatty, so that you can follow the action going on on your system.

If you have only basic security needs, you can probably just remove the debug settings and take the rest of the configuration to production. If you are security-sensitve, you should have a look at the various stunnel settings that help you further secure the system.

Preventing Systems from talking directly to the rsyslog Server

It is possible that remote systems (or attackers) talk to the rsyslog server by directly connecting to its port 61514. Currently (Jule of 2005), rsyslog does not offer the ability to bind to the local host, only. This feature is planned, but as long as it is missing, rsyslog must be protected via a firewall. This can easily be done via e.g iptables. Just be sure not to forget it.

Conclusion

With minumal effort, you can set up a secure logging infrastructure employing ssl encrypted syslog message transmission. As a side note, you also have the benefit of reliable tcp delivery which is far less prone to message loss than udp.

Feedback requested

I would appreciate feedback on this tutorial. If you have additional ideas, comments or find bugs (I *do* bugs - no way... ;)), please let me know.

Revision History

• 2005-07-22 * Rainer Gerhards * Initial Version created
• 2005-07-26 * Rainer Gerhards * Some text brush-up, hyperlinks added
• 2005-08-03 * Rainer Gerhards * license added

Copyright

Copyright (c) 2005 Rainer Gerhards and Adiscon.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be viewed at http://www.gnu.org/copyleft/fdl.html.