The TLS traffic to be inspected is specified in the IPv4 Access rules. Traffic that matches the Access rule is decrypted and inspected in the same way as regular HTTP traffic according to the Inspection rules.
To mark traffic for TLS inspection, you must use the custom Service that you created, and deep inspection must be enabled in the rule. See Access Rules (page 91) for more information about the Access Rules.
Using TLS Inspection
The general configuration of TLS Inspection is explained above. This section provides further information on configuring TLS Inspection.
Security Considerations
Because the TLS communications mediated by the engine are decrypted for inspection, and because the private keys of the servers are stored in the Server Protection Credentials elements on the Management Server, you must carefully consider security precautions when using TLS Inspection. The following recommendations are general guidelines for ensuring the security of the engine and the Management Center:
•Run the Management Server on a hardened operating system.
•Disable SSH access to the engine’s command line if it is not needed regularly.
•Ensure that the engine’s Control interface is in a controlled network.
•Save Management Server backups as encrypted files.
Virus Scanning of Decrypted TLS Traffic
Once TLS traffic has been decrypted, virus scanning can be done in the same way as for regular traffic (requires the StoneGate UTM solution). Any traffic that is allowed to continue after virus scanning is re-encrypted and sent to its destination. For more information about how virus scanning works, see Virus Scanning (page 151).
Examples of TLS Inspection
The examples in this section illustrate some common uses for TLS Inspection in StoneGate and general steps on how each scenario is configured.
Server Protection
Company A’s Web server offers HTTPS services to their customers. The administrators want to be able to detect and block attacks targeting the HTTPS server, even if the attacks are
encrypted inside an SSL tunnel. They decide to configure TLS Inspection to decrypt and inspect traffic to and from the HTTPS server.
The administrators do the following:
1. Create a Server Protection Credentials element and import the private key and certificate of the HTTPS server.
2. Select the Server Protection Credentials in the Firewall properties.
3. Create a custom HTTPS Service and enable HTTPS decryption and inspection in the Protocol Parameters.
4. Create IPv4 Access rules with the custom HTTPS Service as the Service.
5. Use the Inspection rules from the Default Inspection Rules Template Policy to look for
Client Protection
The administrators also want to detect and block Web-based attacks targeting the Web
browsers of users in Company A’s network to protect the workstations and internal networks. In addition to searching for attacks, the administrators also want to enable virus scanning.
However, the employees at Company A often use online banking services that are secured with HTTPS, and these connections should not be inspected. The administrators decide to configure TLS Inspection to detect and block Web-based attacks that are encrypted inside an SSL tunnel, and use a TLS Match element to globally exclude the online banking domains from decryption and inspection.
The administrators do the following:
1. Create a Client Protection Certificate Authority element and generate a new certificate and private key. Outside of StoneGate, the administrators add the Client Protection Certificate Authority they created to the list of trusted certificate authorities in the users’ Web browsers.
2. Select the Client Protection Certificate Authority in the Firewall properties.
3. Create a TLS Match element that prevents decryption when certificate validation
succeeds for the domain names for the online banking Web sites that are excluded from decryption.
4. Create a custom HTTPS Service and enable HTTPS decryption and inspection.
•Because the TLS Match is applied globally, the administrators do not have to use it in any specific rules.
5. Create IPv4 Access rules with the custom HTTPS Service as the Service.
6. Use the Inspection rules from the Default Inspection Rules Template Policy to look for attacks in HTTP traffic, and check the HTTP traffic against the anti-virus signatures.
7. Save and install the policy.
C HA PT E R 14
W EB F ILTERING
Web filtering compares the URLs that end-users attempt to open to a list of URLs, which can be defined manually or through pre-analyzed and categorized addresses. When a match is found, you can configure the system to respond in the various ways allowed by Inspection rules.
The following sections are included:
Overview to Web Filtering (page 144)
Configuration of Web Filtering (page 144)
Examples of Web Filtering (page 146)
Overview to Web Filtering
Web filtering can prevent end-users from intentionally or accidentally accessing most web sites that are objectionable (based on the content they contain) or potentially harmful (for example, phishing and malware sites). This type of content filtering can increase network security and enforce an organization’s policy on acceptable use of resources.
In web filtering, the engines compare the URLs (uniform resource locators) in web browser page requests against a list of forbidden URLs. There are two ways to define the forbidden URLs:
•You can define a small number of blacklisted URLs manually according to your own criteria.
•You can filter access according to a supplied URL categorization scheme (for example, filter out ‘adult content’).
Both methods can be used together. You can also define whitelisted URLs manually if a useful site happens to be included in a category of URLs that you want to otherwise ban.
The URL categorizations are provided by an external service. At this time, the BrightCloud service is supported. BrightCloud provides categories for malicious sites as well as several categories for different types of non-malicious content you may want to filter or log. Using category-based filtering with BrightCloud is a license-controlled feature.
The categories allow you to configure policies based on the types of sites to ban instead of manually typing in URLs. The individual URLs included in the categories are updated continuously, so they are fetched dynamically from the categorization service. The individual URLs are not viewable in the Management Client except when a match is found in traffic and the match is logged. The engines query the actual URLs from the external URL categorization service to access up-to-date URL listings. Different responses can be taken when a URL match is found: for example, you can log the matches or block the traffic. If you decide to block traffic, the firewall can additionally notify the end-user with a custom message that the end-users see in their browsers instead of the page they tried to open.
Configuration of Web Filtering
Illustration 14.1 Elements in the Configuration
The Web Filtering feature is configured through Stonesoft-supplied Web Filtering Situations and/
or manual URL lists. The Inspection rules are configured in the same basic way as other Inspection rules. However, Web Filtering Situations can uniquely be configured to directly override other Situations to whitelist some URLs manually (as explained further in this chapter).
Since the URLs that are included in category-based filtering are defined dynamically by an external service, it is not possible for you to manually add new categories or edit the existing ones. New web filtering situations are added through dynamic updates as necessary.
Situations Inspection Rules Firewall
Default Elements
There are default elements for the categories you can use in web filtering. These are
represented by a specific type of Situation elements, which can be found under SituationsBy TypeWeb Filtering in the element tree and in the corresponding branch of the Rules tree in the Inspection rules.
The Context for manually defining lists of URLs is HTTP URL Filter (under Application ProtocolsHTTP when selecting a Context for a Situation).
The Situations that represent web filtering categories have a distinctive blue color so that you can easily spot them in the rules. URL lists that you create yourself carry the standard red icon.
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.