Jan-Piet Mens

deepOfix is a mail server in a box licensed under the GPL.

deepOfix is LDAP-driven with an OpenLDAP server, brings SpamAssassin and ClamAV support with it and offers Webmail and the ubiquitious SMTP, POP3 and IMAP services.

I spent an hour test driving this software and it looks good. A clean web interface to manage the lot, shell access for root and optionally for individual users offer what a small business would need.

Note to self: keep an eye on this project.

I need to provide secure file copy to clients, simultaneously forbidding them to log in to our systems. To this effect I'm looking at rssh, the restricted shell for use with OpenSSH and the other alternative known to me, which is scponly.

Both tools do their job. rssh is more flexible in its configuration, and I know for a fact that it is also used by some large Internet Service Providers (ISP). Both tools support chroot jails which is good.

rssh appears to have the better logging features, but it lacks subdirectories in chroot jails.

On the other hand, scponly supports home-directories in the chroot environment with the // syntax (/var/chroot//home/jpm), meaning the chroot jail is in /var/chroot and the initial working directory is in /home/jpm thereunder. Unfortunately, there is no way to lock a user into the jailed home except by restricting permissions of the directories above (more like security through obscurity). I could of course create a chroot for each user, but that is cumbersome and a huge waste of disk space…

I've tested both tools with OpenSSH's SFTP, as well as with Windows versions of WinSCP and FileZilla without any issues, but I still have to make up my mind on which to use.

This book fully covers the ground in securing a Linux system. Hardening Linux by James Turnbull (who also authored Pro Nagios 2.0) packs all you need to know about getting a Linux system secured into a single five-hundred page volume.

Turnbull takes the reader in a fast-paced but very comprehensive fashion through the arduous tasks of closing up the open holes in a Red-Hat or Debian – based Linux distribution, and he covers all major topics which include unlikely candidates such as the virtual terminals on the console, immutable files and capabilities, system logging, rootkits, and penetration detection and recovery.

After reading up on the basics which include users & passwords, Pluggable Authentication Modules (PAM), and information on hardening the Linux kernel and the boot loaders, the reader gets an excellent introduction to firewalling with iptables with a whole firewall script for a bastion host in the appendix. That is followed by a full chapter devoted to securing connections with SSL/TLS and remote administration with ssh.

Chapter four is dedicated to securing files and file systems, and includes a section on encrypted file systems to safekeep your data, as well as a walk-through Tripwire. That is followed by a comprehensive look at logging with syslog and syslog-ng, and this chapter includes a discussion and tools related to log analysis and correlation.

NMAP, Nessus and network sniffers make up the bulk of the security testing tools with which Turnbull rightly suggests we check our work after having hardened the basic system. These are covered on fourty pages.

Although Mr. Turnbull recommends Postfix, he covers both that and Sendmail, carefully noting that he doesn't want to contribute to the "my mail server is better than yours" wars. On over fifty pages, the two mail transport agents (MTA) are given careful consideration as to making them as secure as possible. In a further chapter aptly titled Authenticating and Securing Your Mail, the author covers SSL/TLS certificate generation with OpenSSL as well as SMTP authentication (SMTP AUTH) with Cyrus SASL, for both flavors of mail server.

As far as access to mail is concerned, the Cyrus IMAP server is well documented in chapter nine, and the last two chapters guide the reader through securing FTP servers as well as the BIND name server.

Every person responsible for installing a Linux server must read this book! There is of course also detailed information to be gathered from dedicated books which cover the individual subsystems (such as those for DNS & BIND, OpenSSH, etc.), but I strongly encourage every system administrator to have a copy of this excellent book on his or her desk.

Our VMware appliance DAD/miniDAD, the LDAP-controlled CentOS server with embedded preconfigured Ubuntu miniDAD clients that "know" how to contact DAD is still available for download, and we'd appreciate some feedback.

The combination of the two appliances in one is quite interesting, and they even contain an LDAP-controlled software distribution system we developed specially for DAD & miniDAD.

We've created DAD for the enterprise administrator who wants to easily deploy Open Source to the site's user-base and who wants a migration path. All utilities supplied with DAD are geared towards making the process both painless and efficient. We've even included a utility which, when run on a Windows server, will export a list of users in such a way as that these can easily be imported into DAD. Alternatively, an NT trust can be set up between DAD and the Windows world.

If you are new to OpenSSH, don't let the "Pro" in the title scare you off; the first half of the 270-page book is just what you need: the first two chapters of Pro OpenSSH are of an introductory nature and introduce the reader to the insecurity of the legacy R-tools and telnet as well as a quick implementation of OpenSSH and a short introduction to the excellent PuTTY, an SSH client for Windows (this is expanded on in an appendix).

In part 2, Michael Stahnke discusses the configuration of OpenSSH starting with a detailed look at the files required by the client and the server portions of the program including manual-page-like descriptions of the keywords in sshd_config and the options and syntax of the command-line tools. The chapter on Authentication digs into Public Key Authentication, key generation and distribution as well as key management (also taken onto a new level in a later chapter), and agent forwarding. This is a must-read for anyone who uses SSH to connect to more than one host.

The advanced topics start in part 3, and this is where the "Pro" begins. The complex topic TCP forwarding is well explained and a number of diagrams help the reader to better understand the nitty-gritty of setting up tunnels with OpenSSH.

The most interesting chapter I found next; Managing your OpenSSH Environment, in which the author introduces an OpenSSH secure gateway that can be used in large environments. Securing OpenSSH, SSH- and Key-Management are followed by SSHFP (RFC 4255), a method to store public host keys in DNS. Stahnke implements a method for distributing public keys using RPM. Although that is interesting in itself, I strongly missed a discussion on storing SSH public keys in an LDAP directory; a must-have IMHO.

Part 4 of Pro OpenSSH deals with Administration. Sundry Shell and Perl scripts in real-world examples give the reader a good look into the capabilities of using OpenSSH in her own tools on her own systems. Last but not least, the appendices focus on alternative SSH clients and SSH on Windows.

Even if you have, like I have, already read SSH, The Secure Shell, Apress' Pro OpenSSH is well worth reading. I give it an 8/10.

I spend a good part of any day in my favorite web browser, and even if I don't see its whole window, the lower right part of the status bar is always visible under a pile of other application windows (mostly SSH sessions). That status bar is the ideal place to put up a small monitor with which I can keep an eye on a number of important servers, without having to wait for alerts sent to me by Nagios.

To this effect I have created a tiny Firefox and Thunderbird extension called whatmon, which can monitor almost anything you wish to monitor. Number of logged on users? Current load average? Health of your LDAP servers? Mail server queues? No problem for whatmon, as long as you can create a CGI program in Perl, C, or any other language you are comfortable with, or even a PHP or Active-Whatever script which runs on your web server and can produce a wee bit o' XML. There is one thing that whatmon can't watch: the web server from which it retrieves that XML …

whatmon periodically reads a short bit of XML text from a web server (in my case: Apache). The XML contains an integer status and a single line of text. In practice, that line of text can contain whatever the administrator desires. I want an indication of the health of the mail queues on a number of mail servers we have inhouse. The line of text therefore contains two-letter codes with which I can identify the hostname of the mail server in question as well as a count of mails on the queue for each of the servers in question.

The program that produces that line of text also returns a numeric integer indicating okay, warning or critical so that the extension can colour-code the status bar accordingly. Sample XML.

I've tried to keep this as simple as possible so as to not overcomplicate the extension proper (and because creating Mozilla extensions is about the worst I've ever had to do ). Each of the labels and values on the status bar could have been individually described in the extension, but then it would require modification whenever something changes. I didn't want that to happen.

The extension requires two preferences to be set. I've named these whatmon.url and whatmon.refresh. They are the URL from which the XML is to be read and the frequency in seconds in which the extension should do a GET request from the URL.

Use the configuration editor in Firefox or Thunderbird to create or change these settings. To call up the preference settings in Firefox, go to the URL about:config. In Thunderbird choose Tools => Options => Advanced => General => Config Editor. Create the two new settings by right-clicking on the page an choosing New => String. Enter whatmon.url as the preference name and the URL to your service (e.g. http://example.com/monit.php as its value. Repeat that step, for a new integer value, naming it whatmon.refresh and give it an integer number of seconds after which the extension should refresh the status bar. I'd think 120 or 60 should do the trick nicely. The preferences for whatmon should then resemble this:

After restarting Firefox or Thunderbird, whatmon will then periodically perform a GET request on the URL set in the whatmon.url preference.

The actual monitoring program is part of your web server, and it can be written in any language supported by the latter. It will return a tiny bit of XML text specifying both a status code and a string that whatmon will print to the status bar of Firefox or Thunderbird.

This simple example shell script displays the number of currently running processes on the server.

Visit fupps.com/extensions to download.

Can this be improved on? You bet! Firefox and/or Thunderbird need restarting whenever the URL preference changes. A nice options dialog with which the extension's preferences can be set would be welcome. Instead of plain text on the labels, I'd have liked to display images generated by the web server which change as the status changes. Any takers?

OpenSSH is the free version of the SSH suite of tools. Contrary to telnet or rlogin, ssh allows a user to safely connect to a remote system because all traffic (specially a user's credentials) are encrypted.

SSH also supports public-key authentication. Public-key authentication allows you to connect to a remote server without sending your password over the Internet. Public-key authentication uses two keys, a private key that only you have, and the public key, which is placed on the server you wish to gain access to, usually by yourself, adding your public key to the ~/.ssh/authorized_keys file. There is a nice introduction to public key authentication with SSH here, and another one here.

That is all very well when you only have a couple of machines you want to log in to, but what happens when you have dozens or more? You have to maintain your public keys on all those systems, ensuring they are kept up to date. God forbid that you loose your private key, or that it becomes compromised: you'd have to quickly change all the authorized_keys files on all machines!

Enter LDAP. Eric Auge has made a patch to OpenSSH which allows the SSH server (sshd) to read the public keys from an LDAP directory. I've tested it with OpenLDAP and the patch works like a charm.

After patching the source of portable OpenSSH (I used version 4.1p1) with Eric's OpenSSH LDAP Public Key Patch corresponding to the OpenSSH version you downloaded, it is a matter of following the good instructions in README.lpk, adjusting your ./configure invocation according to the flavor of the day. After building, installing and restarting the patched OpenSSH, ensure you can still log on to your system.

Now add the LDAP options to your sshd_config file, adjusting the settings to suit your LDAP directory information tree, and restart sshd. Add the schema file openldap-lpk.schema to your slapd.conf and restart your directory server.

Add an object of class ldapPublicKey to your LDAP user entry, ensuring that you also have a posixAccount (sshd constructs the LDAP search filter by and-ing both object classes and the userid of the person logging on), and add one or more sshPublicKey attribute types. My LDIF now looks like this:

dn: uid=jpm,ou=People,dc=fupps,dc=com
sn: Mens
cn: Jan-Piet Mens
gecos: JP Mens
uidNumber: 400
gidNumber: 400
uid: jpm
homeDirectory: /home/jpm
loginShell: /bin/bash
objectClass: inetOrgPerson
objectClass: person
objectClass: ldapPublicKey
objectClass: posixAccount
sshPublicKey: ssh-rsa CAr9x8...
sshPublicKey: environment="LDP_USER=jpm" ssh-rsa AAAAB...

I can now connect to all machines which have an sshd appropriately set up, without needing to distribute my public keys. [In case you are wondering about the environment option in the second public-key: that is for ldp, my LDAP distributed shell profile; have a look at that too!]

Isn't that insecure? Well, not if you are careful. sshd will only allow you to connect if you already a a "local" user (i.e. if sshd can find your username on the local system). That doesn't necessarily mean that you have an entry in /etc/passwd; it means that whatever underlying mechanism your systems use to determine whether your username is valid to log on to the machine, they have reported that you are a valid user. These mechanisms could be any combination of PAM, NSS, etc.

So before letting the OpenSSH LDAP Public Key Patch fly on your publicly accessible machines, do ensure you are careful during deployment.

Oh, and before you ask: if the LDAP directory server is unavailable, it will obviously not be able to return public keys. In that case, sshd falls back to the other mechanisms you've configured (i.e. password) and/or public-key authentication from ~/.ssh/authorized_keys. This ensures you won't be locked out in case the directory server goes South.

ldp (LDAP distributed profile) will read a user-specific shell profile (.profile) from an LDAP directory server upon login, allowing users (including multiple people operating as root) to always have the same settings irrespective of which machine they are working on. ldp also operates correctly when logging in via SSH via public key auth.

Used properly, any user logging on as root to a machine, can have her customized .profile loaded upon login instead of having to "share" a ~root/.profile or similar. That for me, is the end of having to put up with colleagues who prefer emacs mode in a bash.

I've submitted an initial announcement and a release of my distributed .profile from LDAP idea to freshmeat.net. I've put up quite an extensive document about ldp on my wiki (the home of ldp); do have a look & comment on it, please.

There are still some things pending: decent man pages, an import utility and perhaps profile storage in the user's real $HOME instead of in a spool directory. Anothing thing pending is my first freshmeat submission: it is still in the queue…

In any case, even though the whole thing is rather simple, I'm quite pleased with the result of ldp. I've been testing it from a number of different machines, and my life has changed for the better!