By the time you get this issue of Linux Journal, my new book, Linux System Administration: A User's Guide, will have hit the shelves. Because they are just so darn cool, the folks at Linux Journal have given me some space in this month's issue to give you a teaser from the book.

Being the kind of guy that I am, I ached over what to present while trying to keep it short. After all, there's so much to choose from. Setting up a scanner? A CD writer? Blocking unwanted access to your network? Printing? Backups? Sendmail tweaks? What? In the end, I decided to talk about something that doesn't get enough press in today's internet world, and that's good old-fashioned user security. What you are about to read is an excerpt from Chapter Seven of the book, “Users and Groups”. It is not the complete chapter, nor are all the pieces in order. “The chef has been sipping too much of his own wine”, you say? Not at all. In fact, like my alter ego, I wanted to use this space to give you a sample, a taste if you will, of what you might find in the pages of my new book. Think of it as nibbling from a buffet table. As Chef Marcel would say, Bon appétit!

Linux is a multiuser operating system, meaning that one or more users can work on it at the same time. Every user is referenced by their user name. Each user name has a user ID (UID) associated with it and one or more groups. Like user names, group names are also represented by a numeric identifier, this time called a group ID (GID). A user's UID is unique as is a group's GID.

When it comes to your files and directories, security on a Linux system is defined by means of permissions, which directly relate to the user ID. Users are either administrative users or regular users. The chief administrative user is called root. A user's ID is used to decide what commands can be executed and what files can be read from or written to.

Each user ID also has a password associated with it. That password can and should be changed on a regular basis.

The short answer here is that you should never use the root user unless you absolutely have to. The danger lies in the fact that the root user is virtually omnipotent on the system. A mistake can have serious implications that can wipe out your entire system. Unless you absolutely have to, it is best to work as a nonadministrative user. There are other reasons as well.

The first is security. Because the root user has access to everything, it makes sense that only those who really need to have access are given the root password. The fewer people who have access to root, the better. Let me give you a few good reasons for jealously guarding root access: it makes it easier to maintain security, it decreases the risk of dangerous code and errors do not (usually) have global implications. Yes, it is still possible for a nonroot user to do great damage to a system, but the risk is much, much smaller.

As if you didn't already have enough things to do, here's yet another job. On a regular basis, you should run a report to identify accounts or logins that have gone dormant. This is a nice way of saying “people who are gone and who are not coming back anytime soon”.

An earlier chapter of the book explains the finger command, which displays information relating to the last time an account was used. Try typing this command to list each user ID and to check the last login time. Note that the single quotes (just before the sort command and just before the pipe symbol) are actually back quotes (or back ticks). The back quote is usually found with the tilde (~) just under the Esc key on most keyboards.

finger 'sort /etc/passwd | cut -f1 -d":"' | grep -i log | more

The output of this command looks something like this:

Login: aeinstein                Name: A. Einstein
Never logged in.
Login: guitux                   Name: Tux the Penguin
Last login Mon Jan  8 14:54 (EST) on tty2
Login: halt                     Name: halt
Never logged in.
Login: lp                       Name: lp
Never logged in.
Login: mail                     Name: mail
Never logged in.
Login: mgag                     Name: Marcel Gagné
Last login Wed Mar  7 17:29 (EST) on 1 from website
Login: named                    Name: Named
Never logged in.
Login: natika                   Name: Natika the Cat

Now, I used that example to give you a feel for your command-line prowess. However, I should tell you that there is a cleaner way to do this. Your Linux system comes with a handy little command called lastlog that does just this sort of thing:

[root@scigate /root]# lastlog | more
Username  Port  From              Latest
root      tty1                    Wed Mar  7 17:18:40
                                           -0500 2001
bin                               **Never logged in**
daemon                            **Never logged in**
adm                               **Never logged in**
lp                                **Never logged in**
sync                              **Never logged in**
shutdown                          **Never logged in**
mgagne    1     scigate           Wed Mar  7 17:29:55
                                           -0500 2001
postgres                          **Never logged in**
www                               **Never logged in**
natika    8     localhost.locald  Thu Dec  7 14:30:15
                                           -0500 2000
guitux    tty2                    Mon Jan  8 14:54:55
                                           -0500 2001

Geek trivia: you can't edit or modify this file, but the lastlog command information comes from the file /var/log/lastlog.

Here is another thing you should do. Every once in a while, run the command pwck. By default, it walks through your /etc/passwd and /etc/shadow files and does some basic integrity checks, such as making sure that the right number of fields are present and that each name is uniquely identified. For the group file, there is a companion command called grpck.

The reason for a good password goes right back to my description of the password file earlier in the book, specifically as it relates to the password field in nonshadow files. Here's a quick reminder of the format:

root:2IsjW45pb4L56:0:0:root:/root:/bin/bash

The password field (field 2) is encoded by virtue of a hashing algorithm. If you are curious as to the gory details, type <@cxb>man crypt<@$p> and you'll find everything you ever wanted to know about encoding passwords. The short form is this: that strange password is actually a coded version of your password based on a two-character, randomly generated salt. This salt is then used to seed the hashing routine to generate the final group of characters.

The term hashing represents a technique for taking a string of characters (a person's last name, for instance) and generating a unique key (ideally) for easy retrieval of the information from a database. What you are doing is encoding the normal text into a shorter, (usually) numeric representation.

Password crackers figure out passwords by using that salt to generate passwords against every word in the dictionary. While this sounds pretty complex, it's not. A simple program calls the crypt routine, runs the hash on a word and then compares it to the password entry in the /etc/passwd file. If it matches, bingo! They have your password. If it doesn't, they move on to the next word. On a reasonably punchy system, it doesn't take all that long for crackers to work their way through every password in the book.

Don't believe me? Take a look at the output in Figure 1 from a little program called Nutcracker, a freeware tool that does the kind of brute-force password checking I was talking about.

Figure 1. Why Dictionary Wofrds Make Bad Passwords

As you can see in Figure 1, picking something you'll remember easily because it is a common word is a bad choice for a password.

Have a look at what happens when I log in to a machine. Everything looks normal. I have a login name, a request for my password. I enter the password and voilà, I am in. But hold on—read that little one-line message that appears after I enter the password:

login: mgagne
Password:
Last login: Mon Jan  8 16:00:39 from energize

What the heck is “energize”? Energize is the hostname of the computer from which I last logged in apparently, except I don't have a system called energize. Furthermore, let's pretend that I don't know anyone with that system and I always log in from the same place. The only explanation is that somebody from a system called energize logged in to the server with my login name and password.

This is just a hypothetical situation, but it does illustrate one other habit that you should consider training your users to adopt. If they are logging in from the same PC day in and day out, that message should never change. If they do not recognize the hostname in the last login message, they should make it a policy to alert you.

Security isn't just the domain of the system administrator. After all, you've got plenty on your hands. Any help is appreciated. You need to get the users involved. Let them know that system security is their business as well as yours.

Resources