Best Practices for Connection Logging
Use the following best practices to ensure that you log only the connections you want to log.
So that you log only critical connections, enable connection logging on a per-access-control-rule basis.
Connections that are always logged
The system automatically logs the following:
-
Some connections associated with detected files, malware, intrusions, and Intelligent Application Bypass (IAB).
For more information, see Connections That Are Always Logged.
-
Monitored connections.
For more information, see Logging for Monitored Connections.
Connections to never log
Do not enable logging for the following:
-
Access control rules with a Trust action.
Trusted connections are not subject to deep inspection or discovery, so connection events for trusted connections contain limited information.
-
Do not enable logging for Block rules in passive deployments. To log connections that the system would have blocked if your devices were deployed inline, use a Monitor rule instead of a Block rule.
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.
-
Traffic you're not interested in. Examples follow:
-
Specific allowed traffic, such as DNS requests to a trusted DNS host.
-
Infrastructure traffic that is not related to your service offering.
(As previously mentioned, you can still monitor this traffic for threats.)
-
As discussed in Connections That Are Always Logged, even if you disable logging for the preceding, intrusion events, malware, and IAB are still logged.
Avoid logging what's being logged elsewhere
If another device or service is logging connection data for a network segment, disable logging for that segment's data in the CDO. Examples follow:
-
If a router logs connection events on the same network segment as the CDO, avoid logging the same connections on the CDO unless you need those connection events for something else, such as correlation policies or traffic profiles.
For more information about correlation policies, see Introduction to Correlation Policies and Rules. For more information about traffic profiles, see Introduction to Traffic Profiles.
-
If you use Secure Network Analytics to leverage NetFlow records reported from switches and routers to identify potential behavioral anomalies and suspicious traffic patterns, you can disable connection logging for rules monitoring those segments and instead rely on Secure Network Analytics for behavioral analytics for those parts of your network.
For more information, consult the Secure Network Analytics documentation.
Log either the beginning or end of the connection (not both)
If you have a choice between beginning and end-of-connection logging, enable end-of-connection logging. This is because end-of-connection logs information from beginning-of-connection events, as well as information gathered over the duration of the session.
Log the beginning of connections only if you want to log blocked connections, or if end-of-connection information does not matter to you.
For more information, see Beginning vs End-of-Connection Logging.
Logging for blocked traffic
Because blocked traffic is immediately denied without further inspection, usually you can log only beginning-of-connection events.
For more information, see Logging for Blocked Connections.
Log events to an external location
If your company's security policy permits it, you can save disk space on your CDO by streaming logs to an external source using any of the following:
-
eStreamer, which enables you to stream logs from a CDO to a custom-developed client application. For more information, see the Firepower eStreamer Integration Guide.
-
Syslog or SNMP trap, which are referred to as alert responses. For more information, see Cisco Defense Orchestrator Alert Responses.
Specify the maximum number of event records
Consider the minimum and maximum number of records that can be stored in the database. For example, a virtual CDO by default stores 10 million events but the maximum number of events is 50 million. Go to to adjust the size to meet your needs.
For a list of all CDO models and their event database sizes, see Database Event Limits.
Control what is displayed in connection events
To specify the number of rows displayed in connection events, click your username in the upper right of the CDO and click . The maximum you can set is 1000 events per page.
Set up connection event reports
To make sure you do not miss connection events, you can set up automated reports in .csv format and optionally schedule them to occur at a regular interval. For more information, see the following:
-
Use the report designer (Report Template Creation.
): -
Schedule tasks (About Task Scheduling.
):