Chapter 4 Common Objects

Common objects are the components or data objects that you use in making up the rules for a security policy. Before you write these rules, you must add or define the common objects that you plan to use. This chapter describes the common objects that are used in configuring and administering SunScreen. It contains information on the following topics:

• "Service Object"

• "Address Object"

• "Screen Object"

• "Interface Object"

• "authuser Object"

• "Time Object"

• "proxyuser Object"

• "Jar Signature Object"

• "Jar Hash Object"

• "Certificate Object"

• "IPsec Key Object "

• "Administration GUI Limitations"

After the common objects have been added to a policy, they are stored in a database and can be reused to create rule sets for additional policies. Common objects are of two types:

• Automatically-saved common objects that do not require saving after being defined or modified

• Common objects that require saving after being defined or modified

The following common objects are automatically saved when they are edited or new objects are added. You do not need to save these objects. Once these objects are added or edited, the change is saved immediately and is not repealed if the edit session is aborted. The Save button in the administration GUI remains greyed out, indicating that no Save is necessary due to such changes.

• Authorized User

• Jar Signature

• Jar Hash

• Proxy User

• logmacro

• mail_relay

• mail_spam

• vars

Although the changes made to these objects are saved immediately, the changes do not take effect until a policy is activated.

All other common objects are not automatically saved after you define or modify them. The Save button in the GUI becomes active to show that they require saving because they are specific to the SunScreen's database. If you are using the configuration editor, you must save them with the save command.

All objects except Authorized User, Jar Signature, Jar Hash, Mail Relay, Mail Spam, Proxy User and the Screen object itself can have an optional Screen attribute. This attribute is normally specified by the syntax SCREEN name_SCREEN The exceptions are for the logmacro and vars objects, which use the sys=name_SCREEN prefix.

Screen attributes designate that a particular object is to be used in favor of a non-specific object of the same name, when evaluated on the named SCREEN. It is possible and acceptable that there only be screen-specific objects for a given name (an underlying non-specific object need not be present, if it is never referenced). Nearly all pre-configured objects (except the Screen and Interface objects created by the initial configuration processes) lack Screen attributes.

Normally, Interface objects will have Screen attributes. Only when CMG will never be used, or in special situations, such as identical screens in an HA cluster, would warrant such.

Service Object

SunScreen is shipped with a number of predefined network services, such as ftp, telnet, dns, and rsh. See Appendix C, Services and State Engines for a complete list of services and service groups. These services describe the network protocol that is used in the packet-filtering rules. You manipulate them through the SunScreen administration GUI or the configuration editor. You can modify these services or define new services as needed.

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.

There are two types of service objects, described below:

• single service

• service group

Single Service

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, for most sites you 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 can allow anyone in the internal corporate network to send outbound traffic, but only allow inbound traffic in this protocol to go to the public 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. The state engine is a read-only object that describes the filtering behavior of the packet-filtering engines in SunScreen. For example, the FTP state engine checks port numbers when the ftp service is being used. For more information about state engines, see Appendix C, Services and State Engines. Table C-1 lists the predefined single service objects in SunScreen, along with the state engine and discriminator (port, RPC program number, or type). It also indicates the parameters (state engine modifiers, such as time-outs) and BROADCAST where applicable.

You can modify existing services or define new services as needed. Each service must use a predefined state engine. Troubleshooting is easier if you create a new service rather than modifying an existing one because you do not have to examine the services to see which ones you have modified. Note the purpose of the new (or edited) service in the description.

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.

You control the filtering activities by specifying what packet-filtering engine you want to use and the various discriminators and parameters applicable to that filtering engine.

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

• What protocol(s) does the new service use?

• What port(s) does the protocol use?

• If your service is an RPC protocol, what program numbers does it use?

• If your service is a UDP protocol, how many responses can be sent back for each request?

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 C, Services and State Engines for more information on state engines, their discriminators, and their parameters.

You can specify state engines as filters in both the forward and the reverse direction. The FORWARD filter applies when traffic originates from the From Address and goes to the To Address in a rule. The REVERSE filter applies 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 is always 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 non-stateful traffic to return. An example is a rule that uses the nlm (network lock manager) service, which uses the non-stateful ICMP filter engine. It allows nlm requests (ICMP type 8) in the forward direction and nlm replies (ICMP type 0) in the reverse direction.

State engines can have a single port or a range of ports as a discriminator. A single port is just a number (#) ; a range of ports is denoted by a number-to-number range, written as #-# with no space before or after the hyphen. The keyword PORT or BROADCAST is used to identify the type of discriminator. 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 discriminator both with broadcast selected (BROADCAST) and without it selected (PORT) .

Optionally, a set of parameters can immediately follow the port or range of ports that they modify. They are indicated by keywords and are a space-separated list of numbers.

A service's unique name is its given name plus the name of the Screen if it is associated with one. All references to a service are to its generic name, without regard to any associated Screen.

Service Group

A service group comprises a collection of single services and/or other groups of services. You can group network services together to apply a single rule to multiple network services. "SunScreen Network Service Groups" in Appendix C, Services and State Engines, shows the predefined service groups in SunScreen and the services each includes. Note that not every service is included in a service group.

The predefined common service group, for example, contains the following services: tcp, all, udp all, syslog, dns, rpc all, nfs, prog, icmp all, rip, ftp, rsh, real audio, pmap, udp all, pmap, and tcp all. 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.

State engines that you use in describing services come in distinct classes and each class has subclasses. The subclasses form an order for choosing state engines when a rule includes a service group. Table 4-1 below shows state engines in order of preference--the greater the class/subclass number, the higher the preference. If you have a rule that uses a group of state engines, the one with the higher preference is matched.

A state engine that is followed by an asterisk(*) may conflict with another state engine because another state engine is in the same class and subclass.

A given service that you have defined manually to contain multiple state engines or in a service group that includes multiple services, can only contain a single state engine in a particular class or subclass for a particular port.

Address Object

An address object can be used in filtering rules, NAT rules, interface definitions, remote access rules, and VPN gateways. It can be an individual address, a range of addresses, or a group of addresses. You manipulate an address object through the SunScreen GUI or the configuration editor.

The addresses named * and localhost are reserved and cannot be modified in any way. The value of * is all IP addresses, as if a RANGE were defined with a starting IP address of 0.0.0.0 and an ending IP address of 255.255.255.255.

The value of localhost is the set of all addresses associated with the machine that SunScreen is running on--that is, the Screen's own IP address.

Optionally, you can associate addresses with a specific Screen object. In this case, its value is only used on the Screen with which it is associated. This approach enables multiple Screens to have different values for an address object with the same name. This is useful if, for example, you want to use the address "inside" and "outside" for all the Screens being managed.

An address object's unique name is its given name plus the name of the Screen if it is associated with one. All references to addresses are to their generic names without regard to any associated Screen.

There are three types of address objects:

• Host Address

• Address Range

• Address Group

Host Address

SunScreen identifies a host address as an individual host by linking its unique IP address to an address object. This address object can use the name of the host, IP address of the host, or some other identifier. The figure below shows an example of a host identified by its IP address (172.16.1.1).

Figure 4-1 HOST - Single Address

Address Range

An address range is a set of numerically contiguous IP addresses. Networks and subnetworks are typically identified by a name for the range of IP addresses. 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. The figure below 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.

SunScreen 3.2 supports four syntaxes for ranges:

• a.b.c.d e.f.g.h

• a.b.c.d - e.f.g.h (same as above, spaces optional around '-')

• a.b.c.d/m.n.o.p (m.n.o.p is the network+subnet mask)

• a.b.c.d/# (# is CIDR, number of network+subnet bits)

In the figure below, for example, the following are all the same:

• 172.16.3.0 172.16.3.255

• 172.16.3.0-172.16.3.255

• 172.16.3.0 - 172.16.3.255

• 172.16.3.0/255.255.255.0

• 172.16.3.0/24

The values in parentheses in the figure (255.255.255.0) represent a netmask.

Figure 4-2 Range of IP Addresses

Address Group

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.

There are two addresses you cannot modify: localhost, which is the IP address or addresses of the actual Screen and *, which represents all IP addresses.

The value of an address group is determined first by all included addresses, which means that all the IP addresses explicitly specified and all IP addresses contained in any other address groups included in the group are added to the address group. Next, all IP addresses of all the addresses and address groups that are excluded are removed from the address group. Note that you cannot control the order in which the IP addresses are added or removed: 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 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 has the majority of addresses on it. For example, the Internet network interface in the network illustrated in figure below has the most addresses, because it is the interface for all addresses except those in the Corp, ftp-www, and Sales networks.

Figure 4-3 SunScreen as Internet Firewall

Rather than enumerating all the addresses for the Internet, you can define the address group for the Internet address object to include 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.

Screen Object

A Screen object, which is created or modified through the configuration editor or the Administration GUI, maintains information about each Screen in the network and the relationships between the Screens.

The Screen object allows for an optional description of 256 characters or less in the comment field. It is also possible to edit:

• Miscellaneous Screen parameters

• SNMP information

• HA and CMG parameters

• Mail Proxy configuration

SunScreen Install automatically creates a local Screen object and gives it a name based on the output of uname -n. Additional Screen objects must be created when setting up a High Availability (HA) cluster or a Centralized Management Group (CMG).

The Screen named * is created by default and cannot be modified in any way. This name is reserved and is used to indicate any Screen when an object or rule requires a Screen name to be specified.

Miscellaneous Parameters

There are various flags that can be set within a Screen object when you use the configuration editor. These flags indicate:

• Whether or not Destination Address Checking is enabled (DEST_CHECK)

• If the Screen will allow or deny routing traffic (RIP)

• Which naming services it will use (DNS, NIS or none)

• Whether the Screen uses SKIP certificate discovery protocol (CDP)

Destination address checking checks the destination IP address of each packet coming out of a Screen. The packet is allowed to go out only if its destination IP address is defined on the interface. Those addresses are defined by listing them in the valid addresses for an interface. See "Interface Object" for a discussion of valid addresses. Destination address checking protects against sending packets out on the wrong interface.

Destination address checking is an attribute of the Screen object. You enable or disable it Screen-wide. You can't enable it on only some interfaces.

The size of the log file (LOGSIZE) is an optional parameter which is specified in megabytes. If no size is specified, the default size is 100 MB.

If the Screen is configured in stealth mode, the network that it partitions and the netmask must be specified. In the configuration editor this is accomplished using the STEALTH_NET #.#.#.# #.#.#.# keyword, where the first #.#.#.# is the network address and the second #.#.#.# is the netmask. In the administration GUI, these parameters are the Stealth Net Address and Stealth Netmask, respectively, in the Miscellaneous tab of the Screen object.

SNMP Information

In order to issue SNMP alerts, a list of SNMP receivers and their respective IP addresses must be specified. The SNMP time status indicator can also be enabled by setting the SNMP timer interval in minutes. These parameters are set in the configuration editor with the SNMP and SNMP_TIMER keywords, or in the administration GUI under the SNMP tab of the Screen object.

The following SNMP traps are supported:

• An action on a packet that matches a particular rule

• A default drop action on an interface

• Time status indicator traps

The first two types include the following data:

• interface - The SunScreen network interface number on which the packet was received.

• interfaceName - The SunScreen network interface name on which the packet was received.

• errorReason - The reason the alert was generated. (See the sunscreen.mib file for a complete list of reasons.)

• packetLength - The actual length of the packet in bytes.

• lengthLogged - The length of the data logged in bytes.

• packetData - The packet data.

The SNMP timed status indicator trap uses the same receivers database as other types of SNMP traps. There is only one database with a maximum of five receivers. These receivers are specified as variable to the screen object.

The following data are in the SNMP timed status indicator. These data cannot be modified and new data cannot be added:

• cpuUsage - Average percentile CPU usage

• memoryAvail - Current swap space available, in kilobytes

• swapIn - Current swap ins

• swapOut - Current swap outs

• scanRate - Current scan rate

• tcpUsage - Current number TCP connections in the SunScreen state table

• ipUsage - Current number IP connections in the SunScreen state table

• udpUsage - Current number UDP connections in the SunScreen state table

• rootUsage - Disk usage of the root partition, /

• varUsage - Disk usage of the var partition, /var

• etcUsage - Disk usage of the etc partition, /etc

• tmpUsage - Disk usage at the tmp partition, /tmp

Only these SNMP traps are supported. No get or set operations are supported.

If you want the Screen to use SNMP time status indicator, you must set the SNMP_TIMER keyword with a time value in minutes. You must have defined the SNMP receivers to use this feature. If it is not set, it is not enabled.

SunScreen 3.2 supports four syntaxes for ranges:

• STEALTH_NET a.b.c.d e.f.g.h

• STEALTH_NET a.b.c.d - e.f.g.h (same as above, spaces optional around '-')

• STEALTH_NET a.b.c.d/m.n.o.p (m.n.o.p is the network+subnet mask)

• STEALTH_NET a.b.c.d/# (# is CIDR, number of network+subnet bits)

HA and CMG Parameters

When a Screen is part of a High Availability (HA) cluster or Centralized Management Group (CMG) , it is classified as either a Primary or Secondary Screen. Primary and Secondary are defined as follows:

• Primary - One of the Screens in the collection must be the primary Screen, and all other Screens are Secondary. The primary Screen is used for all administration: it holds the configuration data and is responsible for communicating with the Secondary Screens in order to update their policies.

• Secondary - A Secondary Screen receives all its policy information from the primary Screen. A Secondary Screen must indicate the name of the primary Screen in its Screen object. This name is specified with the MASTER keyword in the configuration editor or the Primary Name field under the Primary/Secondary tab in the administrative GUI.

The primary Screen object has no Primary name specified, but is recognized as the primary Screen if its name appears in the Primary Name field of at least one other Screen.

If the Screen is part of a centralized management group or is administered remotely, you must specify the following field:

• ADMIN_IP - An IP address that can be used to communicate with the Screen for administrative traffic. You specify it as an IP address in the form #.#.#.#.

• ADMIN_CERTIFICATE - The name of the certificate that can be used to secure administrative traffic to the Screen

• KEY, DATA, MAC, and COMPRESSION - The algorithms to control how data are encrypted between the Screens in the administrative group

• TUNNEL - (Optional) This field specifies if tunneling is being used. It is the name of an address object.

If IKE is used to protect these data communications, you must also specify the following fields:

• IKE ("name of Certificate", "name of Algorithm", "name of Algorithm", "name of Algorithm") - The name of a certificate that can be used to secure administrative traffic to the Screen when using the IPsec/IKE protocol. IKE is used if both IKE and SKIP are specified.

• ESP ("name of Algorithm", "name of Algorithm") -

• AH ("name of Algorithm") -

If the Screen is part of an HA cluster, the HA_PRIMARY or HA_SECONDARY options must be specified in the configuration editor. This can also be accomplished in the administrative GUI using the High Availability field of the Primary/Secondary tab.

If the Screen is specified as the HA Primary, the High Availability IP Address (HA_IP #.#.#.#) and Ethernet Address (HA_ETHER #:#:#:#:#:#) must also be specified.

If the Screen is specified as an HA Secondary, the primary Screen name (MASTER) and High Availability IP Address (HA_IP #.#.#.#) must also be specified.

Mail Proxy Configuration

In the administrative GUI, it is possible to modify the mail proxy spam restrictors in the Mail Proxy tab of the Screen Object window. Note, however, that manipulating this information in the configuration editor is not done through the Screen object, but through the mail_spam subcommand of ssadm edit. For more information about the Mail Proxy, see "SMTP Proxy Operation".

Interface Object

An interface object is a common object that describes a network interface which is associated with a SunScreen configuration. You can manipulate interface objects through the administration GUI or the configuration editor.

When configuring interface objects, you must specify the type of interface being used. SunScreen uses five types of interfaces, which are discussed later in this section. Note that when using the configuration editor to add or modify an interface, the interface type must be typed using all caps as shown below:

• ROUTING

• STEALTH

• ADMIN

• HA

• DISABLED

See the SunScreen 3.2 Installation Guide for detailed information about interface types and their installation, including a caution about mixing routing and stealth interface modes. See also the SunScreen 3.2 Administration Guide and the SunScreen 3.2 Configuration Examples, the latter of which includes an example of a mixed-mode configuration.

You can, as an option, associate any interface with a specific Screen object. If the specified Screen name is part of a centralized management group (CMG), this association is necessary to distinguish which interface definition belongs to which Screen.

In addition to the interface type and Screen parameters, there are several other parameters which are part of the interface object. These parameters are defined as follows:

• Description - The interface description allows for an optional COMMENT of 256 characters or less.

• Valid Addresses - Specifies the set of addresses reachable through a particular interface. The interface's valid address set is the basis for packet forwarding decisions in stealth mode and for source address spoof protection in routing mode.

• Spoof Protection - Each routing interface is marked as having a complete or incomplete valid address set.

  If the valid address set is complete, only the addresses defined in the set are allowed as the source address for packets received on the interface. Any other addresses are considered "spoofed" and the packets are dropped.

  If the valid address set is incomplete, some of the source address spoof protection is disabled. Specifically, addresses defined in another interface's valid address set are disallowed on the incomplete interface, but addresses that are not explicitly assigned to another interface are considered legal, and therefore allowed.

  ---

  Note -

  If the valid address sets are empty and incomplete is set (default after routing mode install), all source addresses are valid on all interfaces.

  If the address sets are empty, and complete is set, no source addresses are valid on any interface. The Screen will not pass any traffic if configured like this.

  Spoof checking is the first thing that is done to a packet when it arrives on the interface. No other SunScreen processing is performed unless the packet passes the spoof check.

  ---

• Address Overlap - Each routing interface optionally may specify an overlap parameter that contains a set of addresses that are allowed to overlap between this interface's valid address set and that of another routing interface on the same Screen. Otherwise, it is an error to define two routing interfaces that have overlapping valid address sets. This option is not available for stealth interfaces.

• Logging - Identifies the disposition of a packet when a packet arriving on an interface does not match any rule or does not pass the spoof check. It has the values:

  • None - Do not log.

  • Summary - Record the first 40 bytes of the packet in the log.

  • Detail - Record the complete packet in the log.

• SNMP Alerts - Specifies whether the Screen should issue an SNMP alert when a packet received on an interface does not match a rule or does not pass the spoof check. the options are:

  • SNMP_NONE - Do not send an SNMP alert message. This is the default.

  • SNMP - Send an SNMP alert message to the SNMP receivers listed in the Screen object when a packet received on this interface is rejected.

• ICMP Action - Identifies the ICMP rejection message that is issued if a packet received on the interface is rejected. In most cases, the Screen rejects packets by sending and ICMP Destination Unreachable packet with the reject code set as specified in the ICMP action on the interface. However, if a TCP packet matches a DENY rule, and the ICMP action is set to PORT_UNREACHABLE, a TCP RESET packet is issued instead. It has the options:

  • NONE

  • NET_UNREACHABLE

  • HOST_UNREACHABLE

  • PORT_UNREACHABLE

  • NET_FORBIDDEN

  • HOST_FORBIDDEN

• Router IP Address - Specifies the router's address when the Interface type is stealth. A stealth interface may define up to five routers, by IP Address. These routers are used for forwarded traffic not on the local network.

Routing Interface

Routing interfaces have one or more IP addresses and route packets using the standard IP routing mechanisms in the operating system. Each routing interface is connected to a different IP network just like a standard IP router. In terms of network placement, a Screen with routing interfaces replaces a router. A routing interface can also receive administrative traffic from a remote Administration Station.

Connections to and from proxies can only occur through ROUTING interfaces. Thus, to run proxies or if you want to install additional network services on the Screen, you must configure the Screen to have at least one routing interface.

Use routing interfaces to:

• Replace an existing router

• Control packet flow between different IP networks

• Receive administrative traffic for the SunScreen configuration

• Install proxies or other network services on the Screen

A Screen with routing interfaces does not need a separate admin interface, because the administrative traffic can come in through one of the routing interfaces. If Screens are part of an HA cluster, they each must have a unique HA interface for the dedicated HA heartbeat network.

Stealth Interface

Stealth interfaces have no IP address. A Screen with stealth interfaces partitions an IP network and controls packet flow between the partitions. Screens containing only STEALTH interfaces are required to have one ADMIN interface for administrative traffic.

Although it acts much like an IP bridge or switch, a Screen with stealth interfaces does not implement the bridging algorithms that detect loops. Make sure that no loops exist in your network configuration where a packet could be sent out from one stealth interface and be received on another. Also note that HA (high availability) clusters require that the machines be connected by means of a non-switching hub.

Stealth interfaces provide a higher degree of security than routing interfaces because they are separate from the standard IP mechanisms used by the operating system. Thus, packets flowing through stealth interfaces cannot inadvertently leak into other network applications running on the system, thereby compromising the security of the firewall.

Admin Interface

An admin interface is a special case of a routing interface configured only to pass administration traffic for the Screen. An admin interface is not required for a Screen with routing interfaces because routing interfaces can pass administration traffic through to the Screen.

Because stealth interfaces have no IP address, they cannot provide the IP address needed for administration traffic. You must, therefore, configure a Screen that has only stealth interfaces with an additional admin interface.

Routing and Stealth Interfaces on a Single Screen

You can configure a Screen with a mixture of routing and stealth interfaces subject to the following restrictions:

• Packets do not flow between the routing and stealth interfaces. Packets received on a stealth interface are only sent out on another stealth interface. Packets received on a routing interface are only sent out on another routing interface.

• Any packet affected by NAT or encryption must only pass through the Screen once.

HA Interface

Each Screen that is part of an HA cluster must have a single, unique HA interface for the dedicated HA heartbeat network. It is possible to administer the HA cluster over this interface, but it is primarily for synchronizing the Screens within the cluster and passing configuration data from the primary Screen to the secondary Screens.

Disabled Interface

An interface of type DISABLED does not filter any traffic. It is important to understand that traffic can still flow across such an interface if it is configured "up" within Solaris. Care should be taken to understand the possible ramifications of using a DISABLED interface in this manner.

If the Screen contains ROUTING interfaces, it is possible for packets to flow between the DISABLED interface and the ROUTING interface (due to Solaris routing). The packets entering or leaving the disabled interface are not filtered, but the packets leaving the Screen over the ROUTING interface are filtered.

If the DISABLED interface is defined on a Stealth-mode-only Screen, it will pass no traffic.

authuser Object

The authuser (authenticated user) common object specifies the means by which users are to be validated for their roles in proxyuser objects. SunScreen administrative privileges are also often granted based on authuser objects. The authuser common object is automatically saved when it is edited or a new authorized user object is added. The change is not repealed if the edit session is aborted. The Save button in the administration GUI remains greyed out, indicating that no Save is necessary due to such changes.

An authuser object is one of the data objects that defines a SunScreen configuration. You manipulate it through the configuration editor or administration GUI. authuser objects are the repositories for authentication and demographic information used to identify individual users. This information is used to authenticate users by a Screen's access control facilities.

Each authuser object has a name. The name cannot contain the following characters:

! # $ % ^ & * { } [ ] < > " \ ? ` / @ NULL

You can choose the names to coincide with existing, real-world naming schemes for individuals. Thus, "harold.bovis", "Sally Ann Studebaker", and "Rundum, Karr Bo" are examples of legitimate authuser names . The name space of the authorized user is separate from all others in the SunScreen firewall. (In particular, authuser names are different from those that name proxyuser objects.)

Tip: Unlike the names of proxyuser objects, the names of authuser objects are rarely entered by the user directly. The exception to this is their (optional) direct use in administrative access rules (accesslocal and accessremote).

authuser objects store information describing individual users of interest to various SunScreen access control facilities. The data contained within its entries fall into three general groups:

• authentication

• demographics

• control

Authentication information is employed by the processing in the SunScreen firewall to confirm the identity of a potential user. Three types of authentication are supported: simple password, SecurID, and RADIUS. RADIUS authentication does not use authuser objects. A given user object can specify the use of either or both of the other two types simultaneously. Authentication processing attempts to match any password or passcode entered against each type specified in the order present within the entry's record.

(The preceding statement is true within certain limits. For example, a password that cannot possibly be a SecurID passcode will never be presented to that mechanism even if SecurID is specified. If you use the SecurID type, it should be given after all other types.)

The Java-based graphical configuration tools only allow for a single, simple password type or a SecurID type, in that order. Both the authuser objects and the SunScreen authentication processing allow multiple, simple password types to be specified, and each will be tried in the order present. However, entries with multiple, simple password types will not be properly displayed or edited by the Java-based tools.)

Demographic information stored in authuser objects is used to identify users better and to improve and possibly automate user contact:

• DESCRIPTION="desc" - Specifies a plain-text description string desc to be associated with the user entry.

• REAL_NAME-"namestr" - Specifies an optional real name string to be associated with the authuser object.

• CONTACT_INFO="contactstr" - Specifies an optional contact information string to be associated with the authuser object (for example, email address).

Control items are used by the authentication logic to restrict processing, and the like. Each authentication item can have an individual enablement tag, which determines if that particular item is to be processed. The entire object also has such an enablement tag, allowing a user's entry to be turned-off without deleting it. (Technically, the structure that stores the name is also a control item.)

• ENABLED - Allows authentication processing to consider this object. This is the default.

• DISABLED - Does not allow authentication processing from considering this object.

• PASSWORD={ "pwd" pwdarg ... } - Specifies a simple password method to be used for authentication. The pwd field is the user password, in plain-text. The processing for the PASSWORD keyword automatically translates this string from plain-text into crypto-text, and causes a CRYPT_PASSWORD subitem to represent pwd. Thereafter, the plain-text password is displayed as an empty string, with the CRYPT_PASSWORD subitem retaining the password. The subitems for the pwdarg are:

  • CRYPT_PASSWORD="cryptpwd" - The DES-encrypted version of the user's password. This value retains the password in a form that avoids its compromise. When presenting this value to the add verb, the value of pwd should be empty (""). (The password encryption mechanism is the same one used by Solaris' native user password scheme.)

  • ENABLED - Allows authentication processing to attempt to match this password item. This is the default.

  • DISABLED - Does not allow authentication to attempt to match this password item.

• SECURID={ "sidname" sidargs ... } - Specifies the SecurID method to be used for authentication. The sidname is the string in the login: or Default login: field in the SecurID server entry for this user. The subitems within sidargs are:

  • ENABLED - Allows authentication processing to attempt to match this SecurID item. This the default.

  • DISABLED - Does not allow authentication processing to attempt to match this SecurID item.

Time Object

Time objects are specified using a 24-hour clock in 5-minute increments. You use time objects to set a policy's time-of-day, day-of-week, and the like in time-based rules. For instance, you can 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. You can set a few time-based policy rules that reference the same set of hours, or you can specify the hours covered for a particular day or range of days, 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.

Although you can define many time objects, only 31 distinct time objects can be in actual use on any given Screen. You cannot modify the time object named * in any way; it represents 24 hours a day, 7 day a week. It is the same as if no time object is used. It is not included in the limit of 31 time objects.

For example, Los Angeles (LA) and New York (NY) have a three-hour difference. Suppose each site is protected by a Screen. If you only want the two sites to communicate when they are both within "regular" hours (that is, 8 a.m. to 5 p.m.), then NY is available to communicate to LA between 11 am and 5 p.m., and LA is available to communicate to NY between 8 a.m. and 2 p.m.

A downside to this is that during hours that do not overlap, one of the two Screens allows traffic through while the other does 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

Set the rules by typing:

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

These rules apply to both Screen, although the definition of regular is different for each Screen

Case 2: Distinctly Named Time Objects

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 ny-business ALLOW
SCREEN NY telnet NY LA TIME ny-business ALLOW

proxyuser Object

The proxyuser common object contains the mapping information for users of SunScreen proxies. You manipulate the proxyuser through the administration GUI or the configuration editor. The proxy user object has the subtypes single and group. FTP Telnet, and (optionally) HTTP proxy rules reference the proxy user entries.

The proxyuser object is automatically saved when it is edited or a new proxyuser object is added. The change is saved immediately and is not repealed if the edit session is aborted. The Save button in the administration GUI remains greyed out, indicating that no Save is necessary due to such changes.

proxyuser objects store associations between authuser objects and a user ID (or other host-based user identifier) to be used by a proxy to authenticate and establish a user's identity on a "backend" server system. These associations, or "mappings", enable reusing the authentication information within authuser objects; by creating multiple mappings, any given authuser can be cast into different roles with respect to one's identity on different "backend" servers to be proxied. These mapping proxyuser objects are dubbed "simple" ones.

Finally, some proxyuser objects are considered "special" ones. Such objects are similar to simple objects but provide access paths to one or more user entities that can be authenticated by an external mechanism. RADIUS and SecurID are two such external mechanisms that are presently supported.

proxyuser objects are referenced in SunScreen proxy policy rules.

Each proxyuser object has a name. The name cannot contain the following characters:

! # $ % ^ & * { } [ ] < > " \ ? ` / @ NULL

You can choose names that coincide with existing real-world naming schemes for individuals, existing computer-based naming, or any other scheme. Thus, "hbovis (mechengg)", "sally.ann.studebaker", and "Rundum, Karr Bo - security" are all examples of legitimate proxyuser object names. The namespace of the proxyuser objects is disjoint from all others in the SunScreen firewall. (In particular, proxyuser names are different from those that name authuser objects.)

Tip: Choose names for proxyuser objects which can be readily entered by users.

Each proxyuser object has an enabled tag, so that you can turn it off for processing purposes without deleting it:

• ENABLED - Allows authentication processing to consider this object; this is the default.

• DISABLED - Disallows authentication processing from considering this object.

The two portions of the simple object mapping are: an authuser object reference and backend user name. Each of these is an optional field:

• AUTH_USER_NAME="authusername" - Specifies a reference to an authuser object with the given authorized user name. If this item is not present, then the proxyuser object does not require authentication.

• BACKEND_USER_NAME="backendname" - Specifies the system-dependent name, to be supplied to the backend server as the identity of the user of this mapping. (At present, this item should always be defined.)

In addition to simple entries, proxyuser objects also enable creating groups of sibling objects. The GROUP is a way to group proxy users that have the same privileges. Group proxyusers save time when creating rules. Before creating a proxy user group, define the proxy user objects for that proxy user group. These GROUP objects can contain zero or more references to other simple or group proxyuser objects. The group structures are maintained hierarchically, not flattened. For GROUP proxyuser objects the value fields are:

• MEMBER_NAME="mname" - Makes a reference to another proxyuser object mname by the one containing it. This item can be repeated as many times as needed to make references to all group members.

Any proxyuser object, regardless of type, may have the following optional attributes:

• DESCRIPTION="desc" - Specifies a plain-text description string desc to be associated with the user entry.

Jar Signature Object

The Jar signature common object identifies the Java archives (JARs) that you want the Screen to pass. You can manipulate it through the administration GUI or the configuration editor. JAR signatures apply only to the HTTP proxy.

The Jar signature object is automatically saved when it is edited or a new Jar signature object is added. The change is saved immediately and is not repealed if the edit session is aborted. The Save button in the administration GUI remains greyed out, indicating that no Save is necessary due to such changes.

Jar signature objects are named, and their name space is distinct from all others within SunScreen. The name of a Jar signature object is entirely ephemeral; it is not referenced in any other context by SunScreen. The name consists of 1 to 255 characters, not including the following:

! # $ % ^ & * { } [ ] < > " \ ? ` / @ NULL

Each Jar signature object has a value part. This value is a 32-character hex digit MD5 hash value. It is used to verify the integrity of Java archives (JARs) that are allowed through the SunScreen HTTP proxy.

Jar Hash Object

The HTTP proxy can be set up to filter the Java applets based on the hash value of the Jar file. Each Jar hash object has a value part. This value is a 32-character hex MD5 hash value. It is used to verify the integrity of Java archives (JARs) which are allowed through the SunScreen HTTP proxy.

A Jar hash object is one of the data objects that define a SunScreen configuration. You can manipulate it through the configuration editor or the administration GUI. A Jar hash object is automatically saved when it is edited or a new Jar hash object is added. The change is saved immediately and is not repealed if the edit session is aborted. The Save button in the administration GUI remains greyed out, indicating that no Save is necessary due to such changes.

Jar hash objects are named, and their name space is distinct from all others within SunScreen. The name of a Jar hash object is entirely ephemeral. It is not referenced in any other context by SunScreen. The name consists of 1 to 255 characters, not including the following characters:

! # $ % ^ & * { } [ ] < > " \ ? ` / @ NULL

Certificate Object

A certificate object is a mapping between a name that users can read and a SKIP or IKE identity. You manipulate certificate objects through the administration GUI or the configuration editor and use certificate objects to configure the certificates that you use for secure communication between your Screen and remote hosts. Remote administration is only possible using certificate objects.

Changes to the certificate object that pertain to loading into SKIP or IKE take effect immediately without having to be saved. On the other hand, changes to the certificate object as stored in the common objects registry do not take effect immediately and must be saved explicitly. They only take effect when the policy in which they are used is activated. For example, if you add a new certificate, the certificate is created and loaded immediately into SKIP or IKE, but the name has not been saved as part of the common objects, and must be saved explicitly. Similarly, if you rename a certificate, you must explicitly save it.

You can write an optional description for all certificates in the comment field. The description is limited to 256 characters or less.

Optionally, you can associate a certificate object with a specific Screen. If you associate a certificate object with a Screen, its value is used only on that Screen.

A certificate's unique name is its given name plus the name of the Screen, if any, with which it is associated.

There are two subtypes of certificates:

• Single Certificate

• Certificate Group

Single Certificate

A single certificate object represents a single SKIP or IKE identity. A SKIP certificate object has an NSID (name space identifier) and an MKID (master key identifier). An IKE certificate object is identified by the Subject Name DN (Distinguished Name).

You can assign a name to a SKIP or IKE certificate that already exists. The certificate object provides a way to associate a usable name with a SKIP certificate NSID/MKID pair or an IKE DN. This naming facility makes using certificates easier, as well as isolating the Screen configuration from exact SKIP or IKE names. You associate a certificate ID when you want to encrypt communication between two Screens or between a Screen and a remote Administration Station.

Certificate Group

A certificate group allows grouping single certificates that you want to use together. In the Administration GUI select New Group... from the Add New Object pulldown to create a certificate group.

IPsec Key Object

An IPsec key object is a mapping between a human-readable name and a hexadecimal string of keying material to be used for manually-keyed IPsec communication or IKE authentication using a pre-shared key. It is manipulated with the configuration editor or the administration GUI.

Administration GUI Limitations

The administration GUI performs almost all the normal administration tasks, but it does not support every option of the configuration editor for use with the command line interface. The configuration editor offers many options for each command. Appendix B, Configuration Editor Reference contains information about the configuration editor.