12-2. Configuring IOS Firewall Logging The IOS firewall uses logging to send system messages to a logging facility. Messages are generated according to a severity level (0 through 7). Logging messages can be sent to any of five different facilities: This chapter discusses only buffered and Syslog logging. You can set the logging level to determine which messages should be sent to each of the facilities. When you set a severity level for a facility, all messages with a lower severity level are also sent. You should always add time stamps to Syslog messages to help in real-time debugging and management. The IOS firewall can add time stamps as messages are generated, or a Syslog server can add time stamps as messages are received. TIP You should have all your network devices use a common time reference point so that all the time stamps on all logging messages are synchronized. You can do this by configuring firewalls, routers, switches, and Syslog servers to use one or more NTP servers as a time source.
Each logging message has a severity level associated with it. Logging severity levels are used to identify a threshold of desired information. Each level also includes every level below it. The higher the severity level, the more types of messages that are included. You can use the following severity levels: Emergencies (0) Alerts (1) Critical (2) Errors (3) Warnings (4) Notifications (5) Informational (6) Debugging (7)
System messages are logged in EMBLEM format, as shown in Figure 12-1. Each message has the following fields: Time stamp The date and time from the IOS firewall clock (the default is no time stamp). Device-ID Uniquely identifies the IOS firewall that is generating the message. The device ID, also called the origin ID, is not used by default, but it can be configured to show the firewall IP address. Message ID This always begins with %FW-, followed by the severity level, followed by a mnemonic. Message text A description of the event or condition that triggered the message.
Figure 12-1. IOS Firewall Logging Message Format 
NOTE When an IOS firewall sends logging to a Syslog server, it uses UDP port 514. The MNEMONIC portion of the message is arbitrarily defined by Cisco and uniquely identifies each logging message. The Syslog messages related to IOS firewall functions are listed in the section "IOS Firewall Logging Messages," as well as in several other appropriate places in this chapter.
Syslog Server Suggestions To make full use of the logging messages generated by a firewall, you need a Syslog server application running somewhere in your network. Here are some recommendations for Syslog servers: Kiwi Syslog Daemon A commercial Syslog server for Windows-based platforms, available at http://www.kiwisyslog.com. CiscoWorks 2000 A Syslog server is built into the Resource Manager Essentials (RME) module of the base CiscoWorks 2000 package. If you have CiscoWorks VMS, IOS firewall Syslog can be collected directly. Cisco PIX Firewall Syslog Server (PFSS) A Syslog server available in the Cisco.com Software Center, under PIX Firewall Software. A valid Cisco.com user account is required to access the PFSS. Syslog server Available as a part of the FirewallAnalyzer product from eIQnetworks at http://www.eiqnetworks.com. Syslog server Available as part of the PrivateI and enVision analysis products from Network Intelligence Corporation at http://www.network-intelligence.com. UNIX syslogd A Syslog daemon is built into most versions of the UNIX operating system.
TIP If you have a large network with firewalls that generate a large amount of Syslog information, an average Syslog server software application might become overwhelmed with the load. The end result is that logging messages are lost or that the Syslog server runs out of storage space. In this case, you should consider moving the Syslog resources to a hardware platform. For example, Network Intelligence Corporation (http://http://www.network-intelligence.com) offers Syslog collection and analysis based on hardware appliances. Logging appliances can also be clustered, offering collection rates of up to 30,000 Syslog events per second.
Logging Configuration Use the following steps to configure logging on an IOS firewall router: 1. | (Optional) Keep an internal log of buffered messages.
(Optional) Enable the firewall's internal buffer: IOSFirewall(config)# logging buffered level
The firewall keeps a buffer in memory that can hold the most recent logging messages. Messages at or below level (the severity level0 to 7) are held in the buffer. The logging buffer can be handy if you don't have access to a Syslog server or if the Syslog server is unavailable. To see the buffered messages, use the show logging EXEC command. (Optional) Adjust the logging buffer size: IOSFirewall(config)# logging buffered buffer-size
Logging messages are copied to a circular buffer of size buffer-size (4096 to 4,294,967,295 bytes). The buffer is maintained until the IOS firewall is reloaded or loses power.
TIP The default size of the logging buffer varies according to the router platform. You can display the current buffer size with the show logging command. The size is shown just before the logging buffer contents are displayed, as in the following example: IOSFirewall# show logging Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled) Console logging: level debugging, 48 messages logged, xml disabled Monitor logging: level debugging, 0 messages logged, xml disabled Buffer logging: level debugging, 48 messages logged, xml disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Trap logging: level informational, 56 message lines logged Logging to 192.168.199.52, 4 message lines logged, xml disabled Log Buffer (4096 bytes): Jan 21 15:56:17.480 EST: %SYS-5-CONFIG_I: Configured from console by vty0 (192.168.199.35)
| 2. | (Optional) Log to a Syslog server.
Set the logging level: IOSFirewall(config)# logging trap level
Messages at or below the severity level (1 to 7) are sent to any configured Syslog server address. TIP Notice that logging to a Syslog server requires the trap keyword, even though SNMP traps are not used. Logging to an SNMP management station with true SNMP traps is configured with the logging history command. (Optional) Use a consistent source address for Syslog messages: IOSFirewall(config)# logging source-interface type mod/num
A Syslog server usually records the originating IP address along with each message received. When an IOS firewall sends Syslog messages, it uses the IP address of the outgoing interface as the source. You can use this command to make sure the IOS firewall always identifies itself with a consistent address. (Optional) Add an identifier to each message: IOSFirewall(config)# logging origin-id [ip | hostname | string text]
You can use the logging origin-id command to add an identifier at the beginning of each Syslog message. This can be useful when you need to search through Syslog records that have been collected from many firewalls or network devices. By default, no identifier is sent. The identifier can be ip (the IP address of the sending, or source, interface), hostname (the router's host name), or string (the arbitrary string text, up to 255 characters). If a text string is used, it can't contain spaces unless it is surrounded by quotation marks. If you do not enter any of these keywords, ip is the default. Select a Syslog server to receive messages: IOSFirewall(config)# logging ip-address
Syslog messages are sent to the server at ip-address. You can repeat this command to define multiple Syslog servers. In that case, the same logging messages are replicated to each server at the same time. (Optional) Add time stamps to Syslog messages: IOSFirewall(config)# service timestamps log datetime [localtime] [show-timezone] [msec] [year]
By default, Syslog messages are sent with no indication of the date or time they occurred. In this case, the Syslog server should add its own time stamps to the messages as they are received. Make sure the Syslog server synchronizes its clock with a known, accurate source. The service timestamps log datetime command causes the IOS firewall to add a date and time stamp to each Syslog message before it is sent. The IOS firewall should have its clock set and time synchronized to a known and accurate sourcepreferably an NTP server that is common to all devices on your network. Add the localtime keyword to use the local time zone in the time stamps, as opposed to the default UTC. The show-timezone keyword causes the time zone's abbreviation to be added to the time stamp. By default, time stamps include hours, minutes, and seconds. You can use the msec keyword to add milliseconds too. This can be important if you need to analyze the IOS firewall activity during a very busy timeframe. Use the year keyword to add the year to the time stamp.
TIP You can add time stamps to debugging messages separately with the service timestamps debug command. This command has the same syntax and keywords as its logging counterpart. Debugging messages from the debug command are normally sent as Syslog messages with severity level 7 (debugging). However, logging time stamps aren't added to these, because they are still considered debugging messages. You should use both service timestamps commands to enable time stamps on all types of messages, as in the following commands: IOSFirewall(config)# service timestamps log datetime localtime show-timezone msec year IOSFirewall(config)# service timestamps debug datetime localtime show-timezone msec year
| 3. | (Optional) Enable logging to all configured destinations:
Firewall(config)# logging on
By default, logging is globally enabled. If logging has been disabled for some reason, you can use this command to re-enable it.
NOTE The IOS and PIX firewalls are different in this respect. PIX logging is globally disabled by default. | 4. | Verify that logging messages are being sent.
Use the show logging command to verify where logging messages are being sent. The first few lines of output show message counters for every possible logging destination. For example, the IOS firewall in the following example has sent 1862 messages to the internal buffer and 1866 messages to the Syslog host at 192.168.100.100:
IOSFirewall# show logging Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled) Console logging: disabled Monitor logging: level debugging, 3 messages logged, xml disabled Buffer logging: level debugging, 1862 messages logged, xml disabled Logging Exception size (4096 bytes) Count and timestamp logging messages: disabled Trap logging: level informational, 1866 message lines logged Logging to 192.168.100.100, 1866 message lines logged, xml disabled Log Buffer (8192 bytes): [output deleted]
If you cannot clearly determine that the firewall is sending Syslog messages, you can use another method to force messages to be sent while watching them being received at the destination. First, make sure that the logging destination has been configured for severity level 5 or greater. Then, from enable mode in a session, run the following EXEC commands:
IOSFirewall# configure terminal IOSFirewall(config)# exit
This enters and exits configuration mode without making any changes. You should see the following logging messages displayed at the appropriate logging destination:
Mar 10 13:12:46.347 EST: %SYS-5-CONFIG_I: Configured from console by dhucaby on vty1 (192.168.4.199)
|
TIP You can view the IOS firewall's internal logging buffer with the show logging EXEC command. The most recent messages are shown. To clear the internal logging buffer, you can use the clear logging command.
IOS Firewall Logging Messages Cisco firewall logging messages are listed in this section grouped according to their default (predefined) severity levels (0 to 7 from highest to lowest): 0 Emergencies 1 Alerts 2 Critical messages 3 Errors 4 Warnings 5 Notifications 6 Informational messages 7 Debugging messages
The logging messages listed here are based on Cisco IOS software Release 12.3. You can use this section when you choose a severity level for a logging destination. Make sure the level you choose will generate the messages you need to see. In each of the message tables, you can find the default severity level as part of the message prefix. For example, the prefix %IPNAT-6-NATCREATE uses severity level 6. NOTE When you choose a severity level, remember that logging messages from that level and all lower-numbered levels are sent. Only the messages from a higher-numbered level are not sent.
Table 12-1 lists the Syslog messages that are related to Network Address Translation (NAT) IOS firewall functions. These messages are based on Cisco IOS software Release 12.3T. Table 12-1. NAT-Related IOS Firewall Syslog MessagesMessage Prefix | Message Description |
|---|
%IPNAT-6-NATCREATE | A NAT entry has been created in the NAT database. | %IPNAT-6-NATDELETED | A NAT entry has been deleted from the NAT database. |
Table 12-2 lists the Syslog messages that are related to Content-Based Access Control (CBAC) Inspection IOS firewall functions. These messages are based on Cisco IOS software Release 12.3T. Table 12-2. CBAC-Related IOS Firewall Syslog MessagesMessage Prefix | Message Description |
|---|
%FW-4-ALERT_OFF | The half-open connection rate or new connection rate has decreased; an attack may have stopped. | %FW-4-ALERT_ON | The high threshold of half-open connection rate or new connection rate has been exceeded. | %FW-2-BLOCK_HOST | The host that is generating too many half-open connections is being blocked. | %FW-3-DROP_PKT | Firewall inspection has dropped a packet. | %FW-3-FTP_NON_MATCHING_IP_ADDR | A host has attempted to open an FTP connection to somewhere other than the original destination. | %FW-3-FTP_PRIV_PORT | A host has attempted to gain access to a privileged port through FTP. | %FW-3-FTP_SESSION_NOT_AUTHENTICATED | A host has attempted to gain access before the FTP connection was authenticated. | %FW-4-HOST_TCP_ALERT_ON | The threshold for half-open TCP connections has been exceeded. | %FW-3-HTTP_JAVA_BLOCK | HTTP inspection has blocked a Java applet. | %FW-6-INIT | Firewall inspection has started. | %FW-3-NOTFOUND | CBAC was unable to find an inspected session in its database. | %FW-6-PRE_ALLOCATED_MEDIA_CHANNEL | Inspection has been set up for a new streaming media connection. | %FW-6-SESS_AUDIT_TRAIL | An inspected connection has just closed. | %FW-6-SESS_AUDIT_TRAIL_START | An inspected connection has just opened. | %FW-4-SKINNY_INSPECTION_DISABLED | Skinny application protocol inspection has been disabled because the router didn't have enough memory to allocate the initial skinny data structures. | %FW-3-SMTP_INVALID_COMMAND | A host has sent an unsupported or unexpected SMTP command. | %FW-3-SMTP_UNSUPPORTED_PARAMETER | A host has sent an unsupported parameter in an SMTP command. | %FW-4-TCP_MAJORDOMO_EXEC_BUG | A host has attempted to exploit a bug in the Majordomo program running on a protected server. | %FW-4-TCP_SENDMAIL_BAD_FROM_SIG | A host has sent an e-mail with the pipe symbol (|) in the From: field. | %FW-4-TCP_SENDMAIL_BAD_TO_SIG | A host has sent an e-mail with the pipe symbol in a recipient field. | %FW-4-TCP_SENDMAIL_DECODE | Someone has sent an e-mail with ":decode@" in the header. | %FW-4-TCP_SENDMAIL_INVALID_COMMAND | An invalid SMTP command was detected. | %FW-4-TCP_SENDMAIL_OLD_SIG | Someone has attempted to exploit the legacy wiz or debug SMTP commands. | %FW-4-UNBLOCK_HOST | A host that was sending too many half-open TCP connection requests is now unblocked. |
Table 12-3 lists the Syslog messages that are related to access list activity on an IOS firewall. These messages are based on Cisco IOS software Release 12.3T. Table 12-3. ACL-Related IOS Firewall Syslog MessagesMessage Prefix | Message Description |
|---|
%SEC-6-IPACCESSLOGDP | ICMP packets have matched the ACL condition. | %SEC-6-IPACCESSLOGNP | IP protocols other than UDP and TCP have matched the ACL condition. | %SEC-6-IPACCESSLOGP | UDP or TCP packets have matched the ACL condition. | %SEC-6-IPACCESSLOGRP | Routing protocol packets have matched the ACL condition. | %SEC-6-IPACCESSLOGS | Packets have matched a standard IP ACL condition (source-only). | %SEC-6-IPACCESSLOGRL | ACL logging has been rate-limited because of its volume. |
Table 12-4 lists the Syslog messages that are related to URL-filtering alerts on an IOS firewall. These messages are based on Cisco IOS software Release 12.3T. Table 12-4. URL-Filtering Alert IOS Firewall Syslog MessagesMessage Prefix | Message Description |
|---|
%URLF-3-ALLOW_MODE | Connections to all the URL filter servers are down, allow mode is enabled. | %URLF-3-MAX_REQ | The number of pending request exceeds the maximum limit. | %URLF-3-RESOURCE_ALLOC_FAILED | The URL filtering process can't allocate enough memory. | %URLF-3-SERVER_DOWN | The URL filter can't be contacted. | %URLF-5-SERVER_UP | The URL filter has returned to service. Allow mode is no longer being used. | %URLF-3-URL_TOO_LONG | A requested URL was longer than the URL filtering server allows. |
Table 12-5 lists the Syslog messages that are related to URL-filtering audit trails on an IOS firewall. These messages are based on Cisco IOS software Release 12.3T. Table 12-5. URL-Filtering Audit Trail IOS Firewall Syslog MessagesMessage Prefix | Message Description |
|---|
%URLF-6-SITE_ALLOWED | The IOS firewall has permitted access to an entire site (and all URLs within it). | %URLF-4-SITE_BLOCKED | The IOS firewall has denied access to an entire site (and all URLs within it). | %URLF-6-URL_ALLOWED | The URL filtering server has allowed a user to access a specific URL. | %URLF-4-URL_BLOCKED | The URL filtering server has denied a request to access a specific URL. |
Table 12-6 lists the Syslog messages that are related to authentication proxy user authentication IOS firewall functions. These messages are based on Cisco IOS software Release 12.3T. Table 12-6. User Authentication IOS Firewall Syslog MessagesMessage Prefix | Message Description |
|---|
%AP-6-AUTH_PROXY_AUDIT_START | An authentication proxy accounting entry has begun. | %AP-6-AUTH_PROXY_AUDIT_STOP | An authentication proxy accounting entry has ended. | %AP-1-AUTH_PROXY_DDOS_ATTACK | The authentication proxy router is possibly undergoing a distributed DoS attack from many hosts. | %AP-1-AUTH_PROXY_DOS_ATTACK | The authentication proxy router is possibly under-going a DoS attack from a single host. | %AP-4-AUTH_PROXY_NOMEM | Insufficient memory was available to perform a task. | %AP-1-AUTH_PROXY_RETRIES_EXCEEDED | A host has exceeded the maximum number of login attempts. | %AP-6-POSTURE_DOWNLOAD_ACL | An authentication, authorization, and accounting (AAA) request to download an ACL has been sent. | %AP-4-POSTURE_EXCEED_MAX_INIT | The maximum number of entries in the posture cache has been exceeded. | %AP-6-POSTURE_POLICY | A policy has been enforced or removed for a host. | %AP-6-POSTURE_START_VALIDATION | A posture cache entry has been created for a host and will be validated. | %AP-6-POSTURE_STATE_CHANGE | The posture cache entry for a host has changed state. |
|
