Practical UNIX & Internet Security phần 9 pptx

login REPEATED LOGIN FAILURES ON <tty>
[FROM <hostname>] <user>
Somebody tried to log in as <user> and supplied a bad
password more than five times.
reboot rebooted by <user> <user> rebooted the system with the /etc/reboot
command.
su BAD SU <user> on <tty> Somebody tried to su to the superuser and did not
supply the correct password.
shutdown reboot, halt, or shutdown by <user> on <tty> <user> used the /etc/shutdown command to reboot,
halt, or shut down the system.
Other critical conditions that might be present might include messages about full filesystems, device failures, or
network problems.
Table 10.5: Typical Info Messages
Program Message Meaning
date date set by <user> <user> changed the system date.
login ROOT LOGIN <tty> [FROM <hostname>]
root logged in.
su <user> on <tty> <user> used the su command to become the superuser.
getty <tty> /bin/getty was unable to open <tty>.
NOTE: For security reasons, some information should never be logged. For example, although you
should log failed password attempts, you should not log the password that was used in the failed attempt.
Users frequently mistype their own passwords, and logging these mistyped passwords would help a
computer cracker break into a user's account. Some system administrators believe that the account name
should also not be logged on failed login attempts - especially when the account typed by the user is
nonexistent. The reason is that users occasionally type their passwords when they are prompted for their
usernames. If invalid accounts are logged, then it might be possible for an attacker to use those logs to
infer people's passwords.
You may want to insert syslog calls into your own programs to record information of importance. Third-party software
also often has a capability to send log messages into the syslog if configured correctly. For example, Xyplex terminal
servers and Cisco routers both can log information to a network syslog daemon; Usenet news and POP mail servers
also log information.

If you are writing shell scripts, you can also log to syslog. Usually, systems with syslog come with the logger
command. To log a warning message about a user trying to execute a shell file with invalid parameters, you might
include:
logger -t ThisProg -p user.notice "Called without required # of parameters"
NOTE: Prior to 1995, many versions of the syslog library call did not properly check their inputs to be
certain that the data would fit into the function's internal buffers. Thus, many programs could be coerced
to accept input to write arbitrary data over their stacks, leading to potential compromise. Be certain that
you are running software using a version of syslog that does not have this vulnerability.
10.5.3.1 Beware false log entries
The UNIX syslog facility allows any user to create log entries. This capability opens up the possibility for false data to
be entered into your logs. An interesting story of such logging was given to us by Alec Muffet:
A friend of mine - a UNIX sysadmin - enrolled as a mature student at a local polytechnic in order to
secure the degree which had been eluding him for the past four years.
[Chapter 10] 10.5 The UNIX System Log (syslog) Facility
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_05.htm (6 of 7) [2002-04-12 10:45:30]
Simpo PDF Merge and Split Unregistered Version -
One of the other students on his Computer Science course was an obnoxious geek user who was shoulder
surfing people and generally making a nuisance of himself, and so my friend determined to take revenge.
The site was running an early version of Ultrix on an 11/750, but the local operations staff were
somewhat paranoid about security, had removed world execute from "su" and left it group-execute to
those in the wheel group, or similar; in short, only the sysadmin staff should have execute access for su.
Hence, the operations staff were somewhat worried to see messages with the following scrolling up the
console:
BAD SU: geekuser ON ttyp4 AT 11:05:20
BAD SU: geekuser ON ttyp4 AT 11:05:24
BAD SU: geekuser ON ttyp4 AT 11:05:29
BAD SU: geekuser ON ttyp4 AT 11:05:36

When the console eventually displayed:
SU: geekuser ON ttyp4 AT 11:06:10

all hell broke loose: the operations staff panicked at the thought of an undergrad running around the
system as root and pulled the plug (!) on the machine. The system administrator came into the terminal
room, grabbed the geekuser, took him away and shouted at him for half an hour, asking (a) why was he
hacking, (b) how was he managing to execute su and (c) how he had guessed the root password?
Nobody had noticed my friend in the corner of the room, quietly running a script which periodically
issued the following command, redirected into /dev/console, which was world-writable:
echo BAD SU: geekuser ON ttyp4 AT `date`
The moral of course is that you shouldn't panic, and that you should treat your audit trail with suspicion.
10.4 Per-User Trails in the
Filesystem
10.6 Swatch: A Log File Tool
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 10] 10.5 The UNIX System Log (syslog) Facility
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_05.htm (7 of 7) [2002-04-12 10:45:30]
Simpo PDF Merge and Split Unregistered Version -
Chapter 6

6. Cryptography
Contents:
A Brief History of Cryptography
What Is Encryption?
The Enigma Encryption System
Common Cryptographic Algorithms
Message Digests and Digital Signatures
Encryption Programs Available for UNIX
Encryption and U.S. Law
Cryptography is the science and art of secret writing - keeping information secret.[1] When applied in a
computing environment, cryptography can protect data against unauthorized disclosure; it can
authenticate the identity of a user or program requesting service; and it can disclose unauthorized
tampering. In this chapter, we'll survey some of those uses, and present a brief summary of encryption

methods that are often available in UNIX systems.
[1] Cryptanalysis is the related study of breaking ciphers. Cryptology is the combined study
of cryptography and cryptanalysis.
Cryptography is an indispensable part of modern computer security.
6.1 A Brief History of Cryptography
Knowledge of cryptography can be traced back to ancient times. It's not difficult to understand why: as
soon as three people had mastered the art of reading and writing, there was the possibility that two of
them would want to send letters to each other that the third could not read.
In ancient Greece, the Spartan generals used a form of cryptography so that the generals could exchange
secret messages: the messages were written on narrow ribbons of parchment that were wound spirally
around a cylindrical staff called a scytale. After the ribbon was unwound, the writing on it could only be
read by a person who had a matching cylinder of exactly the same size. This primitive system did a
reasonably good job of protecting messages from interception and from the prying eyes of the message
courier as well.
In modern times, cryptography's main role has been in securing electronic communications. Soon after
[Chapter 6] Cryptography
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (1 of 4) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
Samuel F. B. Morse publicly demonstrated the telegraph in 1845, users of the telegraph began worrying
about the confidentiality of the messages that were being transmitted. What would happen if somebody
tapped the telegraph line? What would prevent unscrupulous telegraph operators from keeping a copy of
the messages that they relayed and then divulging them to others? The answer was to encode the
messages with a secret code, so that nobody but the intended recipient could decrypt them.
Cryptography became even more important with the invention of radio, and its use in war. Without
cryptography, messages transmitted to or from the front lines could easily be intercepted by the enemy.
6.1.1 Code Making and Code Breaking
As long as there have been code makers, there have been code breakers. Indeed, the two have been
locked in a competition for centuries, with each advance on one side being matched by counter-advances
on the other.
For people who use codes, the code-breaking efforts of cryptanalysts pose a danger that is potentially

larger than the danger of not using cryptography in the first place. Without cryptography, you might be
reluctant to send sensitive information through the mail, across a telex, or by radio. But if you think that
you have a secure channel of communication, then you might use it to transmit secrets that should not be
widely revealed.
For this reason, cryptographers and organizations that use cryptography routinely conduct their own
code-breaking efforts to make sure that their codes are resistant to attack. The findings of these
self-inflicted intrusions are not always pleasant. The following brief story from a 1943 book on
cryptography demonstrates this point quite nicely:
[T]he importance of the part played by cryptographers in military operations was
demonstrated to us realistically in the First World War. One instructive incident occurred in
September 1918, on the eve of the great offensive against Saint-Mihiel. A student
cryptographer, fresh from Washington, arrived at United States Headquarters at the front.
Promptly he threw the General Staff into a state of alarm by decrypting with comparative
ease a secret radio message intercepted in the American sector.
The smashing of the German salient at Saint-Mihiel was one of the most gigantic tasks
undertaken by the American forces during the war. For years that salient had stabbed into
the Allied lines, cutting important railways and communication lines. Its lines of defense
were thought to be virtually impregnable. But for several months the Americans had been
making secret preparations for attacking it and wiping it out. The state was set, the minutest
details of strategy had been determined - when the young officer of the United States
Military Intelligence spread consternation through our General Staff.
The dismay at Headquarters was not caused by any new information about the strength of
the enemy forces, but by the realization that the Germans must know as much about our
secret plans as we did ourselves - even the exact hour set for the attack. The `intercepted'
message had been from our own base. German cryptographers were as expert as any in the
world, and what had been done by an American student cryptographer could surely have
been done by German specialists.
[Chapter 6] Cryptography
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (2 of 4) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -

The revelation was even more bitter because the cipher the young officer had broken,
without any knowledge of the system, was considered absolutely safe and had long been
used for most important and secret communications.[2]
[2] Smith, Laurence Dwight. Cryptography: The Science of Secret Writing.
Dover Publications, New York, 1941.
6.1.2 Cryptography and Digital Computers
Modern digital computers are, in some senses, the creations of cryptography. Some of the first digital
computers were built by the Allies to break messages that had been encrypted by the Germans with
electromechanical encrypting machines. Code breaking is usually a much harder problem than code
making; after the Germans switched codes, the Allies often took several months to discover the new
coding systems. Nevertheless, the codes were broken, and many historians say that World War II was
shortened by at least a year as a result.
Things really picked up when computers were turned to the task of code making. Before computers, all
of cryptography was limited to two basic techniques: transposition, or rearranging the order of letters in a
message (such as the Spartan's scytale), and substitution, or replacing one letter with another one. The
most sophisticated pre-computer cipher used five or six transposition or substitution operations, but
rarely more.
With the coming of computers, ciphers could be built from dozens, hundreds, or thousands of complex
operations, and yet could still encrypt and decrypt messages in a short amount of time. Computers have
also opened up the possibility of using complex algebraic operations to encrypt messages. All of these
advantages have had a profound impact on cryptography.
6.1.3 Modern Controversy
In recent years, encryption has gone from being an arcane science and the stuff of James Bond movies, to
being the subject of debate in several nations (but we'll focus on the case in the U.S. in the next few
paragraphs). In the U.S. that debate is playing itself out on the front pages of newspapers such as The
New York Times and the San Jose Mercury News.
On one side of the debate are a large number of computer professionals, civil libertarians, and perhaps a
majority of the American public, who are rightly concerned about their privacy and the secrecy of their
communications. These people want the right and the ability to protect their data with the most powerful
encryption systems possible.

On the other side of the debate are the United States Government, members of the nation's law
enforcement and intelligence communities, and (apparently) a small number of computer professionals,
who argue that the use of cryptography should be limited because it can be used to hide illegal activities
from authorized wiretaps and electronic searches.
MIT Professor Ronald Rivest has observed that the controversy over cryptography fundamentally boils
down to one question:
Should the citizens of a country have the right to create and store documents which their
[Chapter 6] Cryptography
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (3 of 4) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
government cannot read?[3]
[3] Rivest, Ronald, speaking before the MIT Telecommunications Forum,
Spring 1994.
This chapter does not address this question. Nor do we attempt to explore the U.S. Government's[4]
claimed need to eavesdrop on communications, the fear that civil rights activists have of governmental
abuse, or other encryption policy issues. Although those are interesting and important questions -
questions you should also be concerned with as a computer user - they are beyond the scope of this book.
Instead, we focus on discussion of the types of encryption that are available to most UNIX users today
and those that are likely to be available in the near future. If you are interested in the broader questions of
who should have access to encryption, we suggest that you pursue some of the references listed in
Appendix D, Paper Sources, starting with Building in Big Brother, edited by Professor Lance Hoffman.
[4] Or any other government!
A Note About Key Escrow
There has been considerable debate recently centering on the notion of key escrow. The usual context is
during debate over the ability of private citizens to have access to strong cryptography. Many
government officials and prominent scientists advocate a form of escrowed encryption as a good
compromise between law enforcement needs and privacy concerns. In such schemes, a copy of the
decryption key for each user is escrowed by one or more trusted parties, and is available if a warrant is
issued for it.
Whatever your feelings are on the matter of law enforcement access to your decryption keys, consider

escrowing your keys! By this, we do not mean making your keys available to the government. Rather, we
mean placing a copy of your keys in a secure location where they can be retrieved if you or someone else
needs them. You may pick a key so strong that you forget it a year from now. Or, you might develop
amnesia, get food poisoning from a bad Twinkie, or get kidnapped by aliens to keep Elvis company. If
any of these calamities befall you, how are your coworkers or family going to decrypt the vital records
that you have encrypted?
We recommend that you deposit copies of your encryption keys and passwords in safe locations, such as
a safe or safety deposit box. If you are uncomfortable about leaving the keys all in one place, there are
algorithms with which you can split a key into several parts and deposit a part with each of several
trusted parties. With key-splitting schemes, one or two parts by themselves are not enough to recreate the
key, but a majority of them is enough to recover the key. Consult a good book on cryptography for
details.
But do escrow your own keys!
5.10 Summary 6.2 What Is Encryption?
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 6] Cryptography
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch06_01.htm (4 of 4) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
Chapter 10
Auditing and Logging

10.4 Per-User Trails in the Filesystem
Although not obvious, there are some files that are kept on a per-user basis that can be helpful in
analyzing when something untoward has happened on your system. While not real log files, as such, they
can be treated as a possible source of information on user behavior.
10.4.1 Shell History
Many of the standard user command shells, including csh, tcsh, and ksh, can keep a history file. When
the user issues commands, the text of each command and its arguments are stored into the history file for
later re-execution. If you are trying to recreate activity performed on an account, possibly by some
intruder, the contents of this file can be quite helpful when coupled with system log information. You

must check the modification time on the file to be sure that it was in use during the time the suspicious
activity occurred. If it was created and modified during the intruder's activities, you should be able to
determine the commands run, the programs compiled, and sometimes even the names of remote accounts
or machines that might also be involved in the incident. Be sure of your target, however, because this is
potentially a violation of privacy for the real user of this account.
Obviously, an aware intruder will delete the file before logging out. Thus, this mechanism may be of
limited utility. However, there are two ways to increase your opportunity to get a useful file. The first
way is to force the logout of the suspected intruder, perhaps by using a signal or shutting down the
system. If a history file is being kept, this will leave the file on disk where it can be read. The second way
to increase your chances of getting a usable file is to make a hard link to the existing history file, and to
locate the link in a directory on the same disk that is normally inaccessible to the user (e.g., in a
root-owned directory). Even if the intruder unlinks the file from the user's directory, it can still be
accessed through the extra link.
Also note that this technique can come in handy if you suspect that an account is being used
inappropriately. You can alter the system profile to create and keep a history file, if none was kept
before. On some systems, you can even designate a named pipe (FIFO) as the history file, thus
transmitting the material to a logging process in a manner that cannot be truncated or deleted.
Even if you were unable to preserve a copy of the history file, but one was created and then unlinked by
the intruder, you can still gain some useful information if you act quickly enough. The first thing you
must do is to either take the system to single-user mode, or umount the disk with the suspect account (we
recommend going to single-user mode). Then, you can use disk-examination tools to look at the records
on the free list. When a file is deleted, the contents are not immediately overwritten. Instead, the data
[Chapter 10] 10.4 Per-User Trails in the Filesystem
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_04.htm (1 of 2) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
records are added back into the freelist on disk. If they are not reused yet (which is why you umount the
disk or shut the system down), you can still read the contents.
10.4.2 Mail
Some user accounts are configured to make a copy of all outgoing mail in a file. If an intruder sends mail
from a user account where this feature is set (or where you set it), this feature can provide you with

potentially useful information. In at least one case we know of, a person stealing confidential information
by using a coworker's pirated password was exposed because of recorded email to his colleagues that he
signed with his own name!
Some systems also record a log file of mail sent and received. This file can be kept per-user, or it may be
part of the system-wide syslog audit trail. The contents of this log can be used to track what mail has
come in and left the system. If nothing else, we have found this information to be useful when a disk
error (or human error) wipes out a whole set of mailboxes - the people listed in the mail log file can be
contacted to resend their mail.
10.4.3 Network Setup
Each user account can have several network configuration files that can be edited to provide shortcuts for
commands, or to assert access rights. Sometimes, the information in these files will provide a clue as to
the activities of a malefactor. Examples include the .rhosts file for remote logins, and the .netrc file for
FTP. Examine these files carefully for clues, but remember: the presence of information in one of these
files may have been there prior to the incident, or it may have been planted to throw you off.
10.3 Program-Specific Log
Files
10.5 The UNIX System Log
(syslog) Facility
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 10] 10.4 Per-User Trails in the Filesystem
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch10_04.htm (2 of 2) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
Chapter 11
Protecting Against Programmed
Threats

11.2 Damage
The damage that programmed threats do ranges from the merely annoying to the catastrophic - for
example, the complete destruction of all data on a system by a low-level disk format. The damage may
be caused by selective erasures of particular files, or minute data changes that swap random digits or zero

out selected values. Many threats may seek specific targets - their authors may wish to damage a
particular user's files, destroy a particular application, or completely initialize a certain database to hide
evidence of some other activity.
Disclosure of information is another type of damage that may result from programmed threats. Rather
than simply altering information on disk or in memory, a threat can make some information readable,
send it out as mail, post it on a bulletin board, or print it on a printer. This information could include
sensitive material, such as system passwords or employee data records, or something as damaging as
trade secret software. Programmed threats may also allow unauthorized access to the system, and may
result in installing unauthorized accounts, changing passwords, or circumventing normal controls. The
type of damage done varies with the motives of the people who write the malicious code.
Malicious code can cause indirect damage, too. If your firm ships software that inadvertently contains a
virus or logic bomb, there are several forms of potential damage to consider. Certainly, your corporate
reputation will suffer. Your company could also be held accountable for customer losses as well; licenses
and warranty disclaimers used with software might not protect against damage suits in such a situation.
You cannot know with certainty that any losses (of either kind - direct or indirect) will be covered by
business insurance. If your company does not have a well-defined security policy and your employees
fail to exercise precautions in the preparation and distribution of software, your insurance may not cover
subsequent losses. Ask your insurance company about any restrictions on their coverage of such
incidents.
11.1 Programmed Threats:
Definitions
11.3 Authors
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 11] 11.2 Damage
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch11_02.htm [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
Chapter 1
Introduction

1.2 What Is an Operating System?

For most people, a computer is a tool for solving problems. When running a word processor, a computer
becomes a machine for arranging words and ideas. With a spreadsheet, the computer is a financial
planning machine, one that is vastly more powerful than a pocket calculator. Connected to an electronic
network, a computer becomes part of a powerful communications system.
At the heart of every computer is a master set of programs called the operating system. This is the
software that controls the computer's input/output systems such as keyboards and disk drives, and that
loads and runs other programs. The operating system is also a set of mechanisms and policies that help
define controlled sharing of system resources.
Along with the operating system is a large set of standard utility programs for performing common
functions such as copying files and listing the contents of directories. Although these programs are not
technically part of the operating system, they can have a dramatic impact on a computer system's
security.
All of UNIX can be divided into three parts:
The kernel, or the heart of the UNIX system, is the operating system. The kernel is a special
program that is loaded into the computer when it is first turned on. The kernel controls all of the
computer's input and output systems; it allows multiple programs to run at the same time, and it
allocates the system's time and memory among them. The kernel includes the filesystem, which
controls how files and directories are stored on the computer's hard disk. The filesystem is the
main mechanism by which computer security is enforced. Some modern versions of UNIX allow
user programs to load additional modules, such as device drivers, into the kernel after the system
starts running.
●
Standard utility programs are run by users and by the system. Some programs are small and serve
a single function - for example, /bin/lslists files and /bin/cp copies them. Other programs are large
and perform many functions - for example, /bin/sh and /bin/csh, UNIX shells that process user
commands, are themselves programming languages.
●
System database files, most of which are relatively small, are used by a variety of programs on the
system. One file, /etc/passwd, contains the master list of every user on the system. Another file,
/etc/group, describes groups of users with similar access rights.

●
From the point of view of UNIX security, these three parts interact with a fourth entity:
[Chapter 1] 1.2 What Is an Operating System?
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_02.htm (1 of 2) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
Security policy, which determines how the computer is run with respect to the users and system
administration. Policy plays as important a role in determining your computer's security as the
operating system software. A computer that is operated without regard to security cannot be
trusted, even if it is equipped with the most sophisticated and security-conscious software. For this
reason, establishing and codifying policy plays a very important role in the overall process of
operating a secure system. This is discussed further in Chapter 2.
●
1.1 What Is Computer
Security?
1.3 History of UNIX
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 1] 1.2 What Is an Operating System?
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_02.htm (2 of 2) [2002-04-12 10:45:31]
Simpo PDF Merge and Split Unregistered Version -
Chapter 19
RPC, NIS, NIS+, and Kerberos

19.7 Other Network Authentication Systems
Besides Sun's Secure RPC and Kerberos, there are a variety of other systems for providing authentication
and encryption services over an unprotected network.
19.7.1 DCE
DCE is the Distributed Computing Environment developed by the Open Software Foundation. DCE is an
integrated computing environment that provides many services, including user authentication, remote
procedure call, distributed file sharing, and configuration management. DCE's authentication is very
similar to Kerberos, and its file sharing is very similar to the Andrew File System.

DCE's security is based on a Security Server. The Security Server maintains an access control list for
various operations and decides whether clients have the right to request operations.
DCE clients communicate with DCE servers using DCE Authenticated RPC. To use Authenticated RPC,
each DCE principal (user or service) must have a secret key that is known only to itself and the Security
Server.
A complete description of DCE can be found at />19.7.2 SESAME
SESAME is the Secure European System for Applications in a Multi-vendor Environment. It is a single
sign-on authentication system similar to Kerberos.
SESAME incorporates many features of Kerberos 5, but adds heterogeneity, access control features,
scalability of public key systems, improved manageability, and an audit system.
The primary difference between SESAME and Kerberos is that SESAME uses public key cryptography
(which is not covered by patent in Europe), allowing it to avoid some of the operational difficulties that
Kerberos experiences. SESAME is funded in part by the Commission of the European Union's RACE
program.
A complete description of SESAME can be found at the following Web address:
/>[Chapter 19] 19.7 Other Network Authentication Systems
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch19_07.htm (1 of 2) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
19.6 Kerberos 20. NFS
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 19] 19.7 Other Network Authentication Systems
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch19_07.htm (2 of 2) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
Chapter 16
TCP/IP Networks

16.4 Other Network Protocols
There are several other network protocols that may be involved in a network environment. We'll mention
them here, but we won't go into detail about them as they are not as common in UNIX environments as
IP networks are. If you are curious about these other network protocols, we suggest that you consult a

good book on networks and protocols; several are listed in Appendix D. Several of these protocols can
share the same physical network as an IP-based network, thus allowing more economical use of existing
facilities, but they also make traffic more available to eavesdroppers and saboteurs.
16.4.1 IPX
Novell Netware networks use a proprietary protocol known as Internet Packet eXchange protocol (IPX).
It does not scale well to large networks such as the Internet, although RFC1234 describes a system for
connecting IPX networks together using IP networks and a technique known as tunneling.
IPX is commonly found in PC-based networks. Some UNIX vendors support IPX-based services and
connections with their products.
16.4.2 SNA
The System Network Architecture (SNA) is an old protocol used by IBM to link mainframes together. It
is seldom found elsewhere. These days, IBM machines are in the process of transitioning to IP or IPX.
We expect that SNA will be extinct before too long.
16.4.3 DECnet
The DECnet protocol was developed at Digital Equipment Corporation to link together machines and is
based on Digital's proprietary operating systems. DECnet provides many of the same basic functions as
IP, including mail, virtual terminals, file sharing, and network time. During its heyday, many third parties
also built peripherals to support DECnet. Many large DECnet networks have been built, but the trend
within Digital has been to migrate to open standards such as IP.
[Chapter 16] 16.4 Other Network Protocols
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch16_04.htm (1 of 2) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
16.4.4 OSI
The Open System Interconnection (OSI) protocols, developed by the International Standards
Organization (ISO), are an incredibly complex and complete set of protocols for every kind of network
implementation. OSI was developed after TCP/IP, and supports many of the same kinds of services.
OSI is a classic example of what happens when a committee is asked to develop a complex specification
without the benefit of first developing working code. Although many organizations have stated that they
intend to switch from IP to OSI standards, this has not happened except for a few high-level services,
such as X.500 directory service and cryptographic certificates. On matters such as data transmission, the

OSI standards have in general proven to be too cumbersome and complex to fully implement efficiently.
We are clearly not big fans of OSI, but if you are interested in pursuing all the gory details, an excellent
book on the topic (which will give you a fairer treatment of OSI than we do here) is The Open Book: A
Practical Perspective on OSI by Marshall T. Rose (Prentice Hall, 1990).
16.4.5 XNS
The Xerox Network Systems (XNS) protocol family was developed by Xerox. These were supported by
a few other computer manufacturers, but few people use them now. Development inside Xerox has
largely switched over to IP as well.
16.3 IP Security 16.5 Summary
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 16] 16.4 Other Network Protocols
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch16_04.htm (2 of 2) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
Chapter 5
The UNIX Filesystem

5.4 Using Directory Permissions
Unlike many other operating systems, UNIX stores the contents of directories in ordinary files. These files are similar to
other files, but they are specially marked so that they can only be modified by the operating system.
As with other files, directories have a full complement of security attributes: owner, group, and permission bits. But
because directories are interpreted in a special way by the filesystem, the permission bits have special meanings (see
Table 5.11).
Table 5.11: Permissions for Directories
Contents Permission Meaning
r read You can use the opendir() and readdir() functions (or the ls command) to find out which files are
in the directory.
w write You can add, rename, or remove entries in that directory.
x execute You can stat the contents of a directory (e.g., you can determine the owners and the lengths of
the files in the directory). You also need execute access to a directory to make that directory
your current directory or to open files inside the directory (or in any of the directory's

subdirectories).
If you want to prevent other users from reading the contents of your files, you have two choices:
You can set the permission of each file to 0600, so only you have read/write access.1.
You can put the files in a directory and set the permission of that directory to 0700, which prevents other users
from accessing the files in the directory (or in any of the directory's subdirectories) unless there is a link to the
file from somewhere else.
2.
Note the following:
You must have execute access for a directory to make it your current directory (via cd or chdir) or to change to
any directory beneath (contained in) that directory.
●
If you do not have execute access to a directory, you cannot access the files within that directory, even if you own
them.
●
If you have execute access to a directory but do not have read access, you cannot list the names of files in the
directory (e.g., you cannot read the contents of the directory). However, if you have access to individual files,
you can run programs in the directory or open files in it. Some sites use this technique to create secret files - files
that users can access only if they know the files' names.
●
To unlink a file from a directory, you need only have write and execute access to that directory even if you have
no access rights to the file itself.
●
If you have read access to a directory but do not have execute access, you will be able to display a short listing of
the files in the directory (ls); however, you will not be able to find out anything about the files other than their
●
[Chapter 5] 5.4 Using Directory Permissions
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch05_04.htm (1 of 3) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
names and inode numbers (ls -i) because you can't stat the files. Remember that the directory itself only contains
name and inode information.

This processing can cause quite a bit of confusion, if you are not expecting it. For example:
% ls -ldF conv
dr 4 rachel 1024 Jul 6 09:42 conv/
% ls conv
3ps.prn bizcard.ps letterhead.eps retlab.eps
% ls -l conv
conv/3ps.prn not found
conv/retlab.eps not found
conv/letterhead.eps not found
conv/bizcard.ps not found
total 0
%
Removing Funny Files
One of the most commonly asked questions by new UNIX users is "How do I delete a file whose name begins with a
dash? If I type rm -foo, the rm command treats the filename as an option." There are two simple ways to delete such a
file. The first is to use a relative pathname:
% rm ./-foo %
A second way is to supply an empty option argument, although this does not work under every version of UNIX:
% rm - -foo %
If you have a file that has control characters in it, you can use rm command with the -i option and an asterisk, which
gives you the option of removing each file in the directory - even the ones that you can't type.
% rm -i *
rm: remove faq.html (y/n)? n
rm: remove foo (y/n)? y
%
A great way to discover files with control characters in them is to use the -q option to the UNIX ls command. You can,
for example, alias the ls command to be ls -q. Files that have control characters in their filenames will then appear with
question marks:
% alias ls ls -q
% ls f*

faq.html fmMacros fmdictionary fo?o
faxmenu.sea.hqx fmMacrosLog.backup fmfilesvisited
%
Table 5.12 contains some common directory permissions and their uses.
Table 5.12: Common Directory Permissions
Octal Number Directory Permission
0755 / Anybody can view the contents of the directory, but only the owner or superuser can make
changes.
1777 /tmp Any user can create a file in the directory, but a user cannot delete another user's files.
0700 $HOME A user can access the contents of his home directory, but nobody else can.
[Chapter 5] 5.4 Using Directory Permissions
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch05_04.htm (2 of 3) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
5.3 The umask 5.5 SUID
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 5] 5.4 Using Directory Permissions
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch05_04.htm (3 of 3) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
Chapter 1
Introduction

1.5 Role of This Book
If we can't change UNIX and the environment in which it runs, the next best thing is to learn about how
to protect the system as best we can. That's the goal of this book. If we can provide information to users
and administrators in a way that helps them understand the way things work and how to use the
safeguards, then we should be moving in the right direction. After all, these areas seem to be where many
of the problems originate.
Unfortunately, knowing how things work on the system is not enough. Because of the UNIX design, a
single flaw in a UNIX system program can compromise the security of the operating system as a whole.
This is why vigilance and attention are needed to keep a system running securely: after a hole is

discovered, it must be fixed. Furthermore, in this age of networked computing, that fix must be made
widely available, lest some users who have not updated their software fall victim to more up-to-date
attackers.
NOTE: Although this book includes numerous examples of past security holes in the UNIX
operating system, we have intentionally not provided the reader with an exhaustive list of
the means by which a machine can be penetrated. Not only would such information not
necessarily help to improve the security of your system, but it might place a number of
systems running older versions of UNIX at additional risk.
Even properly configured UNIX systems are still very susceptible to denial of service attacks, where one
user can make the system unusable for everyone else by "hogging" a resource or degrading system
performance. In most circumstances, however, administrators can track down the person who is causing
the interruption of service and deal with that person directly. We'll talk about denial of service attacks in
Chapter 25, Denial of Service Attacks and Solutions.
First of all, we start by discussing basic issues of policy and risk in Chapter 2. Before you start setting
permissions and changing passwords, make sure you understand what you are protecting and why. You
should also understand what you are protecting against. Although we can't tell you all of that, we can
outline some of the questions you need to answer before you design your overall security plan.
Throughout the rest of the book, we'll be explaining UNIX structures and mechanisms that can affect
your overall security. We concentrate on the fundamentals of the way the system behaves so you can
understand the basic principles and apply them in your own environment. We have specifically not
presented examples and suggestions of where changes in the source code can fix problems or add
security. Although we know of many such fixes, most UNIX sites do not have access to source code.
[Chapter 1] 1.5 Role of This Book
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_05.htm (1 of 2) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
Most system administrators do not have the necessary expertise to make the required changes.
Furthermore, source code changes, as do configurations. A fix that is appropriate in March 1996 may not
be desirable on a version of the operating system shipped the following September. Instead, we present
principles, with the hope that they will give you better long-term results than one-time custom
modifications.

We suggest that you keep in mind that even if you take everything to heart that we explain in the
following chapters, and even if you keep a vigilant watch over your systems, you may still not fully
protect your assets. You need to educate every one of your users about good security and convince them
to practice what they learn. Computer security is a lonely, frustrating occupation if it is practiced as a
case of "us" (information security personnel) versus "them" (the rest of the users). If you can practice
security as "all of us" (everyone in the organization) versus "them" (people who would breach our
security), the process will be much easier. You also need to help convince vendors to produce safer code.
If we all put our money behind our stated concerns, maybe the vendors will finally catch on.
1.4 Security and UNIX 2. Policies and Guidelines
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 1] 1.5 Role of This Book
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_05.htm (2 of 2) [2002-04-12 10:45:32]
Simpo PDF Merge and Split Unregistered Version -
Chapter 23
Writing Secure SUID and
Network Programs

23.7 UNIX Pseudo-Random Functions
The standard UNIX C library provides two random number generators: rand( ) and random( ). A third
random number generator, drand48( ), is available on some versions of UNIX. Although you won't want
to use any of these routines to produce cryptographic random numbers, we'll briefly explain each. Then,
if you need to use one of them for something else, you'll know something about its strengths and
shortcomings.
23.7.1 rand ( )
The original UNIX random number generator, rand( ), is not a very good random number generator. It
uses a 32-bit seed and maintains a 32-bit internal state. The output of the function is also 32 bits in
length, making it a simple matter to determine the function's internal state by examining the output. As a
result, rand( ) is not very random. Furthermore, the low-order bits of some implementations are not
random at all, but flip back and forth between 0 and 1 according to a regular pattern. The rand( ) random
number generator is seeded with the function srand( ). On some versions of UNIX, a third function is

provided, rand_r( ), for multi threaded applications. (The function rand( ) itself is not safe for multi-
threading, as it maintains internal state.)
Do not use rand( ), even for simple statistical purposes.
23.7.2 random ( )
The function random( ) is a more sophisticated random number generator which uses nonlinear feedback
and an internal table that is 124 bytes (992 bits) long. The function returns random values that are 32 bits
in length. All of the bits generated by random( ) are usable.
The random( ) function is adequate for simulations and games, but should not be used for security related
applications such as picking cryptographic keys or simulating one- time pads.
23.7.3 drand48 ( ), lrand48 ( ), and mrand48 ( )
The function drand48( ) is one of many functions which make up the System V random number
generator. According to the Solaris documen- tation, the algorithm uses "the well-known linear
congruential algorithm and 48-bit integer arithmetic." The function drand48( ) returns a double-precision
number that is greater or equal to 0.0 and less than 1.0, while the lrand48( ) and mrand48( ) functions
[Chapter 23] 23.7 UNIX Pseudo-Random Functions
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch23_07.htm (1 of 2) [2002-04-12 10:45:33]
Simpo PDF Merge and Split Unregistered Version -
return random numbers within a specified integer range. As with random( ), these functions provide
excellent random numbers for simulations and games, but should not be used for security-related
applications such as picking cryptographic keys or simulating one-time pads; linear congruential
algorithms are too easy to break.
23.7.4 Other random number generators
There are many other random number generators. Some of them are optimized for speed, while others are
optimized for randomness. You can find a list of other random number generators in Bruce Schneier's
excellent book, Applied Cryptography (John Wiley & Sons, Second Edition, 1995).
Some versions of the Linux operating system have carefully thought out random number generators in
their kernel, accessible through the /dev/random and /dev/urandom devices. We think that this design is
excellent-especially when the random number generators take into account additional system states, user
inputs, and "random" external events to provide numbers that are "more" random.
23.6 Tips on Generating

Random Numbers
23.8 Picking a Random Seed
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 23] 23.7 UNIX Pseudo-Random Functions
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch23_07.htm (2 of 2) [2002-04-12 10:45:33]
Simpo PDF Merge and Split Unregistered Version -
Chapter 11
Protecting Against Programmed
Threats

11.6 Protecting Your System
No matter what the threat is called, how it enters your system, or what the motives of the person(s) who wrote it
may be, the potential for damage is your main concern. Any of these problems can result in downtime and lost or
damaged resources. Understanding the nature of a threat is insufficient to prevent it from occurring.
At the same time, remember that you do not need many special precautions or special software to protect against
programmed threats. The same simple, effective measures you would take to protect your system against
unauthorized entry or malicious damage from insiders will also protect your system against these other threats.
11.6.1 File Protections
Files, directories, and devices that are writable (world-writable) by any user on the system can be dangerous
security holes. An attacker who gains access to your system can gain even more access by modifying these files,
directories, and devices. Maintaining a vigilant watch over your file protections protects against intrusion and also
protects your system's legitimate users from each other's mistakes and antics. (Chapter 5 introduces file
permissions and describes how you can change them.)
11.6.1.1 World-writable user files and directories
Many inexperienced users (and even careless experienced users) often make themselves vulnerable to attack by
improperly setting the permissions on files in their home directories.
The .login file is a particularly vulnerable file. For example, if a user has a .login file that is world-writable, an
attacker can modify the file to do his bidding. Suppose a malicious attacker inserts this line at the end of a user's
.login file:
/bin/rm -rf ~

Whenever a user logs in, the C shell executes all of the commands in the .login file. A user whose .login file
contains this nasty line will find all of his files deleted when he logs in!
Suppose the attacker appends these lines to the user's .login file:
/bin/cp /bin/sh /usr/tmp/.$USER
/bin/chmod 4755 /usr/tmp/.$USER
When the user logs in, the system creates a SUID shell in the /usr/tmp directory that will allow the attacker to
assume the identity of the user at some point in the future.
In addition to .login, many other files pose security risks when they are world writable. For example, if an
attacker modifies a world-writable .rhosts file, she can take over the user's account via the network.
[Chapter 11] 11.6 Protecting Your System
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch11_06.htm (1 of 3) [2002-04-12 10:45:33]
Simpo PDF Merge and Split Unregistered Version -
In general, the home directories and the files in the home directories should have the permissions set so that they
are only writable by the owner. Many files in the home directory, such as .rhosts, should only be readable by the
owner as well. This practice will hinder an intruder in searching for other avenues of attack.
11.6.1.2 Writable system files and directories
There is also a risk when system files and directories are world writable. An attacker can replace system programs
(such as /bin/ls) with new programs that do the attacker's bidding. This practice is discussed in Chapter 8,
Defending Your Accounts.
NOTE: If you have a server that exports filesystems containing system programs (such as the /bin
and /usr/bin directories), you may wish to export those filesystems read-only. Exporting a filesystem
read-only renders the client unable to modify the files in that directory. To export a filesystem
read-only, you must specify the read-only option in the /etc/exports file on the server. For example,
to export the /bin and /usr/bin filesystems read-only, specify the following in your /etc/dfs/dfstab file:
share -F nfs -o ro=client /bin
share -F nfs -o ro=client /usr/bin
On a Berkeley-based system, place these lines in your /etc/exports file:
/bin -ro, access=client
/usr/bin -ro, access=client
Group-writable files

Sometimes, making a file group writable is almost as risky as making it world writable. If everybody on your
system is a member of the group user, then making a file group-writable by the group user is the same as making
the file world-writable.
You can use the find command to search for files that are group writable by a particular group, and to print a list
of these files. For example, to search for all files that are writable by the group user, you might specify a
command in the following form:
# find / -perm -020 -group user \!
\( -type l -o -type p -o -type s \) -ls
If you have NFS, be sure to use the longer version of the command:
# find / \( -local -o -prune \) -perm -020 -group user \!
\( -type l -o -type p -o -type s \) -ls
Often, files are made group writable so several people can work on the same project, and this may be appropriate
in your system. However, some files, such as .cshrc and .profile, should never be made group writable. In many
cases, this rule can be generalized to the following:
Any file beginning with a period should not be world writable or group writable.
A more security-conscious site can further generalize this rule:
Files that begin with a period should not be readable or writable by anyone other than the file's owner
(that is, they should be mode 600).
Use the following form of the find command to search for all files beginning with a period in the /u filesystem that
are either group writable or world writable:
# find /u -perm -2 -o -perm -20 -name .\* -ls
[Chapter 11] 11.6 Protecting Your System
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch11_06.htm (2 of 3) [2002-04-12 10:45:33]
Simpo PDF Merge and Split Unregistered Version -
NOTE: As noted earlier, if you're using NFS, be sure to add the -local or -xdev option to each of the
find commands above and run them on each of your servers, or use the fstype/prune options.
11.6.1.3 World-readable backup devices
Your tape drive should not be world readable. Otherwise, it allows any user to read the contents of any tape that
happens to be in the tape drive. This scenario can be a significant problem for sites which do backups overnight,
and then leave the tape in the drive until morning. During the hours that the tape is awaiting removal, any user can

read the contents of any file on the tape.
11.6.2 Shared Libraries
Programs that depend on shared libraries are vulnerable to a variety of attacks that involve switching the shared
library that the program is running. If your system has dynamic libraries, they need to be protected to the same
level as the most sensitive program on your system, because modifying those shared libraries can alter the
operation of every program.
On some systems, additional shared libraries may be specified through the use of environment variables. While
this is a useful feature on some occasions, the system's shared libraries should not be superseded for the following
kinds of programs:
Programs executed by SUID programs
●
User shells●
Network servers●
Security services●
Auditing and logging processes●
On some versions of UNIX, you can disable shared libraries by statically linking the executable program. On
others, you can limit whether alternate shared libraries are referenced by setting additional mode bits inside the
executable image. We advise you to take these precautions when available.
11.5 Protecting Yourself 12. Physical Security
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 11] 11.6 Protecting Your System
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch11_06.htm (3 of 3) [2002-04-12 10:45:33]
Simpo PDF Merge and Split Unregistered Version -