[Ntp] Re: NTP DDoS Attacks (Was: Re: NTPv5 Requirements vs. NTPv5 Spec)

[Dave Hart <[e-mail]>]

On Thu, Jun 26, 2025 at 1:33 AM Richard Laager <[e-mail]> wrote:

> On 2025-06-25 18:53, Dave Hart wrote:
>
>
> From the cloudflare report [1], the megaflood they defended against had
> ~14% of 0.004% classified as NTP reflection attack.  Not exactly the
> low-hanging fruit.
>
> For *this particular* attack. Attack profiles can vary quite a lot. I've
> had large attacks where the vast majority or even ~100% is NTP
> amplification traffic. I've also had (even larger) attacks where ~0% was
> NTP traffic. Additionally, this is a dynamic "game" (in roughly the game
> theory sense) in the sense that your defenses shape the attackers behavior.
>
I don't doubt there have been massive NTP reflection attacks over the last
dozen years.  I do question how many of those involved mode 6 and how many
were recent.

> What I'm asking is to not advocate filtering other people's use of NTP
> mode 6 as inherently useless or dangerous as it crosses a transit network
> they have no control over.
>
> This essentially fairly characterizes my position. My position is that
> it's at least somewhat dangerous and largely useless to legitimate users,
> so together, those factors mean the cost-benefit of blocking it makes sense.
>
If you count me out of legitimate users, sure.  Given the widespread
configuration of ntpd to reject all mode 6 queries from off-host, I'll
admit I'm part of a relatively small minority, but transit networks should
engage in protocol-specifc blocking only where the benefit is
overwhelming.  I don't think you've made a convincing argument that's so
for mode 6 queries, and I think a lot of the confusion comes from
mitigation instructions for older ntpd, where "restrict noquery" was the
easiest way to disable monlist, causing people to assume all mode 6 and
mode 7 queries were equally dangerous.

> Are you sure that mode 6 is not an issue?
>
> I vaguely remember it being a problem (and that's why I blocked both 6 and
> 7), but I don't have any captures to prove it either way.
>
> If I Google it, there are various discussions about mode 6 being an
> amplification vector, including some technical details. For example, here
> are two random results:
>
> https://www.csk.gov.in/csksa/csksa_01.html says "ntpq -c rv IP" will
> result in amplification.
>
>
> https://community.cisco.com/t5/switching/97861-network-time-protocol-ntp-mode-6-scanner-ios-12-2-55-se10/td-p/3751556
> talks about mode 6 being a separate vulnerability from mode 7.
>
I didn't claim there was no amplification possible with mode 6 queries.  I
do suspect the amplification factors possible with mode 6 make it
relatively uninteresting compared to, for example, traditional DNS over UDP
53.  There are huge numbers of well-connected public DNS recursive
resolvers to which to spread the spoofed queries around to help evade
detection.  Cloudflare documented a 50x amplification attack [2] querying
"any isc.org" which no longer offers such a large factor, but there a many
other domains -- I'm guessing it's not terribly hard to figure out similar
or greater UDP DNS amplification factors.  For the same reason it would be
wrong for ISPs to block UDP 53, it's wrong to block mode 6 lacking evidence
it's not just suffering from confusion with mode 7.  Undoubtedly there are
other UDP services that offer amplification as well.

> I just tested an `ntpq -c rv IP` against a server of mine (after changing
> the config). Including Ethernet headers, I sent one 54 byte frame and I got
> back a 522 byte frame and a 90 byte frame. That's 11.3x amplification.
>
I note that according to Cloudflare [1] monlist offered 200x
amplification.  Personally, I'd be fine with changing ntpd and ntpq to
require queries be close to as large as responses, which in practice might
mean every query is padded to 465 bytes, for example.  I believe ntpsec has
taken this approach.  I've suggested as much but the idea was vetoed.  It
does also feel wasteful of resources, but amplification is a real issue.
Another possible approach is to change ntpd/ntpq so that all mode 6 queries
protect against spoofing using a 3-way-handhake-like nonce to ensure
responses actually go to the requester not some innocent bystander.  That
would be a breaking change, meaning old ntpq would be unable to query any
new ntpd, but it may be the best path forward.  However, given the
blowback, perhaps a wiser approach would be to make the nonce-requiring
variants actually different rather than just making a breaking change to
the existing stuff -- so that operators and defaults might choose to allow
nonced queries while rejecting the original mode 6 unauthenticated,
non-nonced queries.

> I have my hand in NTP servers spread across a huge geography, and I find
> it useful to be able to query them, particularly the unauthenticated peers
> billboard (ntpq -p or as I often use, ntpq -clpe for corner-case reasons)
> and readvar/rv, sysstats as well as for the authenticated ifstats and and
> reslist ntpq queries.
>
> Personally, I would use SSH to run ntpq on the NTP server. And I would
> recommend the same to you/others.
>
> Using SSH, or a VPN, or remote desktop, or Anydesk or similar, is quite
heavyweight compared to using ntpq.  For many situations, ssh might be
fine, but for scripting, particularly across multiple servers, one ssh
setup/teardown per ntpq query makes the overall operation orders of
magnitude slower.  I'm not suggesting you change your practice, just that
you not advocate that network operators impose what amounts to firewalling
that people transiting those networks can't opt out of.

> I certainly would encourage you to add "nomrulist" to Debian's "restrict
> default" line, despite it having no effect combined with "noquery".  It
> would raise awareness and provide a backstop for those who find reason for
> removing "noquery" as well as an example they might use in crafting more
> specific subnet-/host-specific restrictions.
>
> I've filed a wishlist bug report: https://bugs.debian.org/1108327
>
> Debian is currently in a hard freeze, so I can't make that change now.
>
Thank you!

[1] https://www.cloudflare.com/learning/ddos/ntp-amplification-ddos-attack/
[2] https://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack/

Cheers,
Dave Hart