Paranoid Penguin - Security Features in Ubuntu Server
It's no coincidence that I used the aptitude command in the above examples. Chances are, one of the first things you'll do after installing Ubuntu Server is install some additional software, and aptitude is Ubuntu Server's best tool for this job.
Perhaps surprisingly, given that the Ubuntu Server distribution doesn't even fill a 650MB CD-ROM, there are many useful packages from which to choose on the CD in its /pool directory. When you install Ubuntu Server, the installer also automatically configures the Advanced Package Tool (apt) system, for which aptitude is a front end, with the locations of some download repositories.
In last month's column, I described the Ubuntu repository structure in detail. In case you missed that, here's a quick review:
Main contains Ubuntu's fully supported, fully patched, free software packages.
Restricted contains Ubuntu's fully supported, nonfree (copyrighted) software packages.
Universe contains Ubuntu's free but not fully supported/patched packages.
Multiverse contains packages that are neither fully free nor fully supported/patched.
You might think that on a server system, universe and multiverse packages should be avoided, as they lack any guarantee of timely security patches or bug fixes. And, as a general rule, I think you'd be right.
But, there are some notable packages in universe and multiverse that may be worth installing and sustaining whatever risk is entailed. One such package is Bastille (in universe), a comprehensive system-hardening tool you can uninstall after it does its thing. Another might be Tripwire (in multiverse), which is the classic file integrity checker, though the main repository's aide packages provide the same functionality and are fully supported by the Ubuntu security team.
All of these packages are part of the main repository. Unlike with Ubuntu Desktop, however, these can be installed from the Ubuntu Server CD.
Space does not permit me to include lengthy charts of security-related packages like those I provided in the Ubuntu Desktop column last month. If I did, they would be very similar except for two things.
First, I would omit security auditing tools, such as Nessus and tcpdump (though both are on the Ubuntu Server CD). You shouldn't install anything on any Internet server, or other multiuser system, that can be used by an attacker against the system itself or other systems on your network. Instead, you should run such tools from an administrative system, where they're less likely to be abused.
Second, you would see that many packages on Ubuntu Desktop must be downloaded from a main repository Web site. These are, in fact, provided on the Ubuntu Server CD under /pool. These include the following:
I'll leave it to you to explore the many other security-related packages available in the Ubuntu repositories. One of the best ways to do this is to look them up on packages.ubuntu.com.
Given the importance of patching to maintain system security, you might be surprised to learn that Ubuntu Server doesn't have any specific mechanism for automatically downloading and installing security updates. I can explain why in two words: change control.
On a production server that does real work, it's a bad idea to apply any patches, even security updates, until after you've tested them on a similar server in a lab to make sure they don't break anything. Sure, you can run the commands aptitude -y update, aptitude -y upgrade, aptitude -y dist-upgrade and aptitude -y autoclean from a cron job each night. But that -y option, which allows aptitude to run unattended, also might cause a package update to overwrite some custom configuration file with a default configuration.
On a server, you're better off running these commands manually as needed, without the -y option (after first doing so on a test system if you run in a change-controlled environment). That way, you'll be prompted before any configuration files are overwritten, and you'll be able to observe firsthand the changes aptitude makes to your system as they happen. Subscribe to the ubuntu-security-announce mailing list (via www.ubuntu.com/support/community/mailinglists) to receive e-mail notifications of security patches as they're made available.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- 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
- Rogue Wave Software's Zend Server