- ASA FirePOWER Module User Guide
- Introduction to the Cisco ASA FirePOWER Module
- Managing Reusable Objects
- Managing Device Configuration
- 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 Network Analysis and Intrusion Policies
- Using Layers in a Network Analysis or Intrusion Policy
- 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 Policies Using Rules
- Detecting Specific Threats
- Globally Limiting Intrusion Event Logging
- Understanding and Writing Intrusion Rules
- Blocking Malware and Prohibited Files
- Logging Connections in Network Traffic
- Viewing Events
- Configuring External Alerting
- Configuring External Alerting for Intrusion Rules
- Using the ASA FirePOWER Dashboard
- Using ASA FirePOWER Reporting
- Scheduling Tasks
- Managing System Policies
- Configuring ASA FirePOWER Module Settings
- Licensing the FireSIGHT System ASA FirePOWER Module
- Updating ASA FirePOWER Module Software
- Monitoring the System
- Using Backup and Restore
- Generating Troubleshooting Files
- Importing and Exporting Configurations
- Viewing the Status of Long-Running Tasks
- Security, Internet Access, and Communication Ports
- Deciding Which Connections To Log
- Logging Security Intelligence (Blacklisting) Decisions
- Logging Connections Based on Access Control Handling
- Logging URLs Detected in Connections
Logging Connections in Network Traffic
As devices monitor traffic generated by the hosts on your network, they can generate logs of the connections they detect. Various settings in access control policies give you granular control over which connections you log, when you log them, and where you store the data. An access control rule’s specific logging configuration also determines whether you log file and malware events associated with the connection.
In most cases, you can log a connection at its beginning and its end. When you log a connection, the system generates a connection event. You can also log a special kind of connection event, called a Security Intelligence event, whenever a connection is blacklisted (blocked) by the reputation-based Security Intelligence feature.
Connection events contain data about the detected sessions.
You should log connections according to the security and compliance needs of your organization.
Deciding Which Connections To Log
Using various settings in access control policies, you can log any connection that your ASA FirePOWER module monitors. In most cases, you can log a connection at its beginning and its end. However, because blocked traffic is immediately denied without further inspection, the system can log only beginning-of-connection events for blocked or blacklisted traffic; there is no unique end of connection to log.
When you log a connection event, you can view it in the event viewer. You can also send connection data to an external syslog or SNMP trap server.
Tip To perform detailed analysis of connection data using the ASA FirePOWER module, Cisco recommends you log the ends of critical connections.
- Logging Critical Connections
- Logging the Beginning And End of Connections
- Logging Connections to the ASA FirePOWER Module or External Server
- Understanding How Access Control Rule Actions Affect Logging
- License Requirements for Connection Logging
Logging Critical Connections
You should log connections according to the security and compliance needs of your organization. If your goal is to limit the number of events you generate and improve performance, only enable logging for the connections critical to your analysis. However, if you want a broad view of your network traffic for profiling purposes, you can enable logging for additional connections. Various settings in access control policies give you granular control over which connections you log, when you log them, and where you store the data.
In addition to the logging that you configure, the system automatically logs most connections where the system detects a prohibited file, malware, or intrusion attempt. The system saves these end-of-connection events for further analysis. All connection events reflect why they were automatically logged using the Action and Reason fields.
Security Intelligence Blacklisting Decisions (Optional)
You can log a connection whenever it is blacklisted (blocked) by the reputation-based Security Intelligence feature. Optionally, and recommended in passive deployments, you can use a monitor-only setting for Security Intelligence filtering. This allows the system to further analyze connections that would have been blacklisted, but still log the match to the blacklist.
When you enable Security Intelligence logging, blacklist matches generate Security Intelligence events as well as connection events. A Security Intelligence event is a special kind of connection event that you can view and analyze separately, and that is also stored and pruned separately. For more information, see Logging Security Intelligence (Blacklisting) Decisions.
Access Control Handling (Optional)
You can log a connection when it is handled by an access control rule or the access control default action. You configure this logging on a per-access control rule basis so that you only log critical connections. For more information, see Logging Connections Based on Access Control Handling.
Connections Associated with Intrusions (Automatic)
When an intrusion policy invoked by an access control rule (see Tuning Traffic Flow Using Access Control Rules) detects an intrusion and generates an intrusion event, the system automatically logs the end of the connection where the intrusion occurred, regardless of the logging configuration of the rule.
However, when an intrusion policy associated with the access control default action (see Setting Default Handling and Inspection for Network Traffic) generates an intrusion event, the system does not automatically log the end of the associated connection. Instead, you must explicitly enable default action connection logging. This is useful for intrusion prevention-only deployments where you do not want to log any connection data.
For connections where an intrusion was blocked, the action for the connection in the connection log is Block
, with a reason of Intrusion Block
, even though to perform intrusion inspection you must use an Allow rule.
Connections Associated with File and Malware Events (Automatic)
When a file policy invoked by an access control rule detects a prohibited file (including malware) and generates a file or malware event, the system automatically logs the end of the connection where the file was detected, regardless of the logging configuration of the access control rule. You cannot disable this logging.
Note File events generated by inspecting NetBIOS-ssn (SMB) traffic do not immediately generate connection events because the client and server establish a persistent connection. The system generates connection events after the client or server ends the session.
For connections where a file was blocked, the action for the connection in the connection log is Block
even though to perform file and malware inspection you must use an Allow rule. The connection’s reason is either File Monitor
(a file type or malware was detected), or Malware Block
or File Block
(a file was blocked).
Logging the Beginning And End of Connections
When the system detects a connection, in most cases you can log it at its beginning and its end.
However, because blocked traffic is immediately denied without further inspection, in most cases you can log only beginning-of-connection events for blocked or blacklisted traffic; there is no unique end of connection to log.
Note For a single non-blocked connection, the end-of-connection event contains all of the information in the beginning-of-connection event, as well as information gathered over the duration of the session.
Note that monitoring a connection for any reason forces end-of-connection logging; see Understanding Logging for Monitored Connections.
The following table details the differences between beginning and end-of-connection events, including the advantages to logging each.
Logging Connections to the ASA FirePOWER Module or External Server
You can log connection events to the ASA FirePOWER module, as well as to an external syslog or SNMP trap server. Before you can log connection data to an external server, you must configure a connection to that server called an alert response ; see Working with Alert Responses.
Understanding How Access Control Rule Actions Affect Logging
Every access control rule has an action that determines not only how the system inspects and handles the traffic that matches the rule, but also when and how you can log details about matching traffic.
- Using Rule Actions to Determine Traffic Handling and Inspection
- Understanding Logging for Monitored Connections
- Understanding Logging for Trusted Connections
- Understanding Logging for Blocked and Interactively Blocked Connections
- Understanding Logging for Allowed Connections
- Disabling File and Malware Event Logging for Allowed Connections
Understanding Logging for Monitored Connections
The system always logs the ends of the following connections to the ASA FirePOWER module, regardless of the logging configuration of the rule or default action that later handles the connection:
- connections matching a Security Intelligence blacklist set to monitor
- connections matching an access control Monitor rule
In other words, if a packet matches a Monitor rule or Security Intelligence monitored blacklist, the connection is always logged, even if the packet matches no other rules and you do not enable logging on the default action. Whenever the system logs a connection event as the result of Security Intelligence filtering, it also logs a matching Security Intelligence event, which is a special kind of connection event that you can view and analyze separately; see Logging Security Intelligence (Blacklisting) Decisions.
Because monitored traffic is always later handled by another rule or by the default action, the action associated with a connection logged due to a monitor rule is never Monitor
. Rather, it reflects the action of the rule or default action that later handles the connection.
The system does not generate a separate event each time a single connection matches an access control Monitor rule. Because a single connection can match multiple Monitor rules, each connection event logged to the ASA FirePOWER module can include and display information on the first eight Monitor access control rules that the connection matches.
Similarly, if you send connection events to an external syslog or SNMP trap server, the system does not send a separate alert each time a single connection matches a Monitor rule. Rather, the alert that the system sends at the end of the connection contains information on the Monitor rules the connection matched.
Understanding Logging for Trusted Connections
A trusted connection is one that is handled by a Trust access control rule or the default action in an access control policy. You can log the beginnings and ends of these connections; however, keep in mind that trusted connections are not inspected for intrusions, or prohibited files and malware. Therefore, connection events for trusted connections contain limited information.
Understanding Logging for Blocked and Interactively Blocked Connections
For access control rules and access control policy default actions that block traffic (including interactive blocking rules), the system logs beginning -of-connection events. Matching traffic is denied without further inspection.
Connection events for sessions blocked by an access control rule have an action of Block
or Block with reset
.
Interactive blocking access control rules, which cause the system to display a warning page when a user browses to a prohibited website, log ends of connections. This is because if the user clicks through the warning page, the connection is considered a new, allowed connection which the system can monitor and log; see Understanding Logging for Allowed Connections.
Therefore, for packets that match an Interactive Block or Interactive Block with reset rule, the system can generate the following connection events:
- a beginning-of-connection event when a user’s request is initially blocked and the warning page is displayed; this event has an associated action of
Interactive Block
orInteractive Block with reset
- multiple beginning- or end-of-connection events if the user clicks through the warning page and loads the originally requested page; these events have an associated action of
Allow
and a reason ofUser Bypass
Note that only devices deployed inline can block traffic. Because blocked connections are not actually blocked in passive deployments, the system may report multiple beginning-of-connection events for each blocked connection.
Understanding Logging for Allowed Connections
Allow access control rules permit matching traffic to pass to the next phase of inspection and traffic handling.
When you allow traffic with an access control rule, you can use an associated intrusion or file policy (or both) to further inspect traffic and block intrusions, prohibited files, and malware before the traffic can reach its final destination.
Connections for traffic matching an Allow access control rule are logged as follows:
- When an intrusion policy invoked by an access control rule detects an intrusion and generates an intrusion event, the system automatically logs the end of the connection where the intrusion occurred to the ASA FirePOWER module, regardless of the logging configuration of the rule.
- When a file policy invoked by an access control rule detects a prohibited file (including malware) and generates a file or malware event, the system automatically logs the end of the connection where the file was detected to the ASA FirePOWER module, regardless of the logging configuration of the access control rule.
- Optionally, you can enable beginning- and end-of-connection logging for any allowed traffic, including traffic that the system deems safe or that you do not inspect with an intrusion or file policy.
For all of the resulting connection events, the Action and Reason fields reflect why the events were logged. Note that:
- An action of
Allow
represents explicitly allowed and user-bypassed interactively blocked connections that reached their final destination. - An action of
Block
represents a connection that was at first allowed by an access control rule, but where an intrusion, prohibited file, or malware was detected.
Disabling File and Malware Event Logging for Allowed Connections
License: Protection or Malware
When you allow traffic with an access control rule, you can use an associated file policy to inspect transmitted files, and block prohibited files and malware before it can reach its destination; see Tuning Intrusion Prevention Performance.
When the system detects a prohibited file, it automatically logs one of the following types of event to the ASA FirePOWER module:
- file events, which represent detected or blocked files, including malware files
- malware events, which represent detected or blocked malware files only
- retrospective malware events, which are generated when the malware disposition for a previously detected file changes
If you do not want to log file or malware events, you can disable this logging on a per-access-control-rule basis by clearing the Log Files check box on the Logging tab of the access control rule editor.
Note Cisco recommends you leave file and malware event logging enabled.
Regardless of whether you save file and malware events, when network traffic violates a file policy, the system automatically logs the end of the associated connection to the ASA FirePOWER module, regardless of the logging configuration of the invoking access control rule; see Connections Associated with File and Malware Events (Automatic).
License Requirements for Connection Logging
Because you configure connection logging in access control policies, you can log any connection that those policies can successfully handle.
Although you can create access control policies regardless of the licenses on your ASA FirePOWER module, certain aspects of access control require that you enable specific licensed capabilities before you can apply the policy.
The following table explains the licenses you must have to successfully configure access control, and therefore to log connections handled by an access control policy.
Logging Security Intelligence (Blacklisting) Decisions
As a first line of defense against malicious Internet content, the ASA FirePOWER module includes the Security Intelligence feature, which allows you to immediately blacklist (block) connections based on the latest reputation intelligence, removing the need for a more resource - intensive, in - depth analysis. This traffic filtering takes place before any other policy-based inspection, analysis, or traffic handling.
Optionally, and recommended in passive deployments, you can use a monitor-only setting for Security Intelligence filtering. This allows the system to further analyze connections that would have been blacklisted, but still log the match to the blacklist.
Enabling Security Intelligence logging logs all blocked and monitored connections handled by an access control policy. However, the system does not log whitelist matches; logging of whitelisted connections depends on their eventual disposition.
When the system logs a connection event as the result of Security Intelligence filtering, it also logs a matching Security Intelligence event, which is a special kind of connection event that you can view and analyze separately. Both types of events use the Action and Reason fields to reflect the blacklist match. Additionally, so that you can identify the blacklisted IP address in the connection, host icons next to blacklisted and monitored IP addresses look slightly different in the event viewer.
Logging Blocked Blacklisted Connections
For a blocked connection, the system logs beginning-of-connection Security Intelligence and connection events. Because blacklisted traffic is immediately denied without further inspection, there is no unique end of connection to log. For these events, the action is Block
and the reason is IP Block
.
IP Block
connection events have a threshold of 15 seconds per unique initiator-responder pair. That is, once the system generates an event when it blocks a connection, it does not generate another connection event for additional blocked connections between those two hosts for the next 15 seconds, regardless of port or protocol.
Logging Monitored Blacklisted Connections
For connections monitored—rather than blocked—by Security Intelligence, the system logs end-of-connection Security Intelligence and connection events to the ASA FirePOWER module. This logging occurs regardless of how the connection is later handled by an access control rule or the access control default action.
For these connection events, the action depends on the connection’s eventual disposition. The Reason field contains IP Monitor
, as well as any other reason why the connection may have been logged.
Note that the system may also generate beginning-of-connection events for monitored connections, depending on the logging settings in the access control rule or default action that later handles the connection.
To log blacklisted connections:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon () next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Select the Security Intelligence tab.
Security Intelligence settings for the access control policy appear.
Step 4 Click the logging icon ().
The Blacklist Options pop-up window appears.
Step 5 Select the Log Connections check box.
Step 6 Specify where to send connection and Security Intelligence events. You have the following choices:
- To send events to the ASA FirePOWER module, select Event Viewer.
- To send events to an external syslog server, select Syslog, then select a syslog alert response from the drop-down list. Optionally, you can add a syslog alert response by clicking the add icon (
- To send connection events to an SNMP trap server, select SNMP Trap, then select an SNMP alert response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon (
You must send events to the Event Viewer if you want to set blacklisted objects to monitor-only, or perform any other ASA FirePOWER module-based analysis on connection events generated by Security Intelligence filtering. For more information, see Logging Connections to the ASA FirePOWER Module or External Server.
Step 7 Click OK to set your logging options.
The Security Intelligence tab appears again.
Step 8 Click Store ASA FirePOWER Changes.
You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Logging Connections Based on Access Control Handling
Within an access control policy, access control rules provide a granular method of handling network traffic. So that you can log only critical connections, you enable connection logging on a per-access-control-rule basis—if you enable connection logging for a rule, the system logs all connections handled by that rule.
You can also log connections for the traffic handled by the default action of your access control policy. The default action determines how the system handles traffic that matches none of the access control rules in the policy (except Monitor rules, which match and log—but do not handle or inspect—traffic).
Note that even if you disable logging for all access control rules and the default action, end-of-connection events may still be logged to the ASA FirePOWER module if the connection matches an access control rule and contains an intrusion attempt, prohibited file, or malware
Depending on the rule or default policy action and the associated inspection options that you configure, your logging options differ. For more information, see:
- Logging Connections Matching an Access Control Rule
- Logging Connections Handled by the Access Control Default Action
Logging Connections Matching an Access Control Rule
To log only critical connections, you enable connection logging on a per-access-control-rule basis. If you enable logging for a rule, the system logs all connections handled by that rule.
Depending on the rule action and intrusion and file inspection configuration of the rule, your logging options differ; see Understanding How Access Control Rule Actions Affect Logging. Also, note that even if you disable logging for an access control rule, end-of-connection events for connections matching that rule may still be logged to the ASA FirePOWER module if the connection:
- contains an intrusion attempt, prohibited file, or malware
- previously matched at least one access control Monitor rule
To configure an access control rule to log connection, file, and malware information:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon () next to the access control policy you want to modify.
The access control policy editor appears, focused on the Rules tab.
Step 3 Click the edit icon () next to the rule where you want to configure logging.
The access control rule editor appears.
Step 4 Select the Logging tab.
Step 5 Specify whether you want to Log at Beginning and End of Connection, Log at End of Connection, or you want No Logging at Connection.
For a single non-blocked connection, the end-of-connection event contains all of the information in the beginning-of-connection event, as well as information gathered over the duration of the session. Because blocked traffic is immediately denied without further inspection, the system logs only beginning-of-connection events for Block rules. For this reason, when you set the rule action to Block or Block with reset you are prompted Log at Beginning of Connection.
Step 6 Use the Log Files check box to specify whether the system should log any file and malware events associated with the connection.
The system automatically enables this option when you associate a file policy with the rule to perform either file control or AMP. Cisco recommends you leave this option enabled; see Disabling File and Malware Event Logging for Allowed Connections.
Step 7 Specify where to send connection events. You have the following choices:
- To send connection events to the ASA FirePOWER module, select Event Viewer. You cannot disable this option for Monitor rules.
- To send events to an external syslog server, select Syslog, then select a syslog alert response from the drop-down list. Optionally, you can add a syslog alert response by clicking the add icon (
- To send events to an SNMP trap server, select SNMP Trap, then select an SNMP alert response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon (
You must send events to the event viewer if you want to perform ASA FirePOWER module-based analysis on connection events. For more information, see Logging Connections to the ASA FirePOWER Module or External Server.
Step 8 Click Store ASA FirePOWER Changes to save the rule.
Your rule is saved. You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Logging Connections Handled by the Access Control Default Action
You can log connections for the traffic handled by the default action of your access control policy. The default action determines how the system handles traffic that matches none of the access control rules in the policy (except Monitor rules, which match and log—but do not handle or inspect—traffic); see Setting Default Handling and Inspection for Network Traffic.
The mechanisms and options for logging connections handled by the policy default action largely parallel the options for logging connections handled by individual access control rules, as described in the following table. That is, except for blocked traffic, the system logs the beginning and end of connections, and you can send connection events to the ASA FirePOWER module, or to an external syslog or SNMP trap server.
|
|
|
---|---|---|
Understanding Logging for Blocked and Interactively Blocked Connections |
||
However, there are some differences between logging connections handled by access control rules versus the default action:
- The default action has no file logging options. You cannot perform file control or AMP using the default action.
- When an intrusion policy associated with the access control default action generates an intrusion event, the system does not automatically log the end of the associated connection. This is useful for intrusion detection and prevention-only deployments, where you do not want to log any connection data.
An exception to this rule occurs if you enable beginning- and end-of-connection logging for the default action. In that case, the system does log the end of the connection when an associated intrusion policy triggers, in addition to logging the beginning of the connection.
Note that even if you disable logging for the default action, end-of-connection events for connections matching that rule may still be logged to the ASA FirePOWER module if the connection previously matched at least one access control Monitor rule.
To log connections in traffic handled by the access control default action:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon () next to the access control policy you want to modify.
The access control policy editor appears, focused on the Rules tab.
Step 3 Click the logging icon () next to the Default Action drop-down list.
The Logging pop-up window appears.
Step 4 Specify whether you want to Log at Beginning and End of Connection, Log at End of Connection, or you want No Logging at Connection.
For a single non-blocked connection, the end-of-connection event contains all of the information in the beginning-of-connection event, as well as information gathered over the duration of the session. Because blocked traffic is immediately denied without further inspection, the system logs only beginning-of-connection events for the Block All Traffic default action. For this reason, when you set the default action to Access Control: Block All Traffic you are prompted Log at Beginning of Connection.
Step 5 Specify where to send connection events. You have the following choices:
- To send connection events to the ASA FirePOWER module, select Event Viewer. You cannot disable this option for Monitor rules.
- To send events to an external syslog server, select Syslog, then select a syslog alert response from the drop-down list. Optionally, you can add a syslog alert response by clicking the add icon (
- To send events to an SNMP trap server, select SNMP Trap, then select an SNMP alert response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon (
You must send events to the event viewer if you want to perform ASA FirePOWER module-based analysis on connection events. For more information, see Logging Connections to the ASA FirePOWER Module or External Server.
Step 6 Click Store ASA FirePOWER Changes to save the policy.
Your policy is saved. You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.
Logging URLs Detected in Connections
When you log an end-of-connection event to the ASA FirePOWER module for HTTP traffic, the system records the URL requested by the monitored host during the session.
By default, the system stores the first 1024 characters of the URL in the connection log. However, you can configure the system to store up to 4096 characters per URL to make sure you capture the full URLs requested by monitored hosts. Or, if you are uninterested in the individual URLs visited, you can disable URL storage entirely by storing zero characters. Depending on your network traffic, disabling or limiting the number of stored URL characters may improve system performance.
Note that disabling URL logging does not affect URL filtering. Access control rules properly filter traffic based on requested URLs, their categories, and reputations, even though the system does not record the individual URLs requested in the traffic handled by those rules. For more information, see Blocking URLs.
To customize the number of URL characters you store:
Step 1 Select Configuration > ASA FirePOWER Configuration > Policies > Access Control Policy.
The Access Control Policy page appears.
Step 2 Click the edit icon () next to the access control policy you want to configure.
The access control policy editor appears.
Step 3 Select the Advanced tab.
Advanced settings for the access control policy appear.
Step 4 Click the edit icon () next to General Settings.
The General Settings pop-up window appears.
Step 5 Type the Maximum URL characters to store in connection events.
You can specify any number from zero to 4096. Storing zero characters disables URL storage without disabling URL filtering.
Advanced settings for the access control policy appear.
Step 7 Click Store ASA FirePOWER Changes to save the policy.
Your policy is saved. You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.