The Tao of Linux Security: the Five Phases of a Secure Deployment
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.
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
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.
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 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.
|PasswordPing Ltd.'s Exposed Password and Credentials API Service||Apr 28, 2017|
|Graph Any Data with Cacti!||Apr 27, 2017|
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
- Graph Any Data with Cacti!
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Understanding Firewalld in Multi-Zone Configurations
- Simple Server Hardening
- A Switch for Your RPi
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- Server Technology's HDOT Alt-Phase Switched POPS PDU
- Nventify's Imagizer Cloud Engine