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.
-
The original packet is encapsulated inside a new IP packet for transmission over the Internet.
-
A SKIP header is added so that the receiver can decrypt the packet.
-
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
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
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.
- © 2010, Oracle Corporation and/or its affiliates