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.