Policy Rules

You can define rules and order them either from the administration GUI or the command line editor.

You set up ordered policy 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 forms a policy.

When you install SunScreen, 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 when 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 VPN, ENCRYPT, or ALLOW action.

Sequence of Rules

The sequence in which rules are ordered is critical. When the Screen processes packets, it compares the packet information to each rule in order. 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 properly. In general, services which require more sophisticated protocol knowledge must appear before or within a rule which would allow the same traffic through a less-sophisticated service definition. If you want to deny FTP packets, for example, you must place the rule denying FTP packets before the more general rule that allows common services:

1. ftp * * DENY
2. common services * * ALLOW

If you put the common services rules before the ftp rule, FTP packets will be allowed because ftp is one of the common services.

For a more complex example, consider the case of a service group such as tcp_all, which does not include services such as ftp, rsh, and realaudio. If you want to deny FTP packets and a tcp_all rule occurs before the ftp DENY rule, the tcp_all rule will pass the ftp 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 rule been placed first.

Services and Service Groups in Rules

When a packet filter checks to see if a packet matches a rule, the difference between a 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.

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, the tcp_all rule will pass the ftp 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.

Configure stealth mode to identify the network and netmask that the Screen partitions 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, etc.), 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.

Rule Syntax

See the SunScreen 3.2 Administration Guide for procedural information about creating SunScreen policies with the administration GUI. The basic command-line syntax for a rule is:

Service Source_address Destination_address "action" (ALLOW or DENY) plus optional fields: Time Screen Comment Encryption Proxy User VPN

See "add rule" in the man page for ssadm-edit(1M) and "add rule" for more information about command line rule syntax.

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

• Source_address - An individual network address, a range of addresses, or a group of addresses. Named addresses are also used to define the network interfaces. "Source" refers to the network address from which the packet is coming.

• Destination_address - An individual network address, a range of addresses, or a group of addresses. Named addresses are also used to define the network interfaces. "Destination" refers to the network address to which the packet is going. See "Address Object" for more information.

• "action" - What the Screen should do with packets. The action choices are ALLOW (default) and DENY (only ALLOW is valid for encryption actions; only DENY is valid for ICMP actions). The command-line syntax for specifying an action is in the form: ALLOW LOG_options SNMP_options (for example, ALLOW LOG_SUMMARY SNMP_NON) or DENY LOG_options SNMP_options ICMP_options (for example, DENY LOG_SUMMARY SNMP_NONE ICMP_HOST_UNREACHABLE). The first underscore shown above with LOG, SNMP, and ICMP options is not required. For example, you can use either LOG_SUMMARY or LOG SUMMARY, SNMP_NON or SNMP NON.

• Time - (Optional) A component for setting up time-of-day-based Policy Rules. The command-line syntax for specifying time is in the form TIME name_TIME .

• Screen - (Optional) Screen name; command-line syntax is of the form SCREEN name_SCREEN

• Comment - (Optional) Text that clarifies the purpose of a rule; command-line syntax is of the form COMMENT "comment string."

• Encryption - (Optional) The type of encryption (SKIP, IPSEC, or VPN) to be used when transferring packets. Encryption is only supported if ALLOW action 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 or IKE on the Screen), 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, 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 is local or if both certificates are local, the rule is ignored by the compilation process.

• 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. They are only valid in a rule that has not specified any encryption parameters nor VPN. The command-line syntax for specifying a proxy is of the form: PROXY_proxy_name proxy_flags; for example, "PROXY_HTTP ACTIVE_X JAVA," "PROXY_FTP FTP_GET," or "PROXY_SMTP NO_RELAY." The Telnet proxy ("PROXY_Telnet") does not take flags.

• User - (Optional) A name in the proxy database of users. The command-line 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 required if the rule is PROXY_FTP or PROXY_Telnet, and is optional if the rule is PROXY_HTTP. Otherwise, the Screen does not support user-based rule criteria.

  ---

• VPN - A component that makes it possible to define your security policy with fewer rules because the Screen automatically generates the multiple rules containing all the SKIP or IKE information that the VPN defines. A VPN is group of Screens that transfer encrypted data among themselves over the public network. The command-line syntax for specifying VPN is of the form: vpn_name.

  ---

  Note -

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

  ---

Example of a Rule Configuration

XYZ Company wants to set up SunScreen rules to implement the following security policy:

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

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

3. Deny all other telnet traffic and send NET_UNREACHABLE ICMP rejection messages for rejected traffic.

4. Discard all other packets.

The table below illustrates the SunScreen rules that the XYZ Company would set up to implement this security policy. Note that the default action for services not expressly mentioned in a rule would be specified as DENY.