After creating or modifying a Firewall Policy, you must transfer the changes to the engine using the Management Client. You can either install the policy (transfers the policy you select) or refresh the policy (transfers the most recent version of the policy that the engine already uses).
You can install the same Firewall Policy on several engines.
When you install a modified or a completely new Firewall Policy, any existing connections that are not allowed by the new Firewall Policy are dropped. The existing connections allowed by the new Firewall Policy are not affected; they continue uninterrupted. These include related
connections and authenticated connections on the engines.
Policy installation transfers any new engine configuration information in addition to the Firewall Policy. Whenever you update the engine’s configuration, you must reload the Firewall Policy on the engine to make the changes take effect. This includes, for example, changes in the routing configuration, the VPN configuration, and the properties of the Firewall, Master Engine, or Virtual Firewall element itself, even if the changes are not directly related to the rules in the Firewall Policy.
If the Firewall Policy installation fails, the system automatically rolls back to the previously installed configuration. By default, a rollback also occurs if the system detects that the new Firewall Policy or related configuration (such as routing configuration) does not allow the Management Server to connect to the engines. This safety feature prevents an administrator from inadvertently installing a configuration that would cause the critical management connections to fail.
94 Chapter 9 Firewall Policies
Using Policy Elements and Rules
The main points of using policy elements are explained in the preceding sections of this chapter.
The sections below illustrates additional points that are useful to know when working with policies and rules:
•Validating Policies
•User Responses
•Connection Tracking vs. Connectionless Packet Inspection (page 95)
•Policy Snapshots (page 97)
•Continue Rules (page 97)
•Adding Comments to Rules (page 97)
•Naming Rules (page 98)
Validating Policies
The number of rules in a Firewall Policy may grow quite large over time. It may become quite difficult, for example, to notice configuration errors in a policy. To make policy management easier and to make sure that the policy does not contain misconfigured rules, you can
automatically validate the policy during editing as well as during the policy installation process.
You can select different criteria for validating the policy. You can, for example, check the policy for duplicate and empty rules or check if there are rules that cannot match traffic.
Additionally, the engines automatically count how many times each Access rule has matched.
Engines also count the number of matches to NAT rules. You can run an analysis over a selected time frame in the policy editing view to display rule counter hits for each rule (in the Hits cell).
This allows you to find otherwise valid rules that are unnecessary because they match traffic that does not appear in your networks.
User Responses
The User Response element allows you to send a configurable server reply to the client instead of just ending the TCP connection when an HTTP connection is terminated or blacklisted. The reply can be a custom error message, or an HTTP redirect to a specified URL. The User Response is selected in the Action options in Access rules and in the Exceptions in the Inspection Policy. User Responses are not supported on Master Engines, or Virtual Firewalls.
Connection Tracking vs. Connectionless Packet Inspection
Connection tracking means that the engine keeps a record of all currently open connections (stateful inspection). With connection tracking, the engine can verify that the connection proceeds according to the protocol standards. Connection tracking is also required for modifying addresses using NAT and enforcing some other connection-related settings. By default,
connection tracking is on.
However, it is not necessary to keep track of the state of certain kinds of connections (for example, SNMP traps). Some applications may also communicate in a non-standard way that prevents them from being allowed through the engine when connection tracking is used. For those connections, you can disable connection tracking in the Access rules. This allows the engine to function as a simple packet filter for those connections. However, this also prevents the use of some features that require connection tracking.
When connection tracking is off, each packet that you want to allow must match an Access rule that allows the packet. This means that even if two-way communications are always opened one way, both directions of communication must be explicitly allowed in Access rules. Reply packets are not recognized, so they are not automatically allowed through. If done carelessly, turning connection tracking off reduces the benefits you gain from your engine and may even weaken security. You may have other options: in some cases using the correct Protocol Agent helps.
When connection tracking is enabled in an Access rule, the Service cell of the rule must contain one of the protocols supported for connection tracking (ICMP, TCP, UDP, or another protocol that belongs to the IP protocol suite). ICMP and UDP are stateless protocols that do not contain any connection data. However, ICMP and UDP packets contain data that the engine can use to build virtual connections. The engine can also build virtual connections based on the IP address and IP protocol data in other types of IP packets.
You can choose between several connection tracking modes, depending on the traffic type and how strictly you want the connections to be tracked. The effect of the connection tracking setting in the Access rules depends on the traffic type. The available options are explained in Table 9.2.
Note – Before disabling connection tracking, always check if there is a Protocol Agent for the protocol in question. The Protocol Agents can pass connections that require special handling when connection tracking is on, which is always a more secure option.
Table 9.2 Connection Tracking Modes in Access Rules
Mode Explanation
Inherited from Continue Rule(s)
The connection tracking setting defined in the Continue rule(s) higher up in the policy is used.
The additional options available for connection tracking are explained in the next table.
Note! If connection tracking is disabled in Continue rule(s) higher up in the policy, the Firewall behaves as described in the Off (Not recommended) explanation below.
96 Chapter 9 Firewall Policies
If Connection Tracking is on, you can also set the Idle Timeout for connections. The timeout is meant for clearing the engine’s records of old connections that the communicating hosts leave hanging. The timeout concerns only idle connections, so connections are not cut because of timeouts while the hosts are still communicating. The timeout defined for an Access rule overrides the default idle timeout value that is set for the protocol in the engine’s properties.
Off (Not Recommended)
Connection tracking is disabled. The Firewall operates as a simple packet filter and allows packets based on their source, destination, and port. You must add separate Access rules that explicitly allow the reply packets. NAT cannot be applied to traffic allowed without connection tracking.
Note! Turn off logging in the rule if you disable connection tracking. When connection tracking is off, a log entry is generated for each packet. This may put considerable strain on the engine, network, and the Log Server.
Defined in Engine Properties
The Firewall allows or discards packets according to the Connection Tracking mode selected in the Firewall properties.
Protocols that use a dynamic port assignment must be allowed using a Service with the appropriate Protocol Agent for that protocol (in Access rules and NAT rules).
The additional options available for connection tracking are explained in the next table.
Normal
The Normal mode is the default Connection Tracking Mode for Firewalls.
The Firewall drops ICMP error messages related to connections that are not currently active in connection tracking (unless explicitly allowed by a rule in the policy). A valid, complete TCP handshake is required for TCP traffic. The Firewall checks the traffic direction and the port parameters of UDP traffic. If the Service cell in the rule contains a Service that uses a Protocol Agent, the Firewall also validates TCP and UDP traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped.
Strict
The Firewall allows only TCP traffic that strictly adheres to the TCP standard as defined in RFC 793. The Firewall also checks the sequence numbers of the packets in pre-connection establishment states and for RST and FIN packets, and drops packets that are out of sequence. If the Service cell in the rule contains a Service that uses a Protocol Agent, the Firewall also validates the traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped.
Loose
The Firewall allows some connection patterns and address translation operations that are not allowed in the Normal mode. This mode can be used, for example, if routing is asymmetric and cannot be corrected or if the use of dynamic routing protocols causes the Firewall to receive non-standard traffic patterns.
Caution – Setting excessively long timeouts for a large number of connections may consume engine resources and degrade engine performance and stability. Be especially careful when defining timeouts for ICMP and UDP. The ICMP and UDP virtual connections do not have closing packets, so the engine keeps the records for the ICMP and UDP connections until the end of the timeout.
Table 9.2 Connection Tracking Modes in Access Rules (Continued)
Mode Explanation
Connection Tracking options in Access rules also allow you to override the limit for concurrent connections from a single source and/or destination IP address defined on the Advanced tab in the Security Engine properties, in Virtual Resource properties, and in the properties of some interface types. When the set number of connections is reached, the next connection attempts are blocked by the engine until a previously open connection is closed.
Changes in the Connection Tracking mode affect how existing connections are handled when you install or refresh the policy. When you install or refresh the policy on an engine, the engine checks if the existing connections are still allowed in the policy. If the connection tracking mode changes from Loose to Strict, existing virtual ICMP connections are only allowed if they began with a valid packet (for example, not with a response packet). In addition, if the mode changes from Normal to Strict, existing TCP connections are only allowed if all the packets in the connection have been seen. In all other cases, changes in connection tracking mode do not affect existing ICMP, TCP, and UDP connections at policy installation.
Policy Snapshots
A Policy Snapshot is a stored record of a policy configuration. A Policy Snapshot is stored in an engine’s upload history whenever a policy is installed or refreshed on the engine. The Policy Snapshots allow you to the check which Firewall Policies, and other configuration information were uploaded, and when they were uploaded. You can also compare any two Policy Snapshots and see the differences between them.
Continue Rules
The Continue action for a rule sets default options (such as logging options, idle timeout, etc.) for the traffic matching process. Options set in Continue rules are used for subsequent rules that match the same criteria as the Continue rule, unless the rules are specifically set to override the options. Continue rules are also very useful in the hierarchical structure of the policies. Firewall Template Policies are particularly convenient for setting options with a Continue rule, because all the Firewall Policies and Template Policies that use the Firewall Template Policy inherit the option settings you have specified. Continue rules are explained in detail in Configuring Default Settings for Several Rules (page 111).
Adding Comments to Rules
Each policy can contain a large number of rules. Adding comments provides administrators with useful information and also makes it easier to read policies. You can add comments to all types of rules. In rule tables, you can add comments in the rule’s Comment cell. You can also add a Rule Section that begins with a comment row and can contain one or more rules.
The Rule Section automatically contains all the rules below the Rule Section until the next Rule Section in the policy. You can expand and collapse the Rule Sections as necessary. The comment row in a Rule Section is displayed on a colored background (with configurable colors).
This makes Rule Sections particularly useful in visually separating the sections of rules within a single policy.
98 Chapter 9 Firewall Policies
Naming Rules
In addition to comments, it is possible to specify an optional name or short description for Access rules and NAT rules in Firewall Policies, Exceptions in Inspection Policies, and rules in QoS Policies and Alert Policies. Names help administrators identify individual rules in large rule tables. You can also search for a rule by its name. If a rule has been named, the name is displayed in the Logs view as well.
Examples of Policy Element Use
The examples in this section illustrate some common uses for the different policy elements and general steps on how each scenario is configured.
Protecting Essential Communications
Company A has a firewall system administered by multiple administrators of various degrees of familiarity with networking, firewalls, and McAfee Firewalls. The administrators must often make very quick changes to respond to the needs of the company and attend to any problems detected.
In this situation, it is possible that someone may accidentally alter the Firewall Policy in such a way that important services are cut off. The administrators decide to separate the rules allowing the most important business communications from rules that deal with non-essential traffic to minimize this risk. The administrators:
1. Create a new Firewall Template Policy and select the pre-defined Firewall Template as the basis of the policy.
2. Cut and paste the rules allowing essential communications from their current Firewall Policy into the new Firewall Template Policy.
•In this case, all administrators are allowed to edit the new Firewall Template Policy as well.
3. Add an insert point below the copied rules in the Firewall Template Policy.
•Having the insert point below the essential rules prevents the rules added to the inheriting Firewall Policy from affecting the essential communications.
4. Reparent their current Firewall Policy to use the new template, moving it down a step in the policy hierarchy.
5. After validating the policy and making sure that the rules are correct, refresh the current Firewall Policy.
•Since most daily editing is done in the Firewall Policy, there is less risk of someone accidentally changing the essential rules in the Firewall Template Policy, because the rules are not editable in the Firewall Policy.
Improving Readability and Performance
Company B has two separate DMZs, one for the extranet and one for other web services. The number of services offered is quite large. The company also has a large number of partners and customers that have varying access rights to the different services. The administrators realize that a large number of the rules in their policies are related to the DMZ connections. The rest of the rules govern access to and from the company’s internal networks. Many of the rules have
been entered over time by inserting them at the beginning of the rule table, so rules governing access to the different networks are mixed and finding all the rules that govern access to a particular network takes time.
The administrators decide that they want to make their Firewall Policy more readable and at the same time optimize the way the firewall handles traffic, so they:
1. Create two new Firewall Sub-Policies: one for each DMZ.
2. Cut-and-paste the rules from the current Firewall Policy into the correct Firewall Sub-Policy.
3. Add Jump rules into the Firewall Policy to direct the examination of traffic to/from the different networks into the correct Firewall Sub-Policy.
4. Refresh the Firewall Policy.
Restricting Administrator Editing Rights
Company C is implementing a distributed network with multiple sites: one central office where most of the administrators work, and a number of branch offices in different countries. The branch offices mostly have IT staff with only limited networking experience, but who are still responsible for the day-to-day maintenance of the network infrastructure at their site. They must be able to, for example, add and remove Access rules for testing purposes without always contacting the main administrators.
The administrators decide to limit the privileges of the branch office IT staff so that they are not able to edit the policies of the firewalls at any of the other sites. The administrators:
1. Create a new Firewall Template Policy and select the pre-defined Firewall Template as the basis of the policy.
2. Add rules to the Firewall Template Policy using Alias elements to cover the essential services that each of these sites has, such as the VPN connections to the central site.
•Using a common Firewall Template Policy for all the branch offices also eliminates the need to make the same changes in several policies, easing the workload.
3. Create a new Firewall Policy based on the new Firewall Template Policy for each of the branch office sites.
•Although a single Firewall Policy for all sites could work, in this case the administrators decide against it, since separate policies are needed for the separation of editing rights.
The policies are based on the same Firewall Template Policy, so rules can still be shared without duplicating them manually.
4. Grant each Firewall Policy to the correct Firewall element.
•After this, only the correct policy can be installed on each firewall. No other policy is accepted.
5. Create new administrator accounts with restricted rights for the branch office administrators and grant the correct Firewall element and Firewall Policy to each administrator.
•The branch office administrators are now restricted to editing one Firewall Policy and can install it on the correct firewall.
•The branch office administrators are not allowed to edit the Firewall Template Policy the
100 Chapter 9 Firewall Policies
C H A P T E R 1 0
A CCESS R ULES
Access rules are lists of matching criteria and actions that define how the engine treats different types of network traffic. They are your main configuration tool for defining which traffic is stopped and which traffic is allowed.
The following sections are included:
Overview to Access Rules (page 102)
Configuration of Access Rules (page 103)
Using Access Rules (page 110)
Examples of Access Rules (page 115)
102 Chapter 10 Access Rules
Overview to Access Rules
The IPv4 and IPv6 Access rules are traffic handling rules in which you define the details of how you want the traffic to be examined and which action you want to take when matching details are found. The Access rules are stored in policy elements, which are discussed in Firewall Policies (page 83).
The traffic matching is based on the information contained in the packets:
•Source and destination IP addresses.
•Protocol-specific information, such as the port information for protocols that use ports.
•Protocol-specific information, such as the port information for protocols that use ports.