Chapter 5 Administration

This chapter describes the concept of Screen administration and possible ways to administer a single Screen or multiple Screens. It contains information on:

• "Administering the Screen"

• "Local Administration"

• "Remote Administration"

• "Centralized Management Group"

• "Logging"

• "Common Objects Used in Centralized Administration"

• "Creating Common Objects and Policies for Multiple Screens"

Administering the Screen

SunScreen has two types of components for administration: a Screen and an Administration Station. The two components can be installed separately and remotely or they can be installed locally on a single system.

You can administer Screens either through the administration GUI or through the command line. See the SunScreen 3.2 Administration Guide for GUI procedures and Appendix B, Configuration Editor Reference for information about the command line.

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

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.

Object definitions, policies, logs, etc. reside on the Screen(s). logmacros and the logs themselves reside on all Screens (master, slave, primary, secondary). All other configuration information resides only on the master Screen in a CMG. Multiple admin stations have equal and uniform access to the same configuration information. This provides for multiple administrators, mobile administrations, and other flexibility advantages. Once logs are downloaded (via the log browser and/or the command line log manipulation tools), their accessibility is outside of the provisions of the SunScreen management model. The administrative organization, access control, policies and procedures, and log retrieval, analysis, and archival should be carefully planned and articulated to users.

Local Administration

Local administration is performed on the same 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 5-1 Local Administration of a Screen in Routing Mode

Remote Administration

For remote administration of a Screen from an Administration Station, install the software packages, including SunScreen SKIP and/or IKE, on separate systems, as shown in the figure below. In the figure, 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. Note that communication between a remote Administration Station and a Screen must be encrypted.

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

Centralized Management Group

A centralized management group (CMG) is a group of Screens that can be deployed throughout your organization. A CMG is managed with a set of configuration objects through an Administration Station or several Administration Stations.

• Primary Screen - Policies and all configuration objects reside on a specific Screen called the CMG's primary Screen. The centralized management group's primary Screen manages itself, as well as the centralized management group's secondary Screens. It is configured with all the common objects and rules for all the Screens in the centralized management group. The primary Screen can be administered locally or from a remote Administration Station, or both. Each primary Screen can nominally support up to 20 secondary Screens, although there is no hard limit. It is limited only by performance.

• Secondary Screens - The default configuration on the secondary is only the initial setup policy that was created during installation of the software so that the primary Screen could communicate with it. You cannot directly edit a policy on a secondary Screen, once that Screen has joined a CMG.

Logging

The logs are stored in a circular buffer on each Screen. You can download them to the Administration Station for analysis, archival, etc. Although no central logging mechanism exists for a global view of the logs on the individual Screens in a centralized management group, the secondary Screens make some basic emergency administration possible. For example, if the primary Screen is down for service, you can select a specific Screen and view its log.

If you have configured your centralized management group with multiple Screens and the Screens' names differ from the host name, be sure to use the correct host name if you want to view the information for that Screen. This name must match the host name in the /etc/hosts file.

Common Objects Used in Centralized Administration

Centralized administration requires secure communication among the Screens. This information is contained in the screen object. On the primary Screen, screen objects must exist for all the Screens. On each secondary Screen, Screen objects must exist for that secondary and the primary Screen.

Once you successfully activate a configuration from the primary Screen, it will replace objects on the secondary. If these new objects are incorrect, you may not be able to activate additional configurations centrally. If so, you can manually activate an old configuration on the secondary, fix the errors on the primary, and then activate the configuration again.

Creating Common Objects and Policies for Multiple Screens

When creating common objects and policies for multiple Screens, the object or policy rule by default applies to all Screens controlled by that primary Screen. You can restrict an object or rule to a single Screen by specifying its name in the Screen field in objects and rules.

While you could restrict all your objects and rules to a single Screen, the power of centralized administration comes when you can use common objects and rules to apply to multiple Screens.

Most common objects are applicable to all Screens, but sometimes an object such as an address object called Inside may be different on different Screens. In this case, make the names unique by adding a suffix or prefix to the name (for example Inside-East and Inside-West) rather than using the Screen option to restrict the scope of the object.

Interface Objects

You generally need to limit interface objects to a specific Screen because the names must be the name of the network interface on that system. Because the names of these objects must match those of the Solaris network devices they configure, use the Screen entry in the interface object to restrict that object to a single Screen.

Policies

Policies for a centralized management group are the same as any other policies and consist of a set rules that control the behavior of the centralized management group. You set up rules for the entire centralized management group of Screens using the administration GUI.

Policies and all configuration objects reside on the primary Screen. The primary Screen pushes the rules that apply to the remote Screens out to the Secondary Screens when the policy is activated. Each rule in the policy can be applied to all Screens or just one.

The policy is sent over an encrypted connection to the secondary Screens. The policy is then complied locally on each secondary Screen. The compiled policy is stored on the primary Screen.

The primary Screen "pings" the secondary Screens before it activates a policy and sends the administrator a message if there is a problem. The primary can push a policy to the other secondary Screens in a centralized management group even if one of the secondary Screens doesn't respond to the ping. A policy that is being pushed out to the secondary Screens is activated in parallel on all the secondary Screens. The primary Screen does not have to wait for each secondary Screen to compile the policy separately before sending it out to the next secondary Screen.

You cannot edit an activated policy on the primary Screen. You also cannot directly edit a policy from a Secondary Screen.