Home > NTP configuration

Archive for the ‘NTP configuration’ Category

Importance of Preventing NTP Time Server Abuse

Wednesday, November 26th, 2008

NTP time server (Network Time Protocol) abuse is quite often unintentional and fortunately thanks to the NTP pool is less frequent than it was although incidents still happen.

NTP server abuse is any act that violates the access rules of a NTP time server or an act that damages it in any way. Public NTP servers are those servers that can be accessed from across the Internet by devices and routers to use as a timing source to synchronise a network to. Most public NTP time servers are non-profit and set up as acts of generosity, mostly by University’s or other technical centres.

For this reason access rules have to be set up as huge amounts of traffic can generate giant bandwidth bills and can lead to the NTP time server being turned off permanently. Access rules are used to prevent too much traffic from accessing stratum 1 servers, by convention stratum 1 servers should only be accessed by stratum 2 servers which in turn can pass the timing information on down the line.

However, the worst cases of NTP server abuse have been where thousands of devices have sent requests for time, where in the hierarchical nature of NTP only one is needed.

Whilst most acts of NTP abuse are intentional some of the worst abuses of NTP time servers have been committed (albeit unintentionally) by large companies. The first large firm discovered to have been guilty of NTP abuse was Netgear, who, in 2003 released four routers that were all hard coded to use the University of Wisconsin’s NTP server, the resulting DDS (Distributed Denial of Service) reached nearly 150 megabits a second.

Even now, five years on and despite the release of several patches to fix the problem and the University being compensated by Netgear the problem still continues as some people have never patched their routers.

Similar incidents have been committed by SMC and D-Link. D-Link in particular caused controversy as when the matter was drawn to their attention they decided to bring the lawyers in. Only after it was discovered that they violated nearly 50 NTP servers did they attempt resolve the problem (and only after scathing press coverage did they relent).

The easiest way to avoid such problems is to use a dedicated external stratum 1 time server. These devices are relatively inexpensive, simple to install and far more accurate and secure than online NTP servers. These devices receive the time from atomic clocks either from the GPS network (Global Positioning System) .

The MSF Time Signal

Saturday, November 22nd, 2008

The MSF time signal is a dedicated radio broadcast providing an accurate and reliable source of UK civil time, based on the global time scale UTC (Coordinated Universal Time), the MSF signal is broadcast and maintained by the UK’s National Physical Laboratory (NPL).

The MSF time signal can be utilised by anyone requiring accurate timing information its main use however is as a source of UTC time for administrators synchronising a computer network with a radio clock. Radio clocks are really another term for a network time server that utilises a radio transmission as a timing source.

Most radio based network time servers use NTP (Network Time Protocol) to distribute the timing information throughout the network.

The MSF signal is broadcast from Anthorn Radio station in Cumbria by VT communications under contract to the NPL.  It is available 24 hours a day across the whole of the UK and beyond, although the signal is vulnerable to interference and local topography. Users of the MSF service receive predominantly a ‘ground wave’ signal. However, there is also a residual ‘sky wave’ which is reflected off the ionosphere and is much stronger at night; this can result in a total received signal that is either stronger or weaker.

The MSF signal is carried on a frequency of 60 kHz (to within 2 parts in 1012) and is controlled by a Caesium atomic clock based at the radio station.

The antenna at Anthorn is at 54° 55′ N latitude, and 3° 15′ W longitude. The signal’s field strength exceeds 100 µV/m(micro volts a metre) at a distance of 1000 km from Anthorn, covering the whole of the UK, and can even be received throughout some of northern and western Europe.

The MSF transmits a simple binary code containing time and date information The MSF time and date code includes the following information: year, month, day of month,  day of week,  hour, minute, British Summer Time (in effect or imminent),  DUT1 (a parameter giving UT1-UTC)

Five Reasons Why You Should Never Use an Internet Timing Source

Thursday, November 20th, 2008

Time synchronisation is now an integral part of network administration. Networks that are not synchronised to UTC time (Coordinated Universal Time) become isolated; unable to process time sensitive transactions or communicate securely with other networks.

UTC time has been developed to allow the entire globe to communicate under a single time-frame and it is based on the time told by atomic clocks.

To synchronise to UTC time many network administrators simply connect to an Internet timing source and assume they are receiving a secure source of UTC time. However, there are pitfalls to this and any network that requires security should NEVER use the Internet as a timing source:

1.    To use an internet timing source a port needs to be forwarded in the firewall. This ‘hole’ to allow the timing information to pass through can be utilised by anybody else too.
2.    NTP (Network Time Protocol) has an inbuilt security measure called authentication that ensures a timing source is exactly who it says it is, this can’t be utilised over the Internet.
3.    Internet timing sources are wholly inaccurate. A survey by Nelson Minar of MIT (Massachusetts  Institute of Technology) discovered less than half were close enough to UTC time to be described as reliable (some where minutes and even hours out!).
4.    Distance across the Internet can render even an extremely accurate Internet timing source useless as the distance to client could cause delay.
5.    A dedicated time server will use a radio of GPS timing signal which can be audited to guarantee its accuracy, providing security and legal protection; internet timing sources cannot.

Dedicated NTP time servers not only offer greater protection and security than Internet time sources. They also offer unbridled accuracy with both the GPS and time and frequency radio transmissions (such as MSF, DCF or WWVB) accurate to within a few milliseconds of UTC time.

NTP GPS Server Synchronisation Solution

Tuesday, November 18th, 2008

Time synchronisation is now a critical aspect of network management enabling time sensitive applications to be conducted from across the globe. Without correct synchronisation computer systems would be unable to communicate with each other and transactions such as seat reservation, Internet auctions and online banking would be impossible.

For effective time synchronisation the global timescale UTC (Coordinated Universal Time) is a prerequisite. While a computer network can be synchronised to any single time source, UTC is employed by computer networks all over the world. By synchronising to a UTC time source a computer network can therefore be synchronised to every other computer network across the globe that also use UTC as their time source.

Receiving a reliable UTC time source is not as easy as it sounds. Many network administrators opt to use a UTC Internet time source. Whilst many of these time sources are accurate enough, they can be too far away to provide reliability and there are plenty of Internet time sources that are vastly inaccurate.

Another reason why Internet time sources should not be used as a source of time synchronisation is because an Internet time source is outside of a firewall and leaving a gap in the firewall to receive timing information can leave a system open to abuse.

So that UTC time can be opted as a civil time throughout the world several national physics laboratories broadcast a UTC timing signal that can be received and utilised as a network time source. Unfortunately, however, these time signals are not available in every country and even in those areas where a signal exists; they can be quite often obstructed by interference and local topography.

Another method for receiving a source of UTC time is to use the GPS satellite network. Strictly speaking the Global Positioning System (GPS ) does not relay UTC but it is a time based on International Atomic Time (TAI) with a predefined offset. A GPS NTP clock can simply convert the GPS time into UTC for synchronisation purposes.

The main advantage of using GPS is that a GPS signal is available anywhere on the planet providing that there is a clear view of the sky above (GPS transmissions are broadcast via line-of-sight) so UTC synchronisation can be conducted anywhere.

Common NTP Server Time Reference Problems

Friday, November 14th, 2008

The NTP server (Network Time Protocol) is one of the most used but least understood computer networking hardware items.

A NTP Server is just a time server that uses the protocol NTP. Other time protocols do exist but NTP is by far the most widely used. The terms ‘NTP server’, ‘time server’ and ‘network time server’ are interchangeable and often the terms ‘radio clock’ or ‘GPS time server’ are used but these simply describe the method which the time servers receive a time reference.

NTP servers receive a time source that they can then distribute amongst a network. NTP will check a devices system clock and advance or retreat the time depending on how much it has drifted. By regularly checking the system clock with the time server, NTP can ensure the device is synchronised.

The NTP server is a simple device to install and run. Most connect to a network via an Ethernet cable and the software included is easily configured. However, there are some common troubleshooting problems associated with NTP servers and in particular with receiving timing sources:

A dedicated NTP server will receive a time signal from various sources. The Internet is probably the most common sources of UTC time (Coordinated Universal Time), however, using the Internet as a timing source can be a cause for several time server problems.

Firstly Internet timing sources can’t be authenticated; authentication is NTP’s in-built security measure and ensures that a timing reference is coming from where it says it is. On a similar note to use an Internet timing source would mean that a gap would have to be created in the network firewall, this can obviously cause its own security issues.

Internet timing sources are also notoriously inaccurate. A survey by MIT (Massachusetts Institute of Technology) found less than a quarter of Internet timing sources were any where near accurate and often those that were, were too far away from clients to provide a reliable timing source.

The most common, secure and accurate method for receiving timing source is the GPS system (Global Positioning System). While a GPs signal can be received anywhere on the planet there are still common installation issues.

A GPS antenna has to have a good clear view of the sky; this is because the GPs satellite broadcast their signal by line of sight. He signal can not penetrate buildings and therefore the antenna has to be situated on the rood. Another common issue with a GPS time server is that they need to be left for at least 49 hours to ensure the GPS receiver gets a good satellite fix. Many users find that they are receiving an intermittent signal this is normally due to impatience and not letting the GPS system obtain a solid fix.

The other secure and reliable method for receiving a timing signal is the national radio transmissions. In the UK this is called MSF but similar systems exist in the US (WWVB), Germany (DCF) and several other countries. There are usually less problems faced when using the MSF/DCF/WWVB signal.

Although the radio signal can penetrate buildings it is susceptible to interference from topography and other electrical appliances.  Any issues with a MSF time server can normally be resolved by moving the server to another locale or often just angling the server so its ib-built antenna is perpendicular to the transmission.

NTP Time Server Packet Header Explained

Thursday, November 6th, 2008

Most time servers use Network Time Protocol and like other Internet based protocols NTP contains a packet header. A packet header, put simply, is just is a formatted unit of data that describes the information contained in the packet.

The NTP packet header consists of a number of 32-bit words. Here is a list of the most common packet header terms and their meaning:

IP address – the address of the NTP Time Server

NTP Version – which version of NTP (currently version 4 is the most recent)

Reference timestamp (the prime epoch ) used by NTP to work out the time from this set point (normally January 01 1900

Round trip delay (the time it takes request to arrive and come back in milliseconds)

Local clock offset – time difference between host and client

Leap indicator (if there is to be a leap second that day –normally only on 31 December)

Mode3  –  a three bit integer which values represent: 0=reserved, 1=symmetric active, 2= symmetric passive, 3=client, 4=server, 5=broadcast, 6=NTP control message, 7=reserved for private use.

Stratum level – which stratum level the NTP server is (a stratum 1 server receives the time from an atomic clock source a stratum 2 server receives the time from a stratum 1 server)

Poll Interval (How many requests is made and their intermittence)

Precision – how accurate in milliseconds is the system clock

Root Delay – This is a signed fixed-point number indicating the total roundtrip delay to the primary reference source at the root

Root dispersion (in milliseconds)- The root dispersion is the maximum (worst case) difference between the local system clock and the root of the NTP tree (stratum 1 clock)

Ref ID – 32 bit identifying the reference clock

Originate time stamp (time before synchronisation request)

Receive timestamp – the time the host/NTO time Server got the request

Transmit timestamp – the time the host sent back the request

Valid  response– is the system clock  synchronised or not

Timescales of NTP and advanced time server information

Monday, October 27th, 2008

The NTP timescale is based on UTC (Coordinated Universal Time) which is a global civil timescale that is based on International Atomic Time (TAI) but accounts for the slowing of the Earth’s spin by intermittingly adding ‘leap seconds.’

This is done to ensure that UTC is kept in coincidence with GMT (Greenwich Meantime, often referred to as UT1). Failing to account for the Earth’s slowing in its rotation (and occasional speeding up) would mean that UTC would fall out of synchronisation with GMT and noon, when the sun is traditionally the highest in the sky would drift. In fact if leap seconds were not added eventually noon would fall at midnight and vice versa (albeit in several millennia).

Not everybody is happy with leap seconds, there are those that feel that adding of seconds to keep the Earth’s rotation and UTC inline is nothing but a fudge. However, failing to do so would make such things as astronomical observations impossible as astronomers need to know the exact positioning of the stellar bodies and farmers are pretty reliant on the Earth’s rotation too.

The NTP clock represents time in a totally different way to the way humans perceive time. Instead of formatting time into minutes, hours, days, months and years, NTP uses a continuous number that represents the number of seconds that have past since 0h 1 January 1900. This is known as the prime epoch.

The seconds counted from the prime epoch continue to rise but wraps around every 136 years. The first wrap-around will take place in 2036, 136 years since the prime epoch. To deal with this NTP will utilise an era integer, so when the seconds reset to zero, the integer 1 will represent the first era and negative integers represent the eras before the prime epoch.

Time servers that receive their time from the GPS system are not in fact receiving UTC, primarily because the GPS network was in development before the first leap second but they are based on TAI.  However, GPS time is converted to UTC by the GPS time server.

The radio transmission broadcast from national physics laboratories such as MSF, DCF or WWVB are all based on UTC and so the time servers do not need to do any conversion.

Network Time Protocol Security

Saturday, October 25th, 2008

The protocol used by most network time servers is NTP (Network Time Protocol) and has been around for quite a long time yet it is constantly being updated and developed offering ever higher levels of accuracy and security.

Synchronisation is an essential part of modern computer networks and is essential for keeping a system secure. Without NTP and time synchronisation a computer network can be vulnerable o malicious attacks and even fraud.

Even with a perfectly synchronised network security can still be an issue but there are a few key steps that can be taken to ensure your network is kept secure.

Always use a dedicated Network Time Server. Whilst Internet time sources are common place they are a time source situated outside the firewall. This will have obvious security draw backs as a malicious user can take advantage of the ‘hole’ left in your firewall to communicate with the NTP server. A dedicated NTP server will receive a time signal from an external source.

Normally these types of dedicated time servers will utilise either the GPS network (Global Positioning System) or specialist national time and frequency radio transmissions. Both these time sources offer an accurate and reliable method of UTC time (coordinated universal time) whilst also being secure.

Another way to ensure security is to take advantage of NTP’s built-in security mechanism – authentication. Authentication is a set of encrypted keys that are used to establish if the time source is coming from where it is claiming to come from.

Authentication verifies that each timestamp has come from the intended time reference by analysing a set of agreed encryption keys that are sent along with the time information. NTP, using Message Digest encryption (MD5) to un-encrypt the key, analyses it and confirms whether it has come from the trusted time source by verifying it against a set of trusted keys.

Trusted authentication keys are listed in the NTP server configuration file (ntp.conf) and are stored in the ntp.keys file. The key file is normally very large but trusted keys tell the NTP server which set of subset of keys is currently active and which are not. Different subsets can be activated without editing the ntp.keys file using the trusted-keys config command.

Authentication is highly important in protecting a NTP server from malicious attack; however Internet time sources can’t be authenticated which doubles the risk of using an Internet based time reference.

How to Configure an Authoritative Time Server in Windows Server 2008

Thursday, October 16th, 2008

Time synchronisation in modern computer networks is essential, all computers need to know the time as many applications, from sending an email to storing information are reliant on the PC knowing when the event took place.

Microsoft Windows Server from 2000 onwards has a time synchronisation utility built into the operating system called Windows Time (w32time.exe) which can be configured to operate as a network time server.

Windows Server 2008 can easily set the system clock to use UTC (Coordinated Universal Time, the World’s time standard) by accessing an Internet source (either: time.windows.com or time.nist.gov).

To achieve this, a user merely has to double click the clock on their desktop and adjust the settings in the Internet Time tab.

It must be noted however, that Microsoft and other operating system manufacturers strongly advise that external timing references should be used as Internet sources can’t be authenticated.

To configure the Windows Time service to use an external time source, click Start, Run and type regedit then click OK.

Locate the following subkey:
In the right pane, right-click Type then click Modify, in edit Value type NTP in the Value data box then click OK.

Locate the following subkey:
In the right pane, right-click AnnounceFlags and click Modify. The ‘AnnounceFlags’ registry entry indicates whether the server is a trusted time reference, 5 indicates a trusted source so in the Edit DWORD Value box, under Value Data, type 5, then click OK.

Network Time Protocol (NTP) is an Internet protocol used for the transfer of accurate time, providing time information along so that a precise time can be obtained
To enable the Network Time Protocol; NTPserver, locate and click:

In the right pane, right-click Enabled, then click Modify.

In the Edit DWord Value box, type 1 under Value data, then click OK.

Now go back and click on
In the right pane, right-click NtpServer, then Modify, in the Edit DWORD Value under Value Data type In the right pane, right-click NtpServer, then Modify, in the Edit DWORD Value under Value Data type the Domain Name System (DNS), each DNS must be unique and you must append 0x1 to the end of each DNS name otherwise changes will not take effect.

Now click Ok.

Locate and click the following
In the right pane, right-click SpecialPollInterval, then click Modify.

In the Edit DWORD Value box, under Value Data, type the number of seconds you want for each poll, ie 900 will poll every 15 minutes, then click OK.
To configure the time correction settings, locate:
In the right pane, right-click MaxPosPhaseCorrection, then Modify, in the Edit DWORD Value box, under Base, click Decimal, under Value Data, type a time in seconds such as 3600 (an hour) then click OK.
Now go back and click:
In the right pane, right-click MaxNegPhaseCorrection, then Modify.

In the Edit DWORD box under base, click Decimal, under value data type the time in seconds you want to poll such as 3600 (polls in one hour)
Exit Registry Editor
Now, to restart windows time service, click Start, Run (or alternatively use the command prompt facility) and type:

net stop w32time && net start w32time
And that’s it your time server should be now up and running.

Windows Time Server Synchronising Your Network With NTP

Wednesday, October 15th, 2008

Nearly all a computers activity involves time whether logging a timestamp for when a network was accessed to sending an email, knowing the time is crucial for computer applications.

All computers have an on-board clock that provides time and date information. These Real Time Clock (RTC) chips are battery backed so that even when off they can maintain time, however these RTC chips are mass produced and cannot maintain accurate time and tend to drift.

For many applications this can be quite adequate, however if a computer is on a network and needs to talk to other machines, failing to be synchonised to the correct time can mean many time-sensitive transactions can not be completed and can even leave the network open to security threats.

All versions of Windows Server since 2000 have included a time synchronization facility, called Windows Time Service (w32time.exe), built into the operating system. This can be configured to operate as a network time server synchronizing all machines to a specific time source.

Windows Time Service uses a version of NTP (Network Time Protocol), normally a simplified version, of the Internet protocol which is designed to synchronise machines on a network, NTP is also the standard for which most computer networks across the global use to synchronise with.

Choosing the correct time source is vitally important. Most networks are synchronized to UTC (Coordinated Universal Time) source. UTC is a global standardized time based on atomic clocks which are the most accurate time sources.

UTC can be obtained over the Internet from such places as time.nist.gov (us Naval Observatory) or time.windows.com (Microsoft) but it must be noted that internet time sources can not be authenticated which can leave a system open to abuse and Microsoft and others advise using an external hardware source as a reference clock such as a specialized NTP server.

NTP servers receive their time source from either a specialist radio transmission from national physics laboratories which broadcast UTC time taken from an atomic clock source or by the GPS network which also relays UTC as a consequence of needing it to pin point locations.

NTP can maintain time over the public Internet to within 1/100th of a second (10 milliseconds) and can perform even better over LANs.