Port 123 – NTP (Network Time Protocol)

Port 123 is the default port for NTP (Network Time Protocol), the service that keeps clocks in sync across a network. It runs over UDP, not TCP — a client sends a small timestamp query to UDP 123 and the server answers with its own timestamps, and that single exchange is enough to discipline the client’s clock to within milliseconds. Almost every server, router, firewall, and domain controller talks to something on port 123, which is exactly why an exposed one is worth a look: the same protocol that syncs time has been turned into one of the internet’s most effective DDoS amplifiers.

Why It’s Open

Nothing works for long without accurate time. Kerberos rejects tickets once the clock skew passes five minutes, TLS certificate validation depends on the clock being right, TOTP two-factor codes drift out of sync, and log correlation across hosts is meaningless if their timestamps don’t agree. So NTP is on almost everything: Linux boxes running chronyd (the default on modern RHEL and Ubuntu) or legacy ntpd, Windows domain controllers running the w32time service, Cisco and Juniper network gear, firewalls, hypervisors, and embedded appliances that quietly reach out to pool.ntp.org.

Most of that traffic is outbound — a host querying an upstream server. The problem is the servers that also listen on UDP 123 and answer anyone. Public time servers are supposed to; the internal ntpd on a forgotten box facing the internet is not, and that’s where reflection and information-disclosure attacks start. If you’re mapping a host’s time and directory stack, port 123 usually sits alongside Kerberos on port 88 and LDAP on port 389 on a domain controller.

Common Risks

• Amplification / reflection DDoS. A spoofed request to a misconfigured NTP server produces a response many times larger, aimed at the victim whose address was forged. The classic vector is the monlist command (mode 7), where a ~230-byte query returns up to the last 600 client addresses — a response up to 206× the request. US-CERT measured NTP amplification factors as high as 556×, which puts it among the worst reflectors on the internet.
• Information disclosure. Mode 6 (ntpq) and mode 7 (ntpdc) control queries leak the ntpd version, host OS, uptime, and the list of upstream peers and internal IPs — a clean fingerprint of the box and a map of the network behind it.
• Time shifting and spoofing. An attacker who can inject or forge NTP responses can move a client’s clock. Push it forward and cached credentials or CRLs expire and certificates roll over; push it back and expired certificates validate again and Kerberos replay windows reopen. Off-path attacks like the Crypto-NAK bypass (CVE-2015-7871) let this happen without a man-in-the-middle position.
• Exploitable legacy daemons. Old ntpd builds carry remote stack overflows (CVE-2014-9295) that run code as the NTP process, plus a run of crash bugs reachable from a single crafted packet.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and check for monlist

nmap -sU -p 123 --script=ntp-info,ntp-monlist <target>

Query the clock with the native client

ntpdate -q <target>

Read internal variables (mode 6 — version, OS, peers)

ntpq -c rv <target>
ntpq -p <target>

Check the legacy monlist command (mode 7)

ntpdc -n -c monlist <target>

If the server returns a list of recent clients, it’s amplification-capable — flag it.

Metasploit modules

msfconsole -q
use auxiliary/scanner/ntp/ntp_monlist
set RHOSTS <target>
run

use auxiliary/scanner/ntp/ntp_readvar
set RHOSTS <target>
run

Record every server that answers a monlist or readvar query — an open reflector is a finding in its own right, even before any CVE. Keep those results somewhere they survive the engagement, not a scratch terminal, so they land in the final pentest report.

What to Look For

Known CVEs and Exploits

• CVE-2013-5211 — The monlist amplification bug in ntpd before 4.2.7p26. A forged REQ_MON_GETLIST request turns the server into a DDoS reflector. This is the flaw behind the 2014 amplification wave; see CISA’s advisory.
• CVE-2015-7871 — “NAK to the future.” A crafted Crypto-NAK packet bypasses NTP authentication in 4.2.x before 4.2.8p4, letting an off-path attacker force a client to sync with a hostile time source. CVSS 9.8.
• CVE-2014-9295 — Multiple stack buffer overflows in ntpd before 4.2.8 (crypto_recv, ctl_putdata, configure) allow remote code execution as the NTP user via a single crafted packet. Found by the Google Security Team; tracked as CERT VU#852879.
• CVE-2016-7434 — A NULL-pointer dereference in read_mru_list crashes ntpd before 4.2.8p9 from an unauthenticated mrulist query — a quick, remote denial of service.

Mitigation

• Disable monlist and control queries. Add restrict lines that block mode 6/7 access, or upgrade to a build where monlist is gone:

restrict default kod nomodify notrap nopeer noquery limited
restrict -6 default kod nomodify notrap nopeer noquery limited
restrict 127.0.0.1
restrict ::1

• Prefer chrony over ntpd. Chrony doesn’t implement the legacy mode 7 interface at all, so monlist-style amplification simply isn’t available. It’s the default on current RHEL and Ubuntu for a reason.
• Firewall UDP 123. Block inbound from the internet unless the host is a deliberate public time server. Internal clients only need outbound 123 to their upstream — they don’t need to answer the world.
• Authenticate time. Deploy NTS (Network Time Security, RFC 8915) with chrony, or symmetric keys, so a spoofed response can’t quietly move the clock.
• Filter spoofed traffic (BCP 38). Reflection only works because source addresses are forged; anti-spoofing at the network edge kills the amplification vector for everyone downstream. This is the same defense that matters for DNS on port 53 and SSDP on port 1900, the other big UDP reflectors.
• Patch the daemon. Keep ntpd at 4.2.8p15 or later, or move to chrony, to close the RCE and DoS CVEs above.

Real-World Example

In February 2014, Cloudflare absorbed an NTP reflection attack that peaked just short of 400 Gbps — the largest DDoS on record at the time. The attacker didn’t need a big botnet: they bounced spoofed monlist queries off 4,529 misconfigured NTP servers spread across 1,298 networks, each averaging 87 Mbps toward the victim. For comparison, the 2013 Spamhaus attack needed roughly 30,000 open DNS resolvers to reach 300 Gbps; NTP got a third more firepower from a seventh as many servers. The reason so many servers were usable was mundane — default ntpd configs left monlist (CVE-2013-5211) enabled, and nobody had turned it off.

FAQ

Is port 123 dangerous?

Port 123 itself is just NTP’s listener, and outbound time sync is harmless. The risk is a server that answers queries from the internet: a misconfigured one becomes a DDoS amplifier through monlist, leaks its version and internal peers through mode 6/7 queries, and — if it’s an old ntpd — may be exploitable for code execution. Lock inbound UDP 123 down and the danger largely goes away.

Does NTP use TCP or UDP?

NTP uses UDP on port 123. There’s no standard TCP-based NTP service, so if you see connections to TCP 123 they’re almost always misconfigured clients, load balancers, or scanners probing the port — not real time sync. The lightweight, connectionless UDP exchange is the whole point: one request, one response, no handshake.

Why does NTP need bi-directional access to UDP 123?

Classic ntpd in client mode sends its query from source port 123 to destination port 123, so a stateless firewall needs a rule allowing UDP 123 in both directions for the reply to get back. Modern clients like chrony use a random high source port, so a normal outbound-UDP rule is enough — which is why the “bi-directional 123” requirement mostly shows up on older ntpd setups.

How do I secure or close port 123?

Add restrict ... noquery lines to disable monlist and control queries (or switch to chrony, which doesn’t support them), firewall inbound UDP 123 from the internet, and enable NTS or symmetric-key authentication so responses can’t be spoofed. If a host doesn’t need to serve time, it only needs outbound 123 — block inbound entirely and rescan to confirm.

TL;DR

• Service: NTP (Network Time Protocol), over UDP
• Default port: 123/UDP (there is no standard TCP NTP)
• Biggest risk: monlist amplification for reflection DDoS, plus info disclosure and clock-spoofing
• Mitigation: disable monlist/control queries or run chrony, firewall inbound 123, and authenticate time with NTS