Having precise time on your entire system is just as important as having a solid network security strategy. Having specific time is one of the primary components of good systems management and is at the forefront of organization and security. Especially in the management of distributed applications, virtual services, and even distributed security tools, precise time is required.
If you are running a network or server, you need to keep track of which client goes where and when. However, if the time of the device you keep the records on is wrong, your records will not matter.
Even when you receive an attack from the external network, you need to know where and when the attack occurred. Similarly, if you run a server, you should know who connects to your server and when. Therefore, the servers’ time and the server where you keep the network logs must be correct.
Once your system is appropriately set up, NTP ensures that the time is right by making minor adjustments to avoid affecting running applications.
See Also: PCI DSS Logging Requirements
The Network Time Protocol exact time can be derived from the hardware clock based on the atoms’ electron frequencies. There are also methods based on GPS (Global Positioning System). Electron frequencies are more precise, but GPS-based systems are also pretty good.
Atomic clocks require very specialized and expensive equipment, but their developers connect them to computers running NTP and ultimately allow us to use them for free. This is how we synchronize our system.
To create a simple sync architecture, you will need:
- Direct or indirect (via firewall) connection to the internet.
- Choose NTP servers. You can use the public server pool.ntp.org or either of the NTP website’s tier 2 public time servers. If you do not have Internet access, your WAN administrator can provide you with some internal addresses.
- Have an NTP package for all systems you want to synchronize. You can find it on your favorite Linux distribution as RPM or search rpmfind.net.
What is Network Time Protocol (NTP)?
NTP is a sequential time distribution system with redundant capacity. Algorithms on the network as well as on the target machine measure the latency. Using these techniques can synchronize the clocks up to split seconds. NTP settings are made either from the /etc/NTP.conf or the /etc/xntp.conf file, depending on which distribution is used.
There are two server names in the NTP.conf file with the most basic configurations. One is the server’s name from which the clock is requested to be set, and the other is a fake IP address.
The fake IP address is used in network problems or if the NTP server is down / crashes. The NTP application will adjust the system clock again when the remote NTP server is up. The first of these two servers act as the primary server, and the second is for backup purposes. Also, the location of this target file must be specified. Over time, NTP will “learn” the system clock’s error rate and adjust itself accordingly.
The NTP configuration file /ect/ntp.conf contains the following information that the xntpd “daemon” uses at startup:
- List of possible synchronization servers
- According to which criteria the synchronization server will be selected
- The server’s limitations when connecting to the host machine
- Whether NTP packets will be broadcast on the network
- Whether to listen to broadcast (broadcast) NTP packets
- Whether to listen to multicast NTP packets or not
- Driftfile file location
- Whether to display NTP connections or not
- Whether the host will be allowed to renew the configuration or not
The configuration file can be written in the desired format. Lines starting with # are comment lines. In client mode, the server checks other servers to get the current time. After all, servers have been checked, and the host chooses which server to synchronize to. To configure the server in client mode, there must be a server sentence that contains the name and IP address of the servers to be controlled in NTP configuration.
How Does NTP Work?
To set the time of your Server or Clients, you should ask someone correct. For this purpose, you can find many public NTP server addresses on the internet. Some NTP server addresses are as follows:
- us.pool.ntp.org
- ntp-b.nist.gov
- ntp-wwv.nist.gov
- ntp-c.colorado.edu
- ntp-d.nist.gov
Your clients must have NTP client software to fix your clock. The software can be pre-installed on your operating system itself, or you can install it on your computer as third-party software.
Communication with time servers UDP (Universal Datagram Protocol), transmission via port 123 is required. Therefore, this protocol and port must be open in your firewall.
What are the NTP Modes of Operation?
The system can be synchronized with other servers using the xntpd “daemon” and the following methods:
- Client mode
- Broadcast or multicast client mode
- Symmetrical active mode
Client mode: In this mode, the server checks to get the current time from other servers. Once all servers have been checked, the local host chooses which server to synchronize with. To configure the server in client mode, there must be a server sentence with its name and IP address to check-in NTP configuration.
Broadcast and multicast modes: In this mode, the server does not poll; it listens for multicast and multicast NTP packets on the local network.
To configure a server in one of these modes, the NTP configuration file must contain the “broadcast yes” or “multicast yes” clause. Local time servers must be configured with the multicast configuration clause, and the multicast mode must be configured with the multicast configuration clause. The client manager can be used to configure a server as an NTP client.
What are the PCI DSS requirements for NTP?
When using multiple devices without time synchronization, each source will think the correct time is different. If you try to compare logs between sources, none of the timestamps will be sorted. Suppose data is collected on a log server or security information event manager. In that case, events appear jumbled, and analytics and correlation engines cannot process data for unusual behavior or consensus signs.
This becomes a security nightmare and a formidable challenge for any cyber forensics investigation. Some knowledgeable threat actors may even tamper with the NTP, knowing that it will complicate forensic log analysis and make it harder to reveal their actions and traces in data noise.
Adequate security starts with the right timing. Good timing means that all resources in an environment, from cameras to servers, all have the right time. The most common method to set the correct time is to use an NTP server. The point is simple, all devices need to have the same clock, and they need to reset their clocks periodically so that all daily operational data, alerts, and runtime have the proper time.
Requirements in PCI DSS for NTP are as follows:
- PCI DSS Requirement 10.4: Using time synchronization technology, synchronize all critical system clocks and times and ensure the following are applied to obtain, distribute and store time.
- PCI DSS Requirement 10.4.1: Critical systems should have accurate and consistent time.
- PCI DSS Requirement 10.4.2: Protect time data.
- PCI DSS Requirement 10.4.3: Time settings should be taken from industry-accepted time sources.
PCI Requirement 10.4.3 requires time settings to be obtained from industry-accepted time sources to ensure that vital device clocks and time are consistent and accurate. Reliable time sources can be from the US Navy, NASA, NIST, Google, or other organizations that use GPS to synchronize.
PCI DSS also optionally states that time updates can be encrypted with a symmetric key. Access control lists that specify IP addresses should be created to prevent unauthorized use of client machines to be provided with time updates.
The reason NTP configuration is essential is that the time settings must be the same on all devices. Time settings should be smooth and synchronized. This is necessary to promptly and adequately see the logs on the router or any network device or the log records on a server.
The use of authentication mechanisms in the Network Time Protocol (NTP) is critical in preventing an attacker from tampering with time information.
The following settings are made for the authentication of synchronization requests from NTP shared computers:
First, a group of keys must be created to be used in authentication requests.
The following lines should be added to the /etc/init/NTP.conf file for each server that we want to configure authentication definition for:
authenticate yes
keys /etc/init/NTP.keys
The following line is added to the /etc/NTP.conf file:
trusted key ID1 ID2 … IDn
This line is the list of keys to be used for authentication.
For ntpd to reread the configuration file, the following must be done. The changes made in this way will take effect:
- After the process id is found from the ps command processes, the service is closed with the kill command and then restarted.
- If there is a new key waiting to be allowed in the running configuration file, ntpd is run, and the readkeys command is run.
driftfile:
The driftfile (heap file) is in /etc/NTP.conf, and this tells ntpd, which indicates where the clock stack, i.e., the frequency error of the system clock, can be found. If the file exists initially, it is read, and its value initializes the value of the frequency error of ntpd. It is updated hourly by ntpd. A stack file must be a must, as it has been calculated to have a good connection to the NTP server.
Restriction:
Restrict option can be used in NTP to provide better control and keep security.
Example of Restriction in NTP:
# By default, do not trust and do not allow modifications
restrict default notrust nomodify
# These hosts are trusted for time, but no modifications allowed
restrict 172.16.0.0 mask 255.255.0.0 nomodify
restrict 128.115.14.97 nomodify
restrict 16.1.0.22 nomodify
# These local addresses are unrestricted
restrict 172.16.246.16
restrict 127.0.0.1
Before using the restriction option, it is highly recommended to have a properly working NTP service. By accident, it can restrict adaptation and cause too long and unnecessary time to determine where the error is. There are several tools to check if the NTP service is doing its job properly. The ntpq -p command will show the system’s current time status.
How is NTP Security Provided?
Network Time Protocol (NTP) is a network protocol used for clock synchronization of networked computing devices. Despite being one of the oldest network protocols dating back to 1985, it remains the cornerstone of modern computer synchronization. It is crucial to ensuring the proper functioning and security of computing devices.
NTP is intended to synchronize within a few milliseconds Coordinated Universal Time (UTC) by querying a host server for the current time and then resetting its local time to match. NTP uses specific algorithms to accurately coordinate the time between hosting time servers and adjusting local time calibrations with variables such as network latency.
As a solution, NTP is most commonly a client-server model. Still, it can also be implemented using peer-to-peer (p2P) technology and even broadcast and multicast to allow all computing devices to operate simultaneously. If any device is out of sync, environments can face operational difficulties and pose unnecessary cybersecurity risks.
Below you can find best practices for configuring your own NTP server and requesting a generic NTP server.
Use Public NTP for external hosts. Suppose an organization is building capabilities, services, or other integrated platforms intended to be deployed outside of the organization. In that case, network administrators may consider requesting a public NTP server from the pool mentioned above of available servers.
It is important to remember that most public NTP servers set the rules for joining. If multiple devices within an organization used NTP, it would make sense to set it up to synchronize their hierarchy rather than compete for access to public servers.
Configure your network’s own internal NTP hierarchical service. For less than the cost of a standard server, Stratum 1 or Stratum 0 NTP devices can be purchased for internal use. It is also possible to set up a low-cost private NTP server.
If you decide to configure your own, consider the following best practices:
- Standardize to UTC. Within an organization, standardize all systems to coordinate universal time (UTC). Standardization concerning UTC simplifies the daily relationship within the organization and with external parties, regardless of which time zone the synchronized device is located.
- Ensure the security of network time service. Restrict the commands that can be used on layer servers. Do not allow general inquiries of tier servers. Allow only known networks or hosts to communicate with their respective layer servers.
- Consider the business need for cryptography. Many administrators try to secure their networks with encrypted communication and encrypted authentication. Although there are cryptographic services associated with NTP to secure NTP communications, encryption creates more resources for issues such as requiring key management and requires a higher computational overhead.
- Ideally, it works well to have three or more Stratum 0 or Stratum 1 servers and use these servers as the primary administrator. Having two NTP servers makes it challenging to know which one is correct. The two Stratum 0 servers will provide a more accurate timestamp as they use a time source that is considered firm.
The presence of three or more time sources will allow the network to maintain the correct time even if one of the primary hosts fails. Ideally, NTP servers are placed in three geographically different locations. This primary group of masters will be the source of time for the venture.
They are considered to be secret masters as they will only serve secondary tier servers. This configuration allows these servers to provide time to side-by-side secondary hosts that help an organization.
Primary administrators remain private and are only accessed by the NTP infrastructure that provides services elsewhere. This supply chain should allow you to give the right time throughout your organization and have multiple sources validating an accurate time source.
Additional Stratum 2 or Stratum 3 servers can be added for locations with more devices whose time needs to be synchronized, allowing them to rely on secondary hosts and each other to serve a larger group of NTPs.
By installing an internal NTP service on the latest revision of stable code and standardizing its use.
The sequence of events in a consensus becomes more comfortable to define because logs can now be recording systems. For law enforcement and other investigative agencies, correct NTP services can be very constructive in assessing evidence and sequencing a chain of events.
What is Network Time Security (NTS), and What are the Differences with NTP?
The use of authentication mechanisms in the Network Time Protocol (NTP) is needed to prevent an attacker from tampering with time information.
Symmetric Key-based method and Autokey approach are authentication mechanisms that have existed for many years. However, both have serious drawbacks, so they are rarely used to secure NTP connections.
After years of development, a new standard, Network Time Security (NTS), has been released to solve the problems of existing mechanisms and offer a real alternative.
- NTS is a modern authentication scheme for NTP that addresses many of the flaws in previous security methods.
- Uses a separate TLS connection for initial parameter and key exchange; the next NTP connection is then secured with NTS extension fields.
- The functionality of NTP remains untouched, and time data is not encrypted by NTS but verified.
To protect the time information, NTP currently offers two authentication modes in the current version 4.
Unfortunately, its inability to scale is the old and still secure symmetric key approach, which has a significant disadvantage. Using preshared keys always requires manual configuration of the client, depending on the server. Therefore, it is not possible to add new clients, and changing the keys on the server side will cause adjustments to all clients.
The Autokey method solved the above problems, which showed severe other design flaws after analysis in 2012. With this method, attackers can disconnect a secure connection in a matter of seconds and change the time data in NTP packets. Therefore, built-in solutions in NTP do not provide a satisfactory protection mechanism.
NTP alternatives over TLS or tlsdate; on the other hand, TCP-based connections and tunneling concepts increase latency and NTP packet uptime. Even though these solutions offer higher security, this is only accompanied by loss of synchronization accuracy and larger time fluctuations. The same is true for tlsdate, which no longer works with the current TLS version 1.3.
The absence of security mechanisms in NTP led to the development of the Autokey v2 specification in 2012. Due to the previous version’s lousy reputation and fundamentally different communication structure, Autokey v2 was soon renamed NTS.
The NTS protocol is a time protocol security extension that currently focuses on NTP in unicast mode. It protects against packet manipulation with strong cryptographic defense, prevents monitoring, scales, is resilient against packet loss, and reduces accuracy due to the security process.
NTS uses NTP Extension Field (EF) to preserve time information, where parameter and status information is also transferred between the client and the time server. The safe-time protocol remains untouched, so it is also possible to use NTS in other protocols such as the Precision Time Protocol (PTP). This also implies that NTS does not encrypt the time data, but rather verifies it.
NTS currently consists of sub-protocols that constitute two communication phases. The first stage occurs at the start of the communication and is used for parameter negotiation and the exchange of key information in the form of cookies.
In the second step, the NTS-secure NTP connection occurs. For this purpose, the client uses cookies provided by the server that it adds to NTP requests. The client remains at this stage until the connection is disconnected or if cookies are no longer available due to repeated packet loss. In this case, the first stage is executed again.
For detailed information, you can visit the ntp.org website.
