About Connection Logging
The system can generate logs of the connections its managed devices detect. These logs are called connection events. Settings in rules and policies give you granular control over which connections you log, when you log them, and where you store the data. Special connection events, called Security Intelligence events, represent connections that were blocked by the reputation-based Security Intelligence feature.
Connection events contain data about the detected sessions. The information available for any individual connection event depends on several factors, but in general includes:
-
Basic connection properties: timestamp, source and destination IP address, ingress and egress zones, the device that handled the connection, and so on
-
Additional connection properties discovered or inferred by the system: applications, requested URLs, or users associated with the connection, and so on
-
Metadata about why the connection was logged: which configuration handled the traffic, whether the connection was allowed or blocked, details about encrypted and decrypted connections, and so on
Log connections according to the security and compliance needs of your organization. When setting up connection logging, keep in mind that the system can log a connection for multiple reasons, and that disabling logging in one place does not mean that matching connections will not be logged.
The information in a connection event depends on several factors, including traffic characteristics, the configuration that ultimately handled the connection, and so on.
 Note |
You can supplement the connection logs gathered by your managed devices with connection data generated from exported NetFlow records. This is especially useful if you have NetFlow-enabled routers or other devices deployed on networks that your Firepower System managed devices cannot monitor. |
Other Connections You Can Log
So that you log only critical connections, enable connection logging on a per-rule basis. If you enable connection logging for a rule, the system logs all connections handled by that rule.
You can also log connections handled by policy default actions. Depending on the rule or default action (and for access control, a rule's inspection configuration), your logging options differ.
SSL Policy: Rules and Default Action
You can log connections that match an SSL rule or SSL policy default action.
For blocked connections, the system immediately ends the session and generates an event. For monitored connections and connections that you pass to access control rules, the system generates an event when the session ends.
Access Control Policy: Security Intelligence Decisions
You can log a connection whenever it is 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 blocked by Security Intelligence, but still log the match. Security Intelligence monitoring also allows you to create traffic profiles using Security Intelligence information.
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, and that is also stored and pruned separately. So that you can identify the matching IP address in the connection, host icons beside blocked and monitored IP addresses look slightly different in the tables on the pages under the Analysis > Connections menus.
Access Control Policy: Rules and Default Action
You can log connections that match an access control rule or access control policy default action.
Connections That Are Always Logged
Unless you disable connection event storage, the system automatically saves the following end-of-connection events to the Firepower Management Center database, regardless of any other logging configurations.
Connections Associated with Intrusions
The system automatically logs connections associated with intrusion events, unless the connection is handled by the access control policy's 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. 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.
However, if you enable beginning-of-connection logging for the default action, the system does log the end of the connection when an associated intrusion policy triggers, in addition to logging the beginning of the connection.
Connections Associated with File and Malware Events
The system automatically logs connections associated with file and malware events.
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. |
Connections Associated with Intelligent Application Bypass
The system automatically logs bypassed and would-have-bypassed connections associated with IAB.
Monitored Connections
The system always logs the ends of connections for monitored traffic, even if the traffic matches no other rules and you do not enable default action logging. For more information, see Logging for Monitored Connections.
Beginning vs End-of-Connection Logging
You can log a connection at its beginning or its end, with the following exceptions for blocked traffic:
-
Blocked traffic—Because blocked traffic is immediately denied without further inspection, usually you can log only beginning-of-connection events for blocked traffic. There is no unique end of connection to log.
-
Blocked encrypted traffic—When you enable connection logging in an SSL policy, the system logs end-of-connection rather than beginning-of-connection events. This is because the system cannot determine if a connection is encrypted using the first packet in the session, and thus cannot immediately block encrypted sessions.
To optimize performance, log either the beginning or the end of any connection, but not both. Monitoring a connection for any reason forces end-of-connection logging. 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.
The following table details the differences between beginning and end-of-connection events, including the advantages to logging each.
|
Beginning-of-Connection Events |
End-of-Connection Events |
|||
|---|---|---|---|---|
|
Can be generated... |
When the system detects the beginning of a connection (or, after the first few packets if event generation depends on application or URL identification). |
When the system:
|
||
|
Can be logged for... |
All connections except those blocked by the SSL policy. |
Most connections |
||
|
Contain... |
Only information that can be determined in the first packet (or the first few packets, if event generation depends on application or URL identification). |
All information in the beginning-of-connection event, plus information determined by examining traffic over the duration of the session; for example, the total amount of data transmitted or the timestamp of the last packet in the connection.
|
||
|
Are useful... |
If you want to log:
|
If you want to:
|
Firepower Management Center vs External Logging
If you store connection and Security Intelligence event logs on the Firepower Management Center, you can use the Firepower System's reporting, analysis, and data correlation features. For example:
-
Dashboards and the Context Explorer provide you with graphical, at-a-glance views of the connections logged by the system.
-
Event views (most of the options available under the Analysis menu) present detailed information on the connections logged by the system, which you can display in a graphical or tabular format or summarize in a report.
-
Traffic profiling uses connection data to create a profile of your normal network traffic that you can then use as a baseline against which to detect and track anomalous behavior.
-
Correlation policies allow you to generate events and trigger responses (such as alerts or external remediations) to specific types of connections or traffic profile changes.
The number of events the Firepower Management Center can store depends on its model.
Note |
To use these features, you must log connections (and in most cases, the end of those connections rather than the beginning). This is why the system automatically logs critical connections—those associated with logged intrusions, prohibited files, and malware. |
You can also log events to an external syslog or SNMP trap server using the following:
-
For external logging on any device:
A connection you configure called an alert response.
How Rules and Policy Actions Affect Logging
Connection events contain metadata about why the connection was logged, including which configurations handled the traffic. Where you can configure connection logging, rule actions, and policy default actions determine not only how the system inspects and handles matching traffic, but also when and how you can log details about matching traffic.
Logging for Monitored Connections
The system always logs the ends of connections for traffic matching the following configurations, even if the traffic matches no other rules and you do not enable default action logging:
-
Security Intelligence—Block lists set to monitor (also generates a Security Intelligence event)
-
SSL rules—Monitor action
-
Access control rules—Monitor action
The system does not generate a separate event each time a single connection matches a Monitor rule. Because a single connection can match multiple Monitor rules, each connection event can include and display information on the first eight Monitor access control rules that the connection matches, as well as the first matching SSL Monitor rule.
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.
Logging for Trusted Connections
You can log the beginnings and ends of trusted connections, which includes traffic matching the following rules and actions:
-
Access control rules—Trust action
-
Access control default action—Trust All Traffic
Note |
Although you can log trusted connections, we recommend you do not do so because trusted connections are not subject to deep inspection or discovery, so connection events for trusted connections contain limited information. |
The system logs TCP connections handled by a Trust access control rule differently depending on the device that detected the connection:
-
For 7000 and 8000 Series devices, TCP connections detected by a Trust rule on the first packet generate different events depending on the presence of a preceding enabled Monitor rule. If the Monitor rule is active, the system evaluates the packet and generates both a beginning and end-of-connection event. If no Monitor rule is active, the system generates only an end-of-connection event.
-
For all other models, TCP connections detected by a Trust rule on the first packet generate only an end-of-connection event. The system generates the event one hour after the final session packet.
Logging for Blocked Connections
You can log blocked connections, which includes traffic matching the following rules and actions:
-
Security Intelligence—Block lists not set to Monitor (also generates a Security Intelligence event)
-
SSL rules—Block and Block with reset
-
SSL default action—Block and Block with reset
-
Access control rules—Block, Block with reset, and Interactive Block
-
Access control default action—Block All Traffic
Only devices deployed inline (that is, using routed, switched, or transparent interfaces, or inline interface pairs) 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.
 Caution |
Logging blocked TCP connections during a Denial of Service (DoS) attack can affect system performance and overwhelm the database with multiple similar events. Before you enable logging for an Block rule, consider whether the rule monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack. |
Beginning vs End-of-Connection Logging for Blocked Connections
When you log a blocked connection, how the system logs it depends on why the connection was blocked; this is important to keep in mind when configuring correlation rules based on connection logs:
-
For SSL rules and SSL policy default actions that block encrypted traffic, the system logs end-of-connection events. This is because the system cannot determine if a connection is encrypted using the first packet in the session.
-
For other blocking actions, the system logs beginning-of-connection events. Matching traffic is denied without further inspection.
Logging Bypassed Interactive Blocks
Interactive blocking access control rules, which cause the system to display a warning page when a user browses to a prohibited website, allow you to configure end-of-connection logging. 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.
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 BlockorInteractive 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
Allowand a reason ofUser BypassThe following figure shows an example of an interactive block followed by allow.
Logging for Allowed Connections
You can log allowed connections, which includes traffic matching the following rules and actions:
-
SSL rules—Decrypt action
-
SSL rules—Do not decrypt action
-
SSL default action—Do not decrypt
-
Access control rules—Allow action
-
Access control default action—Network Discovery Only and any intrusion prevention option
Enabling logging for these configurations ensures the connection is logged, while also permitting (or specifying) the next phase of inspection and traffic handling. SSL logging is always end-of-connection; access control configurations also allow beginning-of-connection logging.
When you allow traffic with an access control rule or default action, you can use an associated intrusion policy to further inspect traffic and block intrusions. For access control rules, you can also use a file policy to detect and block prohibited files, incuding malware. Unless you disable connection event storage, the system automatically logs most allowed connections associated with intrusion, file, and malware events. For detailed information, see Connections That Are Always Logged.
Connections with encrypted payloads are not subject to deep inspection, so connection events for encrypted connections contain limited information.
File and Malware Event Logging for Allowed Connections
When a file policy detects or blocks a file, it logs one of the following events to the Firepower Management Center database:
-
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
You can disable this logging on a per-access-control-rule basis. You can also disable file and malware event storage entirely.
Note |
We recommend you leave file and malware event logging enabled. |
)
)
)
Feedback