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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open