Please note that nobody can query the server except from the monitoring IP address.
With this configuration I can prove that the owner of the server had the intention the server to be added to the pool.
@ask: You can verify now my servers with ntpq -p -n 156.106.214.48 and ntpq -p -n 156.106.214.52 from the monitoring station did I had the intention to add them to the pool?
I don’t like the idea of allowing anyone not in my LAN querying my server status. And nomodify is also unnecessary when using noquery. I would like to suggest the following:
By deliberately blocking NTPv3 packets while allowing NTPv4 packets (not a default config from any distro), the admin can show his willingness to follow the proposed pool setup guideline. However I don’t know if it is possible for other NTP software like chrony to behave like this…
Enabling ntpq access for the monitoring node would make it vulnerable to amplification attacks.
A simple protocol based on TCP would probably be safer and more portable. The server could be required to fetch a URL from manage.ntppool.org, or it could be required to respond on a TCP port using a command like
echo hello pool | nc -l -p 12312
However, this would be difficult to do on HW-based NTP servers that don’t have an OS or full TCP/IP stack. Maybe a firewall in front of the server could temporarily redirect the port or translate the address, but I’m not sure how many people would be willing to do deal with that.
That is right. But only towards the verification monitoring station(s). That is greatly reduced surface attack relative to the traditional amplification attack, which is most of the case the whole Internet. In addition too, no need the verification configuration to stay in place after the verification succeeded, it is possible to clean-up.
I do not like that idea. The NTP service administrator may not have the necessary privilege to make arbitrary interaction with the network stack of the server. For example when the NTP service is running in a container. I belive that the verification process should be implemented within the realm of NTP protocol itself.
With the excellent idea of using the “version” restriction of @alica, I may go even further.
There could be a dedicated time server, let’s call it server-ip[46]-peer-verify.ntppool.org .
Every NTP service administrator supposed to add the a statement like:
peer server-ip4-peer-verify.ntppool.org noselect minpoll 13 maxpoll 13
peer server-ip6-peer-verify.ntppool.org noselect minpoll 13 maxpoll 13
into the configuration when (s)he intend to add the new server into the NTP pool. The first or both the two statement, depending on having IPv4 or dual-stack configuration.
Then, it is sufficient to monitor the NTP traffic towards this verification monitoring server to know the intention of a given NTP server (identified by its IP) to be part of the NTP pool, or not.
The server-ip[46]-peer-verify server may not run NTP on it, or run with low stratum, high stratum, doesn’t matter. Referring with a name to it, its IPv4 and IPv6 addresses change management is easy, if required.
Sending NTP requests to the monitoring node won’t work either. The source address can be easily spoofed. Also, some servers don’t have a client at all, so there is the same problem as with the other proposals.
That is true. May be then the verification server must run an NTP service with all candidate pool servers configured as peers, and then check for appropriate peer interaction to take place?
My proposal does not require client. It is a just server configuration.
We may not want to restrict ourselves with only one verification method. For those who can easily run a web server on the NTP server (unlike me) that could be a method.
If it verified that the symmetric association has valid packets exchanged in both directions, that would work for verification of the server. However, it would allow an off-path attacker to break the association in order to remove the server from the pool.
The server needs to be able to operate as a peer, i.e. not be just an SNTP stratum-1 server. Not all pool servers can do that.
It is enough to get the server verified once. Repeated verification is good, but not obligatory. So even if the association is broken sometimes, the server may stay in the pool.
I see. That is a restriction then for this verification method. A different method is needed for the specific servers which has no built-in client function.
Yes, supporting multiple verification methods would make sense to me.
For the simplest devices that cannot do anything except respond to NTP client requests, there could be a protocol consisting of responding and not responding to requests made by the monitoring system. The device could be turned off (or blocked in the firewall) for one minute, then one minute turned on and this could repeat few times to make it unlikely a busy public server would pass by chance.
Yeah, something along those lines were my plan. For people running systems where it isn’t possible we can have a manual process to otherwise verify (email people in whois, allow the verification from another system on the same subnet, or similar).
Perhaps there could be a verification server which attempts to make NTP requests which the server wishing to be in the pool must block, then a server would be verified if the monitor server can get an NTP reply but the verification server could not.
I presume that the IP addresses you are configured to use by the hardware based NTP servers are stable in time (that is required by ntppool). I guess the IP address must be dedicated to you then. There must be an external entity that controls the IP address assignment and the reverse DNS. You should contact this hosting provider for any possible change on reverse DNS entry.
Some of us have a dedicated IP with our fiber internet connection, but no possibility of changing the reverse.
Maybe your organization enforces you to use another reverse (machine.org.com for example).
They are stable as long as I pay the fee for the connection and the dedicated IP assigned to each connection, but it is a subscription type aimed at normal consumer use and it is simply not possible to get the ISP to change the reverse DNS.
Seeing as how I’m sure this is only affecting a few servers per year, I don’t think we need to go all crazy implementing verification schemes just yet when there is so much other important work that IMO takes higher priority… (like auto creation of vendor zones)…
In the short-term, it would probably be easiest to blacklist certain IPs / Hostnames that should not be in the pool (cloudflare, apple, google, etc, etc…).
Also, multiple verification schemes would likely have to be developed to overcome the limitations of how each server is being hosted… Again, taking more time when other projects are higher priority.