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.
The good news is that the Ubuntu Server installer:
Can create encrypted disk volumes.
Doesn't ask you for a root password, because you never log on as root in Ubuntu.
Is surprisingly fast, obviously thanks to its simplicity.
Generally installs things with conservative, fairly secure, default settings (which is actually a function of packages' individual installation scripts).
The bad news is that the Ubuntu Server installer:
Doesn't allow you to select specific/individual software packages; instead, it just asks you the general role the server will play (Figure 2).
Prompts you for the MySQL administrator's password, but doesn't prompt you a second time to make sure you didn't mistype it.
Doesn't check passwords for complexity (uppercase/lowercase, numerals and so forth).
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.
- Smoothwall Express
- Machine Learning Everywhere
- Own Your DNS Data
- Bash Shell Script: Building a Better March Madness Bracket
- Simple Server Hardening
- Returning Values from Bash Functions
- Understanding Firewalld in Multi-Zone Configurations
- From vs. to + for Microsoft and Linux
- Understanding OpenStack's Success
- Tech Tip: Really Simple HTTP Server with Python