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.
Some Applications can open several related connections. If a related connection is identified by an Access rule that detects Application use, the related connection is matched against the Access rules again. If the rule that detected the Application use has Deep Inspection enabled and the related connection matches a rule that has Deep Inspection enabled, the related connection is matched against the Inspection Policy. No NAT payload modifications are done for the connection that matches the rule that detected the Application use. NAT payload
Examples of Applications
The example in this section illustrates a common use for Applications 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.
Source Destination Service Action
Internal networks Not internal networks expression Social Media Application Tag Discard
Response: User Response to redirect connections to the intranet page Internal
CHA PT E R 21
BLACKLISTING
Blacklisting is a way to temporarily block unwanted network traffic either manually or automatically with blacklist requests from a Security Engine or Log 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 194)
Configuration of Blacklisting (page 195)
Overview to Blacklisting
Blacklisting makes it possible to block unwanted network traffic for a specified time. Security Engines can add entries to their own blacklists based on events in the traffic they inspect. Security Engines and Log Servers can also send blacklist requests to other Security Engines. You can also blacklist IP addresses manually.
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 blacklisting must be defined only with good reasons.
Table 21.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 a source of malicious traffic.
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.
Configuration of Blacklisting
Blacklisting is executed as defined in the Access rules of the Firewall Policy, the Layer 2 Firewall Policy, or the IPS Policy. Automatic blacklisting requests are sent as defined in the Inspection Policy.
Illustration 21.1 Blacklisting Process
1. Security Engines add entries to their own blacklists for traffic they inspect.
•There is one blacklist for each Firewall, Layer 2 Firewall, IPS engine, or Virtual Security Engine.
•In engine clusters, there is one blacklist for each cluster. The nodes in the cluster exchange blacklist information in their synchronization communications.
2. Log Servers send blacklisting requests as a response to correlation of detected events. When one Security Engine sends a blacklisting request to another Security Engine, the Log Server relays the blacklisting request to the Management Server.
3. Management Servers relay manual blacklisting commands from administrators, and blacklisting requests sent by Log Servers to the Security Engines.
•There is no direct communication between different Virtual Security Engines or between Virtual Security Engines and the Management Server. This means that Virtual Security Engines cannot send blacklisting requests to other Virtual Security Engines.
4. Security Engines enforce the entries on their blacklists according to their Access rules.
•Each blacklist entry exists only for a defined time period after which the entry is cleared and matching connections are again allowed. The duration of the blocking is defined when the blacklist entry is created.
•Access rules check connections against the blacklist. If the IP addresses and ports in one of the blacklist entries match, the connection is discarded.
•If the connection does not match a blacklisting Access rule or its related blacklist entries, Log Server Management Server Management Client Security
Engine A Engine BSecurity
Blacklist Blacklist
Access
Rules Access Rules
1
2 3
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the Stonesoft
Administrator’s Guide.