Section 21.2. Objective 2: Set Up Host Security

21.2. Objective 2: Set Up Host Security

Once a Linux system is installed and working, you may need to do nothing more to it. However, if you have specific security needs or just want to be cautious, you'll want to implement additional security measures on your system.

21.2.1. Shadow Passwords

The shadow password system enhances system security by removing encrypted passwords from the publicly available /etc/passwd file and moving them to the secured /etc/shadow file. This prevents users from running password-cracking programs against all of the encrypted passwords on your system.

Shadow passwords are covered in the section "The Shadow Password and Shadow Group Systems" in Chapter 18, which describes user management. In order to secure a system, it is a good idea to implement shadow passwords if they aren't already. You can check this by looking for /etc/shadow and verifying that the user list matches the one in /etc/passwd. If shadow passwords are not enabled, you may enable them by entering the pwconv command with no arguments. In the unlikely event that you use group passwords, you should also enable group shadowing with grpconv.

21.2.2. inetd Minimalism

As mentioned in the "Objective 1: Configure and Manage inetd, xinetd, and Related Services" section in Chapter 20, inetd and /etc/inetd.conf (its configuration file) handle access to many system services. Despite the use of TCP wrappers on these services, the best security can be achieved by simply not offering services that aren't explicitly needed. Do this by removing or commenting out lines in inetd.conf for services that are unnecessary. For example, to eliminate the talk and finger servers from your system, comment their configuration lines:

 #talk   dgram  udp wait   root /usr/sbin/tcpd  in.talkd #ntalk  dgram  udp wait   root /usr/sbin/tcpd  in.ntalkd #finger stream tcp nowait root /usr/sbin/tcpd  in.fingerd 

After making this change, you must instruct inetd to reconfigure itself. For example:

 # finger root@localhost [localhost] Login: root                             Name: root Directory: /root                        Shell: /bin/bash On since Sat Feb 12 00:11 (EST) on tty1      2 hours 48 minutes idle  (messages off) On since Sat Feb 12 01:11 (EST) on ttyp1 (messages off) No mail. No Plan. # vi /etc/inetd.conf # killall -HUP inetd # finger root@localhost [localhost] finger: connect: Connection refused 

In this example, finger is first demonstrated to work. Then inetd is edited to disable fingerd, inetd is reconfigured, and finger stops working.

21.2.3. Logging and Superuser Mail

The syslog system is a constant companion to the security-conscious system administrator. Its logs are necessary to review security breaches and to trace possible perpetrators. The configuration of syslogd is described in Chapter 18, "Objective 3: Configure and Use System Log Files to Meet Administrative and Security Needs."

Some system responses to security problems can come in the form of email to the root user. You may wish to log in as root regularly to check its mail, but you can make such checking passive by instructing Sendmail to forward root's mail to administrators. To do so, add a line like this to /etc/aliases:

 root: jdoe, bsmith 

Then execute the newaliases command to recompile the aliases database:

 # newaliases 

Now all email for root goes to both jdoe and bsmith (but not root), who will presumably act on important messages.

21.2.4. Watching for Security Announcements

Another important function of system administration is to keep on top of any new bugs and exploits in the software on your system. There are countless sites on the Web you can watch to find announcements about such things, but two stand out and could be mentioned on Exam 102:

CERT

In 1988, a small Computer Emergency Response Team formed at the Software Engineering Institute (SEI), a research and development center operated by Carnegie Mellon University. The Defense Advanced Research Projects Agency (DARPA) originally funded its work. It is now known as the CERT Coordination Center (CERT/CC) , and CERT no longer officially stands for anything. Funding comes from a mix of federal, civil, and private sources.

CERT/CC is made up of network security experts who provide 24-hour technical assistance for responding to computer security incidents. It also analyzes product vulnerabilities, publishes technical documents, and presents security-related training courses. CERT/CC may be found at http://www.cert.org. Specifically, security advisories may be found at http://www.cert.org/advisories.

A periodic visit to the CERT/CC site can keep you informed of developments in computer security and on problems found with various software packages.

BUGTRAQ

In 1993, a mailing list was created to publicly disclose demonstrated bugs in popular software, with the intent of forcing responsible parties to fix the problems quickly. The list has grown into a respected resource on security topics and has thousands of subscribers. To subscribe to the BUGTRAQ list, follow the instructions in the BUGTRAQ section of http://www.securityfocus.com. Archives of BUGTRAQ are also available there.

Attention to these and other resources can help you keep your system up-to-date. You'll be aware of problems found in software you're using, and since updates are almost always produced quickly in response to these notifications, you can upgrade, patch, or replace software as needed to keep your systems secure.