test

SunScreen 3.2 Administrator's Overview

Chapter 2 SunScreen Concepts

This chapter explains why SunScreen is important for protecting your company's proprietary information and describes how SunScreen works. It includes the following topics:

Why Use SunScreen?

Your company may want to provide Internet services for customers and others, while allowing your employees to connect to the Internet for services and for access to corporate information. However, such connections may put your company assets at risk. SunScreen protects your company's assets by inserting a firewall between them and the Internet.

A Sample SunScreen Network Map

SunScreen divides the network into discrete areas, each served by an interface. You set up filtering rules to control 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 stealth mode functions as a firewall to connect the Engineering network over an unsecured public network (the Internet) through a Screen in routing mode to other secure networks.

Figure 2-1 Sample Network Map

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 can then control access between these areas and the rest of the Internet.

See "Defining Security Policies" in SunScreen 3.2 Installation Guide for worksheets and instructions to aid you in determining your network configuration and your desired security level.

How SunScreen Works

SunScreen is a Solaris software product that supports the following platforms: Solaris 2.6, Solaris 7, and Solaris 8 and compatible versions, for both the SPARC and Intel platforms, and Trusted Solaris 8 for the SPARC platform.

Note -

Upgrade your system to at least Solaris 2.6. SunScreen cannot be used with Solaris 2.5.1 because of Unicode internationalization requirements.

For local administration, the administration GUI works on any hardware or software system with a browser that supports JDK 1.1 (up to and including 1.1.3). For remote administration, the administration GUI works on any hardware or software system with a browser that supports JDK 1.1 (up to and including 1.1.3) and SKIP or IPsec/IKE installed.

Integration of the two SunScreen firewall products--SunScreen EFS and SunScreen SPF-200--in SunScreen 3.2 enables you to create:

You can also deploy SunScreen on existing application and data servers throughout an enterprise to control access and provide encryption.

SunScreen includes the following graphical user interfaces (GUIs):

Use the install wizard to configure your Screen in routing mode (the default) or in stealth mode.

Note -

For machines without a monitor, use pkgadd to install SunScreen and ssadm configure to configure the initial configuration.

Following installation, use the administration GUI to administer your Screen locally (on the same machine) or remotely (from an Administration Station). With the administration GUI you can administer single Screens, high availability (HA) clusters, or centralized management groups (CMGs) of Screens--locally or remotely.

Note -

The skiptool GUI is not available on a SunScreen Screen; it is incompatible with SunScreen's SKIP implementation.

The behavior of a SunScreen is governed by a set of ordered rules called a policy. Individual policies and versions or histories of a policy can be copied or saved into a new policy. Each version of a policy is stored in a separate file on the (master) Screen. You can either use all of a policy or a portion of a policy at a later date.

The network address translation (NAT) feature enables the Screen to map unregistered internal network addresses to a registered network address. NAT can also map an internal network address to a different network address. As the packet passes between an internal host and a public network, it replaces the addresses in the packet with new addresses transparently, corrects the checksums and sequence numbers, and monitors the state of the address map. You specify when the ordered NAT rules apply to a packet based on source and destination addresses. Note that SunScreen performs NAT of source address before encrypting and NAT of destination address after decrypting. See Chapter 7, Network Address Translation for detailed information about NAT.

High availability (HA) protects data by using a set of Screens to provide failover protection. One member of the HA cluster, the active Screen, services packets travelling between a protected inside network and an insecure 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. One of the passive Screens automatically becomes the active Screen if the active Screen fails.

Routing and Stealth Mode Interfaces

SunScreen includes routing-mode capabilities from SunScreen EFS and stealth-mode from SunScreen SPF.

Routing Mode Interface

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

Access to all proxies is through the transmission control protocol (TCP) and can only run on Screens configured with at least one routing mode interface.

Stealth Mode Interface

A SunScreen in stealth mode bridges the MAC layer. It therefore partitions an existing single network and, consequently, does not itself divide the network into subnetworks. A stealth-mode interface does not have an associated IP address.

In stealth mode, you must configure one interface as an administration interface (to perform remote administration). This interface is special case of a routing interface that is configured so that it only passes encrypted administration traffic between the Screen and a remote Administration Station.

Hardening the OS

If all of your filtering interfaces are in stealth mode, SunScreen offers optional hardening of the OS, which removes packages and files from the Solaris operating system that are not used by SunScreen--in accordance with the best practices as described in http://www.sun.com/blueprints/browsesubject.html#security. Hardening in SunScreen 3.2 is based upon JASS (JumpStart Architecture and Security Scripts). The JASS scripts are in /usr/lib/sunscreen/admin/jass. The hardening script is /usr/lib/sunscreen/lib/harden_os. The process of hardening can be carried out at install time or at a later time by running the script.

WARNING: this script cannot be reversed; once files have been removed, the only way to recover them is to reinstall Solaris.

Note -

If some of your filtering interfaces are in stealth mode and other interfaces are in routing mode, you should not use the option of hardening of the OS that SunScreen offers.

Administration

SunScreen consists of two components: an Administration Station and a Screen. The two components can be installed on separate machines with Screen on one or more machines and another machine as a remote Administration Station, or they can be installed on a single machine for local administration of a Screen. If both components are installed on a single machine, the Administration Station can administer not only the local Screen, but other Screens that are remote as well.

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. An Administration Station can manage multiple Screens.

You typically choose whether to administer a Screen locally or remotely when you install the SunScreen software. Alternatively, you can add a remote Administration Station after the Screen software has been installed.

Local Administration

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

Figure 2-2 Local Administration of a Screen

Graphic

Remote Administration

Remote administration is performed from an Administration Station, where the administration software, including SunScreen SKIP and/or IKE, is installed. As shown in the figure below, a remote Administration Station on the internal network administers the Screen located between the internal network and the Internet. This Screen could be configured as the router between the internal network and the Internet. A second remote Administration Station for this Screen is located on the external network. The Administration Stations must be configured to communicate with the Screen using encryption. SunScreen SKIP or IKE is used to encrypt all communication between the remote Administration Stations and Screens, regardless of network topology between them.

Figure 2-3 Remote Administration From an Administration Station to a Screen

Graphic

Locating the SunScreen Screen

A Screen can only control traffic that passes through it; the Screen must, therefore, be placed in the network such that the traffic you want to control passes through it. All packets coming into the network and leaving it must pass through the Screen that controls the network.

If multiple paths exist between the Internet and the corporate network, the Screen will not work optimally, because, depending on the routing, traffic can pass through the Screen in one direction, but can bypass it in the reverse direction. To control the traffic on a network properly, both incoming and outgoing traffic must pass through the same Screen.

The figure below shows a network divided into several pieces by a Screen.

Figure 2-4 SunScreen as Internet Firewall Dividing a Network into Several Pieces

Graphic

In the figure above there are two networks: the Internet and the company's network. The company's network is further divided into several demilitarized zones (DMZs) where public services reside. The advantage of dividing the network into two or more DMZs is that even if a system on a DMZ is compromised, the traffic on that system must still pass through the Screen.

Security Policy

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.

Configuration

A SunScreen policy comprises the rules that a SunScreen Screen uses to implement your company's security policy. A configuration is the union of a SunScreen policy with common objects to form a complete description of the behavior of one or more Screens. A policy is a named set of policy objects. When the SunScreen software is first installed, there is one policy, named Initial, which contains a single rule and objects for the Screen and its interfaces. Common objects are data objects relevant to all policies. Common object types include address, screen, service, interface, certificate, and time. Ordered objects include filtering rules, NAT rules, administration access rules, and VPN (virtual private network) gateway descriptions.

Neither common objects nor rules include objects loaded into SKIP or IKE, but they do include the reference from the certificate name in the common object registry to the internal identity used by SKIP or IKE.

Stateful Packet Filtering

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

SunScreen uses a set of ordered rules to filter packets. When you configure SunScreen, you translate the security policies for your site into a series of policy rules that specify which services are 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.

Centralized Management Group

A centralized management group (CMG) reduces the overhead in configuring a set of firewalls and enables you to locate Screens at different points in the network and group them as an object. You can then manage this group of Screens with a standard set of objects through an Administration Station. All the firewalls in the group share the same policy, but apply it based upon their location in the network topology.

Network Address Translation (NAT)

Network address translation (NAT) translates one set of IP addresses to another set. NAT is typically used to:

NAT modifies the address fields in the IP header of the packet as it passes through the Screen. It also modifies the checksum and sequence number fields in the packet. Certain protocols (such as ftp) also require that data within the packet containing address information be modified.

Tunneling and Virtual Private Networks (VPN)

Organizations typically have offices in more than one location. SunScreen 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.

When a tunnel, or virtual private network (VPN), is set up between two or more locations, all data packets traveling from one location to the other are encrypted and wrapped inside other packets before they are sent over the public Internet. Encrypting the packets guarantees that their contents will remain private; anyone capturing packets with the snoop program on network traffic between the two locations will be unable to read them. When the packets arrive at the remote location, they are unwrapped, 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.

High Availability (HA)

High Availability (HA) enables you to deploy groups of Screens together in situations in which the connection between a protected inside network and an insecure 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 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. 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.

HA cluster, the passive

SunScreen provides flexible logging of packets. This means that each primary and secondary Screen can keep a log of its traffic. Logs of the packets are kept on the Screen that passed or rejected the packets.

Encryption

SunScreen 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 or IKE devices can be encrypted. All traffic between a Screen and an Administration Station is encrypted.

Logging

You can configure SunScreen to log a packet when it matches a rule or when it does not match any particular rule. Most frequently, packets matching DENY rules or packets that are dropped because they do not match any rule are logged. The action defined in a rule controls whether a packet is logged and what information about the packet is recorded.

Examining logged packets is useful when you are trying to identify the causes of problems during configuration or administration. You should also examine logs periodically for evidence of attempts to break into your network.

In an HA cluster, only the active Screen logs network traffic. However, traffic destined for the active or passive HA machine itself may be logged according to the rule. This means that some passive Screens may log some traffic, but only the traffic to them, not the traffic that is going through them. Each machine in an HA cluster logs what that system passed or rejected, as well as any locally processed nonpacket events.

Proxies

A proxy is a user-level application that runs on the Screen. The main purpose of proxies is to provide content filtering (for example, allow or deny Java applets) and user authentication.

You can set up proxies for ftp, HTTP, SMTP, and Telnet protocols. Although each proxy has different filtering capabilities and requirements, you can allow or deny sessions based on the source or destination address of packets. Proxies share common objects and policy rule files. To start a proxy, you set up rules for a proxy in your security policy and activate the policy.

Use of these proxies does not require installing any additional client or server system software. Some changes, however, may be required in system configurations or user-supplied commands to have access to protected destinations through the proxies.

Event Logging With Proxies

In addition to packet (SUMMARY and DETAIL) and SESSION log events, authentication, editing and activation, HA, proxies and other components of SunScreen create additional log entries. These entries are added to the SunScreen log chronologically, interspersed as events take place. Events such as administrator or proxy user authentication (or denial), policy-related events, HA failovers, proxy connection establishment, connection completion, transfers, as well as large a variety of debugging messages are inserted.

These non-packet, non-session events are sometimes referred to as extended events, since the mechanism used to log them is both an extension of earlier types of logging and it is itself extensible. They consist almost entirely of printable (UTF-8) strings

These extended events are flagged by ssadm logdump as XLOG. In the log browser, they are flagged with the severity level, followed by the application name.

Extended log events are described in detail in Chapter 11, Logging.

IPsec/IKE

IPsec is the name of the IETF standard system for Internet Protocol security. Specified in RFCs 2401, 2402, 2406, and 2409, among others, IPsec provides network-layer security for IP packets, and therefore, for any protocol that is based on IP. IPsec provides approximately the same functionality as SKIP. Both were developed from the same ideas and technology, but IPsec has been adopted as an IETF standard and is supported by a growing variety of software and equipment vendors. IPsec security can include:

When a packet is sent using IPsec, it contains security information in addition to the normal payload and IP headers. If confidentiality is desired, the normal payload and some of the headers are encrypted using a cryptographic key, and can only be decrypted by a recipient with the correct key. If authentication and integrity protection are desired, a message authentication code (MAC) is computed by the sender using a cryptographic key and can be verified by a recipient with the correct key.

The security information in an IPsec packet is carried in one or both of the special headers that form the IPsec protocols: AH and ESP. AH is an authentication header inserted between a packet's IP header and its transport layer payload. AH does not modify the payload; it merely adds an integrity check value so that a recipient can confirm the authenticity of the payload. ESP (encapsulating security payload), on the other hand, does modify the payload by encrypting it, making it unreadable until a recipient decrypts it using the correct key.

A variety of encryption and authentication algorithms can be used, but both the sender and receiver must use the same algorithms and keys. Multiple "flows" of packets using different algorithms or keys can exist simultaneously between a pair of systems. Each flow of packets using a particular algorithm and key is identified by a security parameters index, or SPI, which is included in the IPsec headers for the receiver's use. The association of an algorithm, a key, and an SPI with a packet flow is called a security association (SA). Each system using IPsec has a security association database that helps control the processing of incoming and outgoing IPsec packets. A security association is unidirectional, so it is typical to have a pair of SAs, one in each direction, for bidirectional protocols such as TCP.

The specific algorithm and key used by each SA can be configured into both systems manually, or can be determined by an automatic process called the Internet Key Exchange (IKE). To configure an SA manually, each administrator of two communicating systems enters the SPI, algorithm, and key identically on each system. To use IKE, the administrator enters the algorithm to be used; IKE automatically chooses keys and changes the keys periodically to minimize the risk of massive data compromise in the event that a key is stolen or "cracked." Another difference between manual keying and using IKE is that IKE chooses parameters and sets up SAs for both directions of traffic, while the manually configured SAs have to be explicitly set up in each direction.

Internet Key Exchange (IKE)

IKE defines a two-phased protocol to establish IPsec SAs for the communication peers. In Phase I, an authenticated, ephemeral Diffie-Hellman exchange allows the peers to authenticate each other, and provides a secure communication channel (an IKE security association) for later use. The IKE SA created in Phase I is then used in Phase II to establish the IPsec SAs used in the ESP and AH security protocols. Multiple Phase II exchanges can be performed under a protection of a single Phase I IKE SA.

One of the following authentication methods must be chosen for the two IKE peers to authenticate each other:

IKE supports the use of X.509 public key certificates for authentication. SunScreen maintains a certificate database for the local system's certificates and for certificates of IKE peers with which the system may communicate. Certificates can be generated on a SunScreen system itself--self-signed, and manually distributed and verified--or can be generated and signed by a certificate authority, the signature validated automatically using the certificate authority's public certificate. An alternative to certificates is the use of a pre-shared key by both peers to authenticate each other, but this method has some security disadvantages.

Other security parameters that must be chosen for Phase I include an encryption algorithm (SunScreen supports DES and Triple-DES), an authentication algorithm (SunScreen supports MD5 and SHA-1), and an Oakley Group (SunScreen supports groups 1, 2, and 5).

Note -

RSA-ENCRYPTION cannot use certificate payload. This precludes interoperating with Win2K using this authmethod. Since Win2K does not support this authmethod, this is not a significant problem. The following two conditions must be met for RSA-ENCRYPTION:

SunScreen IPsec Configuration

SunScreen's IPsec module uses the same cryptographic (encryption and authentication) modules as the Solaris IPsec implementation. The IPsec encryption and authentication algorithms must be installed and configured in the Solaris kernel in order to be used by SunScreen. SunScreen and Solaris support DES and Triple-DES for encryption and MD5 and SHA-1 for authentication. You may need to install the optional software packages SUNWcryr and/or SUNWcryrx to make these algorithms available.

Configuration of IPsec and IKE in SunScreen is done through parameters to the rules. Please refer to ssadm-edit(1m) and rule(4sunscreen). Commands are provided for certificate generation and certificate database maintenance; see the man pages for ssadm-certlocal(1m) and ssadm-certdb(1m).