Linux Security: The Seven Most Deadly Sins
This chapter is from the book
This chapter is from the book
This chapter is from the book
If you are new to security, I recommend that you start with Chapter 2, "Quick Fixes for Common Problems." At first glance, this chapter sounds simple and sweet. However, it covers the security problems that are so severe they are likely to result in a rather unpleasant and expensive break-in. These problems affect all unhardened Linux systems regardless of their use. This chapter is not full of fluff, theoretical ideas, or impractical suggestions. Instead, it is a hundred pages of no-nonsense, thoroughly explained, practical advice that has proven successful for many systems over the course of time.
Chapter 2's section entitled "The Seven Most Deadly Sins" explains exactly these. Indulge any of these seven sins and almost certainly your systems will be broken into in one to twelve months. I find that the difference between Linux and Windows is that with knowledge and a little effort, Linux can be made very secure. I provide that knowledge in Real World Linux Security, Second Edition, along with some humor and real world examples of successes and failures. Following the easy advice in the pages of this section will boost the security of an "out of the box" Linux system by an order of magnitude. Shall we begin?
Bob Toxen
These are the seven common problems most likely to allow major damage to occur to your system or bank account. If any of these are currently a problem on your systems, you should take care of them immediately.1
2.2.1 Weak and Default Passwords (#1)
As a system administrator, you are aware of the system breaches possible on your Linux machine. You have taken the time and effort to devise a difficult-to-guess password that uses at least eight characters, uses both letters and numbers, upper- and lowercase letters, and possibly some punctuation. Your root password is awesome—no one could guess it in a hundred years. (OK, some obsessive with a decrypt package could destroy it in a few days except that you use shadow passwords, but that is another story.)
How are your users doing? Choke, cough, gag, hack. Every account is a possible entry point. Have your users followed your advice, company policy, or threats to devise a good password? Are they being as careful as you are? Probably not. Now it is your turn to don the black hat and think like your enemy.
It is critically important to read "Avoiding Weak and Default Passwords" on page 42.
Using programs like crack (which cracks passwords), can you break into your users' accounts? You definitely will need to get written management approval to conduct this level of security audit. There are notable cases of unauthorized audits landing people in jail or at least on the unemployment rolls. Randal Schwartz is one.
You might even install a module in the passwd program that automatically tries to break a user's proposed new password. Though the standard passwd program makes very simple tests, there are more sophisticated routines that include much of crack's capability. One way to do this is to make use of the cracklib capability in the Pluggable Authentication Modules (PAM) enhancements to the passwd program. The cracklib library analyzes passwords to determine whether they are easily crackable. PAM offers additional security for Linux systems and other operating systems too. Edit the /etc/pam.d/passwd file to include:
passwd password requisite /usr/lib/security/pam_cracklib.so retry=3 passwd password required /usr/lib/security/pam_pwdb.so use_authtok
This will cause the PAM-enabled passwd program to load these dynamically loadable program libraries. PAM now is standard with Red Hat. On some systems these are in /lib instead of /usr/lib.
There is more documentation on configuring PAM-enabled utilities at:
Another good source for PAM information is:
On Slackware, this capability will be enabled if the following line is present in /etc/login.defs (and the dictionary is installed):
CRACKLIB_DICTPATH /var/cache/cracklib/cracklib_dict
See also "Restricting Login Location and Times" on page 315.
Avoid default passwords as if your job depended on it.
I know what Cisco uses as the default password for many of its routers because a client's unhardened Linux system was cracked the night it was put on the Web. The password was used to determine which randomly chosen IPs on the Internet accepted Cisco's default password. A system at the same location, where I had been allowed to do "light" hardening months earlier, remained uncompromised. The next day, the list had grown to hundreds of IPs before the system was taken offline. A better design would have been for Cisco to force the administrator to pick a decent password before the device started accepting traffic. For years now, most Linux distributions have been forcing an initial nondefault password before routing network traffic.
So much for Cisco's advertising claim that their routers are more secure than Linux or UNIX systems because they "have security designed in and they use proprietary equipment" rather than using open source. It took me only a minute with Google to find a list of the default passwords for hundreds of popular switches.