|
|
19.1 Dangerous AccountsEvery 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 PasswordsLike 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:[1]
% 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.
19.1.2 Default AccountsMany 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.
19.1.2.1 The superuser accountMany 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 accountsIn 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. 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).
19.1.3 Accounts That Run a Single CommandUnix 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 AccountsSome 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 shellsSome 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)[3]—usually as a link to the standard shell.[4] 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:
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 rshTo set up a restricted account that uses rsh , you must:
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 shellsBe 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( ) JailA 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.
There are at least three good uses for such an environment:
19.1.5.1 Setting up the chroot( ) environmentThere are three ways that the chroot( ) system call can be used within a Unix program or subsystem:
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.
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. Figure 19-1. Example of restricted filesystem
19.1.5.2 Limiting network serversThe 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 usersOne 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.
19.1.5.4 Checking new softwareAnother 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 AccountsA 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.
|
|
|
