8.1.1 Accounts Without Passwords

Like the lock or guard on the front door of a building, the password on each one of your computer's accounts is your system's first line of defense. An account without a password is a door without a lock. Anybody who finds that door - anybody who knows the name of the account - can enter.

Many so-called "computer crackers" succeed only because they are good at finding accounts without passwords or accounts that have passwords that are easy to guess.

On SVR4 versions of UNIX , you can scan for accounts without passwords by using the logins command:

# logins -p

You can also scan for accounts without passwords by using the command:

% cat-passwd | awk -F: 'length($2)<1 {print $1}' 
george
dan
% 

In this example, george and dan don't have passwords. Take a look at their entries in the /etc/passwd file:

% egrep 'dan|george' /etc/passwd
george::132:10:George Bush:/usr/wash/george:/bin/csh
dan::132:10:Dan Quayle:/u/backyard/dan:/bin/csh
%

These two users have probably long forgotten about their accounts on this system. Their accounts should be disabled.

NOTE: The /etc/passwd file may not be the correct file to check for missing passwords on systems that have shadow password files (described later in this chapter) installed. Different shadow password schemes store the actual encrypted passwords in different locations. On some systems, the file to check may be /etc/shadow or /etc/secure/passwd . On some AT&T System V systems, passwords are stored on a user-by-user basis in individual files located underneath the /tcb directory. Check your own system's documentation for details. Also, systems using NIS, NIS+ or DCE may get the passwords from a server; see Chapter 19, RPC, NIS, NIS+, and Kerberos , for details.

8.1.2 Default Accounts

Many computer systems are delivered to end users with one or more default accounts. These accounts usually have standard passwords.

For example, many UNIX computers come with a root account that has no password. Vendors tell users to assign passwords to these accounts, but, too often, users do not. ( UNIX is not alone with this problem; other operating systems come delivered with standard accounts like SYSTEM with the password set to MANAGER .)

One way around this problem that has been taken by several UNIX vendors is to have the operating system demand passwords for special accounts such as root when it is first installed. We hope that all vendors will adopt this approach in the future.

Make a list of all of the accounts that came with your computer system. (These accounts are normally at the beginning of the /etc/passwd file and have names like bin , lib , uucp , and news .) Either disable these accounts (as described later in this chapter) or change their passwords.

Some application programs automatically install accounts in the /etc/passwd file with names like demo (used to demonstrate the software). Be sure to delete or disable these accounts after the software is installed. Likewise, computers that are taken to trade shows sometimes have demo accounts created to make demonstrations easier to run. Remember to remove these accounts when the computer is returned. (Even better: erase the hard disk and reinstall the operating system. You never know what a computer might bring back from a trade show.)

Table 8.1 is a list of accounts that are commonly attacked. If you have any of these accounts, make sure that they are protected with strong passwords or that they are set up so they can do no damage if penetrated (see the sections below entitled "Accounts That Run a Single Command" and "Open Accounts").

Table 8.1: Account Names Commonly Attacked on UNIX Systems

open	help	games
guest	demo	maint
mail	finger	uucp
bin	toor	system
who	ingres	lp
nuucp	visitor
manager	telnet

8.1.3 Accounts That Run a Single Command

UNIX allows the system administrator to create accounts that simply run a single command or application program (rather than a shell) when a user logs into them. Often these accounts do not have passwords. Examples of such accounts include date , uptime , sync , and finger as shown below:

date::60000:100:Run the date program:/tmp:/sbin/date
uptime::60001:100:Run the uptime program:/tmp:/usr/ucb/uptime
finger::60002:100:Run the finger program:/tmp:/usr/ucb/finger
sync::60003:100:Run the sync program:/tmp:/sbin/sync

If you have these accounts installed on your computer, someone can use them to find out the time or to determine who's logged into your computer simply by typing the name of the command at the login: prompt. For example:

login: uptime
Last login: Tue Jul 31 07:43:10 on ttya

		Whammix V 17.1 ready to go!

9:44am up 7 days, 13:09, 4 users, load average: 0.92, 1.34, 1.51

login: 

If you decide to set up an account of this type, you should be sure that the command it runs takes no keyboard input and can in no way be coerced into giving the user an interactive process. Specifically, these programs should not have shell escapes . Letting a user run the Berkeley mail program without logging in is dangerous, because the mail program allows the user to run any command by preceding a line of the mail message with a tilde and an exclamation mark.

% mail Sarah
Subject: test message
~!date
Wed Aug 1 09:56:42 EDT 1990

Allowing programs like who and finger to be run by someone who hasn't logged in is also a security risk, because these commands let people learn the names of accounts on your computer. Such information can be used as the basis for further attacks against your computer system.

NOTE: If you must have accounts that run a single command, do not have those accounts run with the UID of 0 ( root ) or of any other privileged user (such as bin , system , daemon , etc.)

8.1.4 Open Accounts

Many computer centers provide accounts on which visitors can play games while they are waiting for an appointment, or allow visitors to use a modem or network connection to contact their own computer systems. Typically these accounts have names like open , guest , or play . They usually do not require passwords.

Because the names and passwords of open accounts are often widely known and easily guessed, they are security breaches waiting to happen. An intruder can use an open account to gain initial access to your machine, and then use that access to probe for greater security lapses on the inside. At the very least, an intruder who is breaking into other sites might direct calls through the guest account on your machine, making their calls difficult or even impossible to trace.

Providing open accounts in your system is a very bad idea. If you must have them, for whatever reason, generate a new, random password daily for your visitors to use. Don't allow the password to be sent via electronic mail or given to anyone who doesn't need it for that day.

8.1.5 Restricted Filesystem

Another way to restrict some users on your system is to put them into a restricted filesystem. You can construct an environment where they have limited access to commands and files, but can still have access to a regular shell (or a restricted shell if you prefer). The way to do this is with the chroot () system call. chroot () changes a process's view of the filesystem such that the apparent root directory is not the real filesystem root directory, but one of its descendents.

SVR4 has a feature to do this change automatically. If the shell field (field 7) for a user in the /etc/passwd file is a "*" symbol, then the login program will make a chroot () call on the home directory field (field 6) listed in the entry. It will then reexecute the login program - only this time, it will be the login program in the reduced filesystem, and will be using the new passwd file found there (one that has a real shell listed, we would expect). If you do not have this feature in your version of UNIX , you can easily write a small program to do so (it will need to be SUID root for the chroot () call to function), and place the program's pathname in the shell field instead of one of the shells.

The restricted filesystem so named must have all the necessary files and commands for the login program to run and to execute programs (including shared libraries). Thus, the reduced filesystem needs to have an /etc directory, a /lib and /usr/lib directory, and a /bin directory. However, these directories do not need to contain all of the files and programs in the standard directories. Instead, you can copy or link only those files necessary for the user.[2] Remember to avoid symbolic links reaching out of the restricted area, because the associated directories will not be visible. Using loopback mounts of the filesystem in read-only mode is one good way to populate these limited filesystems as it also protects the files from modification. Figure 1.1 shows how the restricted filesystem is part of the regular filesystem.

[2] This may take some experimentation on your part to get the correct setup of files.

Figure 8.1: Example of restricted filesystem

There are at least two good uses for such an environment.

8.1.6 Group Accounts

A group account is an account that is used by more than one person. Group accounts are often created to allow a group of people to work on the same project without requiring that an account be built for each person. Other times, group accounts are created when several different people have to use the same computer for a short period of time. In many introductory computer courses, for example, there is a group account created for the course; different students store their files in different subdirectories or on floppy disks.

Group accounts are always a bad idea, because they eliminate accountability. If you discover that an account shared by 50 people has been used to break into computers across the United States, tracking down the individual responsible will be nearly impossible. Furthermore, a person is far more likely to disclose the password for a group account than he is to release the password for an account to which he alone has access. An account that is officially used by 50 people may in fact be used by 150; you have no way of knowing.

Instead of creating group accounts, create an account for each person in the group. If the individuals are all working on the same project, create a new UNIX group in the file /etc/group , and make every user who is affiliated with the project part of the group. This method has the added advantage of allowing each user to have his own start-up and dot files.

For example, to create a group called spistol with the users sid , john , and nancy in it, you might create the following entry in /etc/group :

spistol:*:201:sid,john,nancy

Then be sure that Sid, John, and Nancy understand how to set permissions and use necessary commands to work with the group account. In particular, they should set their umask to 002 or 007 while working on the group project.

NOTE: Some versions of UNIX limit the number of characters that can be specified in a single line. If you discover that you cannot place more than a certain number of users in a particular group, the above restriction might be the cause of your problem. In such a case, you may wish to place each user in the group by specifying the group in the user's /etc/passwd entry. Or, you may wish to move to a network configuration-management system, such as NIS + or DCE , which is less likely to have such limitations.