Hey.

I wondered the following:


1) In the systemd unit file, it's commented:
# Specifying -g on the command line allows ntpd to make large adjustments to
# the clock on boot.  However, if Restart=yes is set, a malicious (or broken)
# server could send the incorrect time, trip the panic threshold, and when
# ntpd restarts, serve it the incorrect time (which would be accepted).

but in /etc/default/ntpsec there's nevertheless:
NTPD_OPTS="-g -N"
which is used.

Shouldn't -g be removed?



2) Also in /etc/default/ntpsec, per default IGNORE_DHCP is "".
Shouldn't that be set to yes, so that per default a malicious DHCP server
couldn't add it's own possible rogue servers?



3) The legacy ntp.conf used:
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

okay, notrap is gone, but they still had one entry for -4 and one for -6.

That's similar what upstream does in their examples:
https://gitlab.com/NTPsec/ntpsec/-/blob/master/etc/ntp.d/use-no-remote-configuration
restrict default kod limited nomodify nopeer noquery
restrict -6 default kod limited nomodify nopeer noquery

Sure that one entry would account for all possible (v4/v6) hosts in the default
entry?



4) Also the legacy ntp.conf used in addition:
restrict source notrap nomodify noquery

Am I right, that this is no longer needed because of the changed meaning of nopeer?



Thanks :-)

Chris.

I think I've answered all your questions and I'm not seeing any changes
necessary, so I'm going to mark this as closed. If you disagree, feel
free to reopen (or just comment and I can if necessary).

First off, note that the stock ntpsec.service has Restart=no, not
Restart=yes. So in the malicious/broken server scenario described, ntpd
will die, but not restart.

As far as -g goes, there's really no one right answer. If you keep -g,
then ntpsec can fix arbitrarily broken clocks. If you remove it, then it
can't. Imagine how confusing would be if you clock is wrong, you install
ntpsec, and your clock is still wrong. Additionally, consider systems
like the Raspberry Pi where there is no real-time clock; they need ntpd
to be able to make large adjustments, so removing -g would break them.

So I've landed on -g and Restart=no. This makes things work on Raspberry
Pi, on new installs, plus any other scenarios where the clock is crazy
wrong on boot/startup, while minimizing the security risk in
steady-state operation.

Users can override the -g default in /etc/default/ntpsec and/or the
Restart=no default with a systemd drop-in file. FWIW, at my day job, I
override both on non-Pi always-on server systems: I set NTPD_OPTS="-N"
(no -g) and Restart=on-failure. On Raspberry Pis, I keep -g and still
set Restart=on-failure, but I'm not doing anything security sensitive on
Pis. Those settings mean that ntpd will get restarted if it crashes (not
that I've ever seen it crash).
ntpsec doesn't pull it in. If you choose to install that package, you
(arguably) are expressing a desire to use its features, and the DHCP
integration is a big part of that.

Counterpoint: Maybe you just want to use ntpdig. So maybe that should be
split out, as you have proposed in bug #1003966.
upstream):

commit 34e1c81a709806487341abdd4c12c00c319b3b7e
Author: Richard Laager <rlaager@wiktel.com>
Date:   Tue Nov 7 06:06:35 2017 -0600

     Drop notrap from ntp.conf

     This is ignored by ntpsec, so we might as well remove it.

docs/access.adoc (in the source), which compiles to
/usr/share/doc/ntpsec-doc/html/access.html in ntpsec-doc, says:
+restrict default+, with no mask option, modifies both IPv4 and IPv6
default entries.

So it should apply to both. If you have any reason to believe it's not
working for both, please let me know.

Given that notrap no longer exists, then that's just doing nomodify and
noquery. I guess I'm not seeing why that "restrict source" would be
useful, if those restrictions are already set by default per "restrict
default".

How does that add protection? Isn't it still, that if one e.g. reboots
and ntpd starts the first time, then an attacker could basically set
any time?

One could argue here, that most "normal" systems (desktops, servers)
have usually rather well working clocks... an so they wouldn't be
likely affected by what you describe.

OTOH, embedded systems are "special" and if someone uses a system with
no clock at all, than IMO it's rather his duty to take necessary steps
so that it works (e.g. by installing ntpdate).

Someone who installs ntpsec probably goes for the "sec" part... and it
feels as if security would be weakened quite a bit by having -g or
allowing DCHP advertised clocks per default, just in order to make
things more runs-out-of-the-box.

Again,... seems like if security would be weakened for use cases where
security isn't that important anyway (and ntpsec itself isn't that
crucial).

I didn't realise that /etc/default/ntpsec's IGNORE_DHCP actually
affects only ntpsec-ntpdate (or at least that's how I understand
you)... which however has it's own /etc/default file with it's own
IGNORE_DHCP??

That's what I've meant with my "is gone" :-)
Ah I see.

No, not apart from those links I've sent before.



Thanks for your help :-)
Chris.

Control: reopen -1

Yes, -g is only applicable at boot (or first install).
A) the server serves bogus/malicious time
B) a MITM messes with the time.

The primary protection for A is consensus (see specifically minsane). A
single bogus/malicious clock can't do anything.

Of course, in scenario B, the MITM can mess with all of the clocks
you're talking to. NTS is the best protection. The older style fixed
secret hash-based (e.g. MD5/SHA) authentication is better than nothing.

But yes, without NTS and with -g (both being the defaults in Debian),
ultimately a MITM could adjust all of the times you're seeing and set
any time, but only once upon boot. Eliminating -g would improve security
in this situation. But there are trade-offs.
now your clock is wrong, despite running ntpd.

I'm not sure how installing ntpdate is different from installing ntpsec
in that regard.


Let's say I remove -g by default. (Then I can safely set
Restart=on-failure by default.) I could address some/all of the trade-offs:

I'd imagine I could script up something to add -g on the first run of
ntpd on initial install, to address that case. For example, I could
detect the first run scenario as there being no drift file.

I could use hwclock(1) to determine if there is an RTC. If not, add -g.
That would make the Raspberry Pi case work out-of-the-box without
decreasing security for regular systems.

That still leaves the case of "my RTC battery died". I could probably
detect that too, by checking to see if the current time is older than
the drift file, and again add -g.

The only problem I see with this is that if I'm adding -g under various
circumstances, there's then no way for the administrator to prohibit -g.

Another option would be to remove -g from $NTPD_OPTS if none of those
conditions apply. If I'm only removing -g, the admin can still ensure -g
is not used by removing it. This creates the opposite problem: there's
no way for an admin to add -g if they want it always. (Unless my -g
removal only removes one and they set NTPD_OPTS="-g -g" but that seems
like a hack.) But, removing options is itself tricky (e.g.
NTPD_OPTS="-gN" or NTPD_OPTS="-Ng") and that feels like asking for trouble.

Yeah, in looking at this more, this is different / more complicated than
I remember, and arguably messy.

So both ntpsec and ntpsec-ntpdate have DHCP support, which is enabled by
default (IGNORE_DHCP="").

/etc/default/ntpsec's IGNORE_DHCP affects ntpd from ntpsec.

/etc/default/ntpsec-ntpdate affects ntpdate-debian (note the -debian
there) from ntpsec-ntpdate.

It's technically possible to have both installed, but generally one is
either using ntpd or ntpdate-debian, not both.

The only documentation for this is README.Debian, which only references
/etc/default/ntpsec. In fairness, lots of that file is talking only
about ntpd from the ntpsec package, which ntpsec-ntpdate being a bit of
a separate thing / an afterthought.

Really, ntpsec-ntpdate should just die and this gets simpler.

As far as DHCP goes, though... the DHCP server controls my address and
my gateway. It can trivially MITM me. It could serve me DNS that
redirects the pool servers somewhere. Or even without DNS being
involved, it could simply serve me a gateway IP that forwards all NTP
traffic somewhere.

That said, if I'm using NTS in my ntp.conf, that's being defeated by the
DHCP integration. That's probably a good reason to disable DHCP
integration by default.

Yes,... (B) should be rather difficult with NTS (well the X.509 CA
system is inherently broken, and I'd guess it's rather "easy" to get a
forged cert... but that's another topic - and at least one can specify
a single cert per server... so it can be made quite secure).

(A) is kinda what I'd want to prevent by having -g removed... at least
it shouldn't be "so easy" anymore for a rogue server (NTS or not) to
quickly change the time by amounts that really matter.

At least not quickly... AFAIU it should still be able to slowly change
my time, over time.

But intuitively I'd also say, that this increases the chances of
noticing the attack.
Not if the attacker's goal is to shift my time by 3 minutes or so...
but for any larger times, one could sooner or later notice it (that is:
on desktop systems - but for anyone who really needs tight time
security on servers, there are probably anyway other measures to be
taken).

But IMO even with NTS.
I get my time from some triple-letter-agency,... no not the CIA but PTB
(less something like the CIA, but more comparable to NIST ... and
Germany's official time provider).
With -g, and even despite NTS, they could send me malicious time, every
time I boot (or (re)start the service manually).

Sure... but still it's a conceptual question what one wants:

If one installs ntpsec, rather than just ntp or systemd-timesync ...
and at least if one uses NTS,... then the intention is probably to get
secure time.

Conceptually I'd say, that in such situation, if the battery dies, I'd
rather get failure on starting (which one could at least detect and
e.g. send some mail notification).
possibly no longer be able to give time to such systems.

The same conceptual question comes up as above.

Let's use another example for it: embedded systems often have bad RNG
sources (or at least their initial seeding takes long).

If e.g. SSH is used, than people expect things to be secure. Thus one
rather lets SSH fail or block (until enough entropy has been collected)
instead of letting it use bad random numbers - even, if then things
don't work so out-of-the-box anymore.


The same would IMO apply to a service like ntpsec, which one typically
installs for exactly the reason of being (more) secure.

Maybe one could add some debconf dialog, that just shows the "previous"
time, and in comparison the time after it was first (and once) set with
-g.

Similarly, I'd recommend a debconf question here (which is e.g. only
asked if no RTC is found).

I don't see much what one could do here (apart perhaps from sending
mail to root, but that would require someone to actually read this).

Also, any automagical configuration changes (after initial installation
)are IMO rather no so advisable.

I guess that's simply a risk that comes with using secured NTP.
It's similar to when I hardcode a root CA or server cert for some time
source - I must live with the fact that it could change respectively
expire.


One could perhaps ask (yet another) debconf question, asking whether -g
should be added, describing the case of e.g. dying RTC battery while
also explaining the risks of enabling this.

Which would defeat the whole purpose.

Extremely exaggerated: ;-)
As if SSH would default do: Oh you don't have verified your remote
public key? Well just accept it blindly, because everything else would
mean it doesn't work out-of-the-box.

One could add another option, that controls whether your script are
allowed (or not) to automatically add -g.

But as said... any automagical things are IMO quite suspect. I'd then
rather just ask debconf questions, choosing secure defaults (which
would IMO be not using -g or DHCP in any case, regardless of no-
RTC/battery/etc. - simply for the sake of the purpose of ntpSEC ).

That would still allow an easy override... and even to script that.
;-)

Yes... I'd really leave that just in for e.g. server farms, which trust
their own network and DHCP to give them a proper time source.

But even then.... for any such big site, they probably have some
configuration management in place and it may be easier to set the time
source directly in ntp.conf via that... instead of indirectly via DHCP.


I always hated (and considered it quite security questionable) how much
DHCP is allowed to modify.
E.g. it doesn't seem to be possible to forbid it setting the DNS search
key.


Cheers,
Chris.

I don't see how that's possible. Eventually that single server will tick
too far outside of the consensus window and be excluded as a falseticker.

To give you a real example of this... At $DAYJOB a week ago, one of my
NTP servers has a PPS input from a telecom GPS clock. This clock failed;
specifically it started outputting bad time (ticking at the wrong rate,
as opposed to stopping outputting time entirely). ntpd followed this for
a bit, making it look like the other sources all went insane
simultaneously. After a few minutes (of elapsed time, not of time
drift!), the error was bad enough that ntpd realized the PPS was insane,
stopped following it, and followed the consensus of the other sources
back to sanity. And this was with the PPS source marked "prefer". I'm
not sure if anyone kept the graphs, but the error was us or ms, not even
seconds, much less your example of 3 minutes.

Yes, they could. And someone (USNO, I think) had a bug a couple years
ago where they did serve bad time. But if you have multiple sources, as
you should, then you have protection against this. For example, I get my
time from 8 sources, two with old style authentication and 1 with NTS.

So even on boot, even with -g, a single source can't cause one to accept
bad time.

The default configuration uses the pool, so there too, a single source
cannot cause one to accept bad time at boot even with -g.


Back to scenario B, the network MITM:

Now, given NTS's current limited deployment, I have limited protections
against a network MITM. Only 3 of my 8 sources have any protection at
all, so a MITM could change the other 5 and I'd follow that. My choices
are: reduce the number of non-authenticated sources, raise minsane,
and/or run without -g (which only matters at boot).

In the default configuration, a MITM could slowly change your clock over
time by changing all of the times you see. But -g or no -g is irrelevant
to that. The _only_ real answer to the MITM is NTS.

I meant for the case when people don't use the pool... or maybe they
use a pool, which is under the single control of one group.

But then you have a pool configured, right? Didn't you mention in some
readme (or was that somewhere else?) that there is not yet a pool just
for NTS supporting sources?

Ah here you answer it already.

Okay it get's awkward now, but even such a situation (with a pool)
might probably be attackable (blocking attack).

Consider a powerful attacker who a) runs a clocksource one trusts and
b) can block traffic to any other sources in the pool one uses?

Does NTP(sec) complain eventually (like too many sources not answering,
something is fishy)... or would it just happily continue with the one
(then evil) source?

Okay there I don't know enough about NTP, how that actually works (i.e.
does it even then already use multiple sources... or would it just pick
one of them).
But as I understand you... it would even then already use and compare
multiple sources.


Sure.


Cheers,
Chris.

With the Debian-default of "tos minsane 3", it's not going to follow a
single source, period.