In the Firewall properties, you specify the Client Protection Certificate Authority (if you want to inspect traffic between internal clients and external servers), and/or the Server Credentials (if you want to inspect traffic for which an internal server is the destination). Depending on the options you specify, you can configure only client protection, only server protection, or both client and server protection.
If the default HTTPS (with decryption) Service element meets your needs, you can use the default HTTPS (with decryption) Service element in the Access rules without modification. You must create a custom HTTPS Service in the following cases:
•You want to enable decryption for HTTPS traffic that uses a different port.
•You want to select a different HTTPS Inspection Exceptions element.
•You want to log the URLs in matching traffic.
•You want to modify any of the other settings in the Service Properties.
The Access rules define which traffic is decrypted and inspected. To select specific traffic for decryption and inspection, you create Access rules that enable Deep Inspection and use a custom HTTPS Service or the default HTTPS (with decryption) Service element. To enable the
Note – Once a certificate for client and/or server protection has been uploaded to the engine, it is possible to unintentionally enable TLS decryption for all traffic by adding an Application that allows or requires the use of TLS to an Access rule, enabling the logging of Application information in the Access rules, or enabling Deep Inspection in an Access rule with the Service cell of the rule set to ANY.
160 Chapter 14 TLS Inspection
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 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 McAfee:
•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 IP address is in a protected network.
•Save Management Server backups as encrypted files.
Virus Scanning of Decrypted TLS Traffic
Once TLS traffic has been decrypted, virus scanning (separately-licensed feature) can be done in the same way as for regular traffic. 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 171).
URL Filtering Decrypted TLS Traffic
Once TLS traffic has been decrypted, URL filtering (separately-licensed feature) can be done in the same way as for regular traffic. Any traffic that is allowed to continue after URL filtering is re-encrypted and sent to its destination. For more information about how URL filtering works, see URL Filtering (page 163).
Examples of TLS Inspection
The examples in this section illustrate some common uses for TLS Inspection and general steps on how each scenario is configured.
Server Protection
Company A’s 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 Credentials element and import the private key and certificate of the HTTPS server.
2. Select the Server Credentials in the Firewall properties.
3. Create IPv4 Access rules with the default HTTPS (with decryption) Service as the Service.
4. Use the Medium-Security Inspection Policy to look for attacks in HTTP traffic, and check the HTTP traffic against the anti-virus signatures.
5. Save and install the policy.
Client Protection
The administrators also want to detect and block -based attacks targeting the 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 -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. In their network environment, the administrators add the Client Protection Certificate Authority they created to the list of trusted certificate authorities in the users’
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 sites that are excluded from decryption. Because the TLS Match is applied globally, the administrators do not have to use it in any specific rules.
4. Create IPv4 Access rules with the default HTTPS (with decryption) Service as the Service.
162 Chapter 14 TLS Inspection
C H A P T E R 1 5
URL F ILTERING
URL filtering compares the URLs (uniform resource locators) 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 engine to respond in the various ways.
The following sections are included:
Overview to URL Filtering (page 164)
Configuration of URL Filtering (page 164)
Examples of URL Filtering (page 166)
164 Chapter 15 URL Filtering
Overview to URL Filtering
URL 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 URL filtering, the engines compare the URLs 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 otherwise want to block.
The URL categorizations are provided by the external BrightCloud service. 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. Category-based filtering with BrightCloud is a license-controlled feature.
The categories allow you to configure policies based on the types of sites to block instead of manually typing in URLs. The individual URLs included in the categories are updated
continuously. The engines query the actual URLs from the external URL categorization service to access up-to-date URL listings. The individual URLs are not viewable in the Management Client except when a match is found in traffic and the match is logged.
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 URL Filtering
Illustration 15.1 Elements in the Configuration
The URL filtering feature is configured through McAfee-supplied URL Filtering Situations and/or manual URL lists. The Access rules and the Inspection Policy define how URL Filtering Situations are matched to traffic and what kind of reaction a match triggers. URL Filtering Situations can 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. The URL category names are updated through dynamic update packages.
Situations Firewall
Inspection Policy
Access Rules
Default Elements
There are default elements for the categories you can use in URL filtering. These are
represented by a specific type of Situation elements, which can be found under SituationsBy TypeURL 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
ProtocolsApplication ProtocolsHTTP when selecting a Context for a Situation).
The Situations that represent URL 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 Situation icon.
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 McAfee SMC Administrator’s Guide.