Chapter 4 Administration

This chapter describes the types of administration possible. It contains information on:

• "Remote Administration"

• "Local Administration"

• "Centralized Management Groups of Screens"

• "Creating Common Objects and Policies for Multiple Screens"

Administering the Screen

You can administer Screens either through the graphical user interface (GUI) or through the command line. See Chapter 5, Administration Graphical User Interface for information on the GUI and Appendix B, Command-Line Reference for information on the command line.

SunScreen 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.

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 software. You can add a remote Administration Station after the Screen software has been installed.

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.

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 4-1. Communication between a remote Administration Station and a Screen must be encrypted.

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

In FIGURE 4-1, 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.

Local Administration

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

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

Centralized Management Groups of Screens

Groups of Screens deployed throughout your organization are managed with a set of configuration objects through an Administration Station. Policies reside on a specific Screen called the centralized management group's primary Screen. Many Administration Stations can manage the Screens.

The centralized management group's primary Screen, where all configuration objects reside, manages itself, as well as the centralized management group's secondary Screens. The secondary Screens in a centralized management group make some basic emergency administration possible. For example, if the primary Screen is down for service, although no central logging mechanism exists 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.

Centralized Administration

Many sites run multiple Screens. With centralized administration, you can keep all common objects and policies on a central, primary Screen and use it to activate all the Screens in your site.

The primary Screen is the one that contains the common objects and policies for it and all the other Screens. The other Screens are the secondary Screens.

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 SunScreen, 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, it may be impossible 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. The following section provides some pointers on when this is and is not possible.

Address Objects

Most address objects should be applicable to all the Screens. Sometimes addresses such as Inside may be different on different Screens. In this case, it is generally better to 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 machine. Because you cannot modify the names, use the Screen entry in the interface object to restrict that object to a single Screen.

Rules

You set up rules for the entire centralized management group of Screens using the administration GUI.