1. ITIS 3110 IT Infrastructure II
Tony Kombol

2. NTP

3. "Does Anybody Realy Know What Time It Is?"*
Time keeping is one of most fundamental aspects of computer infrastructure
Many protocols rely on accurate clocks
Correlating information from multiple systems impossible with out a shared clock
*Does Anybody Realy Care (CTA aka Chicago, 1969)

4. Time Sources

5. Side note: Difference between precision and accuracy
Closeness to the actual value
E.g. the clock is 1 hour off
Precision
How much it does not vary
E.g. the clock varies by less than a nanosecond in a year
So which is better?
A clock might not vary by more than a nanosecond, but be off by one hour
A clock might be off by one second, but vary by a millisecond over the day

6. Network Time Protocol (NTP)
Port 123/udp
Can maintain time in fractions of a second
Can use external time source
e.g. Atomic clock or GPS clock
Most computers and devices act as a client

7. Network Time Protocol (NTP)
All servers belong to a ‘Stratum’
Denotes how far from a time source they are
Prevents Loops
Can only sync with servers in same stratum or higher
Stratum 0: time source
Stratum 1: server directly attached to time source
Etc…
Versions available for:
UNIX family
Windows family
SNTP for 2000 and XP
Full NTP for Server 2003 and Vista

8. Security concerns
Only a few security problems have been identified in the reference implementation of the NTP codebase in its 25+ year history
The protocol has been undergoing revision and review over its entire history
As of January 2011, there are no security revisions in the NTP specification and no reports at CERT
The current codebase for the reference implementation has been undergoing security audits from several sources for several years now
There are no known high-risk vulnerabilities in the current released software

9. NTP: Security Considerations
Default configuration is usually client-only
Supports authentication if working in a paranoid environment

10. NTP Stratum Yellow arrows are direct connections
Red arrows are network connections

11. Clock strata
NTP uses a hierarchical, semi-layered system of levels of clock sources
Each level of this hierarchy is termed a stratum
Assigned a layer number starting with 0 (zero) at the top
The stratum level defines its distance from the reference clock and exists to prevent cyclical dependencies in the hierarchy
Note 1: the stratum level is not a guarantee of quality or reliability
It is common to find stratum 3 time sources that are higher quality than other stratum 2 time sources
Note2: This definition of stratum is also different from the notion of clock strata used in telecommunication systems

12. Clock strata Stratum 0 Stratum 1 Devices such as
Atomic clocks (cesium, rubidium)
GPS clocks
Radio clocks (e.g. WWV)
Stratum-0 devices are traditionally not attached to the network
Instead they are locally connected to computers
e.g., via an RS-232 connection using a pulse per second signal
Stratum 1
These are computers attached to Stratum 0 devices.
Normally they act as servers for timing requests from Stratum 2 servers via NTP
These computers are also referred to as time servers
They are typically attached to the network

13. Clock strata
Stratum 2
Computers that send NTP requests to Stratum 1 servers
Normally a Stratum 2 computer will reference a number of Stratum 1 servers and use the NTP algorithm to gather the best data sample
Dropping any Stratum 1 servers that seem obviously wrong
Stratum 2 computers will peer with other Stratum 2 computers to provide more stable and robust time for all devices in the peer group
Stratum 2 computers normally act as servers for Stratum 3 NTP requests
Stratum 3
These computers employ exactly the same algorithms for peering and data sampling as Stratum 2
Can themselves act as servers for stratum 4 computers, and so on…

14. Clock strata NTP supports up to 256 strata
Only the first 16 are employed
Any device at Stratum 16 is considered to be unsynchronized
Some systems may reject a time update from a "too highly numbered" stratum
Note: Depends on what version of NTP protocol in use

15. SNTP - Simple Network Time Protocol
A less complex implementation of NTP
Uses the same protocol
Does not require the storage of state over extended periods of time
Used in some embedded devices and in applications where high accuracy timing is not required
See RFC 1361, RFC 1769, RFC 2030, RFC 4330 and RFC 5905

16. NTP timestamps 64-bit timestamps used by NTP consist of Gives NTP:
32-bit part for seconds
32-bit part for fractional second
Gives NTP:
Time scale that rolls over every 232 seconds
~136 years
Theoretical resolution of 2−32 seconds
~233 picoseconds
NTP uses an epoch of January 1, 1900
First rollover occurs in 2036
Before the UNIX year 2038 problem

17. NTP timestamps
Implementations should disambiguate NTP time using a knowledge of the approximate time from other sources
NTP only works with the differences between timestamps and never their absolute values
Wraparound is invisible as long as the timestamps are within 68 years of each other
This means that the rollover will be invisible for most running systems, since they will have the correct time to within a very small tolerance
However, systems that are starting up need to know the date within no more than 68 years
Given the large allowed error, it is not expected that this is too onerous a requirement
One suggested method is to set the clock to no earlier than the system build date
Many systems use a battery powered hardware clock to avoid this problem

18. NTP timestamps
Even so, future versions of NTP may extend the time representation to 128 bits:
64 bits for the second and 64 bits for the fractional- second
The current NTP4 format has support for Era Number and Era Offset, that when used properly should aid fixing date rollover issues
According to Mills:
"The 64 bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64 bit second value is enough to provide unambiguous time representation until the universe goes dim."

19. Stratum 0 clocks are usually directly connected to the network
True
False

20. Logging

21. Logging
Best practice is to centralize all logs to a dedicated log host
Good for debugging, forensics, etc.
Centralized logging needs a shared clock for best results

22. Clock synchronization algorithm
To synchronize its clock with a remote server, the NTP client must compute the round-trip delay time and the offset
Round-trip delay is d = (t3-t0) – (t2-t1)
Where:
t0 is the time of the request packet transmission
t1 is the time of the request packet reception
t2 is the time of the response packet transmission
t3 is the time of the response packet reception
(t3-t0) is the time elapsed on the client side between the emission of the request packet and the reception of the response packet
while t2-t1 is the time the server waited before sending the answer.
Offset is given by o = ((t1-t0) + (t2-t3)) /2

23. Clock synchronization algorithm
The NTP synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay
If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times

24. Syslog
Port 514/UDP
Modern implementations support TCP as well
Most computers and devices can generate syslog messages
UDP is used because it is stateless

25. Syslog Facilities Every syslog message is associated with a facility
The facility is the general source of the message
Example facilities are
AUTH
CRON
DAEMON
FTP
MAIL
Allows different facilities to be handled differently

26. Facility Levels 0-11 Facility Number Keyword Facility Description kern
kern
kernel messages 1
user
user-level messages 2
mail
mail system 3
daemon
system daemons 4
auth
security/authorization messages 5
syslog
messages generated internally by syslogd 6
lpr
line printer subsystem 7
news
network news subsystem 8
uucp
UUCP subsystem 9
clock daemon 10
authpriv 11
ftp
FTP daemon

27. Facility Levels (12-23) Facility Number Keyword Facility Description
NTP subsystem 13
log audit 14
log alert 15
cron
clock daemon 16
local0
local use 0 (local0) 17
local1
local use 1 (local1) 18
local2
local use 2 (local2) 19
local3
local use 3 (local3) 20
local4
local use 4 (local4) 21
local5
local use 5 (local5) 22
local6
local use 6 (local6) 23
local7
local use 7 (local7)

28. Syslog Priorities Every syslog message has a set priority
Declares how important the message is
Examples are:
debug
notice
warning
error

29. Severity Levels
Code
Severity
Keyword
Description
General Description
Emergency
emerg (panic)
System is unusable.
A "panic" condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call. 1
Alert
alert
Action must be taken immediately.
Should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a primary ISP connection. 2
Critical
crit
Critical conditions.
Should be corrected immediately, but indicates failure in a primary system, an example is a loss of a backup ISP connection. 3
Error
err (error)
Error conditions.
Non-urgent failures, these should be relayed to developers or admins; each item must be resolved within a given time. 4
Warning
warning (warn)
Warning conditions.
Warning messages, not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given time. 5
Notice
notice
Normal but significant condition.
Events that are unusual but not error conditions - might be summarized in an to developers or admins to spot potential problems - no immediate action required. 6
Informational
info
Informational messages.
Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required. 7
Debug
debug
Debug-level messages.
Info useful to developers for debugging the application, not useful during operations.
A common mnemonic used to remember the syslog levels down to top is:
"Do I Notice When Evenings Come Around Early".

30. Syslog Configuration
Messages can be routed based on facility and priority
What subsystem and its importance
Destination can be:
Local log file
Remote syslog server
Log files can be written synchronously or asynchronously
Synchronous – slower but guaranteed write
Asynchronous – faster, but may lose some logs if the system crashes

31. Example Syslog Configuration
# Log all kernel messages to the console. # Logging much else clutters up the screen. kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # Send all logs to log.example.com

32. Notes about the configuration*
The asterisk is a ‘glob’ character.
It means to match anything
You will see it in many configuration files as well as on the command line
/dev/console
UNIX has a philosophy that everything is a file
/dev/console is a device file
It writes messages to all locally attached terminals

33. Syslog: Security Considerations
No authentication
No encryption
UDP source can be spoofed
Malicious user could run log server out of disk space
Same for a mis-configured system

34. Syslog: Security Mitigations
Limit access to Syslog using firewall
Run on internal network if possible
Log to a separate partition
Monitor disk usage on log server
Use more feature-rich syslog implementations that support TCP and/or encryption

35. Why do NTP and Syslog need to work together:
Both share the same base protocol
All systems need a common timebase for log timestamps
TCP requires synchronized packet transfers
It keeps the NSA synchronized