The first step in securing any operating system is to secure the user and group accounts. This includes, but is not limited to, the following:
These steps are discussed in the following sections. Other precautions, such as securing a user's working environment, handling filesystem security, preventing and detecting intruders, as well as system hardening are discussed in later chapters in this book Using Strong PasswordsLike having good and secure locks on your house, you want users to pick passwords that are difficult to guess yet easy enough to remember so the users will not write down their passwords for the world to find. Difficult-to-guess passwords means they should not be associated with the user personally, such as the name of his or her spouse, names of children, pets, or the user's address. Strong passwords should also not include dictionary words. Many password-cracking programs make use of word lists to brute-force crack passwords. Many of these programs are freely available over the Internet; two of the most popular password-crackers are Crack and John the Ripper. We will discuss how you can use John the Ripper to detect weak passwords on your system in Chapter 11. One way to select a difficult-to-guess password is to use a randomly selected string of characters, such as i2#yA9%3r. This is not a word found in any dictionary, nor is it remotely connected to a user. Unfortunately, your user probably wouldn't be able to remember such a password. The likely result is that the user will write it down on a sticky note and paste it underneath his or her keyboard! A better way to select a strong password is to use a short phrase (commonly referred to as a passphrase) such as I missed hockey! Alternatively, you can derive a password from a long sentence such as The Adventures of Buckaroo Banzai across the Eighth Dimension! One derivation is to simply take the first letter from each word, except for the word Eighth, which is replaced by the number 8, and you get TaoBBat8D. Or you can take the second letter of each word, except again for the word Eighth, and you get hdfuach8i. As you can see, you can use many variations to come up with difficult-to-guess but rather easy-to-remember passwords. NOTE Given the ever-increasing computing power and the ready availability of utilities such as John the Ripper and packet sniffers (such as Ethereal), even the most difficult-to-guess passwords are fast becoming worthless. If a hacker obtains a list of your usernames and hashed passwords, he can run Crack or John the Ripper against the list until a match is found. If the user is logging in over a network, both username and password are sent in cleartext (unless the session is encrypted such as when using SSH instead of Telnet). This makes it even easier for the bad guy because all he needs is a sniffer to capture all the network traffic and look for "Login:" and "Password:" in the packets. No need for John the Ripper at all! You can take many steps discussed throughout this book to minimize the impact and even prevent these types of attacks from happening in the first place. The standard industry recommendations on selecting strong passwords and enforcing password security are summarized in the following sections. PROTECT YOUR PASSWORDSThe first rule of password security is that you don't ever write down your password; memorize it instead. In particular, don't write it down and leave it somewhere that is publicly or easily accessible by others, and don't place it in an unencrypted file! If you can't memorize it, you didn't choose a good password. If you must write it down, keep it on your person at all times! If you have access to different systems and a centralized authentication mechanism (such as NIS or LDAP) is not used, use unrelated passwords on these machines. This also applies to your access to systems controlled by different organizations: You don't know how well they protect their systems and don't want to help any bad guys to get into your servers using information hacked from those other systems. Don't give or share your password, in particular to someone claiming to be from computer support or a vendor, especially over the phone! Often, a hacker uses deception or misdirection to obtain information from an unsuspecting userespecially a new user. The hacker often pretends to be someone in authority, such as someone from IT Security or a vendor's customer support group that needs to verify a user's identity. Consider the following telephone conversation:
This method is referred to as social engineering. The hacker simply carries out a seemingly innocent conversation with the victim in a social setting and obtains the necessary information without having to spend days trying to crack a single MD5- or Blowfish-hashed password! CAUTION In recent years, such social engineering ploys (known as phishing) have been used on the Internet. The bad guys send out an email to a user falsely claiming to be an established, legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft. The email directs the user to visit a website where he or she is asked to update personal information, such as passwords and credit card, Social Security, and bank account numbers that the legitimate organization already has. The website, however, is bogus and set up only to steal the user's information. Visit http://www.ftc.gov/bcp/conline/pubs/alerts/phishingalrt.htm for more information. Don't let anyone watch you enter your password and don't enter your password into a computer you do not trust. If the password is needed only for a limited time, change it periodically. When it comes to safeguarding your password, the golden rule is practice perseverance and vigilance. CHOOSE HARD-TO-GUESS PASSWORDSA strong password should be something you would not find in a dictionary (in any language or jargon). You shouldn't use a name (including that of a spouse, parent, child, pet, and so on) or any variation of your personal or login name. Don't use publicly accessible information about you (such as your phone number, car license plate, or employee number) or your environment (such as office address) as part of your password. Don't use a birthday or a simple pattern (such as spelling the username backward, following the name with a digit, or preceding the name with a digit). A good, hard-to-guess password consists of a mixture of upper- and lowercase letters as well as digits or punctuation. When choosing a new password, make sure it's unrelated to any previous passwords (such as by adding a digit to an old password). Use long passwords (say, eight characters or more). You might use a word pair with punctuation inserted (such as greAT:@Book), a passphrase, or selected letters of each word in a long sentence, as discussed previously. BUTTON DOWN THE HATCHES!You should never, ever, allow an account without a password. Such an account is an open invitation begging some bad guy to compromise your system. Lock all unused accountsfor users who are away for an extended period of time or users who have left your organization but you need to retain their environmentsusing the passwd -l command. You will also find many of the system accounts to have an invalid password assigned (a single * or ! in the password field in /etc/shadow). These accounts exist to allow programs to be run as the UID associated with that account; they are not direct login accounts. If you ever need to create such an account, ensure you disable its login access. TIP In addition to locking dormant accounts by disabling the passwords, you should also remove (or rename) all .rhosts, .netrc, and .forward files in their home directories to prevent remote access as those users via FTP or any of the r- commands (such as rlogin and rexec). You should also change these users' shells to a dummy shell such as /dev/null, /bin/false, or /sbin/nologin. This way, even if someone is able to log in as one of these users, an immediate exit will be the result. You may not want to use nologin because it informs the user that the account is not availablea giveaway to hackers that the account does exist but is disabled. USE PASSWORD AGINGNo matter how hard a password is to guess, if it has been used for an extended period of time, someone is going to figure it out. It is not uncommon for users to brag with each other about how secure or how clever their passwords are: "I used all my three children's middle names. How's that for a tough password?" "You know the color that I really, really hate?" or "Hey, I used my wife's favorite Italian dish as my password. Try to guess that!" Given enough talk, and some luck, a bad guy may just figure out what the password is. Therefore, it is a good idea to force the users to periodically change their passwords. Password aging may be implemented on a system-wide basis or on a per-user basis. Password-aging policy in Linux is controlled through the shadow password file and is configured automatically by SLES during installation. BE A CRACKER JACKUse a password-cracker yourself to audit for weak passwords. SUSE LINUX implements Pluggable Authentication Module (PAM) by default to provide flexible user authentication. One of the side benefits of PAM is its ability to help enforce strong passwords (through the pam_pwcheck module, for instance). (You can find more details about PAM in Chapter 5, "User Environment Management and Security.") There is always a possibility that another system administrator assigned a weak password without realizing it. To find out, you should periodically use a password-cracker, such as John the Ripper, to self-audit and see whether any weak passwords are reported. CAUTION When nonroot users change their passwords, PAM ensures a "good" password is chosen; otherwise, the password is not changed. However, for the root user, PAM gives the warning when a weak password is detected but allows it to be used. TIP A set of cron scripts called seccheck is included and installed by default as of SuSE 6.3. Seccheck performs daily, weekly, and monthly checks of your system's security and compares them to the last run. The results are emailed to the root account. Weak password checks are performed weekly using John the Ripper. For more information, refer to /usr/share/doc/packages/seccheck/README. USE A STRONG PASSWORD-HASHING ALGORITHMThe previous recommendations of using passphrases and long passwords are fine if the password-hashing algorithm you use supports long strings. By default, SLES 9 (and many other Linux distributions) uses a DES-based algorithm, which supports passwords up to eight characters in length; any string longer than eight characters is truncated to eight characters in size. Fortunately, SUSE ships with the option of encrypting passwords with the stronger MD5 hash algorithm or with Blowfish. (For more information on the MD5 hash algorithm, consult RFC 1321; see http://www.schneier.com/blowfish.html for more information about the Blowfish encryption algorithm.) Although MD5 and Blowfish passwords do not eliminate the threat of password cracking, they do make cracking your passwords much more difficult. NOTE SLES uses DES as the password-hashing method by default. However, you can change it to either MD5 or Blowfish during install as discussed in the "Detailed Installation Steps" section in Chapter 1, "Installing SUSE LINUX Enterprise Server." Or you can change it any time after the server is up and running, as discussed next. If you didn't change the password-hashing algorithm from DES to MD5 or Blowfish during install, you can easily change it at a later time. This is easily done using YaST because it will make changes to all the related configuration files for you (such as /etc/security/pam_unix2.conf and /etc/security/pam_pwcheck.conf). You can make the change either via the User and Group Administration module or the Local Security Configuration module as follows:
WARNING There appears to be a cosmetic bug with the User and Group Administration module when setting passwords. Regardless of your current password-hashing algorithm, when you try to use a password longer than eight characters, YaST always warns you that the password is too long and asks if it should be truncated. When you click Yes, it is truncated when using DES. However, with MD5 and Blowfish, the password is not truncated even though you are led to believe it will be after you click Yes; if you click No, you're returned to the screen to enter the password again. CAUTION Changing the password-hashing method used does not change the existing password hash values to the new one. For instance, switching from the default DES to MD5 leaves existing password hashes as DES. However, new passwords will be hashed using MD5. Therefore, if you want all user passwords to be hashed using the new algorithm, change the method and then expire all passwords. This way, the next time a user logs in, that user will be prompted to change his or her password, and it will be hashed using the new method. You can determine what hashing algorithm was used for a given password hash by examining /etc/shadowanother reason why this file is accessible by root only because you don't want to give any hackers hints on what hashing algorithm you are using:
Each of the DES, MD5, and Blowfish algorithms has its pros and cons, and you should give them some careful thought before picking one. For instance, the Linux (and Unix) implementation of the DES hashing method limits the password to only eight characters, but because all versions of Linux/Unix and most other Unix-like operating systems support it, it is a good choice for cross- platform compatibility. On the other hand, MD5 and Blowfish allow for much longer passwords (127 characters for MD5 and 72 characters for Blowfish), but the algorithms are computational-intensive. So if you have an underpowered server that needs to perform many user authentications per second (such as an LDAP authentication server), performance will suffer. There are also some networking protocols that do not play well with passwords longer than eight characters. For example, only the first eight characters are significant in NIS+ passwords because the underlying secure-RPC protocol uses DES. Consider the following suggestions when choosing a password-hashing algorithm for your system:
TIP You can find the RPM for a version of Perl that supports Blowfish at http://rpmfind.net/linux/RPM/contrib/libc6/i386/perl-Crypt-Blowfish-2.09-1.i386.html and at http://rpmfind.net/linux/RPM/suse/8.2/i386/suse/i586/perl-Crypt-Blowfish-2.09-188.i586.html. The Perl crypt home page is at http://cpan.org/modules/by-module/Crypt. In most cases, MD5 provides the best balance between performance and security. Auditing Default AccountsAs mentioned earlier, a number of system accounts exist to allow programs to be run as the UID associated with that account; they are not direct login accounts. FTP, named (for DNS), mail, and news are some examples of such system accounts. Make sure such accounts are prevented from a terminal login by setting their shell to /bin/false or similar. If the services for these accounts are not in use, uninstall them and remove the accountsor at the very least, disable unused services (see Chapter 8 for more information). Periodically, you should check the contents of /etc/passwd and /etc/shadow to ensure that the removed system accounts didn't "spontaneously resurrect" themselves or new system accounts were not added without your knowledge, and nonlogin system accounts don't "suddenly" get assigned valid password hashes and shells. The Root AccountThe root account is the key to your entire server kingdom (and to your entire network if the server in question serves as the central authentication server). Nothing is more important than the password to the root account in the Linux/Unix world. For this reason, you will not want to make your root password known to anyone else but yourself. Well, this is often easier said than done. As you may already have found out, many of the administrative tasks, such as resetting a user's forgotten password, changing system configuration, and so on, require you to be root. If you're the lone ranger who looks after the system(s) at your organization, keeping the root password safe is relatively easy: Follow the recommendations given earlier in this chapter about selecting strong passwords, change it often, never write it down, and so on. However, it is not uncommon in a company for system administration tasks to be shared by two or more people. In such cases, how do you safeguard the root password effectively? The more people who know it, the higher the likelihood it will be leaked to someone who shouldn't know about it! TIP If you are the sole system administrator at your organization, it might be a good idea to record the root password in a sealed envelope and keep it in a secure location where only trusted company officers (such as the accountant or CTO) have access to it; a bank safety deposit box is a good choice. The idea here is that although you would want to keep the root password secret from others, you need to provide a way for "continuity" should you be unavailable, due to illness or any other reasons. There are a number of ways to address the multiple administrator requirements, and we discuss two of them here:
NOTE Further discussion about sudo can be found in Chapter 5. Running as root all the time is not a very good idea. Because it grants you all-powerful, unlimited access to the server and its files, one little mistake may render the whole system useless. For example, before you execute rm -r * (or even just rm *), make very sure you are in the right directory! In general, think twice before you perform certain actions as root. Here are some tips regarding using the root account:
User in Too Many Groups?Linux and most other recent Unix systems support at least 32 groups per user. However, because the NFS protocol supports only 16 groups, most of them (SUSE included) have imposed a soft limit of 16 groups per user. There are very rarely circumstances that require more than 16 groups, but it is usually possible to use more if the system will not be exporting or using NFS-mounted filesystems; NFS has a hard-coded limit of 16 groups in its underlying RPC protocol. The first 16 groups are passed to the NFS server for permission checking, while the others are ignored. In other words, a user might appear to belong to a group, but if the 16-group limit is exceeded, the user might not have the access privileges of that group. |