Do I need to open ports for NTP?

Question

I just noticed that my hwclock was off by nearly 30 seconds. It's almost certainly due to the recent initscripts update.
As I was looking into resetting the clock, I found out that openntpd is deprecated so I've switched to ntp, configured the daemon, reset the time with ntpd -q, and started the daemon. The time is not accurate again.
I remember back when I first installed Arch I tried to set up ntp but it didn't seem to work, so I tried openntpd and stuck with that. I reached the conclusion that ntp required open ports, which I felt was unnecessary given that openntpd could do the same thing without open ports.
Now that I'm looking at it again, I can't find any definitive answer...
Do I need to open ports for ntp if I only want to sync the system that it's running on?

Answer 1

ISC ntpd (the ntp package) will open UDP 123 on all your interfaces regardless of what you do with it. It will work anyway even if you block this port in iptables, assuming that you're allowing responses to established traffic as usual - your outbound mobilization requests to your chosen servers will be enough to allow the responses, and the same with further traffic sent for the lifetime of ntpd. Using iptables like this is probably the easiest way to secure ntpd.
There's also some defense in depth you can do:
- run ntpd as non-root
- run it chrooted to some safe directory (really only makes sense when doing non-root as well, since root can break out of a chroot)
- apply ntpd's built-in access controls (see examples in ntpd.conf, and full docs in ntp_acc(5))
I accomplish the first two of these by chowning /var/lib/ntp (and any contents) to ntp:ntp (so ntpd can write ntp.drift there when non-root), by using a driftfile path relative to the chroot in ntp.conf, and by setting NTPD_ARGS="-g -i /var/lib/ntp -u ntp:ntp" in /etc/conf.d/ntp-client.conf.
For the third, I chose to not allow any remote traffic to initiate anything with my ntpd, with this /etc/ntp.conf:
server ac-ntp0.net.cmu.edu iburst
server ac-ntp1.net.cmu.edu iburst
server ac-ntp2.net.cmu.edu iburst
server ac-ntp3.net.cmu.edu iburst
server ac-ntp4.net.cmu.edu iburst
restrict default nomodify nopeer noquery
restrict 127.0.0.1
driftfile /ntp.drift
Note the two "restrict" lines. The first shuts out remote access of most kinds, and the second allows the local machine all the access that would also be denied to it as well otherwise by the first rule. Note also the driftfile path, relative to the chroot of /var/lib/ntp/.
With all these security features, ISC ntpd can be just as safe as openntpd.
The use of the "iburst" keyword on the server lines to recover more quickly from out-of-contact conditions is also quite nice, and not rude to the remotes like "burst" would be.
One of the nicest other features of ISC ntpd is that it's smart enough to notice when network state changes occur, like bringing a VPN up/down, changing routes, or switching from wired to wireless and back. openntpd tended to just lose connections in these cases.