Having a correct time set on a Cisco ASA is important for a number of reasons. Possibly the most important reason is that digital certificates compare this time to the range defined by their Valid From and Valid To fields to define a specific validity period. Having a correct time set is also important when logging information with the timestamp option. Whether you are sending messages to a syslog server, sending messages to an SNMP monitoring station, or performing packet captures, time stamps have little usefulness if you cannot be certain of their accuracy.
The default ASA time is set to UTC (Coordinated Universal Time), but you can add local time zone information so that the time displayed by the ASA is more relevant to those who are viewing it. Even if you set local time zone information, the ASA internally tracks time as UTC, so if it is interacting with hosts in other time zones (which is fairly common when using digital certificates for VPN connectivity, for example), they have a common frame of reference.
To set the time locally on the ASA (that is, not using Network Time Protocol [NTP]), first navigate to Configuration > Device Setup > System Time > Clock to display the Clock settings window, shown in Figure 6-1. If you want to set the clock to UTC time, simply enter a new date and time, as UTC is the default time zone. If you prefer to set the clock using your local time zone, choose that time zone from the drop-down list before you enter a new date and time (Figure 6-1 shows the North American Central Time Zone being selected).
Figure 6-1 Setting Local Time Parameters
You can then set the date and time accordingly. Time is set as hours, minutes, and seconds, in 24-hour format. Optionally, you can click the Update Displayed Time button to update the time shown in the bottom-right corner of the Cisco ASDM status bar. The current time updates automatically every ten seconds. Click Apply to complete the setting of the internal clock.
The configured time is retained in memory when the power is off, by a battery on the security appliance motherboard.
Of course, to ensure precise synchronization of the ASA's clock to the rest of your network, you should configure the ASA to obtain time information from a trusted NTP server. To do so, navigate to Configuration > Device Setup > System Time > NTP. The NTP settings window opens. To define a new NTP time source, click Add to open the Add NTP Server Configuration dialog box, shown in Figure 6-2. Define the IP address of the new NTP time source, the ASA interface through which this NTP server can be reached, and any information relevant to the use of authenticated NTP communication.
Figure 6-2 Configuring an NTP Server
Figure 6-2 shows the configuration of an internal NTP server, 10.0.0.5, which is preferred to other NTP sources and uses NTP authentication for added security. To use NTP authentication, both the server and any clients must be configured with the same trusted key number and key (effectively, a password). The key number must be included in NTP packets from the server in order for the ASA to accept synchronization to that server. The key is used to create a keyed hash for verification that NTP advertisements are from an authorized source, and have not been tampered with. You must check the Trusted check box for the configured key ID for authentication to work. You must also check the Enable NTP Authentication box at the bottom of the NTP server window (shown in the background in Figure 6-2).
You can configure additional NTP servers (a minimum of three associations is recommended for optimal accuracy and redundancy). Figure 6-3 shows the result of configuring TIME.NIST.GOV as an additional NTP server (it is not set as preferred, and does not use authentication). Note that, although the name command was used in Chapter 5 to map TIME.NIST.GOV to the IP address 18.104.22.168, if you tried to configure TIME.NIST.GOV in the server field, it will result in an Invalid IP Address error. You can enter IP addresses only when defining NTP servers.
Figure 6-3 Configuring Multiple NTP Servers
Using an NTP server reachable through the outside interface, and not using authentication, is inherently subject to potential compromise, so it should be done only as a backup to an internal NTP server, if available. Note also that, because NTP Authentication is enabled on this ASA, time would not currently be accepted from the TIME.NIST.GOV server, because it is not configured for authenticated NTP messaging. Thus, the addition of this server is for example purposes only.
Time derived from an NTP server overrides any time set manually in the Clock pane. However, in the unlikely event of an extended period of unavailability of any configured NTP servers, the local clock can serve as a fallback mechanism for maintaining time on the security appliance. Setting a server as preferred does not guarantee that the ASA will accept the time advertised by such a server. The security appliance will choose the NTP server with the lowest stratum number and synchronize to that server. (A stratum number indicates the distance from the reference clock, so a lower stratum number implies that a server is more reliable than others with a higher stratum number. The atomic clock at NIST, for instance, is considered stratum 0.) If several servers have similar accuracy, the preferred server is used. If another server is significantly more accurate than the preferred server, however, the ASA uses the more accurate one.
The CLI commands generated by the changes made are as follows:
clock set 21:24:37 NOV 1 2010 clock timezone CST -6 0 clock summer-time CDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00 60 ntp server 10.0.0.5 key 1 source inside prefer ntp server 22.214.171.124 source outside ntp authenticate ntp authentication-key 1 md5 UEB34mid@#9C ntp trusted-key 1
If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode (the clock set command can actually be entered from privileged mode as well).
Note that if you set the time zone using ASDM, the use of Daylight Saving Time (DST) is automatically enabled, if appropriate, with the correct date and time parameters for the selected time zone. To alter the start and end dates of DST, should they be incorrect, you would need to make the change from the CLI.
The clock set command is used to manually set the security appliance date and time information. It can be used from the CLI in privileged EXEC mode (use of configuration mode is not necessary). When setting from the CLI, the date can be specified as MONTH DAY YEAR or DAY MONTH YEAR, whichever you prefer.
The clock timezone command defines a name for your local time zone (in Standard Time) as well as its offset from UTC in hours (the -6 in the example), and in minutes (the 0 in the example) if you live in a time zone with an offset that is not in whole hours.
The clock summer-time command defines a name for your local time zone (in DST), and uses the keyword recurring to set a recurring range, defined as a day and time of a given month, rather than a specific date, so that you do not need to alter the setting yearly. Use it to set the beginning and ending days and times for DST in your time zone (in the example, DST begins on the second Sunday in March at 2 a.m., and ends on the first Sunday of November at 2 a.m.) and the DST offset from Standard Time (in the example, 60 minutes).
The ntp server command defines a server to be used as a time source by the security appliance. This command sets the server IP address, authentication key number (if used), source interface, and whether or not it is a preferred server.
To enable authentication with an NTP server, you must use the ntp authenticate command from global configuration mode. The ntp authentication-key command ties the key number to the specific key used to create an MD5 keyed hash for source validation and integrity check. For NTP authentication to succeed, any key ID to be accepted by the security appliance must be defined as trusted. This is done using the ntp trusted-key command.
Verifying System Time Settings
Security appliance time can be verified using two commands, show clock and show ntp associations. Both have an optional keyword of detail. Example 6-1 shows the use of both the standard and detailed version of the show clock command.
Example 6-1. Verifying System Time with show clock
FIREWALL# show clock 10:09:16.309 CDT Tue Nov 2 2010 FIREWALL# show clock detail 10:03:55.129 CDT Tue Nov 2 2010 Time source is
NTPSummer time starts 02:00:00 CST Sun Mar 14 2010 Summer time ends 02:00:00 CDT Sun Nov 7 2010
As shown in the example, using the detail keyword with the show clock command adds information on the time source, and the local time zone DST information. Note the source of NTP in this example.
Example 6-2 shows the use of the show ntp associations command, which displays the configured NTP server and whether the security appliance is successfully synced.
Example 6-2. Verifying System Time with show ntp associations
FIREWALL# show ntp associations address ref clock st when poll reach delay offset disp *~10.0.0.5 127.0.0.1 3 87 1024 377 2.5 -0.23 1.8 -~126.96.36.199 .ACTS. 1 147 1024 377 41.5 -1.08 16.5 * master (synced), # master (unsynced), + selected, - candidate, ~ configured