You are right that priorities must be taken into account to decide where to put resources when the time comes to implement something. However, this discussion thread is just brainstorming, not a pilot to force implementing anything. Not having enough resource to implement should not stop us thinking about how to do.
You are absolutely right. There is no one single verification scheme which fulfills all possible legitimate scenarios, so multiple schemes are needed.
Let me recapitulate here where we are now:
a well-defined peer to be added to the server configuration. The verification process checks that the peer association is fully established. Limitations:
certain servers has no client function library in the code
certain NTP server appliance may not have appropriate configuration option
Use different protocol other the NTP to the same IP address as the NTP server to be verified, for example: http://1.2.3.4/.well-known/ntppool-verification must return a predefined challenge. Limitations:
other protocol then NTP is not always available from the NTP server (for example enterprise security policy)
certain NTP server appliance may not have appropriate configuration option to allow other service then the NTP
Okay, I’ll go with that. I guess I must have missed the ‘brainstorming’ part in your first post.
#1 is an iffy idea… First, you would have to code a completely custom program on the ‘pool’ side to be able to handle peering in an automated fashion and an unknown number of connections at once. Second, you would need to make sure the ‘client’ isn’t using this as a valid time source under any circumstance. But also this seems rather tedious for a person to do what should be a simple verification process. Most people want something quick & simple, point & click and done…
Along the lines of #2, rather than require a web server to be running on the user’s end, one could also request a page FROM their IP (that is the same as their NTP server). Then they could use a web browser or even just curl/wget… But there will no doubt be a small handful of appliances with dedicated IPs that won’t be able to use this method. Perhaps allowing a little wiggle room, say if the request is made within the same /24 network? Those two options of establishing a TCP connection one way or the other (via http request) seems like it would be the least amount of coding effort on the pool side, and the least amount of effort on the user side.
A custom reverse DNS entry (#3) would probably be the least used. No residential user would be able to change it, most hosting companies it’s a manual request to change, some even charge for it, and if the server is being used for other purposes it could break other functionality. However, it could be used in a similar fashion the way email servers will check for verification. If you can match up the domain in a reverse lookup with the user’s email address on their account, then you know it’s likely legit.
Also worth thinking about is are only new accounts / servers going to be required to verify? Or are all existing pool servers going to have to verify before a certain date (or be dropped out of the pool)?
It just requires an NTP server running with generated configuration file with peer statements from the database with those IP addresses where this verification method is selected and pending verification status. Time to time the association is verified and if it is OK, add the verification timestamp of the IP address to the database.
The verification NTP server must run with valid time, but higher stratum number. Even if the server to be verified synchronize to it, it is not a big deal. As it was mentioned earlier, it is recommended for the peer statement on the server to contain the “noselect” term.
The NTP server to become member of the pool must be configured anyhow. We already have a page for configuration recommendation. We just have to add additional step to prepare for this kind of verification.
This is good idea, client connection from the IP. Also, for any TCP service running on the host does not have to be HTTP server on port 80, as it was already mentioned earlier. However, all have the limitation of not being part of the realm of the NTP protocol itself (for example, failing on security policy).
These are very pertinent questions. My opinion: IP addresses must be verified, not accounts, since only the IP address are subject of misuse. I believe that one time verification is enough, we just mark in the database when occurred, no need to verify repeatedly.
I think only newly added server IPs must be verified. No need to verify old servers, the verification status can be marked as “legacy”. But old servers may have to option to be verified, if the owner wish to do so.
If this is a “one time” verification - Could it be as simple as keeping the time server off then adding it in the ntppool gui and then turning it on when asked to by the gui. It demonstrates control over the IP and protect against adding existing NTP servers from Apple, MS, Google, Cloudflare etc.
Using a stock NTPD build and trying to auto-generate config files and constantly restarting the program just seems like a bad idea on multiple levels (even if it would be the easiest), even if you are using a dedicated small virtual machine for it. First, it’s going to jack with the time on the server side every time it restarts and it’s going to take time to sync up. Also if the restart would have to be implemented on some schedule to prevent a DoS situation. How long would a peer association have to exist to be considered verified (remember this is going to be using NTP poll intervals)? A peer association is still unencrypted UDP packets going back & forth which in theory could be susceptible to various attacks. What’s the likelihood someone would go that far just to get a server in the pool? Probably zero… But you never know, and if you are going to invest so much time & effort into creating something then it’s best not to build it knowing there are inherent exploits that can not be rectified.
The reason I would choose writing a custom program vs using NTPD is that you could leave NTPD alone on the server to maintain the system time, and your custom script would be running on a different IP. The packets themselves are not difficult to construct / decode, and since you are not using them for any time adjustments on the server there is no reason to have the full NTPD backend.
At least by making HTTPS requests (from one direction or the other) you are building on a layer of existing security and authentication. Also the verification process would be instant and not require any configuration file changes or restarts on the user’s side.
The main thing is to keep it simple and make it quick for the user. If it’s something overly elaborate then they might decide it’s not worth the effort to join.
That is another potential possibility… I like how simple it is. But, in theory that too could be susceptible to various attacks if someone were able to intercept the UDP packets before reaching their destination. For instance, they could DoS a router along the path to the point it would start dropping UDP packets.
I think we need to consider the “adversary” we are trying to protect against and the reason why it is being considered to implement in the first place.
Is it really a very tech savvy attacker or it is a misguided user? Personally I think this extra very simple verification, that underlines how important it is your own server, will stop 99,9% of these registrations.
Yes, you are correct we are basically just trying to prevent the ‘misguided user’ from registering a server they do not have control over. But we also don’t want to create a situation where a tech savvy attacker could be mischievous, or could wreak havoc and in a worse case situation incapacitate the pool.
I wasn’t trying to dismiss your idea, it is probably one of the top contenders that I would choose. I was just merely giving my thoughts as to its pros/cons. Like I said, “I like how simple it is”. It provides quick verification and would only require some very basic code on the server side. The end user can do anything from stop the daemon, block via their firewall, or even physically unplug an ethernet cord…
Thanks for your thoughts on it and don’t worry – I wasn’t offended or anything. I just have a work habit of making a “risk assessment” first, so we do not over-engineer this.
In fact, no need to restart the NTP service. It is possible to runtime configure with “ntpdc addpeer” command.
If the association is there, the remote NTP server should be accepted as verified since it has demonstrated the willingness of joining the pool.
If I understand well you are telling that a peer association might be unsafe and so it might be an attack vector towards any of the server. That we have to keep in mind and weight the risk. We could recommend the user to remove the peer statement from the configuration after the verification is positively confirmed.
We may introduce the verification process as not compulsory. Get some experience how users react, and if they are fine with it, then make the server’s IP address verification obligatory for new servers to join the pool.
I like the idea. On the other hand the gui should give indication from which IP the communication must be cut to satisfy the verification. In certain condition the NTP server is already used for NTP service outside of the NTP pool.
I have no problem with that. I also think you should have limited amount of time to complete the registration, so downtime with a vendor isnt used to add their time servers to the pool, but that are just minor details that can be tweeked.
What if somebody keeps requesting verification after each verification time-out? One day he may be lucky as random vendor server down condition may add the server to the pool.
I would think sending off an email to an administrator could also quickly identify if the attempt is malicious or someone is having technical difficulty.
But I agree with Hedberg, after so many failed attempts on a particular NTP server’s IP then it is prevented from being tested again for a certain period of time. The more failed attempts that build up, the longer the next time period will be… But I would assume too if automated emails were sent that either the server could be added by manual means, or permanently blacklisted if it shouldn’t be in the pool.
