Chapter 3 Packet Filtering

This chapter describes a possible SunScreen configuration and explains what packet filtering is. It includes the following topics:

• "SunScreen Model"

• "Stateful Packet Filtering"

• "Policy Rules"

• "Policy Versions"

SunScreen Model

When a packet passes from system A to system B, the following takes place:

1. System A looks in its routing table for a route to system B and finds one through the firewall.

2. System A must send the packet to the firewall for routing to system B. It sends out an ARP (address resolution protocol) request and receives a reply from the firewall. System A now knows the MAC address of the firewall and sends the packet to the firewall.

3. The firewall takes the packet and compares its source IP address, destination IP address, and service against the rules. If the rules permit passing the packet, a state-table entry is created and the packet is passed to the routing interface nearest system B (routed).

4. The firewall sends out an ARP request to get the unique MAC (media access control) address of system B; the packet is sent to system B.

5. If this packet is part of a session that requires packets to flow back to system A from system B, they are passed because the state-table entry created allows this. In an HA configuration, all members of the HA cluster must have the same state-table entries. If they do not, sessions can be dropped if the active Screen fails and a passive Screen becomes the active Screen.

Stateful Packet Filtering

A Screen, which sits between the client and server, uses stateful packet filtering to examine each data packet as it arrives. Based on information in the packet, state retained from previous events, and a set of security policy rules, the Screen either passes the data packet, or blocks and drops it.

SunScreen uses a set of ordered rules to filter packets. When you configure SunScreen, you translate the security policies for your site into a series of policy rules that specify which services are allowed, what to do with packets for services that are disallowed, and what action to take when packets are dropped. You then place these policy rules in sequence to specify which rules override others.

When the Screen receives a packet, it tests the packet against the rules in a policy in order. The Screen does not need to test each packet against each rule; it assumes that the first rule to match the service, source address, and destination address of the packet is the rule that governs the disposition of the packet. Additionally, if the applicable rule so specifies, the Screen records a log message or generates an SNMP (simple network management protocol) alert.

Spoof detection and checking against existing connections occurs before policy rules checking.

If the packet does not match any rule, the Screen uses its default action for the interface on which the packet arrived to determine the disposition of the packet. Typically, this action logs the packet and drops it; other actions such as logging and emitting an ICMP or SNMP message are available options.

The sequence in which a Screen performs packet filtering, network address translation, and encryption and decryption depends on the direction in which the packets are moving, for routing mode as shown in Figure 3-1.

Figure 3-1 Rule Processing Order in a Routing Mode Screen

Inbound Packet Rule Checking

When a packet arrives on any of the defined interfaces it is:

1. Decrypted if it has been encrypted with the Screen's public key. The Screen calls the SKIP key manager or IKE, which identifies the appropriate keys and decrypts the packet. The SKIP key manager or IKE passes the packet back to the Screen.

2. Translated, if necessary. The Screen determines whether it should use NAT to convert the packet's destination IP address to an internal address. If NAT is used, the destination address information in the packet is changed to the translated destination address.

3. Filtered according to the packet-filtering rules. The Screen applies its filtering rules to the packet to determine whether the packet meets the criteria of an ALLOW or DENY rule. If the packet meets the criteria of an ALLOW rule, the Screen forwards the packet. If the packet meets the criteria of a DENY rule, it is denied. If so specified, the Screen can create a log entry identifying the circumstances.

A packet is only tested against the packet-filtering rules once.

Outbound Packet Rule Checking

If the packet is allowed by the rules (and is not destined for the Screen itself), before being sent out on the appropriate interface, it is:

1. Translated - The Screen determines whether it should use NAT to convert the source address information in the packet. If NAT is being used , the translated source address information is modified to the source address. Depending on the type of packet, the Screen may also modify address information in the data portion of the packet or modify packet checksums.

2. Encrypted - The Screen determines whether the packet should be encrypted based upon the information in the rule that matched. If the packet should be encrypted, the Screen calls the SKIP key manager or IKE, which identifies the appropriate encryption keys and algorithms and encrypts the packet. The SKIP key manager or IKE passes the encrypted packet back to the Screen, which then forwards the packet.

A packet is only tested against the packet-filtering rules once.

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.

Policy Versions

The currently active policy is the policy currently being used to filter network traffic. The currently active policy, which is displayed in the Policies List of the administration GUI and which can be determined from the command line by typing ssadm active, cannot be modified. You can make the common objects embedded in this version of the policy the current common objects, overwriting the existing set of common objects.

A regular policy (that is a policy without a version number) uses the current set of common objects and shares the common objects with other regular policies.

Each version of a policy has an associated version number. Edited policies automatically generate an historical version or snapshot of the common objects that are saved for reference. The version is shown by the incremental number after the dot in the name of the policy--the higher the number, the later the version. A version of a policy must be copied as a new policy with a new name before it can be activated.

Version numbering is implemented through the administration GUI or by using the edit subcommand of the ssadm command. A new version is created every time a configuration is saved.

A new version of a policy supersedes older versions. The older version still includes specific information and the actual content of the common object registry, not just a reference. An older policy version can become invalid because of changes to the network topology or to SunScreen host hardware or both.

The registry is the database of common objects. Each policy refers to a single registry. The versions of the policies have their own registry because the versions are histories.

You can copy a policy to a new name. You can edit a policy and save the changes to a new name to create a new policy. The rules can become the current rule for a policy; for example, the rules for policy Initial.10 can be made the rules for the current version of Initial.

The rules created in this way are used with the current set of common objects. On verifying this policy, you may have to fix any inconsistencies.