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.
When you install the SunScreen EFS 3.0 software, you start with a policy object 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 Encryption or Allow action.
The sequence in which rules are ordered is critically important. 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.
You can use the administration GUI or the command line (see Appendix B) to set up the table of ordered rules for a policy, which allows you to 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.
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 email, remote login, and ftp.
Addresses - Named addresses to define the network elements that make up the configuration. A named address can represent an individual address, as a range of addresses, or as a group of addresses. Named addresses are also used to define the network interfaces.
Source_Address - An address object from the client side over which these services are provided to users.
Destination_Address - An address object from the server side over which these services are provided to users.
Encryption - (Optional) The version of SKIP to used for encryption, in one of two forms: SKIP_VERSION_1 source_cert dest_cert key_algorithm data_algorithm, or 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_information SNMP_information; for example, ALLOW LOG_SUMMARY SNMP_NONE or DENY LOG_INFORMATION SNMP_INFORMATION ICMP_INFORMATION.
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_SNMP SNMP 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.
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 that allows time-of-day-based Policy Rules. The syntax for specifying time is in the form: time_object_name.
VPN - (Optional) A component that allows you to no longer specify all the SKIP information, but have the Screen do it for them. The syntax for specifying VPN is in the form: vpn_name.
VPN is not support if any SKIP information is specified, if DENY is selected, or if any Proxy is specified.
The XYZ Company wants to set up a series of rules to implement the following security policies:
Allow telnet traffic from A (an address object representing an individual host) to B (an address object representing any host on a specified network).
Deny and log mail traffic between A and B.
Send a NET_UNREACHABLE ICMP rejection messages for rejected telnet traffic.
Discard all other packets.
TABLE 2-2 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.
Table 2-3 Sample Rules Table
Service |
From |
To |
Rule Type |
Log |
SNMP |
ICMP |
---|---|---|---|---|---|---|
telnet |
A |
B |
Allow |
NONE |
NONE |
NONE |
|
A |
B |
Deny |
SUMMARY |
NONE |
NONE |
|
B |
A |
Deny |
SUMMARY |
NONE |
NONE |
telnet |
* |
* |
Deny |
NONE |
NONE |
NET_UNREACHABLE |