The Tao of Linux Security: the Five Phases of a Secure Deployment

Start on “the Path” to a more secure system.
Phase 3: Patching

The next phase in this deployment is to patch the systems. Although sometimes tedious, patching is a necessary evil. After all, 843 packages are a lot to protect. You also need to keep your systems updated to mediate the threat of new vulnerabilities. Thankfully, the example distros covered in this article make the process very easy. On the Fedora client, you already have this ability. Upon the first login, the system checks for updates automatically (Figure 5). Fedora uses the Yellow Dog Update Manager, better known as yum, and a new update GUI, pup, to automate the update process. However, the pop-up style reminder seems to work only in the GNOME desktop environment. If you want to update your system manually, you also can use the commands yum list updates or yum info updates to see which packages need an update. You also simply can run yum without any options to apply all available updates to all installed packages.

Figure 5. Fedora checks for updates immediately after install.

Moving on to the example server, Debian uses a utility called aptitude (apt) for updating packages. apt traditionally is used as a package manager, like Red Hat's RPM, but it also has the ability to check for updates like yum. It uses predefined and custom source lists to check for updates against your installed packages. If you do not have the following line in your /etc/apt/sources.list file, add it so you can check for updates against the main stable US archive:

deb http://http.us.debian.org/debian stable main contrib non-free

Run the apt-get update command after adding the line. To update all the packages on your system, type apt-get upgrade (Figure 6) from a command prompt, and the system will begin checking and, with your approval, downloading and applying the updates. If you want to see what packages you have before running apt-get, use the command dpkg -l. To check for updates once a week, use the commands below or write your own script and use crontab to schedule it:

echo /usr/bin/apt-get  update > /etc/check4updates
echo /usr/bin/apt-get  upgrade >> /etc/check4updates
chmod 750 /etc/check4updates
crontab -e

Figure 6. Use apt-get to look for Debian security updates.

Add the following lines to your crontab file to make the script run every Wednesday at 3:30am:

30 3 * * 3  /etc/check4updates

Beware—if you compile your own packages or use packages from another source, they may not be updated automatically using yum or apt-get.

Phase 4: Hardening

After patching your new system, you may need to take additional steps to secure it. This is where having your security goals noted in the planning phase helps. You can use these goals to determine what additional steps are appropriate, as you more than likely will have more steps than the few illustrated here. The more goals you have, the more steps you are likely to have as well. Try to keep simplicity in mind. Complex settings actually can make a system less secure, because they often can lead to misconfiguration. Also, remember to note these steps in your build log.

The Fedora example already has shown two important steps to enhance security: enabling SELinux and installing a firewall. In most typical desktop-use scenarios, when combined with an antivirus application, this is enough. For the Debian box, I have selected three common steps that should be used on any server system: using sudo, locking down SSH and using a restrictive iptables firewall. These simple items should be considered the bare minimum on any server system, and if desired, they can be applied to a desktop as well.

sudo

sudo is a great application for limiting root access, which should be guarded closely on any server. Adding users to the /etc/sudoers file, limits their ability to use su to specific commands, specific directories or by network host. Any users in the sudoers file simply need to type sudo before the commands they want to execute to run under root credentials. This is much easier and much safer than giving the root password to everyone.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thanks a lot

Geziler's picture

Thank a lot, i thing this is wonderfull

Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions