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.
Each 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.
In 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.
A 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.
In 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.
If the source, destination, and services match, an action is applied. The Action part of the rule can have the following values.
Accept: Allow the connection through the firewall.
Drop: Do not allow the connection through the firewall; give no notification to the sender.
Reject: Do not allow the connection through the firewall; notify the sender with a TCP Reset message or an ICMP Destination Unreachable message as appropriate.
User/Client/Session Auth: Allow the connection through the firewall provided the user successfully authenticates. See Chapter 8 for more details on these actions.
Encrypt/Client Encrypt: Allow the connection through the firewall and encrypt or decrypt the packet. This option will show up only if Traditional VPN mode is used and is covered in Chapters 11 and 12.
After 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.
None: Do not log.
Log: All available information about the packet is written to the log.
Account: This is usually used with a rule using an action of accept. The number of bytes and length of the connection are logged to the accounting log file as well as a normal long log entry, which is written to the normal log. Do not use this option lightly because it can significantly increase the amount of CPU time FireWall-1 uses to log the information.
Alert/Mail Alert/SNMP Trap/User Defined: Make a long log entry and execute an action to notify the administrator.
In 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.
In 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.
The 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.
Figure 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.
[4] You might wonder why I did not choose Any in the Destination field. Typically, you do not need the firewall to reach the internal network. Any, although a setting even I use in a rulebase from time to time, is considered insecure. For more details about this setting, consult the Black Hat 2000 Security briefing on FireWall-1, which can be found at http://www.dataprotect.com/bh2000/. There is also a mirror of this document at http://www.phoneboy.com/docs/bh2000/.
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.
Established 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:
Inbound anti-spoof check (verifies that the source IP is included in the interface's Topology setting)
Inbound check against the rulebase (includes properties)
NAT, if appropriate properties are enabled (see Chapter 10)
Outbound check against the rulebase (includes properties)
NAT, if appropriate properties are not enabled (see Chapter 10)
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.
Rulebase properties listed as First are processed. Matches are accepted and not logged.
Rules 1 through n?1 (assuming n rules) are processed and logged according to their individual settings.
Rulebase properties listed as Before Last are then processed. Matches are accepted and not logged.
Rule n is processed and logged according to its setting.
Rulebase properties listed as Last are then processed. Matches are accepted and not logged.
The Implicit Drop rule is matched (no logging occurs).
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.
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:
Client Encrypt rules
FireWall to FireWall Encryption rules
Incoming (from Internet) Accept rules
Outgoing (to Internet) Accept rules
Client Authentication rules
Session Authentication rules
User Authentication rules
Cleanup rule (drop all)
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.