Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd)

Sergei_Shablovsky

@bingo600 said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

Thank You for opinion!

@sergei_shablovsky
IMHO pfSense should continue using the "Industri standard" NTP, that is installed on thousands of servers around the world.

But this is really old, outdated, and vulnerable solution. Agree?

If you need ntpsec, do as @johnpoz
Make a dedicated NTP server facing public, with ntpsec , and point your internal servers to the ntpsec box.

As I wrote before, in case using non-specialized time-source device, like a just another one server, we receive some disadvantages:

power consuming;
several additional rules for pfSense for internal networks;
several additional rules for pfSense for NTP users outside;
another one (+1) point of failure; (for example if You have two(2) pfSense+GPS on COM port in HA-scheme, Your NTP service also protected, otherwise a You need two(2) dedicated NTP servers and synchronization between them...)

If i was to change from NTP, to something "Brand new". I would prob. consider Chrony instead.

Or maybe even look at Ntimed (which i suppose have excellent FreeBSD support , since PHK has been digging deep into it) , it just seems a bit immature.
https://news.ycombinator.com/item?id=8781435

/Bingo

Generally say, in IT I am “conservative”” in mind, so rarely try to using “all newest”. ;) This topic I start about really outdated and vulnerable NTP need to be replaced. And mine proposition are NTPsec.

Please, describe in short about advantages Chrony & Ntimed against NTP and NTPsec. Thank You for Your time!

johnpoz

@sergei_shablovsky said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

**really outdated and vulnerable NTP”” need to be replaced.

What specific vulnerability are you talking about.. Just because NTP has been around long time - does not mean its not been kept up to date for security issues.

While current version is a year so old 4.2.8p15, I wouldn't call it outdated..

mer

@johnpoz My understanding of current NTPD is there is a lot of security stuff that can be used/implmented but "it's not the default".

if defaults were changed to be tighter, then new deployments (maybe upgrades) would be tighter but existing ones would need manual changes.

That argument I think applies to ntpsec: new deployments are affected but existing ones aren't.

johnpoz

@mer said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

"it's not the default".

Well that is on the runner of the software.. Are you saying there should be something changed in default settings of ntp server on pfsense?

I wouldn't in a million years provide such a service off my firewall to the public internet, ntp on pfsense is meant for ntp server for your local network.

And if I was going to provide it as public service - I would make sure I go through its config, etc. To make sure nothing stupid is in there ;)

edit: There was a thread around here somewhere someone asking about NTPv3 auth - rfc 1305, which you can do with pfsense ntp.. I don't think it was that long ago.. I personally don't get the need to be honest. While sure I could see wanting to make sure your talking to a specific ntp server externally.. Just run your own internal ntp - and not have to worry about any of that.. Not really seeing the need for any sort of ntp security on my own local secure network. If you ask me - just something else that could break ;) For very little security benefit..

mer

@johnpoz I agree 100% with you. A lot of discussions around services like this seem to devolve to "the defaults aren't good/secure enough and should change".
50% take that stance the other 50% say "If you are standing something up you need to go through the defaults first".

Kind of like "what editor should be the default, vi or ee"

johnpoz

@mer agree.. If your not a fan of the defaults - change them.. Defaults are almost always what they are to minimize chance of it not working.. What is the most basic config I can put in - that pretty much a given it will "work". That is the default..

Nobody says that default working config = secure ;)

While I agree as something like pfsense matures and stuff its using evolves - defaults change, and old non secure stuff can drop off. I do recall not that long ago some issues people were having because the changed and dropped off some ssh ciphers from the default config - which broke some users access via their ssh clients, because their clients were out dated, etc.

Default broke shit ;) heheh atleast from the users point of view.. I don't see pretty much anything be it ntp, ssh, web being locked down to tightest mos secure best practice from a security point of view for defaults.. Because its less likely to just work out of the box - which when it doesn't work out of the box, users not happy ;)

bingo600

@johnpoz said in [Network Time Security (NTS, NTPsec) to replace

I wouldn't in a million years provide such a service off my firewall to the public internet, ntp on pfsense is meant for ntp server for your local network.

I totally agree here.
When i worked w. PIX/ASA , there was a sntp client , no NTP service.

In fact NTP service prob. doesn't belong on a firewall , just a sync client. pointing to an inside NTP server.

And if I was going to provide it as public service - I would make sure I go through its config, etc. To make sure nothing stupid is in there ;)

The last OOPZ i know about in NTPD was the amplification attack,
and that is easily avoided in the setup today.

And i agree with : What security issues needs to be fixed in NTP right now ?

/Bingo

AndyRH

I think the security question must be narrowed to have relevance.
NTP sends the time in clear text. (Time is not a secret)
NTP does not validate who it is talking to. (In theory you could use this to be mean to someone, NTP has a sanity check on time changes, check those defaults!)
NTP service has no known vulnerabilities at this time. (Software is secure)
It is simple to use and hard to mess up, does that help security?

johnpoz

@andyrh nice way to look at it.. I concur!

DaddyGo

@sergei_shablovsky

an evasive post but important: (for all :))

I recommend it to all who to use GPSD based stratum1 NTP - follow and update guidelines!!! (on your network NTP source)

https://www.theregister.com/2021/10/19/gpsd_bug_reset/

we run it and it affects our settings:
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/#RASPBIAN

the biggest thanks to Gary Miller and others

Sergei_Shablovsky

@daddygo said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

I recommend it to all who to use GPSD based stratum1 NTP - follow and update guidelines!!! (on your network NTP source)
https://www.theregister.com/2021/10/19/gpsd_bug_reset/
we run it and it affects our settings:
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/#RASPBIAN

Let's to remind very old but useful Network Time Protocol: Best Practices White Paper

Sergei_Shablovsky

@andyrh said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

NTP service has no known vulnerabilities at this time. (Software is secure)
It is simple to use and hard to mess up, does that help security?

“If something in Internet was not already hacked, this is not because it’s strong, it’s because till this time no one pay serious attention on this “something”(c)myself

No one goes deeply and care about how this old things working, but only after a lot of crashes, transporting issues, and some quantity of broken peoples lifes community starting SLOWLY changing mindset about needs to keep up to date old protocols that used in billions devices from your coffee maker, heart cardio stimulator, cars to blood pumps, very big oil & gas sea tankers, citie's energy stations, etc...

DaddyGo

@sergei_shablovsky said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

it’s because till this time no one pay serious attention on this “something”(me)

Hmmm, that's a serious formula, but just think of all the stratum1 satellites... (there are a few of them)
The NTP is currently massive....
(but like everything else it may be vulnerable)

everything would be dead without it, think of the stock exchange, credit card transactions that are dampened by prime number encryption and much more....

BTW:
use your power for good things

mer

I feel like I am missing something here.
Synchronizing time across the network, even if a single server and single client, means what?
client asks a configured server "what time do you think it is" and then applies alogrithms on the reply.

Security wise:
What level of trust does the client have for the server it's asking? One would think the client shouldn't be configured to as clients it doesn't trust.

Granted:
NTP servers typically are open, so anyone can ask them, which could result in DOS from the server. But "so what"? Client can't talk to a server?

So: I think a lot of this discussion is based on standing up a server not simply being a client.
If your pfSense box is going to have an independent time source at stratum 1, of course make it so only your desired clients (your network) use it as a definitive source of time.

JKnott

@mer

One thing to remember is you can set up NTP with multiple sources. You should have at least 3, so that if one starts providing bad data, then it will be ignored. This makes it difficult to tamper with.

I have 5 sources, 3 of which are stratum 1 and 2 stratum 2.

Sergei_Shablovsky

@daddygo said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

@sergei_shablovsky said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

it’s because till this time no one pay serious attention on this “something”(me)

use your power for good things

Sorry my misstyping, I mean that’s phrase made by myself. :)

Sergei_Shablovsky

@bingo600 said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

If i was to change from NTP, to something "Brand new". I would prob. consider Chrony instead.

Thank You again one time for suggestion.

Just for anyone this Comparison of NTP implementations

Ok, I agree with You: for various reasons (some of it are very valuable like less dependent from main CPU frequency changes (because power management enabled in BIOS), link delay/jitter/lost packets, noticeable working speed,...) the Chrony looks like more logical solution both for NTP client & server.

bingo600

@sergei_shablovsky
Even though Chrony is "Shining Brand New" , i would .. As it is the industry standard.
Still prefer NTP to be the timeserver on pfSense

Chrony would be something i'd play with on a separate host , if i wanted to.

/Bingo

Patch

@bingo600 said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):

Even though Chrony is "Shining Brand New" , i would .. As it is the industry standard.
Still prefer NTP to be the timeserver on pfSense

Imo Chrony is just plan better and can see no reason not to use it on pfsense

Time synchronisation is better (faster and more accurate synchronisation)
Better reporting via the combination of

chronyc tracking
chronyc sources
chronyc sourcestats
chronyc clients

So I would like to see chrony on pfsense. For me it would be cleaner than using my Proxmox host for chrony / site time.

Sergei_Shablovsky

@patch Even more:

chrony vs ntp
Things chrony can do better than ntp:

chrony can perform usefully in an environment where access to the time reference is intermittent. ntp needs regular polling of the reference to work well.

chrony can usually synchronise the clock faster and with better time accuracy.

chrony quickly adapts to sudden changes in the rate of the clock (e.g. due to changes in the temperature of the crystal oscillator). ntp may need a long time to settle down again.

chrony can perform well even when the network is congested for longer periods of time.

chrony in the default configuration never steps the time to not upset other running programs. ntp can be configured to never step the time too, but in that case it has to use a different means of adjusting the clock (daemon loop instead of kernel discipline), which may have a negative effect on accuracy of the clock.

chrony can adjust the rate of the clock in a larger range, which allows it to operate even on machines with broken or unstable clock (e.g. in some virtual machines).

chrony is smaller, it uses less memory and it wakes up the CPU only when necessary, which is better for power saving.

Things chrony can do that ntp can’t:

chrony supports the Network Time Security (NTS) authentication mechanism.

chrony supports hardware timestamping on Linux, which allows an extremely stable and accurate synchronisation in local network.

chrony provides support for isolated networks whether the only method of time correction is manual entry (e.g. by the administrator looking at a clock). chrony can look at the errors corrected at different updates to work out the rate at which the computer gains or loses time, and use this estimate to trim the computer clock subsequently.

chrony provides support to work out the gain or loss rate of the real-time clock, i.e. the clock that maintains the time when the computer is turned off. It can use this data when the system boots to set the system time from a corrected version of the real-time clock. These real-time clock facilities are only available on Linux, so far.

Things ntp can do that chrony can’t:

ntp supports all operating modes from RFC 5905, including broadcast, multicast, and manycast server/client. However, the broadcast and multicast modes are inherently less accurate and less secure (even with authentication) than the ordinary server/client mode, and should generally be avoided.

ntp supports the Autokey protocol (RFC 5906) to authenticate servers with public-key cryptography. Note that the protocol has been shown to be insecure and has been obsoleted by NTS (RFC 8915).

ntp has been ported to more operating systems.

ntp includes a large number of drivers for various hardware reference clocks. chrony requires other programs (e.g. gpsd or ntp-refclock) to provide reference time via the SHM or SOCK interface.