11.3. NTP
One problem with logging events
over a network is that differences in system clocks can make
correlating events on different systems very difficult. It is not
unusual for the clock on a system to have drifted considerably. Thus,
there may be discrepancies among timestamps for the same events
listed in different log files. Fortunately, there is a protocol you
can use to synchronize the clocks on your system.
Network
Time Protocol (NTP) provides a mechanism so that one system can
compare and adjust its clock to match another system's clock.
Ideally, you should have access to a very accurate clock as your
starting point. In practice, you will have three choices. The best
choice is an authoritative reference clock. These devices range from
atomic clocks to time servers that set their clocks based on time
signals from radios or GPS satellites.
The next best source is from a
system that gets its clock setting from one of these reference
clocks. Such systems are referred to as stratum 1 servers. If you
can't get your signal from a stratum 1 server, the next best
choice is to get it from a system that does, a stratum 2 server. As
you might guess, there is a whole hierarchy of servers with the
stratum number incrementing with each step you take away from a
reference clock. There are public time servers available on the
Internet with fairly low stratum numbers that you can coordinate to
occasionally, but courtesy dictates that you ask before using these
systems.
Finally, if you are not attached to the Internet, you can elect to
simply designate one of your systems as the master system and
coordinate all your other systems to that system. Your clocks
won't be very accurate, but they will be fairly consistent, and
you will be able to compare system logs.
NTP works in one of several ways. You can
set up a server to broadcast time messages periodically. Clients then
listen for these broadcasts and adjust their clocks accordingly.
Alternately, the server can be queried by the client. NTP uses UDP,
typically port 123. Over the years, NTP has gone through several
versions. Version 4 is the current one, but Version 3 is probably
more commonly used at this point. There is also a lightweight time
protocol, Simple Network Time Protocol (SNTP), used by clients that
need less accuracy. SNTP is interoperable with NTP.
For Unix systems, the most common
implementation is
ntpd, formerly
xntpd, which is described here. This is actually
a collection of related programs including the daemon
ntpd and support programs such as
ntpq,
ntpdate, and
ntptrace. You'll want to start
ntpd automatically each time you boot your
system.
ntpd uses a configuration file,
/etc/ntp.conf, to control its operation. This
configuration file can get quite complicated depending on what you
want to do, but a basic configuration file is fairly simple. Here is
a simple three-line example:
server 205.153.60.20
logconfig =syncevents +peerevents +sysevents +allclock
driftfile /etc/ntp.drift
The
first line identifies the server. This is the minimum you'll
need. The second establishes which events will be logged. The last
line identifies a drift file. This is used by
ntpd to store information about how the clock on
the system drifts. If
ntpd is stopped and
restarted, it can use the old drift information to help keep the
clock aligned rather than waiting to calculate new drift information.
One
minor warning about
ntpd is in order. If your
clock is too far off,
ntpd will not reset it.
(Among other things, this prevents failures from propagating
throughout a network.) This is rarely a problem with computers, but
it is not unusual to have a networking device whose clock has never
been set. Just remember that you may need to manually set your clock
to something reasonable before you run
ntpd.
ntpdate can be used to do a onetime clock set:
bsd2# ntpdate 205.153.60.20
4 Jan 10:07:36 ntpdate[13360]: step time server 205.153.60.20 offset 11.567081
sec
ntpdate cannot be used if
ntpd is running, but there shouldn't be
any need for it if that is the case.
ntpq can be used to query servers about their
state:
bsd2# ntpq -p 172.16.2.1
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp.lander.edu .GPS. 1 u 18 64 173 5.000 -1.049 375.210
CHU_AUDIO(1) CHU_AUDIO(1) 7 - 34 64 177 0.000 0.000 125.020
172.16.3.3 0.0.0.0 16 - - 64 0 0.000 0.000 16000.0
172.16.2.2 0.0.0.0 16 u - 64 0 0.000 0.000 16000.0
In this example, we have queried a system for a list of its peers.
ntptrace can be used to discover the chain of
NTP servers, i.e., who gets their signal from whom:
bsd2# ntptrace 172.16.2.1
NLCisco.netlab.lander.edu: stratum 2, offset 0.009192, synch distance 0.00526
ntp.lander.edu: stratum 1, offset 0.007339, synch distance 0.00000, refid 'GPS '
Only two servers were involved in this example, but you should get
the basic idea.
Each of these tools has other features that are documented in their
manpages. NTP can be an involved protocol if used to its fullest.
Fortunately, a lot of documentation is available. Whatever you
want -- information, software, a list of public NTP
servers -- the best place to start is at
http://www.eecis.udel.edu/~ntp. The work of
Dave Mills and others, this is a remarkable site.
 |  |  |
| 11.2. Log Files and Auditing |  | 11.4. Security Tools |
