One of the crucial issues in designing policies is the order of the rules. The most important thing to keep in mind when editing the Template Policies, Firewall Policies, and the Firewall Sub-Policies is that the rules are read from top down. The actions Allow, Refuse, and Discard and the action Use IPsec VPN with the option Enforce stop the processing from continuing down the rule table for any connection that matches the rule. Therefore, rules with any of these actions must be placed so that the more limited the rule is in scope, the higher up in the rule table it is. For example, this means that an Access rule that allows connections to the IP address
192.168.10.200 must be put above an Access rule that stops all connections to the network 192.168.10.0/24.
See Example of Rule Order, on page 129 for a more detailed example and Guidelines for Building Network Security, on page 353 for a thorough presentation on policy design.
Comment
Your optional free-form comment for this rule. If you add a rule from the Logs view, the Comment cell of the rule automatically includes information on the log entry which was used as the basis of the rule. Note that you can also add separate comment rows in between rules.
Tag
(Not editable.) Automatically assigned unique identifier for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @180.2). The first part of the tag is permanent and belongs to only that rule. The second part changes when the rule is changed. The first part and the second part are separated by a period.
Source VPN Makes the rule match traffic based on whether it is coming from a specific VPN. If this cell is left empty, the rule matches both VPN and non-VPN traffic.
Hit
(Not editable.) Shows the number of connections that have matched the rule. This information is only shown if you have run a Rule Counter Analysis for the policy. The cell shows “N/A” if there is no information available about the rule. See Rule Counter Analysis, on page 110.
TABLE 11.1 Access Rule Cells (Continued)
Cell Explanation
120 Chapter 11: Access Rules
Default Elements
There is a template called Default that contains the basic Access rules that allow communications between the StoneGate firewall on which the policy is installed and other system components.
You must use the Default template as the basis for defining your own templates and policies, as it is not possible to create a new template at the highest level of the policy hierarchy. No changes can be made directly to the Default template, but you can create your own copy of it if you have a specific need to modify those rules.
Note – If you decide to use a copy of the Default template, you may have to adjust your rules manually when the system is upgraded to account for changes in system communications. Upgrades can change only the Default template, not the copies.
Illustration 11.3 Default Template Access Rules
The illustration above shows the Access rules included in the Default template. The insert point, where rules can be added in the inheriting Policy and Template Policy elements, is shown as an orange row near the end of the Access rules table.
The rules above the insert point detail the various kinds of system communications.
Most of the IP addresses are defined using Aliases to make the rules applicable on any system where they are installed. These Aliases are default elements in the system and they are listed in the appendix Predefined Aliases, on page 321. The Service cell is the best starting point for understanding in greater detail what these rules do. See appendix Default Communication Ports, on page 293 for a listing of the system communications and the Service elements that correspond to them.
Configuration of Access Rules 121 There are two rules below the insert point. The rule directly below the insert point has the action Refuse for the Ident protocol traffic, which means that this traffic is stopped with an ICMP error message sent to the Ident request sender. This rule exists to prevent Ident requests from being silently dropped (as the next rule specifies for all other traffic), because silently dropping Ident requests causes delays in
communications. The last rule before the end of the policy is a rule that discards all traffic and creates a log entry that is stored. This rule’s purpose is to ensure that this connection dropping is logged, since the firewall silently drops the connection without creating a log entry if the matching process reaches the end of the policy.
Configuration Workflow
The following sections provide an overview of the configuration tasks related to configuring and customizing Access Rules. Detailed step-by-step instructions for configuring the rules can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.
Task 1: Define the Source and Destination
The Source and Destination cells specify the IP addresses that are compared to the IP addresses in each packet’s header. Based on these and other criteria, the rule is applied to matching packets. By default, these cells are set to NONE, and you must change the value in both cells to make the rule valid.
The Source and Destination cells accept many kinds of elements. Any of the elements in the Network Elements category can be used to represent IP addresses in the Source and Destination cells. You can add more than one element in each cell.
Groups, Aliases, Address Ranges, and Expressions are especially useful for defining IP addresses in complex scenarios. You can set these cells to ANY to make the rule match all possible source or destination IP addresses.
Task 2: Define the Service
The Service cell defines the protocol(s) that are compared to the protocol-related information in each packet’s header. By default, the Service is set to NONE, and you must change the value to make the rule valid.
The Service cell accepts only Service and Service Group elements. There are ready-made Services in the system that cover most needs, but you may also use your own customized versions, for example, to define a non-standard port. The Services available for rule design are categorized according to protocols. You can add more than one element in this cell to make the rule match several Services.
Certain Services are associated with Protocols of the Protocol Agent type, which define more advanced inspection and handling for the connections. Additionally, the Protocol element identifies the protocol for the traffic for inspection against the Inspection rules (only some protocols are supported for this purpose on the firewall).
For more information on Protocols, Protocol Agents, and the network protocols that require their use, see Protocol Agents, on page 161.
122 Chapter 11: Access Rules
You can set the Service to ANY to make the rule match traffic using any protocol. A previous Continue rule (such as the one in the Default template) may define a Protocol Agent for certain types of traffic that is allowed by rules with ANY as the Service (see Configuring Default Settings for Several Rules, on page 126). If there is no previous Continue rule matching the same connection that would define a Protocol Agent, a rule allowing ANY Service does not apply a Protocol Agent to the traffic.
Note – The firewall cannot handle some types of traffic correctly if the traffic is allowed without the correct Protocol Agent when connection tracking is on (stateful inspection).
Task 3: Select the Action
The Action cell defines what happens when a packet matches the rule. The available actions are explained in Table 11.2.
TABLE 11.2 Action Field Options
Action Explanation
Allow The connection is let through the firewall.
Continue
Stores the contents of the Options and QoS Class cells and the Protocol (if defined in the Service used) in memory and continues the inspection process. Used for setting options for subsequent rules as explained in Configuring Default Settings for Several Rules, on page 126.
Discard The connection is silently dropped.
Refuse The connection is dropped and an ICMP error message is sent in response to notify the packet’s sender.
Jump Matching is continued in the specified sub-policy until a match is found. If there is no matching rule in the sub-policy, the process is resumed in the main policy.
Configuration of Access Rules 123
Task 4: Select Rule Options
Each Access rule has the following types of options: logging options, connection tracking options, and blacklisting options.
By default, the rule’s Logging options are undefined, which means that the rule uses logging options that have been set in the previous Continue rule above. If there is no previous Continue rule, a Stored-type log entry is created. Logging for the closing of the connection can be turned on or off, or on with accounting information. You must collect accounting information if you want to create reports that are based on traffic volumes.
The log levels are explained in Table 11.3.
IPsec VPN Action
Enforce The connection is allowed if the specified VPN is used.
Otherwise the connection is discarded.
Apply The connection is allowed if the specified VPN is used.
Otherwise, the rule is considered as non-matching and the matching process continues to the next rule.
Forward The connection is forwarded from one VPN to another. For more information, see VPN Configuration, on page 267.
The Selected IPsec VPN
Specifies a gateway-to-gateway or a client-to-gateway IPsec VPN.
$ Client-to-Gateway IPsec
VPNs Specifies any client-to-gateway IPsec VPNs.
Apply Blacklist Checks the packet against the blacklist according to the options set for this rule. If the packet matches a blacklist entry, the connection is discarded.
TABLE 11.3 Log Levels in Access Rules
Log Level Explanation
Alert An alert entry is generated.
Stored A log entry is generated and stored on the Log Server.
Essential
When the Log Server is unavailable, log entries are temporarily stored on the Firewall engine. When the Firewall engine is running out of space to store the log entries, it begins discarding log data in order of importance.
TABLE 11.2 Action Field Options (Continued)
Action Explanation
124 Chapter 11: Access Rules
Connection Tracking options define if the firewall keeps a record of the currently open connections (stateful inspection). By default, connection tracking is on. See
Connection Tracking vs. Connectionless Packet Inspection, on page 107 for more information.
The Deep Inspection option determines whether matching connections are inspected also against the Inspection rules. Any rule that has the Deep Inspection option selected must also have a Service that uses a Protocol that is supported for deep inspection on the firewall (HTTP, HTTPS, IMAP, POP3, or SMTP). For deep inspection of other protocols, use StoneGate IPS.
The Anti-Virus options are only supported for StoneGate UTM appliances. The options determine whether HTTP, HTTPS, IMAP, POP3, or SMTP traffic is inspected against a virus signature database. By default, the Antivirus options are undefined, which means that the rule uses anti-virus options set in the previous matching Continue rule above. To check traffic for viruses, the Service cell in the rule must include a Service that uses a Protocol that is supported for anti-virus inspection on the firewall. When you enable anti-virus inspection in the rule, the Deep Inspection option is also automatically activated. To use the Antivirus options, Antivirus Settings must also be enabled in the firewall’s properties. See Virus Scanning, on page 197 for more information on configuring virus scanning for UTM appliances.
The Enforce TCP MSS option allows you to enforce the Maximum Segment Size (MSS) for TCP connections and also to define the maximum and minimum size for the TCP packets.
The Blacklisting options are used in rules that have Apply Blacklist as the action.
The options allow you to choose which entries on the blacklist apply to connections that match the rule based on the component that added the blacklist entry on the blacklist. A restriction based on blacklist sender may be necessary, for example, if the same IP address exists in two different networks. The default setting is to take all blacklist entries into account regardless of the component that created the entry.
Task 5: Add User Authentication
The firewall can enforce user authentication. A client-to-gateway VPN always requires some form of authentication, but you can also add the authentication requirement to any non-VPN rules if you wish.
The authentication is configured in the Users and Authentication cells. The Users cell accepts User and User Group elements and defines the end-users who are allowed to
Transient A log entry is only available for immediate display in the Logs view and is not stored.
None The rule does not produce any log entries.
TABLE 11.3 Log Levels in Access Rules (Continued)
Log Level Explanation
Configuration of Access Rules 125 make connections allowed by the rule. You define the authentication method used in this particular rule in the Authentication cell, as each user and user group can have several authentication methods configured.
If the authentication fails, the connection is discarded. If the authentication succeeds, the connection is allowed through.
For more information, see User Authentication, on page 177.
Task 6: Restrict the Time When the Rule Is Enforced
Optionally, you can set a specific time period when a rule is applied using the Time cell. The validity of the rule can be set by month, day of the week, and time of day. For example, you might have certain rules that allow access only during business hours on weekdays. If you leave the Time cell empty, the rule is always valid.
Note – The times are entered in Coordinated Universal Time (UTC), and you must adjust the times you enter to make them correspond to the firewall’s local time zone. Also consider that UTC time does not adjust to daylight saving time (summer time).
Task 7: Restrict the Rule Match Based on Source VPN
Optionally, you can match the rule based on whether the traffic is coming from a VPN.
You can define that the rule matches only non-VPN traffic, or only traffic from a certain VPN.
You can use the Source VPN cell with the Forward option as the Use IPsec VPN action to transfer traffic from a VPN to the gateway-to-gateway VPN defined in the Action cell.
For more information, see Overview to VPNs, on page 259.
126 Chapter 11: Access Rules