Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations
Hello, thanks for your replies! I think I have to explain the problem in more detail, perhaps with an example: Let's say that I have a local NTP server, and lots of remote NTP clients (running ntpd). All clients know my authentication key(s), so they can successfully authenticate with my local NTP server. None of the clients is entered in my local ntp.conf (of course). So far, so good. Now assume that one of the remote NTP clients turns bad, deliberately configures forged time, and enters "peer " in its ntp.conf. This (correct me if I'm wrong) creates a dynamic mobilization with my local NTP server, and my local NTP server will eventually believe in the client's (now it's a peering server) time. I think that this a potential security problem, and I'm looking for a parameter which I can use to r e j e c t dynamic mobilizations of a u t h e n t i c a t e d remote servers with my local server. For *un*authenticated servers, 'nopeer' is the parameter for doing this. But 'nopeer' does only work for unauthenticated connections. Stefan ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations
On Thu, Mar 09, 2017 at 03:16:57PM +, Moser, Stefan wrote: > Now assume that one of the remote NTP clients turns bad, deliberately > configures forged > time, and enters "peer " in its ntp.conf. This > (correct me > if I'm wrong) creates a dynamic mobilization with my local NTP server, and my > local > NTP server will eventually believe in the client's (now it's a peering > server) time. Stefan, Ahh, now I understand the problem. You are misunderestimating NTP. Simply being authenticated allows you to establish the symmetric association -- it does not mean ntpd will select that peer to provide time to it. If it provides time that differs from the servers it has configured (even if unauthenticated), the selection and filter algorithms will ignore the symmetric association. The peer, even if authenticated and malacious, needs to pass all the filtering and selection algorithms any source of time does. Authentication authenticates the peer and the the timestamps -- it does not assure quality of the time provided, and ntpd does not make that assumption. > I think that this a potential security problem, and I'm looking for a > parameter > which I can use to r e j e c t dynamic mobilizations of a u t h e n t i c a t > e d > remote servers with my local server. For *un*authenticated servers, 'nopeer' > is > the parameter for doing this. But 'nopeer' does only work for unauthenticated > connections. You can always use "notrust" forcing the clients to authenticate even if you're simply a server to them. There's nothing that says you must use authentication with symmetric mode; they are orthagonal to each other (although, you should authenticate symmetric peers as a best practice -- but you may also authenticate simple clients.) --msa ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations
On Thu, Mar 09, 2017 at 10:56:22AM -0500, Majdi S. Abbas wrote: > On Thu, Mar 09, 2017 at 03:16:57PM +, Moser, Stefan wrote: > > Now assume that one of the remote NTP clients turns bad, deliberately > > configures forged > > time, and enters "peer " in its ntp.conf. This > > (correct me > > if I'm wrong) creates a dynamic mobilization with my local NTP server, and > > my local > > NTP server will eventually believe in the client's (now it's a peering > > server) time. > The peer, even if authenticated and malacious, needs to pass all > the filtering and selection algorithms any source of time does. > Authentication authenticates the peer and the the timestamps -- it does > not assure quality of the time provided, and ntpd does not make that > assumption. Couldn't the malicious client create a larger number of ephemeral associations, using multiple IP addresses, in order to outvote good servers? To me it seems the only defense against this is the new extended keyfile format which can restrict keys to specific IP addresses. If each client had its own key and the key was restricted to one address, the client could create just one ephemeral symmetric association. Of course, if multiple clients coordinated in this attack, it would be still be a problem. The documentation clearly says the nopeer option applies only to unauthenticated packets, but it's not very clear to me what was the reason for that. Do you think it would make sense to modify its behavior to apply to both authenticated and unauthenticated packets? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations
> > > Now assume that one of the remote NTP clients turns bad, deliberately > configures forged time, and enters "peer " in its > ntp.conf. This (correct me if I'm wrong) creates a dynamic mobilization with > my local NTP server, and my local NTP server will eventually believe in the > client's (now it's a peering server) time. > I think that this could only happen if the local NTP server has a peer command for that client. So you only need to restrict that client’s modification access. > Stefan > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions "The power of accurate observation is commonly called cynicism by those who have not got it. » George Bernard Shaw ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can I stop authenticated peers from mobilizing symmetric associations
On Thu, Mar 09, 2017 at 05:24:35PM +0100, Miroslav Lichvar wrote: > Couldn't the malicious client create a larger number of ephemeral > associations, using multiple IP addresses, in order to outvote good > servers? If it has a bunch of IP addresses, maybe... but you'd have to be close enough to the existing clock to capture the peer.. (read: close/low latency and jitter path, and serve better time than the configured servers for a while). ...and that assumes you aren't using prefer on your chosen servers. So someone on a network near you, with a bunch of resources, who already has your credentials, serves you good time, and then slowly walks you away from it. Too fast, you'll just hop back to your former associations and throw the lot out. They'll have to maintain state (crypto, peer, refid, etc.) for each session and each IP needs to have a very good connection to you. So they wouldn't be able to move the clock very far very quickly in practice (maybe a few ms per hour) and they need access to a network very close to you (possibly yours.) For you not to notice this means you're not monitoring your servers, either, at least not in a very comprehensive fashion. This doesn't strike me as a particularly likely threat. Anyone that close to you who already has your credentials has them because they're in control of your systems and network anyway, at which point NTP is not your biggest problem. If they get away with it, it's because you weren't monitoring for a very long period of time... so I'm not going to lose any sleep over this one. If you're really that worried about it, acquire local reference clocks of high quality and attach them to your hosts. --msa ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
