|
|
< Day Day Up > |
|
System MonitoringThe security appliance can generate system and debug messages when an event occurs. These messages can be logged to the local buffer or to an external server, depending on an organization's security policies. This section discusses how to enable event logging and Simple Network Management Protocol (SNMP) polling, which can be used to check the status of the security appliance. This section also discusses how to monitor the health of the security appliance by monitoring the CPU and memory utilization. System LoggingSystem logging is a process by which the Cisco ASA generates an event for any significant occurrence that affects the system, such as network problems, error conditions, and threshold breaches. These messages can either be stored locally on the system buffer or be transferred to external servers. You can use these logs for event correlations to detect network anomalies or you can use them for monitoring and troubleshooting purposes. The security appliance assigns a message ID to each event it generates. These message IDs range from 101001 to 720073 and contain a brief description of the event. The security appliance also associates each message ID to a severity level ranging from 0 to 7. The lower the severity level number is, the more critical the message is. Table 4-12 lists the severity levels, along with the associated keyword and a brief description.
Each severity level not only displays the events for that level but also shows the messages from the lower severity levels. For example, if logging is enabled for debugging (level 7), the security appliance also logs levels 0 through 6. Note For a complete list of all the severity messages, please consult the System Log Messages Guide located at Cisco.com. The next subsection discusses how to enable logging on the security appliance to log relevant events. Enabling LoggingTo enable logging of system events, use the logging enable command, as shown in Example 4-53. This global command sends logs to all the terminals and devices set up to receive the syslog messages. Example 4-53. Enabling System LoggingChicago(config)# logging enableOnce the logging is enabled, ensure that the messages are timestamped before they are sent. Use the logging timestamp command to enable the timestamp in the syslog messages, as shown in Example 4-54. Example 4-54. Enabling Syslog TimestampsChicago(config)# logging timestampThe security appliance's robust operating system allows specific events and severities to be logged to specific hosts. For example, the VPN-related log messages can be stored in the local buffer, while all other events can be sent to an external syslog server. This is done by defining a logging list to specify the interesting event messages. The following are the command syntaxes of logging list: logging list event_list level sev_level [class event_class] logging list event_list message start_id[-end_id] Note The default severity level for a logging list is 3 (errors). event_list is a list name that specifies the level of messages the security appliance should be logging. Use the level keyword followed by a logging level to identify messages by the specified severity level, which also covers the higher severity level messages. You can optionally classify the messages within the logging level by using the class keyword and an event class name. The security appliance comes with predefined event classes to log specific processes. These classes include: In Example 4-55, a logging list called IPSec_Crit is set up to group all the IPSec messages. The selected severity level is critical, which also includes level 0 and level 1 events. Example 4-55. Setting Up a Logging ListChicago# configure terminal Chicago(config)# logging list IPSec_Crit level critical class vpn Logging TypesCisco ASA supports the following types of logging capabilities: The followings sections describe each logging type in detail. Console LoggingConsole logging enables the security appliance to send syslog messages to the console serial port. This method is useful for viewing specific live events during troubleshooting. Use the logging console command to set up console logging. The complete command syntax for logging console is as follows: logging console event_list | sev_level In Example 4-56, event logs that are identified in an event list called IPSec_Cric are being viewed on the console port. Example 4-56. Enabling Console LoggingChicago# configure terminal Chicago(config)# logging list IPSec_Cric level critical class vpn Chicago(config)# logging console IPSec_Cric Caution Enable console logging with caution; the serial port is only 9600 bits per second, and the syslog messages can easily overwhelm the port. If the port is already overwhelmed, access the security appliance from an alternate method, such as SSH or Telnet, and lower the severity. Terminal LoggingTerminal logging sends syslog messages to a remote terminal monitor such as a Telnet or a SSH session. It is useful for viewing live events during troubleshooting. Use the logging monitor command to set up terminal monitoring, which uses the same arguments as the logging console command. In Example 4-57, event logs that are identified in an event list called IPSec_Cric and all the messages with the severity level set to 0 (emergencies) and 1 (alerts) are being viewed. Example 4-57. Setting Up Terminal LoggingChicago# configure terminal Chicago(config)# logging list IPSec_Cric level critical class vpn Chicago(config)# logging monitor IPSec_Cric Chicago(config)# logging monitor alerts Buffered LoggingThe security appliance allocates 4096 bytes of memory to store log messages in the buffer. This is the preferred method to troubleshoot an issue because it does not overwhelm the console or terminal ports. Buffered logging can be enabled by using the logging buffered command, as shown in Example 4-58. All severity levels up to level 3 (errors) are being sent to the buffer. To ensure that the security appliance does not run out of the allocated memory, the buffer size is increased to 16,384 bytes by using the logging buffer-size command. Example 4-58. Setting Up Buffered LoggingChicago# configure terminal Chicago(config)# logging buffered errors Chicago(config)# logging buffer-size 16384 Note The allocated memory is a circular buffer; consequently, the security appliance will not run out of memory. View the buffered logs by using the show logging command, as demonstrated in Example 4-59. This shows all different types of logging supported on the security appliance and indicates whether they are enabled or disabled. Additionally, it provides the number of messages logged on each of the configured logging types with the logging severity. Each syslog message starts with %ASA, to indicate that a Cisco security appliance generated the message, followed by the logging level, the unique message ID, and then a brief string to describe the log message. Example 4-59. Output of show loggingChicago# show logging
Syslog logging: enabled
Facility: 20
Timestamp logging: disabled
Standby logging: disabled
Deny Conn when Queue Full: disabled
Ambiguous interface parameters: 98
Console logging: disabled
Monitor logging: list IPSec_Cric, 293 messages logged
Buffer logging: level errors, 174 messages logged
Trap logging: disabled
History logging: disabled
Device ID: disabled
Mail logging: disabled
ASDM logging: disabled
%ASA-3-109013: User must authenticate before using this service
%ASA-3-109020: Downloaded ACL has config error; ACE
%ASA-3-113001: Unable to open AAA session. Session limit 3
! Output omitted for brevityThe buffered log messages can be saved to the local flash or to an FTP server for future analysis. The security appliance supports three methods to save buffered logs:
Using the manual flash logging method, you can save the log messages located in the buffer space to the local flash (disk0: or disk1:). The security appliance creates a file in the /syslog directory of flash using the default name of LOG-YYYY-MM-DD-HHMMSS.TXT, where YYYY stands for year, the first MM for month, DD for days, HH for hours, the second MM for minutes, and SS for seconds. In Example 4-60, the buffered logs are saved in flash using the logging savelog command and the default filename. Check the flash directory to make sure that the file is successfully saved, by using the dir /recursive command. Example 4-60. Manual Saving of Logs in FlashChicago# logging savelog Chicago# dir /recursive Directory of disk0:/* 9 -rw- 5124096 05:37:16 Aug 6 2005 ASA702.bin Directory of disk0:/syslog 5461 -rw- 16384 06:25:26 Aug 6 2005 LOG-2005-08-06-062527.TXT Note The Cisco ASA uses the local clock settings to add the timestamp. Consult the section "System Clock" earlier in this chapter. The security appliance can auto-save the buffered log messages to the local flash using the logging flash-bufferwrap command, as shown in Example 4-61. The security appliance uses the same format of the filename discussed in the previous example. Each file size depends on the buffer size, discussed in the "Buffered Logging" section. To ensure that there is room left in flash for other administrative tasks, use the logging flash-minimum-free command and specify the minimum space in kilobytes (4 MB in this case) that the security appliance should maintain. You can, optionally, specify the maximum space the security appliance can use to store the buffered logs in flash. This is accomplished by using the logging flash-maximum-allocation command. Example 4-61 shows that the security appliance is allocating 2 MB of space to save logs in flash. Example 4-61. Automatic Saving of Logs in FlashChicago# configure terminal Chicago(config)# logging flash-bufferwrap Chicago(config)# logging flash-maximum-allocation 2000 Chicago(config)# logging flash-minimum-free 4000 The security appliance can transfer the buffer logs to an FTP server to conserve disk space. This is done by using the logging ftp-bufferwrap command. An FTP server is specified to store the log files. In Example 4-62, an appliance is set up to send log files to an FTP server, located at 192.168.10.150. The username to log into the FTP server is cisco with a password of cisco123. The logs will be stored in the root directory (.) for that user. Example 4-62. Automatic Saving of Logs in the FTP ServerChicago# configure terminal Chicago(config)# logging ftp-bufferwrap Chicago(config)# logging ftp-server 192.168.10.150 . cisco cisco123 E-Mail LoggingThe security appliance supports sending log messages directly to individual e-mail addresses. This feature is extremely useful when you are interested in getting immediate notification when the security appliance generates a specific log message. Use the logging mail command followed by the name of the event list or the logging level to set up e-mail logging. When an interesting event is produced, the security appliance contacts the specified e-mail server and sends out an e-mail message to the e-mail recipient from a preconfigured e-mail account. The smtp-server command is used to configure an e-mail server, while the recipient-address command specifies an e-mail address to which to send messages. The logging from-address command uses a preconfigured e-mail address to generate the log messages. In Example 4-63, a logging list called FO_Cable is set up with a message ID of 101002 to classify the failover cable issues. This logging list is linked to send e-mail messages from Chicago@securemeinc.com to e-mail address admin@securemeinc.com using 209.165.201.10 as the primary e-mail server and 209.165.201.11 as the secondary e-mail server. Example 4-63. Configuration of E-Mail LoggingChicago(config)# logging list FO_Cable message 101002 Chicago(config)# logging mail FO_Cable Chicago(config)# logging from-address Chicago@securemeinc.com Chicago(config)# logging recipient-address admin@securemeinc.com level errors Chicago(config)# smtp-server 209.165.201.10 209.165.201.11 ASDM LoggingCisco Adaptive Security Device Manager (ASDM) is a GUI that you can use to configure and monitor the security appliance. Use the logging asdm command to send log messages to a connected ASDM host. You can specify the number of messages that can exist in the ASDM buffer. You do this by using the logging asdm-buffer-size command followed by the actual number of messages, as shown in Example 4-64. The security appliance is set up to send messages with the logging level set to notifications or lower, while the ASDM buffer size is set to hold 512 messages. Example 4-64. Setting Up ASDM LoggingChicago# configure terminal Chicago(config)# logging asdm notifications Chicago(config)# logging asdm-buffer-size 512 Note ASDM is discussed in Chapter 18 in greater detail. Syslog Server LoggingCisco ASA supports sending the event logs to an external syslog server. Messages can be stored for use in anomaly detection or event correlation. The security appliance allows the use of both TCP and UDP protocols to communicate with a syslog server. To configure a syslog server, use the logging host command followed by the IP address of the server. For UDP-based syslogs, the security appliance allows logging of messages in the Cisco EMBLEM format. Many Cisco devices, including the Cisco IOS routers and CiscoWorks management server, use this format of syslogging. In Example 4-65, two syslog servers are defined to send the log messages. The first server collects the logs using UDP and in the Cisco EMBLEM format, while the other server uses TCP port 1300 to accept the syslog messages. The security appliance will send all logging level 7 and below messages to these servers. This is done by using the logging trap debugging command. Example 4-65. Setting Up Syslog ServersChicago# configure terminal Chicago(config)# logging host inside 192.168.10.160 format emblem Chicago(config)# logging host outside 192.168.10.170 TCP/1300 Chicago(config)# logging trap debugging For TCP-based syslog servers, the security appliance drops the new connections if the session to the syslog server cannot be established. This default behavior can be changed by using the logging permit-hostdown command, as demonstrated in Example 4-66. Example 4-66. Allowing Syslog Messages when a TCP-Based Syslog Server Is DownChicago# configure terminal Chicago(config)# logging permit-hostdown Additional Syslog ParametersThe security appliance does not send debug logs, such as debug crypto, to a syslog server unless the logging debug-trace command is turned on, as shown in Example 4-67. Example 4-67. Allowing Syslog Messages when a TCP-Based Syslog Server Is DownChicago# configure terminal Chicago(config)# logging debug-trace The security appliance sends all log messages to the logging devices, internal and external. However, if you are not interested in logging a particular message, you can suppress it by using the no logging message command followed by the message ID number, as shown in Example 4-68, where message ID 101001 is disabled. Example 4-68. Disabling a Message IDChicago# configure terminal Chicago(config)# no logging message 101001 Simple Network Management ProtocolSNMP is an application layer protocol that was developed to monitor the health of network devices. It has become a de facto standard because of its simple protocol design. A successful SNMP implementation requires a management station, also known as the manager, and at least one agent, such as the Cisco ASA. The network management station, such as CiscoWorks, monitors the agents by collecting the device and network information and presenting it in a GUI. The agents, on the other hand, respond to the manager's request for information. If an important event occurs, the agents can also initiate a connection to the manager to send the message. The SNMP implementation uses the following five message types, known as protocol data units (PDUs), for the communication between the management station and the agent:
The GET and GET-NEXT messages are initiated by the network manager to request specific information by using the Management Information Base (MIB). The agent replies with a GET-RESPONSE, which provides the requested information, if available. In a case where the requested information is not available, the agent sends an error with a reason why the request cannot be processed. The SET message type is used by the network manager to change or add values in the configuration rather than retrieve the information. The agent replies with a GET-RESPONSE message to indicate whether the change was successful. The TRAP messages are agent-initiated to inform the network manager about an event, such as a link failure, so that an immediate action can be taken. Figure 4-8 illustrates the PDU communication between a security appliance, as an agent, and a CiscoWorks server, as a management server. Figure 4-8. SNMP Communication Between the Cisco ASA and CiscoWorks
Note The security appliance does not allow SET PDUs, for device-security reasons. Consequently, the configuration of the security appliance cannot be modified using SNMP. Configuring SNMPThe security appliance must be configured before a network management server can initiate a connection. The SNMP configuration is discussed in the following steps: SNMP MonitoringThe show snmp-server statistics command is useful for checking the statistics of the SNMP engine. It displays not only the total SNMP packets received and transmitted but also any bad or illegal packets handled by the security appliance. Example 4-69 displays the output of this command, where the security appliance received 12 GET requests and replied to all of them as GET-RESPONSE. Example 4-69. Output of show snmp-server statisticsChicago# show snmp-server statistics 12 SNMP packets input 0 Bad SNMP version errors 0 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 36 Number of requested variables 0 Number of altered variables 12 Get-request PDUs 0 Get-next PDUs 0 Get-bulk PDUs 0 Set-request PDUs (Not supported) 12 SNMP packets output 0 Too big errors (Maximum packet size 1500) 0 No such name errors 0 Bad values errors 0 General errors 12 Get-response PDUs 0 SNMP trap PDUs CPU and Memory MonitoringThe show cpu usage command indicates current CPU utilization. It displays an approximation of load every 5, 60, and 300 seconds. Example 4-70 shows that the 5-second utilization is 2 percent, while the 1-minute and 5-minute utilizations are 1 percent. Example 4-70. Output of show cpu usageChicago(config)# show cpu usage
CPU utilization for 5 seconds = 2%; 1 minute: 1%; 5 minutes: 1%The security appliance can display memory usage through the show memory command. It shows a summary of the available and allocated memory in bytes and as a percentage. In Example 4-71, the free memory on the security appliance is 969,397,424 bytes (~921 MB), while the allocated or used memory is 104,344,400 bytes (~103 MB). The total memory on the security appliance is 1024 MB. Example 4-71. Output of show memoryChicago# show memory
Free memory: 969397424 bytes (90%)
Used memory: 104344400 bytes (10%)
------------- ----------------
Total memory: 1073741824 bytes (100%)Note Using the show memory detail command with show memory binsize allows you to check the number of bytes allocated to a given size memory chunk. These commands should be used under a TAC engineer's supervision if advanced memory troubleshooting needs to be done. The security appliance can display the system buffer utilization if the show block command is executed. When the security appliance boots up, the operating system carves out memory to create the maximum number of blocks for different block sizes. The maximum number of blocks does not change, except for the 256 and 1550 size blocks. For these blocks, the security appliance can dynamically create more blocks if necessary. The security appliance allocates a block from the pool when it needs to use it, and returns it when it is done using it. There are nine different sizes of buffer blocks, and each buffer type is responsible for handling specific packets. Table 4-13 shows the buffer block sizes and provides a brief description on where they are used.
When you run the show block command, the security appliance displays the following counters:
In Example 4-72, the security appliance has allocated 300 blocks for 4-byte block size, and it is currently using one block. The LOW counter is set to 299 because the security appliance had allocated only one block of it since the last reboot. Example 4-72. Output of show blockChicago# show block
SIZE MAX LOW CNT
4 300 299 299
80 1200 1199 1200
256 1100 1098 1100
1550 13316 11777 11785
2560 1990 1990 1990
4096 80 80 80
8192 160 160 160
16384 250 250 250
65536 16 16 16 |
|
|
< Day Day Up > |
|