Cisco Cisco Firepower Management Center 4000

In general, if you want to perform any kind of detailed analysis on connection data, you should log 
connection events at the end of connections. This is because beginning-of-connection events do not have 
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. 

For this reason, the system uses only end-of-connection data to populate connection summaries (see 

). which the system then uses to create connection 

graphs and traffic profiles. Therefore, if you want to use the view connection summaries in custom 
workflows, view connection data in graphical format, or create and use traffic profiles, you must log 
connection events at the end of connections. 

If, however, you simply want to log an event each time the system detects a new connection, 
beginning-of-connection events are sufficient. You can trigger correlation rules based on either 
beginning- or end-of-connection events.

Because matching traffic is denied without further inspection, blocking rules can only log 
beginning-of-connection events. You can, however, configure end-of-connection logging for interactive 
blocking rules. This is because when the user clicks through the warning page displayed by the system, 
(see 

), the connection is considered a new, allowed 

connection which the system can monitor until it terminates.

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 HTTP request is initially blocked; this event has an 
associated action of 

Interactive Block

 or 

Interactive Block with reset

 in the connection log

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 of 

User Bypass

For packets that match a Monitor rule, the system always generates a connection event at the end of the 
connection, regardless of the logging configuration of the rule or default action that later handles the 
connection. In other words, if a packet matches a Monitor rule, the connection is always logged, even if 
the packet matches no other rules and you do not enable logging on the default action. 

Because traffic matching a Monitor rule 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 is one of:

the action for the first non-Monitor rule triggered by the connection, or

the default 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 logged to the 
Defense Center database can include and display information on up to eight matched monitor rules — 
the first eight Monitor rules that the connection matches.

Similarly, if you send connection events to the syslog or an 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 first eight Monitor rules that the 
connection matched.