Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: ntpd configuration question
Date: Thu, 23 Mar 2006 16:03:37
Message-Id: pan.2006.03.23.15.59.39.630287@cox.net
In Reply to: Re: [gentoo-amd64] ntpd configuration question by David Fellows
David Fellows posted <200603230252.k2N2qG8r017703@××××××××××××.ca>,
excerpted below,  on Wed, 22 Mar 2006 22:52:15 -0400:

> Following are the non-comment lines from my /etc/ntp.conf. I have > changed the values that define the real external server that I sync > with. My guess is you are missing the "restrict default ignore" line in > yours. My policy is for one machine to sync with the external world, but > not to serve to the external world. Internally other machines sync > against this machine. I do have firewall between the local ntp server > that blocks all externally initiated traffic so maybe I have a bug in my > config that has never been probed, but I have been using a variant of > this for many years - pre-gentoo. > > server ntp.extern.server prefer #dmf 2004-08-17 > server 127.127.1.0 #local clock a la Fedora 2 > fudge 127.127.1.0 stratum 10 #a la Fedora 2 > > driftfile /var/lib/ntp/ntp.drift > > restrict default ignore > > restrict 127.0.0.1 # allow local control > > restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap #allow local network machines to sync to us > restrict 999.888.0.0 mask 255.255.0.0 nomodify #so we can sync with external server
Some suggestions, altho I'm not an expert and don't claim to be, and you may have good reasons for your choices: 1 Check the docfile accopt.html (/usr/doc/ntp-ver/html/accopt.html) and compare "nomodify" with "noquery". noquery is stricter and more secure, unless you have reason to allow the servers you sync with to get info but without allowing modification from your server, in which case nomodify is correct. 2 Consider a stricter netmask on the sync-server (999.888 network above), again, unless you have a specific reason not to. Here's the format of my sync server entries, keeping everything in one place: server host.sample.com #location Anywhere, AA (that's the state, US based) #contact support@××××××.com #notify not req. #server 000.000.000.000 (this was the IP address when I set it up) restrict host.sample.com noquery This as I said keeps everything in one place, including contact info and whether notification was requested or not when I setup. However, the thing to note here is that I'm specifically "unignoring" /only/ that specific host, not an entire /16 subnet. Also note that depending on who you are syncing from, the IP address can change while the domain name remains the same, so the NTP docs suggest using the domain name. It appears you do in the server entry, but not in the restrict entry, so it's possible the IP address could change out from under you. Of course, if it's someone you control or are in close enough contact with to get notification if that happens, that's fine, but... . One exception to the host-only restriction would be if that host resolves to a server farm of several possible IP addresses. However, one hopes it should still be possible to reduce the netmask to something smaller than a /16, perhaps a /8 or smaller (unless it's the global ntp pool, in which case a /16 seems incorrect). Of course, in that case it /would/ remain an IP subnet as opposed to a domain address in the restrict, as there'd be little you could do about it. 3 For failsafe, consider at least one additional secondary sync server, assuming you aren't simply using pool.ntp. It's nice to have sync keep working if a particular host goes dark. If you wish, set the stratem or the prefer keyword such that your preferred server remains dominant, or simply let ntpd decide on its own based on network conditions which one it wishes to sync to -- it's designed to do this well. Ideally, choose your backup sync server from someplace located rather far from your primary sync server, both internet-wise (different IP space, ISP, and backbone) and physically (different state or nation), so it's less likely that both go down at once. The internet is designed to be fault tolerant, might as well take advantage of that (realizing of course that the most likely issue would be one's own connection, certainly for a home connection and likely for a biz without redundant connectivity arranged, and the fault tolerance of the general internet won't help in that case). Having three sync servers in widely differing locations is good, but at least a primary and a backup would be preferred over a single server, unless of course it's the pool, in which case you would have had little reason to munge the server line above. ... In reply to the OP, I too was worried about this, so did my own investigation. I don't believe it's possible to set ntpd not to listen at all on an interface (tho of course packets to it can be blocked by netfilter or the like), only to ignore IPs and subnets, altho I'm open to being proved wrong (and I've certainly learned from past exchanges, you tend to know as much or more than I about a subject and this may be no different, I'm no expert nor do I claim to be). The config file has provisions for setting IP network ignores, but unfortunately, has no way to tell it what interface(s) to listen on or not. That isn't quite as bad as it sounds, because NTP is a UDP based protocol, and UDP is connectionless. If ntpd is set to ignore IPs globally, set to noquery for the specific hosts it syncs to, and set appropriately for the hosts allowed to query or control, a UDP probe on the listening port from anywhere else will be ignored due to that global setting, so there will be no way for the prober to know there's even anything listening on that port since UDP being connectionless wouldn't be expected to return an ACK/NACK in any case. Proper routing should take care of IP spoofing of an IP on other interfaces, so again, the probe wouldn't get a response and the prober would have no way of knowing that the port was open That said, for a network border machine, setting up appropriate firewall/netfilter rules should prevent probe packets even getting to the listening ntpd in the first place, and as you are already running the machine as a firewall so should have a firewall configuration already active, that shouldn't be difficult. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@g.o mailing list

Replies

Subject Author
Re: [gentoo-amd64] Re: ntpd configuration question "P.V.Anthony" <pvantony@×××××××××××.sg>
[gentoo-amd64] Re: ntpd configuration question Steve Herber <herber@×××××.com>