test

SunScreen EFS Release 3.0 Reference Manual

Chapter 2 SunScreen EFS 3.0 Concepts

This chapter describes the SunScreen EFS 3.0 concepts:

Security Considerations

A company's assets are at risk when it connects to the Internet. It might want to provide Internet services for customers and other users of the Internet, while allowing its employees to connect to the Internet for services or access to corporate information.

SunScreen EFS 3.0 divides the world into discrete areas, each served by an interface. You set up filtering rules to control the access to one area from another area, which can be another network within your company or an area outside your company.

The following figure shows a sample map of a simple network in which a Screen in routing mode functions as a firewall and router to connect the Engineering network over an unsecured public network (the Internet) through a Screen in stealth mode to other secure networks.

Figure 2-1 Sample Network Map

Graphic

The ftp-www server might be the "public" area of the company, also called the demilitarized zone (DMZ), and the engineering, sales, and corporate network segments might be part of the "private" area. SunScreen EFS 3.0 can then control access between these areas and the rest of the Internet.

A security policy is the collection of decisions an organization makes about network security and its stance regarding what network activities are permitted or denied. The most important aspect in installing and administering a firewall is a well-defined security policy.

When defining your security policy, consider the following factors:

A security policy is a protective device; therefore, it is necessary to determine what you are trying to protect and from whom. Once you have identified your security requirements for protecting the integrity and accessibility of your corporate data and computer resources, determine what services you want to support at your site for employees and customers.

To help determine your requirements, use the following questions:

Once you have determined the answers to these and any other site-specific security issues, you are ready to plan your SunScreen EFS 3.0 configuration.

Policy rules are used to control access to your computer network and to control encryption for access to your data. By default, SunScreen EFS 3.0 drops any packets that do not specifically match a rule. This makes it easier to create rules, since you only have to write a rule for the services you want to pass.

To prepare to implement policy rules, you must:

See the SunScreen EFS 3.0 Administration Guide for worksheets to assist you in gathering the information you need for setting up your security policy.

Define Screen's Name Properly

SunScreen EFS 3.0 automatically chooses a name for each Screen based on the hostname setting output by uname -n. There are various situations in which this name is used as an IP host name (IP address) for remote administration and centralized management groups.

Therefore, it is necessary for each Screen's name to be defined as a valid IP address for that Screen. The definition must be accessible through /etc/hosts, NIS or DNS on every remote administration station as well as every Screen in a centralized management group.

How SunScreen EFS 3.0 Works

SunScreen EFS 3.0 is a Solaris software product supporting Solaris 2.6 and Solaris 7 for both SPARC and X86 systems.

Note -

Upgrade your system to at least Solaris 2.6, as SunScreen EFS 3.0 cannot support Solaris 2.5.1 due to Unicode internationalization requirements.

The administration GUI software works on any hardware or software system with a browser that supports JDK 1.1 (>= 1.1.3) and has End-system SKIP installed.

Integration of the two SunScreen firewall products in SunScreen EFS 3.0 allows you to create a stealth-mode firewall as a dedicated perimeter defense and extranet firewall, or a routing-mode firewall as a traditional firewall on the perimeter of a network or a remote-access server inside the intranet to segregate departments, or deployed on an existing application or data server throughout an enterprise to control access and provide encryption.

SunScreen EFS 3.0 and SunScreen SKIP use graphical user interfaces called:

See the SunScreen SKIP 1.5 User's Guide regarding the skiptool GUI.

The installation wizard allows you to configure your Screen in routing mode, which is the default, or in stealth mode. Following installation, use the administration GUI to administer your Screen locally on the same machine or remotely from an Administration Station. Use the skiptool GUI to encrypt administration commands that travel from the Administration Station over a potentially insecure network to the Screen.

Note -

For backwards compatibility, installation for SunScreen EFS 3.0 retains the ss_install command.

The ssadm sub-command edit, which invokes the configuration editor, maintains the SunScreen EFS 3.0 configuration database.

A configuration is the union of one policy with the common objects to form a complete description of the behavior of one or more Screens. A policy is a named set of policy objects. For example, when the SunScreen EFS 3.0 software is first installed, there is one policy, named "Initial." Common objects are data objects relevant to all policies. Object types are either named or ordered. Named common object types include Address, Screen, State Engine, Service, Interface, Certificate, and Time objects. Ordered policy object types include filtering rules, NAT rules, administration access rules, and VPN gateway descriptions. Neither common objects nor policy objects include objects loaded into SKIP but they do include the reference from the Certificate name in the common object registry to the internal identity used by SKIP.

The centralized management group feature allows Screens located at different points in the network to be managed with a standard set of objects through an Administration Station.

The high availability (HA) cluster feature allows groups of Screens to be deployed for failover protection. One member of the HA cluster, the active Screen, services packets travelling between a protected inside network and a nonsecure outside network. Other members, the passive Screens, receive the same packets, perform the same calculations, and mirror the state of the active Screen, but they do not forward traffic between the inside network and the outside network. When an active Screen fails, the passive Screen that has been running the longest takes over as the active Screen within 15 seconds. During this time (before the passive Screen takes over), no traffic will go through the HA cluster.

The network address translation (NAT) feature enables a Screen to map an internal network address to a different network address. As it passes packets between an internal host and a public network, the addresses in the packet are replaced with new addresses transparently, checksums and sequence numbers are corrected, and the state of the address map is monitored. You specify when a packet using ordered NAT is applied based on source and destination addresses.

Individual versions of a policy are copied or saved into a new policy. Each version of a policy is maintained and you can use either all or a portion of a policy at a later date.

How SunScreen EFS 3.0 Uses Encryption

SunScreen EFS 3.0 uses a combination of public-key and shared-key cryptography to encrypt and decrypt packets. Any traffic that passes between any two machines or other SKIP devices can be encrypted, while all traffic between a Screen and an Administration Station is encrypted.

When the rules and policies determine that a specific packet should be encrypted, the new packet is first checked to see if it is too large to send on.

Encrypted packets are larger than the original packet for three reasons.

  1. The original packet is encapsulated inside a new IP packet for transmission over the Internet.

  2. A SKIP header is added so that the receiver can decrypt the packet.

  3. The encryption process requires some padding of the original data.

If the new packet is too large to send on, and the original packet carries the "Don't Fragment" bit, then a message is sent back to the sender requesting a smaller packet (ICMP Fragmentation needed but Don't-Fragment bit set). If the new packet is too large and fragmentation is allowed, the original packet is first fragmented and then encrypted. This allows the other end of the encryption tunnel to decrypt each fragment independently.

The encryption routine builds a new IP packet to carry the original data. It uses the original source and destination addresses or, if tunnelling is specified, the tunnel source and destination addresses.

After a new packet is created, the original packet is encrypted using the specified encryption mechanism (DES, RC2, or RC4) and a randomly generated traffic key. The traffic key is then encrypted using the specified encryption mechanism (DES or RC2) and a key encrypting key acquired from the SKIP key manager. The new IP header, SKIP header, and encrypted data are concatenated together to form the new IP packet, which is sent on to the destination addresses.

Note -

Due to a limitation in SunScreen SKIP 1.5 for Solaris, the RC2 encryption algorithm is not available when running Solaris 7 in 64-bit mode.

When an encrypted packet is received it is passed to the decryptor. By examining the SKIP header, it determines the correct decryption mechanisms for both the encrypted traffic key (DES or RC2) and the encrypted data (DES, RC2, or RC4). It retrieves the traffic encrypting key from the key manager. It then decrypts the traffic key and in turn decrypts the original IP packet.

Finally, the decrypted packet is sent through the rules or policies to determine the action to be taken on the packet (for example, whether the decrypted packet should be passed or dropped).

SunScreen EFS 3.0 uses encryption in a feature called tunneling that is used to hide actual source and destination addresses. In this feature, you can substitute the addresses on the packet header with other addresses. When the SunScreen EFS 3.0 encrypts a packet, it replaces the packet's source address with the (optional) tunnel address of the From Encryptor and replaces the packet's destination address with the (optional) tunnel address of the To Encryptor. When the SunScreen EFS 3.0 encrypts a packet, the original addresses are restored.

Note -

SunScreen EFS 3.0 incorporates cryptography at the network (IP) layer to provide privacy and authentication over unsecure public networks, such as the Internet. See the SunScreen SKIP 1.5 User's Guide for full descriptions of these and the Certification Authority (CA) issued keys and certificates.

Remote and Local Administration

SunScreen EFS 3.0 consists of two components: a Screen and an Administration Station. The two components can be installed on a Screen and a remote Administration Station, or they can be installed locally on a single machine.

The number of Screens and Administration Stations needed at a site depends on its network topology and security policies. Typically, one Screen is installed at each network direct public access location that needs to be restricted. One or more Administration Stations can manage multiple Screens.

A machine that is being administered remotely can be headless (no monitor) and have no keyboard. You typically choose whether to administer a Screen locally or remotely when you install the SunScreen EFS 3.0 software. You can add a remote Administration Station after the Screen software has been installed.

Remote Administration

Remote administration from an Administration Station to the Screen, installs the software packages, including SunScreen SKIP, on separate machines, as shown in FIGURE 2-2. Because administration commands travel from the Administration Station to the Screen over a potentially insecure network, commands are encrypted using SunScreen SKIP.

Figure 2-2 Remote Administration From an Administration Station to a Screen in Routing Mode

Graphic

In FIGURE 2-2, a remote Administration Station on the internal network administers the Screen located between the internal network and the Internet. This Screen is the router between the internal network and the Internet. A second remote Administration Station for this Screen is located on the external network. Either Administration Station can be configured to communicate with the Screen using encryption.

Local Administration

Local administration is performed on the same host where the Screen software is installed, as shown in FIGURE 2-3. Because administrative commands do not travel over a network, local administration does not require encrypted communication.

Figure 2-3 Local Administration of a Screen in Routing Mode

Graphic

Centralized Management of Firewall Groups

Groups of Screens deployed throughout the world are managed with a set of configuration objects through an Administration Station. Policy objects reside on a specific Screen called the centralized management group's primary Screen. As in prior releases of SunScreen firewall product lines, Screens can be managed by many Administration Stations.

The centralized management group's primary Screen, where all configuration objects reside, manages the centralized management group's secondary Screens. centralized management group secondary Screens allow basic emergency administration capabilities; for example, if the primary Screen is down for service. Although there is no central logging mechanism for a global view of the logs on the individual Screens in a centralized management group, you can select a specific Screen and view its log.

Common objects are named objects, like address, screen, state engine, service, interface, certificate, and time. Policy objects are ordered filtering rules, NAT rules, administrative access rules, and VPN gateway descriptions. Neither common objects nor policy objects include objects loaded into SKIP but they do include the reference from the Certificate name in the common object registry to the internal identity used by SKIP.

Setting up rules for the entire centralized management group of Screens is done through the administration GUI.

Setting Up Access Control

Access control determines which users and Administration Stations can administer the Screen. You choose local or remote administration by selecting the Administrative Access tab in the Policy Rules area of the administration GUI. The "Access Rules for GUI Local Administration" table under local administration lists rule No, Screen, User, Access Level, and Description.

You can use the configuration editor's syntax through the command-line interface (see Appendix B for command line reference) to specify which machines on your network can administer a Screen as well. The configuration editor is the primary command-line tool for creating and manipulating the data objects that control the operation of a Screen.

Policy Versions

Each version of a policy has an associated version number. Edited policies automatically generate historical version numbers. Version numbering is implemented through the administration GUI using the edit sub-command of ssadm, which allows you to create new policy object files by name.

When a particular policy is superseded by a new version of that policy, the older version includes the policy object-specific information and the actual content of the common object registry instead of just a reference. Although you may find that the older policy version has become invalid due to changes that occurred in the network and hardware topology, it can be more consistent.

Routing and Stealth Modes

SunScreen EFS 3.0 includes stealth-mode capabilities and routing-mode capabilities.

Routing Mode

Routing-mode interfaces have IP addresses and perform IP routing. Routing mode requires that you connect each interface to a different network with its own network number.

All proxies are accessed through the transmission control protocol (TCP), and therefore can only run on systems configured in routing mode.

Stealth Mode

Stealth-mode offers optional hardening of the OS, which removes packages and files from the Solaris operating system that are not used by SunScreen EFS 3.0. Stealth-mode requires the Screen to partition a single network.

Stealth mode firewall partitions an existing network and, consequently, does not require you to sub-net the network. Stealth-mode interfaces do not have IP addresses, and do MAC-layer bridging.

In stealth mode, SunScreen EFS 3.0 is similar to the SunScreen SPF-200 product; however, it differs from it in the following ways:

If you configure a network interface that you later set to Stealth mode, the Screen will hang upon activation. If this happens, you must reboot the Screen in single-user mode, then remove the /etc/hostname.interface_name file (which unconfigures that interface), and reboot the Screen again.

If you accidentally misconfigure the system in this way, here is the procedure for restoring proper operation:

  1. Type control-C a few times to break out and send your machine into single-user mode.

  2. After typing your root password, you must type the following to remount the root partition read-write:


    # mount -o remount /# ls /etc/hostname*/etc/hostname.hme0  /etc/hostname.qfe2

The qfe2 interface is the admin interface in this example.

Note -

Do not disturb your admin interface, as it must be the only hostname interface file in the /etc directory.

As the example shows, the problem is the existence of a hme0 interface file.

  1. To rename or remove the problem hostname interface file, type:


    # mv /etc/hostname.hme0 /etc/hostname.hme0.old

  2. Reboot the machine.


    Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi
270MHz), No Keyboard

OpenBoot 3.11, 128 MB memory installed, Serial #10411258.

Ethernet address 8:0:20:9e:dc:fa, Host ID: 809edcfa.

Rebooting with command: boot 

Boot device: disk:a  File and args: kadb

kadb: kernel/sparcv9/unix

Size: 314284+93248+121472 Bytes

/platform/sun4u/kernel/sparcv9/unix loaded - 0xca000 bytes used

SunOS Release 5.7 Version Generic 64-bit [UNIX(R) System
V Release 4.0]

Copyright (c) 1983-1998, Sun Microsystems, Inc.

plumbing SunScreen network interfaces:^C

INIT: Cannot create /var/adm/utmp or /var/adm/utmpx

INIT: failed write of utmpx entry:"  "

INIT: failed write of utmpx entry:"  "

INIT: SINGLE USER MODE

Type Ctrl-d to proceed with normal startup, (or give root password for
system maintenance): 

Entering System Maintenance Mode

May  5 17:10:04 su: 'su root' succeeded for root on /dev/syscon

Sun Microsystems Inc.   SunOS 5.7       Generic October 1998

# mount -o remount /

# ls /etc/hostname*

/etc/hostname.hme0  /etc/hostname.qfe2

# mv /etc/hostname.hme0 /etc/hostname.hme0.old

# ls /etc/hostname*

/etc/hostname.hme0.old  /etc/hostname.qfe2
# reboot

SunScreen EFS 3.0 Functions

The sequence in which a Screen performs packet filtering, network address translation, and encryption and decryption depends on the direction in which the packets are moving, as shown in the following figure.

Figure 2-4 Rule Processing Order in a Screen

Graphic

When a host on a private (internal) network sends a packet addressed to an outside host through a Screen, the Screen does the following:

  1. The Screen applies its packet filter rules to the packet to determine whether the packet meets the criteria of an ALLOW or DENY rule. If the packet meets the criteria of a DENY rule, then the packet is denied and, if so specified, can make a log entry identifying the circumstances.

  2. If the packet meets the criteria of an ALLOW rule, the Screen determines whether it should use NAT to convert the source IP address information in the packet. If NAT is being used, the source address information in the packet is modified. Depending on the type of packet, the Screen may also modify address information in the data portion of the packet or modify packet checksums.

  3. The Screen determines if the packet should be encrypted based upon the information in the rule that matched. If the packet should be encrypted, the Screen calls the SKIP key manager, which identifies the appropriate encryption keys and algorithms and encrypts the packet. The SKIP key manager passes the encrypted packet back to the Screen, which then forwards the packet to the public network.

When a Screen receives a packet addressed to an internal host from a host on the public network, it performs a similar sequence of actions:

  1. If the incoming packet has been encrypted with the Screen's public key, the Screen calls the SKIP key manager, which identifies the appropriate keys and decrypts the packet. The SKIP key manager passes the decrypted packet back to the Screen.

  2. The Screen determines whether it should use NAT to convert the packet's destination IP address to an internal IP address. If NAT is being used, the address information in the packet is modified.

  3. The Screen applies its filtering rules to the packet to determine whether the packet meets the criteria of an ALLOW or DENY rule. If the packet meets the criteria of an ALLOW rule, the Screen forwards the packet to the internal network. If the packet meets the criteria of a DENY rule, then the packet is denied.

SunScreen EFS 3.0 Function Details

The following SunScreen EFS 3.0 functions are described in more detail:

Dynamic Packet Filtering

Dynamic packet filtering enables a Screen, which sits between the client and server, to examine each data packet as it arrives. Based on information in the packet, state retained from previous events, and a set of security policy rules, the Screen either passes the data packet, or blocks and drops it.

SunScreen EFS 3.0 uses a set of ordered rules to filter packets. When you configure SunScreen EFS 3.0, you translate the security policies for your site into a series of policy rules that specify which services are to be allowed, what to do with packets for services that are disallowed, and what to do when packets are dropped. You then place these policy rules in sequence to specify which rules override others.

When the Screen receives a packet, it tests the packet against the two certificates, the algorithms, and the rules in the order in which they are numbered. The Screen does not test each packet against each rule; it assumes that the first rule to match the service, source address, and destination address of the packet addresses is the rule that governs the disposition of the packet. Additionally, if the applicable rule so specifies, the Screen can record a log message or generate an SNMP alert.

If the packet does not match any rule, the Screen uses its default action for the interface on which the packet arrived to determine disposition of the packet. Typically, this action logs the packet and drops it, though other options are available.

Network Address Translation (NAT)

SunScreen EFS 3.0 NAT gives you fine-grain control by adding ordered NAT translations, allowing table entries to intersect, and allowing you to specify when to have NAT translate the source or destination addresses.

NAT enables a Screen to map an internal network address to a different network address. As it passes packets between an internal host and a public network, the addresses in the packet are replaced with new addresses transparently, checksums and sequence numbers are corrected in both the IP header and the TCP or UDP header, and the state of the address map is monitored. You specify when a packet using ordered NAT translations is applied based on source and destination addresses.

Note -

Be sure to configure your NAT rules to not perform address translation while an internal host is attempting to communicate directly with the Screen.

Additionally, services such as FTP also carry IP address information. These packets must also be changed, ensuring that the checksums and sequence numbers are correct. All of this is done inside the Screen's kernel to ensure high-speed processing and transparency to the end user and applications. NAT is stateful, which increases the efficiency of lookups in the address translation table by using address hashings and checksum adjustments that use differential checksum calculations.

NAT is typically used in the following situations when:

Note -

Using NAT to hide addresses differs from tunneling in that NAT does not rely on the use of encryption and decryption and consequently does not require an encryption-decryption device at each end of the connection over the public network.

NAT lets you use private or unregistered Internet addresses to number your internal networks and hosts and still maintain full connectivity to the Internet. The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

With this approach, you can use a registered Class C address space, which offers about 254 externally routable addresses, to provide connectivity for an unregistered Class B network, which supports approximately 65,000 hosts or 255 networks of 254 hosts (internally).

Static NAT

Registered addresses are necessary for advertised kinds of resources, such as publicly accessible servers on your network, because these machines must be at well-known, fixed addresses. Static NAT is frequently used to provide public access to HTTP or FTP servers that use private addresses. These servers must use static NAT reverse rules so that other hosts can use the same registered addresses to reach them, so the reverse rules must be generated by you.

Static NAT maps a specific unregistered address to a specific registered address. Static translations can also map a range of unregistered addresses to a range of registered addresses, which requires the number of addresses in each range to match.

Dynamic NAT

Dynamic NAT maps a large set of unregistered IP addresses to a smaller set of registered addresses. Dynamic NAT lets you connect a very large number of hosts to the public Internet using a limited number of registered addresses.

Unlike static NAT, which sets up a one-to-one mapping between internal private addresses and external public addresses, dynamic NAT creates a many-to-one mapping where several internal addresses use the same public address. Dynamic NAT avoids IP address conflicts by maintaining a state table that records five values (source address, source port, destination address, destination port, and protocol) for each TCP or UDP connection. When the Screen uses a public address that is already in use, it uses a different source port number, thereby making a distinction between the two connections. A Screen can multiplex many thousands of translations over a single registered address by ensuring the source ports for the connections differ.

Dynamic NAT is unidirectional, meaning that communication can be initiated only internally from the unregistered private network. Dynamic NAT only works when a user originates a connection from inside the firewall; packets from outside that are not in the address lookup table of an established connection cannot identify a host on the private network and are discarded.

NAT Examples

The following NAT examples show how to set up NAT mappings when using only one registered IP address, and shows two scenarios that illustrate how a demilitarized zone could use registered addresses or unregistered addresses with NAT.

Example One:

When you only have one registered IP address ("A") and you want to have all inbound traffic to "A" go to your Screen and have all other hosts use that address ("A") for unidirectional, outbound traffic, then set up the following NAT mappings:

Table 2-1 Example of a One-Address NAT Table Entry

Index 

Screen 

TYPE 

Source 

Destination 

Translated Source 

Translated Destination 

Comment 

1 

 

STATIC 

"*" 

"A" 

"*" 

"A" 

"" 

2 

 

DYNAMIC 

"Inside" 

"Internet" 

"A" 

"Internet" 

"" 

where "Internet" is all addresses on inbound interface "qe0" and "A"; and "Inside" is all internal hosts on all other interfaces. With only these NAT rules, all hosts in the "Inside" communicate with their private, unregistered, addresses when communicating with the Screen or among themselves.

Write your filtering rules in the context of the internal addresses.

Valid mapping combinations are:

Example Two:

Registered addresses are necessary for advertised kinds of resources, such as publicly accessible servers on your network, consequently these machines must be at well-known, fixed addresses. Because a host must have a registered address before it can communicate over public networks, either machines that host public resources must have stable registered addresses, or their internal (unregistered) addresses must translate to stable registered addresses. The following scenarios illustrate how a demilitarized zone (DMZ), an internal network with limited public access, could use registered addresses or unregistered addresses with network address translation.

Scenario 1: DMZ Uses Registered Addresses

In FIGURE 2-5, the Screen, in routing-mode, uses Q1 as its own IP address on the external network interface. It has a DMZ network with registered addresses R1 through R8 on a second interface. The Screen (Q1) and the servers in the DMZ (the FTP server (R2) and the WWW server (R3)) have routable registered addresses on the public network that allow them to communicate with any other machine with a registered address. The Screen uses the remaining registered addresses (R4 through R8) for NAT.

Figure 2-5 Scenario 1: Static and Dynamic NAT

Graphic

The Screen uses dynamic NAT to map the addresses in its unregistered address range (U2-Un) to map the remaining addresses in its registered address range (R4-R8). When an internal host with an unregistered address tries to connect to an external host with a registered address, the Screen assigns the internal host a registered address to use for the duration of the network communication session.

Scenario 2: DMZ Uses NAT Addresses

FIGURE 2-6 illustrates an organization that has a network consisting of a large number of unregistered addresses (Un) and a set of eight registered addresses (R1-R8). Hosts on the inside network must be able to communicate through the Screen with external hosts.

Figure 2-6 Scenario 2: Static and Dynamic NAT

Graphic

In FIGURE 2-6, the Screen is connected to the public network R1-R8. R1 is its IP address on the public network interface. It uses static NAT to map the unregistered DMZ addresses of the FTP server (U2) and the WWW server (U3) to the registered (public) addresses R2 and R3. The private addresses U4 through Un will be mapped dynamically to the registered addresses R4 through R8. Because the IP addresses of the servers and the internal network are translated to routable registered addresses, they can communicate with any other registered address.

In routing-mode (not needed in stealth-mode), the Screen must respond to ARP requests the public addresses (R2 through R8) because it will be translating public addresses to private addresses. You must add an arp entry (using the command arp -s IP_address ether_address pub) for them. You must either add this entry each time that you reboot the Screen or add it to the /etc/inetd.conf file. If you are remotely administering the Screen in routing mode, you either must go to the Screen to add this entry, or you must have a rule in your policy that allows you to log in remotely (rlogin) to your Screen.

The Screen uses dynamic NAT to map the addresses in its unregistered address range (U4-Un) to the remaining addresses in its registered address range (R4-R8). When an internal host with an unregistered address tries to connect to an external host with a registered address, the Screen assigns the internal host a registered address to use for the duration of the network communication session.

This scenario has the advantage that, if you change ISPs, you do not have to readdress all the hosts on your internal registered network.

Applying NAT

NAT mappings for your site are automatically applied to all packets. When packets addressed to an internal host are received from an external host, the Screen translates network address information in the packets before they are processed by the stateful packet-filtering engine. Similarly, packets travelling from an internal host to an external host are filtered before NAT takes place. This approach lets you use your internal addresses when you define filtering rules, simplifying policy management.

NAT and Mapping Collisions

Mapping collisions can cause service to be denied to a network user. Mapping collisions occur when network software cannot complete the address mapping process because two or more packets are not uniquely identified. Each packet must have a destination IP address, a destination port, source IP address, a source port, and protocol if it is to be delivered. These elements are processed as a 5-tuple of information of the form: (dest IP addr, dest port, srcaddr, src port, proto), which is part of the packet header.

A 5-tuple is unique as long as at least one of the five pieces of data that it contains differs from the others with which it is being compared. Since each piece of data has a large number of possible values, the number of possible permutations for the 5-tuple is enormous. For a mapping collision to occur, multiple internal machines using the same registered IP address must try to access the same registered address Xn at the same destination port number, and from the same source port number, all at the same time-an unlikely scenario.

Suppose a user at the unregistered address U5, shown in FIGURE 2-5, attempts to go to a Web page at the registered destination address 192.4.15.37 at destination port 80 from source port 34080 through the registered address R5. Another user at U6 can do the same to the same address and destination port through source port 34070, or go to a different Web page through source port 34080.

Table 2-2 Two Dynamic Addresses

Registered IP Address 

Destination IP Address 

Destination Port 

Source Port 

Protocol 

R4 

192.4.15.37 

80 

34080 (on U5)

tcp 

R4 

192.4.15.37 

80 

34070 (on U6)

tcp 

R4 

192.4.15.44 

80 

34080 (on U7)

tcp 

R5 

192.4.15.44 

80 

34080 (on U7)

tcp 

The following table shows a mapping of unregistered addresses, Un, to registered addresses, Rn.

If a user at unregistered address U7 attempts to go to a web page at the registered destination IP address 192.4.15.44 at destination port 80 from source port 34080 using registered address R4, a mapping collision will occur. The user at U7 would have to use another source port to have a unique 5-tuple and avoid a mapping collision, which would happen automatically during a subsequent connection attempt.

Situations such as power failures typically result in mapping collisions. When power is restored, all hosts on a network come up at the same time and try to reestablish network connections. Each host's operating system resets its source port counter to a low number. It may take time for the counters on each machine to cycle up to higher and more randomized port numbers (which are more likely to produce unique 5-tuples). In the interim, mapping collisions may cause network service to be denied temporarily. Internal hosts must continue trying to establish network connections until the NAT rules resolve the mapping collisions.

Note -

Ports 0 though 1024 are reserved for well-known port assignments and are controlled by the IANA. To avoid conflicts, the Solaris operating environment uses ports that range approximately from 32768 through 65535

High Availability (HA)

HA lets you deploy groups of Screens together in situations where the connection between a protected inside network and a nonsecure outside network is critical. At any time, one member of the HA cluster is the active Screen, which performs packet filtering, network address translation, logging, and encryption or decryption of packets travelling between the inside and outside networks. The other members of the HA cluster, the passive Screens, receive the same packets, perform the same calculations as the active Screen, and mirror the state of the active Screen, but they do not forward traffic.

HA Policy

When you set up an HA cluster, you designate one Screen as its primary HA Screen that is configured with the policy's configuration objects, including named Screen objects, like Address or Service with attributes that include these settings, and policy rules that the HA cluster will use. When you activate the security policy, the SunScreen EFS 3.0 and SunScreen SKIP policies are copied from the primary HA Screen to the secondary Screens in the HA cluster.

Solaris policy settings, such as network interfaces and routing configuration, are not copied from the primary Screen and must be identical on all the Screens in the HA cluster.

Caution - Caution -

Because the HA cluster transmits secret keys and policies in the clear over the dedicated HA network, you must keep the HA network physically secure.

The interfaces for network connections must be the same for each HA cluster member. Similarly, you must assign all HA Screens the same IP addresses on their non-dedicated interfaces as well. The following figure shows a network protected by two Screens in an HA cluster. Each Screen in the HA cluster connects to the external and internal networks through Ethernet hubs, which pass the same signals to all HA cluster members at the same time. Each HA Screen therefore sees the same traffic, ensuring that passive Screens can duplicate the state of the packet filter engine should the active Screen fail.

Figure 2-7 Network With HA Cluster of Screens

Graphic

HA Network Connections and Failovers

Note -

When the active HA cluster Screen is an x86 machine running Solaris 7, failover does not work properly. The ETHER_ADDRESS for the primary does not set correctly.

Once the HA cluster is running, the active and passive Screens poll each other every few seconds to verify connectivity and status. If the active Screen fails or becomes unavailable, the passive Screen that has been running the longest takes over as the active Screen within 15 seconds. During this time (before the passive Screen takes over), no traffic will go through the HA policy.

HA is designed to maintain the great majority of network connections. In the case of a reboot (an orderly shutdown), the active Screen being rebooted notifies the passive Screens, and the appropriate passive Screen takes over as the active Screen without loss of connections. Because the passive Screens do not forward, reject, or log packets, the load on passive Screens is less than the load on the active Screen. Consequently, load-induced faults that affect the active Screen are unlikely to affect the passive Screens.

If a failover occurs, these connections may be disrupted:

These connections may be lost if one of the following conditions occurs:

HA automatically disconnects if it is only running on one machine, allowing it to act like a standard SunScreen EFS 3.0 Screen.

You choose to configure SunScreen EFS 3.0 as an HA cluster during installation. Alternatively, you can configure HA settings through the command line, as described in Appendix B, "Command Line Reference."

HA Alerts

Note the following HA limitations:

It is not necessary to switch back to the original Screen except when its abilities or speeds are better. If they are, you can force the faster machine to take over as the active Screen, or wait until both machines have the same state because eventually the out-of-sync connections will timeout and become synchronized, then force the failover.

Time-Based Rules

Time-based rules are time objects that are specified using a 24-hour clock in 5-minute increments. They allow you to set a policy's time-of-day, day-of-week, and so forth, rules. For instance, you may want to allow telnet but only during regular business hours, or after hours, or outside certain hours.

The policy rule default setting is ANY time, which applies the rule at all times like in prior SunScreen firewall releases. You can set a few time-based policy rules that reference the same set of hours, or you can specify specific hours covered in a specific day such as Monday to Friday, 9 a.m. to 5 p.m., local time.

Time is always interpreted as the Screen's time zone, which requires that you either have Screen-specific Time definitions to coordinate traffic between the Screens in different time zones, or have distinctly-named Time objects and Screen-specific rules.

Note -

Although you can define many Time objects, only 31 distinct Time objects can be in actual use on any given Screen.

For example, Los Angles (LA) and New York (NY) have a three hour difference. If you only want the two sites to communicate when they are both within "regular" hours (that is, 8am to 5pm), then NY is available to communicate to LA between 11am and 5pm, and LA is available to communicate to NY between 8am and 2pm.

A down-side to this is that during hours that do not overlap, one of the two Screens allows traffic through while the other will not. So, early in the morning the NY Screen allows traffic through, but it is blocked by the LA Screen. Similarly, in the afternoon, the LA Screen is blocked by the NY Screen.

Case 1: Screen-Specific Time Objects

Name 

Screen 

Value 

regular  

NY 

MONDAY { 11:00 17:00 } TUESDAY { 11:00 17:00 } ... 

regular 

LA 

MONDAY { 08:00 14:00 } TUESDAY { 08:00 14:00 } ... 

Set the rules by typing:


telnet LA NY TIME regular ALLOW
telnet NY LA TIME regular ALLOW

Case 2: Distinctly-Named Time Objects

Name 

Value 

ny-business  

MONDAY { 11:00 17:00 } TUESDAY { 11:00 17:00 } ... 

la-business 

MONDAY { 08:00 14:00 } TUESDAY { 08:00 14:00 } ... 

Set the rules by typing:


SCREEN LA telnet LA NY TIME la-business ALLOW
SCREEN LA telnet NY LA TIME la-business ALLOW
SCREEN NY telnet LA NY TIME la-business ALLOW
SCREEN NY telnet NY LA TIME la-business ALLOW

User Authentication

SunScreen EFS 3.0 allows you to configure user entities to authenticate individual administrators and to allow access through the firewall when using proxied services.

Authentication allows you to verify the identity of both internal and external users based on user name and a simple text password, or on a user name and SecurID\256 token passcode, or both.

Proxies provide a means to validate, regulate, and extend the abilities of certain services beyond those afforded by kernel-based stateful packet filtering. (See Chapter 5, "Proxies," for more information regarding user authentication.)

SunScreen EFS 3.0 provides two distinct levels of user identification: Authorized User, through the authuser database, and Proxy User, through the proxyuser database.

Authorized Users

Authorized User is a named common object that describes an individual administrative user who is distinct from all others. The attributes provide a repository for demographic and authentication data about that individual.

Access to and use of the administrative GUI functions require that you establish the Authorized User identity before administration is allowed. Both the administration GUI Login screen and the login sub-command of the ssadm command line facility reference an Authorized User object.

Note -

Authorized User authenticity establishes only the identity of an individual administrator, not the various roles they may play while using SunScreen EFS 3.0. Role establishment is afforded in one of two ways: (1) reference within the User field in the administrative access rules of a policy, (2) reference from a packet filtering rule that utilizes user authentication (proxies).

Proxy Users

Proxy User is a named common object distinct from the Authorized User. Proxy Users are either SIMPLE or GROUP objects. SIMPLE objects are used to provide for and establish an association between an individual administrator and the role they play in usage of the facilities controlled by SunScreen EFS 3.0. GROUP objects are used to allow creation of groups of SIMPLE Proxy Users that share common access to facilities. Thus, GROUPs streamline the task of allowing or removing access to established facilities.

Some special Proxy User objects also provide the means to map external collections of users into the SunScreen EFS 3.0 access control facilities. SunScreen EFS 3.0 provides external access to SecurID and RADIUS users. (Access to other external user databases is afforded using RADIUS as an intermediary agent. For example, access to LDAP user databases stored through Sun Directory Services (SDS) are accessible through RADIUS.)

The following diagram summarizes the relationship between Rules, Authorized Users, Proxy Users, and external user databases:

Graphic

Authorized Users and Proxy Users names are distinct, and you can have objects with identical names in each. Choose a naming strategy for each set that best reflects the naming systems already employed. For example, you can choose to name Authorized Users by employee identities, like distinguished names or employee numbers, and Proxy Users by names that reflect their normal user login names deployed on server systems (for example: Unix login name).

Note -

Names cannot contain any of the following characters: "!", "#", "$", "%", "^", "&", "*", "{", "}", "[", "]", "<", ">", """, "', "?", "`", "/", "@", or NUL characters.

Space, tab, and other whitespace characters are allowed in names, but in doing so you should be prepared to supply quotation marks in some situations in order to protect such whitespace within names.

Names of Authorized Users, Proxy Users, and other user naming items are often deliberately chosen to be different for purposes of clarity.

Event Logging With Proxies

Event logging (failure and success, including subsystem authentication) through the log browser supports filtering and ordering capabilities to define and store named filtering and sorting macros. The size of the log is configurable. The log collection facility allows the proxies to add information to the current log. The types of logged events are extensible to anticipate the evolving use of this facility. Filtering and ordering automates uploading, storage, and post-processing of logs. You can create post-processing of your choice of uploaded logs (for instance, analysis and compression).

Encryption and Decryption

Encryption is the process by which a readable message is converted to an unreadable form to prevent unauthorized parties from reading it. Decryption is the process of converting an encrypted message back to its original (readable) format. The original message is called the plaintext message. The encrypted message is called the ciphertext message.

Digital encryption algorithms work by manipulating the content of a plaintext message mathematically, using an encryption algorithm and a digital key to produce a ciphertext version of the message. The sender and recipient can communicate securely if the sender and recipient are the only ones who know the key.

Encryption is important to SunScreen EFS 3.0 because it provides a mechanism for protecting the privacy of communications and authenticating the identities of the sender and receiver. Without encryption, you would have to define packet screen rules broadly: "all the machines on the Internet" and "all the machines on the inside." Encryption technology lets you authenticate machines and users. As a result, you can define rules that control access by specific cryptographic identities rather than by general IP addresses.

SunScreen EFS 3.0 uses the SunScreen Simple Key-Management for Internet Protocols (SKIP) as the basis for its encryption technology. SKIP provides secure, encrypted communication between a remote Administration Station and the Screen and between a Screen and a remote SKIP host.

For detailed information on how SKIP encryption works, refer to the SunScreen SKIP 1.5 User's Guide.

Address Management

SunScreen EFS 3.0 identifies network elements--networks, subnetworks, and individual hosts--by mapping a named address object to one or more IP addresses. SunScreen EFS 3.0 uses address objects to define the network elements that make up the policy. These address objects are then used in defining SunScreen EFS 3.0's network interfaces and as the source and destination addresses for rules and for NAT. An address object can represent a single computer or a whole network. You can gather address objects representing individual and network addresses together to form address groups. SunScreen EFS 3.0 lets you define address objects that specifically include or exclude other address objects (single IP hosts, ranges of contiguous IP addresses, or groups of discontiguous IP addresses).

Individual IP Addresses

SunScreen EFS 3.0 identifies an individual host by linking its unique IP address to an address object, which can use the name or IP address of the host or some other identifier. FIGURE 2-8 shows an example of a host identified by its IP address (172.16.1.1).

Figure 2-8 Single Host Address

Graphic

Address Ranges

An address range is a set of numerically contiguous IP addresses. Networks and subnetworks are typically identified by an IP address range name. You use the beginning and ending addresses to identify an IP address range,

You can set up an address object to represent an address range in SunScreen EFS 3.0. FIGURE 2-9 shows examples of ranges of addresses for the Corporate and Sales networks. For example, the Corporate address object is defined as a range of addresses from 172.16.3.2 to 172.16.3.255. You could then establish access or encryption rules for hosts on the Corporate network by indicating the rule applies to the Corporate address object.

Figure 2-9 Examples of IP Address Ranges

Graphic

Address Groups

An address group is a collection of host addresses, address ranges, and other address groups. After you set up an address group, you can use it to identify multiple hosts as a single element. You can define groups in terms of the addresses they include ("Address group A consists of the IP address 1.2.3.4 and the members of address group B"), the addresses they exclude ("Address group C consists of all the hosts on the 192.4.5.0 network except 192.4.5.5 and 192.4.5.9"), or both. Address groups cannot be self-referential; that is, you cannot include address group X as a member of address group Y and then define address group Y as a member of address group X.

Note -

There are two addresses you cannot modify: localhost, which is the IP address(es) of the actual SunScreen, and "*", which represents all IP addresses.

The value is determined by first, all Addresses are included, which means that all the IP addresses contained in any of them are added to the Address Group. Next, all IP addresses of all the Addresses that are excluded are removed from the Address group. You cannot control the order in which the IP addresses are added or removed, as all includes are done before all excludes.

Designing an Addressing Scheme

You can take several steps when creating address objects to simplify maintenance of your security policies. When you are planning your addressing scheme, choose interface names that describe which addresses are on that interface or that reflect the names of the interfaces. Make naming conventions meaningful and consistent so that maintenance and daily administration are uneventful.

A network interface is a network connection coming into a Screen through which one or more IP addresses are accessible. These IP addresses need to be identified to SunScreen EFS 3.0 so that IP spoofing can be detected and prevented.

The easiest way to define address objects for network interfaces is to define an address group for each network interface. You can choose names that identify which addresses are on that network interface (such as, Corporate, Sales, ftp-www, and Internet) or names that identify the interfaces by type (such as le0 or qe0).

In most cases, one interface usually has the majority of addresses on it. For example, the Internet network interface (qe0) in the network illustrated in the figure, has the most addresses, since it is the interface for all addresses except those in the Corp, ftp-www, and Sales networks.

Figure 2-10 SunScreen EFS 3.0 as Internet Firewall

Graphic

Rather than enumerating all the addresses for the Internet, you can define the address group for the Internet address object to includes all network addresses ("*") and then exclude those that you do not want to be part of that address. In the example shown in the figure, you would define the Internet address object as an address group that includes all addresses except Corp, Sales, and ftp-www. You would then define which hosts, networks, or address groups are members of the Corp, Sales, and ftp-www addresses to exclude them from the Internet address group.

Services and Service Groups

SunScreen EFS 3.0 is shipped with a number of predefined network services, such as ftp, telnet, dns, and rsh. You can modify these services or define new services as needed.

Note -

A well-defined service must not include two entries for the same port with different attributes, such as two different filters for the same port but with different state engines, or the same state engine but with different parameters set.

Standard Services

Part of setting up your network security policy is to define what network services will be available to hosts on your internal network and to hosts on the external network. Generally, most sites need to determine or set up rules that govern the basic services.

Besides the basic services, every TCP/IP implementation provides services such as echo, discard, daytime, chargen, and time. For services such as ftp, you may want to allow anyone in the internal corporate network to send outbound traffic, but only allow inbound traffic in this protocol to go to the FTP server. This requires two rules: one for the outbound traffic and one for the inbound traffic going to the public server.

Each service uses a state engine, a sort of protocol checker. For example, the FTP state engine checks port numbers when the ftp service is being used. For more information on state engines, see Appendix B, "Services and State Engines."

Table C-1 in Appendix C, "Services and State Engines," lists the single services in SunScreen EFS 3.0, along with the state engine and discriminator (port, RPC program number, or type). Parameters (state engine modifiers, such as timeouts) and BROADCAST are indicated where applicable.

Modifying or Creating New Services

You can modify or define existing services or define new services as needed. Each service must use a predefined state engine. When you define a new service, you must specify a state engine for the new service to use and identify the various discriminators and parameters appropriate for that state engine.

Before you can define a new network service, you need to identify how the new service will work:

For example, if you have an FTP implementation that uses port 45 for its control port and port 44 for data, you could define a new FTP service called ftp-45. Refer to Appendix B, "Services and State Engines," for more information on state engines, their discriminators, and their parameters.

You can specify state engines as filters for both the forward and the reverse direction. The forward filters apply when traffic originates from the From Address and goes to the To Address in a rule. The reverse filters apply to traffic originating from a machine in the To Address going to the From Address of a rule.

Normally, rules for stateful services do not have reverse filtering rules. For instance, an FTP connection always gets established in the forward direction, and the returning traffic is handled by a state-table entry created when the connection is initiated. Reverse filtering rules are mostly valuable when you want to allow nonstateful traffic to return. An example is the nlm rule, which uses the nonstateful ICMP filter engine. It allows network lock manager (nlm) requests (ICMP type 8) in the forward direction and nlm replies (ICMP type 0) in the reverse direction.

State engines' discriminators can optionally be tagged with a BROADCAST attribute. When BROADCAST is specified for a service, the rules where the service is used allow communication to broadcast and multicast addresses. If you also want the service to work for non-broadcast addresses, you must include a filter line both with and without BROADCAST selected.

Service Groups

You can group network services together to apply a single rule to multiple network services. This group is called a Service Group. Table C-1 in Appendix C, "Services and State Engines," shows the predefined Service Groups in SunScreen EFS 3.0 and the services each includes. Not every service is included in a service group.

You can create additional service groups using any combination of the individual network services. A useful group to define might be an "internet services" group, consisting of public services, such as FTP, email, and WWW.

Policy Rules

Policy rules are based on sets of ordered policy rules. You set up these rules to reflect the security policy for your site. These rules specify the action to be taken for services between two addresses that are on different interfaces of the Screen.

When you install the SunScreen EFS 3.0 software, you start with a policy object called Initial that establishes access rules for basic TCP/IP services. You then define policy rules to allow clear or encrypted communication between hosts that meet your criteria.

Each rule must specify all three selection criteria: source address, destination address, and type of service. Each rule can also specify what action to take if a packet meets those criteria. For example, different rules will specify whether the Screen should forward or drop the packet; encrypt or decrypt the packet; record the packet in the Screen logs; and issue ICMP messages or SNMP traps concerning the packet. The default rule is to drop any packet that does not have a specific Encryption or Allow action.

The sequence in which rules are ordered is critically important. When the Screen processes packets, it compares the packet information to each rule in the order it occurs in the Screen's active policy. When a packet meets the criteria of a rule, the Screen applies the actions specified for that rule and disregards the following rules.

You can use the administration GUI or the command line (see Appendix B) to set up the table of ordered rules for a policy, which allows you to edit rule components, such as source and destination addresses, directly. You can change the order of the rules by dragging and dropping them through the configuration editor.

Rule Syntax

The basic syntax for a rule is:


Service Source_address Destination_address optional_Time optional_Encryption "action" optional_Proxy

where:

Encryption works as follows:

Example of a Rule Configuration

The XYZ Company wants to set up a series of rules to implement the following security policies:

  1. Allow telnet traffic from A (an address object representing an individual host) to B (an address object representing any host on a specified network).

  2. Deny and log mail traffic between A and B.

  3. Send a NET_UNREACHABLE ICMP rejection messages for rejected telnet traffic.

  4. Discard all other packets.

TABLE 2-2 illustrates the rules the XYZ Company would set up to implement this security policy. Note that the default action would be specified as DENY for each interface to implement policy 4.

Table 2-3 Sample Rules Table

Service 

From 

To 

Rule Type 

Log 

SNMP 

ICMP 

telnet 

A 

B 

Allow 

NONE 

NONE 

NONE 

mail 

A 

B 

Deny 

SUMMARY 

NONE 

NONE 

mail 

B 

A 

Deny 

SUMMARY 

NONE 

NONE 

telnet 

* 

* 

Deny 

NONE 

NONE 

NET_UNREACHABLE 

Tunneling and VPNs

Organizations typically have offices in more than one location. SunScreen EFS 3.0 provides a tunneling mechanism to let the different offices use public networks as a secure private network without needing dedicated lines and with no changes to user applications.

Note -

When editing multiple rules with ENCRYPT as the ACTION value, the tunnel address settings of the first rule you edit is copied into the next rule you edit. Use the command-line interface to modify the tunnel address settings of these rules.

When a tunnel, or virtual private network, is set up between two locations, all data packets traveling from one location to the other are encrypted and encapsulated inside other packets before they are sent over the public internetwork. Encrypting the packets guarantees that their contents will remain private; anyone capturing packets to snoop on network traffic between the two locations will be unable to read them. When the packets arrive at the remote location, they are decapsulated, decrypted, and forwarded to their intended destination.

In addition to protecting the privacy of network traffic, tunneling also lets a site conceal the details of its network topology from intruders or eavesdroppers. Because the original packets are encrypted, the source and destination addresses in their IP headers cannot be read. When the encrypted packets are encapsulated inside other packets, the new IP headers identify the addresses of the Screens that protect the locations, not the hosts that originated the packets. Consequently, the network topology behind the Screens is never exposed.

Note -

When using encryption with tunneling in 64-bit mode, the destination address is incorrectly translated. 32-bit machines are unaffected. To set a 64-bit installed machine to boot in 32-bit mode, go into firmware (the "ok" prompt) and set the boot file to kernel/unix, by typing: ok setenv boot-file kernel/unix.

FIGURE 2-11 illustrates how tunneling affects the outside IP header of a packet traveling from Host A to Host B. Note that the encrypted packet containing the original data Host A sent to Host B is the same whether or not tunneling is used.

Figure 2-11 Effect of Tunneling on Contents of IP Headers

Graphic

If you do not use a virtual private network (a tunnel) to transfer data between the two locations, the source and destination addresses on the outer IP header are the same as the source and destination addresses on the inner (encrypted) IP header: 1.1.1.10 and 2.2.2.10, respectively. Someone intercepting this packet would not be able to read its contents but could determine that hosts with IP addresses 1.1.1.10 and 2.2.2.10 reside behind the Screens protecting the two locations.

If you use a virtual private network to transfer data between the two locations, the Screen protecting Host A substitutes the IP address of its external interface (1.1.1.1) for the IP address of host A (1.1.1.10) in the Source Address field of the external IP header. Similarly, it substitutes the external IP address of the Screen at the other end of the tunnel (2.2.2.1) for the IP address of Host B in the Destination field. The local Screen then sends the packet through the nonsecure public network to the remote Screen.

When the remote Screen receives the packet, it strips off the encapsulation and decrypts the original packet from Host A. The remote Screen then reads the destination address from the original IP header of the decrypted packet and forwards the packet to Host B.

Note that, since the IP addresses behind the Screen are never exposed to hosts on the external Internet, the two locations do not need to assign externally valid IP addresses to hosts behind the Screens. As long as hosts behind the Screens do not need to communicate with hosts on the Internet, the two locations can use a shared IP address space, as shown in FIGURE 2-12.

Figure 2-12 Geographically Dispersed Network

Graphic