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. TIP NTP version 3 is based on RFC 1305 and uses UDP port 123. Information about public NTP servers and other NTP subjects can be found at http://www.ntp.org. You can also use a commercial product as your own stratum 1 time source. For example, Symmetricom (http://www.ntp-systems.com/products.asp) offers several NTP time servers that are based on Global Positioning Satellite (GPS) signals.
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.
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
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 TIP In PIX 7.x multiple-context mode, NTP must be configured on the system execution space only. All the other contexts (both admin and user) obtain their clock information from the system execution space, because all the contexts exist in the same physical firewall. You can use the changeto system command to move your session into the system execution space before using the following configuration steps. The Firewall Services Module (FWSM) doesn't have a standalone clock, and it doesn't support NTP. Because it is a module inside a Catalyst 6500 chassis, it relies on the switch clock instead. Therefore, you should make sure the switch has been configured for NTP as an accurate clock source.
1. | (Optional) Use NTP authentication.
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. (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.) 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.
Verify the NTP configuration commands:1 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. 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. 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. |
|
