- 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
- Inspecting Allowed Traffic For Intrusions and Malware
- Tuning Intrusion Prevention Performance
- Tuning File and Malware Inspection Performance and Storage
Controlling Traffic Using Intrusion and File Policies
Intrusion and file policies work together as part of the FireSIGHT System, as the last line of defense before traffic is allowed to its destination:
- Intrusion policies govern the system’s intrusion prevention capabilities; see Understanding Network Analysis and Intrusion Policies.
- File policies govern the system’s network-based file control and advanced malware protection (AMP) capabilities; see Understanding and Creating File Policies.
Hardware-based fast-pathing, Security Intelligence-based traffic filtering (blacklisting), SSL inspection-based decisions, and traffic decoding and preprocessing occur before network traffic is examined for intrusions, prohibited files, and malware. Access control rules and the access control default action determine which traffic is inspected by intrusion and file policies.
By associating an intrusion or file policy with an access control rule, you are telling the system that before it passes traffic that matches the access control rule’s conditions, you first want to inspect the traffic with an intrusion policy, a file policy, or both.
Note By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured. For more information, see Understanding Traffic Decryption and Using the SSL Preprocessor.
Intrusion prevention and AMP require that you enable specific licensed capabilities on your access control policy’s target devices, as described in the following table.
If your organization has a FireAMP subscription, the Defense Center can also receive endpoint-based malware detection data from the Cisco cloud. The Defense Center presents this data alongside any network-based file and malware data generated by the system. Importing FireAMP data does not require a license in addition to your FireAMP subscription. For more information, see Working with Cloud Connections for FireAMP.
For more information on inspecting traffic for intrusions, prohibited files, and malware, see:
Inspecting Allowed Traffic For Intrusions and Malware
License: Protection or Malware
Supported Devices: feature dependent
Supported Defense Centers: feature dependent
Intrusion and file policies govern the system’s intrusion prevention, file control, and AMP capabilities as a last line of defense before traffic is allowed to its destination. Hardware-based fast-path rules, Security Intelligence-based traffic filtering, SSL inspection decisions (including decryption), decoding and preprocessing, and access control rule selection occur before intrusion and file inspection.
Access control rules provide a granular method of handling network traffic across multiple managed devices. By associating an intrusion or file policy with an access control rule, you are telling the system that before it passes traffic that matches the access control rule’s conditions, you first want to inspect the traffic with an intrusion policy, a file policy, or both. Access control rule conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, and user.
The system matches traffic to access control rules in the order you specify. In most cases, the system handles network traffic according to the first access control rule where all the rule’s conditions match the traffic. An access control rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or allow (with or without further inspection) matching traffic; see Using Rule Actions to Determine Traffic Handling and Inspection.
The following diagram shows the flow of traffic in an inline intrusion prevention and AMP deployment, as governed by an access control policy that contains four different types of access control rules and a default action.
In the scenario above, the first three access control rules in the policy—Monitor, Trust, and Block—cannot inspect matching traffic. Monitor rules track and log but do not inspect network traffic, so the system continues to match traffic against additional rules to determine whether to permit or deny it. Trust and Block rules handle matching traffic without further inspection of any kind, while traffic that does not match continues to the next access control rule.
The fourth and final rule in the policy, an Allow rule, invokes various other policies to inspect and handle matching traffic, in the following order:
- Discovery: Network Discovery Policy— First, the network discovery policy inspects traffic for discovery data. Discovery is passive analysis and does not affect the flow of traffic. Although you do not explicitly enable discovery, you can enhance or disable it. However, allowing traffic does not automatically guarantee discovery data collection. The system performs discovery only for connections involving IP addresses that are explicitly monitored by your network discovery policy. For more information, see Introduction to Network Discovery.
- Advanced Malware Protection and File Control: File Policy— After traffic is inspected by discovery, the system can inspect it for prohibited files and malware. Network-based AMP detects and optionally blocks malware in many types of files, including PDFs, Microsoft Office documents, and others. If your organization wants to block not only the transmission of malware files, but all files of a specific type (regardless of whether the files contain malware), file control allows you to monitor network traffic for transmissions of specific file types, then either block or allow the file.
- Intrusion Prevention: Intrusion Policy— After file inspection, the system can inspect traffic for intrusions and exploits. An intrusion policy examines decoded packets for attacks based on patterns, and can block or alter malicious traffic . Intrusion policies are paired with variable sets , which allow you to use named values to accurately reflect your network environment.
- Destination— Traffic that passes all the checks described above passes to its destination.
Note that an Interactive Block rule (not shown in the diagram) has the same inspection options as an Allow rule. This is so you can inspect traffic for malicious content when a user bypasses a blocked website by clicking through a warning page. For more information, see Interactive Blocking Actions: Allowing Users to Bypass Website Blocks.
Traffic that does not match any of the non-Monitor access control rules in the policy is handled by the default action. In this scenario, the default action is an Intrusion Prevention action, which allows traffic to its final destination as long as it is passed by the intrusion policy you specify. In a different deployment, you might have a default action that trusts or blocks all traffic without further inspection; see Table 12-4. Note that the system can inspect traffic allowed by the default action for discovery data and intrusions, but not prohibited files or malware. You cannot associate a file policy with the access control default action.
Note Sometimes, when a connection is analyzed by an access control policy, the system must process the first few packets in that connection, allowing them to pass, before it can decide which access control rule (if any) will handle the traffic. However, so these packets do not reach their destination uninspected, you can use an intrusion policy—called the default intrusion policy—to inspect them and generate intrusion events. For more information, see Setting the Default Intrusion Policy for Access Control.
For more information on the above scenario and instructions on associating file and intrusion policies with access control rules and the access control default action, see:
- Understanding File and Intrusion Inspection Order
- Configuring an Access Control Rule to Perform AMP or File Control
- Configuring an Access Control Rule to Perform Intrusion Prevention
- Setting Default Handling and Inspection for Network Traffic
Understanding File and Intrusion Inspection Order
License: Protection or Malware
Supported Devices: feature dependent
Supported Defense Centers: feature dependent
The scenario in Inspecting Allowed Traffic For Intrusions and Malware shows one access control rule of each type, including an Allow rule associated with both a file policy and intrusion policy. In your access control policy, you can associate multiple Allow and Interactive Block rules with different intrusion and file policies to match inspection profiles to various types of traffic.
Note Traffic allowed by an Intrusion Prevention or Network Discovery Only default action can be inspected for discovery data and intrusions, but cannot be inspected for prohibited files or malware. You cannot associate a file policy with the access control default action.
You do not have to perform both file and intrusion inspection in the same rule. For a connection matching an Allow or Interactive Block rule:
- without a file policy, traffic flow is determined by the intrusion policy
- without an intrusion policy, traffic flow is determined by the file policy
- without either, allowed traffic is inspected by network discovery only
Tip The system does not perform any kind of inspection on trusted traffic. Although configuring an Allow rule with neither an intrusion nor file policy passes traffic like a Trust rule, Allow rules let you perform discovery on matching traffic.
The diagram below illustrates the types of inspection you can perform on traffic that meets the conditions of either an Allow or user-bypassed Interactive Block access control rule. For simplicity, the diagram displays traffic flow for situations where both (or neither) an intrusion and a file policy are associated with a single access control rule.
For any single connection handled by an access control rule, file inspection occurs before intrusion inspection. That is, the system does not inspect files blocked by a file policy for intrusions. Within file inspection, simple blocking by type takes precedence over malware inspection and blocking.
For example, consider a scenario where you normally want to allow certain network traffic as defined in an access control rule. However, as a precaution, you want to block the download of executable files, examine downloaded PDFs for malware and block any instances you find, and perform intrusion inspection on the traffic.
You create an access control policy with a rule that matches the characteristics of the traffic you want to provisionally allow, and associate it with both an intrusion policy and a file policy. The file policy blocks the download of all executables, and also inspects and blocks PDFs containing malware:
- First, the system blocks the download of all executables, based on simple type matching specified in the file policy. Because they are immediately blocked, these files are subject to neither malware cloud lookup nor intrusion inspection.
- Next, the system performs malware cloud lookups for PDFs downloaded to a host on your network. Any PDFs with a malware file disposition are blocked, and are not subject to intrusion inspection.
- Finally, the system uses the intrusion policy associated with the access control rule to inspect any remaining traffic, including files not blocked by the file policy.
Note Until a file is detected and blocked in a session packets from the session may be subject to intrusion inspection.
Configuring an Access Control Rule to Perform AMP or File Control
License: Protection or Malware
Supported Devices: feature dependent
Supported Defense Centers: feature dependent
An access control policy can have multiple access control rules associated with file policies. You can configure file inspection for any Allow or Interactive Block access control rule, which permits you to match different file and malware inspection profiles against different types of traffic on your network before it reaches its final destination.
When the system detects a prohibited file (including malware) according to the settings in the file policy, it automatically logs an event to the Defense Center database. If you do not want to log file or malware events, you can disable this logging on a per-access-control-rule basis. After you associate the file policy with the access control rule, clear the Log Files check box on the Logging tab of the access control rule editor. For more information, see Disabling File and Malware Event Logging for Allowed Connections.
The system also logs the end of the associated connection to the Defense Center database, regardless of the logging configuration of the invoking access control rule; see Connections Associated with File and Malware Events (Automatic).
Caution Associating a file policy with an access control rule, or subsequently dissociating the policy by selecting None, 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.
To associate a file policy with an access control rule:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control .
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy where you want to configure AMP or file control using access control rules.
Step 3 Create a new rule or edit an existing rule; see Creating and Editing Access Control Rules.
The access control rule editor appears.
Step 4 Ensure the rule action is set to Allow , Interactive Block , or Interactive Block with reset .
Step 5 Select the Inspection tab.
Step 6 Select a File Policy to inspect traffic that matches the access control rule, or select None to disable file inspection for matching traffic.
You can click the edit icon (
) that appears to edit the policy in a new browser tab; see Creating a File Policy.
Step 7 Click Add to save the rule.
Your rule is saved. You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Configuring an Access Control Rule to Perform Intrusion Prevention
An access control policy can have multiple access control rules associated with intrusion policies. You can configure intrusion inspection for any Allow or Interactive Block access control rule, which permits you to match different intrusion inspection profiles against different types of traffic on your network before it reaches its final destination.
Whenever the system uses an intrusion policy to evaluate traffic, it uses an associated variable set . Variables in a set represent values commonly used in intrusion rules to identify source and destination IP addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions and dynamic rule states.
Tip Even if you use system-provided intrusion policies, Cisco strongly recommends you configure the system’s intrusion variables to accurately reflect your network environment. At a minimum, modify default variables in the default set; see Optimizing Predefined Default Variables.
The number of unique intrusion policies you can use in a single access control policy depends on the model of the target devices; more powerful devices can handle more. Every unique pair of intrusion policy and variable set counts as one policy. Although you can associate a different intrusion policy-variable set pair with each Allow and Interactive Block rule (as well as with the default action), you cannot apply an access control policy if the target devices have insufficient resources to perform inspection as configured. For more information, see Simplifying Rules to Improve Performance.
Understanding System-Provided and Custom Intrusion Policies
Cisco delivers several intrusion policies with the FireSIGHT System. By using system-provided intrusion policies, you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For these policies, the VRT sets intrusion and preprocessor rule states, as well as provides the initial configurations for advanced settings. You can use system-provided policies as-is, or you can use them as the base for custom policies. Building custom policies can improve the performance of the system in your environment and provide a focused view of the malicious traffic and policy violations occurring on your network.
In addition to custom policies that you create, the system provides two custom policies: Initial Inline Policy and Initial Passive Policy. These two intrusion policies use the Balanced Security and Connectivity intrusion policy as their base. The only difference between them is their Drop When Inline setting, which enables drop behavior in the inline policy and disables it in the passive policy. For more information, see Comparing System-Provided with Custom Policies.
Connection and Intrusion Event Logging
When an intrusion policy invoked by an access control rule detects an intrusion and generates an intrusion event, it saves that event to the Defense Center database. The system also automatically logs the end of the connection where the intrusion occurred to the Defense Center database, regardless of the logging configuration of the access control rule; see Connections Associated with Intrusions (Automatic).
Caution Associating an intrusion policy with an access control rule, or subsequently dissociating the policy by selecting None, 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.
To associate an intrusion policy with an access control rule:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control .
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy where you want to configure intrusion inspection using access control rules.
Step 3 Create a new rule or edit an existing rule; see Creating and Editing Access Control Rules.
The access control rule editor appears.
Step 4 Ensure the rule action is set to Allow , Interactive Block , or Interactive Block with reset .
Step 5 Select the Inspection tab.
Step 6 Select a system-provided or custom Intrusion Policy , or select None to disable intrusion inspection for traffic that matches the access control rule.
If you select a custom intrusion policy, you can click the edit icon (
) that appears to edit the policy in a new browser tab; see Editing Intrusion Policies.
Step 7 Optionally, change the Variable Set associated with the intrusion policy.
You can click the edit icon (
) that appears to edit the variable set in a new browser tab; see Working with Variable Sets.
Step 8 Click Save to save the rule.
Your rule is saved. You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Tuning Intrusion Prevention Performance
Cisco provides several features for improving the performance of your system as it analyzes traffic for attempted intrusions. You configure these performance settings on a per-access-control-policy basis, and they apply to all intrusion policies invoked by that parent access control policy.
- Limiting Pattern Matching for Intrusions describes how you can specify the number of packets to allow in the event queue, and enable or disable inspection of packets that will be rebuilt into larger streams.
- Overriding Regular Expression Limits for Intrusion Rules describes how you can override default match and recursion limits on Perl-compatible regular expressions (PCRE).
- Limiting Intrusion Events Generated Per Packet describes how you can configure rule processing event queue settings.
- Configuring Packet and Intrusion Rule Latency Thresholds describes settings for packet and rule latency thresholding.
- Configuring Intrusion Performance Statistic Logging describes how you can configure your managed devices’ basic performance monitoring and reporting parameters.
Limiting Pattern Matching for Intrusions
You can specify the number of packets to allow in the event queue. You can also, before and after stream reassembly, enable or disable inspection of packets that will be rebuilt into larger streams.
To configure event queue settings:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Performance Settings
, then select the
Pattern Matching Limits
tab in the pop-up window that appears.
Step 5 You can modify the following options:
- Type a value for the maximum number of events to queue in the Maximum Pattern States to Analyze Per Packet field.
- To inspect packets which will be rebuilt into larger streams of data before and after stream reassembly, select Disable Content Checks on Traffic Subject to Future Reassembly . Inspection before and after reassembly requires more processing overhead and may decrease performance.
- To disable inspection of packets which will be rebuilt into larger streams of data before and after stream reassembly, clear Disable Content Checks on Traffic Subject to Future Reassembly . Disabling inspection decreases the processing overhead for inspection of stream inserts and may boost performance.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Overriding Regular Expression Limits for Intrusion Rules
You can override default match and recursion limits on PCRE that are used in intrusion rules to examine packet payload content. See Searching for Content Using PCRE for information on using the
pcre
keyword in intrusion rules. The default limits ensure a minimum level of performance. Overriding these limits could increase security, but could also significantly impact performance by permitting packet evaluation against inefficient regular expressions.
Caution Do not override default PCRE limits unless you are an experienced intrusion rule writer with knowledge of the impact of degenerative patterns.
The following table describes the options you can configure to override the default limits.
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Performance Settings
, then select the Regular Expression Limits tab in the pop-up window that appears.
Step 5 You can modify any of the options in the Regular Expression Constraint Options table.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Limiting Intrusion Events Generated Per Packet
When the rules engine evaluates traffic against rules, it places the events generated for a given packet or packet stream in an event queue, then reports the top events in the queue to the user interface. You can elect to have the rules engine log more than one event per packet or packet stream when multiple events are generated. Logging these events allows you to collect information beyond the reported event. When configuring this option, you can specify how many events can be placed in the queue and how many are logged, and select the criteria for determining event order within the queue.
The following table describes the options you can configure to determine how many events are logged per packet or stream.
To configure how many events are logged per packet or stream:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Performance Settings
, then select the
Intrusion Event Logging Limits
tab in the pop-up window that appears.
Step 5 You can modify any of the options in the Intrusion Event Logging Limits Options table.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Configuring Packet and Intrusion Rule Latency Thresholds
Settings for packet and rule latency thresholding maintain device latency. For more information, see:
Understanding Packet Latency Thresholding
You can balance security with the need to maintain latency at an acceptable level by enabling packet latency thresholding. Packet latency thresholding measures the total elapsed time taken to process a packet by applicable decoders, preprocessors, and rules, and ceases inspection of the packet if the processing time exceeds a configurable threshold.
Packet latency thresholding measures elapsed time, not just processing time, in order to more accurately reflect the actual time required for the rule to process a packet. However, latency thresholding is a software-based latency implementation that does not enforce strict timing.
The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks.
A timer starts for each packet when decoder processing begins. Timing continues either until all processing ends for the packet or until the processing time exceeds the threshold at a timing test point.
As illustrated in the above figure, packet latency timing is tested at the following test points:
- after the completion of all decoder and preprocessor processing and before rule processing begins
- after processing by each rule
If the processing time exceeds the threshold at any test point, packet inspection ceases.
Tip Total packet processing time does not include routine TCP stream or IP fragment reassembly times.
Packet latency thresholding has no effect on events triggered by a decoder, preprocessor, or rule processing the packet. Any applicable decoder, preprocessor, or rule triggers normally until a packet is fully processed, or until packet processing ends because the latency threshold is exceeded, whichever comes first. If a drop rule detects an intrusion in an inline deployment, the drop rule triggers an event and the packet is dropped.
Note No packets are evaluated against rules after processing for that packet ceases because of a packet latency threshold violation. A rule that would have triggered an event cannot trigger that event, and for drop rules, cannot drop the packet.
For more information on drop rules, see Setting Rule States.
Packet latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by stopping inspection of packets that require excessive processing time. These performance benefits might occur when, for example:
- for both passive and inline deployments, sequential inspection of a packet by multiple rules requires an excessive amount of time
- for inline deployments, a period of poor network performance, such as when someone downloads an extremely large file, slows packet processing
In a passive deployment, stopping the processing of packets might not contribute to restoring network performance because processing simply moves to the next packet.
Configuring Packet Latency Thresholding
Latency-based performance settings are enabled by default by the system-provided Balanced Security and Connectivity intrusion policy. The following table describes single option for configuring packet latency thresholding.
You can enable rule 134:3 to generate an event when the system stops inspecting a packet because the packet latency threshold is exceeded. See Setting Rule States for more information.
To configure packet latency thresholding:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Latency-Based Performance Settings
, then select the Packet Handling tab in the pop-up window that appears.
Tip By default, packet latency thresholding is enabled. To completely disable latency thresholding, clear the Enable checkbox.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
To disable packet latency thresholding:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Latency-Based Performance Settings
, then select the Packet Handling tab in the pop-up window that appears.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Understanding Rule Latency Thresholding
Rule latency thresholding measures the elapsed time each rule takes to process an individual packet, suspends the violating rule along with a group of related rules for a specified time if the processing time exceeds the rule latency threshold a configurable consecutive number of times, and restores the rules when the suspension expires.
Rule latency thresholding measures elapsed time, not just processing time, in order to more accurately reflect the actual time required for the rule to process a packet. However, latency thresholding is a software-based latency implementation that does not enforce strict timing.
The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks.
A timer measures the processing time each time a packet is processed against a group of rules. Any time the rule processing time exceeds a specified rule latency threshold, the system increments a counter. If the number of consecutive threshold violations reaches a specified number, the system takes the following actions:
- suspends the rules for the specified period
- triggers an event indicating the rules have been suspended
- re-enables the rules when the suspension expires
- triggers an event indicating the rules have been re-enabled
The system zeroes the counter when the group of rules has been suspended, or when rule violations are not consecutive. Permitting some consecutive violations before suspending rules lets you ignore occasional rule violations that might have negligible impact on performance and focus instead on the more significant impact of rules that repeatedly exceed the rule latency threshold.
The following example shows five consecutive rule processing times that do not result in rule suspension.
In the above example, the time required to process each of the first three packets violates the rule latency threshold of 1000 microseconds, and the violations counter increments with each violation. Processing of the fourth packet does not violate the threshold, and the violations counter resets to zero. The fifth packet violates the threshold and the violations counter restarts at one.
The following example shows five consecutive rule processing times that do result in rule suspension.
In the second example, the time required to process each of the five packets violates the rule latency threshold of 1000 microseconds. The group of rules is suspended because the rule processing time of 1100 microseconds for each packet violates the threshold of 1000 microseconds for the specified five consecutive violations. Any subsequent packets, represented in the figure as packets 6 through n, are not examined against suspended rules until the suspension expires. If more packets occur after the rules are re-enabled, the violations counter begins again at zero.
Rule latency thresholding has no effect on intrusion events triggered by the rules processing the packet. A rule triggers an event for any intrusion detected in the packet, regardless of whether the rule processing time exceeds the threshold. If the rule detecting the intrusion is a drop rule in an inline deployment, the packet is dropped. When a drop rule detects an intrusion in a packet that results in the rule being suspended, the drop rule triggers an intrusion event, the packet is dropped, and that rule and all related rules are suspended. For more information on drop rules, see Setting Rule States.
Note Packets are not evaluated against suspended rules. A suspended rule that would have triggered an event cannot trigger that event and, for drop rules, cannot drop the packet.
Rule latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by suspending rules that take the most time to process packets. Packets are not evaluated again against suspended rules until a configurable time expires, giving the overloaded device time to recover. These performance benefits might occur when, for example:
Configuring Rule Latency Thresholding
Rule latency thresholding suspends rules for the time specified by Suspension Time when the time rules take to process a packet exceeds Threshold for the consecutive number of times specified by Consecutive Threshold Violations Before Suspending Rule .
You can enable rule 134:1 to generate an event when rules are suspended, and rule 134:2 to generate an event when suspended rules are enabled. See Viewing Intrusion Events and Setting Rule States for more information.
The following table further describes the options you can set to configure rule latency thresholding.
To configure rule latency thresholding:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Latency-Based Performance Settings
, then select the Rule Handling tab in the pop-up window that appears.
Step 5 You can configure any of the options in the Rule Latency Thresholding Options table.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Configuring Intrusion Performance Statistic Logging
You can configure the basic parameters of how devices monitor and report their own performance. This allows you to specify the intervals at which the system updates performance statistics on your devices by configuring the following options.
Sample time (seconds) and Minimum number of packets
When the number of seconds specified elapses between performance statistics updates, the system verifies it has analyzed the specified number of packets. If it has, the system updates performance statistics. Otherwise, the system waits until it analyzes the specified number of packets.
Troubleshooting Options: Log Session/Protocol Distribution
Support might ask you during a troubleshooting call to log protocol distribution, packet length, and port statistics.
Caution Changing the setting for this troubleshooting option will affect performance and should be done only with Support guidance.
Troubleshooting Options: Summary
Support might ask you during a troubleshooting call to configure the system to calculate the performance statistics only when the Snort® process is shut down or restarted. To enable this option, you must also enable the Log Session/Protocol Distribution troubleshooting option.
Caution Changing the setting for this troubleshooting option will affect performance and should be done only with Support guidance.
To configure basic performance statistics parameters:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Performance Settings
, then select the Performance Statistics tab in the pop-up window that appears.
Step 5 Modify the Sample time or Minimum number of packets as described above.
Step 6 Optionally, expand the Troubleshoot Options section and modify those options only if asked to do so by Support.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Tuning File and Malware Inspection Performance and Storage
License: Protection or Malware
Supported Devices: feature dependent
Supported Defense Centers: feature dependent
If you use file policies to perform file control, file storage, dynamic analysis, or malware detection or blocking, you can set the options listed in the following table. Keep in mind that increasing the file sizes can affect the performance of the system.
Caution Changing a value of an access control policy Files and Malware Settings advanced setting 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.
Note that because you cannot use a Malware license with a DC500, nor enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to capture, store, or block individual files, analyze the contents of archive files, submit files for dynamic analysis, or view file trajectories for files for which you conduct a malware cloud lookup.
To configure file and malware inspection performance and storage:
Access: Admin/Access Admin/Network Admin
Step 1 Select Policies > Access Control.
The Access Control Policy page appears.
Step 2 Click the edit icon (
) next to the access control policy you want to edit.
The access control policy editor appears.
Step 3 Select the Advanced tab.
The access control policy advanced settings page appears.
Step 4 Click the edit icon (
) next to
Files and Malware Settings
.
The Files and Malware Settings pop-up window appears.
Step 5 You can set any of the options in the Advanced Access Control File and Malware Detection Options table.
You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Feedback