In order to determine who can do what, you must create rules. The rules are created in terms of objects and services as defined in the previous section. Rules should be listed in the order you want them enforced. In the following subsections, I discuss the actual order in which rules are applied, but for the sake of discussion at this point, let's assume they will be enforced in the order shown in the rulebase. The Parts of a RuleEach rule has several elements. In many cases in this book, I will not show all the elements because they are not always relevant. However, in this section, I discuss all of them. Source and DestinationIn the Source and Destination parts of the rule, you input the hosts that will be allowed to originate a connection or will be an allowed destination for a connection. Multiple objects can be listed in this part of the rule. If there are multiple sources or destinations listed in a rule, they are treated as an OR, meaning that any host that matches will be allowed. If ViaA VPN Community is specified in this column, which will be present when Simplified mode is enabled in the Global Properties screen for VPN-1 Pro. The If Via part of the rule indicates that this rule will apply if the connection is coming from or going to a member of the VPN Community specified (i.e., it will be encrypted or decrypted). If this column contains Any (the default), no encryption will be used for this rule. Chapter 11 covers this in more detail. ServiceIn the Service part of the rule, you input the services that are allowed between the source(s) and destination(s) listed in the rule. If there are multiple services listed, they are treated as an OR, meaning that any service listed in the rule will match. ActionIf the source, destination, and services match, an action is applied. The Action part of the rule can have the following values.
TrackAfter an action is taken on the packet, you need to determine how to log it. There are several options you can choose; more details about these options appear in Chapter 5.
Install OnIn the Install On part of the rule, you indicate which gateway(s) will be responsible for enforcing this rule. These can be gateways (the default), integrated firewalls, a specific target, or Src or Dst. Src causes the rule to be installed on all gateways and enforced only in the outbound direction. Dst causes the rule to be installed on all gateways and enforced only in the inbound direction. TimeIn the Time part of the rule, you select a time object that represents when this rule will apply. If the time/date does not match, the rule does not apply. CommentThe Comment part of the rule contains a description of the rule. In some versions of FireWall-1, a carriage return in a comment can cause problems, so try to avoid using carriage returns. Also, it is unwise to use characters that are not typically ASCII characters (like umlauts) because they can sometimes cause a policy installation to fail. Sample RulesFigure 4.28 shows a sample rule that is fairly common in most installations. This rule permits the internal network to use HTTP, HTTPS, and SSH to any host not on the internal network. [4] Another common rule is shown in Figure 4.29.
Figure 4.28. Rule to permit services from internal network
Figure 4.29. Rule to permit SMTP from the Internet to the e-mail server
Figure 4.30 shows another rule you will commonly see. This rule drops all packets and logs the packets. It shows up as the last rule in your rulebase. It is commonly referred to as the Cleanup rule. Figure 4.30. Rule to drop all traffic
Order of OperationsEstablished connections are allowed provided they are listed in the state tables and are accepted and address translated as necessary. For new connections, FireWall-1 and surrounding pieces follow this order of operations:
The rulebase is applied in the directions specified in rules by the Install On field. In most cases, it means both entering and leaving the gateway. However, if a rule specifies Src (outbound) or Dst (inbound), the rule applies only in that direction. Once a packet matches a rule, it performs the action listed in the Action field, and no further rulebase processing occurs on that packet. For authenticated connections not going through Security Servers, the rules and properties are processed in the following order.
Figure 4.31 shows a diagram of the preceding sequence, which helps demonstrate what happens during this process. Note that dropped packets may be logged prior to reaching the end of the flowchart, depending on the circumstances and configuration. Figure 4.31. Flowchart of rulebase evaluation order
Various versions of the FireWall-1 documentation state that the rules are examined in the sequence they are presented in the rulebase. This is generally correct, but you must also take into consideration what is permitted by the settings on the Properties screens. The rules that result from the Properties settings (i.e., the Properties rules) will be enforced appropriately with respect to your rulebase. This means the Properties rules marked First will be applied before your rulebase, Before Last will be applied between rules n 1 and n , and Last will be applied after your last rule. There is one case where FireWall-1 does not process the rules in order but instead uses the rule that is most permissive: when authentication for HTTP, FTP, Telnet, and rlogin is used and such a rule is matched in the rulebase. If a user authentication rule matches the packet (i.e., the source, destination, and service match), then before authentication occurs, all rules in the rulebase are evaluated. The least restrictive rule will be used. An example of this is shown in Chapter 8. So what is a good rule of thumb when ordering the rules in your rulebases ? The following list shows how I typically order my rulebase based on action types:
Note that any rules that will be used heavily should be moved as close to the top of the rulebase as possible because it will improve performance, particularly if there are more than 30 rules. |