Re: [chrony-users] Pros and Cons of acquisitionport directive

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Wed, Aug 10, 2016 at 08:04:20PM +1200, Bryan Christianson wrote:
> I have been observing chronyd with a profiler (Apple Instruments - gui to dtrace) and noticed that open/close operations on the client sockets was responsible for 80% of the time used. It seems to take the kernel a while to cleanup a socket on close.
> 
> I have specified acquisitionport in the config and resource use is significantly better.

How much is that as a percentage of CPU time?

> What are the disadvantages of using a non-random port? Security is my first guess (i.e. I have opened up a listening port for use as an attack surface) but are there any other disadvantages?

I think it's just security.

With fixed acquisitionport there is only one client socket (per
IPv4/IPv6), which is always open and it's not connected. This means an
attacker can send packets that will reach the chronyd process at any
time from any address. If you don't use a well-known port number (e.g.
123 like ntpd does) and the attacker doesn't have an access to one of
the servers you are using or have some other way to get that number,
the attacker would need to send you about 2^15 packets to get one to
chronyd.

When acquisitionport is not set, the socket is connected and it's
closed after receiving a good response, so there are more variables
that need to be guessed in order to get a packet to chronyd. It
needs to be sent at the right time, with right port number and right
source address. For example, if you used four pool.ntp.org servers
from a zone that has 100 servers (assuming they are distributed over
DNS uniformly), used a 1024 second polling interval and the roundtrip
time was 100 milliseconds, the number of packets the attacker would
have to send you before one reached chronyd would now be somewhere in
billions.

Of course, packets from attackers reaching chronyd running as an NTP
client shouldn't normally be a problem as the origin timestamp has to
match the transmit timestamp of the request to accumulate a sample for
synchronization of the clock. chronyd randomizes all 64 bits of the
transmit timestamp in client mode packets, so in the example described
above the attacker would have to send somewhere around 2^95 packets to
actually inject one false sample. And there are multiple sources, so
one false sample wouldn't do much harm anyway.

-- 
Miroslav Lichvar

-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.