Invalid-NAK errors from ntpd

Server operators
1

Hi there,

I’ve only just noticed that in the last few months I’ve started getting lots of errors from ntpd about ‘Invalid-NAK’:

Jul 15 11:56:00 electra ntpd[687]: Invalid-NAK error at 1638 109.74.206.120<-5.150.101.130
Jul 15 11:56:05 electra ntpd[687]: Invalid-NAK error at 1643 109.74.206.120<-86.63.7.233
Jul 15 11:56:27 electra ntpd[687]: Invalid-NAK error at 1666 109.74.206.120<-5.150.101.130

Is this to do with clients attempting NTP authentication? I don’t have that setup, so I’m assuming this is why - what are other server operators doing wrt NTP auth? I didn’t see any note in the configuration recommendations about authentication.

Both of these clients seem to be WightFibre.

Thanks,
Jamie

2

In the past we have quietly dropped those packets. I came to the conclusion that if one doesn’t know about abuse, the problem can easily grow until it is overwhelming. So now we say something. You may do whatever you want with this information. A future NTP release will likely offer better control over this sort of reporting.

See NTP BUG 3007: CRYPTO-NAK DoS for example.

Maybe the IPs sending those have been infected by malware. Maybe they are malicious. Maybe they are running broken code.

But at least “now you know”, and you have the option to do whatever you want:

  • ignore them
  • tell them (or their upstream)
  • deny them service

The messages give you information you did not have before. At least now you have that information, and can use it to make some conscious decisions.

H

3

But what do we know? Given this message is reported when there is no association to be demobilized, and given 4.2.8p7 resolved the bug you referred to, what is the danger or issue that merits the operator’s attention?

4

We know who is sending us invalid NAKs, and how often.

Yes, anybody running code at p7 or later will not fall victim to the attack, but it’s still misbehavior.

I’m working on some NTP-related DoS mitigations, and one aspect of that will be collecting the IPs of abusive hosts.

I consider these messages to be “mechanism”. What the operator chooses to do about the information is “local policy choice”.

5

@harlan , welcome to the community!

In addition too, they may have forged source address.

1 Like
6

You haven’t answered the question of why it might be interesting to the operator, or even explained what an Invalid NAK is. I don’t see how the readers of this thread are supposed to make that local policy choice, given the cryptic message and your lack of advice on handling it. I know I find it useless clutter on a pool server getting ~1.5 Mbps of NTP requests, and there’s no mechanism to quiet it. It’s also duplicative of another message which appears the first 15 times it occurs, before thankfully being shut up until an intervening event resets the counter:

20 Feb 16:52:44 ntpd[15804]: 0.0.0.0 041c 8c bad_auth Invalid_NAK
20 Feb 16:52:44 ntpd[15804]: Invalid-NAK error at 9735 192.168.201.101<-72.240.53.26
20 Feb 16:53:50 ntpd[15804]: 0.0.0.0 042c 8c bad_auth Invalid_NAK
20 Feb 16:53:50 ntpd[15804]: Invalid-NAK error at 9802 192.168.201.101<-72.240.53.26

That first message could easily be changed to include the remote IP, at which point the second message is more appropriate for -D debug output, as it happens with every such packet, effectively a DoS opportunity against the ntp log/syslog.

1 Like
7

I didn’t see anybody ask what a Crypto-NAK was. An invalid Crypto-NAK should never occur, so if we get one it’s an indication of a problem.

The messages help with the local policy choice in that they tell you where they are coming from (unless somebody is forging the source address).

If the first and third lines of your example above of the “duplicative other message which appears the first 15 times it occurs”, I’d disagree, as those lines do not say anything about who is sending them.

But it’s clear you don’t want to see them, and we need a way to let folks control whether or not they see these messages.

I also know you don’t care to see the “seconds since startup” count (the 9735 and 9802 in the 2nd and 4th lines of your example above), and I find them to be very useful when examining other logs (rawstats, etc) to identify what’s going on.

8

The log messages do not mention Crypto-NAK, one refers to Invalid_NAK the other to Invalid-NAK. If these are indeed Crypto-NAK, I’m guessing they are relevant only if Autokey is in use. Is there any reason (other than your general interest in logging when seeing curious packets) these messages should be logged if Autokey is not in use?

Those other logs don’t prefix each line with the date and time. Logging to syslog/ntp.log the time since startup is duplicative as it’s easy to find the associated startup time in the same logfile.

9

I think this may be someone trying to exploit:

  1. NTP BUG 2941: NAK to the Future: Symmetric association authentication bypass via crypto-NAK
  2. Or CVE-2016-9311 to create a DoS

In the meantime, as the two IPs are responsible for all of the attempts I’ve blocked them at the firewall level. Thanks for the responses and input on this!

1 Like