After creating or modifying a Firewall Policy, you must transfer the changes to the firewall using the Management Client. You can either install the Firewall Policy (transfers the policy you select) or refresh the Firewall Policy (transfers the most recent version of the policy that the firewall already uses). You can install the same Firewall Policy on several firewalls.
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 (including related connections and authenticated connections).
Policy installation transfers any new firewall configuration information, in addition to the Firewall Policy. Whenever you update the firewall configuration or the properties of an element used in the configuration, you must reload the Firewall Policy on the firewall engine to make the changes take effect. This includes, for example, changes in the routing configuration, the VPN
configuration, and the 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
A Jump rule inserts the Firewall Sub-Policy, which is shown as an
expandable section.
Management Server to connect to the firewall engines. This safety feature prevents an administrator from inadvertently installing a configuration that would cause the critical management connections to fail.
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
•Connection Tracking vs. Connectionless Packet Inspection
•Policy Snapshots (page 82)
•Continue Rules (page 82)
•Adding Comments to Rules (page 82)
Validating Policies
The number of rules in a Firewall Policy may grow quite large over time. It may become quite difficult, for example, to spot duplicate rules 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 various 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 firewall engines automatically count how many times each Access and NAT rule has matched. 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.
Connection Tracking vs. Connectionless Packet Inspection
Connection tracking means that the firewall keeps a record of all currently open connections (stateful inspection). With connection tracking, the firewall 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 passing the firewall when connection tracking is used. For those
connections, you can disable connection tracking in the Access rules. This allows StoneGate to function as a simple packet filter for those connections, but it also prevents you from using some features that require the connection information from being applied to the connections.
When connection tracking is off, each packet that you want to allow must match an Access rule allowing 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
tracking is on. If done carelessly, turning connection tracking off reduces the benefits you gain from your firewall 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, or UDP). ICMP and UDP are stateless protocols that do not contain any connection information. However, the ICMP and UDP packets contain data that the firewall can use to build virtual connections. You can choose between several connection tracking modes depending on the traffic type and how strictly you want the connections to be tracked. The meaning of the connection tracking setting in the Access rules depends on the traffic type. For TCP traffic, is also depends on whether Strict Connection Tracking has been enabled in firewall properties. The available options are explained in Table 8.1.
Note – Before disabling connection tracking, always check if there is a Protocol Agent for the protocol in question. The Protocol Agents can pass such troublesome connections with connection tracking on, which is always a more secure option.
Table 8.1 Connection Tracking Modes
Mode Protocol Explanation
Default
TCP Traffic is handled as in the Normal mode or Strict mode depending on whether Strict Connection Tracking has been enabled in the firewall properties. See below for more information.
ICMP and
UDP Traffic is handled as in the Normal mode (see below).
Normal
ICMP
This is the recommended mode for ICMP. The firewall drops packets that refer to non-existing connection tracking entries if the packets are not allowed by another rule in the policy.
TCP
This is the recommended mode for TCP. The firewall checks that the traffic proceeds according to the TCP protocol (that a valid, complete TCP handshake is performed). 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 connection is dropped.
UDP
This is the recommended mode for UDP. The firewall checks the traffic direction and the port parameters used in the communications. The traffic itself is not checked by default. 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 connection tracking is on, you can also set the Idle Timeout for connections. The timeout is meant for clearing the firewall’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 question in the Firewall element’s properties.
Strict TCP
This mode can be used if you only want to allow TCP traffic that strictly adheres to TCP as defined in RFC 793. Other TCP traffic, for example, Transactional TCP traffic, is not allowed (see RFC 1644).
The firewall checks that the TCP handshake proceeds according to the TCP definition. It also checks the sequence numbers of the packets in pre-connection establishment states and for RST and FIN packets, and drops the 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 connection is dropped.
Loose
ICMP
You can use this mode in special cases when you want to use connection tracking for virtual ICMP connections that would not be allowed in the Normal mode (for example, to allow ICMP echo requests and replies).
The firewall allows packets that refer to non-existing connection tracking entries to pass.
TCP
You can use this mode to allow connections or to enable NAT in special cases (for example, if routing is asymmetric or dynamic routing protocols are used).
The firewall accepts connections that begin with any kind of packet. It allows packets belonging to traffic that has expired in connection tracking to continue. In this mode, only static NAT is supported (but not with Multi-Link).
UDP
You can use this mode in special cases when you want to use NAT with virtual UDP connections that would not be allowed in the Normal mode.
Only NAT is affected. If the connection tracking mode was Loose when an old NAT entry was generated and the entry is in conflict with a new NAT entry, the new entry replaces the old one. In addition, if an engine detects that a Server Pool member or an ISP has gone down, the NAT entries for the virtual connection are cleared and a new NAT entry is made when the next packet arrives.
Caution – Setting excessively long timeouts for many connections can consume resources to a point where the firewall performance and stability start to suffer. Be especially careful when defining timeouts for ICMP and UDP. The ICMP and UDP virtual connections do not have closing packets, so the firewall keeps the records for the ICMP and UDP connections until the end of the timeout.
Table 8.1 Connection Tracking Modes (Continued)
Mode Protocol Explanation
Changes in the connection tracking mode affect how existing connections are handled at policy installation. When you upload a policy on an engine, the firewall 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). Also, 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 highlighted.
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 Firewall 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 95).
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. You can add comments in the rule’s Comment cell or add dedicated Comment Rule rows between rules. When you add a Comment rule, a new section is added to the policy. The new section automatically contains all the rules below the Comment Rule until the next Comment Rule in the policy. You can expand and collapse the sections as necessary. The Comment rules are displayed on a colored background, so they are particularly good for visually separating sections of rules within a single policy.
Examples of Policy Element Use
The examples in this section illustrate some common uses for the different policy elements in StoneGate 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 StoneGate. 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 under the Default Template 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-Policies.
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 StoneGate 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 StoneGate administrators.
The StoneGate 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 based on the Default Template 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 policy is based on, nor can they install any other policies on any other firewalls.
For detailed information on administrator rights, see the Management Center Reference Guide.
C HA PT E R 9
A CCESS R ULES
Access rules are lists of matching criteria and actions that define how the firewall 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 86)
Configuration of Access Rules (page 87)
Using Access Rules (page 95)
Examples of Access Rules (page 99)
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 71).
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.
Additional matching criteria that is not based on information in the packets includes:
•The firewall interface the traffic is coming from or going to. This allows you to restrict which traffic is allowed through which interfaces in more detail than basic antispoofing.
•The VPN the traffic is coming from (on an engine where that VPN terminates). This allows creating rules that apply to VPN traffic only, or rules that apply to all traffic except VPN traffic.
•(IPv4 only) User authentication (allowing you to create rules that define the end-users who are allowed to make connections and the authentication methods for the end-users).
•The User or User Group of a user who has logged in to an integrated Microsoft Active Directory domain.
•The day of the week and the time of day (allowing you to enforce rules only during certain times, such as working hours).
•The day of the week and the time of day (allowing you to enforce rules only during certain times, such as working hours).