Howto deal with bad NTP-Client / Attacker?

[ask]

@davehart

My understanding is special-casing the response to pool monitors is specifically frowned upon because the monitors are supposed to reflect the experience of J. Random User, many of which are stuck behind NAT on IPv4-only ISPs, and more will be as time progresses and the price of IPv4 addresses continues to rise and large ISPs are more likely to use CGNAT.

Yes, agreed.

The monitors do a configurable number of queries to each NTP server. It helps get better results (picking the “best” answer) and it’s also to make sure clients aren’t (very) unreasonably rate limited (a rate limit answer to any of the queries will “fail” the server).

It’s not used yet, but one of the changes in progress (with the validation system) is for the system to decide a “netspeed” up to the configured netspeed to have some more nuance to partially “take out” a server if it’s behaving weird; so for example the monitor could once in a while send 15 queries (over ~30 seconds) instead of 3 or 4 to encourage operators to configure their systems to allow that to work.

@ebahapo

As I said above, my first recommendation, which I myself follow, is to add only an IPv6 server to the pool, which avoids most bad and buggy actors. IPv4 is just too much of a headache for a small pool server operator.

That’s totally reasonable! The NTP Pool Project generally don’t run NTP services (ironically, I guess!) to focus on the other services that makes the system work; but for testing I do have a few IPv6 IPs in the system…