Ports

Port 123: NTP

Time synchronization. Small packets, big impact on security and reliability.

Where you will see it: You will see this in scans, firewall rules, vulnerability reports, and service configs. Treat open ports as exposure points and verify the service is expected, hardened, and restricted.

What it is

UDP port 123 is used by NTP, the time synchronization protocol. A port is a transport layer number used together with an IP address and a protocol such as TCP or UDP to direct traffic to the correct service on a host.

A server process binds a socket to a port and listens, while a client typically chooses an ephemeral source port for outbound connections. The combination of source and destination IP addresses, source and destination ports, and the transport protocol uniquely identifies a flow so the operating system can keep many conversations separate.

Firewalls, NAT, and scanners talk about ports because the destination port is the stable rendezvous point that exposes a service to the network. NTP is typically UDP because the messages are small and periodic.

A client sends a request from an ephemeral source port to a server on destination port 123, and the server replies with timestamps that let the client estimate clock offset and network delay. The client then adjusts its clock gradually and repeats the process, sometimes using multiple servers to improve accuracy and resilience.

Time is a security dependency: certificates, logs, Kerberos, and incident timelines all assume clocks are close to reality. Exposed or misconfigured NTP can also be abused for reflection and amplification attacks, and attackers may try to shift time to break validation or confuse log analysis, which is why access controls and authenticated modes are relevant.

How it works in broad strokes

  1. Client sends a time request to an NTP server, usually with a small UDP packet.
  2. Server replies with timestamps that let the client estimate offset and network delay.
  3. Client disciplines its clock gradually, then repeats periodically and may consult multiple servers.

Concrete example

During an investigation you see log timestamps out of order. The root cause is a failed NTP sync on one server, which is why time health checks are as important as CPU or disk checks.

Why it matters

Time drift causes confusing logs and broken security. Kerberos, TLS, and many API auth schemes assume clocks are close. NTP is also abused in reflection attacks, so exposing open NTP to the internet can create risk.

Security angle

  • Restrict who can query your NTP servers and prefer authenticated NTP or secure time sources where supported.
  • Use multiple upstream sources and monitor offset and stratum health.
  • Validate time sync for critical auth systems such as domain controllers.

Common pitfalls

  • Allowing public NTP servers without rate limiting, enabling amplification abuse.
  • Pointing many clients to a single fragile server, creating a single point of failure.
  • Assuming time is correct even when virtual machines suspend or networks partition.