Oct 1, 1996 - system administrators in implementing their organization's security policy. A well- ... The BNST offers a network administrator the ability to.
BASIC NETWORK SECURITY TOOL Technical Report TR 96-033 Department of Computer Science Texas A&M University 1 October 1996 Paul Brutch, Michael McDonald, Lars Crotwell, Willis Marti, and Udo Pooch
ABSTRACT In this paper, we examine important security issues for Sun workstations connected to the Internet. In particular, we discuss the need for an organization to devise a network security policy, and we introduce the Basic Network Security Tool (BNST), being developed in the Department of Computer Science at Texas A&M University, that aids system administrators in implementing their organization’s security policy. A wellwritten network security policy should clearly state how network resources may be accessed. The policy should describe the network objects covered by these access rules and also address methods of enforcing the rules. We strongly believe that an organization’s security policy must incorporate the host security model as well as the network security model. By using the BNST, administrators can easily and efficiently implement their policy rules. The BNST offers a network administrator the ability to describe the objects in their network, specifying the network services and access permissions for each network object, and provides a method of enforcing these descriptions. Being developed as a freely available, public domain program, our tool currently only allows for TCP/IP -based network services; other protocols will added in future versions.
NETWORK SECURITY MOTIVATION FOR NETWORK SECURITY Begun in the late 1960s as a network research project funded by the U.S. Department of Defense, the Internet refers to a collection of worldwide networks linked together by a common protocol. Originally, the Internet comprised four hosts. As people discovered the ease at which ideas and information could be distributed over the Internet, and as more effective tools became available, the popularity of the Internet exploded. Because of its ubiquity, the Internet offers an astounding amount of information. Without access to this information, businesses and educational institutions have an obvious disadvantage. Unwilling to feel left behind and wanting to take advantage of
available services and resources, individuals and organizations race to connect to the Internet. New connections tally close to 1 million per month [Cobb 1995, 179]. Unfortunately, most users arrive with little knowledge of the risks involved in attaching their local network to the Internet. With connectivity come increased security threats. Whereas a system administrator before needed only to worry about organizational personnel stealing secrets and eavesdroppers intercepting messages over communication lines, they must now be concerned with unauthorized persons penetrating the private network through the Internet connection. Computer hackersfrom teen-age punks to professional spiescan, and often do, break into apparently secure systems on the Internet. The tremendous growth of the Internet has spawned a new generation of potential hackers Concomitantly, intrusion incidents have grown. In a May 1996 report, the General Accounting Office (GAO) stated that the Defense Information Systems Agency estimates Department of Defense (DOD) systems are attacked 250,000 times a year and that only 1 in 500 of these attacks are detected and reported [GAO 1996]. The need to provide network security is obvious, but balancing network protection and user productivity can be difficult. Opening the network to a large number of services gives users high access to network resources, but increases the risk that one of these services might be used to compromise the system. Cheswick and Bellovin describe the major TCP/IP services and their well-known ports. They recommend that administrators block almost half of the available services and they caution the use of the remaining services [CHESWICK, p:249-52]. Denying services, however, often leads to user frustration. Therefore, it is important to develop a formal set of rules to determine which services should be available on each host.
WHAT IS A NETWORK SECURITY POLICY? A network security policy is a set of rules used to govern the behavior of users, services provided, and resources available on the network. Ford defines a security policy as follows [FORD, p:14]: A security policy is a set of rules to apply to all security-relevant activities in a security domain (a security domain is typically the set of processing and communications resources belonging to one organization). The rules are established by an authority for that security domain. The network security policy must address rules concerning access to network resources, enforcement of policy, sanctions for violations of policy, and a description of objects covered by these rules. Rules on network accessibility describe the services and network resources available and the permissions granted to users of the network. Rules about policy enforcement are concerned with host and firewall configuration and the level of network monitoring provided. Rules on sanctions describe the penalties implied by violations of the network security policy; in particular, sanctions must address whether the intent was malicious or an honest mistake. In addition, the set of network objects that are governed by the network security policy must be described.
DEVELOPING A NETWORK SECURITY A formal method is required to develop and implement a network security policy. A network security policy to secure large distributed systems, including ill-formed legacy designs, requires a formal systematic approach. Implementation may be manual, but we believe that this is best accomplished by using an automated system. This is the reason that we are developing the BNST. The formulation of a network security policy should reflect comments received from the users, management direction, and prudent security considerations. User and management participation in the development of the network security policy can increase security awareness and encourage adherence to policy goals. The network administrator must examine the network service access requirements for each host in their network. Although many of these requirements might be the same for all hosts, some hosts might need to be less accessible than others, depending on user requirements and the host’s function. The network service access rules for each host constitute its network service access policy.
NETWORK SERVICE ACCESS POLICY The National Computer Security Association (NCSA) defines a network service access policy as an “issue-specific policy which defines those services which will be allowed or explicitly denied from the restricted network, plus the way in which these services will be used, and the conditions for exceptions to this policy” [NCSA , p:6]. In this paper, we broaden this definition to include those services accessible from hosts inside the administrator’s network as well as those from the Internet. The network service access rules for an individual host in a network can be determined by its relationship to all other hosts that can reach this host. For the purpose of this paper, we refer to any host residing outside of the administrator’s network as the Internet. These relationships can be broken down into three categories: internal relationships, external relationships, and global relationships. Internal Network Service Access Relationships are relationships among hosts residing within the administrator’s network. External Network Service Access Relationships are relationships between hosts inside the administrator’s network and hosts on the Internet. Global Network Service Access Relationships are relationships that can be applied equally to hosts within the administrator’s network as well as to any host on the Internet. At a minimum, a network service access policy for an individual host must address external and global relationships. If all of the hosts within an administrator’s network are implicitly trusted, then internal service access relationships might not be necessary. We recommend, however, that all of the relationships be considered. Once the network service access policy for each host in the network has been determined, the administrator can implement the rules to enforce the organization’s network security policy. The network security policy can be enforced by incorporating the two models of security.These are the host security model and network security model.
HOST SECURITY MODEL The first layer of protection that needs to be considered when implementing a network security policy is the host security model. Chapman describes the host security model as follows [CHAPMAN , p:14]: Probably the most common model for computer security is host security. With this model, you enforce the security of each host machine separately, and you make every effort to avoid or alleviate all the known security problems that might affect that particular host. What’s wrong with host security? It’s not that it doesn’t work on individual machines; it’s that it doesn’t scale to large numbers of machines. In the host security model, a Sun workstation’s network services can be disabled by manually editing it’s inetd daemon configuration file by employing server filters such as TCP Wrapper or xinetd, or using the Basic Network Security Tool (BNST). The prototype BNST provides host security for Sun workstations by either allowing or denying the network services in the host’s inetd configuration file. Farrow describes the inetd daemon as follows [FARROW, p:150]: The UNIX system has an unusual method for launching network daemons. (Daemons are processes that run independently of any terminal or user.) Most UNIX daemons are started during the startup process, by the rc scripts. The network daemons get started by a single daemon, inetd, the Internet daemon. The Internet daemon reads a configuration file, /etc/inetd.conf, when it starts up. This configuration file tells the Internet Daemon which sockets (virtual connections) to listen to. When the Internet daemon gets awakened by a packet arriving at a socket, it launched the network daemon associated with that socket. The TCP Wrapper from Wieste Venema and the xinetd by Panagiotis Tsirigotis provide the ability for access control and logging of the services started by the inetd daemon. Hughes calls these programs server filters and defines a server filter as follows [HUGHES, p: 315]: Also called host-based firewalls, these [server] filters run on the same hosts as the server programs they protect, operating strictly at the application layer. In many cases, they even provide their flavor of access control without a single modification to the server application code.
NETWORK SECURITY MODEL The second layer of protection that needs to be considered when implementing a network security policy is the network security model. Chapman describes the network security model as follows [CHAPMAN, p:15]: With a network security model, you concentrate on controlling network access to your various hosts and the services they offer, rather than on
securing them one by one. Network security approaches include building firewalls to protect your internal systems and networks, using strong authentication approaches (such as one-time passwords), and using encryption to protect particularly sensitive data as it transits the network. A firewall is a barrier that restricts the flow of data between the Internet and the administrator’s network. Cooper defines firewalls as “devices that separate a system from another system or provide a significant barrier to entry” [COOPER, p: 48]. The BNST uses the Drawbridge firewall, which was developed by a separate research group at Texas A&M University. The Drawbridge firewall is described in more detail later in this paper.
IMPLEMENTING A NETWORK SECURITY POLICY We recommend implementing both models of security protection whenever possible. From our experience, we have found that solely relying on protection being provided by the host security model is not completely secure. For example, if a site has more than one administrator, a “secure” host’s configuration files might be changed by an untrained administrator. This could open a security hole that was thought to have been closed; thus, attacks on this vulnerability might be ignored. Most network administrators invest their efforts primarily in erecting a firewall. The basic premise behind a firewall is that it provides protection to hosts inside a trusted network from a untrusted network. We believe that a network security policy must address the security relationships between hosts residing within the network as well as to the Internet. For simplicity, we refer to all hosts residing outside of the system administrator’s network as the Internet. If the administrator’s network consists of hundreds of hosts, as ours does, implementing a new network security policy can be time-consuming. Manually editing individual hosts configuration files can lead to errors, which can introduce unexpected security access vulnerabilities. Writing script files to configure a firewall, such as Drawbridge, can also introduce similar security problems. What is required is an automated tool that can aid an administrator in implementing their organization’s network security policy from a trusted host. Such a tool should provide a user-friendly interactive method to describe the desired network security policy and provide the tools necessary to actually implement that policy in an automated manner. The tool should not only be able to configure the firewall between the Internet and the administrator’s network, but also each individual host inside of the network.
COMMERCIAL PRODUCTS FOR ENFORCING NETWORK SECURITY There are several commercial applications that enforce an organization’s network security policy. One such product is the Solstice FireWall-1, which is described below [SUNSOFT, p:4]:
Solstice FireWall-1, from SunSoft, was developed by CheckPoint Software Technologies Ltd., an Israeli company. The product combines the efficiency of a general-purpose solution for all network protocols with application-level savvy. Logging and alerting mechanisms are included, and easy installation and setup procedures are provided. On top of this unique protocolindependent technology, a simple, intuitive, object-oriented user interface enables a flexible and uniform way of implementing an organization’s global security policy. Although commercial products are available, we are developing the BNST for the public domain. Our tool is being developed to facilitate the implementation of a network security policy for organizations in which the success a of security attack would not devastate the organization’s ability to operate. One such environment would be academia. We recommend that the business and government sectors choose from the available commercial tools.
BASIC NETWORK SECURITY TOOL GOAL OF THE BASIC NETWORK SECURITY TOOL PROJECT At Texas A&M University, we are developing an automated tool, the Basic Network Security Tool (BNST), to aid administrators in implementing their organization’s network security policy. Built by using the C programming language and Tcl/Tk, the BNST is designed to run on any workstation running Solaris 2.x. We assume that the workstation selected to run the BNST is secure and is trusted by the other hosts on the network. We also assume that the administrator has erected a firewall between their network and the Internet. By default, the BNST works with the Drawbridge Firewall tool, which was also developed at Texas A&M University. Unlike other network security tools, the BNST does not assume that “all hosts” within the administrator’s network are trusted. The BNST provides the capability to create an organization’s network security policy, addressing the internal, external and global network service access relationships for each host in the administrator’s network. The BNST comprises seven modules: User Interface, Topology Descriptor, Network Service Access, Host Configuration, Firewall Configuration, Centralized Logging, and Help Module. The design goal for each of these six modules is described in the following sections.
USER INTERFACE MODULE The User Interface Module offers a user-friendly method of implementing a network security policy. The goal of the User Interface Module is to provide a windows-based, mouse-driven environment for access to each of the other modules. We are currently using Tcl/Tk to meet this goal.
TOPOLOGY DESCRIPTOR MODULE The goal of the Topology Descriptor Module is to provide the administrator with the ability to describe the objects in their network; the module allows the administrator to create a model of their network topology. By default, the topology configuration is a firewall between the Internet and the administrator’s network. Icons are available to model the following network objects: •
Hosts
•
Firewalls
•
Routers
•
Hubs
•
Bridges
•
Various types of cable
All IP-addressable objects within the administrator’s network have various attributes that can be maintained by the BNST. Attributes that are currently maintained include IP address, host and domain name, machine type, operating system, and a comment field for additional pertinent information.
NETWORK SERVICE ACCESS MODULE The Network Service Access Module provides the capability to maintain network service access for each host in the administrator’s network. Network services currently under consideration are those of the TCP/IP protocol suite. We have functionally grouped several of these services; each group has its own menu. For each host in the network, the service access menus under consideration are shown in Table 1:
Remote Login Access Menu
File Transfer and File Access Menu
User Information Menu
Electronic Mail/ User Access Menu
telnet
ftp/ftp-data
finger
smtp
login
tftp
who
talk
shell
nfsd exec Table 1. Service Access Menus.
To develop a network security policy for a selected host, the administrator applies restrictions to each of the network service in the service access menus. Service access restrictions can be applied according to the direction of the network traffic. That is, restrictions can be applied to traffic coming into the selected host or to traffic going from the selected host to the Internet.
The following restrictions can be applied to each service on traffic coming into a selected host:
n n n n n
Allow All Access Deny All Access Deny Only Internet Access Allow Only {IP Address | hostname} Deny Only {IP Address | hostname }
The following restrictions can be applied to each service on traffic going to the Internet from a selected host:
n n
Allow All Access Deny All Access
HOST CONFIGURATION MODULE Once the administrator has entered the desired service access restrictions for a selected host or group of hosts, the Host Configuration Module produces the configuration files necessary to implement the desired service access policy on each host. The Host Configuration Module addresses the service access restrictions on traffic coming into the host and whether the source of the traffic is a host inside the administrator’s network or on the Internet. We are considering implementing the xinetd program, developed by Panagiotis Tsirigotis, to perform host level security configuration. The xinetd program provides for access control and selective logging on the services started by the inetd daemon. Cooper states that xinetd also offers the following capabilities [COOPER, p:63]:
n n n
Enhanced logging, including the duration of each client/server connection Ability to restrict access times for a service Ability to restrict the number of simultaneous instances of a server program
Although this implementation will not provide complete host level security, it does satisfy some of the basic security requirements for interconnected hosts. Currently, each host’s configuration files are written to a separate directory on the trusted host running the BNST. We are evaluating the development of a secure daemon, using RPC, to automatically transfer these configuration files from the trusted host to each of the selected hosts in the administrator’s network. Strong authentication is necessary to verify that the system files being transferred to a network host are originating from the trusted host and not from an unauthorized source. As is wellknown, most RPC authentication schemes are insecure. We have developed a program under SunOS 4.1.3 that uses DES authentication in an ONC RPC environment to prototype the transfer of system files. We are continuing to research
the same idea using ONC RPC under Solaris 2.5, which implements several RPC commands that differ from earlier versions of SunOS.
FIREWALL CONFIGURATION MODULE The BNST’s Firewall Configuration Module evaluates the network service access policy for each host in the administrator’s network and produces the necessary configuration files for the administrator’s existing firewall tool. The Firewall Configuration Module assumes that there is a firewall between the administrator’s network and the Internet. The administrator’s firewall tool provides the capability to restrict network traffic coming in to and going out from the administrator’s network. BNST is currently designed to configure the Drawbridge Packet Filter; however, we desire to make the tool compatible with other firewall products. Packet filters are an inexpensive and flexible element of network security. Cheswick and Bellovin describe how a packet filter functions [CHESWICK, p:55]: Packet filters work by dropping packets based on their source or destination addresses or ports. In general, no context is kept; decisions are made only from the contents of the current packet. Depending on the type of router, filtering may be done at input time, at output time, or both. The administrator makes a list of the acceptable machines and services and a stoplist of unacceptable machines or services. It is easy to permit or deny access at the host or network level with a packet filter. Packet filters suffer from several disadvantages; for example, despite their simplistic operation, packet filters can be extremely tedious to configure [Chapman, p:135-6]. Organizations that gamble on packet filters as their only line of network defense run the risk of hackers exploiting such limitations. In the BNST, we have attempted to overcome these disadvantages by additionally implementing host security and automating the packet filter configuration process. Packet filtering is usually done by routers, though not all routers have this capability. PC-based packet filters also exist. The Drawbridge Packet Filter is a PC-based filter that was developed by David Hess, Doug Schales, and David Safford at Texas A&M University. Siyan and Hare provide an overview of the Drawbridge Packet Filter [Siyan, p:253-57]: Drawbridge is a bridging filter that has filtering at the center of design. It uses custom table-driven software called the Filter that can run on a dedicated PC. The Filter Manager and Filter Compiler both run on Sun workstations. The Filter Manager communicates and manages Filter (running on a PC) using SUN’s NIT support. The Filter Compiler generates filtering tables that are loaded into Filter through the Filter Manager. The language used by the Filter Compiler contains constructs for creating the various tables used by the Filter.
The Filter program filters TCP/IP on incoming and outgoing basis and UDP/IP on an incoming basis. All other protocols are transparently bridged. The Drawbridge Filter Compiler program accepts a configuration file developed by using the Drawbridge Filter language to create the Filter tables. These tables are uploaded to the Filter by the Filter Manager and the tables contain the rules used to enforce the desired network security policy. The BNST program currently produces packet filter configuration files according to the Drawbridge Filter Language. The Drawbridge Filter Language has the service specification as its basic element. Safford describes the service specifications as follows [SAFFORD]: The service specification contains four pieces of information: the service, protocol, source or destination, and traffic direction. The service can be either an entry from /etc/services or a numeric port. Service ranges can also be used. The protocol specifies the protocol the service uses. The source or destination indicates whether the filter should use the source port or the destination port. Finally, the traffic direction indicates whether this is for outbound packets, inbound packets, or both. One limitation of Drawbridge is that it provides only limited exception handling. Two tables are produced by the Filter Compiler to handle exceptions: REJECT and ALLOW. The Drawbridge Filter Language provides the ability to reject all inbound packets from an specified host outside of the firewall or allow outbound packets for a specified service to a specified host outside of the firewall. Future enhancements to the Drawbridge Packet Filter will provide the ability to create service restrictions between a specified host inside the firewall to a specified host outside the firewall.
CENTRALIZED LOGGING MODULE One of the main goals of the BNST project is to provide centralized logging and alerting capability for the network administrator. Currently, there is little or no logging and alerting capability in the prototype BNST. We are interested in incorporating the extensive logging capability provided by the xinetd program and the Monitor tools, which are part of the TAMU Security Package, into the BNST. In addition to access control of the services started by the inetd daemon, the xinetd program provides significant logging capabilities. In the xinetd README file, Tsirigotis states that logging is provided on the time a server started, the remote user who started the server, the address of remote user’s site, how long the server was running, and information on failed attempts [TSIRIGOTIS]. Version 2.0 of Drawbridge now provides syslog support, but the majority of logging by the Texas A&M Security Package is provided by the Monitor tools set. Safford describes the Monitor tools as follows [SAFFORD]: Realizing that drawbridge was a compromise between convenience and security, a set of monitoring tools was developed to look for intrusions that might be attempting to circumvent the filter. These tools continuously monitor
the Internet link, checking for unusual connections, patterns of connections, and for a wide range of specific intrusion signatures. We are evaluating the Simple Network Management Protocol (SNMP), along with the logging capabilities provided by the tools described above, to develop a Centralized Logging Module. In addition to general logging of network service activity, the Centralized Logging Module alerts the administrator of any suspicious behavior detected on any of the monitored hosts or at the Internet link.
HELP MODULE The Help Module provides context-sensitive help for the services supported by the BNST. The Help Module uses a window-based display to describie the selected services and any recommendations for restricting the use of that service.
BNST PROTOTYPE A prototype of the BNST is currently under development. This prototype demonstrates the basic capabilities required for a tool to implement an organization’s network security policy. The modules for each of the functional components of the tool are described in the following sections.
USER INTERFACE MODULE Developed by using Tcl/Tk, the User Interface Module provides a user-friendly, interactive method to implement an organization’s network security policy. The user interface provides menus for the network administrator to describe the objects in their network topology, create a service access policy for each host, and provide a method to enforce the network security policy. A user-interactive help menu is also under development to provide assistance for an administrator to create their network security policy. This help menu will describe the TCP/IP services addressed by the tool and provide information on security vulnerabilities associated with allowing these services.
TOPOLOGY DESCRIPTOR MODULE The Topology Descriptor Module was also developed by using Tcl/Tk. The Topology Descriptor provides the administrator with the capability to describe the objects in the network, covered by the network security policy, by creating a network topology model. Icons are used to describe the network topology. Currently, the BNST only provides support for a network topology in which there is a single firewall between the administrator’s network and the Internet. Eventually, we would like to support multiple firewall instantiations inside of an administrator’s network. The Topology Descriptor allows the administrator to describe attributes for each object in the network. Attributes that are used to describe a host include the following: •
IP Address
•
Host Name
•
Machine Type
•
Operating System
SERVICE ACCESS POLICY MODULE The prototype BNST provides the capability to describe and implement a network service access policy for each host within the administrator’s network. There are three functional areas of TCP/IP protocol services that are currently supported. These are shown in Table 2.
REMOTE LOGIN
FILE TRANSFER/ACCESS
USER INFO/ACCESS
telnet
ftp
finger
login
tftp
talk
shell
exec Table 2. TCP/IP Services Currently Supported.
The service access policy considers whether traffic originates from outside or inside the administrator’s network. The policy also allows restrictions to be placed on traffic coming into a host or traffic leaving the administrator’s network. For traffic coming into a host, the restrictions that can be applied to each service are shown in Table 3.
DEFAULT
ALLOW ALL
DENY ALL
Allow service into host
Allow service into host
Deny service into host
Deny service thru firewall
Allow service thru firewall
Deny service thru firewall
Table 3. Service Access Restriction for Traffic Coming In to a Host. The administrator must decide whether to allow an individual host to send traffic outside of the network, depending on the service. The restrictions for each service on traffic leaving the administrator’s network are shown in Table 4.
Default Allow service thru firewall
Deny Deny service thru firewall
Table 4. Service Access Restrictions for Traffic Leaving the Network.
HOST CONFIGURATION MODULE Originally, hosts on a network ran a separate daemon for each TCP/IP service. When a service request, such as a Telnet connection, was made to or from a remote host, the service daemon would spawn a process to handle the service. As the number of TCP/IP services grew, this method resulted in an inordinate amount of running daemons. To solve this dilemma, BSD UNIX introduced the inetd daemon, a “super server” initiated at system boot time, which starts the appropriate service daemon when a specific service request is detected. The inetd daemon uses a single configuration file, inetd.conf, that lists the services that the system provides, in addition to the port number associated with each service. This grouping of services into a single configuration file offers a convenient first level of host security. By modifying inetd.conf, service access restrictions for inbound or outbound traffic can be applied. According to the file syntax described by the inetd.conf man page: Each server entry is composed of a single line of the form: service-name endpoint-type protocol wait-status uid server-program server-arguments A # (number sign) indicates the beginning of a comment; characters up to the end of the line are not interpreted by routines that search this file. By commenting its file entry, the service is effectively turned off. When a request arrives at the host for a restricted service, for example, the inetd daemon searches the inetd.conf file for the appropriate server. Finding none, because the inetd daemon ignores commented lines, the connection request is refused. The Host Configuration Module receives the service access restrictions for a host from the Service Access Module and creates a directory to hold the configuration files for that host. A pristine copy of the inetd.conf file, which can be edited by the Module, is stored in the directory. The Host Configuration Module searches for each restricted service in the file. If this Module finds a restricted service, a comment character is prepended to the line containing the “service-name.” When the Module finishes, the user has an inetd.conf file that implements the restrictions. The file can then be transferred to the corresponding host to replace the original /etc/inetd.conf file.
FIREWALL CONFIGURATION MODULE Service access restrictions for traffic coming into and leaving the administrator’s network are also applied at the firewall level. The BNST uses Drawbridge, a packet filtering firewall developed at Texas A&M University, to implement restrictions at this level. Drawbridge uses a Filter Compiler to create tables that are used by Filter, which is a table-based filtering bridge. The Drawbridge configuration process can be briefly described as follows [SAFFORD]: First a source file containing filtering specifications in a special language is generated and maintained by an administrator. The file is passed through the fc [filter compiler], which generates the tables used by filter. These tables can be loaded via fm [filter manager] or by floppy disk.
The BNST’s Firewall Configuration Module creates the “source file” that is passed through the Drawbridge’s Filter Compiler. The Module simply appends an entry to the source file for each host’s service restrictions. For the prototype, we assume that by default, all UDP-based services are disallowed coming into the network, but all TCPbased services are allowed in and out. If, for example, we want to deny all inbound FTP and Telnet connections at host babylon.tamu.edu, then our source file would like the following: define default
, ;
host babylon.tamu.edu default, , , ; Restrictions that cannot be implemented at either the host level or the firewall level are flagged to the user as being unsupported.
CONCLUSIONS The goal of the Basic Network Security Tool (BNST) project is to develop a public domain tool, which may be used to provide network security for interconnected Sun workstations. The BNST provides the minimum set of security rules for the enforcement of an organization’s network security policy. One feature that we see lacking in many commercial products is a failure to address the host security model. Most available tools for implementing network security concentrate solely on the firewall. The BNST provides security rules to enforce both the host and network security models. The BNST is a practical application of ongoing research to provide Internet security.
ACKNOWLEDGMENT We would like acknowledge David Hess for his advice and support.
REFERENCES CHAPMAN
D. Brent Chapman and Elizabeth Zwicky. Building Internet Firewalls. Sebastopol CA: O’Reilly and Associates, Inc., 1995.
CHESWICK William Cheswick and Steven Bellovin. Firewalls and Internet Security: Repelling the Wiley Hacker. Reading MA: Addison-Wesley, 1994. COBB
Steven Cobb. “Internet Firewalls”. BYTE 20, no. 12 (1995): 179-80.
COOPER
Fredric Cooper, Chris Goggans, John Halvey; and et. al. Implementing Internet Security, Indianapolis, IN: New Riders Publishing, 1995.
FARROW
Rik Farrow. UNIX System Security: How to Protect Your Data and
Prevent Intruders, Reading MA: Addison Wesley, 1991. FORD
Warwick Ford. Computer Communications Security, Englewood Cliffs, NJ: Prentice-Hall Inc., 1994.
GAO
United States General Accounting Office. “Information Security: Computer Attacks at Department of Defense Pose Increasing Risks”. GAO/AIMD-96-84, 22 May 1996.
HUGHES
Larry Hughes, Actual Useful Internet Security Techniques, Indianapolis, IN: New Riders Publishing, 1995.
NSCA
National Computer Security Association. “NCSA Firewall Policy Guide V 1.01”, NCSA Security White Paper Series, 1996.
SAFFORD
David Safford, Douglas Scales, David Hess, “The TAMU Security Package: An Ongoing Response to Internet Intruders in an Academic Environment”, Fourth USENIX Security Symposium, 1993.
SIYAN
Karanjit Siyan and Chris Hare. Internet Firewalls and Network Security. Indianapolis: IN: New Riders Publishing, 1995.
SUNSOFT
SunSoft, “Solstice FireWall-1 Internet Firewall Technology”. Technical White Paper, July, 1995.
TSIRIGOTIS Panagiotis Tsirigotis, “README”, available at ftp.irisa.fr, 1992.
