Is port 123 (NTP) exposed to the internet?

What’s listening on 123

NTP (RFC 5905) keeps a device’s clock in sync with a reference time source, and IANA assigns UDP port 123 to it. Routers, NAS boxes, cameras and plenty of general-purpose servers run an NTP daemon so their own logs and certificates have an accurate clock — and depending on configuration, that same daemon can also answer time queries from anyone who can reach it, not just the device’s own clients.

Why an open NTP port is a risk, not just noise

An exposed NTP server’s main risk isn’t someone reading your clock — it’s amplification. An attacker sends a small UDP query with the victim’s IP address spoofed as the source; the server’s reply goes to the spoofed address instead of the real sender, and certain NTP query types historically returned a reply many times larger than the request, turning a handful of small packets into a flood aimed at someone else entirely. Current ntpd releases disable the specific monitoring command most responsible for the largest amplification factor by default, but an old or unpatched install can still have it enabled, and even an ordinary time query response contributes some amplification on a server configured to answer the whole internet rather than a defined set of peers.

How to check it today

AdminKit’s open ports check is a live tool today, but it currently only probes a fixed list of TCP ports — UDP services like NTP on 123 aren’t covered yet, so confirm this one manually. From a machine outside your network (testing from inside will give you the wrong answer), check your own public IP (see My IP for your current address):

nc -u -vz -w 3 203.0.113.5 123

UDP has no handshake, so a lack of response doesn’t always mean the port is closed — for a clearer signal, query it as an actual NTP client from outside your network, for example ntpdate -q 203.0.113.5 or ntpq -c rv 203.0.113.5, and see whether it returns a real time/status reply.

How to fix it

If your device doesn’t need to serve time to other networks, don’t expose NTP to the internet at all — most home routers and IoT devices only need to query outbound to a time source, never accept inbound queries. If you deliberately run an NTP server for others, restrict which clients it answers using your NTP software’s access controls (ntpd’s restrict directive, or the equivalent in chrony), keep the software patched, and disable any legacy monitoring/query commands your version still ships with. Open resolvers are the DNS equivalent of this same misconfiguration — see is your DNS resolver an open resolver for how the same spoofed-source amplification pattern plays out there.

Other exposure checks worth running

If you’re reviewing exposure more broadly: is your DNS resolver an open resolver covers the DNS side of the same amplification risk, how to publish and test MTA-STS covers mail transport security, and how to find a dangling CNAME covers a different, DNS-hygiene kind of exposure. All four sit in AdminKit’s machine protocols and DNS clusters alongside the live tools and glossary terms that back them.

Defensive use only

Every check this page describes is for assets you own or are explicitly authorized to test. Never query, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.