ntp time. An example of configuring a local NTP server to work with NetPing devices. Troubleshooting Management

There are many services in operating systems whose normal functioning depends on the accuracy of the system clock. If the exact time is not set on the server, this can cause various problems.

For example, on a local network, it is required that the clocks of machines sharing files be synchronized - otherwise it will not be possible to correctly set the modification time of files. This, in turn, can cause version conflicts or important data to be overwritten.

If the server does not have an exact time set, there will be problems with Cron jobs - it is not clear when they will run. It will be very difficult to analyze the system event logs to diagnose the causes of failures and malfunctions ...

You can go on for a long time...

To avoid all the described problems, you need to set up synchronization of the system clock. Linux uses NTP (Network Time Protocol) for this. In this article, we will talk in detail about how to install and configure NTP on the server. Let's start with a little theoretical introduction.

How does the NTP protocol work?

The NTP protocol is based on a hierarchical structure of exact time servers, in which different levels (English strata) are distinguished. Level 0 refers to the reference clock (atomic clock or GPS clock). At level zero, NTP servers don't work.

Tier 1 NTP servers, which are sources for Tier 2 servers, synchronize with the reference clock. Tier 2 servers synchronize with Tier 1 servers, but can also synchronize with each other. Tier 3 and below servers work the same way. In total, up to 256 levels are supported.

The hierarchical structure of the NTP protocol is characterized by fault tolerance and redundancy. In the event of connection failures with the upstream servers, the backup servers take over the synchronization process. Redundancy ensures that NTP servers are always available. By synchronizing with multiple servers, NTP uses data from all sources to calculate the most accurate time.

Installing and configuring an NTP server

The best known and most widely used time synchronization tool is the ntpd daemon. Depending on the settings specified in the configuration file (this will be discussed below), it can act both as a server and as a client (i.e. it can both receive time from remote hosts and distribute it to other hosts) . Below we will describe in detail how to install and configure this daemon in OC Ubuntu.

Installation

The NTP program is included in the distributions of most modern Linux systems and is installed using a standard package manager:

$ sudo apt-get install ntp

Setting

After the installation is complete, open the /etc/ntp.conf file in a text editor. It stores all program settings. Let's consider them in more detail.

Logging options

The first line of the config file looks like this:

Driftfile /var/lib/ntp/ntp.drift

It specifies a file for storing information about the frequency of the time offset. This file stores the value resulting from previous time adjustments. If external NTP servers become unavailable for one reason or another, the value will be taken from it.

Logfile /var/log/ntp.log

List of servers for synchronization

The configuration file specifies the list of NTP servers with which synchronization will be performed. By default it looks like this:

Server 0.ubuntu.pool.ntp.org server 1.ubuntu.pool.ntp.org server 2.ubuntu.pool.ntp.org server 3.ubuntu.pool.ntp.org

Each line means a group of servers that will report the correct time to our server. You can improve synchronization accuracy using the iburst option (it indicates that not one, but several packets should be sent to the server for synchronization):

Server 0.ubuntu.pool.ntp.org iburst server 1.ubuntu.pool.ntp.org iburst server 2.ubuntu.pool.ntp.org iburst server 3.ubuntu.pool.ntp.org iburst

You can also specify your preferred server with the prefer option:

Server 0.ubuntu.pool.ntp.org iburst prefer

NTP servers are scattered around the world (here, for example, is a list of available public NTP servers). To ensure a more accurate setting of the system clock, it is recommended to synchronize only with ntp servers of the region in which our server is geographically located. To do this, in the /etc/ntp.conf configuration file, specify the regional subdomain for pool.ntp.org in the server addresses:

• Asia - asia.pool.ntp.org;
• Europe - europe.pool.ntp org;
• Africa — africa.pool.ntp.org;
• North America - north-america.pool.ntp.org;
• South America - south-america.pool.ntp.org;
• Oceania - oceania.pool.ntp.org.

You can also specify subdomains for individual countries (for more details, see ). There is also a subdomain for Russia - ru.pool.ntp.org

Backup time server

An NTP server that is disconnected from the Internet for any reason may transmit its system clock data for synchronization. To do this, add the following line to the configuration file:

Server 127.127.1.0

Restrictions

Recently, cases of using NTP servers to amplify traffic in DDoS attacks have become more frequent (for more details, see, for example,). To prevent our server from becoming a victim of abuse, it would be useful to set access restrictions for external clients. By default, the following restrictions are set in the /etc/ntp.conf file:

Restrict −4 default kod notrap nomodify nopeer noquery restrict −6 default kod notrap nomodify nopeer noquery

The nomodify, notrap, nopeer, and noquery options prevent third-party clients from modifying anything on the server. The kod parameter (this abbreviation means kiss of death) provides additional protection: a client that sends too many requests will first receive a so-called kod packet (denial of service warning) and then be disconnected from the server.

In order for machines from the local network to synchronize with the NTP server, add the following line to the configuration file:

Restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

For the local host, you can set access to the NTP server without restrictions:

Restrict 127.127.1.0

Synchronization check

After all the necessary changes have been made to the configuration file and saved, restart the NTP server:

$ service restart ntp

Then run the following command:

$ ntpq -pn

Its output will be presented in the form of a table:

Remote refid st t when poll reach delay offset jitter ======================================= ====================================== *62.76.96.4 130.173.91.58 2 u 207 256 37 10.985 -215.79 256.992 +85.21.78.91 89.175.22.41 2 u 193 256 37 32.623 -207.70 259.121 +31.131.249.27 89.175.22.41 2 u 198 25 6 37 0.621 -216.90 257.037 +85.21.78.8 193.11.166.20 2 u 193 256 37 32.028 - 207.41 259.863 +91.189.94.4 193.79.237.14 2 u 192 256 37 50.573 -206.62 259.542

The table indicates the following parameters:

• remote — exact time server address (this column displays servers from the list in the configuration file);
• refid - upstream server (the one from which the server from the previous columns receives synchronization);
• st — level (stratum) of the server;
• t — peer type (u- unicast, m- multicast);
• when is the time of the last synchronization;
• poll is the time in seconds it takes for the NTP daemon to synchronize with the peer.
• reach — server availability status; after eight successful synchronization attempts, the value of this parameter becomes equal to 377;
• delay — response delay time from the server;
• offset is the time difference between our server and the synchronization server; a positive value of this parameter means that our clock is fast, a negative value means that it is behind;
• jitter is the time offset on the remote server.

The following characters can be specified to the left of the server address:

• * server selected for synchronization;
• + a server suitable for updating (with which you can synchronize);
• — it is not recommended to synchronize with the server;
• x server is unavailable.

You can check if a server from the list is suitable for synchronization using the command:

Ntpdate -q server хх.ххх.ххх.ххх, stratum 2, offset −0.127936, delay 0.02600 7 Jul 14:30:23 ntpdate: adjust time server хх.ххх.ххх.ххх offset −0.127936 sec

From the above output, it can be seen that the server is suitable for synchronization, its level is 2, the offset is 0.127936 ms, and the delay is 0.026 ms.

You can also find out how the synchronization went (successfully or with errors) from the logs:

7 Jul 15:17:17 ntpd: synchronized to 91.198.10.4, stratum=2 7 Jul 15:17:17 ntpd: kernel time sync disabled 0041 7 Jul 15:17:21 ntpd: kernel time sync enabled 0001

Setting the local date and time

The ntpdate command can be used to set the local date and time on the server by sending a request to the NTP server.

The exact time server is designed to synchronize time-frequency indicators. The device generates frequency and time signals with high accuracy and synchronizes these parameters at remote sites.

The time synchronization server can operate using various signals and protocols, including the common NTP protocol and the more popular PTP protocol. Receiving signals from satellites of global positioning systems GPS and GLONASS, the server transmits them to client devices and synchronizes time parameters.

Description of SSV-1G

Frequency and time server "SSV-1G" is a stand-alone device 1.5 U high, installed in a 19" telecommunication rack, designed to generate frequency and time signals.

Unlike many other products on the market, the SSV-1G time server is not based on industrial servers, but uses its own hardware platform, which significantly reduces its cost, increases reliability, and eliminates dependence on the manufacturer of the operating system and server platform .

Synchronization of the exact time server is carried out from the signals of satellite radio navigation systems (SRNS) of both the Russian GLONASS and GPS, which increases the accuracy of time determination and reduces the risks of the operator's dependence on foreign navigation systems.

The 1PPS signal input, the E1/2.048 MHz input, or the 5 (10) MHz input can be used as backup clock sources for the master oscillator.

The RS232 input of the COMB module can be used as a backup source of time scale synchronization using the TOD, Sirf protocols.

The SSV-1G is powered by two inputs (Main / Backup) from independent sources AC 220 V 50Hz / DC 48 V. A delivery option is available with two DC 48 V power inputs and an additional external converter AC 220 V 50Hz - DC 48 V, which allows to supply power to the SSV-1G through one input AC 220 V 50 Hz, and through the other input DC 48 V. Power consumption depends on the configuration and does not exceed 40 W.

Maintenance of the device is simplified as much as possible. Operating personnel can receive information and control the device using the Maintenance System software, or using the control tools built into the device - a graphic indicator and a keyboard.

Specifications SSV-1G

Advantages of the SSV-1G time source

• Optimal price-quality ratio

The SSV-1G source has one of the best price-quality ratios in its equipment class. This is achieved by two technological solutions.

Firstly, the SSV-1G is built on the basis of a hardware platform of its own production. In addition, there is no third-party licensed software in the SSV-1G device.

Secondly, instead of expensive high-precision rubidium oscillators with a short service life, quartz oscillators are used with double temperature control, which ensures a constant temperature level necessary to ensure a stable operating mode. This solution is similar in accuracy to rubidium generators, but it costs significantly less and is more reliable.

• Information Security

All SSV-1G expansion modules, including the NTP-server module, have a hardware implementation built on the basis of a rigid automaton.

This solution provides the highest performance and as a result:

1. High accuracy of time stamp transmission due to the absence of internal delays that affect the asymmetry of the NTP packets transmission and reception channel.
2. The impossibility of disrupting the functioning of the NTP server due to DDOS attacks. The speed of the local NTP server is higher than the speed of the Ethernet channel.
3. The impossibility of disrupting the functioning of the NTP server due to unauthorized access to resources through the Ethernet port. The NTP time server only provides functionality and does not respond to any other IP packets.

Modular design

The base chassis of the SSV-1G source is a 19-inch case with installed control modules, a SRNS signal receiver, a thermally stabilized quartz oscillator with a phase-locked loop, and a backplane for installing functional expansion modules.

The modular design allows you to create up to 16 NTP servers on the basis of one device in physically separated networks.

Expansion modules are installed in accordance with the required configuration of input / output signals based on the specification determined at the time of order.

When changing the configuration, there is no need to buy a new device, it is enough to install an additional required number of expansion modules.

In total, up to 8 expansion modules can be installed.

Frequency and time source modules SSV-1G

MLAN module

• Simple Network Time Protocol (RFC 1769, RFC 2030);
• Time Protocol (RFC 868);
• Daytime Protocol (RFC 867).

MLANP module

The module is designed to receive requests from clients and generate a packet with the exact current time according to the following protocols:

• Network Time Protocol (RFC 1119, RFC 1305, RFC 5905);

The Precision Time Protocol (PTP) is designed for a single client connection. The operating mode is determined by any combination of the following parameters:

When using the Network Time Protocol (NTP), it is possible to send packets to the specified IP address (including broadcast Broadcast), with the specified frequency.

The module has two independent channels with identical functionality and the same set of configuration parameters. Channels are configured individually. The load capacity of each channel is about 123,000 packets per second.

MGLAN module (NTP/PTP)

The module is designed to receive requests from clients and generate a packet with the exact current time according to the following protocols:

• Precision Time Protocol V2 (IEEE Std 1588-2008);
• Network Time Protocol (RFC 1119, RFC 1305, RFC 5905);
• Simple Network Time Protocol (RFC 1769, RFC 2030).

MPPS module

The module is designed to receive a PPS signal (1Hz) and form a signal, the shape of which is set in the configuration, has two identical channels, each of which can operate in the receive or transmit mode.

Module "MSYNC 120", "MSYNC 75"

The module is designed to receive and generate 2.048 MHz (G.703/10) or 2.048 Mbps (G.703/6) signals and has two identical channels, each of which can operate in the signal reception or transmission mode.

MCOMB module

The MCOMB module is designed to receive/transmit the exact current time in the specified format via the RS-232 interface, as well as to receive and generate a 1 PPS time stamp pulse.

Supported RS-232 interface protocols: TOD; Sirf, TimeString, NMEA.

Module "M10M"

The module is designed to receive and generate 5 MHz or 10 MHz signals and has two identical channels, each of which can operate in the mode of receiving or transmitting a signal.

Module "MTP" (Current Loop)

The module is designed to generate a time stamp pulse via the "Current loop" or "Dry contact" interface and has two independent, galvanically isolated channels.

MIRIG module

The MIRIG module is designed to generate a signal according to the IRIG STANDARD 200-04 protocol specification.

Module "M422"

Module "M422" is designed to receive/transmit the exact current time in the specified format via the RS-422/485 interface, as well as receive and generate a time stamp pulse via the RS-422/485 interface.

Supported RS-422/485 interface protocols: TOD, Sirf, TimeString, NMEA.

Centralized Management

Control and management of the operation of synchronization devices installed on the operator's network can be provided by specialized network software "Maintenance", developed by CJSC "COMSET-service".

Troubleshooting Management

• collection of messages about accidents, malfunctions and events requiring attention from connected devices;
• getting a list of accidents;
• filtration of accidents with assignment of severity degree to them;
• display of accidents and malfunctions, as well as their characteristics;
• control of the accessibility of the control device (the presence of a communication channel between the device and the control system);
• generation of reports on accidents and events.

Security management

• protection of access to the system using a username and password;
• user authorization in the control system;
• four levels of user rights from administrator (with full rights) to a user with read-only rights;
• control of actions of operators on processing of malfunctions.

Configuration management

• adding a new device;
• for each supported device remote display of information about the device: information on the inputs/outputs used, device configuration, device operation modes, parameters that determine the operation of the device;
• automatic recognition of device serial numbers (inventory function).

Performance management

• displaying the current characteristics of devices in real time.

Output and user interface

• data on the state of network elements are displayed in a tabular form with the possibility of printing them;
• the system has a user-friendly interface that makes it easy to view:
  • a list of devices, their current state and state information elements;
  • list of users, access rights granted to users;
  • current state of all device modules;
  • the state of the satellite signal receiver, the state of the satellite constellation visible at the installation point;
  • and much more.
• “Maintenance” software has advanced tools for visualization and analysis of fault signals with the possibility of sound notification of various tones, easily customizable by the user of the system.

The time server "SSV-1G" is a proprietary development of the KOMSET-service company. It has an independent hardware platform, high timing accuracy, user-friendly interface and two power supplies: main and backup. You can buy a time synchronization server in Moscow from us in a standard or extended version. It is also possible to supply the device throughout Russia. You can get prices for equipment by submitting a request for a commercial offer from the company.

Where is the NTP time server used?

The scope of the equipment is quite wide. NTP servers are used at all facilities where it is extremely important to regulate time parameters:

• Companies of mobile operators and telecommunications.
• Internet providers.
• Airports, railway and bus stations.
• In commercial automated accounting systems.

Setting up an NTP server in Windows

Starting with Windows 2000, all Windows operating systems include a time service W32Time. This service is designed to synchronize time within an organization. W32Time is responsible for the operation of both the client and server parts of the time service, and the same computer can be both an NTP (Network Time Protocol) client and server.

By default, the Windows time service is configured as follows:

When the operating system is installed, Windows starts an NTP client and synchronizes with an external time source;
When you add a computer to a domain, the synchronization type changes. All client computers and member servers in a domain use a domain controller that authenticates them for time synchronization;
When a member server is promoted to a domain controller, an NTP server is launched on it, which uses a controller with the PDC emulator role as a time source;
The PDC emulator, located in the forest root domain, is the primary time server for the entire organization. At the same time, it is also synchronized with an external time source.

This scheme works in most cases and does not require intervention. However, the Windows time service structure may not follow a domain hierarchy, and any computer can be designated as a reliable time source. As an example, I will describe setting up an NTP server in Windows Server 2008 R2, although the procedure has not changed much since Windows 2000.

Starting an NTP server

I note right away that the time service in Windows Server (from 2000 to 2012) does not have a graphical interface and is configured either from the command line or by directly editing the system registry. Personally, the second method is closer to me, so we go to the registry.

So, the first thing we need to do is start the NTP server. Open the registry branch
HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpServer.
Here to enable the NTP server parameter Enabled you need to set the value 1 .

Then we restart the time service with the command net stop w32time && net start w32time

After restarting the NTP service, the server is already active and can serve clients. You can verify this using the w32tm /query /configuration command. This command displays a complete list of service options. If section NtpServer contains the string Enabled:1, then everything is in order, the time server is working.

In order for the NTP server to serve clients, do not forget to open UDP port 123 on the firewall for incoming and outgoing traffic.

Basic NTP server settings

The NTP server has been enabled, now you need to configure it. Open the registry branch HKLM\System\CurrentControlSet\services\W32Time\Parameters. Here we are primarily interested in the parameter type A that specifies the type of sync. It can take the following values:

NoSync- The NTP server is not synchronized with any external time source. The clock built into the CMOS chip of the server itself is used;
NTP- The NTP server is synchronized with external time servers, which are specified in the registry setting NtpServer;
NT5DS- The NTP server synchronizes according to the domain hierarchy;
AllSync- The NTP server uses all available sources for synchronization.

The default value for a computer that is a member of a domain is NT5DS, for a stand-alone computer - NTP.

And parameter NtpServer, which specifies the NTP servers with which this server will synchronize time. By default, this parameter contains the Microsoft NTP server (time.windows.com, 0x1), if necessary, you can add several more NTP servers by entering their DNS names or IP addresses separated by a space. The list of available time servers can be viewed for example.

You can add a flag at the end of each name (ex. ,0x1) which specifies the mode to synchronize with the time server. The following values ​​are allowed:

0x1– SpecialInterval, use of a special polling interval;
0x2– UseAsFallbackOnly mode;
0x4– SymmetricActive, symmetrical active mode;
0x8– Client, sending a request in client mode.

When using the SpecialInterval flag, the interval value set in the key is required SpecialPollInterval. If the UseAsFallbackOnly flag is set, the time service is told that this server will be used as a fallback server and that other servers in the list will be contacted before synchronizing with it. Symmetric active mode is used by NTP servers by default, and client mode can be used in case of synchronization problems. You can see more about synchronization modes, or don’t fool around and just put it everywhere ,0x1(as advised by Microsoft).

Another important parameter Announce Flags located in the registry key HKLM\System\CurrentControlSet\services\W32Time\Config. It is responsible for how the NTP server declares itself and can take the following values:

0x0( Not a time server) - the server does not advertise itself through NetLogon as a time source. It can respond to NTP requests, but neighbors will not be able to recognize it as a time source;
0x1(Always time server) - the server will always announce itself, regardless of the status;
0x2(Automatic time server) - the server will only announce itself if it receives reliable time from another neighbor (NTP or NT5DS);
0x4(Always reliable time server) - the server will always declare itself as a reliable time source;
0x8(Automatic reliable time server) - a domain controller is automatically declared reliable if it is a forest root domain PDC emulator. This flag allows the forest master PDC to assert itself as the authorized time source for the entire forest, even if it is not connected to the upstream NTP servers. No other controller or member server (which has the default flag 0x2) cannot claim to be a reliable source of time if it cannot find a source of time for itself.

Meaning Announce Flags is the sum of its constituent flags, for example:

10=2+8 - The NTP server declares itself as a reliable time source, provided that it receives time from a reliable source or is a root domain PDC. Flag 10 is set by default for both domain members and standalone servers.

5=1+4 - The NTP server always claims to be a reliable time source. For example, to declare a member server (not a domain controller) as a reliable time source, flag 5 is needed.

Well, let's set the interval between updates. The key already mentioned above is responsible for it. SpecialPollInterval, located in the registry key HKLM\System\CurrentControlSet\services\W32Time\TimeProviders\NtpClient. It is in seconds and defaults to 604800, which is 1 week. This is a lot, so it's worth reducing the value of SpecialPollInterval to a reasonable value, say 1 hour (3600).

After configuration, you need to update the service configuration. You can do this with the w32tm /config /update command. And a few more commands for configuring, monitoring and diagnosing the time service:

w32tm /monitor - using this option, you can find out how much the system time of this computer differs from the time on the domain controller or other computers. For example: w32tm /monitor /computers:time.nist.gov
w32tm /resync - With this command, you can force the computer to synchronize with the time server it uses.
w32tm /stripchart - shows the time difference between the current and remote computer, and can display the result in a graphical form. For example, the command w32tm /stripchart /computer:time.nist.gov /samples:5 /dataonly will make 5 comparisons with the specified source and display the result in text form.

w32tm /config is the main command used to configure the NTP service. With its help, you can set the list of time servers used, the type of synchronization, and much more. For example, you can override the default values ​​and set up time synchronization with an external source using the command w32tm /config /syncfromflags:manual /manualpeerlist:time.nist.gov /update
w32tm /query - Shows the current service settings. For example, w32tm /query /source will show the current time source, and w32tm /query /configuration will show all service parameters.

Well, as a last resort 🙁
w32tm /unregister - Removes the time service from the computer.
w32tm /register - Registers the time service on the computer. In this case, the entire parameter branch in the registry is recreated.

Network Time Protocol is a network protocol for synchronizing a computer's internal clock using variable latency networks based on packet switching.

Although traditionally NTP uses UDP for its operation, it is also capable of operating over TCP. The NTP system is extremely robust to changes in media latency.

Time is represented in the NTP system as a 64-bit number, consisting of a 32-bit second counter and a 32-bit fractional second counter, allowing time to be transmitted in the range of 2-32 seconds, with a theoretical accuracy of 2-32 seconds. Because the NTP time scale repeats every 232 seconds (136 years), the recipient must at least roughly know the current time (to within 68 years). Also keep in mind that the time is counted from midnight on January 1, 1900, and not from 1970, so almost 70 years (including leap years) must be subtracted from the NTP time in order to correctly align the time with Windows or Unix systems.

How it works

NTP servers operate in a hierarchical network, each level of the hierarchy is called a tier (stratum). Tier 0 is represented by the reference clock. The GPS signal (Global Positioning System) or ACTS (Automated Computer Time Service) is taken as a reference. At the zero tier, NTP servers do not work.

Tier 1 NTP servers receive time data from a reference clock. Tier 2 NTP servers are synchronized with Tier 1 servers. There can be up to 15 tiers in total.

NTP servers and NTP clients receive their time data from tier 1 servers, although in practice NTP clients would be better off not doing this as thousands of individual client requests would be too much for tier 1 servers. It is better to set up a local NTP server that your customers will use to get information about the time.

The hierarchical structure of the NTP protocol is fault tolerant and redundant. Let's look at an example of his work. Two Tier 2 NTP servers synchronize with six different Tier 1 servers, each on an independent link. Internal hosts are synchronized with internal NTP servers. The two Tier 2 NTP servers coordinate time with each other. If the link to the Tier 1 server or one of the Tier 2 servers fails, the redundant Tier 2 server takes over the synchronization process.

Similarly, Tier 3 hosts and devices can use any of the Tier 2 servers. More importantly, having a redundant network of NTP servers ensures that the time servers are always available. By synchronizing with multiple time servers, NTP uses data from all sources to calculate the most accurate time.

It is worth noting that the NTP protocol does not set the time in its purest form. It corrects the local clock using the time offset, the difference between the time on the NTP server and the local clock. NTP servers and clients adjust their clocks by synchronizing with the current time gradually or all at once.

Good afternoon, guests and regular readers. Gradually moving from the basics to a more in-depth study of Linux. Today I want to review operation of the ntp protocol, as well as setting time servers on linux(ntp server). So let's start with the theory.

NTP protocol

Network Time Protocol (NTP)- a network protocol for synchronizing the computer's internal clock using networks with variable latency (read "width" / channel quality).

NTP uses for its work UDP protocol and port 123.

Current protocol version - NTP 4. NTP uses a hierarchical system "hour levels"(they are also called Stratum). Level 0 (or Stratum 0)- these are usually devices that are atomic clocks (molecular, quantum), GPS clocks or radio clocks. These devices are usually not published to the World Wide Web, but are connected directly to Tier 1 time servers via the RS-232 protocol (marked with yellow arrows in the illustration). Level 1 synchronized with high precision clock level 0, usually work as sources for servers level 2. Level 2 synchronized with one of the machines level 1, and it is also possible to synchronize with servers of your level. Level 3 works similarly to the second. Usually servers of levels from the second and below are published in the network. NTP protocol supports up to 256 levels. I would also like to note that servers of levels 1 and 2, and sometimes 3 are not always open to the public. Sometimes, in order to synchronize with them, you need to send a request by mail - to domain administrators.

Why is there a restriction on access to servers? With the transition to each level, the error relative to the primary server increases slightly, but increasing the total number of servers and hence .

Assigning an NTP server on the local network

Why do we need an NTP server? For example, there are services in operating systems that may depend on synchronized time. The most notable example of such services is the Kerberos authentication protocol. For it to work, it is necessary that on computers accessed using this protocol, the system time differs by no more than 5 minutes. In addition, the exact time on all computers greatly facilitates the analysis of security logs when investigating incidents on a local network.

NTP server/client operating modes

Client/Server

This mode is by far the most commonly used on the Internet. The scheme of work is classic. The client sends a request, to which the server sends a response for some time. The client is configured using the server directive in the configuration file, which specifies the DNS name of the time server.

Symmetric active/passive mode

This mode is used if time synchronization is performed between a large number of peer machines. In addition to the fact that each machine synchronizes with an external source, it also synchronizes with its peers, acting as a client and time server for them. Therefore, even if the machine "loses" the external source, it will still be able to get the exact time from its neighbors. Neighbors can work in two modes - active and passive. When operating in active mode, the machine itself transfers its time to all neighbor machines listed in the peers section of the ntp.conf configuration file. If neighbors are not specified in this section, then the machine is considered to be in passive mode. Authentication must be used to prevent an attacker from compromising other machines by posing as an active source.

Broadcast mode

This mode is recommended when a small number of servers serve a large number of clients. When operating in this mode, the server periodically broadcasts packets using the subnet's broadcast address. A client configured to synchronize in this manner receives the server's broadcast packet and synchronizes with the server. A feature of this mode is that the time is delivered within the same subnet (restriction of broadcast packets). In addition, authentication must be used to protect against intruders.

Multicast mode

This mode is similar to broadcast in many ways. The difference lies in the fact that multicast addresses of class D networks of the IP address space are used to deliver packets. Clients and servers are given the address of the multicast group they use for time synchronization. This makes it possible to synchronize groups of machines located on different subnets, provided that the routers connecting them support the IGMP protocol and are configured to transmit multicast traffic.

Manycast Mode

This mode is new to the fourth version of the NTP protocol. It implies that the client searches for manycast servers among its network neighbors, receives time samples from each of them (using cryptography) and, based on these data, selects the three “best” manycast servers with which the client will synchronize. In the event of a failure of one of the servers, the client automatically updates its list.

To transmit time samples, clients and servers operating in manycast mode use addresses of multicast groups (class D networks). Clients and servers using the same address form the same association. The number of associations is determined by the number of multicast addresses used.

Time in Linux

I will briefly tell you what time exists in Linux and how to set it. In Linux, as in other OS, there are 2 times. First - hardware , sometimes called Real Time Clock, abbreviated ( RTC) (they are also BIOS clocks) they are usually associated with an oscillating quartz crystal, which has an accuracy of up to several seconds per day. The accuracy depends on various fluctuations, such as ambient temperature. Second clock - internal software clock , which run continuously, including during breaks in the system. They are subject to fluctuations associated with high system load and interrupt latency. However, the system usually reads the hardware clock at boot and then uses the system clock.

Operating system date and time set at boot based on the value hardware clock, and time zone settings. The time zone settings are taken from the file /etc/localtime. This file is a link (but more often a copy) of one of the files in the directory structure /usr/share/zoneinfo/.

Linux hardware clocks can store time in the format UTC(analogue of GMT), or the current territorial time. The general recommendation on what time to set (?) is as follows: if the computer has several operating systems and one of them is Windows, then you must use the current time (because Windows takes the time from the BIOS / CMOS and considers it local). If only operating systems of the UNIX family are used, then it is desirable to store the time in the BIOS in UTC format.

After the operating system boots, the operating system clock and the BIOS are completely independent. The system kernel synchronizes the system clock with the hardware clock every 11 seconds.

After some time, there may be a difference of several seconds between the hardware and software clocks. Which clock keeps the correct time? Neither one nor the other until we set up time synchronization.

Note:

The Linux kernel always stores and calculates time as the number of seconds since midnight January 1st, 1970 of the year, whether your clock is set to local time or universal time. The conversion to local time is done during the query process.

Because the number of seconds since January 1, 1970 UTC is stored as a signed 32-bit integer (this is true for Linux/Intel systems), your clock will stop working around 2038. Linux doesn't have a Y2K problem, but it does have a Y2038 problem. Fortunately, by that time all linux's will be running on 64-bit systems. A 64-bit integer will contain our clock up to approximately 292271-millionth year.

NTP Server Linux

Introduction

There are many implementations for time synchronization for Linux OS. The best known are Xntpd (NTP version 3), ntpd (NTP version 4), Crony and ClockSpeed. In our example, we will use the ntp server ntpd.

The ntpd daemon is both a time server and a client, depending on the settings of the configuration file /etc/ntpd.conf (sometimes /etc/ntp.conf), the daemon can "accept" time from remote servers and "distribute" time to other hosts.

General time synchronization circuit on the local network is as follows: you need to have 1 or 2 servers with access to the global network, which will receive time from the Internet. Synchronize all computers on the local network with the specified servers that receive time from the Internet.

Installing ntpd

Actually, daemon installation comes down to installing the following packages: ntp(package including the daemon itself), ntpdate(utility for manual time synchronization - obsolete), ntp-doc(package documentation), in some distributions you will need to install the same ntp-utils(diagnostic utilities), some of them are included in the ntp package. How to install programs on Linux, I described in. After installing the package, in most distributions, the daemon will already be configured as an ntp client (for example, it was like this in Debian). Accordingly, the main configuration files were automatically created: /etc/ntp.conf and /var/lib/ntp/ntp.drift and the daemon was launched automatically.

Before configuring the daemon to synchronize with the outside world, I would suggest setting the current system date to a value that is as close to real time as possible. Setting the Date in Linux produced by the command: date MMDDhhmmCCYY.ss, where MM - month, DD - day of the month, hh - hours, mm - minutes, CCYY - 4 digits of the year, ss - seconds. At the same time, the values CCYY.ss not required to be specified.

As you can see, the specified command will set the current date and time to December 27, 2010, 20:06:30. date command without parameters, display the current system time. This command has a bunch of options, which can be found in man date.

Also, you need to correctly configure the hardware clock and time zone. As mentioned above, the time zone is configured by copying the required zone file from the directory /usr/share/zoneinfo/ to file /etc/localtime:

Ntp-server:~# cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Hardware I set the clock to UTC:

# cat /etc/sysconfig/clock | grep UTC # UTC=true indicates that the clock is set to UTC; UTC=true ntp2-server:~# cat /etc/default/rcS | grep UTC UTC=yes

The first example specifies a configuration file that defines the use of UTC for RH, the second - for Deb distributions.

In addition to setting the settings to use UTC time, you must set hardware time. (in most cases this is not necessary, because the set system time is inevitably synchronized with the hardware, by the kernel). However, if you are willing to do so... hwclock command reads and sets the hardware clock based on the parameters passed to it. The available options are described in the command's manual page. Here are some examples of using hwclock:

ntp-server# hwclock # reads the time from the hardware clock ntp-server# hwclock --systohc --utc # sets the hardware clock to # UTC based on the system time ntp-server# hwclock --systohc # sets the hardware clock # to local based on system time ntp-server# hwclock --set --date "22 Mar 2002 13:17" # sets the hardware clock # to the specified string

Another option for changing the time in the hardware clock is accessing the BIOS when the system boots. Because the OS time is independent of the hardware clock, any changes to the BIOS will be taken into account on the next boot.

Now that we have everything prepared and installed, let's proceed to at a construction site.

Managing the ntpd daemon

Control ntpd daemon is no different from controlling any other demons. Start or restart the ntpd service:

#/etc/init.d/ntp start #/etc/init.d/ntp restart

Stop:

#/etc/init.d/ntp stop

#/bin/kill `cat /var/run/ntpd.pid`

The daemon has the following startup options:

P - PID file,
-g - enable transition to big time jump
-c - config file
-q - force manual sync

Setting up the ntpd server

First of all, I advise you to change the daemon startup parameters in the following configuration file:

Ntp-server:~# cat /etc/default/ntp NTPD_OPTS="-g"

# cat /etc/sysconfig/ntpd # Parameters for NTP daemon. # See ntpd(8) for more details. .... # Specifies additional parameters for ntpd. NTPD_ARGS="-g"

This setting will allow the clock to be synchronized even if there is a very large time difference.

So, as I said, the configuration information ntpd daemon is in the file /etc/ntp.conf. The syntax of the file is standard, as in many other configs: empty lines and lines starting with the "#" character are ignored. Here is a simple example:

Ntp-server:~# cat /etc/ntp.conf server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift

Parameter server specifies which servers will be used for synchronization, one per line. If the server is given with an argument prefer, How ntplocal.example.com, then this server is given preference over the others. The response from the preferred server will be discarded if it differs significantly from other servers' responses, otherwise it will be used without regard to other responses. Argument prefer typically used for NTP servers that are known to be very accurate, such as those that use dedicated timekeeping equipment.

Parameter driftfile specifies the file that is used to store the system clock offset. As far as I understand, this file constantly stores some value, which is formed based on the analysis of past time adjustments, and if external time sources become unavailable, then the time adjustment occurs according to the value from the file drift. It must not be modified by any other processes. And before specifying this file in the configuration - the file must be created.

By default, the NTP server will be available to all hosts on the Internet. Parameter restrict in file /etc/ntp.conf allows you to control which machines can access your server. If you want to prevent all machines from accessing your NTP server, add the following line to the file /etc/ntp.conf:

restrict default ignore

If you want to allow sync your clock with your server only machines on your network, But ban them configure the server or be equal participants in time synchronization, then instead of the specified one, add the line:

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

where 192.168.1.0 is the IP address of your network and 255.255.255.0 is its netmask. /etc/ntp.conf may contain multiple restrict directives.

For the daemon to work correctly and more accurately, it is advisable to choose a level server - from stratum 2 (you can, of course, stratum1, but you have to kill time looking for such a server) and from the selected stratum 2 those to which the minimum "distance". Usually such servers can be provided by your ISP. The number of selected servers is desirable - more than 2-3, the more the better, but within reasonable limits. If you are too lazy to choose the best servers, then you can take a list of open servers of the second level from here: http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers.

Select a list of reference NTP servers

We go to the specified address (http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers) and select a list of initial servers. From this list, we select the servers that meet our requirements by analyzing the output of the command ntpdate. When the command is executed, the following syntax is applied:

ntpdate parameters servers_space separated

In order for our query not to make changes to the system, we must use the -q parameter, which indicates the use of the query without making changes. It is also possible to use the -d switch, which indicates that the command will be executed in debug mode, displaying additional information, without making real changes (with this switch, a bunch of other garbage is displayed :), which we don’t need at the moment). See man 8 ntpdate for other options. From the specified link, I selected all the Open Access servers located in Russia (RU) + the one provided by the provider and ran the command, it turned out something like this:

ntp-server:~# ntpdate -q ntp2.ntp-servers.net ntp1.vniiftri.ru ntp2.vniiftri.ru ntp4.vniiftri.ru ntp0.ntp-servers.net ntp1.ntp-servers.net ntp.corbina.net server 88.147.255.85 stratum 1 offset 0.006494 delay 0.09918 server 62.117.76.142 stratum 1 offset 0.002552 delay 0.06920 server 62.117.76.141 stratum 1 offset 0.003 147, delay 0.06918 server 62.117.76.140, stratum 1, offset 0.004823, delay 0.07350 server 88.147.254.228, stratum 1, offset -0.002355, delay 0.12030 server 88.147.254.229, stratum 1, offset -0.000922, delay 0.10577 server 62.117.76.1 38, stratum 1, offset 0.005331, delay 0.07401 server 195.14 .40.141, stratum 2, offset 0.002846, delay 0.07188 13 Jan 19:14:09 ntpdate: adjust time server 62.117.76.141 offset 0.003147 sec

In the example, our servers successfully issued the stratum1 level, which is good news (except for the provider's server), offset is the time difference with this server in seconds, delay is the synchronization delay in seconds. Usually, b ABOUT Greater accuracy is obtained when using servers that have a low latency packet transmission over the network. To find out, you can use . Accordingly, by first choosing those with a shorter response time, and of them, those with fewer hops. I, in order not to waste time, will use all the specified servers and enter them into the configuration file. Total, knowing all of the above, I will describe my resulting file /etc/ntp.conf:

Ntp-server:~# cat /etc/ntp.conf # LAN servers (commented out, not used - only one server on the network) #server 192.168.0.2 #server 192.168.0.5 # Internet server server ntp2.ntp-servers.net server ntp1.vniiftri.ru server ntp2.vniiftri.ru server ntp4.vniiftri.ru server ntp0.ntp-servers.net server ntp1.ntp-servers.net server ntp3.vniiftri.ru server ntp.corbina.net # Server files driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntpstats # restricting access to the server: # ignore everything by default restrict default ignore # localhost without parameters - everything is allowed. Parameters go only to bans. restrict 127.0.0.1 # the following describes the servers with which we synchronize in the local network. # We allow them everything except traps and requests to us restrict 192.168.0.2 noquery notrap restrict 192.168.0.5 noquery notrap # for LAN we also allow everything except traps and modifications restrict 192.168.0.1 mask 255.255.255.0 nomodify notrap nopeer # allow external time sources access: restrict ntp2.ntp-servers.net restrict ntp1.vniiftri.ru restrict ntp2.vniiftri.ru restrict ntp4.vniiftri.ru restrict ntp0.ntp-servers.net restrict ntp1.ntp-servers.net restrict ntp3.vniiftri.ru restrict ntp.corbina.net # and this is a hack that sets the level of trust for the server (strata) to itself equal to 3 # in a nutshell, the higher the level, the lower the number. 0 is the atomic clock, #1 is synchronized with it, 2 is with the first one, and so on. server 127.127.1.1 fudge 127.127.1.1 stratum 3

For a more in-depth understanding and configuration of the server, I will describe some ntpd configuration options that I did not mention:

• enable/disable auth/monitor/pll/pps/stats - Turn on, turn off working mode:
  • auth- communicate with unmentioned neighbors only in authentication mode;
  • monitor- allow request monitoring;
  • pll- allow setting local clock frequency via NTP;
  • stats- allow the collection of statistics;
• statisticsloopstats- with each modification of the local clock, writes a line to the file loopstats;
• statisticspeerstats- each communication with a neighbor is recorded in a log stored in a file peerstats;
• statisticsclockstats- each message from the local clock driver is written to a log stored in a file clockstats;
• statsdir(catalogue_name_with_statistics)- sets the name of the directory where files with server statistics will be located;
• filegen - defines the algorithm for generating filenames, which consist of:
  • prefix- constant part of the file name, set either during compilation or by special configuration commands;
  • file name- added to the prefix without a slash, two dots are forbidden, can be changed with the file key;
  • suffix- is generated depending on typename;
• restrictnumeric-address- sets the access restriction: packets are sorted and masked, the source address is taken and compared sequentially, the flag is taken from the last successful comparison access:
  • no flags- give access;
  • ignore- ignore all packets;
  • noquery- ignore NTP 6 and 7 packets (request and state modification);
  • nomodify- ignore NTP 6 and 7 packets (state modification);
  • limited- serve only a limited number of clients from a given network;
  • nopeer- serve the host, but do not synchronize with it;
• clientlimitlimit- for the flag limited determines the maximum number of clients served (by default 3);

In total, we got ntpd-server, which is synchronized with the outside world, allows you to get the time for clients from the local network 192.168.0.1 with a mask of 255.255.255.0, and can also be synchronized with the local server (if you uncomment a few lines). We just need to set up the clients and learn how to monitor our server.

Monitoring the ntpd server and synchronization

When you are all set. NTP will keep the time in sync. This process can be observed using the NTP Query (ntpq) command:

Ntp-server:~# ntpq -p remote refid st t when poll reach delay offset jitter ============================== ==============================================-n3. time1.d6.hsd .PPS. 1 u 34 64 177 70.162 2.375 8.618 +ntp1.vniiftri.r .PPS. 1 u 33 64 177 43.479 -0.020 10.198 *ntp2.vniiftri.r .PPS. 1 u 6 64 177 43.616 -0.192 0.688 +ntp4.vniiftri.r .PPS. 1 u 4 64 177 43.623 0.440 0.546 -n1.time1.d6.hsd .PPS. 1 u 53 64 77 92.865 -11.358 38.346 -ns1.hsdn.org .GPS. 1 u 40 64 177 78.057 -3.292 35.083 -ntp3.vniiftri.r .PPS. 1 u 44 64 77 47.667 2.292 2.611 -scylla-l0.msk.c 192.43.244.18 2 u 62 64 77 41.565 -1.564 28.914

This command with the -p switch prints a list of time sources with their characteristics to the standard output (other command options in man ntpq). The meaning of each column is as follows:

The name of the remote NTP server. If you specify the -n switch, you will get server IP addresses instead of names.

Indicates where each server is currently getting the time from. It can be a hostname or something like .GPS. indicating the origin of the Global Positioning System.

Stratum (level) is a number from 1 to 16, indicating the accuracy of the server. One means maximum precision, 16 means the server is unavailable. Your level will be equal to the level of the least accurate remote server plus 1.

Interval between polls (in seconds). The value will change between the minimum and maximum polling rates. At the beginning, the interval will be small so that synchronization occurs quickly. After the clocks are synchronized, the interval begins to increase to reduce traffic and load on popular time servers.

An octal representation of an 8-bit array representing the results of the last eight attempts to connect to the server. The bit is set if the remote server has responded.

The amount of time (in seconds) it takes to get a response to a "what time is it?" query.

The most important field. Difference between local and remote server time. During synchronization, this value should decrease (closer to zero), indicating that the local machine's clock is getting more accurate.

Dispersion (Jitter) is a measure of statistical deviations from the offset value (offset field) over several successful request-response pairs. A smaller dispersion value is preferable because it allows for more accurate time synchronization.

Meaning of characters before server names

x - fake source according to the intersection algorithm;
. - excluded from the list of candidates due to the long distance;
- - removed from the list of candidates by the clustering algorithm;
+ - included in the final list of candidates;
# - selected for synchronization, but there are 6 best candidates;
* - selected for synchronization;
o - selected for synchronization, but PPS is used;
space - too much level, cycle or obvious error;

ntpd service"smart" and itself weeds out sources of time that are too out of the bounds of reason. Some time after starting, ntpd will choose the most reliable data sources and will synchronize with them. The list of reference NTP servers provided by us is regularly reviewed by the service.

You can check the possibility of synchronization locally on the server with the command:

Ntp-server:~# ntpdate -q localhost server 127.0.0.1, stratum 2, offset -0.000053, delay 0.02573 server::1, stratum 2, offset -0.000048, delay 0.02571 14 Jan 14:49:57 ntpdate: adjust time server ::1 offset -0.000048 sec

From the output of the command, it can be seen that our server has already become a stratum 2 level. It takes some time to reach this level. Perhaps in the first 10-15 minutes the server level will be higher.

The correct operation of the ntp server can also be judged by the logs of the ntpd daemon:

Ntp-server:~# cat /var/log/ntpstats/ntp 13 Jan 20:13:16 ntpd: Listening on interface #5 eth0, fe80::a00:27ff:fec1:8059#123 Enabled 13 Jan 20:13: 16 ntpd: Listening on interface #6 eth0, 192.168.0.8#123 Enabled 14 Jan 14:31:00 ntpd: synchronized to 62.117.76.142, stratum 1 14 Jan 14:31:10 ntpd: time reset +10.291312 s 14 Jan 14 :31:10 ntpd: kernel time sync status change 0001 14 Jan 14:34:31 ntpd: synchronized to 88.147.255.85, stratum 1 14 Jan 14:36:04 ntpd: synchronized to 62.117.76.141, stratum 1 14 Jan 15: 04:36 ntpd: synchronized to 62.117.76.142, stratum 1 14 Jan 15:10:58 ntpd: synchronized to 62.117.76.140, stratum 1 14 Jan 15:17:54 ntpd: no servers reachable 14 Jan 15:31:49 ntpd : synchronized to 62.117.76.140, stratum 1 14 Jan 15:32:14 ntpd: time reset +13.139105 s

Configuring netfilter (iptables) for NTP server

Having configured the server, it would be nice to protect it. We know that the server is running on port 123/udp, while requests are also sent from port 123/udp. After reading the article, and having read the practical ones, you can create network traffic filtering rules:

Ntp ~ # iptables-save # generic iptables rules for DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # allow LAN access to NTP server: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 123 -m conntrack - -ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # allow NTP server access to make outgoing requests -A OUTPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate NEW -j ACCEPT COMMIT

This is a typical example! To set iptables rules for your tasks and network configuration, you need to understand how netfilter works in Linux by reading the above articles.

Setting up client machines

To synchronize time on UNIX machines local network, it is advisable to use the ntpdate utility, running it several times a day, for example, every hour. To do this, you need to add the following line:

0 * * * * /usr/sbin/ntpdate -s

The -s switch directs the output of the command. If the client machines have a couple of extra megabytes of RAM, then you can start the ntpd daemon, just like on the server with the following config:

server restrict default ignore restrict noquery notrap restrict 127.0.0.1 nomodify notrap

I think everything is clear in this config: the time source (server) is a local ntpd server, deny access to everyone, allow only the local ntpd server.

Also, on clients, you must correctly specify in which format to store the time and select the correct time zone, .

To configure the Windows NTP client, you need to run the following commands in the console:

C:\>nettime /setsntp: The command completed successfully. C:\>net stop w32time The Windows Time service is stopping. The Windows Time service was stopped successfully. C:\>net start w32time The Windows Time service is starting. The Windows Time service started successfully. C:\>net time /querysntp The current SNTP value is: The command completed successfully.

Conclusion

Well, like everything! The volume of the article turned out to be enormous ... I didn’t even expect it myself. Let me summarize a little. In this article, I hope it became clear to us what is and how the NTP server works. We learned how to configure the server and clients on UNIX and Windows machines. In a few words, the structure of time synchronization in the local network is as follows: There are 1.2 or more exact time servers in the local network, they synchronize their time with external sources in the global network. Server and client settings are based on /etc/ntp.conf (main ntpd daemon configuration file), /etc/localtime (current timezone file), /etc/sysconfig/ntp (for RH) and /etc/default /ntp (for Deb) - daemon startup parameter files. For the local ntp server, external servers are specified in the configuration file to receive time and access is allowed for these servers with the restrict parameter, as well as for computers on the local network, for clients the time source is specified - local servers on the local network, and access is also denied for all , except for the time source in the local network. All. Thank you all for your attention! I will be glad to comments!

• (article archive) describes how to connect GPS to the server to organize your Stratum1 level exact time server.
• describes how to configure authorization on the ntp server.