Section 13.1 Timing Is Everything | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

13.1 Timing Is Everything

To assist in tracing intrusions, it is important for your system's clock to be accurate to match up time-stamps in logs and e-mail on your system with events on intruding systems and intervening systems. Note that the intruding system most likely is an innocent system that has already been compromised by the intruder. What you will be trying to show is that an entry in your system's logs indicates that a particular system improperly accessed yours. You want to find an entry on that other system with an almost identical time-stamp that indicates the same thing. At the time of discovery, if each system's SysAdmin can determine the amount of time his system's clock is off by, they can compute the actual time of each event and match them up accurately. If either system's clock is wrong by an unknown amount, it becomes an issue of who to believe and that can destroy the "beyond a reasonable doubt" requirement for legal action in many countries.

This is because the defense attorney will claim that the source address was spoofed. Even if the prosecution explains the difficulty of spoofing TCP addresses and so on, the case becomes difficult to prove. In other words, an accurate time-stamp can help to create a chain of evidence from when the cracker dialed in several systems away to events on your system. The netdate command may be used to synchronize your system clock to some net time standards using port 37. (There are other programs and time ports too.) The listed URLs use local atomic clocks or other means for extreme accuracy, though network delays diminish results. The -l 30 specifies that a deviation of up to 30 seconds between the best two servers will be allowed.

The tcp argument specifies that the following servers should be contacted via TCP; this avoids possible cracker spoofing that UDP is vulnerable to. Specifying multiple hosts makes it even harder to spoof the time, as well as increasing the accuracy of received time. The spoofing would be accomplished by sniffing your LAN for the request and simply sending a spoofed UDP reply. The offset in times listed after each host is the number of seconds that that host is ahead of "+" or behind "-" your host. The most reliable time servers should be listed first. Then clock is invoked to update the CMOS clock; the -u flag is used if the CMOS clock is kept on Greenwich Mean Time (also known as GMT, Coordinated Universal Time, UTC, or Zulu time). Keeping the CMOS clock on GMT avoids errors when the system is booted after the switch between Summer (Daylight Saving) and Winter (Standard) time.

 netdate -l 30 tcp radar.gatech.edu bitsy.mit.edu \   tick.usno.navy.mil tock.usno.navy.mil /sbin/clock -u -w

Typical results follow. The final line is the time standard selected.

 radar.gatech.edu +0.537  Sun Oct 01 01:20:27.000 bitsy.mit.edu -0.172     Sun Oct 01 01:20:27.000 netdate: connect: Connection refused Connection with tcp to tick.usno.navy.mil failed. tock.usno.navy.mil +0.577 Sun Oct 01 01:20:29.000 radar.gatech.edu -0.032  Sun Oct 01 01:20:29.000

In this example, tick is not ticking. Although tick was operating when this example was generated, USNO's tycho.usno.navy.mil was not, and so provided the error text. It has been my experience that tycho is frequently down and tick and tock occasionally. Although this is a benign failure when connecting with TCP, the results with UDP can be a serious problem. The UDP failure mode is that most of these sites will return a time of 0, in direct violation of RFC 826, which defines what should be returned on error.

I modified netdate to verify that this is the raw data received by read(). This modified version of netdate, which detects this bug and rejects the bogus data, is available from the CD-ROM. This problem has been observed on all of these sites except Georgia Tech's.

An alternative defense, but less successful, is to list at least two servers, of which one may be localhost. Unless at least two of these agree to within the number of seconds specified by -l (or within 5 seconds otherwise), the system's time is not altered. If you list both tick and tock and they are both broken, you still will get the wrong time unless you use the modified netdate. (If you list only one time server and localhost, the problem will be avoided.) When a break-in attempt is discovered, it is helpful to do the netdate invocation as an ordinary user to compute your system's current offset from exact time (without altering it) so that you can apply a correction to the time-stamps in your log files. Thus, you can state that all of your log files have the same offset from exact time rather than introducing, "I think that I updated the clock here." You might want to suggest that the other system's SysAdmin do the same thing and mail the output to you for your records.

I put a netdate invocation in the /etc/ppp/ip-up file. Those with continuous connections could put an entry in the root crontab to update weekly. It will be useful to periodically compute the rate of your clock's drift so that even this error can be applied to future log file entries. Besides the increased accuracy, this will show a high level of care that will impress the legal types.

The rdate program is found on many distributions and uses the same protocol. Its -p flag will cause the remote time to be displayed; the -s flag will set your system's clock to the remote time. An alternative is to get the official time by phone at +1 303-499-7111. Some people prefer NTP but it uses only UDP, which is too insecure. The timed set of programs will allow the systems on a LAN to synchronize clocks but it uses the UDP protocol too.

On a trusted network with the firewall blocking this port, this might be sufficient for most people. You do not want to offer a time service to the Internet if you use any authentication schemes that depend on interlopers not knowing a system's exact time. Even if you do not run time-sensitive authentication schemes, you run a risk of a DoS attack from someone simply asking your system what the time is continuously. (For the same reason, the echo, chargen, and similar services should be disabled for those with this high level of concern.) Alternatively, for systems in the U.S. and Canada, you can purchase special radios that receive the WWV or WWVH time broadcasts and write a program that will read the data via a serial port. GPS satellites provide precise time throughout the world.

Top