Verifying Event and Session Logging
Only a few commands are used to verify the configuration and functionality of logging. Example 6-3 shows the use of the show logging command to see a summary of the logging configuration, along with any internally buffered log messages.
Example 6-3. Verifying Logging
FIREWALL# show loggingSyslog logging: enabledFacility: 20Timestamp logging: enabledStandby logging: disabled Debug-trace logging: disabledConsole logging: disabledMonitor logging: disabled Buffer logging: level debugging,5548 messages loggedTrap logging: level warnings, facility 20, 2145 messages logged Logging to management 192.168.1.7 History logging: disabled Device ID: hostname "FIREWALL" Mail logging: list ALERT_ADMIN_BY_EMAIL, 0 messages logged ASDM logging: level informational, 802 messages logged Jan 03 2011 16:10:13 FIREWALL : %ASA-7-609001: Built local-host management:192.168.1.15 Jan 03 2011 16:10:19 FIREWALL : %ASA-4-418001: Through-the-device packet to/from management-only network is denied: tcp src management:192.168.1.3/50388 dst out- side:192.168.100.4/22 Jan 03 2011 16:10:23 FIREWALL : %ASA-7-609002: Teardown local-host manage- ment:192.168.1.15 duration 0:00:10 ...output omitted...
The output shows several important pieces of information, which are shaded for easy reference. Logging is globally enabled. Timestamps are enabled. Console logging is disabled, as it should be on production devices, except in rare circumstances. For each configured destination, you can see the number of logged messages. Additionally, if you are using a TCP syslog server, the connection from the ASA to the syslog server will be shown.
At the end of the configuration summary, you will see the full contents of the internal log buffer. This output is truncated here.
To verify NetFlow export operation, use the show flow-export counters command, as shown in Example 6-4. A non-zero packet count will prove that the security appliance is sending NetFlow v9 records to the configured NetFlow collector.
Example 6-4. Verifying NetFlow Export
FIREWALL# show flow-export counters
destination: management 192.168.1.13 2055
Statistics:
packets sent 14327
Errors:
block allocation failure 0
invalid interface 0
template send failure 0
no route to collector 0
Implementation Guidelines
When implementing event and session logging, consider the following implementation guidelines:
- Depending on the requirements of your local security policy, some events can be deleted, archived, or partially archived. This depends on the amount of event history available for online retrieval, the need for long-term reporting, and regulatory and legal requirements, which might require a specific retention period or, conversely, not allow certain types of personal information to be stored in an event database or event archives. Therefore, you should create a log retention policy that will enable you to store appropriate logs for an appropriate amount of time.
- It is generally best to log too much information as opposed to too little. Gathering too much information typically is harmless, unless it causes performance or capacity issues, whereas gathering too little information might prevent you from having information necessary to respond effectively to incidents or to meet regulatory requirements.
- Tune logging to exclude duplicate information. Some events might be redundant or not needed in your local environment. Make sure you analyze the event feed thoroughly to review and confirm these duplicates.
- Use multiple destinations for logging, to increase reliability of the information gathered.
- Try to handle boundary conditions, such as excessive event rate and lack of storage space, appropriately and without interruptions to service. Monitoring should be regularly tested and validated for accuracy, to ensure that changes to the system have not disabled desired functionality.
- Synchronize the security appliance clock to a reliable time source, to ensure trustworthy logging of time stamps.
- Transport events over the network using reliable and secure channels, if possible. Use a trusted network, or at least authenticate and verify the integrity of messages. To ensure reliability and no packet loss, consider using TCP transport for log messages to remote servers.
- To provide the most scalable remote event export in high-connection-rate environments, consider using NetFlow instead of syslog to report on network events.
- Limit access to the security appliance logging subsystem (so that logging cannot be disabled without detection), the central event database, and long-term event archives. Implement mechanisms to prevent or detect changes to stored event data.
- Consider using an appliance-based logging server, especially when output from multiple sources will be collected, or where real-time event parsing along with event correlation might be required.