Paranoid Penguin - Security Features in Ubuntu Server

As I've often said, security begins with operating system installation. This is where you decide your system's role, what set of applications will run on the machine, and what type and degree of user access it will support. So, to what degree does the Ubuntu Server installer help system security?

The Ubuntu Server installer is very similar to the Ubuntu Desktop installer, except that the Server installer is, if anything, even more minimalist. It guides you through partitioning your hard disk, asks what category of software packages to install, walks you through creating a login account (not root), installs the software, and then, depending on what you installed, it may or may not ask you a few very basic questions with which it begins (barely) configuring one or more of those applications.

Figure 1. Ubuntu Server installer offers encrypted volumes.

The good news is that the Ubuntu Server installer:

The bad news is that the Ubuntu Server installer:

Figure 2. Selecting Server Software Bundles

After installation, you may notice that most if not all the server applications you installed (Apache, Postfix and so forth) are up and running, even though you haven't really configured them yet. You'll need to do that yourself by editing the appropriate configuration files in /etc.

On the one hand, my personal preference is that, by default, network services should be disabled initially, to make it harder for an attacker to exploit an application that has been overlooked altogether or that is still in the process of being configured. On the other hand, because Ubuntu's default application configurations tend to be fairly secure, this probably doesn't pose a huge risk.

For example, immediately after installation, Apache is started, displaying a simple “It works!” page, which announces to the world that you've just installed Apache but haven't gotten around to configuring it yet. (Ow!) But, there's no obvious way for an attacker to exploit this. You can't recurse out of the nearly empty default http root directory, default CGI scripts aren't present and so on.

If you're worried about this, you simply can shut down these newly installed services until you've configured them. Or, better still, stage your new server on a protected LAN before connecting it to the Internet.

As I explained in last month's column, Ubuntu is set up so that you never can actually log on as root. Instead, you create one or more nonprivileged login accounts that are authorized to execute root-privileged commands via sudo, the “superuser do” command. This makes it harder to damage your system accidentally, and it has the security benefit of removing the root account as a viable attack vector, because root has no password and can't log in.

So, for example, whereas on a standard Debian system you might install the package foo with this command:

aptitude install foo

On Ubuntu, you'd use:

sudo aptitude install foo

After issuing any command with sudo, you'll be prompted for your own password, not root's, which will be cached for a brief period of time during which subsequent sudo commands won't require re-authorization.

If you need to change sudo's configuration (which determines who is authorized to run which commands, under what circumstances), you must use the visudo command to edit the file /etc/sudoers. The Ubuntu RootSudo Page (see Resources) provides more information.