rule(4)

NAME
rule - packet filtering rule for SunScreen configuration

DESCRIPTION
A rule object is a collection of information that describes network traffic of given type between specified addresses and what to do with that traffic when it arrives at the SunScreen. It is manipulated via the configuration editor or SunScreen administration GUI.

A packet filtering rule contains, minimally, a reference to a Service, to a source address and to a destination address. It may optionally include references to a Time object and SKIP information.

A packet matches a packet filtering rule if its source IP address is contained in the source address in the packet filtering rule, its destination IP address is contained in the destination address in the packet filtering rule, the destination port is contained in the service in the packet filtering rule, if a time is referenced in the packet filtering rule then the current time is included in that time, and if the packet filtering rule expects to have decrypted the packet that it was originally encrypted using expected certificates and algorithms.

A packet filtering rule can be one of two major sub-types: ALLOW and DENY. ALLOW passes the traffic through the Screen, while DENY drops the packet.

A packet filtering rule can log a packet if so indicated with the LOG keyword. The values for LOG are: NONE (same as not set), SUMMARY, and DETAIL. If the packet filtering rule type is ALLOW, then the SESSION type is also valid.

A packet filtering rule can emit an SNMP packet if so indicated with the SNMP keyword.

A DENY packet filtering rule can specify an ICMP packet to be sent to the originator via the ICMP keyword. The values for this field are: NONE (same as not set), NET_UNREACHABLE, HOST_UNREACHABLE, PORT_UNREACHABLE, NET_FORBIDDEN, or HOST_FORBIDDEN.

If the packet filtering rule is to be part of a VPN, the optional VPN field is set with a reference to the VPN of which the packet filtering rule is to be a part. The packet filtering rule must be an ALLOW rule and cannot have any other SKIP-related data specified, nor may it be a proxy rule as described below.

If the packet filtering rule is to be a SKIP-related rule, and not part of VPN, its SKIP data can be specified. There are two types of SKIP data: SKIP_VERSION_1 and SKIP_VERSION_2. They differ in the protocol of SKIP they invoke and SKIP_VERSION_2 requires a MAC and COMPRESSION algorithm. Their syntax is: SKIP_VERSION_1 "name of certificate" "name of certificate" "name of KEY algorithm" "name of Data algorithm" and SKIP_VERSION_2 "name of certificate" "name of certificate" "name of KEY algorithm" "name of Data algorithm" "name of MAC algorithm" "name of COMPRESSION algorithm".

Optionally, in a set of SKIP-related data, a SOURCE_TUNNEL or DESTINATION_TUNNEL address may be specified, which are references by name to addresses.

A packet filtering rule may be a proxy rule, in which case the type of proxy will be indicated by one of these keywords: PROXY_FTP, PROXY_HTTP, PROXY_SMTP or PROXY_Telnet. If the packet filtering rule is a proxy rule, it cannot be a VPN rule, nor have any SKIP-related data associated with it. It if is a PROXY_FTP or PROXY_Telnet type, it must have an associated USER "name of user" file associated with it in order for the proxy server to perform user-level authentication.

Each type of proxy rule has associated with it a set of capabilities which are enabled or not by keyword flags. If a flag is not set, it is the same as if N_<FLAG> were specified, and the capability is disabled. If a proxy rule is a DENY Rule, then none of the flags may be set.

The FTP Proxy allows the following flags to be set: FTP_GET, FTP_PUT, FTP_CHDIR, FTP_MKDIR, FTP_RENAME, FTP_REMOVE_DIR, FTP_DELETE.

The HTTP Proxy allows the following flags to be set: COOKIES, ACTIVE_X, SSL, JAVA, JAVA_SIGNATURE_HASH, JAVA_SIGNATURE, JAVA_HASH. The SMTP Proxy allows the following flag to be set: RELAY

The telnet Proxy does not support any flags.

All packet filtering rules may have an optional COMMENT field associated with them which is a 256-character or less user-provided comment.

All packet filtering rules may be optionally associated with a specific SCREEN object. If a packet filtering rule is so associated, it will only be instantiated on the Screen with which it is associated.

A packet filtering rule is uniquely identified by its position in the list of rules. This numeric position is its identity regradless of any association with a SCREEN object. This identity may change as other packet filtering rules are added to the list.

SEE ALSO
ssadm-edit(1M), address(4), certificate(4), screen(4), proxyuser(4), service(4), time(4), vpngateway(4)