19.1 Dangerous Accounts
Every account on your computer is a door to the outside, a portal
through which both authorized and unauthorized users can enter. Some
of the portals are well-defended, while others may not be. The system
administrator should search for weak points and seal them up.
19.1.1 Accounts Without Passwords
Like the lock on or guard at 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 /etc/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::133: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.
|
The /etc/passwd file may not be the correct file to check
for missing passwords on systems that have shadow password files
(introduced in Chapter 4 and described later in
this chapter). 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 information. Also,
systems using NIS, NIS+, or LDAP may get the passwords from a server;
see Chapter 14 for details.
|
|
19.1.2 Default Accounts
Many
computer systems are delivered to end users with one or more default
accounts. These accounts may have standard passwords or no passwords.
All default accounts that can be logged into represent a security
vulnerability on your system. For example, Table 19-1 lists the default accounts that come with a
minimal Red Hat Linux 7.3 release.
Table 19-1. Default accounts that come with a minimal Red Hat Linux 7.3 system
adm
|
General system administration
|
bin
|
Owns executable files
|
daemon
|
Network daemons
|
ftp
|
Anonymous FTP
|
games
|
Ownership of "high score files" in
the games system
|
gopher
|
Ownership of gopher server files
|
halt
|
System shutdown; lets somebody type
"halt" at the system console
without logging in (NB: Not necessarily a good idea!)
|
lp
|
Ownership of the printing subsystem
|
mail
|
Ownership of the email subsystem
|
news
|
Ownership of the Usenet Netnews subsystem
|
nobody
|
The local "nobody" user
|
operator
|
The user that performs tape backups with dump
|
root
|
The superuser
|
shutdown
|
Similar to halt; another user for shutting down the system
|
sync
|
A user that runs the sync command, so you can
type "sync" at the
login: prompt before
runningshutdown.
|
uucp
|
The user that owns the UUCP subsystem
|
19.1.2.1 The superuser account
Many Unix computers come with a
root account that has no password. Vendors tell
users to assign passwords to these accounts, but, more often than you
might think, users do not. If the person installing the system
can't think of a good password, some versions of
Unix allow the user to specify no password. (Unix is not alone with
this problem; other operating systems come delivered with standard
accounts such as SYSTEM with the password set to
MANAGER.)
One way around this problem is to have the operating system demand
passwords for special accounts such as root when
it is first installed, and not accept a blank password. If the user
can't think of a good password, the system can
generate a password that is both secure and easy to remember. Some
versions of Unix already do this. We hope that
all vendors adopt this approach in the future.
19.1.2.2 Other accounts
In addition to the superuser, there are
many, many other accounts that will come pre-installed with your
computer, or that will be added in the process of installing new
software, especially daemons. The reason for these accounts is,
strangely enough, security: each subsystem on the Unix computer is
given its own username, effectively partitioning the permissions for
each of these subsystems. By giving each subsystem on the computer a
different username, there is less chance that a compromised subsystem
will result in other systems being compromised.
Each of these accounts represents a potential security vulnerability
because any of them could be used to log into your computer.
Normally, these accounts are set up with a * or an
x in the password field. Because the Unix password
routines (typically crypt( ) or MD5) will never
generate a password that begins with a * or is
one-character long, this prevents anyone from logging into these
accounts. But if a password is given to the account, or if the
invalid password is removed, then the account could be used to access
your computer.
When you first install your operating system, you should make a list
of all of the accounts that came with your computer system. Once you
have this list, ensure that each of the accounts is disabled or
deleted, or has a good password.
|
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.)
|
|
One problem with common account names is that these accounts tend to
be attacked. Table 19-2 is a list of some of these
accounts. 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 Section 19.1.3 and Section 19.1.4).
Table 19-2. Account names commonly attacked on Unix systems
bin
|
guest
|
mail
|
open
|
uucp
|
demo
|
help
|
maint
|
system
|
visitor
|
finger
|
ingres
|
manager
|
telnet
|
who
|
games
|
lp
|
nuucp
|
toor
|
|
19.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
here:
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 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 such as
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.
Some site administrators like to set up accounts with names such as
sync,
halt, or shutdown that have
no password. The theory behind these accounts is that they let
somebody walk up to the system console and perform a
safe shutdown of the computer system
in the event of an emergency. Whether you should have such an account
depends on the policies in place at your organization. If you do have
such an account, you should be sure that it can be used only from the
system console, and not over the network. (One easy way to assure
this is to only allow access using SSH, and to set your
sshd.conf or sshd_config
configuration file so that accounts without passwords cannot be
accessed remotely.)
Here is an example /etc/passwd entry for a
script run by such a shutdown user:
shutdown::0:998:shutdown:/usr/home/shutdown:/usr/local/bin/shutdown-script
Notice that the user has a UID of 0. This is required, as the
shutdown command must be run by the superuser.
Here is the matching shutdown script that is the
shutdown user's shell:
#!/bin/sh
if [ `/usr/bin/tty` != '/dev/ttyv0' ]; then
echo Shutdown can only be run on the system console.
exit 0
fi
/sbin/shutdown
19.1.4 Open Accounts
Some
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 such as 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 connect through the guest account on your
machine, making their connections difficult or even impossible to
trace.
Providing open accounts in your system is a very bad idea. If you
must have them, 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.
19.1.4.1 Restricted shells
Some Unix shells allow you to
set up a restricted mode that can be used to minimize the dangers of
an open account. This mode occurs when the shell is invoked with a
-r command-line option, or with some shells,
when the shell is started under the name rsh
(restricted shell)—usually as a link
to the standard shell. When a restricted
shell starts up, it executes the commands in the relevant startup
files in the user's home directory
($HOME/.profile in the case of a restricted
sh or bash,
$HOME/.csh and $HOME/.login in the case of a
restricted csh).
Once the startup files are processed, the following restrictions go
into effect:
The user can't change the current directory.
The user can't change the value of the PATH
environment variable.
The user can't use command names containing slashes
or supply filenames with slashes in them to certain built-in shell
commands.
The user can't redirect output with >, >>,
or other metacharacters.
The user can't use the shell's
built-in exec command to replace the shell with
another shell.
In the case of ksh and
bash, the user can't modify the
ENV or SHELL variables. The Korn shell further prevents the user from
changing the primary group using the newgrp
command.
As an added security measure, if the user tries to interrupt
rsh while it is processing the startup files,
the restricted shell immediately exits.
The net effect of these restrictions is that they prevent the user
from running any command that is not in a directory contained in the
PATH environment variable, prevent the user from changing her PATH,
and prevent the user from changing the .profile
of the restricted account that sets the PATH variable in the first
place.
You can further modify the
.profile file to prevent the restricted account
from being used over the network. You do this by having the shell
script use the tty command to make sure that the
user is attached to a physical terminal and not a network port.
Be aware that rsh is not a panacea. If the user
is able to run another shell, such as sh or
csh, the user will have the same access to your
computer that he would if the account was not restricted at all.
Likewise, if the user can run a program that supports shell escapes,
such as mail, the account is unrestricted (see
Section 19.1.4.3).
19.1.4.2 How to set up a restricted account with rsh
To set up a restricted account that uses
rsh , you must:
|
The setup we show in the following example is not entirely safe, as
we explain later in this chapter.
|
|
For example, to set up a restricted shell that lets guests play
rogue and hack, and use the
talk program, first create a user called
player that has
/bin/restricted_shell as its shell and
/usr/rshhome as its home directory:
player::100:100:The Games Guest user:/usr/rshhome:/bin/restricted_shell
The /bin/restricted_shell shell is actually a
shell script:
#!/bin/sh
exec /bin/ksh -r
Next, create a directory for only the programs you want the guest to
use, and fill the directory with the appropriate links:
# mkdir /usr/rshhome /usr/rshhome/bin
# ln /usr/games/hack /usr/rshhome/bin/hack
# ln /usr/games/rogue /usr/rshhome/bin/rogue
# ln /usr/bin/talk /usr/rshhome/bin/talk
# chmod 555 /usr/rshhome/bin
# chmod 555 /usr/rshhome
Finally, create a .profile for the
player user that sets the PATH environment
variable and prints some instructions:
# cat > /usr/rshhome/.profile
/bin/echo This guest account is only for the use of authorized guests.
/bin/echo You can run the following programs:
/bin/echo rogue A role playing game
/bin/echo hack A better role playing game
/bin/echo talk A program to talk with other people.
/bin/echo
/bin/echo Type "logout" to log out.
PATH=/usr/rshhome/bin
SHELL=/bin/rsh
export PATH SHELL
^D
# chmod 444 /usr/rshhome/.profile
# chown player /usr/rshhome/.profile
# chmod 500 /usr/rshhome
19.1.4.3 Potential problems with restricted shells
Be especially
careful when you use restricted shells: many Unix commands allow
shell escapes, or means of executing arbitrary commands or subshells
from within themselves. Some programs that have shell escapes do not
document this feature; several popular games fall into this category.
If a program that can be run by a
"restricted" account has the
ability to run subprograms, then the account may not be restricted at
all. For example, if the restricted account can use
man to read reference pages, then a person using
the restricted account can use man to start up
an editor, then spawn a shell, and then run programs on the system.
For instance, in our above example, all of the commands linked into
the restricted bin will spawn a subshell when
presented with the appropriate input. Thus, although the account
appears to be restricted, it will actually only slow down users who
don't know about shell escapes.
19.1.5 Restricted Filesystem with the chroot( ) Jail
A better 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 descendants.
|
A
chroot( ) environment is sometimes called a
jail. This is because a process that runs
inside a chroot( ) environment is somewhat
locked up: that process can access only files that are within the
chroot( ) hierarchy. On some versions of Unix
the jail is not perfect, and a process running as the superuser can
break out of the jail. Nevertheless, programs (especially network
daemons) that use the chroot( ) system call and
are provided with a minimal restricted filesystem are significantly
more secure than those that do not.
|
|
There are at least three good uses for such an environment:
Limiting specific programs, especially network daemons
Limiting specific users, especially in a web-hosting environment
Testing new software
19.1.5.1 Setting up the chroot( ) environment
There are three ways that the chroot( ) system
call can be used within a Unix program or subsystem:
Some programs will call the chroot( ) system
call directly. Many FTP servers make use of the
chroot( ) call for either anonymous or normal
FTP access. (For more information, see Section 12.3.3.)
The Internet Software Consortium's
bind name server can run within a
chroot( ) environment. For a program to use the
chroot ( ) system call directly, that program
must be running as the superuser.
Linux
and BSD-derived operating systems have a chroot
wrapper command that can be used to run any command within a
restricted filesystem. This makes it easy to use the
chroot( ) functionality from a script. Once
again, the script must be run as root.
SVR4 has a feature that allows users to be
automatically restricted when they log in. 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
re-execute the login program—only this
time, it will be the login program in the
reduced filesystem, and it will use the new
passwd file found there (one that has a real
shell listed, we would expect).
No special provisions are required to use chroot(
) in programs that call the chroot( )
call directly. But when additional programs are to be run within the
chroot( ) environment, it is necessary to set up
the restricted filesystem so that it has all the necessary files and
commands for these programs to run. This can be very complicated if
the program uses shared libraries—all of the shared libraries
must be present! Thus, the reduced filesystem needs to have an
/etc directory, a
/lib and /usr/lib
directory, and a
/bin directory.
|
These /etc, /lib, and
/usr/lib directories inside the restricted
environment do not need to contain all of the files and programs in
the standard directories—only the ones that are used. It is
good practice to try to limit files and directories to those that you
know are necessary. Furthermore, these directories do not need to
have copies of the files; they can have hard links to the files
instead, provided that the restricted directory is on the same
partition as the target. Remember to avoid
symbolic links because
symbolic links will not be followed if they point outside of the
restricted area. (It may take some experimentation on your part to
get the correct setup of files.) In some cases, symbolic links can
also be used by superuser processes, in some cases, to break out of
the chroot area.
|
|
Files within a restricted filesystem can be further protected by
mounting them as a read-only filesystem via NFS from a local NFS
server—that is, a "loopback"
NFS mount. Figure 19-1 shows how the restricted
filesystem is part of the regular filesystem.
Modern free BSD systems have implemented
a new system call, jail( ), that works like
chroot( ) but offers several security
enhancements:
Even a superuser in a jail area can't create or use
references to shared resources outside the jail. For example,
root can't create a
/dev/kmem device file either inside or outside
the jail.
A single IP address can be associated with the jail. Processes in the
jail can only send and receive IP packets through this address.
With these additional restrictions, it's possible to
build jailed virtual installations of the entire Unix operating
system, superuser and all, that can't compromise
each other or the jailing system.
|
19.1.5.2 Limiting network servers
The primary use of the
chroot( ) system call is in network servers. By
calling chroot( ) before accepting connections
from the network, a server can restrict its view of the
computer's filesystem. In the event that the server
is compromised, the attacker will be significantly limited in what he
can do.
One of the advantages of building the chroot( )
functionality into the daemon, rather than using a wrapper program,
is that it is considerably easier to set up the restricted
filesystem. Specifically, it is not necessary to create copies of
executables, shared libraries, and other files because all of the
necessary files are loaded into the server's address
space before the chroot( ) call is made.
Because of bugs on some older versions of Unix that may not have been
fixed in the version that you are using, the chroot(
) system call should always be used in combination with
the chdir( ) system call.
For example:
/* Restrict this daemon to its log file directory. */
chdir("/var/log/myserver");
chroot("/var/log/myserver");
chdir("/");
You should also test the return values of chdir(
) and chroot( ) to ensure that you
were successful. See Chapter 16 for details.
Nevertheless, because it is sometimes possible to
"break out" of the
chroot( ) jail under certain circumstances, you
should never rely on this system call as your
program's sole source of security.
19.1.5.3 Limiting users
One use of restricted filesystems is to limit the capabilities of
users on your computer.
For example, suppose you have an online company directory and an
order-tracking frontend to a customer database. You might want to
make these available to your customer service personnel. There is no
need to make all of your files and commands accessible to these
users. Instead, you can set up a minimal account structure so that
they can log in, use standard programs that you provide, and have the
necessary access. At the same time, you have put another layer of
protection between your general system and the outside: if intruders
manage to break the password of one of these users and enter the
accounts, they will not have access to the real
/etc/passwd (to download and crack), they will
not have access to network commands to copy files in or out, and they
will not be able to compile new programs to do the same.
Restricted filesystems are also useful in
web-hosting environments, where you want to give users access to
their own files via FTP, but you do not want them to generally
have access to other files on the web server. Many FTP daemons can be
configured so that they will automatically restrict incoming users to
their home directories by performing a chroot( )
system call on those directories once the users log in.
|
Be very, very careful about creating any SUID programs that make a
chroot( ) call. If any user can write to the
directory to which the program chroots, or if
the user can specify the directory to which the chroot(
) occurs, the user could become a superuser on your
system. To do this, he need only change the password file in the
restricted environment to give himself the ability to
su to root, change to the
restricted environment, create a SUID root
shell, and then log back in as the regular user to execute the SUID
shell.
|
|
19.1.5.4 Checking new software
Another use of a restricted environment is
to test new software of questionable origin. In this case, you
configure an environment for testing and enter it with either the
chroot( ) system call or with a program that
executes chroot( ) on your behalf. Then, when
you test the software you have obtained, or unpack an archive, or
perform any other possibly risky operation, the only files you will
affect are the ones you put in the restricted environment—not
everything in the whole filesystem!
19.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 people
have to use the same computer for a short period of time. In some
introductory computer courses, for example, a group account is
sometimes created for the course; different students store their
files in different subdirectories.
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 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
startup 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.
|
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 LDAP, which is less likely to have such
limitations.
|
|
|