Dynamic Packet Filtering

Dynamic packet filtering enables a Screen, which sits between the client and server, 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 to be allowed, what to do with packets for services that are disallowed, and what to do 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 the order in which they are numbered. The Screen does not test each packet against each rule; it assumes that the first rule to match the service, source address, and destination address of the packet addresses is the rule that governs the disposition of the packet. Additionally, if the applicable rule so specifies, the Screen can record a log message or generate an SNMP alert.

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, as shown in FIGURE 3-1.

Figure 3-1 Rule Processing Order in a Screen

When a host on a private (internal) network sends a packet addressed to an outside host through a Screen, the Screen does the following:

1. The Screen applies its packet filter 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 a DENY rule, then the packet is denied and, if so specified, can make a log entry identifying the circumstances.

2. If the packet meets the criteria of an ALLOW rule, the Screen determines whether it should use NAT to convert the source IP address information in the packet. If NAT is being used, the source address information in the packet is modified. Depending on the type of packet, the Screen may also modify address information in the data portion of the packet or modify packet checksums.

3. The Screen determines if 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, which identifies the appropriate encryption keys and algorithms and encrypts the packet. The SKIP key manager passes the encrypted packet back to the Screen, which then forwards the packet to the public network.

When a Screen receives a packet addressed to an internal host from a host on the public network, it performs a similar sequence of actions:

1. If the incoming packet has been encrypted with the Screen's public key, the Screen calls the SKIP key manager, which identifies the appropriate keys and decrypts the packet. The SKIP key manager passes the decrypted packet back to the Screen.

2. The Screen determines whether it should use NAT to convert the packet's destination IP address to an internal IP address. If NAT is being used, the address information in the packet is modified.

3. 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 to the internal network. If the packet meets the criteria of a DENY rule, then the packet is denied.