Logging Settings for Access Control Rules
The logging settings for an access rule determine whether connection events are issued for traffic that matches the rule.
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.
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 a Block rule, consider whether the rule is for an Internet-facing interface or other interface vulnerable to DoS attack.
- Create or edit the access control rule and click the Logging tab.
- Specify the log action:
- Log at Beginning and End of Connection—Issue events at the start and end of a connection. Because end-of-connection events contain everything that start-of-connection events contain, plus all of the information that could be gleaned during the connection, Cisco recommends that you do not select this option for traffic that you are allowing. Logging both events can impact system performance. However, this is the only option allowed for blocked traffic.
- Log at End of Connection—Select this option if you want to enable connection logging at the end of the connection, which is recommended for allowed or trusted traffic.
- Log None—Select this option to disable logging for the rule. This is the default.
Note: 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, regardless of the logging configuration of the rule. 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.
- Specify where to send connection events:
If you want to send a copy of the events to an external syslog server, select the server object that defines the syslog server. If the required object does not already exist, you will need to create one. See Create and Edit Syslog Server Objects for more information.
Because event storage on the device is limited, sending events to an external syslog server can provide more long-term storage and enhance your event analysis.
For Cisco Security Analytics and Logging subscribers:
- If you send events to the Cisco cloud through a Secure Event Connector (SEC), specify an SEC as your syslog server. You will then be able to see these events alongside file policy and malware policy connection events.
- If you send events directly to the Cisco cloud without an SEC, specify when to log events (at the beginning or end of the connection) but do not specify the SEC as the syslog server.
- File Events
Check Log Files if you want to enable logging of prohibited files or malware events. You must select a file policy in the rule to configure this option. The option is enabled by default if you select a file policy for the rule. We recommend you leave this option enabled.
When the system detects a prohibited file, it automatically logs one of the following types of event to the FDM internal buffer.
- 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.
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)
- Click Save.
- Review and deploy now the changes you made, or wait and deploy multiple changes at once.