Protecting your network with firewalls, featuring Sun's SunScreen EFS firewall

We take an in-depth look at firewalls, particularly Sun's SunScreen EFS firewall. We detail its features and show, by example, how best to implement it

By Ken Masica

January 1998

Abstract

The network security plan for any organization should be based on a multiple-level approach. If an intruder manages to penetrate the first level, one or more additional levels of security should be in place to deflect him before the target is reached or corporate assets are threatened. Multiple security levels will at the very least slow down an intruder and will ideally detect suspicious activity. A comprehensive security architecture includes protective measures at the router, firewall, system, data, and user levels. Security plans and their resulting implementation architectures vary widely among organizations and depend on such factors as corporate culture, assets, and perceived risk. In this article, we will examine one of the most important components in a security architecture -- the firewall. The role of the firewall will be explained, and the various types of firewall designs will be discussed. We will then look closely at Sun's EFS firewall product and an example EFS configuration. (3,300 words)

Mail this
article to
a friend

firewall, in the most basic sense, is an electronic barrier between two or more networks. At the very least, it should sit between your private network and the public Internet. A more typical installation, however, will require the firewall to have multiple interfaces and sit between the multiple subnets and networks that comprise your organization. In this role, the firewall acts like a traffic cop, controlling the flow of all network connection requests and all packets across its multiple interfaces. The firewall will either allow a given packet or connection through the intersection of interfaces, or it will stop the packet or connection. The firewall carries out its job by enforcing policies specified in the organizational security plan. And, like any good enforcement entity, the firewall has the ability to detect suspicious activity and capture packets for later analysis. A good way to characterize the role of the firewall is: protection, rejection, and detection.

Advertisements

Types of firewalls
There are three basic firewall product designs:

Packet filtering: This type of firewall examines the header information of every inbound and outbound packet and either passes the packet or drops it. Rules are specified in terms of source and destination IP address, higher layer protocol (TCP, UDP, ICMP, etc.), and TCP or UDP port number. Some firewalls, such as SunScreen EFS, can look beyond the TCP/IP header and examine other fields such as RPC number.
Circuit-level proxy: This type of firewall will create an IP-level connection from a client on one interface to a server on another interface without interpreting the higher level application protocol. The low-level IP bridge that is created by the firewall to connect the client and server is referred to as a "circuit." The term "proxy" is used because the firewall is acting as an intermediary between the client and server to (securely) facilitate the connection.
Application-level proxy: An application proxy also establishes connectivity between a client and server, but at a much higher level. It will actively interpret the application protocol while performing its job of relaying packets. This type of proxy will maintain one high-level connection with the client and another with the server, maintaining a separate dialogue with each.
The circuit and application proxy firewalls are related because they both serve as active intermediate nodes in the connection between the client and the server. They both generate new packets on each interface with the IP address of the firewall. This is in contrast to a packet filtering firewall, which is a passive node in the connection between client and server and does not alter the IP header of processed packets. A packet filtering firewall simply forwards unaltered packets among its various interfaces (assuming the received packet satisfies at least one pass rule).

Features of the EFS firewall
The SunScreen EFS product is a packet filtering firewall. It is a software-only implementation (as opposed to a turnkey firewall system) that will run on a Solaris version 2.4 or later. It does not have proxy capability but instead relies on a flexible rule definition design to provide security. Later, we'll present a simple firewall configuration that will demonstrate the process of defining and implementing EFS rules.

SunScreen EFS has many desirable features, including the support of SNMP trap alerts, a Web browser interface, secure remote administration capability, and the support of SKIP (simple key management for Internet protocols) data encryption and authentication.

SNMP (simple network management protocol) is an Internet standard for the remote monitoring and configuration of network devices. SNMP traps allow a device to autonomously send an alert to a management station when a critical, predefined event occurs. In the case of EFS, network administrators have the option of defining an SNMP alert as the action associated with a rule. The SNMP alert can be sent to a network management console such as Sun's SunNet Manager or Hewlett-Packard's OpenView.

SKIP is a data encryption and authentication protocol developed by Sun. It is based on Diffie-Hellman key exchange and supports numerous encryption algorithms, key lengths, and certificate formats. The EFS firewall uses SKIP to provide secure channels for remote firewall administration and for establishing encrypted data tunnels between EFS and other SKIP-enabled hosts or firewall systems. Tunnels can provide topology hiding and data protection for internal hosts that send data outside the firewall and across a corporate intranet or the public Internet. The SKIP feature can serve as the foundation for building secure intranet or extranet networks.

Installing EFS
As previously mentioned, the EFS firewall is a software-only implementation. Therefore, the network administrator must prepare a workstation for EFS to run on. EFS supports SPARC 4, 5, 10, and 20, and Ultra platforms running Solaris 2.4 or later. One or more additional network interfaces will have to be added to the workstation, depending on the number of subnets that need to be supported. Workstation model and processor speed selection should be based on the size of the network, the number of subnets, and the anticipated amount of firewall traffic loading. Disk space should be determined primarily by the amount of logging that will be done.

EFS installation is a relatively straightforward process of adding packages from a CD-ROM distribution. An initial decision, however, must be made regarding local versus remote administration of the firewall. A nice feature of EFS is that a remote administration workstation can be configured to run the Web browser interface over a secure SKIP encryption channel. This arrangement frees the network administrator from having to configure and monitor the firewall from the local console.

If the remote administration option is selected, the installation process will then involve the extra steps of loading EFS software onto the remote station and configuring the secure SKIP channel. Sun provides an installation script that helps with generating and exporting the necessary encryption keys for the secure channel, but experience with SKIP definitely helps. The SKIP product is actually bundled with EFS, so separate SKIP installation and user manuals are provided to ease the process. (See the Resources section below for more information on SKIP.)

Example firewall implementation
The example shown below will serve as a basis for understanding how EFS can be implemented in a security architecture and how rules are defined and configured on EFS. This example implementation is not meant to be representative of all the public and private services an organization must contend with, nor is it meant to suggest how a network should be designed or where servers should be placed. It merely serves as an example for purposes of explanation and discussion of the EFS firewall.

In our example diagram, it is assumed that a single public Internet address is assigned to the organization and that the address is divided into three subnets. Routing is enabled on the EFS firewall, and a static routing table is created for routing among the subnets. Public DNS and WWW servers are placed on the public subnet called "dmz-net." Note that it is entirely possible to place these servers on their own subnet behind the firewall to enhance their security. When deciding whether to place public servers behind the firewall or on the public subnet, however, factors such as firewall traffic loading and performance to Internet customers should be considered and weighed against system vulnerability and perceived risk. In this example, a public WWW server is placed on the dmz-net to serve pages. A back-end database connection through the firewall to the WWW data server on the servers-net subnet is also provided as a secure link to the corporate information base. The "users-net" subnet is primarily for user desktop machines and also includes the machine used to administer the public servers on the dmz-subnet.

Working with interfaces
The first step in configuring SunScreen EFS is to enable each of the subnet interfaces. Each interface must be manually configured, enabled, and tested using the standard Solaris network configuration procedures. After the interfaces are manually enabled, they must be activated on the firewall using the EFS administration Web interface. The EFS Web interface is a simple-to-use, graphical front end to EFS and is a nice feature of the product. After selecting the appropriate link on the Web administration page, a list of all the detected physical interfaces will be displayed. Each interface can then be configured and enabled. Configuration of an interface involves defining the type of logging, SNMP trap use, and the type of reachability error messages sent to remote systems. The network administrator can enable and disable interfaces at any time using the Web administration tool. An example EFS interfaces page is shown below.

Click image for larger version (28 K).

Working with rules
There are three types of rules that can be defined on EFS:

Encryption rules: used to establish a SKIP-based encrypted tunnel between the firewall and a SKIP-enabled host or another SKIP-enabled firewall
Pass rules: allow packets to be passed from one interface to another if the packet meets specified criteria
Fail rules: cause the firewall to take one or more predefined actions if the packet meets specified criteria

The order in which the rules are presented above is the actual order in which EFS applies them against every processed packet. If a packet meets the criteria of an encryption rule, then it is encrypted with the SKIP protocol and the packet processing ends. If the packet does not match any of the encryption rules but does meet the criteria of at least one pass rule, then it is forwarded to the appropriate interface as defined in the pass rule. If a packet does not match any of the encryption or pass rules, but does match a fail rule, the action associated with the fail rule is taken (i.e., detailed logging or transmission of an SNMP trap). It is important to note that EFS has a "default deny" design. This means that no packets are forwarded by EFS unless specifically permitted by an encryption or pass rule. Fail rules exist to give network administrators more flexibility and control over identifying and documenting suspicious activity. They are not needed to block the forwarding of unwanted packets.

In our example firewall implementation diagram, there are several rules that need to be defined for controlling the flow of packets between the various machines, subnets, and the Internet. We will look in detail at the creation of one of the required rules and then view a summary of the other required rules.

Referring to the diagram, the users-net subnet contains all the user desktop machines. The purpose of this subnet is to consolidate all users behind one interface of the firewall and then define relatively restrictive inbound and outbound services for this group of users. One necessary network service for this group that we will examine now is outbound WWW.

The first step in the rule creation process is to define the IP addresses of the various hosts, servers, subnets, and networks on which the rule will operate. EFS permits the definition of individual machine addresses, address ranges, and address lists. Address ranges and lists allow the network administrator to work with logically-named groups of systems or with entire subnets or networks at one time. For our outbound WWW rule, it is necessary to define two address groups: the "users-net" subnet and the "Internet" network. The users-net subnet is defined as an address range, and the Internet network can be defined using the built-in operator (meaning all IP addresses).

Once the address groups are defined, the service needs to be identified -- in this case the WWW or HTTP protocol assigned to TCP port 80. During rule definition, EFS pops up a list of the standard Internet services and their corresponding port numbers. After selecting "WWW" from the services list, the next step is to specify the permitted direction of packet flow between the address groups. In our example, packet flow is permitted only from the users-net subnet to the Internet network. Note that a rule permitting return inbound WWW packets to the users-net is not required. EFS will automatically allow the return WWW packets so long as they correspond to a WWW session that was initiated by a machine in the users-net subnet. The ability of a firewall to identify session initiation between clients and servers and then monitor and control the inbound and outbound packet flow between them is referred to as "stateful inspection." Because SunScreen EFS has this capability, it will allow only WWW service requests that originate from the machines in the users-net subnet and their corresponding outbound and inbound session packets through the firewall.

Once the address groups, network service, and directional flow have been specified, the final step is to select an action associated with the rule. By default, pass rules take no action. However, a network administrator can define actions such as summary logging, detailed logging, or SNMP trap transmission as desired.

The EFS rules definition window is shown below for our example firewall implementation. Note that rules are defined using a separate windows-based program that runs outside of the Web administration interface.

The rules definition window divides rules into the three categories described previously: encryption, pass, and fail. Sample rules that pertain to our example firewall implementation are given for each category. Note the pass rules defined for both standard WWW/HTTP access (port 80) and for the more secure HTTPS protocol (port 443). The HTTPS protocol was not one of the predefined services on EFS, but was easy to define using the window-based service definition tool. Other pass rules for the "user-net" subnet include access to the public DNS server and access to the mail server.

Also included in the rules definition window are a few sample encryption rules. Use of EFS encryption capability is beyond the scope of this article, but these sample rules were included to suggest possible applications. Encrypted connections are defined from the admin host to the public DNS and WWW servers to create a secure maintenance and administration channel. The encrypted channels are a good idea given the location of the servers on the public subnet. Likewise, an encrypted channel is created from the WWW public server to the back-end WWW database machine. The firewall protects the database server and the secure channel provides data privacy of proprietary or sensitive corporate information.

Finally, two sample EFS fail rules are shown. Both produce detailed logging of events that may concern network administrators. The first rule detects when the firewall is pinged, and the second rule detects when someone is attempting a traceroute through the firewall.

Working with configurations
The EFS administration software allows a network administrator to create multiple profiles of rules that are referred to as "configurations." Each configuration is an independent profile, but all configurations are constructed from the same basic building blocks of addresses, services, and actions.

The management of configurations is done via the Web interface. The configurations page of the Web interface tool will display a list of all the configurations that have been created and the date of their creation. It will also indicate the currently active configuration and the date it was activated. Each configuration is displayed as a hypertext link, and clicking on a link will produce a compilation and activation page for the given configuration. EFS actually uses a rules language for the expression of rules, and each configuration expressed in this language must be compiled. The compilation and activation page will display the results of a compilation (including the dreaded compilation errors if you should be so unlucky as to make a mistake while entering a rule). After a successful compilation the configuration can be activated.

It is important to note that configurations do not take effect until they are compiled and explicitly activated. This gives the network administrator the flexibility of building, compiling, and debugging configurations offline so as not to disturb the current configuration. Also, an administrator can easily switch between firewall configurations, an especially useful feature if a new configuration does not behave as expected.

The example configuration page shown below shows a sequence of configurations beginning with an initial configuration (automatically created during the EFS installation procedure), followed by two test configurations, followed by a final production configuration that is also the active configuration.

Click image for larger version (28 K).

The final analysis
Overall, SunScreen EFS is a cost-effective, software-based packet filtering firewall product that can fit nicely into a multiple-level security architecture. The secure remote administration feature makes management of the firewall more convenient, as does the Web interface for performing all the non-rule administration. Additionally, the SNMP trap support allows EFS to integrate well into an existing SNMP network management environment. The advanced feature of SKIP-based data encryption allows a network administrator to build secure maintenance/configuration channels to public servers and create dynamic outbound encrypted tunnels for secure transmission of data over the Internet.

Potential areas of improvement for SunScreen EFS include better handling and propagation of address modifications, a more integrated Web-based approach to defining and editing rules, and proxy support for the most common user services such as WWW, e-mail, FTP, and telnet. (Proxy support is planned for the next major release.) I also renew my plea for Sun (and other network security vendors) to provide better documentation with their products. Security is a complex technology, and providing high-quality documentation to accompany products and provide conceptual explanations, suggested implementations, and procedures for troubleshooting would go a long way toward helping the embattled administrator on the front lines of network and system security.

Resources

For information pertaining to the SKIP protocol http://skip.incog.com/
For information on Sun's network security solutions, including SunScreen EFS http://www.sun.com/security/
For a comprehensive list of resources related to firewall technology http://www.cs.purdue.edu/coast/firewalls/
For an overview of the definitive textbook on building firewalls http://www.greatcircle.com/firewalls-book/
Sun white paper on deploying SunScreen EFS http://www.sun.com/security/wp-deploying.efs/
"SKIP your way to security," June 1997 SunWorld feature story http://www.sun.com/sunworldonline/swol-06-1997/swol-06-skip.html

About the author
Ken Masica is an electrical engineer specializing in the areas of network design, simulation, and security. Reach Ken at ken.masica@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-01-1998/swol-01-efs.html
Last modified:

Comments:
Name:
Email:
Company Name: