IPFW Proper NTPD and IPFW configuration

dnb

dnb

I'm worried about excessive NTPD activity in the security log on a freshly installed system. I have the following ntpd settings in /etc/rc.conf:
Code: 
ntp_leapfile_expiry_days=30
ntp_leapfile_fetch_opts="-mq"
ntp_leapfile_fetch_verbose="NO"
ntp_leapfile_sources="https://www.ietf.org/timezones/data/leap-seconds.list"
ntpd_enable="YES"
# ntpd_sync_on_start="YES"

The configuration file /etc/ntp.conf has not changed, it is the same as it was when the system was installed.

My ipfw settings for NTPD are as follows:
Code: 
# outbound
/sbin/ipfw -q add allow log udp from any to any 123 out via $extif keep-state # ntpd
/sbin/ipfw -q add deny log all from any to any out via $extif

As a result, in /var/log/security, I see massive constant appeals of the freshly established system to various servers through port 123 (here's an example in a couple of minutes, 111.222.333.444 is me):

Code: 
May 15 21:58:30 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 116.203.244.102:123 out via vtnet0
May 15 21:58:30 test kernel: ipfw: 600 Accept UDP 116.203.244.102:123 111.222.333.444:123 in via vtnet0
May 15 21:58:31 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 85.214.38.116:123 out via vtnet0
May 15 21:58:31 test kernel: ipfw: 600 Accept UDP 85.214.38.116:123 111.222.333.444:123 in via vtnet0
May 15 21:58:32 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 91.107.199.28:123 out via vtnet0
May 15 21:58:32 test kernel: ipfw: 600 Accept UDP 91.107.199.28:123 111.222.333.444:123 in via vtnet0
May 15 21:58:33 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 129.250.35.250:123 out via vtnet0
May 15 21:58:33 test kernel: ipfw: 600 Accept UDP 129.250.35.250:123 111.222.333.444:123 in via vtnet0
May 15 21:58:34 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 85.214.127.75:123 out via vtnet0
May 15 21:58:34 test kernel: ipfw: 600 Accept UDP 85.214.127.75:123 111.222.333.444:123 in via vtnet0
May 15 21:58:37 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 51.75.67.47:123 out via vtnet0
May 15 21:58:37 test kernel: ipfw: 600 Accept UDP 51.75.67.47:123 111.222.333.444:123 in via vtnet0
May 15 21:58:38 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 212.18.3.19:123 out via vtnet0
May 15 21:58:38 test kernel: ipfw: 600 Accept UDP 212.18.3.19:123 111.222.333.444:123 in via vtnet0
May 15 21:58:42 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 188.40.142.18:123 out via vtnet0
May 15 21:58:42 test kernel: ipfw: 600 Accept UDP 188.40.142.18:123 111.222.333.444:123 in via vtnet0
May 15 21:59:37 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 116.203.244.102:123 out via vtnet0
May 15 21:59:37 test kernel: ipfw: 600 Accept UDP 116.203.244.102:123 111.222.333.444:123 in via vtnet0
May 15 21:59:38 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 85.214.38.116:123 out via vtnet0
May 15 21:59:38 test kernel: ipfw: 600 Accept UDP 85.214.38.116:123 111.222.333.444:123 in via vtnet0
May 15 21:59:40 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 85.214.127.75:123 out via vtnet0
May 15 21:59:40 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 91.107.199.28:123 out via vtnet0
May 15 21:59:40 test kernel: ipfw: 600 Accept UDP 91.107.199.28:123 111.222.333.444:123 in via vtnet0
May 15 21:59:40 test kernel: ipfw: 600 Accept UDP 85.214.127.75:123 111.222.333.444:123 in via vtnet0
May 15 21:59:41 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 129.250.35.250:123 out via vtnet0
May 15 21:59:41 test kernel: ipfw: 600 Accept UDP 129.250.35.250:123 111.222.333.444:123 in via vtnet0
May 15 21:59:43 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 51.75.67.47:123 out via vtnet0
May 15 21:59:43 test kernel: ipfw: 600 Accept UDP 51.75.67.47:123 111.222.333.444:123 in via vtnet0
May 15 21:59:47 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 212.18.3.19:123 out via vtnet0
May 15 21:59:47 test kernel: ipfw: 600 Accept UDP 212.18.3.19:123 111.222.333.444:123 in via vtnet0
May 15 21:59:48 test kernel: ipfw: 600 Accept UDP 111.222.333.444:123 188.40.142.18:123 out via vtnet0
May 15 21:59:48 test kernel: ipfw: 600 Accept UDP 188.40.142.18:123 111.222.333.444:123 in via vtnet0

Q: Is this NTPD activity normal? Are my IPFW settings for NTPD sufficient and safe?
 
SirDice said:
Why do you think it's "excessive"?
Click to expand...
From the ntpd(8) documentation, I was able to find out that:

The ntpd utility is an operating system daemon which sets and maintains the system time of day in synchronism with Internet standard time servers.

Q: Is it really necessary to make about 8 exchanges of information with third-party servers per minute in order to set and maintain the system time?
 
Answering your Q: It depends.
The client side of NTPD has to talk to (poll) configured servers to get and set your system time, it talks to each server every time.
The client has a "minpoll" and a "maxpoll" representing the minimum time in seconds between polling and the maximum time. I think the default values are minpoll = 64 and maxpoll = 1024.
When it first starts it polls every minpoll seconds, then gradually increases the interval to maxpoll based on a bunch of different things, but roughly as the local clock gets "better" the interval increases.
Depending on the servers (quality) and the network between the client side and server side it may stay every minute for a while.

On my systems running OpenNTPD the polling starts at 64s intervals, but gradually increases to about 1600s. It t ypically takes an hour or so after a reboot to get maxed out. If after a day or more of running your polling interval stays at around the 64s, something is going on with the network or the quality of the servers such that NTPD can't get your local clock "good enough" to stretch it out.
An easy thing to do is check the servers you are using, make sure you are using a pool, setting iburst helps speed up initial synchronization. Trivial to change the pool used, I think the default is 0.freebsd.pool.ntp.org which you may want to switch to something more local to you like a "Country" pool.

This stackoverflow has some good info, with links to the RFCs:
stackoverflow.com

How does NTP calculates its next polling interval

I tried reading NTPv4 RFC 4905. I cant seem to understand on what basis it is calculating next polling interval to send NTP request packets to its peer. What is the role of ppoll and hpoll in find...
stackoverflow.com stackoverflow.com
 
  • Thanks
Reactions: dnb
mer said:
The client side of NTPD has to talk to (poll) configured servers to get and set your system time, it talks to each server every time.
Click to expand...
Also note that the default pool 0.freebsd.pool.ntp.org iburst is a pool of servers, it's not just one. Each server in the pool is queried. Add the iburst and you get lots of requests.

Code: 
     iburst  When the server is unreachable, send a burst of eight packets
             instead of the usual one.  The packet spacing is normally 2 s;
             however, the spacing between the first two packets can be changed
             with the calldelay command to allow additional time for a modem
             or ISDN call to complete.  This is designed to speed the initial
             synchronization acquisition with the server command and s
             addresses and when ntpd(8) is started with the -q option.
 
Yep on the burst/iburst. My understanding is the flurry of packets should only be happening after NTPD starts and until something in the algorithm decides "ok good enough" then you go to single packets to each server in the pool.
 
  • Thanks
Reactions: dnb
You must log in or register to reply here.
Back
Top