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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.