Policy Rules

You can define rules and order them either from the graphical user interface (GUI) or the command line.

Policy rules are based on sets of ordered policy rules. You set up these rules to reflect the security policy for your site. These rules specify the action to be taken for services between two addresses that are on different interfaces of the Screen. A collection of rules form a policy.

When you install the SunScreen software, you start with a policy called Initial that establishes access rules for basic TCP/IP services. You then define policy rules to allow clear or encrypted communication between hosts that meet your criteria.

Each rule must specify all three selection criteria: source address, destination address, and type of service. Each rule can also specify what action to take if a packet meets those criteria. For example, different rules will specify whether the Screen should forward or drop the packet; encrypt or decrypt the packet; record the packet in the Screen logs; and issue ICMP messages or SNMP traps concerning the packet. The default rule is to drop any packet that does not have a specific SECURE, ENCRYPT. or ALLOW action.

The sequence in which rules are ordered is critical. When the Screen processes packets, it compares the packet information to each rule in the order it occurs in the Screen's active policy. When a packet meets the criteria of a rule, the Screen applies the actions specified for that rule and disregards the following rules.

Define services for a service group carefully and place the rules in an order that will permit the services used to pass easily. For example: If services such as ftp, rsh, and realaudio are not part of a service group such as tcp_all and a tcp_all rule occurs first, then the tcp_all rule will pass the ftp packet, which is a tcp packet, because it assumes a simple tcp connection. Other special-case processing, such as a reverse data-port connection from the server back to the client, will not automatically be allowed by the initial connection as it would had the ftp-based rule been placed first.

When a packet filter checks to see if a packet matches a rule, the difference between service or service group, such as ip_all, and a service or service group with BROADCAST, such as ip_all_with_broadcast, is important. If the service or service group has the BROADCAST flag set, the destination IP address in the packet must be a recognized broadcast address. Configure stealth mode to identify the network and netmask that the Screen partitions properly so that it can correctly identify what the valid broadcast addresses are. If a packet must pass through the Screen that has a destination address of one of the broadcast addresses, set BROADCAST in the service used in the rule to pass the traffic. With respect to all other destination addresses, ip_all and ip_all_with_broadcast are identical.

When you define rules for specific services (such as telnet, HTTP proxy, ftp, and the like), you do not automatically pass network control messages that might be necessary for these rules to work correctly. You may need to add additional rules that allow this traffic to pass. For example, you can add the icmp all rule that allows all internet control messages to pass.

You can use the administration GUI or the command line (see Appendix B, Command-Line Reference) to set up the table of ordered rules for a policy, by means of which you can edit rule components, such as source and destination addresses, directly. You can change the order of the rules by dragging and dropping them through the configuration editor.

Rule Syntax

The basic syntax for a rule is:

Service Source_address Destination_address optional_Time optional_Encryption "action" optional_Proxy

where:

• Service - An individual network service or a group of services provided to users. Sample services are smtp, rlogin, and ftp.

• Source_Address - An address object from the client side over which these services are provided to users. Named addresses to define the network elements that make up the configuration. A named address can represent an individual address, a range of addresses, or a group of addresses. Named addresses are also used to define the network interfaces.

• Destination_Address - An address object from the server side over which these services are provided to users. Named addresses to define the network elements that make up the configuration. A named address can represent an individual address, a range of addresses, or a group of addresses. Named addresses are also used to define the network interfaces.

  ---

  Note -

  The version of SKIP that you can use for encryption, is one of two forms: (1) SKIP_VERSION_1 source_cert dest_cert key_algorithm data_algorithm, or (2) SKIP_VERSION_2 source_cert dest_cert key_algorithm traffic_algorithm mac_algorithm.

  ---

Encryption is only supported if ALLOW is selected. It is not supported if any proxy or VPN is selected. Encryption works as follows:

• If the first certificate is local (the secret key is loaded into SKIP on the Screen), then the rule is considered an encryption rule. The packet will be encrypted on its way out of the Screen.

• If the second certificate is local, then the rule is considered a decryption rule, and the packet will be verified as having been decrypted accordingly (correct certificates and algorithms) before it is allowed to pass.

• If neither certificate or if both certificates are local, then the rule is ignored by the compilation process.

• Action - What the Screen should do with packets. The choices are ALLOW and DENY. The syntax for specifying an action is in the form: ALLOW LOG_options SNMP_options; for example, ALLOW LOG_SUMMARY SNMP_NONE,or DENY LOG_options SNMP_options ICMP_options; for example DENY LOG_SUMMARY SNMP_NONE ICMP_HOST_UNREACHABLE.

  ---

  Note -

  Using the underscore with LOG, SNMP, and ICMP options is optional; for example, LOG_SUMMARY or LOG SUMMARY.

  ---

• Proxy - (Optional) The name of the proxy to be enabled and any flags for the proxy. Proxy flags are only permitted in a rule when the service is a PROXY_* service, where * is the type of proxy and the flags must be of the type for that proxy. The syntax for specifying a proxy is in the form: PROXY_proxy_name proxy_name flags; for example, PROXY_HTTP HTTP flags, PROXY_FTP FTP flags, or PROXY_SMTP SMTP flags. The telnet proxy does not take flags.

• User - (Optional) A name in the proxy database of users. The syntax for specifying a user is USER user_name, where user_name is a name in the proxy database.

  ---

  Note -

  The optional User field is only supported if the rule is Proxy-ftp or Proxy-telnet. Otherwise, the Screen does not support user-based rule criteria.

  ---

• Time - (Optional) A component by means of which you can set up time-of-day-based Policy Rules. The syntax for specifying time is in the form: time_object_name.

• VPN - (Optional) A component by means of which you to no longer specify all the SKIP information, but have the Screen do it. The syntax for specifying VPN is in the form: vpn_name.

  ---

  Note -

  VPN is not support if any SKIP information is specified, if DENY is selected, or if any Proxy is specified.

  ---

Example of a Rule Configuration

The XYZ Company wants to set up a series of rules to implement the following security policies:

1. Allow telnet traffic from A (an address object representing an individual host) to B (an address object representing any host on a specified network).

2. Deny and log mail traffic between A and B.

3. Send NET_UNREACHABLE ICMP rejection messages for rejected telnet traffic.

4. Discard all other packets.

TABLE 3-1 illustrates the rules the XYZ Company would set up to implement this security policy. Note that the default action would be specified as DENY for each interface to implement policy 4.