Previous | Next

Section 14 SECURITY

Objectives

This section aims to introduce you to the basics of security under the UNIX operating system. You will be introduced to

the types of security threats facing a computer system and the methods and tools available under UNIX to combat these problems,
a list of checks that can be used to maintain and check the security of a system,
a number of public domain packages that can be used to enhance the security of a UNIX system,
the problems involved with search paths, set-uid/set-gid scripts, and the permissions of important system files and directories, and
a number of accounting and log files and the commands that can be used to observe the state of a UNIX machine.

A machine running the UNIX operating system can be made into a very secure system if the right amount of effort is expended. However a very secure system is usually too inconvenient for normal users to use. In implementing a security scheme the Systems Administrator must weigh the following costs

the importance of the machine, its availability and the data stored on it,
the amount of effort required to make and keep the system secure, and
how the security features will effect the users of the system.

A system can be made as secure as is necessary but in doing so you might lose all ability to make use of the machine. A machine in a room with no door and no outside connection is very secure, no-one can use it. The Systems Administrator must balance the needs for convenience against the need for security.

To implement security on a system you should first identify the possible threats to the system. There are three major types of threats to a computer system

physical threats
The building burns down, an earthquake hits or an intruder breaks into your office or machine room.
unauthorised access to the system and its data, and
denial of service.
A vandal performs some action that makes the system unavailable to other users. For example, consuming all the disk space and running CPU intensive programs.

Having identified the threats to the machine a security plan must be implemented. A security plan should have two components

methods for preventing or decreasing the possibility of threats,
We will examine methods used under UNIX to prevent threats in this section.
penalties and policy,
There must be a policy stating what is allowed on the system and what is not. There must also exist set punishments for breaking the policy.
a recovery plan.
There is never a 100% guarantee with any security plan. Plans must exist that enable the system to recover from a security breach as quickly as possible.

Physical Threats

Physical threats include

unauthorised access to system consoles and other devices, and
acts of nature (i.e. floods and earthquakes).

Not all attacks on computer systems rely on intimate knowledge of computer hardware and software. The quickest way of denying service is to steal or destroy the physical hardware. Mechanisms should be in place to prevent access to the physical hardware of a system.

One part of modern computer systems that is often overlooked in a security plan is the cabling. The simplest way to bring a site's computer network to the ground is to take a shovel and dig up a few fibre optic cables. This does not always happen on purpose. CQU's network has been taken down a number of times by people (accidentally) digging up fibre.

Acts of Nature

While every effort can be taken to minimise damage from acts of nature there is always the possibility that an event will occur that can destroy a system. This is one possibility that must be served by the site's recovery plan.

The old maxim don't put all your eggs in one basket is very applicable. Copies of backup tapes should be kept at another site. A number of sites in earthquake prone California send copies of backup tapes to other States to make sure that tapes are out of the earthquake zone.

Logical Threats

Logical threats typically take the form of

human beings making mistakes,
Security threats are not always intentional. A student learning how to program might by mistake write a program that forks off thousands of child processes that bring the machine to a grinding halt (I know, I have done it).
human idiots with too much time on their hands, or
People who break into computer systems generally are not very smart. They simply have a great deal of patience and time. They rely on the fallibility of users and a variety of information sources to provide them with security holes through which to gain access to computer systems.
programs written by human idiots with too much time on their hands.
Table 14.1 lists some of the terminology used to describe these programs.

Computer systems today are complex congregations of interacting programs. The complexity of these programs and their interactions means that security holes crop up every now and then. It is these holes that bad guys use to break into systems.

It is important that a Systems Administrator keeps up to date with possible security holes in the systems being managed. Possible source of information about security holes are

system vendors,
Some (not all) vendors will attempt to keep their customers aware of security holes that have been discovered in their systems. Do not depend on them doing so.
trade magazines and other publications,
There are various books and magazines that discuss Systems Administration and security. However the nature of the published word means that notification may not always arrive in time.
the Internet, and
There are various forums on the Internet that discuss security issues. The net is generally more up to date than the previous two sources.

	Name		Method

	bacteria	programs that reproduce rapidly and eventually
			  overwhelm the system
	viruses		programs that hide themselves inside other programs
			  and cause bad side-effects when the enclosing
			  program is executed
	worms		programs that use networks to move from system to
			  system perhaps leaving behind viruses and bacteria
	Trojan horses	programs that appear to provide the functionality
			  of another program but really do something else
	back doors	undocumented methods of access within programs

		Table 14.1. Nasty Program Categories.

Computer Emergency Response Teams

The main aims of a Computer Emergency Response Team (CERT) are

work with the Internet community to facilitate its response to computer security events,
to take proactive steps to raise the community's awareness of computer security issues, and
to conduct research targeted at improving the security of existing systems.

The first CERT was formed by the Defence Advanced Research Projects Agency (DARPA) in response to the Internet worm incident in late 1988. Some of the services provided by CERT include

24 hour technical assistance for responding to computer security incidents,
product vulnerability assistance,
technical documents and seminars,
a number of mailing lists, and
an anonymous FTP server that provides access to a variety of security related documents and tools.

One of the major services provided by CERT are CERT advisories. A CERT advisory provides information on how to patch a known computer security problem or a warning about ongoing attacks.

Much of the information in this section is taken from the FAQ (frequently asked questions) list available from CERT's anonymous FTP site.

	Information Source		Description

	comp.security.announce		newsgroup to which CERT advisories
					  are posted
	cert.org			anonymous FTP site for CERT
	cert-advisory-request@cert.org	mailing list for CERT advisories
	cert-tools-request@cert.org	mailing list about security tools

		Table 14.2. Various Information sources provided by CERT.

Passwords

Passwords are the first line of defence in the security of a computer system. They are also usually the single biggest security hole. The main reason is that users do dumb things with passwords including

write their password on a bit of paper and then leave it laying around,
type their passwords in very slowly while someone is watching over their shoulder, and
choose really dumb passwords like password or their first name.

These methods are the easiest way of breaking into accounts on most computer sites, especially Universities.

There have been a number of experiments that attempt to discover how many users actually choose dumb passwords. All of these experiments have found an alarmingly high percentage of users choose stupid passwords. One experiment found that approximately 10 to 20% of passwords could be guessed using a password list containing variations on login names, user's first and last names and a list of 1800 common first names

Every year the program Crack (more on this program later in the section) is run using the password file of the machine used by students of the Systems Administration subject offered by Central Queensland University. Every year between 10 to 20% of the passwords are discovered by Crack.

There are a number of schemes a Systems Administrator can use to help make passwords more secure including

shadow passwords,
Once they have a system's encrypted passwords bad guys can crack these passwords using a variety of methods. Mentioned in the section on adding users, shadow passwords remove the encrypted password from the /etc/passwd file (a file readable by every user) and place them into a file readable only by the root user. This prevents the bad guys from (easily) getting a copy of your encrypted passwords.
proactive password programs,
Passwords are set by using the passwd command. A proactive password program replaces the normal passwd command with one that enforces certain rules. For example, ensuring that all passwords are greater than 5 characters in length and not accepting insecure passwords like usernames, the word password, 123456789 etc. If a user's new password breaks these rules the new passwd program will reject the password.
password generators,
Some sites do not allow users to choose their own passwords but instead they use password generators that provide the user with a list of passwords, consisting of random strings of characters, and asking them to choose one. The passwords that are generated have to be easy to remember or else users start writing them down.
password aging,
The longer a password is used the greater the chance that it will be broken. Password aging is usually built into most shadow password suites. The system forces passwords to be changed after a set time period. In addition the system may remember past passwords thereby preventing a user simply cycling through a list. Care must be taken that the time period after which passwords must be changed is not too frequent. If it is users start forgetting passwords and resort to writing them down.
password cracking, and
Most crackers will not break passwords by decrypting an encrypted password. Instead they encrypt a list of words (often taken from a dictionary) and compare the encrypted word with the encrypted password. If a match is found they know the password. There is a public domain program called Crack (see Table 14.7) that performs this task automatically. Even though it can consume a great deal of CPU time it can be useful to run Crack on a system's passwords regularly to identify the users who have insecure passwords.
user education.
Users do not want other people breaking into their accounts. If the users of a system are educated in the dangers of using bad passwords most will choose good passwords. One effective education program might be breaking their passwords with Crack and then telling them what their password is (if you can do it, the bad guys can).

Threats to `/etc/passwd`

The /etc/passwd file is the cornerstone of the password security system. The Systems Administrator should perform a number of checks on the contents of the /etc/passwd file. These checks are performed to make sure someone has not compromised security and left a gaping hole. The checks include looking for

accounts without passwords,
In most systems today this might mean checking the /etc/shadow file.
accounts without usernames,
You cannot login to an account without a username using the normal login procedure. However you can become that user by using the command su "".
accounts other than root with a user id of 0,
An account with a uid of 0 will have the same access permissions as the root user since the operating system thinks that anyone with uid 0 is root.
accounts other than root and other system accounts with a group id of 0,
Generally only the root user and one or two system accounts will belong to group 0. Any other account being in that group will obtain permissions it should not.
new additions or deletions from the /etc/passwd file that weren't performed by members of the Systems Administration team and,
The only modifications made to the /etc/passwd file should be made by the Systems Administration team. Any changes not made by that team implies someone has broken the security of your system. One method of checking this is keeping an up to date copy of the passwd file somewhere else and regularly comparing it with the /etc/passwd file.
the file permissions on the file itself
The passwd file is usually owned by root. Only the owner of the file should have write permission on the passwd file. If these permissions have changed someone has broken your security.

Exercise 14-1. Write a shell procedure passwdck that performs all of the checks listed above.

Passwords are only the first line of defence for a system. It must be assumed that someone will be able to break this line of security. The following section examines what steps can be undertaken to improve the internal security of the system.

Search Paths

When you enter a command the shell will search through all the directories listed in the PATH variable for an executable file with a filename that matches the command name. It is almost standard for users to include the current directory (signified by .) in their search path.

If the current directory is included in the search path it should be the last one.

If the current directory is the first directory in the path then whenever the user executes a command the shell will look first in the current directory. This is a security hole. One practice of bad guys is to place programs with names that match standard commands (like passwd and su) everywhere in the directory hierarchy.

They do this to take advantage of situations like the following

the current directory is the first directory in the search path of the user,
the user is in the directory /usr,
a bad guy has placed a program called passwd in that directory, and
the user wants to change their password so they enter passwd.

The shell will find the passwd program written and placed in the /usr directory by the bad guy. Bingo, the vandal has a password.

The current directory SHOULD NOT be in the search path for the root user.

Some Systems Administrators are so worried about this situation that they will always enter the full path of every command executed as root.

For example:

	Instead of typing
	bash$ su
	They will enter
	bash$ /bin/su

File Permissions

If a bad person has actually managed to crack someone's password and break into their account the next step they will want to take is obtain an account with more access (root if possible). The major hurdle they must overcome is UNIX file permissions.

A system's file permissions should be set up in such a way that will prevent users from accessing areas that they should not. The Systems Administrator is responsible for first setting up the file permissions correctly and then maintaining them.

The issues involved with file permissions include

maintaining correct protection settings on all files and directories,
In setting a system up each file and directory must have the correct permissions. This is especially true of important system files including device files and system configuration files (/etc/passwd, the startup scripts etc).
tracking changes, and
Once set up regular checks on the file permissions should be performed to ensure that no-one has been tampering with them.
tracking and limiting disk usage.
If the naughty person is a simple vandal interested only in bringing the system down he might try something like the following

		#!/bin/sh
		while [ 0 ]
		do
		  mkdir .temp  #start with a dot so it is normally hidden
		  cd .temp
		  cp /bin/* .
  		done

One way to prevent this type of thing from happening is to use disk quotas (see the next Section 15) to limit the amount of disk space any user can use.

Permission Settings

The Systems Administrator must ensure

that file system permissions are set correctly to start with, and
ensure that they do not change from these correct settings.

It is important that a system have the correct permission settings on all files especially important system files and the device files. If the system files, such as /etc/passwd, have incorrect permissions bad guys can do a number of nasty things to a system.

The device files are equally important. Having world read and write on device files for disk drives is a security hole. Since the disk can be read from the device file a bad person does not have to go through the file system (the file system enforces the file permissions system). With a little knowledge about the file system structure they can write a program to read (or delete) any file on the disk.

Permission settings are not always set correctly by the manufacturer. One version of a well-known workstation was distributed with sound capabilities, including a microphone. The problem was that the permissions, as set in the factory, for the microphone device file included world read. This meant that if the microphone was turned on anyone on the system could listen to what was being said in the vicinity of the microphone.

Once the permissions are set correctly they must be continually checked to ensure that they are not changed. This can be accomplished by a simple shell script that

performs an ls -l on all important files and sends the output to a summary file,
the summary files are kept for comparison,
the new summary file is compared against the previous summary file using the diff command, and
any differences between the two files means there has been a change.

A script of this description will report changes in

file ownership,
file permissions,
file modification dates, and
file owner and group owner.

Exercise 14-2. Write a shell script fs_check that performs the roles outlined above.

Setuid Programs and Shell Scripts

Create a text file called i_am.cc that contains the following C program

#include <stdio.h>
#include <unistd.h>

void main()
{
  int real_uid, effective_uid;
  int real_gid, effective_gid;

  real_uid = getuid();
  effective_uid = geteuid();
  real_gid = getgid();
  effective_gid = getegid();

  printf( "The real uid is %d\n", real_uid );
  printf("The effective uid is %d\n", effective_uid );
  printf("The real gid is %d\n", real_gid );
  printf("The effective gid is %d\n", effective_gid );
}

Compile the program by using the following command

	cc i_am.cc -o i_am

This will produce an executable program called i_am. Run the program.

Every time you execute a program the operating system creates a process. Associated with every process is a great deal of information including

the real user and group identifiers (both numbers), and
the effective user and group identifiers.

The real user and group identifiers are used to store the user and group ids of the user who executed the command. The effective user and group id are used to determine what access the process has, what files and directories it can read, write and delete.

Normally the effective ids will be the same as the real ids. However the set user identifier (set-uid) and the set group identifier permissions (set-gid) can be used to change the effective identifiers.

The process will be executing a program. The code for that program will be contained in a file somewhere. When the set-uid and set-gid bits are set the effective ids are changed to the uid and gid of the file's owners (instead of those of the user running the program).

The passwd command is a prime example of the use of set uid permissions. passwd allows any user to modify either the /etc/passwd file or the shadow password file. How is this possible if only the root user has write permission on these files? passwd is a set-uid program.

Exercise 14.3. Examine the permissions of the passwd program. What is different?

Exercise 14.4. Examine the manual page for chmod to discover how a file is made setuid and setgid.

Exercise 14.5. Change the ownership of the executable file i_am so it is owned by the root user and is setuid root. Run the program and see how this changes the output.

Exercise 14.6. Make the i_am program setgid root.

Never ever write a setuid shell script. In fact, some operating systems will not allow setuid shell scripts. The reason is that there are well-known ways of using setuid shell scripts to obtain extra privileges for nasty purposes.

Once bad people get root access on a machine they want to keep it. One method of doing this is to write a program or script that is setuid root and secret it away in some part of the file system. The next time they login all they have to do is run the program and they have root access again (even if the root password has been changed).

You should check regularly for the addition of any setuid and setgid programs anywhere in the file system.

Exercise 14-7. Incorporate into the script fs_check the ability to keep a track of current setuid and setgid programs.

Log Files and User Activity

Having all the above precautions in place is only the first step in maintaining security. In addition the Systems Administrator should perform regular checks on

what currently logged on users are doing,
what users have done or have tried to do.

Just to make certain nothing untoward is going on.

What are the Users up to?

A Systems Administrator should have some idea about what is considered normal behaviour for the system they maintain. A Systems Administrator should know the characteristics of their system including what is the normal load, the normal disk usage, when do certain users normally logon and what the users normally do.

This knowledge can help identify when something unusual is going on. There are a variety of system commands and systems that allow the Systems Administrator to keep an eye on the system. These commands are summarised in Table 14.3.

	Command	Purpose						Availability

	ps	List information about current processes	all systems
	top	Similar to ps but provides additional features	BSD systems
								  plus others
	w and	Display information about what users are	all systems
	 who	  logged on
	whodo	Displays information that combines w and ps	SysV
		  with some extras

		Table 14.3. System Observation Commands.

BSD and SysV each have different options for the ps command. Tables 14.4 and 14.5 list some of the more useful ps options for observing the current state of the system.

	Switch	Purpose

	-a	display processes owned by other users
	-x	include process with no controlling terminal
	-S	display accumulated CPU time for the process
	-g	display all processes
	-c	display the real command name

		Table 14.4. BSD ps Switches.


	Switch	Purpose

	-e	display every process now running
	-f	generate a full listing

		Table 14.5. SysV ps Switches.

For example:

	The whodo command produces output like the following
	bash$ whodo
	Thu Sep 22 10:44:53 1994
	UNIX_System_V

	pts/1		david	 10:41
	   pts/1	     4926	0:00 bash
	   pts/1	     4944 	0:00 elm

	pts/2		phil	9:36
	   pts/2	     4806	0:00 bash
	   pts/2	     4946	0:00 whodo

What have the Users done?

Most UNIX systems have a number of accounting functions (discussed in detail in Section 15) that maintain logs of what has been done to and with the system. The type of information normally kept includes

a record of every process executed including who executed it, when it started, when it finished and what percentage of system resources it used,
when users logged in and when they logged out,
various warning and error messages including when somebody has used su, any unsuccessful logins and various information about network connections, and
printer usage.

Table 14.6 summarises some of the commands that can be used to view this information.

	Command		Purpose					Availability

	sa	displays, summarises process accounting information	BSD
       lastcomm	displays information about the last commands that have	BSD
		  been executed
	ac	displays information about login, logout		BSD
	last	displays last login times for users			all
	pac	various information about printer use			BSD
	quot	amount of disk space used by individual users		all
	syslog	a logging function that records certain events, errors	BSD, some SysV
		  and warnings
	du	amount of disk space used				all
	df	amount of disk space free				all

		Table 14.6. Commands for examining Accounting Information.

These commands and systems are discussed in more detail in the next section.

Network Security

Connecting a computer to a network is probably the worst thing you can do from a security point of view. Connection to a network adds a new pile of security holes that have to be plugged and adds a whole new population of bad guys who will try to break your system.

The following is a brief introduction to network security. It is a topic too large to cover properly in an introductory Systems Administration course.

In this networking age it will be a rare computer site that is not networked in some way. The following are some of the schemes that are used to make networking more secure

Internet firewalls,
It is reasonably straight forward to connect an existing TCP/IP based LAN to the Internet. However there is one problem doing it simply. People outside your LAN can see and access each individual machine. This means that all the machines on the LAN must be secure. An Internet firewall surrounds the LAN and allows people outside the LAN to see only one machine. This one machine is set up as the drawbridge between the LAN and the outside world. All network traffic passing through this draw bridge is closely monitored and any traffic that is not allowed is thrown into the moat. The advantage of this system is that there is one central point used to control access to the local LAN. A firewall should be a compulsory part of an Internet connection.
packet filtering, Most commercially available routers and gateways provide some form of packet filtering. This means that the Systems Administrator can specify the type of network packets that are allowed from the outside network onto the local network. Packets can be accepted or rejected on the basis of the network they come from, the particular protocol they use or a number of other criteria. A packet filtering gateway is typically part of an Internet firewall.
encryption, and Most information sent across a network is sent in plain text (including passwords). It is possible to listen in on most of this information. One scheme to combat this is to encrypt the information passing across the network. One system that implements this is the Kerberos system (see Table 14.7)
special network daemons. The public domain program TCPWrappers provides a special daemon that provides some additional security, access control and logging facilities on network connections. TCPWrappers works by being inserted between the inetd daemon and the various network daemons that are executed by inetd.

Diagram 14.1. How network daemons are started without TCPWrappers.

Instead of running the appropriate network daemon inetd will instead run the TCPWrapper daemon. This daemon performs a variety of security checks and some logging functions before running the network daemon that inetd would have run in the original system (Diagram 14.2).

Diagram 14.2. How network daemons are started with TCPWrappers.

Public Domain Security Tools

There are a number of public domain packages that can assist the Systems Administrator in maintaining the security of a machine. Table 14.7 lists some of the more popular, the purpose of the packages and the Internet addresses they can be obtained from.

Name	Purpose				Location

COPS	checks the status of a UNIX	ftp://archie.au/security/cert/cops
	  system, checks permissions,	ftp://cert.sei.cmu.edu/pub/cops
	  for Trojan horses
Kerberos network encryption system	ftp://brolga.cc.uq.oz.au/pub/athena/kerberos
					ftp://aeneas.mit.edu/pub/ATHENA/kerberos
Crack	cracks insecure passwords	ftp://archie.au/security/cert/tools/crack 
					ftp://cert.sei.cmu.edu/pub/tools/crack
Tripwire checks for security of and	ftp://archie.au/security/tools/tripwire
	  changes to the file system	ftp://cert.sei.cmu.edu/pub/tools/tripwire

	Table 14.7. Public Domain Security Packages.

Conclusions

A UNIX machine can be made secure if care and effort is expended. How secure your system is to become must be balanced with other factors including ease of use.

Passwords are the first line of defence and often the weakest. Users must be encouraged to use secure, hard to guess passwords. The internal security supplied by file permissions is the second line of defence. To maintain the security of a machine the Systems Administrator should regularly

have in place a good and up to date recovery plan,
discourage poor choice of passwords and regularly check the security of the passwords,
check the file permissions of system configuration files,
maintain a close watch on the current state of the machine,
use disk quotas and other resource limit schemes to prevent denial of service,
check accounting and logging information for any suspicious events, and
if possible install and use a variety of security packages.

Review Questions

14.1. List the issues that are important for system security.

14.2. List ways in which password security can be enhanced.

14.3. List possible problems with the internal security of a system.

14.4. How would you go about breaking into a system?

Previous | Next

David Jones (author)
Chris Hanson (html 10/09/96)

Section 14

SECURITY