Classnotes | UNIX03 | RecentChanges | Preferences No diff available--this is the first major revision.
(no other diffs)As a system administrator, you are aware of the security problems associated with weak and default passwords. You know that you never log directly as root, but instead log in as yourself (a non-priviledged user) and su to root. You have your account and root's account protected by an impenetratable and complex password with letters, numbers, symbols. But how are your users doing?
Unless you have very serious users, chances are they will have easy to crack, simple, and even default passwords. They will have these in-spite of system policies, admonishment from you, and even knowing the threats involved. Each user's insecure password is another path by way malicious crackers can gain entrance to your system.
So how do you combat this? Some system administrators and operating system vendors recommend that you have expiring passwords that must be changed every XX days. However, is this really secure? Simply requiring a user to change their password every XX days when that user does not want to have to remember a password in the first place will only cause a user to become less and less diligent in their password designs. It may also cause them to keep a running log near their desk of current and past passwords. If this list falls into the wrong hands and this user begins to cycle the passwords, then that user's account is a very easy and attractive target.
Other system administrators use chroot'ed environments set up for their users (which we touched on last class, and will explore more this class) to limit what damage a compromized account could cause. The problem here is that chrooting requires much more disk space, and will probably not be economical in environments with many users.
On traditional Unix systems, passwords were stored encrypted in /etc/passwd, a world readable file. Since encryptions can easily be broken with brute force, modern Unix systems (and virtually all Linux systems) employ the use of MD5 shadow password files that only root can read. This file is most often located at /etc/shadow. As the book says, "Use of shadowed passwords should be considered mandatory" (p. 42), and if your Unix system does not employ them, then it is probably not worth the hard drive space needed to install it.
One way of testing to see how secure your user's passwords are is by using a program such as crack (which is described in the book) or John the Ripper (my personal favorite, and is cross-platform- http://www.openwall.com/john/) to see if you can crack your own user's passwords. This type of security audit is something you would definately need to get management's approval of before performing.
System Accounts
Some distributions fail to put passwords on some system accounts. In order to ensure that all accounts either have some sort of password, or are disabled, you should check your /etc/password file and ensure that the second field for system accounts either contains a "!!" or "*" (indicating the account is disabled) or contains an "x" (indicating that a shadowed password is being used).
You should also check that your /etc/shadow file contains an encrypted password or one of the above characters in its second column as well.
