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.