# Verification step to add a server **URL:** \ **Category:** Pool Development\ **Created:** [June 25, 2019, 9:24am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295 "2019-06-25T09:24:58Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 25, 2019, 9:24am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/1 "2019-06-25T09:24:58Z")
> [@Time.cloudflare.com](https://community.ntppool.org/t/time-cloudflare-com/1292/8): > > > [@Time.cloudflare.com](https://community.ntppool.org/t/time-cloudflare-com/1292/2): > > > > (Were they even added with permission?) > > No, and they’ve been disabled again (some hours ago) at the request of Cloudflare. (You can thank the users doing this sort of thing when you have to go through some verification step to add a server …). That topic is just a brainstorming about the possibility to verify the intention of the server owner of adding his/her server to the pool. I configured my servers the following way: ` restrict default nomodify notrap nopeer noquery restrict 139.178.64.42 nomodify notrap nopeer ` 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? ---
**Author:** ![alica](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/alica/32/337_2.png) [@alica](https://community.ntppool.org/u/alica)\ **Post date:** [June 25, 2019, 2:38pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/2 "2019-06-25T14:38:00Z")
> [@NTPman](#): > > I configured my servers the following way: > > ```auto > restrict default nomodify notrap nopeer noquery > restrict 139.178.64.42 nomodify notrap nopeer > > ``` 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: ```auto restrict default notrap nopeer noquery restrict 139.178.64.42 notrap nopeer noquery version ``` 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… ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [June 25, 2019, 6:11pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/3 "2019-06-25T18:11:33Z")
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](http://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. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 26, 2019, 6:44am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/4 "2019-06-26T06:44:27Z")
> [@mlichvar](#): > > Enabling ntpq access for the monitoring node would make it vulnerable to amplification attacks. 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. > [@mlichvar](#): > > A simple protocol based on TCP would probably be safer and more portable. 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. ---
**Author:** ![frank](https://avatars.discourse-cdn.com/v4/letter/f/3d9bf3/32.png) [@frank](https://community.ntppool.org/u/frank)\ **Post date:** [June 26, 2019, 7:36am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/5 "2019-06-26T07:36:40Z")
In that case, why not simply check that a `curl -H 'Host: pool.ntp.org' IP` doesn’t redirect against [www.pool.ntp.org](http://www.pool.ntp.org) ? ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [June 26, 2019, 7:42am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/6 "2019-06-26T07:42:28Z")
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. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 26, 2019, 7:47am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/7 "2019-06-26T07:47:43Z")
> [@mlichvar](#): > > Sending NTP requests to the monitoring node won’t work either. The source address can be easily spoofed. 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? > [@mlichvar](#): > > Also, some servers don’t have a client at all, so there is the same problem as with the other proposals. My proposal does not require client. It is a just server configuration. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 26, 2019, 7:50am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/8 "2019-06-26T07:50:26Z")
> [@frank](#): > > In that case, why not simply check that a `curl -H 'Host: pool.ntp.org' IP` doesn’t redirect against [www.pool.ntp.org](http://www.pool.ntp.org) ? 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. ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [June 26, 2019, 8:01am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/9 "2019-06-26T08:01:26Z")
> [@NTPman](#): > > 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? 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. > [@](#): > > My proposal does not require client. It is a just server configuration. 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. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 26, 2019, 8:09am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/10 "2019-06-26T08:09:23Z")
> [@mlichvar](#): > > > [@NTPman](#): > > > > 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? > > 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. 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. > [@mlichvar](#): > > > [@NTPman](#): > > > > My proposal does not require client. It is a just server configuration. > > 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. 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. ---
**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\ **Post date:** [June 26, 2019, 12:07pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/11 "2019-06-26T12:07:07Z")
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. ---
**Author:** ![ask](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ask/32/907_2.png) [@ask](https://community.ntppool.org/u/ask)\ **Post date:** [June 26, 2019, 7:32pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/12 "2019-06-26T19:32:14Z")
> [@mlichvar](#): > > 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](http://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` 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). ---
**Author:** ![Bryce](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bryce/32/281_2.png) [@Bryce](https://community.ntppool.org/u/Bryce)\ **Post date:** [June 26, 2019, 9:55pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/13 "2019-06-26T21:55:58Z")
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. ---
**Author:** ![Hedberg](https://avatars.discourse-cdn.com/v4/letter/h/e95f7d/32.png) [@Hedberg](https://community.ntppool.org/u/Hedberg)\ **Post date:** [June 27, 2019, 10:13am UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/14 "2019-06-27T10:13:17Z")
Please remember the many hardware-based ntp servers. They might not have the option to implement many (if any) of the suggestions above. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 27, 2019, 12:08pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/15 "2019-06-27T12:08:05Z")
May be a reverse DNS entry which cleary shows the intention the IP to be part of the pool. Let say in the format of: [x.ntppool.example.com](http://x.ntppool.example.com) ? ---
**Author:** ![Hedberg](https://avatars.discourse-cdn.com/v4/letter/h/e95f7d/32.png) [@Hedberg](https://community.ntppool.org/u/Hedberg)\ **Post date:** [June 27, 2019, 12:38pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/16 "2019-06-27T12:38:39Z")
I do not control the reverse DNS of my two NTP servers and I suspect many other private individuals also do not control theirs. ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [June 27, 2019, 12:53pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/17 "2019-06-27T12:53:55Z")
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. ---
**Author:** ![frank](https://avatars.discourse-cdn.com/v4/letter/f/3d9bf3/32.png) [@frank](https://community.ntppool.org/u/frank)\ **Post date:** [June 27, 2019, 1:05pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/18 "2019-06-27T13:05:32Z")
In the real world this doesn’t work like that. 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](http://machine.org.com) for example). So no, this is not possible in real life. ---
**Author:** ![Hedberg](https://avatars.discourse-cdn.com/v4/letter/h/e95f7d/32.png) [@Hedberg](https://community.ntppool.org/u/Hedberg)\ **Post date:** [June 27, 2019, 1:13pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/19 "2019-06-27T13:13:29Z")
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. ---
**Author:** ![littlejason99](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/littlejason99/32/242_2.png) [@littlejason99](https://community.ntppool.org/u/littlejason99)\ **Post date:** [June 27, 2019, 4:19pm UTC](https://community.ntppool.org/t/verification-step-to-add-a-server/1295/20 "2019-06-27T16:19:09Z")
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. [Next page](https://community.ntppool.org/t/verification-step-to-add-a-server/1295.md?page=2)