- Title Page
- Introduction & Preface
- Logging into the FireSIGHT System
- Using Objects and Security Zones
- Managing Devices
- Setting Up an IPS Device
- Setting Up Virtual Switches
- Setting Up Virtual Routers
- Setting Up Aggregate Interfaces
- Setting Up Hybrid Interfaces
- Using Gateway VPNs
- Using NAT Policies
- Getting Started with Access Control Policies
- Blacklisting Using Security Intelligence IP Address Reputation
- Tuning Traffic Flow Using Access Control Rules
- Controlling Traffic with Network-Based Rules
- Controlling Traffic with Reputation-Based Rules
- Controlling Traffic Based on Users
- Controlling Traffic Using Intrusion and File Policies
- Understanding Traffic Decryption
- Getting Started with SSL Policies
- Getting Started with SSL Rules
- Tuning Traffic Decryption Using SSL Rules
- Understanding Intrusion and Network Analysis Policies
- Using Layers in Intrusion and Network Analysis Policies
- Customizing Traffic Preprocessing
- Getting Started with Network Analysis Policies
- Using Application Layer Preprocessors
- Configuring SCADA Preprocessing
- Configuring Transport & Network Layer Preprocessing
- Tuning Preprocessing in Passive Deployments
- Getting Started with Intrusion Policies
- Tuning Intrusion Rules
- Tailoring Intrusion Protection to Your Network Assets
- Detecting Specific Threats
- Limiting Intrusion Event Logging
- Understanding and Writing Intrusion Rules
- Blocking Malware and Prohibited Files
- Logging Connections in Network Traffic
- Working with Connection & Security Intelligence Data
- Analyzing Malware and File Activity
- Working with Intrusion Events
- Handling Incidents
- Configuring External Alerting
- Configuring External Alerting for Intrusion Rules
- Introduction to Network Discovery
- Enhancing Network Discovery
- Configuring Active Scanning
- Using the Network Map
- Using Host Profiles
- Working with Discovery Events
- Configuring Correlation Policies and Rules
- Using the FireSIGHT System as a Compliance Tool
- Creating Traffic Profiles
- Configuring Remediations
- Using Dashboards
- Using the Context Explorer
- Working with Reports
- Understanding and Using Workflows
- Using Custom Tables
- Searching for Events
- Managing Users
- Scheduling Tasks
- Managing System Policies
- Configuring Appliance Settings
- Licensing the FireSIGHT System
- Updating System Software
- Monitoring the System
- Using Health Monitoring
- Auditing the System
- Using Backup and Restore
- Specifying User Preferences
- Importing and Exporting Configurations
- Purging Discovery Data from the Database
- Viewing the Status of Long-Running Tasks
- Command Line Reference
- Security, Internet Access, and Communication Ports
- Third-Party Products
- glossary
- Configuring Supporting Inspection Information
- Understanding and Creating SSL Rules
- Specifying an SSL Rule’s Order of Evaluation
- Using Conditions to Specify the Encrypted Traffic a Rule Handles
- Using Rule Actions to Determine Encrypted Traffic Handling and Inspection
- Monitor Action: Postponing Action and Ensuring Logging
- Do Not Decrypt Action: Passing Encrypted Traffic Without Inspection
- Blocking Actions: Blocking Encrypted Traffic Without Inspection
- Decrypt Actions: Decrypting Traffic for Further Inspection
- Managing SSL Rules in a Policy
Getting Started with SSL Rules
Within an SSL policy, SSL rules provide a granular method of handling encrypted traffic across multiple managed devices, whether blocking the traffic without further inspection, not decrypting the traffic and inspecting it with access control, or decrypting the traffic for access control analysis.
The system matches traffic to SSL rules in the order you specify. In most cases, the system handles encrypted traffic according to the first SSL rule where all the rule’s conditions match the traffic. Conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, user, certificate, certificate distinguished name, certificate status, cipher suite, or encryption protocol version.
Each rule also has an action , which determines whether you monitor, block, or inspect matching traffic with access control, optionally after decrypting matching traffic. Note that the system does not further inspect encrypted traffic it blocks. It does inspect encrypted and undecryptable traffic with access control. However, some access control rule conditions require unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted payloads.
The following scenario summarizes the ways that SSL rules handle traffic in an inline deployment.
In this scenario, traffic is evaluated as follows:
- Undecryptable Traffic Action evaluates encrypted traffic first. For traffic the system cannot decrypt, the system either blocks it without further inspection or passes it for access control inspection. Encrypted traffic that does not match continues to the next rule.
- SSL Rule 1: Monitor evaluates encrypted traffic next. Monitor rules track and log encrypted traffic but do not affect traffic flow. The system continues to match traffic against additional rules to determine whether to permit or deny it.
- SSL Rule 2: Do Not Decrypt evaluates encrypted traffic third. Matching traffic is not decrypted; the system inspects this traffic with access control, but not file or intrusion inspection. Traffic that does not match continues to the next rule.
- SSL Rule 3: Block evaluates encrypted traffic fourth. Matching traffic is blocked without further inspection. Traffic that does not match continues to the next rule.
- SSL Rule 4: Decrypt - Known Key evaluates encrypted traffic fifth. Matching traffic incoming to your network is decrypted using a private key you upload. The decrypted traffic is then evaluated against access control rules. Access control rules handle decrypted and unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the SSL rule continues to the next rule.
- SSL Rule 5: Decrypt - Resign is the final rule. If traffic matches this rule, the system re-signs the server certificate with an uploaded CA certificate, then acts as a man-in-the-middle to decrypt traffic. The decrypted traffic is then evaluated against access control rules. Access control rules treat decrypted and unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the SSL rule continues to the next rule.
- SSL Policy Default Action handles all traffic that does not match any of the SSL rules. The default action either blocks encrypted traffic without further inspection or does not decrypt it, passing it for access control inspection.
Configuring Supporting Inspection Information
You must create reusable public key infrastructure (PKI) objects to control encrypted traffic based on encrypted session characteristics and decrypt encrypted traffic. You can add this information on the fly when uploading trusted certificate authority (CA) certificates to the SSL policy and creating SSL rule conditions, creating the associated object in the process. However, configuring these objects ahead of time reduces the chance of improper object creation.
Decrypting Encrypted Traffic with Certificates and Paired Keys
The system can decrypt incoming encrypted traffic if you configure an internal certificate object by uploading the server certificate and private key used to encrypt the session. If you reference that object in an SSL rule with an action of Decrypt - Known Key and traffic matches that rule, the system uses the uploaded private key to decrypt the session.
The system can also decrypt outgoing traffic if you configure an internal CA object by uploading a CA certificate and private key. If you reference that object in an SSL rule with an action of Decrypt - Resign and traffic matches that rule, the system re-signs the server certificate passed to the client browser, then acts as a man-in-the-middle to decrypt the session.
See the following for more information:
Controlling Traffic Based on Encrypted Session Characteristics
The system can control encrypted traffic based on the cipher suite or server certificate used to negotiate the session. You can configure one of several different reusable objects and reference the object in an SSL rule condition to match traffic. The following table describes the different types of reusable objects you can configure:
Understanding and Creating SSL Rules
Within an SSL policy, SSL rules provide a granular method of handling network traffic across multiple managed devices. In addition to its unique name, each SSL rule has the following basic components.
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and stops generating warnings and errors for that rule.
Rules in an SSL policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.
Conditions specify the specific traffic the rule handles. Conditions can match traffic by security zone, network or geographical location, VLAN, port, application, requested URL, user, certificate, certificate subject or issuer, certificate status, cipher suite, or encryption protocol version. Conditions can be simple or complex; their use can depends on target device licenses.
A rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or decrypt matching traffic. Decrypted traffic is subject to further inspection. Note that the system does not perform inspection on blocked or trusted encrypted traffic.
A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record of traffic that matches a rule. You can log a connection when the system blocks an encrypted session or allows it to pass uninspected, according to the settings in an SSL policy. You can also force the system to log connections that it decrypts for further evaluation by access control rules, regardless of how the system later handles or inspects the traffic. You can log connections to the Defense Center database, as well as to the system log (syslog) or to an SNMP trap server.
Tip Properly creating and ordering SSL rules is a complex task, but one that is essential to building an effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the SSL policy interface has a robust warning and error feedback system for rules. For more information, see Troubleshooting SSL Rules.
To create or modify an SSL rule:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > SSL .
Step 2 Click the edit icon (
) next to the SSL policy where you want to add a rule.
The SSL policy editor appears, focused on the Rules tab.
Step 3 You have the following options:
) next to the rule you want to edit.Step 4 Type a Name for the rule.
Each rule must have a unique name. You can use up to thirty printable characters, including spaces and special characters, with the exception of the colon (
:
).
Step 5 Configure the rule components, as summarized above. You can configure the following, or accept the defaults:
- Specify whether the rule is Enabled .
- Specify the rule position; see Specifying an SSL Rule’s Order of Evaluation.
- Select a rule Action ; see Using Rule Actions to Determine Encrypted Traffic Handling and Inspection.
- Configure the rule’s conditions; see Using Conditions to Specify the Encrypted Traffic a Rule Handles.
- Specify Logging options; see Logging Decryptable Connections with SSL Rules.
Step 6 Click Save to save the rule.
You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.
Specifying an SSL Rule’s Order of Evaluation
When you first create an SSL rule, you specify its position using the Insert drop-down list in the rule editor. SSL rules in an SSL policy are numbered, starting at 1. The system matches traffic to SSL rules in top-down order by ascending rule number.
In most cases, the system handles network traffic according to the first SSL rule where all the rule’s conditions match the traffic. Except in the case of Monitor rules (which log traffic but do not affect traffic flow), the system does not continue to evaluate traffic against additional, lower-priority rules after that traffic matches a rule.
Tip Proper SSL rule order reduces the resources required to process network traffic, and prevents rule preemption. Although the rules you create are unique to every organization and deployment, there are a few general guidelines to follow when ordering rules that can optimize performance while still addressing your needs. For more information, see Ordering SSL Rules to Improve Performance and Avoid Preemption.
In addition to ordering rules by number, you can group rules by category. By default the system provides three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot delete the system-provided categories or change their order. For information on changing the position or category of an existing rule, see Changing an SSL Rule’s Position or Category.
To add a rule to a category while editing or creating a rule:
Access: Admin/Access Admin/Network Admin
Step 1 In the SSL rule editor, from the Insert drop-down list, select Into Category , then select the category you want to use.
When you save the rule, it is placed last in that category.
To position a rule by number while editing or creating a rule:
Access: Admin/Access Admin/Network Admin
Step 1 In the SSL rule editor, from the Insert drop-down list, select above rule or below rule , then type the appropriate rule number.
When you save the rule, it is placed where you specified.
Using Conditions to Specify the Encrypted Traffic a Rule Handles
An SSL rule’s conditions identify the type of encrypted traffic that rule handles. Conditions can be simple or complex, and you can specify more than one condition type per rule. Only if traffic meets all the conditions in a rule does the rule apply to the traffic.
If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a certificate condition but no version condition evaluates traffic based on the server certificate used to negotiate the session, regardless of the session SSL or TLS version.
When you add or edit an SSL rule, use the tabs on the left side of the lower portion of the rule editor to add and edit rule conditions. The conditions you can add to an SSL rule are described in the following table.
entering or leaving a device via an interface in a specific security zone |
A security zone is a logical grouping of one or more interfaces according to your deployment and security policies. Interfaces in a zone may be located across multiple devices. To build a zone condition, see Controlling Encrypted Traffic by Network Zone. |
|
by its source or destination IP address, country, or continent |
You can explicitly specify IP addresses. The geolocation feature also allows you to control traffic based on its source or destination country or continent. To build a network condition, see Controlling Encrypted Traffic by Network or Geographical Location. |
|
The system uses the innermost VLAN tag to identify a packet by VLAN. To build a VLAN connection, see Controlling Encrypted VLAN Traffic. |
||
You can control encrypted traffic based on the TCP port. To build a port condition, see Controlling Encrypted Traffic by Port. |
||
You can control encrypted traffic based on the LDAP user logged into a host involved in an encrypted, monitored session. You can control traffic based on individual users or groups retrieved from a Microsoft Active Directory server. To build a user condition, see Controlling Encrypted Traffic Based on User. |
||
You can control access to individual applications in encrypted sessions, or filter access according to basic characteristics: type, risk, business relevance, and categories. To build an application condition, see Controlling Encrypted Traffic Based on Application. |
||
by the URL requested in the session, based on the certificate subject distinguished name |
You can limit the websites that users on your network can access based on the URL’s general classification and risk level. To build a URL condition, see Controlling Encrypted Traffic by URL Category and Reputation. 
Caution Adding or removing a URL category and reputation condition in an SSL rule restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.
|
|
by the subject or issuer distinguished name of the server certificate used to negotiate the encrypted session |
You can control encrypted traffic based on the CA that issued a server certificate, or the server certificate holder. To build a distinguished name condition, see Controlling Encrypted Traffic by Certificate Distinguished Name. |
|
by the server certificate used to negotiate the encrypted session |
You can control encrypted traffic based on the server certificate passed to the user’s browser in order to negotiate the encrypted session. To build a certificate condition, see Controlling Encrypted Traffic by Certificate Status. |
|
by properties of the server certificate used to negotiate the encrypted session |
You can control encrypted traffic based on a server certificate’s status. To build a certificate status condition, see Controlling Encrypted Traffic by Certificate Status. |
|
You can control encrypted traffic based on the cipher suite selected by the server to negotiate the encrypted session. To build a cipher suite condition, see Controlling Encrypted Traffic by Cipher Suite. |
||
You can control encrypted traffic based on the version of SSL or TLS used to encrypt the session. To build a version condition, see Controlling Traffic by Encryption Protocol Version. |
Note that while you can control and inspect encrypted traffic with a Series 3 device, controlling traffic using detected application, URL category, or user requires additional licenses. Also, overly complex rules can consume excessive resources and in some cases prevent you from applying the policy. For more information, see Troubleshooting SSL Rules.
Using Rule Actions to Determine Encrypted Traffic Handling and Inspection
Every SSL rule has an associated action that determines the following for matching encrypted traffic:
- handling — foremost, the rule action governs whether the system will monitor, trust, block, or decrypt encrypted traffic that matches the rule’s conditions
- logging — the rule action determines when and how you can log details about matching encrypted traffic.
Your SSL inspection configuration handles, inspects, and logs decrypted traffic:
- The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt; see Setting Default Handling for Undecryptable Traffic.
- The policy’s default action handles traffic that does not meet the condition of any non-Monitor SSL rule; see Setting Default Handling and Inspection for Encrypted Traffic.
You can log a connection event when the system blocks or trusts an encrypted session. You can also force the system to log connections that it decrypts for further evaluation by access control rules, regardless of how the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events, however:
- for blocked connections (Block, Block with reset), the system immediately ends the sessions and generates an event
- for trusted connections (Do not decrypt), the system generates an event when the session ends
For detailed information on rule actions and how they affect handling and logging, see the following sections:
Monitor Action: Postponing Action and Ensuring Logging
The Monitor action does not affect encrypted traffic flow; matching traffic is neither immediately permitted nor denied. Rather, traffic is matched against additional rules, if present, to determine whether to trust, block, or decrypt it. The first non-Monitor rule matched determines traffic flow and any further inspection. If there are no additional matching rules, the system uses the default action.
Because the primary purpose of Monitor rules is to track network traffic, the system automatically logs end-of connection events for monitored traffic. That is, the system always logs the end of the connection to the Defense Center database, regardless of the logging configuration of the rule or default action that later handles the connection. In other words, if a packet matches a Monitor rule, the connection is always logged, even if the packet matches no other rules and you do not enable logging on the default action.
Do Not Decrypt Action: Passing Encrypted Traffic Without Inspection
The Do not decrypt action passes encrypted traffic for evaluation by the access control policy’s rules and default action. Because some access control rule conditions require unencrypted traffic, this traffic may match fewer rules. The system cannot perform deep inspection on encrypted traffic, such as intrusion or file inspection.
Blocking Actions: Blocking Encrypted Traffic Without Inspection
The Block and Block with reset actions are analogous to the access control rule actions Block and Block with reset. These actions prevent the client and server from establishing the SSL-encrypted session and passing encrypted traffic. Block with reset rules also reset the connection.
Note that the system does not display the configured response page for blocked encrypted traffic. Instead, users requesting prohibited URLs have their connection either reset or time out. See Displaying a Custom Web Page for Blocked URLs for more information.
Tip Note that you cannot use the Block or Block with reset action in a passive or inline (tap mode) deployment, as the device does not directly inspect the traffic. If you create a rule with the Block or Block with reset action that contains passive or inline (tap mode) interfaces within a security zone condition, the policy editor displays a warning icon (
) next to the rule.
Decrypt Actions: Decrypting Traffic for Further Inspection
The Decrypt - Known Key and Decrypt - Resign actions decrypt encrypted traffic. The system inspects decrypted traffic with access control. Access control rules handle decrypted and unencrypted traffic identically — you can inspect it for discovery data as well as detect and block intrusions, prohibited files, and malware. The system reencrypts allowed traffic before passing it to its destination.
When you configure the Decrypt - Known Key action, you can associate one or more server certificates and paired private keys with the action. If traffic matches the rule, and the certificate used to encrypt the traffic matches the certificate associated with the action, the system uses the appropriate private key to obtain the session encryption and decryption keys. Because you must have access to the private key, this action is best suited to decrypt traffic incoming to servers your organization controls.
Similarly, you can associate one Certificate Authority certificate and private key with the Decrypt - Resign action. If traffic matches this rule, the system re-signs the server certificate with the CA certificate, then acts as a man-in-the-middle. It creates two SSL sessions, one between client and managed device, one between managed device and server. Each session contains different cryptographic session details, and allows the system to decrypt and reencrypt traffic. This action is more suited for outgoing traffic, as you replace the certificate’s private key with one you control to obtain the session keys.
Re-signing a server certificate involves either replacing the certificate’s public key with a CA certificate public key, or replacing the entire certificate. Normally, if you replace an entire server certificate, the client browser warns the certificate is not signed by a trusted authority when establishing the SSL connection. However, if your client’s browser trusts the CA in the policy, the browser does not warn that the certificate is not trusted. If the original server certificate is self-signed, the system replaces the entire certificate, and trusts the re-signing CA, but the user’s browser does not warn that the certificate is self-signed. In this case, replacing only the server certificate public key causes the client browser does warn that the certficate is self-signed.
If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced internal CA certificate’s signature algorithm type, in addition to any configured rule conditions. Because you associate one CA certificate with a Decrypt - Resign action, you cannot create an SSL rule that decrypts multiple types of outgoing traffic encrypted with different signature algorithms. In addition, any external certificate objects and cipher suites you add to the rule must match the associated CA certificate encryption algorithm type.
For example, outgoing traffic encrypted with an elliptic curve (EC) algorithm matches a Decrypt - Resign rule only if the action references an EC-based CA certificate; you must add EC-based external certificates and cipher suites to the rule if you want to create certificate and cipher suite rule conditions. Similarly, a Decrypt - Resign rule that references an RSA-based CA certificate matches only outgoing traffic encrypted with an RSA algorithm; outgoing traffic encrypted with an EC algorithm does not match the rule, even if all other configured rule conditions match.
- You cannot use the Decrypt - Known Key action in a passive deployment if the cipher suite used to establish the SSL connection applies either the Diffie-Hellman ephemeral (DHE) or the elliptic curve Diffie-Hellman ephemeral (ECDHE) key exchange algorithm. If your SSL policy targets a device with passive or inline (tap mode) interfaces, and contains a Decrypt - Known Key rule with a cipher suite condition containing either a DHE or an ECDHE cipher suite, the system displays an information icon (
) next to the rule. If you later add a zone condition to the SSL rule that contains passive or inline (tap mode) interfaces, the system displays a warning icon (
).- You cannot use the Decrypt - Resign action in a passive or inline (tap mode) deployment, as the device does not directly inspect traffic. If you create a rule with the Decrypt - Resign action that contains passive or inline (tap mode) interfaces within a security zone, the policy editor displays a warning icon (
) next to the rule. If your SSL policy targets a device with passive or inline (tap mode) interfaces, and contains a
Decrypt - Resign
rule, the system displays an information icon (
) next to the rule. If you later add a zone condition to the SSL rule that contains passive or inline (tap mode) interfaces, the system displays a warning icon (
). If you apply an SSL policy that contains a Decrypt - Resign rule to a device with passive or inline (tap mode) interfaces, any SSL sessions that match the rule fail. - If the client does not trust the CA used to re-sign the server certificate, it warns the user that the certificate should not be trusted. To prevent this, import the CA certificate into the client trusted CA store. Alternatively, if your organization has a private PKI, you can issue an intermediate CA certificate signed by the root CA which is automatically trusted by all clients in the organization, then upload that CA certificate to the device.
- The system cannot decrypt traffic encrypted with an anonymous cipher suite. You cannot use either the Decrypt - Resign or Decrypt - Known Key action in an SSL rule if you add an anonymous cipher suite to the Cipher Suite condition.
- The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed device, and the client and server establish a tunneled SSL connection using the CONNECT HTTP method. The Handshake Errors undecryptable action determines how the system handles this traffic. See Setting Default Handling for Undecryptable Traffic for more information.
- You cannot match on Distinguished Name or Certificate conditions when creating an SSL rule with a Decrypt - Known Key action. The assumption is that if this rule matches traffic, the certificate, subject DN, and issuer DN already match the certificate associated with the rule. For more information, see Using Rule Actions to Determine Encrypted Traffic Handling and Inspection.
- If you create an internal CA object and choose to generate a certificate signing request (CSR), you cannot use this CA for a Decrypt - Resign action until you upload the signed certificate to the object. For more information, see Obtaining and Uploading a New Signed Certificate.
- If you configure a rule with the Decrypt - Resign action, and mismatch signature algorithm type for one or more external certificate objects or cipher suites, the policy editor displays an information icon (
) next to the rule. If you mismatch signature algorithm type for all external certificate objects, or all cipher suites, the policy displays a warning icon (
) next to the rule, and you cannot apply the access control policy associated with the SSL policy. For more information, see Controlling Encrypted Traffic by Certificate and Controlling Encrypted Traffic by Cipher Suite.- If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive Block with reset , the system blocks the matching connection without interaction and the system does not display a response page.
- If you enable the Normalize Excess Payload option in the inline normalization preprocessor, when the preprocessor normalizes decrypted traffic, it may drop a packet and replace it with a trimmed packet. This does not end the SSL session. If the traffic is allowed, the trimmed packet is encrypted as part of the SSL session. For more information on this option, see Normalizing Inline Traffic.
- If your browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic by re-signing the server certificate. If you want to allow this traffic, configure an SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name.
Managing SSL Rules in a Policy
The Rules tab of the SSL policy editor, shown in the following graphic, allows you to add, edit, search, move, enable, disable, delete, and otherwise manage SSL rules within your policy.
For each rule, the policy editor displays its name, a summary of its conditions, and the rule action. Icons represent warnings, errors, and other important information. Disabled rules are grayed out and marked
(disabled)
beneath the rule name. See Troubleshooting SSL Rules for more information about the icons.
Searching SSL Rules
You can search the list of SSL rules for matching values using an alphanumeric string, including spaces and printable, special characters. The search inspects the rule name and any rule condition you have added to the rule. For rule conditions, the search matches any name or value you can add for each condition type (zone, network, application, and so on). This includes individual object names or values, group object names, individual object names or values within a group, and literal values.
You can use complete or partial search strings. The column for matching values is highlighted for each matching rule. For example, if you search on all or part of the string
100Bao
, at a minimum, the Applications column is highlighted for each rule where you have added the 100Bao application. If you also have a rule named
100Bao
, both the Name and Applications columns are highlighted.
You can navigate to each previous or next matching rule. A status message displays the current match and the total number of matches.
Matches may occur on any page of a multi-page rule list. When the first match is not on the first page, the page where the first match occurs is displayed. Selecting the next match when you are at the last match takes you to the first match, and selecting the previous match when you are at the first match takes you to the last match.
Access: Admin/Access Admin/Network Admin
Step 1 In the SSL policy editor for the policy you want to search, click the Search Rules prompt, type a search string, then press Enter. You can also use the Tab key or click a blank page area to initiate the search.
Columns for rules with matching values are highlighted, with differentiated highlighting for the indicated (first) match.
Step 2 Find the rules you are interested in:
) or previous-match (
) icon.
).Enabling and Disabling SSL Rules
When you create an SSL rule, it is enabled by default. If you disable a rule, the system does not use it to evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules in an SSL policy, disabled rules are grayed out, although you can still modify them. Note that you can also enable or disable an SSL rule using the rule editor; see Understanding and Creating SSL Rules.
To change an SSL rule’s state:
Access: Admin/Access Admin/Network Admin
Step 1 In the SSL policy editor for the policy that contains the rule you want to enable or disable, right-click the rule and choose a rule state:
Step 2 Click Save to save the policy.
You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.
Changing an SSL Rule’s Position or Category
To help you organize SSL rules, every SSL policy has three system-provided rule categories: Administrator Rules, Standard Rules, and Root Rules. You cannot move, delete, or rename these categories, although you can create custom categories.
By default, any predefined user role that allows you to modify SSL policies also allows you to move and modify SSL rules within and among rules categories. You can, however, create custom roles that restrict users from moving and modifying rules.
Moving an SSL Rule
Proper SSL rule order reduces the resources required to process network traffic, and prevents rule preemption. By default, any predefined user role that allows you to modify SSL policies also allows you to move SSL rules within and among rules categories. You can, however, create custom roles that restrict users from moving rules in the system-provided categories.
The following procedure explains how to move one or more rules at a time using the SSL policy editor. You can also move individual SSL rules using the rule editor; see Understanding and Creating SSL Rules.
Access: Admin/Access Admin/Network Admin
Step 1 In the SSL policy editor for the policy that contains the rules you want to move, select the rules by clicking in a blank area for each rule. Use the Ctrl and Shift keys to select multiple rules.
The rules you selected are highlighted.
Step 2 Move the rules. You can cut and paste or drag and drop.
To cut and paste rules into a new location, right-click a selected rule and select Cut . Then, right-click a blank area for a rule next to where you want to paste the cut rules and select Paste above or Paste below . Note that you cannot copy and paste SSL rules between two different SSL policies.
Step 3 Click Save to save the policy.
You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.
Adding a New SSL Rule Category
To help you organize SSL rules, every SSL policy has three system-provided rule categories: Administrator Rules, Standard Rules, and Root Rules. You cannot move, delete, or rename these categories, although you can create custom categories between the Standard Rules and Root Rules.
Adding custom categories allows you to further organize your rules without having to create additional policies. You can rename and delete categories that you add. You cannot move these categories, but you can move rules into, within, and out of them.
You can create custom roles that restrict users from moving and modifying rules in the system-provided categories, based on the user permissions added to the role. For more information, see User Account Privileges.
Access: Admin/Access Admin/Network Admin
Step 1 In the SSL policy editor for the policy where you want to add a rule category, click Add Category .
Tip If your policy already contains rules, you can click a blank area in the row for an existing rule to set the position of the new category before you add it. You can also right-click an existing rule and select Insert new category.
The Add Category pop-up window appears.
Step 2 Type a unique category Name .
You can enter an alphanumeric name, including spaces and special printable characters, with up to 30 characters.
Step 3 You have the following choices:
- To position the new category immediately above an existing category, select above Category from the first Insert drop-down list, then select the category above which you want to position the rule from the second drop-down list.
- To position the new category rule below an existing rule, select below rule from the drop-down list, then enter an existing rule number. This option is valid only when at least one rule exists in the policy.
- To position the rule above an existing rule, select above rule from the drop-down list, then, enter an existing rule number. This option is valid only when at least one rule exists in the policy.
Your category is added. You can click the edit icon (
) next to a custom category to edit its name, or click the delete icon (
) to delete the category. Rules in a category you delete are added to the category above.
Step 5 Click Save to save the policy.
Troubleshooting SSL Rules
Properly creating and ordering SSL rules is a complex task, but one that is essential to building an effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the SSL policy interface has a robust warning and error feedback system for rules.
For each rule, icons in the policy editor mark warnings and errors, as described in the following table. Hover your pointer over the icon to read the warning, error, or informational text.
Properly configuring SSL rules can also reduce the resources required to process network traffic. Creating complex rules and mis-ordering rules can affect performance.
Understanding SSL Rule Warnings and Errors
Although you can create SSL rules with any license, certain rule conditions and inspection options require that you enable specific licensed capabilities on the targeted device. You cannot apply a policy that uses licensed capabilities to unlicensed devices. The system uses warning icons and confirmation dialogs to designate unlicensed features. For details, hover your pointer over a warning icon.
The following table explains the licenses you must have to use SSL rules.
Understanding Rule Preemption and Invalid Configuration Warnings
Properly configuring and ordering SSL rules is essential to building an effective deployment. Within an SSL policy, SSL rules can preempt other rules or contain invalid configurations. The system uses warning and error icons to mark these issues.
Understanding Rule Preemption Warnings
The conditions of an SSL rule may preempt a subsequent rule from matching traffic. For example:
The second rule above will never block traffic because the first rule will have already allowed the traffic.
Any type of rule condition can preempt a subsequent rule. For example, the VLAN range in the first rule below includes the VLAN in the second rule, so the first rule preempts the second rule:
In the following example, Rule 1 matches any VLAN because no VLANs are configured, so Rule 1 preempts Rule 2, which attempts to match VLAN 2:
A rule also preempts an identical subsequent rule where all configured conditions are the same. For example:
A subsequent rule would not be preempted if any condition is different. For example:
Understanding Invalid Configuration Warnings
Because outside settings that the SSL policy depends on may change, an SSL policy setting that was valid may become invalid. Consider the following examples:
- A rule that contains a URL category condition might be valid until you target a device that does not have a URL Filtering license. At that point, an error icon appears next to the rule, and you cannot apply the policy to that device until you edit or delete the rule, retarget the policy, or enable the appropriate license.
- If you create a Decrypt-Resign rule, and later add a security zone with passive interfaces to a zone condition, the system displays a warning icon next to the rule. Because you cannot decrypt traffic by re-signing a certificate in a passive deployment, the rule has no effect until you remove the passive interfaces from the rule or change the rule action.
- If you add a user to a rule, then change your LDAP user awareness settings to exclude that user, the rule will have no effect because the user is no longer an access-controlled user.
Ordering SSL Rules to Improve Performance and Avoid Preemption
Rules in an SSL policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.
Proper SSL rule order reduces the resources required to process network traffic, and prevents rule preemption. Although the rules you create are unique to every organization and deployment, there are a few general guidelines to follow when ordering rules that can optimize performance while still addressing your needs.
Order Rules from Most to Least Critical
First, you must order rules to suit your organization's needs. Place priority rules that must apply to all traffic near the top of the policy. For example, if you want to decrypt outgoing traffic from a single user for further analysis (using a Decrypt-Resign rule), but not decrypt traffic from all other users in the department (using a Do not decrypt rule), place two SSL rules in that order.
Order Rules from Specific to General
You can improve performance by placing specific rules earlier, that is, rules that narrowly define the traffic they handle. This is also important because rules with broad conditions can match many different types of traffic, and can preempt later, more specific rules.
Consider a scenario where a trusted CA (Good CA) mistakenly issued a CA certificate to a malicious entity (Bad CA), but has not yet revoked that certificate. You want to block traffic encrypted with certificates issued by the untrusted CA, but otherwise allow traffic within the trusted CA’s chain of trust. You should upload the CA certificates and all intermediate CA certificates, then order your rules as follows:
the first rule matches all traffic trusted by Good CA, including traffic trusted by Bad CA. Because no traffic ever matches the second rule, malicious traffic may be allowed instead of blocked.
Order Rules to Allow Traffic from Certificate Pinned Sites
Certificate pinning forces a client's browser to verify that a server's public key certificate matches a certificate the browser already associated with the server before establishing an SSL session. Because the Decrypt - Resign action involves modifying a server certificate before passing it to the client, these modified certificates are rejected if the browser already pinned that certificate.
For example, if a client browser connects to
windowsupdate.microsoft.com
, a site that uses certificate pinning, and you configure an SSL rule that matches that traffic with a Decrypt - Resign action, the system re-signs the server certificate before passing it to the client browser. Because this modified server certificate does not match the browser's pinned certificate for
windowsupdate.microsoft.com
, the client browser rejects the connection.
If you want to allow this traffic, configure an SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name. In the SSL policy, order this rule before all Decrypt - Resign rules that also match the traffic. You can retrieve the pinned certificate from the client's browser after a successful connection to the website. You can also view the certificate from the logged connection event, whether the connection succeeded or failed.
Place Rules that Decrypt Traffic Later
Because traffic decryption requires processing resources, placing rules that do not decrypt traffic (Do not decrypt, Block) before rules that do (Decrypt-Known Key, Decrypt-Resign) can improve performance. This is because traffic decryption can command significant resources. In addition, Block rules can divert traffic that the system might otherwise have decrypted or inspected. All other factors being equal, that is, given a set of rules where none is more critical and preemption is not an issue, consider placing them in the following order:
- Monitor rules that log matching connections, but take no other action on traffic
- Block rules that block traffic without further inspection
- Do not decrypt rules that do not decrypt encrypted traffic
- Decrypt-Known Key rules that decrypt incoming traffic with a known private key
- Decrypt-Resign rules that decrypt outgoing traffic by re-signing the server certificate
Configuring SSL Inspection to Improve Performance
Complex SSL policies and rules can command significant resources. When you apply an SSL policy, the system evaluates all the rules together and creates an expanded set of criteria that target devices use to evaluate network traffic. A pop-up window may warn that you have exceeded the maximum number of SSL rules supported by a target device. This maximum depends on a number of factors, including the physical memory and the number of processors on the device.
The following guidelines can help you simplify your SSL rules and improve performance:
- When constructing a rule, use as few individual elements in your conditions as possible. For example, in network conditions, use IP address blocks rather than individual IP addresses. In port conditions, use port ranges. Use application filters and URL categories and reputations to perform application control and URL filtering, and LDAP user groups to perform user control.
Note that combining elements into objects that you then use in SSL rule conditions does not improve performance. For example, using a network object that contains 50 individual IP addresses gives you only an organizational—not a performance—benefit over including those IP addresses in the condition individually.
- Restrict rules by security zones whenever possible. If a device’s interfaces are not in one of the zones in a zone-restricted rule, the rule does not affect performance on that device.
- Do not overconfigure rules. If one condition is enough to match the traffic you want to handle, do not use two.
Configuring Traffic Decryption
Keep the following guidelines in mind when configuring traffic decryption:
- Traffic decryption requires processing resources to decrypt the traffic, and to inspect it with access control. Create narrowly focused decrypt rules over broad decrypt rules to reduce the amount of traffic the system decrypts, and as a result, reduce the processing resources required to decrypt traffic. Rather than decrypting then later allowing or blocking traffic using an access control rule, block or choose not to decrypt encrypted traffic where possible.
- If you configure certificate status conditions to trust traffic based on the root issuer CA, upload the root CA certificate and all intermediate CA certificates within the root CA’s chain of trust to your SSL policy. All traffic within a trusted CA’s chain of trust can be allowed without decryption, rather than unnecessarily decrypting it.
Feedback