The basic design principle of Inspection rules is the same as in Access rules, meaning that the rules are read from top down, and more specific rules must be placed above more general rules that match the same traffic. But in Inspection rules, matching is mainly done based on information included in the Situation elements. Because each Situation matches only a particular pattern in traffic, the rules match the same traffic only when they match the same Situation, even if they have identical Source,
Destination, and Protocol definitions.
The Inspection rule design is mainly a process of selecting which Situations are applied to which traffic and which reaction is triggered when a match is found. The actual matching criteria is included in the Situation elements. This also means that the behavior of the Inspection rules can change without anyone editing the policy itself. Just creating a new Situation in the system may include it in the policy if there are rules with “ANY” as the defined Situation or rules that include a Tag attached to the Situation.
Action Command for the firewall to carry out when a connection matches the rule.
Options Options for logging, automatic responses, termination, and connection resetting.
Time The time period when the rule is applied. If this cell is left empty, the rule applies at all times.
Comment
Your 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 identification 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.
TABLE 12.1 Inspection Rule Cells (Continued)
Cell Explanation
138 Chapter 12: Inspection Rules
Default Elements
The Inspection rules have their own template called Default Inspection Rules, which is introduced in your system when you import and activate a dynamic update package.
The Default Inspection Rules template is placed below the main Default template in the policy hierarchy, but you must manually reparent any existing policies if you want them to use the Default Inspection rules. It is not mandatory to use the default template for Inspection rules: the Default template (the one that contains the Access rules) has an insert point for Inspection rules on its otherwise empty Inspection rules tab.
The rules in the Default Inspection Rules template may change when you activate new update packages in your system. The illustration below shows the most recent rules at the time of writing this guide.
Illustration 12.3 Default Inspection Rules Template
In Illustration 12.3, you can see the insert point and two rules below that. The Inspection rules may look very simple, but they actually include a multitude of Situations: the Situation cell in both rules includes tags, which means that all Situations that are marked with those tags are included in the rules. This also means that when new Situations are added to the system with one of the Tags in the rules, the firewall will automatically start looking for the patterns the new Situation contains without any direct modifications to the rules.
The Firewall reads the Inspection rules from top down. In the illustration, just below the insert point, Rule 1.2 defines that a connection that matches Situations marked with the Tag Attacks or the Tag Successful Attacks is Terminated. Rule 1.3 below creates a log entry, if less serious Situations are encountered, but Permits the connections.
The insert point is above the two default rules. This supports a workflow where you use the Default template as a basis for your own policies and then add rules that override the default behavior for some Situations to adapt the Inspection Rules to your particular environment. You can use the insert point to add the rules that take no action at all for certain Situations that you know are not relevant in your environment.
Configuration of Inspection Rules 139
Configuration Workflow
The following sections provide an overview to the configuration tasks related to configuring and customizing Inspection 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.
Note – You must import and activate a recent dynamic update to create Inspection rules. See the Online Help for information on updating your system with dynamic updates and instructions for enabling automatic update download and activation.
Task 1: Add Situations
The Situation field is used for matching traffic to known patterns of exploits, so the Situation field includes the information that makes the inspection possible. In addition to individual Situation elements, this cell may contain Tag elements, which are shown as branches in the Situations tree and allow adding the whole branch of Situations at once to a rule. Currently, only HTTP, HTTPS, IMAP, POP3, SIP, and SMTP Situations can be used in Firewall Policies. Incompatible Situations are ignored if you add them to the Firewall Policy.
You may also set the Situation cell to ANY, which makes the cell match any Situation defined in the system. This makes for one notable difference between the Access rules and Inspection rules: Inspection rules do not match all traffic even if all matching cells are set to ANY, because the rule still matches only traffic patterns that are defined in the Situation elements included in the system.
You can create your policies without creating any custom Situation elements: you can decide which of the predefined Situations are applied to which traffic and which kind of responses are triggered when a match is found. If you use the Default Inspection Rules template, the Situations you will add to the policy are most likely those that you consider to be false positives in your environment.
However, if you want to detect some pattern in traffic that is not defined in the predefined Situations (for example, a particular internal file server in your network being accessed) or if you want to create a modified version of some existing Situation, you must create a new Situation element. This is explained in Configuration of Situations, on page 210.
Task 2: Limit the Situations by Severity
Situation elements always have a severity value, which is a number from 1 (least severe) to 10 (most severe). The Severity cell allows you to limit the scope of the rule to those matching Situations that have a severity value within a certain range.
Restricting the scope using Severity is most useful when you use Tags in the Situations cell.
For example, defining the Severity allows you to create different responses for otherwise identical rules that include many different Situations (like Situations that
140 Chapter 12: Inspection Rules
include all known vulnerabilities related to a certain operating system): you could decide to issue an Alert for matches to more severe Situations and only create a normal log or no log at all for less severe ones.
Task 3: Define the Source and Destination
The Source and Destination cells are used for limiting the scope of inspection to certain traffic. This is done in the same way as in Access rules, but with a different purpose. Inspection rules allow all connections to pass by default, unless specifically terminated by a rule. Therefore, the Source and Destination are used only to restrict the scope of the Inspection rules or to except traffic between certain hosts from further inspection.
Task 4: Define the Protocol
The Protocol cell corresponds to the Service cell in Access rules. When the traffic is directed from Access rules, it is defined as belonging to a specific protocol (HTTP, HTTPS, IMAP, POP3, SIP, or SMTP), so all traffic that arrives in Inspection rules has a specific protocol defined. If necessary, you can refer to this protocol to limit a rule’s scope. This is useful, if you have Situations with mixed protocols included in a rule (for example, when the Situations are defined with Tag elements). Individual Situations match only HTTP, HTTPS, IMAP, POP3, SIP, and SMTP traffic in any case.
Task 5: Select the Action
Inspection rules have three actions:
• Permit stops the inspection process for matching connections. All further
inspection rules have no effect on the matching connections. The Permit action is perhaps most often used to eliminate false positives. You can also use it to configure rules that create an alert or a log entry, but do not stop matching traffic.
• Continue rule’s options (defined in the Options cell) are stored in memory while the matching process continues. The options can be overridden partially or completely by a later, matching rule. See Setting Default Options for Several Inspection Rules, on page 142.
• Terminate stops the matching connection according to options set for the rule.
Task 6: Set the Options for the Rule
Each rule has the following options: logging, response, antivirus, the Terminate action, and connection resets.
By default, the rule’s Logging options are undefined, which means (like in Access rules) that the rule uses logging options that are set in the previous matching Continue rule above. But in Inspection rules, the default option is that no log entry is generated if there is no previous Continue rule. The Logging options for Inspection rules also include an option to record excerpts of the actual packet payload in connections that match the rule.
Configuration of Inspection Rules 141 Note – Storing or viewing the packets’ payload may be illegal in some jurisdictions due to laws related to the privacy of communications.
The log levels are explained in Table 12.2.
The Response options are used to define an automatic response for any HTTP connection that is refused, terminated, or blacklisted according to a rule. A default response can be defined using Continue rules, or the response can be specified for an individual rule. The User Response element specified in the options allows you define a different response for each of the following situations:
• Connection terminated by inspection rule: the connection was terminated according to an Inspection rule with the Terminate action.
• URL not allowed: the connection was terminated by an Inspection rule that uses the Web Filter Situation for URL filtering.
• Virus found (Firewall): the UTM’s antivirus feature found a virus in the Web page.
The following responses are available:
• TCP Close: the TCP connection is closed.
• URL Redirecting: the connection is redirected to the specified URL.
• HTML Page: displays the specified HTML statements.
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 inspect traffic for viruses, the Protocol cell in the rule must include one of the Protocol Agents supported for anti-virus inspection on the firewall. 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.
TABLE 12.2 Log Levels in Inspection 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.
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.
142 Chapter 12: Inspection Rules
The connection termination options allow you to select whether you want the Terminate action to actually terminate the connection, or whether it will just log that termination could have occurred. The purpose of this option is to allow you to test a new rule without needing to worry that a mistake could cut the wrong connections. You will get a distinctive log entry in the Logs view (different from any other log entries, including actual terminations of connections).
A second option allows you to select whether the connection termination additionally sends a reset that appears to both communicating hosts as though the other host reset the connection. An additional option for connection resetting defines whether an ICMP error message is sent when the communications use some other protocol in cases where a connection reset would be sent if the rule had matched a TCP connection (by default, no ICMP error message is sent).
Task 7: 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).