This is the 5th Edition of my occassional paper on the architecture
of UNIX network security and related methods.  Due to some persistent
encouragement and continual interest I am now drafting this latest
Edition of the paper.  What I have included below is only a DRAFT at
this point.  But, due to the confusion that I seem to have caused with
the "source" information I gave Rich Morin at "UNIX Review," I thought
it would be a good idea to post this DRAFT now in order to make this
available to all who is interested.  Note that my e-mail address has
changed since I last widely distributed this paper in February 1993.

E-mail:		breinhar@tomahawk.welch.jhu.edu
Anon-FTP:	tomahawk.welch.jhu.edu:/pub/misc/secpaper.txt

Previous versions of this were distributed to security related
newsgroups and the firewalls mailing list several times from
August 1992 - February 1993.

I respectfully submit this final draft to all of you for
any constructive comments and suggestions you may have.
My thanks in advance (and in areers) to all of you who have
offered your suggestions to improve this paper, since the
original version in August '92.

Notice -- A Disclaimer and Copyright Notice are included at
the end of this article.  The contents of this entire article
are approximately 30 pages long.

---Rob Reinhardt (breinhar@tomahawk.welch.jhu.edu)

=======================cut here================================

	An Architectural Overview of UNIX Network Security
	Draft - July 1994 - 5th Edition



	Robert B. Reinhardt
	Manager, Information Technology
	Wilhelmsen Lines (USA), Inc.
	World Trade Center, Suite 1400
	401 East Pratt Street
	Baltimore, Maryland 21202

	breinhar@tomahawk.welch.jhu.edu



1.  Introduction

	The goal of this paper is to present my concept of a UNIX 
network security architecture based on the Internet connectivity 
model and Firewall approach to implementing security, the "UNIX-
NSA Firewall Model."  This model defines seven layers of a 
firewall, which depict the layers of vulnerability.  This paper 
also provides some subjective comments on some of the most widely 
known tools and methods available to protect UNIX networks today, 
plus a brief discussion of the threat and the risk.

	The list of tools and methods that I present in this paper 
were chosen loosely on the basis of the following:  (a) My 
attempt to find at least one, maybe several examples of a tool or 
method designed to address a part of the architectural model 
(some duplication or overlap is accepted); (b) my preference to 
discuss tools that are well-known and/or part of the public 
domain (this is not a strict rule, although I did not purposely 
seek out commercial products); and (c) I hoped to find tools that 
had a recent paper written by the tools' author, for the reader 
to use as detailed reference beyond the scope of this document.

	Nothing in this paper should be construed as a product 
endorsement.  I apologize in advance to the authors of these 
tools and methods; since I am only presenting a brief overview, I 
cannot do justice to a comprehensive description of them.  I also 
apologize to any authors whom I may have left out of this 
discussion; it was not intentional.  The reader should check the 
availability information that accompanies each tool and obtain 
additional information prior to proceeding with any plans or 
implementation.  Of course, there is no warranty expressed or 
implied in this paper.

2.  Risk, Threat, and Vulnerability

	This section presents a general overview of the risk and the 
threat to the security of your network.  These are general 
statements that apply to almost every network.  A complete 
analysis of your network's risk, threat, and vulnerability should 
be done in order to assess in detail the requirements of your own 
network.

2.1	Risk

	Risk is the probability that an intruder may be successful 
in attempting to access the LAN via WAN connectivity.  There are 
many possible affects and degrees of damage of such an 
occurrence.  In general, the possibility exists that if an 
intruder gains access, they could obtain permission to do damage 
in these areas:

		READ ACCESS.  Read or copy information from your 
		network.

		WRITE ACCESS.  Write to or destroy data on your 
		network (including planting trojan horses, 
		viruses, and back doors).

		DENIAL OF SERVICE.  Deny normal use of the 
		network resources or cause failure and system 
		shutdown by consuming all of the bandwidth, 
		CPU, or memory.

2.2  Threat

	Threat exists in many forms.  Anyone with the motivation to 
gain unauthorized access to the network or anyone with authorized 
access to the network is a potential threat.  Vulnerability to 
the threat depends on several factors:

		MOTIVATION.  How would access to or destruction of 
		the network benefit the individual or group trying 
		to break in?

		TRUST.  Can authorized users be trusted?  Do users 
		understand what is acceptable and unacceptable use 
		of the network?  Do users understand the 
		consequences of unacceptable use?

2.3  Vulnerability

	Vulnerability is a subjective statement of how well the 
network is protected from unauthorized access or unauthorized 
use.  Vulnerability can result in internal or external damage:

		Internal.  Intentional theft of information or 	
		damage to the network.  Accidental damage to the 	
		network.  Unintended authorization for access by 	
		outside users.

		External.  Theft of information or damage to the 
		network.

3.  UNIX Network Security Architecture

	For each of the layers in the UNIX Network Security 
Architecture (UNIX-NSA) model below, there is a paragraph that 
follows giving a brief description of that layer and some of the 
most widely used tools and methods for implementing relevant 
security controls.  I am using the ISO/OSI style of model since 
most people in the UNIX community are familiar with it.  This 
architecture is specifically based on UNIX Internet connectivity, 
but it is intended to be general enough to apply to overall 
security of any network methodology.  One could argue that this 
model applies to network connectivity in general, with or without 
the specific focus of UNIX network security.


Layer	Name			Functional Description

LAYER 7	POLICY			POLICY DEFINITION AND DIRECTIVES
LAYER 6	PERSONNEL		PEOPLE WHO USE EQUIPMENT AND DATA
LAYER 5	LAN			COMPUTER EQUIPMENT AND DATA ASSETS
LAYER 4	INTERNAL-DEMARK		CONCENTRATOR - INTERNAL CONNECT
LAYER 3	GATEWAY			FUNCTIONS FOR OSI 7, 6, 5, 4
LAYER 2	PACKET-FILTER		FUNCTIONS FOR OSI 3, 2, 1
LAYER 1	EXTERNAL-DEMARK		PUBLIC ACCESS - EXTERNAL CONNECT


	The specific aim of this model is to illustrate the 
relationship between the various high and low level functions 
that collectively comprise a complete security program for wide 
area network connectivity.  They are layered in this way to 
depict (a) the FIREWALL method of implementing access controls, 
and (b) the overall transitive effect of the various layers upon 
the adjacent layers, lower layers, and the collective model.  The 
following is a general description of the layers and the nature 
of the relationship between them.  After a brief description of 
each layer, the next section of this paper will discuss examples 
of common methods and tools used to implement some of the 
available options at each level, or at least describe several 
sources that can help you get started.  Note that there is some 
overlap between the definitions of the various levels, this is 
most evident between the different layers of the FIREWALL itself 
(layers 2 and 3).

LAYER 7 - POLICY

	The highest layer (7) is the umbrella over the entire 
security program.  It is this function that defines the policies 
of the organization, including the high level definition of 
acceptable risk down to the low level directive of what and how 
to implement equipment and procedures at the lower layers.  
Without a comprehensive, effective, and implemented policy, your 
security program cannot be complete.

LAYER 6 - PERSONNEL

	The next LAYER (6) defines the second most comprehensive 
veil within the umbrella policy defined by LAYER (7).  The people 
that install, operate, maintain, use, and can or do have access 
to the network (one way or another) are all part of this layer.  
This can include people that are not in your organization, that 
you may not have any administrative control over.  Your policy 
regarding personnel should reflect what your expectations are 
from your overall security program.  Once everything is defined, 
it is imperative that personnel are trained and otherwise 
informed of your policy, including what is and is not considered 
acceptable use of the system.

LAYER 5 - LOCAL AREA NETWORK

	The local-area network LAYER (5) defines the equipment and 
data assets that the security program is there to protect.  It 
also includes some of the monitor and control procedures used to 
implement part of the security policy.  This is the layer at 
which the security program starts to become automated 
electronically, among the LAN assets themselves.

LAYER 4 - INTERNAL DEMARKATION POINT

	The internal demarcation LAYER (4) defines the equipment and 
the point at which the LAN is physically connected to the 
FIREWALL that provides the buffer zone between the local area 
network (LAN) and the wide area network (WAN) connectivity.  This 
can take many forms such as a network concentrator that homes 
both a network interface for the FIREWALL and a network interface 
for the LAN segment.  In this case, the concentrator is the 
internal demarcation point.  The minimum requirement for this 
layer is a single point of disconnect if the need should arise to 
spontaneously separate the LAN from the external connectivity 
(WAN) for any reason.

LAYER 3 - GATEWAY

	The embedded UNIX gateway LAYER (3) defines the entire 
platform that homes the network interface coming from the 
internal demarcation point at LAYER 4 and the network interface 
going to the packet filtering router (or other connection 
equipment) at LAYER 2.  The reason to have an embedded UNIX 
gateway is to provide FIREWALL SERVICES, as transparent to the 
user or application as possible, for all WAN services.  What this 
really is for your environment must be defined in your own policy 
(defined in LAYER 1) and illustrates how the upper layers 
overshadow or are transitive to the layers below.  It is intended 
that the UNIX gateway (or server) at this layer will be dedicated 
to this role and not otherwise used to provide general network 
resources (other than the FIREWALL SERVICES such as PROXY FTP, 
etc.).  It is also used to implement monitor and control 
functions that provide FIREWALL support for the functions that 
are defined by the four upper ISO/OSI layers (1-Application, 2-
Presentation, 3-Session, 4-Transport).  Depending on how this and 
the device in LAYER (2) is implemented, some of this might be 
only pass-through to the next level.  The configuration of LAYER 
(3) and LAYER (2) could collectively provide sufficient coverage 
of all 7 of the functions defined by the OSI model.  This does 
not mean that the FIREWALL has to be capable of supporting 
everything possible that fits the OSI model.  What this does mean 
is that the FIREWALL should be capable of supporting all of the 
functions of the OSI model that you have implemented within your 
LAN/WAN connectivity.

LAYER 2 - FILTER

	The packet filter LAYER (2) defines the platform that homes 
the network interface coming from the gateway in LAYER (3) and 
the network interface or other device such as synchronous or 
asynchronous serial communication between the FIREWALL and the 
WAN connectivity at LAYER (1).  This layer should provide both 
the physical connectivity to LAYER (1) and the capability to 
filter inbound and outbound network packets (datagrams) based 
upon some sort of criteria (what this criteria needs to be is 
defined in your policy).  This is typically done today by a 
commercially available intelligent router that has these 
capabilities, but there are other ways to implement it.  There is 
OSI link-level activity going on at several layers in this model, 
not exclusively this layer.  But, the point is that functionally, 
your WAN access security policy is explicitly implemented at this 
level to protect the overall link-level access to the LAN by 
utilizing packet filtering access control lists (ACLs) for each 
interface.

	For implementation of a packet filtering router the 
following can be used as a minimum guideline to get started.  
Each physical interface on the router should have an ACL 
associated with it and configured in such a way that all packets 
going to or coming from the router are implicitly denied 
(rejected) unless explicitly permitted in the ACL.  This will 
force the implicit denial of access unless explicitly permitted; 
which allows for the most efficient definition and control of the 
security policy defined in the router.  The router access list is 
a sequential collection of permit and deny conditions that apply 
to Internet addresses, protocols, and ports (services).  The 
router individually tests each packet as it is received and 
before it is routed (forwarded) against the conditions defined in 
the ACL.  The first match determines whether the router accepts 
or rejects the packet, therefore the order of entries in the ACL 
can be relevant.  The implicit rejection means that any packets 
that do not specifically have authorization in the ACL are 
filtered out, thereby enforcing the security policy.

	Access permissions should be driven by specific operational 
(functional) requirements; i.e. the need to exchange information.  
As these requirements are tempered by security considerations, at 
a minimum, you should filter out packets associated with the 
following services (particularly if you do not take measures at 
another layer in the model to protect and monitor these 
services):  TFTP (UDP/69), LINK (TCP/87), SUNRPC (UDP/111), NFS 
(TCP/2049), EXEC (TCP/512), LOGIN (TCP/513), SHELL (TCP/514), LPD 
(TCP/515), UUCPD (TCP/540), OPEN WINDOWS (TCP/2000), and XWINDOWS 
(TCP/6000).
 
LAYER 1 - EXTERNAL DEMARKATION POINT

	The external demarcation point LAYER (1) defines the point 
at which any device; i.e. telephone circuit, or other media that 
you do not have direct control over within your organization, is 
connected to your network.  This can be further characterized as 
public or non-private connectivity.  Your policy should address 
this for many reasons, such as the nature and quality of the line 
or service itself, and vulnerability to unauthorized access.  At 
this point (or as part of LAYER 2 or LAYER 3) another device may 
be deployed to perform point to point data link encryption.  This 
is not likely to improve the quality of the line (more likely to 
reduce the quality to some degree), but certainly can reduce the 
vulnerability to unauthorized access.  You also need to be 
concerned about the dissemination of information at this level 
that are often considered miscellaneous, such as phone numbers 
and telephone circuit IDs.
 
	Illustration of the UNIX NSA Model

----------------------------------------------------------------
|			POLICY				       |
----------------------------------------------------------------
			  |
			  |
---------------------------------------------------
|			PERSONNEL	 	  |
---------------------------------------------------
		          |
			  |
---------------------------------
|			LAN	|
---------------------------------
		 Enet |
	         Enet |
	   -----------------
	   |  INTERNAL-D   |
	   -----------------
	Enet    |
	Enet    |
-----------------
| GATEWAY-SERVER|
-----------------
	Enet	|
	Enet	|
-----------------
| PACKET-FILTER |	cisco IGS router with access control lists
-----------------
	X.25    |   FRAME RELAY
	ASYNC   |   ATM
	   -----------------
	   |   EXTERNAL-D  |	telecommunications circuit to WAN
	   -----------------
 			 |
			 |
	   + Public Access +
 
4.	DESCRIPTION OF SOME TOOLS OR METHODS TO APPLY AT EACH LAYER

	This section will describe some of the well known tools and 
methods that can be applied to security in the UNIX Network 
Security Architecture (NSA) Model.

4.1  ROUTER (LAYER 2)

	LAYER (2) of the UNIX-NSA model depicts the point at which 
physical connectivity and the data stream become one.  Without 
going into great detail about all of what a router is and does; 
the point is that at this layer, the electrical connectivity, 
which contains encapsulated data in some form (i.e. frame or 
packet), becomes information.  The router will decode the 
electrical signals from the physical connectivity and turn it 
into packets of encapsulated data for any one of various 
networking protocols.  Within this packet of information is 
contained the source address, destination address, protocol ID, 
the datagram itself, etc.

	Many routers available today include the capability to 
create access control lists (ACL) for either one or both of the 
outgoing and the incoming data interfaces [1][5].  This normally 
includes the capability to filter out or allow in packets based 
upon source address, destination address, protocol (such as TCP, 
UDP, ICMP, etc.) and specific port numbers (TCP and UDP).  This 
provides the flexibility to design a network access control 
policy, enforced at the router, before access to the internal 
network resources is required or granted.  In this way, routers 
alone are often used to provide the firewall functionality.

	While the router ACL capability offers a big advantage, it 
should not be the only protection because, basically the router 
only provides protection at the first three levels of the OSI 
connectivity model (1 - Physical, 2 - Data Link, and 3 - Network 
layers).  The rest of the layers of this firewall model address 
ways to apply functional security to the other four OSI layers (4 
- Transport, 5 - Session, 6 - Presentation, and 7 - Application).

	Availability:  I only have personal experience with CISCO 
routers, however I am aware that Wellfleet and Proteon routers 
also have this feature.

4.2  GATEWAY (LAYER 3)

	LAYER (3) defines the point in the UNIX-NSA model to apply 
security procedures to the services identified in the upper four 
layers of the OSI model (i.e. for packets going to and coming 
from the router, for use by the internal network operating system 
such as TCP/IP under UNIX).  The UNIX server is also doing work 
at the bottom three OSI layers also, in order to communicate 
with:  (a) the router on one side of the server, and (b) the 
local-area network on the other side of the server; but the point 
is that the packet filtering protection is not implemented on the 
gateway, but rather on the router, where it is more efficient to 
do so.

	As the path of connectivity (data) travels up the UNIX-NSA 
model from LAYER (1) to LAYER (3), the router is already 
implementing the security policy that you define for the bottom 
three OSI layers, at which point it is up to the dual-homed [10] 
UNIX server (acting as a gateway) to implement the security 
policy you defined relating to functions of the network for the 
upper four OSI layers.  This can mean a lot of things.  Depending 
on what your security policy requires, what you implement at this 
point varies.  The following tools and methods are example of 
some of the tools and methods (functionality) available today 
that can be implemented on the gateway:

4.2.1  TCP Wrapper

	The "TCP WRAPPER" tool [2] provides monitoring and control 
of network services.  How this works is by configuring inetd on 
the dual-homed gateway to run the TCP WRAPPER software whenever 
certain services (ports) are connected to, instead of just 
running the software directly from inetd, which is the default.  
Depending on how TCP WRAPPER is configured, it will then LOG 
information about the connection and then start the expected 
SERVER program that the connection was intended for.  Since the 
source code is provided with the tool, it can be modified to do 
more depending on what your policy requires. For example, you may 
want TCP WRAPPER to connect the user to a proxy service instead 
of the actual program, then have your proxy software handle the 
transaction in whatever way your security requirements demand.

	Availability:  This is available from several sources, but 
to ensure that you get the most recent copy that CERT has 
verified, you should use anonymous FTP to retrieve it from 
cert.org in ~/pub/tools/tcp_wrappers/tcp_wrappers.*.

4.2.2  SOCKS library and sockd

	The "sockd" and "SOCKS Library" [3] provide another way to 
implement a "TCP Wrapper."  It is not intended to make the system 
it runs on secure, but rather to centralize ("firewall") all 
external internet services.  The sockd process is started by 
inetd whenever a connection is requested for certain services, 
and then only allows connections from approved hosts (listed in a 
configuration file).  The sockd will also LOG information about 
the connection.  You can use the Socks Library to modify the 
client software to directly utilize the sockd for outgoing 
connections also, but this is described as very tedious and 
requires you to have the source to those client programs.

	Availability:  The socks package, which in addition to 
including both the daemon and the library, has a pre-modified FTP 
client and finger client; it is available via anonymous FTP from 
s1.gov in ~/pub as socks.tar.Z.  Contact the authors for more  
information.  David Koblas (koblas@netcom.com) or Michelle R. 
Koblas (mkoblas@nas.nasa.gov).

4.2.3  Kernel_Wrap for SunOS RPC via Shared Libraries

	Essentially this is a "wrapper" for SunOS daemons that use 
RPC [4], such as portmap, ypserv, ypbind, ypupdated, mountd, 
pwdauthd, etc.  To utilize this, you must have SunOS 4.1 or 
higher and must have the capability to rebuild your shared 
libraries (but, you don't need the source to your entire system).  
how this works is by modifying the function calls that the kernel 
uses to establish RPC connections, such as accept(), recvfrom() 
and recvmsg().  Since these calls are maintained in the shared 
libraries, they can be modified without rewriting the kernel.

	Availability:  The secured C library package to implement 
this is available via anonymous FTP from eecs.nwu.edu in 
~/pub/securelib.

4.2.4  Swatch

	Simple WATCHER [6] provides two valuable features, it is a 
program used to parse through the myriad of LOG data generated by 
the various security programs, in particular "syslog."  But, it 
is more than that.  It is fully configurable with triggers 
(actions), so that while it is continuously monitoring the LOG in 
"real time," it can take actions based upon certain high-priority 
events that it has been configured to watch for.  To get full use 
of this, network service daemons such as ftpd and telnetd will 
need to be modified so that enhanced logging is added to syslog, 
to feed SWATCH.

	Availability:  The SWATCH source and documentation is 
available via anonymous FTP from sierra.stanford.edu in 
~/pub/sources.

4.2.5  Controlled Access Point (CAP)

	This is more of a method or protocol definition than a 
specific product.  CAP [7] provides a network mechanism intended 
to reduce the risk of:  password guessing, probing for well-known 
accounts with default passwords, trusted host rlogin, and 
password capture by network snooping.  It is a design for a 
variation or enhancement to the general firewall approach to 
connecting two or more networks.  In the paper describing this 
there is an example of two local nets, one a secure segment with 
an authentication service, and the other an unsecure segment. 
Both communicate with each other via a CAP, while there is a 
router for communication to public networks connected on the 
unsecure side of the CAP.  The CAP is essentially a router with 
additional functionality to detect incoming connection requests, 
intercept the user authentication process, and invoke the 
authentication server.
 
	Availability:  Unknown.  Contact the authors for more 
information.  J. David Thompson (thompsond@orvb.saic.com) and 
Kate Arndt (karndt@mitre.org).

4.2.6  Mail Gateway

	This is more of a procedure than a software package 
(although there are packages designed just to do this).  I 
included this to maintain continuity with what is being 
illustrated in this paper.  This should be applied to all network 
services that require external connectivity (meaning any 
communication over non-private or non-secure channels).  In the 
simplest implementation of this, configure your router to filter 
packets so that all mail traffic (SMTP protocol for example) is 
only allowed to and from one host, the "Mail Gateway."  Likewise, 
DNS and MTA software will need to be configured for this as well.

4.2.7  TTY Wrapper

	This is one of my pet ideas.  I have not seen something like 
this around, and I'll probably never have time to develop it.  
But, essentially this would be like "TCP Wrapper," only it is 
designed specifically for serial communications.  After that, we 
will need a "Pseudo-TTY Wrapper," (something more than just 
filtering out the telnet port) but that is for another day.

4.2.8  HSC-Gatekeeper

	The HSC-Gatekeeper from Herve' Schauer Consultants [8], is a 
complete solution to both LAYER (1) and LAYER (2) of the UNIX-NSA 
model.  It consists of a thorough firewall methodology and 
authentication server, providing pass-through FTP and TELNET 
services.  The author (Herve Schauer) noted that HSC-Gatekeeper 
is alone to be able to offer fully transparent authentication for 
these services.  I do not have personal experience with HSC's 
product, therefore I cannot make a conclusive statement about it 
other than to comment that the description of it in HSC's paper 
"An Internet Gatekeeper" (available in the USENIX Proceedings) 
depicts it (IMHO) as a very comprehensive solution.

	Availability:  For more information, contact Herve Schauer 
via e-mail at Herve.Schauer@hsc-sec.fr.

4.2.9  AT&T Inet

	Since I discussed HSC's firewall solution, I thought it only 
fair to mention AT&T's INET Gateway.  For a complete description 
of AT&T's internal solution, you should read Bill Cheswick's 
paper [9] "The Design of a Secure Internet Gateway."  For 
additional information, contact the author via e-mail at 
ches@research.att.com.  I do not believe that AT&T is in the 
business of selling this solution to anyone, but the paper 
describes in good detail how it was done.  It should provide the  
puritan firewaller additional depth to the problems and possible 
solutions to an Internet firewall approach.

4.3  LOCAL AREA NETWORK (PERSONAL WORKSTATIONS)

	LAYER (5) of the UNIX-NSA model depicts the point at which 
networks are most vulnerable and have the most risk.  The 
previous layers discussed ways to protect access to this layer of 
the network.  This layer includes all of the local area network, 
workstations, file servers, data bases, and other network 
resources.  This is also the point at which the "user community" 
sit at their desks and use the network.

	There are several things to be concerned about at this 
point, access to this layer in the first place notwithstanding.  
Just because you think you have protected and may be monitoring 
access to this layer within the previous layers, does not mean 
that use of computers and other resources within your local area 
network should become a free for all.  Again, this depends on 
what you identify in your own particular security policy but, at 
this layer you should do some routine checking for possible 
breaches of your firewall that would leave its mark at this layer 
and pay close attention to effective password handling, etc.  
This is also the layer of this model at which one must address 
training of the users, after all this is where they can 
potentially make their mistakes (and harm your network).

	The following is a list of minimum routine monitoring 
(checks) that should be made on all workstations to note 
exceptions to the norm:

	-	Review logins and ensure logouts

	-	Review system activity and unusual processes

	-	Identify excessive switch user (su) attempts

	-	Validate SETUID and SETGID files

	-	Validate file permissions

	-	Validate hidden files

	-	Validate integrity of the password file

	-	Validate files with special restrictions

4.3.1  Computer Oracle and Password System (COPS), Tripwire, and 
Crack

	This section describes several tools that can be used 
individually or together to check the status of security on UNIX 
systems; these include: COPS, Tripwire, and Crack.

	COPS can form the core of your security integrity checking. 
Use Crack as a substitute or to augment the password checker in 
COPS, and use Tripwire as a substitute or to augment the CRC 
check for files that have been changed in COPS.  COPS is an 
integrated package of a dozen or more tools that provides a 
comprehensive security integrity program.  Crack and Tripwire are 
more recently developed stand-alone tools designed specifically 
for their respective purposes and therefore may be more suitable 
for those checks within the overall security program.

	Each site should review the documentation and capabilities 
of each of the security tools.  Use empirical testing to 
determine the best configuration for the site.

Computer Oracle and Password System (COPS)

	COPS is a UNIX security integrity status checker.  It is a 
collection of a dozen programs that provide the following 
capabilities; it checks for:

	-	File, directory, and device permissions/modes.

	-	Poor passwords. (Recommend you consider substituting or 
		augmenting this program with CRACK).

	-	Content, format, and security of password and group 
		files.

	-	The programs and files run in /etc/rc* and cron(tab) 
		files.

	-	Existence of root-SETUID 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.  (Recommend you consider 
		substituting or augmenting this program with Tripwire).

	-	Writability of users home directories and startup files 
		(.profile, .cshrc, etc.) 

	-	Anonymous ftp setup.

	-	Unrestricted tftp, decode alias in sendmail, SETUID 
		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.

	-	Dates of CERT advisories vs. key files.  This checks 
		the dates that various bugs and security holes were reported 
		by CERT against the actual date on the file in question.

	-	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 
		at "kuang.man".)

	The current version of COPS (1.04) makes a limited attempt 
to detect bugs that are posted in CERT advisories.  Also, it has 
an option to generate a limited script that can correct various 
security problems that are discovered.  Dan also offers a quick 
hint that should easily get you started using COPS.  After you 
have unarchived the COPS package, perform the following steps:  
'./reconfig', 'make', and './cops -v -s . -b bit_bucket'. -- 
There is sufficient README documentation included if you need 
more help.

	Availability:  COPS is public domain (free) software 
developed by Dan Farmer. It can be retrieved via the Internet 
using anonymous FTP to connect to cert.org (CERT Archive Site).  
The file is located in the directory /pub /tools /cops /1.04 
/cops_104.tar.Z.

Crack

	Crack helps the System Administrator identify weak passwords 
by checking for various well known weaknesses and attempting to 
decrypt them.  If Crack can figure out your password, you must 
choose a better password.  It is very likely that a determined 
intruder will be able to get the password using similar 
techniques, or the Crack program itself, since it is publicly 
available).

	Availability:  Crack is public domain (free) software 
developed by Alec D. E. Muffett.  It can be retrieved via the 
Internet using Anonymous-FTP to connect to cert.org (CERT Archive 
Site).  The file is located in the directory 
/pub/tools/crack/crack_4.1-tar.

Tripwire

	Tripwire is a file integrity checker.  It is used to 
generate a baseline database to store information about a 
designated set of files.  Then, to verify file integrity, it 
compares the designated set of system files against the 
information stored in the baselines database.  Differences are 
flagged and logged, and the System Administrator can choose to be 
notified about these discrepancies through e-mail.  Tripwire 
should be run against system files on a regular basis to spot any 
changes in critical system files.  If changes are noted, 
appropriate damage control measures can be taken immediately.  If 
Tripwire detects no changes in the specified files, the System 
Administrator can be confident that a given set of files remain 
free of unauthorized modifications.

	Availability:  Tripwire is public domain (free) software 
developed at Purdue University by Gene Kim and Eugene Spafford.  
It can be retrieved via the Internet using anonymous FTP to 
connect to cert.org (CERT Archive Site).  The file is located in 
the directory /pub /tools /tripwire /tripwire1.1 /tripwire-
1.1.tar.Z.

4.3.2  Shadow

	The shadow password suite of programs [12] replaces the 
normal password control mechanisms on a system to remove the 
encrypted password from the publicly readable file /etc/passwd 
and hides the passwords in a place that only this program has 
permission to read.  It consists of optional, configurable 
components, provides password aging to force users to change 
their passwords regularly, adds enhanced syslog logging, and can 
allow users to set passwords up to a length of sixteen 
characters.

	Many vendors of UNIX are now bundling a shadow password 
suite with the OS, usually under the nomenclature of a "C2" or 
"trusted system."  You may still find that this package has more 
features than your canned package.  Compare them.

	Availability:  Shadow is available from USENET archives 
which store the comp.sources.misc newsgroup.  Distribution is 
permitted for all non-commercial purposes.  For more information 
contact the author, John F. Haugh III (jfh@rpp386.cactus.org).

4.3.3  Passwd+

	Passwd+ is a proactive password checker [13] that replaces 
/bin/passwd on your system.  It is rule-based and easily 
configurable.  It prevents users from selecting a weak password  
so that programs like "Crack" can't guess it, and it provides 
enhanced syslog logging.

	Many vendors of UNIX are now bundling a proactive password 
checker with the OS, usually under the nomenclature of a "C2" or 
"trusted system."  You may still find that this package has more 
features than your canned package.  Compare them.

	Availability:  Passwd+ (developed by Matt Bishop) is 
available via anonymous FTP from dartmouth.edu in 
~/pub/passwd+tar.Z.

4.3.4  Audit

	Audit is a policy-driven security checker for a 
heterogeneous environment [14].  It is fully configurable so that 
you can set up Audit to exactly match your site's security 
policy.  This program functionally does what COPS is intended to 
do, but does not hard-code your policy decisions for you the way 
that COPS does.

	Many vendors of UNIX are now bundling an auditing subsystem 
with the OS, usually under the nomenclature of a "C2" or "trusted 
system."  You may still find that this package has more features 
than your canned package.  Compare them.  One particular subject 
to note is that most (IMHO) vendors early versions of auditing 
subsystems only collect and regurgitate a lot of raw data, with 
no guidance and assistance for using that information.  They 
leave that up to you.  The Audit and/or Swatch tools are probably 
better.

	Availability:  The final version of Audit will eventually be 
posted to USENET.  However, the beta release will only be made 
available on a limited basis, to larger, heterogeneous sites. If 
your interested in participating in the beta test, send e-mail to 
the author, Bjorn Satdeva (bjorn@sysadmin.com).

4.3.5  Miro

	Miro [14] is a suite of tools for specifying and checking 
security constraints (like COPS and Audit), including a couple 
programming languages.  It is general because it is not tied to 
any particular OS, and it is flexible because security 
administrators express site policies via a formal specification 
language.  It is easy to extend or modify a policy by simply 
augmenting or changing the specification of the current policy.

	Availability:  Miro is the product of a large research 
project, and to understand it you need more than the paragraph 
I've written above.  For more information about the Miro project 
send e-mail to (miro@cs.cmu.edu), there is even a video 
available.  The authors Ph.D. thesis, as well as the sources for 
the Miro tools, are available via anonymous FTP from 
ftp.cs.cmu.edu.  When you connect there, type "cd /afs /cs 
/project /miro /ftp" and "get ftp-instructions"; this will 
explain how to get the thesis and/or software.

4.4  SECURITY POLICY

	LAYER (6).  Everything discussed in layers {1...5} above 
involve specific things you can do, tools and techniques to 
implement, to address a particular area or "hole" in security.  
Your SECURITY POLICY is what ties all of that together into a 
cohesive and effective SECURITY PROGRAM.  There are many diverse 
issues to consider when formulating your policy, which alone is 
one of the biggest reasons why you must have one:

		What are the functional requirements of your 
		network?

		How secure do you need to be?  What needs to be 
		protected?

		How will you handle incident reporting and 
		prosecution?  evaluation, notification, response, 
		legal/investigative issues, logs, and post-
		incident procedures (read RFC 1244, it covers this 
		subject as well as the entire policy issue very 
		well).

		What does the law require you to do?  What about 
		privacy?  Since break-ins often occur via multiple 
		hops on computers throughout the US and the rest 
		of the world, you will need to consider a 
		variation of federal, state, local, as well as 
		foreign laws.

		Make security a dedicated and deliberate effort.

		User training and security awareness.

		What is considered acceptable use for users?  Do 
		the users understand what it is they are permitted 
		to do and what it is they are not permitted to do?

		What is considered acceptable use for system 
		administration staff?  Is using Crack to test 
		passwords okay?  Is giving friends outside the 
		organization accounts okay?

		Maintain a working relationship with the Computer 
		Emergency Response Team (CERT) at Carnegie Mellon 
		University (CMU) and your Forum of Incident 
		Response and Security Teams (FIRST) regional 
		representative "CERT" team.

		PLUS a myriad of different issues too numerous to 
		go  into in a summary paper.

	By answering these questions you determine what packages and 
methods in layers {1...5} (or their equivalent) that you want to 
implement, and in what ways you want to modify or configure them.  
"A security policy is a formal specification of the rules by 
which people are given access to a computer and its resources."  
(and to extend that to say...a network and its resources).  
Whatever tools you install to help you maintain the security of 
your network and monitor it, they must be configured to implement 
YOUR POLICY, or else they are not doing the whole job that needs 
to be done.  Therefore, you must first have a POLICY.

	For additional help in the area of policy development, 
contact cert@cert.org.  They can direct you to useful 
documentation on the subject and guide you to your FIRST regional 
CERT team representative.  A good starting point is Request For 
Comments (RFC) 1244 "Site Security Handbook" (96 pages), which is 
available via anonymous FTP from numerous RFC archive sites (for 
example:  nic.ddn.mil).

5.	ADDITIONAL SECURITY ENHANCEMENTS

	The issues and tools described for the UNIX-NSA Firewall 
Model (above), are what I consider part of a "base" set of tools 
and functional requirements for general security administration.  
The tools and methods described in this section are additional 
measures that can be combined with or added to your overall 
security program at any of the other levels.  The list of other 
possibilities for this section could be endless, I overview just 
a few of my favorites.

5.1  One-time Password Key-Card

	Since reusable passwords can be captured and used/reused by 
intruders, consider a "one-time password" scheme.  One-time 
passwords can be implemented using software-only solutions or 
software/hardware solutions, and there are several commercial 
products available; the following is an example.  Each user is 
assigned a "Digital Pathways" key-card (approximately $60 per 
user).  When you enter your PIN code, it supplies a password that 
is good only one time.  The only other piece to this, is software 
that replaces the login shell on your "firewall" server.

	Availability:  The source-code for this shell is based on 
code from the key card vendor and is currently not available to 
the public domain via anonymous FTP.  For additional information 
about this, send e-mail to (cert@cert.org).

5.2  Privacy Enhanced Mail (PEM)

	PEM is a RSA-based encryption scheme that encrypts sensitive 
information, but more than that it checks for message integrity 
and non-repudiation of origin, so that the originator cannot deny 
having sent the message. PEM is actually a protocol that is 
designed to allow use of symmetric (private-key) and asymmetric 
(public-key) cryptography methods.  In this example, Trusted 
Information Systems, Inc. (TIS) has implemented a PEM package 
using the public-key technique together with the Rand MH Message 
Handling System (version 6.7.2).  TIS/PEM libraries [16] can be 
adapted for implementation of non-mail applications as well.

	Availability:  TIS/PEM is a commercially available product, 
for additional information send e-mail to (pem-info@tis.com).

5.3  Kerberos

	Kerberos is a DES-based encryption scheme that encrypts 
sensitive information, such as passwords, sent via the network 
from client software to the server daemon process. The network 
services will automatically make requests to the Kerberos server 
for permission "tickets."  You will need to have the source to 
your client/server programs so that you can use the Kerberos 
libraries to build new applications.  Since Kerberos tickets are 
cached locally in /tmp, if there is more than one user on a given 
workstation, then a possibility for a collision exists.  Kerberos 
also relies upon the system time to operate, therefore it should 
be enhanced in the future to include a secure time server (timed 
is not appropriate).  There are two versions of Kerberos, one for 
OSF ported by HP, and one BSD-based developed by the author.

	Availability:  Kerberos is distributed via anonymous FTP 
from athena-dist.mit.edu in ~/pub/kerberos or ~/pub/kerberos5.

5.4  Private-Key Certificates

	This is not really a product, but rather a design proposal 
[17] that is an alternative method to PEM for adding network 
security to applications such as mail. Simply put, it uses the 
public-key style of implementation with private-key cryptography.  
It can be adapted to different types of applications and it is 
boilerplate so that you can essentially plug-in any encryption 
algorithm.  This is designed so that public-key protocols no 
longer have to rely on public-key encryption.

	Availability:  Unknown.  For more information, contact Don 
Davis, at Geer Zolot Assoc., Boston, MA (formerly of Project 
Athena at MIT).  His paper "Network Security via Private-Key 
Certificates" better describes this technique.

5.5  Multilevel Security (MLS)

	After you've done everything else (above) to make your  
network secure, then MLS will probably be one of your next 
logical steps.  That doesn't mean you have to wait until you've 
done everything else before implementing MLS, it's just (IMHO) 
that you would be wasting your time to go to the n'th degree 
before covering the fundamentals.  However, if you are just now 
deciding to which variant of the UNIX operating system to buy, 
consider buying an MLS variant now.  After you configure the MLS 
system to manage your security policy review the UNIX-NSA model 
to see what else you might add to make it more secure in a 
networked environment.  Many UNIX vendors are now shipping or 
preparing to ship a MLS version.  A couple examples that 
immediately come to mind is SecureWare CMW+ (based on A/UX or SCO 
ODT) and AT&T USL System V-Release 4-Enhanced Security (SVR4ES).

	For additional information regarding MLS implementations 
within the United States Department of Defense (DoD), contact 
Charles West at (703) 696-1891, Multilevel Security Technology 
Insertion Program (MLS TIP), Defense Information Systems Agency 
(DISA).

	For additional information regarding SecureWare CMW+, send 
e-mail to info@sware.com.  For additional information regarding 
AT&T USL SVR4ES, send e-mail to fate@usl.com.

5.6  File Encryption

	Users should get into the habit of encrypting sensitive 
files whenever they are stored in a public place or transmitted 
via public communication circuits. File encryption isn't 
bulletproof, but it is better than clear text for sensitive 
information.  The UNIX crypt utility is the least secure of these 
tools, since it can be broken using well-known decryption 
techniques.  The UNIX des utility (US export restriction apply) 
is more secure.  It has not been known to be broken, however DoD 
does not sanction its use for transmitting classified material.  
A relatively new UNIX tool PGP is available (uses RSA 
encryption), however there may be licensing and legal issues to 
be concerned with.

5.7  Secure Programming Methods

	Programmers can assist in the effort of security by reducing 
the chance that a potential intruder can exploit a hole or bug 
that is coded into locally developed software.  There is probably 
a lot that can be said about this, and their are probably many 
books on the subject somewhere.  But, here are some common 
recommendations:  (a) Never create a SETUID shell script.  There 
are well-known techniques used by intruders to gain access to a 
shell program that is running as root; (b) List the complete file 
name, including the full path in any system() or popen() call; 
and (c) Since there is no reason for users to have read access to 
a SETUID file (or any executable for that matter), set 
permissions to 4711 (SETUID) or 711 (Non-SETUID).

5.8  Counterintelligence

	To extend your security program to seek out, identify, and 
locate intruders;  you may want to modify some of the security 
tools (especially those proxy service daemons and event-driven 
auditors) to trace intruders back to their source, and otherwise 
maintain logs of data on intrusion attempts.  This information 
can prove vital in taking an offensive stance against security 
break-in's and can help prosecute offenders.

5.9  Other Possibilities

	Depending on your requirements you might look into 
specialized solutions such as Compartmented Mode Workstations 
(CMW), end-to-end Data Link Encryption (STU-III, Motorola NES, 
and XEROX XEU are examples), and TEMPEST.  The United States NCSC 
(Rainbow Series) and European ITSEC specifications can provide 
guidance in defining certain security requirements.

6.  SUMMARY OF AVAILABILITY

Section		Name			Availability

4.1		Router			Cisco, Wellfleet, Proteon
4.2.1		Tcp_wrapper		cert.org:/pub/tools/tcp_wrappers
4.2.2		Socks			s1.gov:/pub/socks.tar.Z
4.2.3		Kernel_wrap		eecs.nwu.edu:/pub/securelib
4.2.4		Swatch			sierra.stanford.edu:/pub/sources
4.2.5		CAP			e-mail to thompsond@orvb.saic.com
4.2.8		HSC-Gatekeeper		e-mail to Herve.Schauer@hsc-sec.fr
4.2.9		AT&T INET		e-mail to ches@research.att.com
4.3.1		COPS			cert.org:/pub/tools/cops/1.04
4.3.1		Crack			cert.org:/pub/tools/crack/crack_4.1-tar
4.3.1		Tripwire		cert.org:/pub/tools/tripwire/tripwire1.1
4.3.2		Shadow			comp.sources.misc;jfh@rpp386.cactus.org
4.3.3		Passwd+			dartmouth.edu:/pub/passwd+tar.Z
4.3.4		Audit			e-mail to bjorn@sysadmin.com
4.3.5		Miro			e-mail to miro@cs.cmu.edu
4.4		Policy			RFC 1244 and cert@cert.org
5.1		Key-card		e-mail to cert@cert.org
5.2		TIS/PEM			e-mail to pem-info@tis.com
5.3		Kerberos		athena-dist.mit.edu:/pub/kerberos5
5.4		Private-key		contact Don Davis, at Geer Zolot Assoc.
5.5		MLS			contact your UNIX vendor
5.6		File encrypt		contact your UNIX vendor
5.9		Other Poss.		research and contact various vendors

7.  ADDITIONAL SOURCES OF INFORMATION

	There are several primary sources of information that you 
can subscribe to and correspond with to keep up to date with 
current happenings in general network security and in specific 
the "firewall" community.  I recommend subscribing to the 
following mailing lists:  (a) cert-advisory-request @cert.org; 
(b) cert-tools-request @cert.org, and (c) firewalls 
@greatcircle.com (for the latter send e-mail to 
majordomo@greatcircle.com with a line that says "subscribe 
firewalls".  In addition to those mailing lists read and 
participate in the following USENET newsgroups:  (a) 
comp.security.announce (which echoes the CERT advisory mailing 
list); (b) comp.security.misc; (c) alt.security; (d) comp.risks; 
and (e) comp.virus.  Also, you can copy files from the CERT 
USENET Clipping Archive via anonymous FTP from cert.org.

Computer Emergency Response Team (CERT) Contact Information:

Emergencies:	+1 412 268-7090
FAX:		+1 412 268-6989
E-mail:		cert@cert.org

U.S. Mail:	CERT Coordination Center
		Software Engineering Institute
		Carnegie Mellon University
		4500 Fifth Avenue
		Pittsburgh, PA 15213-3890, USA

USENIX Papers are available directly from USENIX:

The USENIX Association
2560 Ninth Street, Suite 215
Berkeley, CA 94710, USA

8.  ACKNOWLEDGEMENTS

	The author extends thanks to several of the authors of the 
tools discussed in this paper and others for providing feedback 
that effected several changes in the first couple drafts of this 
paper (August 1992-February 1993).  This includes but, is not 
limited to the following:  Ed DeHart (CERT), Jim Ellis (CERT), 
David and Michelle Koblas (SOCKS), Herve Schauer (Gatekeeper), 
Dan Farmer (COPS), D. Brent Chapman (firewalls@greatcircle.com), 
Matt Bishop (Dartmouth), and Michael Jarriel (ARINC Research 
Corporation).

9.  REFERENCES

[1]	S. Carl-Mitchell and John S. Quarterman, Building Internet  
Firewalls. UnixWorld; February, 1992; pp 93-102.

[2]	Wietse Venema.  TCP Wrapper: Network Monitoring, Access 
Control and Booby Traps.  USENIX Proceedings, UNIX Security 
Symposium III; September 1992.

[3]	David and Michelle Koblas.  SOCKS.  USENIX Proceedings, UNIX 
Security Symposium III; September 1992.

[4]	William LeFebvre.  Restricting Access to System Daemons 
Under SunOS.  USENIX Proceedings, UNIX Security Symposium 
III; September 1992.

[5]	D. Brent Chapman.  Network (In)Security Through IP Packet 
Filtering.  USENIX Proceedings, UNIX Security Symposium III; 
September 1992.

[6]	Stephen E. Hansen and E. Todd Atkins.  Centralized System 
Monitoring with Swatch.  USENIX Proceedings, UNIX Security 
Symposium III; September 1992.

[7]	J. David Thompson and Kate Arndt.  A Secure Public Network 
Access Mechanism.  USENIX Proceedings, UNIX Security 
Symposium III; September 1992.

[8]	Herve Schauer.  An Internet Gatekeeper.  USENIX Proceedings, 
UNIX Security Symposium III; September 1992.

[9]	William Cheswick.  The Design of a Secure Internet Gateway.  
Murray Hill, NJ:  AT&T Bell Laboratories.

[10]	Garfinkel, Simson, and Gene Spafford.  Firewall Machines.  
Practical UNIX Security.  Sabastopol, CA: O'Reilly and 
Associates, Inc., 1991.

[11]	Shabbir J. Safdar.  Giving Customers the Tools to Protect 
Themselves.  USENIX Proceedings, UNIX Security Symposium 
III; September 1992.

[12]	John F. Haugh, II.  Introduction to the Shadow Password 
Suite.  USENIX Proceedings, UNIX Security Symposium III; 
September 1992.

[13]	Matt Bishop.  Anatomy of a Proactive Password Checker.  
USENIX Proceedings, UNIX Security Symposium III; September 
1992.

[14]	Bjorn Satdeva.  Audit: A Policy Driven Security Checker for 
a Heterogeneous Environment.  USENIX Proceedings, UNIX 
Security Symposium III; September 1992.

[15]	Allan Heydon and J.D. Tygar.  Specifying and Checking UNIX 
Security Constraints.  USENIX Proceedings, UNIX Security 
Symposium III; September 1992.
 
[16]	James M. Galvin and David M. Balenson.  Security Aspects of 
a UNIX PEM Implementation.  USENIX Proceedings, UNIX 
Security Symposium III; September 1992.

[17]	Don Davis.  Network Security Via Private-Key Certificates.  
USENIX Proceedings, UNIX Security Symposium III; September 
1992.

------------------------NOTICE---DISCLAIMER------------------------
The contents of this paper do not necessarily reflect the opinions
of my employer or anyone else that I know.  Nothing in this paper
should be construed as a product endorsement.  No warranty is
expressed or implied.  Any comments?  Please send me e-mail.
-------------------------------------------------------------------

------------------------NOTICE---COPYRIGHT-------------------------
(c) Copyright 1992,1993,1994 Robert B. Reinhardt.  This paper may be
distributabed freely as long as the paper is not modified in any way,
includes this notice, and is provided without guarantee or warranty
expressed or implied.  E-mail comments to breinhar, address below.
-------------------------------------------------------------------

--------------------------------------------------------
  /                 /    
 /__,_  _  o ____  /_  __.  __    Robert Bryan Reinhardt
/_)  (_</_<_/ / <_/ /_(_/|_/ (_  @tomahawk.welch.jhu.edu
