The Tao of Linux Security: the Five Phases of a Secure Deployment
A tao, meaning “the path” or “the way”, is a system of guidelines or rules meant to achieve a desired end. Like any tao, security requires a structured, systematic approach. It also should be holistic, encompassing every part of a system's life span from planning to retirement. The tao in this article consists of five simple phases that every Linux system should pass through to establish a secure baseline. The phases are not a be-all, end-all formula for security. They merely provide a foundation on which to build deeper levels of security later.
As I go through each phase, I will deploy two sample systems, a Red Hat Fedora desktop and a Debian server system, to show how security is implemented. I chose Fedora because it is arguably the most popular distribution out there. It works well for any purpose, has many desktop enhancements and is one of the easiest distributions for non-command-line Linux users to pick up. I chose Debian as our server platform because it is lightweight, has a long history of reliability, a great support community and extensive documentation. Both are excellent platforms and have their own unique security measures built in. If you have a different distribution preference, the phases presented here can be applied to any system.
The first phase of the tao is also the most important, as it is where you make most of the decisions that affect your overall security. The first step before all others is to define the purpose of the system being deployed. Will it be a mail server? A desktop? An intrusion-detection system? Once you have a purpose, you can use it as your guide throughout this process. The focus then becomes fulfilling that purpose while providing the most secure environment possible. After all, why deploy a system that no one can use? Security never should handicap functionality.
Next, you need to decide what your security goals are for the system. The primary goal of every build always should be the principle of least access or least privilege. This means providing only the minimum permissions to users and programs necessary for the system to operate. You may have other security goals, such as scanning every file with antivirus software or authenticating every user with LDAP, but least privilege always should be paramount.
Armed with these goals, you need to figure out how to accomplish them before actually building the system. Answering some simple questions will help determine the appropriate steps to meet the goals in phases 2 and 4. Will this system be server or a desktop? The answer to this question will dictate a great deal of the configuration on your new system. Will users access the system locally or remotely? This is another important configuration question with security implications. Will the system need a desktop environment?
If you or the people who will be administering the system are comfortable with the command line, deploy your system as “headless”, or without a GUI interface. By eliminating the X Window System from your install, you shrink your attack surface (your exposed area) dramatically. On the other hand, if you or your staff needs a GUI, install only one and understand that additional steps are required to lock down your system properly. It is a good rule of thumb to install a server without X and use a desktop environment for user desktop systems.
Finally, plan the applications that will operate on this system. Determine which dependencies and libraries are essential to operation. Too often, unnecessary libraries are used after a system has been compromised to run remote commands, mask an intruder's presence or probe networks. If you do not need a package do not install it.
When finished working out the answers to these questions, write them down in a build log or notebook and keep them up to date even after the initial build.
Armed with written plans, now comes the building phase. Here is where you begin the technical application of the security goals you set in the planning phase. Due to space constraints, the following section is not a detailed checklist of each of the example installs. I have highlighted only those options that are relevant to the focus on security. As in phase 1, write down your selections during installation in a build log in case you ever need to rebuild the system.
Fedora Core 7
Start by booting a fresh system from a Fedora 7 ISO available from any of the distribution's site mirrors. After entering your keyboard and language settings, you come to the disk partitioning utility. For most desktops, the installer does a fine job of configuring the drives appropriately. But, if the system will be used by someone whose work is sensitive, place the /home folder on its own partition.
After partitioning comes the bootloader options. Select GRUB and set a password. Using a password with your bootloader is good practice and helps prevent data loss if your drive or system ever is stolen. Like any good password, it should have complexity, avoid dictionary words and use numbers, letters and non-alphanumeric characters.
On the next screen, select DHCP, as client machines usually don't require static IPs. If you require one, make sure to use Network Address Translation (NAT) somewhere on your network. Next, set a hostname and domain, and set a complex root password. At the package selection screen, always review what you are installing by using the Customize Now radio button. On the Custom Selection screen, select only one desktop environment. Installing more than one environment leads to more vulnerabilities (and patches to update) later. Leave the default option on GNOME. Go through each of the other checked options, and you will discover a lot of packages will be installed (Figure 1). On my build, I have 843 packages using these options. Your number may vary. Use the Optional Packages button to eliminate any extraneous packages you do not need. When you're finished with package selection, the system will reboot.
Upon reboot, you are prompted to enable the firewall. Enable it, and add only the ports/programs you need to operate this system (Figure 2). At the Security Enhanced Linux screen, if you are able to, set the policy to enforcing (Figure 3). To those unfamiliar with SELinux, it's a policy-based protection scheme, originally developed by the National Security Agency, that adds a layer of security on top of the OS and several popular Linux applications, such as Apache. The downside to using SELinux is it sometimes can break the programs you are trying to protect (and other programs too). If you run into problems, you always can change the policy later, using the setenforce command or by editing the policy with a text editor. You then will be prompted to create a user account, and after a few other selections, the first login screen comes up.
Start your blank server up with a Debian ISO (4.0r1 used here). Because I'm using this system as a server for this example, let's take a more Spartan approach toward the install. Servers usually are a juicier target than desktops for nefarious people, so you need to take extra precaution, especially if they will be deployed on a public network or the Internet.
After setting the usual options for time zone, country and so forth, you need to set a hostname and domain for your server. Next comes the partitioning options. Rather than putting many of the system directories on their own partitions, stick with putting the /home directory on a separate partition, and go one step further by encrypting your drive. This may sound difficult, but the Debian partitioning utility makes this easy. Select Guided partitioning from the options, and then select Guided - Use entire disk and set up encrypted LVM. Use the entire disk and select the option to use a separate home partition. Debian recommends further segregating your directories to keep the root, programs and user data separate, but configurations like this can be difficult to administer. Write the changes to disk and, when prompted (Figure 4), enter a complex passphrase to encrypt the volume. Next, set your time zone and root password, and then the base install will begin.
After the base install, the next few prompts are inconsequential until you get to the software selection screen. For our scenario, install an Apache Web server only. Finally, install the GRUB loader, and your new system is ready to go. Upon reboot, lock down the GRUB loader with a password, by adding the following lines to the /boot/grub/menu.lst file:
timeout 30 password yourpasswordhere
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)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server