Home > Articles > Cisco > CCNP Security

  • Print
  • + Share This
This chapter is from the book

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 logging

   Syslog logging: enabled

    Facility: 20
    Timestamp logging: enabled

    Standby logging: disabled
    Debug-trace logging: disabled
    Console logging: disabled

    Monitor logging: disabled
    Buffer logging: level debugging, 5548 messages logged
    Trap logging: level warnings, facility 20, 2145 messages logged
        Logging to management
    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
Jan 03 2011 16:10:19 FIREWALL : %ASA-4-418001: Through-the-device packet to/from
  management-only network is denied: tcp src management: dst out-
Jan 03 2011 16:10:23 FIREWALL : %ASA-7-609002: Teardown local-host manage-
  ment: 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 2055
    packets sent                                          14327
    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.
  • + Share This
  • 🔖 Save To Your Account