Vulnerabilities provide a short description of the event that has matched. Vulnerability
information is included in dynamic update packages, so all Situations provided by Stonesoft that are related to a known vulnerability are linked to a Vulnerability element. When you create your own Situations, you can associate them with an existing Vulnerability or a custom Vulnerability element.
You can add up to four references to public vulnerability databases to your custom Vulnerabilities (CVE/BID/MS/TA). System vulnerabilities can have an unlimited number of references to any reference system, and can have multiple references to the same reference system. The reference information is also shown in the Logs view.
Using Situations
Situations are used for defining what you want to detect with the Inspection rules. Situations are generally used for detecting harmful, unwanted, or otherwise interesting patterns in traffic. The Situations supplied by Stonesoft in dynamic update packages concentrate on known
vulnerabilities and exploits. The new Situations that you define may detect other patterns, such as a certain URL or file being accessed.
Although the general workflow requires ensuring that a Situation you want to use is included in the Firewall policy, you may often not actually insert the Situation into the rule, but use a Tag or Situation Type element instead to represent a whole group of Situations.
Note – If a Tag or Situation Type you add to a Situation is in use in some IPS policy, the new Situation is automatically included in the policy when you save the Situation, and the IPS components start matching traffic to the Situation when you refresh the policy.
Example of Custom Situations
The example in this section illustrates a common use for Situations in StoneGate and the general steps on how the scenario is configured.
Detecting the Use of Forbidden Software
Company A has a firewall that inspects all outgoing Web traffic against the Inspection rules. The use of instant messaging clients across the Internet is forbidden in the company. The firewall’s Inspection rules are set to detect and log Situations with the Instant Messaging Tag.
The company’s administrators have found out that some of the internal users have started chatting using a new little-known instant messaging client that does not have a default Situation yet. The communications seem to be standard HTTP directly from client to client. The
administrators find one distinctive characteristic in the software: when launched, the software in question always connects to a particular address to check for updates using HTTP.
The administrators:
1. Create a new custom Situation element with the name “Software X”.
2. Add the HTTP Request URI Context to the Situation and type in a regular expression that contains the address they want the Situation to find using the StoneGate regular
expression syntax (see Regular Expression Syntax (page 273)).
3. Add the default system Tag Instant Messaging to the Situation.
4. Refresh the firewall’s policy.
5. Open the Logs view and filter the view using the “Software X” Situation as the filtering criteria.
6. See which computers use the forbidden software and take action to remove the software from the computers shown in the logs.
175
C HAPTER 19
B LACKLISTING
Blacklisting is a way to temporarily block unwanted network traffic either manually or with blacklist requests from a Sensor, Analyzer, or Management Server. Blacklisted connections are blocked for the duration of blacklist entries, after which the connections are again allowed.
The following sections are included:
Overview to Blacklisting (page 176)
Configuration of Blacklisting (page 177)
Using Blacklisting (page 178)
Examples of Blacklisting (page 179)
Overview to Blacklisting
Blacklisting makes it possible to block unwanted network traffic for a specified time. Sensors, Analyzers, and Management Servers can send blacklist requests to Firewalls. Analyzers can add IP addresses to the blacklist based on detected events. You can also blacklist IP addresses manually. Blacklisting is only available for IPv4 traffic.
Risks of Blacklisting
Blacklisting can have unintended consequences that could disrupt business-critical traffic. Use blacklisting with careful consideration. The following two categories represent the typical risks associated with blacklisting:
These risks can be minimized with good planning. The threats must be identified and evaluated carefully, and the active responses must be defined only with good reasons.
Whitelisting
Whitelisting means defining a list of IP addresses that must never be blacklisted. In Stonegate, whitelisting is achieved by following general Access rule design principles. Blacklisting applies only at the position of the blacklisting Access rule(s) in the policy. Traffic that has already been allowed or discarded before the blacklisting rules is not affected by blacklisting. If an Access rule in the firewall’s policy allows a connection, an Access rule that refers to the blacklist further down in the policy cannot blacklist the connection.
Table 19.1 Risks of Blacklisting
Risk Explanation
Blacklisting legitimate connections (false positive)
If the defined pattern for detecting malicious traffic is inaccurate, legitimate traffic may sometimes be blacklisted. This causes service downtime for hosts that are incorrectly identified as malicious.
Causing self-inflicted denial-of-service (DoS)
When an attacker uses spoofed IP addresses, a different
(legitimate) IP address may be blacklisted instead of the attacker’s IP address. This may cause a self-inflicted denial-of-service on legitimate traffic.
Note – Use blacklisting with consideration. An attacker may use spoofed IP addresses, which may cause a self-inflicted denial-of-service on legitimate traffic.
Configuration of Blacklisting 177
Configuration of Blacklisting
Blacklisting is executed as defined in the IPv4 Access rules of the Firewall Policy, and automatic blacklisting requests are sent as defined in the Inspection rules of the IPS policy.
Illustration 19.1 Blacklisting Configuration
In Illustration 19.1, Sensors, Analyzers, and Management Servers send blacklist requests.
When Sensors send blacklisting requests, Analyzers relay the request to the component that enforces the blacklisting. Manual blacklisting commands from the administrators are sent through the Management Server.
Firewalls can execute blacklist requests generated automatically by Sensors and Analyzers that are managed by the same Management Server. The duration of the blocking is defined when the automatic blacklist entry is created. The duration is based on the value configured in the IPS Inspection rule that generates the blacklist entry (firewalls do not automatically create blacklist entries).
There is one blacklist per Firewall. If an Access rule checks a connection against the blacklist and the IP addresses and ports in one of the blacklist entries match, the connection is discarded. Each blacklist entry exists only for a defined time period after which the entry is cleared and matching traffic is again allowed.
If the traffic does not match the blacklisting Access rule or its related blacklist entries, the next Access rule in the policy is checked as usual.
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Policies.
Sensor A Blacklist
IPS Policy Analyzer
Inline Sensor B Firewall
Blacklist Management
Server
Firewall Policy