To detect application use, you must create Access rules and use an Application in the Service cell. You can either use Applications directly in the Service cell, or as part of the Service Definition. Any other criteria in the Service Definition override the Application properties. For example, the predefined Google Application matches only TCP ports 80 and 443, but using the Any TCP Service allows the Application to match any traffic pattern that resembles the use of Google regardless of the port.
Alternatively, you can use Application Types and Tags directly in the Service cell to match any of the Applications that belong to the Application Type or Tag group.
The Action Options and Logging Options in the rule define what application information is available in logs and reports. To include application information in the logs, deep inspection must be enabled for the rule. To generate the data for reports of application use, logging must be enabled with log accounting information and additional payload.
Examples of Applications
The examples in this section illustrate a common use for Applications in StoneGate and the general steps on how the scenario is configured.
Blocking Application Use
The administrators at Company A want to allow the use of HTTP in general, but block the use of social media applications from its corporate network. When social media use is detected, the administrators want to redirect users to the corporate security policy page on the company intranet.
The administrators:
1. Create a User Response to redirect dropped connections to the corporate security policy intranet page.
2. Add the following Access rules:
3. Refresh the firewall’s policy.
Logging Application Use
The administrators at Company C want to generate logs of application use, and create reports of which web-based applications are being used in their networks. To include application
information in the logs, they must enable deep inspection. To generate the data for the reports, they must enable logging with log accounting information and additional payload.
The administrators:
1. Add the following Access rule:
2. Refresh the firewall’s policy.
Response: User Response to redirect connections to the intranet page
C HA PT E R 20
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 174)
Configuration of Blacklisting (page 175)
Using Blacklisting (page 176)
Examples of Blacklisting (page 177)
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 20.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
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 20.1 Blacklisting Configuration
In Illustration 20.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.
Sensor A Blacklist
IPS Policy Analyzer
Inline Sensor B Firewall
Blacklist Management
Server
Firewall Policy