Re: [chrony-dev] Diagnosing pre-shared key authentication failure
On Fri, Oct 14, 2022 at 12:58:16PM +0300, Avamander wrote: > So when someone tries to MITM all NTS and (authenticated) NTP connections, > they'd be marked unreachable just like the ones that are actually > unreachable. > > Would it not benefit from a separate synchronization/selection status? If you can make it reliable, sure. If it's just guessing, I'd rather let the user/admin decide from the raw numbers. If there is missing some statistic, we can add it. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Diagnosing pre-shared key authentication failure
> Falseticker is a source that doesn't agree with a majority of other sources. If authentication is failing due to misconfiguration, it will be displayed as unreachable. So when someone tries to MITM all NTS and (authenticated) NTP connections, they'd be marked unreachable just like the ones that are actually unreachable. Would it not benefit from a separate synchronization/selection status? > If the real server was unreachable, the attacker could be sending incorrectly authenticated packets to make you think it's reachable, but misconfigured. That is fairly easy to determine once suspected, though. On Thu, Oct 13, 2022 at 1:17 PM Miroslav Lichvar wrote: > On Thu, Oct 13, 2022 at 12:52:37PM +0300, Avamander wrote: > > Fair point about logging, but why not reject it as a falseticker? > > Falseticker is a source that doesn't agree with a majority of other > sources. If authentication is failing due to misconfiguration, it will > be displayed as unreachable. > > > Especially in the case of having no successful measurements at all, it > > would pose no (additional) risk, yet would indicate communication (and it > > being invalid). > > If the real server was unreachable, the attacker could be sending > incorrectly authenticated packets to make you think it's reachable, > but misconfigured. > > On Thu, Oct 13, 2022 at 12:54:48PM +0300, Avamander wrote: > > P.S. About logging, some (rate-limited) warnings against such failures > > would actually be very interesting to security teams. Right now there's > > very little visibility in this aspect, which might be worth changing > > really. > > You can check the counters in ntpdata report. If you see "Total RX" > much larger than "Total valid RX", something is going on. > > -- > Miroslav Lichvar > > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-dev] Diagnosing pre-shared key authentication failure
> With your security team hat on, what would you want to know and what would you do if you got a report that said IP address xxx had N authentication failures? Going along with this scenario, I would say it can be considered an authentication failure like all others. If it's immediately actionable or deserves a report is another topic, but it would probably warrant some attention. A misconfiguration, potential malicious MITM or the network corrupting packets, all are relatively grave? On Fri, Oct 14, 2022 at 3:28 AM Hal Murray wrote: > > avaman...@gmail.com said: > > P.S. About logging, some (rate-limited) warnings against such failures > would > > actually be very interesting to security teams. > > With your security team hat on, what would you want to know and what would > you > do if you got a report that said IP address xxx had N authentication > failures? > > > > -- > These are my opinions. I hate spam. > > > > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-dev] Diagnosing pre-shared key authentication failure
avaman...@gmail.com said: > P.S. About logging, some (rate-limited) warnings against such failures would > actually be very interesting to security teams. With your security team hat on, what would you want to know and what would you do if you got a report that said IP address xxx had N authentication failures? -- These are my opinions. I hate spam. -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Diagnosing pre-shared key authentication failure
On Thu, Oct 13, 2022 at 12:52:37PM +0300, Avamander wrote: > Fair point about logging, but why not reject it as a falseticker? Falseticker is a source that doesn't agree with a majority of other sources. If authentication is failing due to misconfiguration, it will be displayed as unreachable. > Especially in the case of having no successful measurements at all, it > would pose no (additional) risk, yet would indicate communication (and it > being invalid). If the real server was unreachable, the attacker could be sending incorrectly authenticated packets to make you think it's reachable, but misconfigured. On Thu, Oct 13, 2022 at 12:54:48PM +0300, Avamander wrote: > P.S. About logging, some (rate-limited) warnings against such failures > would actually be very interesting to security teams. Right now there's > very little visibility in this aspect, which might be worth changing > really. You can check the counters in ntpdata report. If you see "Total RX" much larger than "Total valid RX", something is going on. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] Diagnosing pre-shared key authentication failure
P.S. About logging, some (rate-limited) warnings against such failures would actually be very interesting to security teams. Right now there's very little visibility in this aspect, which might be worth changing really. On Thu, Oct 13, 2022 at 12:13 PM Miroslav Lichvar wrote: > On Thu, Oct 13, 2022 at 12:04:26PM +0300, Avamander wrote: > > My question is, would it be possible to either log or display these types > > of failures in a more prominent manner? Reject as a falseticker for > > example? Or even a custom status, I imagine people having issues with NTS > > might also find that an useful indicator? > > chronyd doesn't know if it's a misconfiguration or an attacker trying > something. If these failures were logged to the system log, attackers > could fill your disk or possibly if the logger was rate limiting, > caused an important message to be dropped. > > The recommended way to debug these is to enable the rawmeasurements > log in chrony.conf and see the NTP tests. An authentication failure > would show up as "111 011" (NTP test 5 failing). > > -- > Miroslav Lichvar > > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-dev] Diagnosing pre-shared key authentication failure
Fair point about logging, but why not reject it as a falseticker? Especially in the case of having no successful measurements at all, it would pose no (additional) risk, yet would indicate communication (and it being invalid).
Re: [chrony-dev] Diagnosing pre-shared key authentication failure
On Thu, Oct 13, 2022 at 12:04:26PM +0300, Avamander wrote: > My question is, would it be possible to either log or display these types > of failures in a more prominent manner? Reject as a falseticker for > example? Or even a custom status, I imagine people having issues with NTS > might also find that an useful indicator? chronyd doesn't know if it's a misconfiguration or an attacker trying something. If these failures were logged to the system log, attackers could fill your disk or possibly if the logger was rate limiting, caused an important message to be dropped. The recommended way to debug these is to enable the rawmeasurements log in chrony.conf and see the NTP tests. An authentication failure would show up as "111 011" (NTP test 5 failing). -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-dev] Diagnosing pre-shared key authentication failure
Hi, I just recently accidentally created a key mismatch between two Chrony peers. The result obviously was that there was no synchronization going on between the two. However it was really difficult to diagnose that it was the keys that didn't match. My question is, would it be possible to either log or display these types of failures in a more prominent manner? Reject as a falseticker for example? Or even a custom status, I imagine people having issues with NTS might also find that an useful indicator? Avamander
