Cisco ASA and PIX Firewall Logging

This chapter is from the book

Cisco ASA and PIX Firewall Handbook

Learn More Buy

This chapter is from the book

This chapter is from the book 

Cisco ASA and PIX Firewall Handbook

Learn More Buy

Refer to the following sections for information about these topics:

• 9-1: Managing the Firewall Clock—Discusses ways to set and maintain the firewall's internal clock so that events and messages can have accurate time stamps.
• 9-2: Generating Logging Messages—Explains how firewalls generate logging messages and how you can configure them to do that.
• 9-3: Fine-Tuning Logging Message Generation—Covers the configuration steps that can be used to enable or disable specific logging messages or change their severity levels. This section also discusses how to configure access list activity logging.
• 9-4: Analyzing Firewall Logs—Provides an overview of how you can approach collecting and analyzing the logging messages that firewalls produce.

Cisco firewalls and security appliances can be configured to generate an audit trail of messages describing their activities. Firewall logs can be collected and analyzed to determine what types of traffic have been permitted or denied, what users have accessed various resources, and so on.

This chapter presents the tasks that are necessary to begin generating and collecting logging messages.

9-1: Managing the Firewall Clock

A Cisco firewall keeps an internal clock that can be used for Syslog time stamps, certificate time stamps, and so on. The clock is powered by a battery in the absence of regular power.

The internal clock is always based on Coordinated Universal Time (UTC). UTC was previously known as Greenwich Mean Time (GMT).

You can set the system time using two different approaches:

• Manually—You set the time and date on the firewall along with the time zone and specify whether to observe daylight savings time. With manual configuration, the firewall clock is only as accurate as the internal clock hardware.
• Using Network Time Protocol (NTP)—This is a protocol defined by RFC 1305 that provides a mechanism for the devices in the network to get their time from an NTP server. With NTP, all the devices are synchronized to a common, trusted source and keep very accurate time.

NTP uses the concept of stratum to determine how close an NTP server is to an authoritative time source (an atomic or radio clock). Stratum 1 means that an NTP server is directly connected to an authoritative time source. NTP also compares the times reported from all configured NTP peers and does not listen to a peer that has a significantly different time.

NTP associations with other NTP peers can be protected through an encrypted authentication.

Setting the Clock Manually

1. (Optional) Identify the time zone:

   Firewall(config)# clock timezone zone-name hours [minutes]

   zone-name is the time zone (an arbitrary text string such as EST) and is hours (0 to 12 or 0 to –12) and optionally minutes offset from UTC. For example, Eastern Standard Time in the U.S. is 5 hours behind UTC and would be configured as follows:

   Firewall(config)# clock timezone EST -5

2. (Optional) Set daylight savings time (summer time) parameters.
   1. Use the following command if daylight savings time recurs at regular intervals:

      Firewall(config)# clock summer-time zone recurring [week weekday month

       hh:mm week weekday month hh:mm] [offset]

      If daylight savings time begins and ends on a certain day and week of a month, you can use this command. The name of the daylight savings time zone is given as zone (an arbitrary name or abbreviation, such as EDT). The week number week (1 to 4 or the words "first" and "last"), the name of the weekday, the name of the month (only the first three letters matter), and the time hh:mm in 24-hour format can all be given to start and stop daylight savings time. The offset value gives the number of minutes to add during daylight savings time (the default is 60 minutes).

      For example, daylight savings time in the U.S. begins at 2 a.m. on the first Sunday in April and ends at 2 a.m. on the last Sunday in October. You could define it with this command:

      Firewall(config)# clock summer-time EDT recurring first Sunday april
       2:00 last Sunday oct 2:00 60

      TIP

      You can use the recurring keyword with no other arguments for any of the U.S. and Canadian time zones. The correct begin and end dates are used automatically. For the preceding example, you could define daylight savings time as follows:

      Firewall(config)# clock summer-time EDT recurring

   2. If daylight savings time occurs at specific times, you can use the following command to specify the exact date and time that daylight savings time begins and ends in a given year:

      Firewall(config)# clock summer-time zone date {day month | month day}
       year hh:mm {day month | month day} year hh:mm [offset]

      This command is useful if the begin and end times change from year to year. Specify the year number as year (four digits, 1993 to 2035).

   3. Set the firewall clock:

      Firewall(config)# clock set hh:mm:ss {day month | month day} year

      The clock is set when this command is executed. The time is given in 24-hour format, day is the day number (1 to 31), month is the name of the month (only the first three letters are needed), and year is the full four-digit year. The day and month parameters can be reversed, according to what is customary.

   4. Verify the clock:

      Firewall# show clock [detail]

      The current time and date are shown. If you use the detail keyword, the source of the time ("hardware calendar" is the internal battery-operated clock) and any daylight savings time definitions are shown, as in this example:

      Firewall# show clock detail
      13:54:21.793 EST Sat Oct 1 2005
      Time source is hardware calendar
      Summer time starts 02:00:00 EST Sun Apr 4 2005
      Summer time ends 02:00:00 EDT Sun Oct 31 2005
      Firewall#

Setting the Clock with NTP

1. (Optional) Use NTP authentication./p>
   1. Define an authentication key:

      Firewall(config)# ntp authentication-key key-number md5 value

      An MD5 authentication key numbered key-number (1 to 4294967295) is created. The key is given a text-string value of up to eight cleartext characters. After the configuration is written to Flash memory, the key value is displayed in its encrypted form.

      You can repeat this command to define additional keys if needed.

   2. (Optional) Identify a key to expect from all defined NTP servers:

      Firewall(config)# ntp trusted-key key-number

      Remote NTP peers must authenticate themselves with the firewall using the authentication key numbered key-number (1 to 4294967295), as defined in Step 1a. If this command is used, any NTP server must supply this key to the firewall before its time update information is accepted. You can repeat this command to identify additional keys to expect. (Trusted keys can also be defined on a per-server basis in Step 2.)

   3. Enable NTP authentication:

      Firewall(config)# ntp authenticate

2. Specify an NTP server:

   Firewall(config)# ntp server ip-address [key number] [source if-name]
    [prefer]

   The NTP peer (server) is identified at ip-address. If you are using NTP authentication, you can use the key keyword to identify which authentication key to expect from this server. (See Step 1a.) By default, the firewall sends NTP packets on the interface derived from its routing table. You can specify an interface to use with the source keyword and the interface named if-name (outside or inside, for example).

   You can repeat this command to define more than one NTP server. If one server is down or unavailable, a second or third server could be used to synchronize time. You can use the prefer keyword to indicate one NTP server that is preferred if multiple NTP servers are configured.

   TIP

   Actually, a firewall using NTP can use its associations with several servers to derive a more accurate idea of the time. If possible, you should configure a minimum of three different NTP servers so that your firewall can determine if any one of them is inaccurate.

3. Verify NTP operation.
   1. Verify the NTP configuration commands:

      PIX 6.x	Firewall# show ntp
      PIX 7.x	Firewall# show running-config ntp

      This command displays the commands but not any information about NTP operation, as in this example:

      Firewall# show running-config ntp
      ntp authentication-key 1 md5 *
      ntp authentication-key 2 md5 *
      ntp authenticate
      ntp server 192.168.254.4 key 1 source inside prefer
      ntp server 192.168.254.3 key 2 source inside
      Firewall#

      Notice that the MD5 hash keys are automatically hidden from being displayed in the configuration. Instead, only an asterisk is shown.

   2. Verify the current NTP status:

      Firewall# show ntp status

      NTP should be in the synchronized state if the firewall has successfully authenticated and exchanged information with at least one NTP server. This command shows this in the first line of output, as shown in the following example. Notice that the firewall has become a stratum 4 time source itself, deriving its time information from a higher (lower-stratum) authority:

      Firewall# show ntp status
      Clock is synchronized, stratum 4, reference is 192.168.254.4
      nominal freq is 99.9984 Hz, actual freq is 99.9984 Hz, precision is 2**6
      reference time is c34d3659.655d8a23 (14:28:25.395 EST Fri Oct 31 2003)
      clock offset is 10.8642 msec, root delay is 87.74 msec
      root dispersion is 15927.54 msec, peer dispersion is 15875.02 msec
      Firewall#

      If the clock is unsynchronized, the firewall has not yet authenticated or synchronized its time clock with an NTP server. Keep checking the status every minute or so to see if the clock becomes synchronized. If it doesn't, confirm your NTP configuration and authentication keys.

   3. View all NTP server associations:

      Firewall# show ntp associations [detail]

      The firewall clock becomes synchronized with only one NTP server. However, it keeps an association with each NTP server that is configured. NTP continuously compares clock information from all known servers so that it can maintain the most accurate time. In the following example, the firewall has associations with two NTP servers:

      Firewall# show ntp associations
         address     ref clock   st when poll reach delay offset
        disp
      *~192.168.254.4  198.82.162.213  3  21  64  3  14.8  10.86
        7889.6
      +~192.168.254.3  198.82.162.213  3  10  64  3   2.5  0.31
        7881.1
       * master (synced), # master (unsynced), + selected, - candidate,
       ~ configured
      Firewall#

      Notice that the two NTP servers are shown (each is stratum 3 in the st column), along with the reference clock that each uses. Here, 192.168.254.4 has become the preferred, or "master," source of synchronization, designated by the * flag. The 192.168.254.3 server is marked with +, indicating that it is selected for possible synchronization.

      If you find that some of the server addresses are not selected or synchronized, you can get more information about the failed associations by adding the detail keyword.

      TIP

      If you are having trouble getting a firewall to synchronize its clock, you can use the debug ntp authentication EXEC command (if the NTP server requires authentication) or the debug ntp {events | select | sync} command to watch the exchange of NTP information. The debug output is shown only in the "debug trace" channel, which is usually the first Telnet or SSH session active on the firewall. If there are no Telnet or SSH sessions, the output is sent to the console.