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
1 David Fellows posted <200603230252.k2N2qG8r017703@××××××××××××.ca>,
2 excerpted below, on Wed, 22 Mar 2006 22:52:15 -0400:
3
4 > Following are the non-comment lines from my /etc/ntp.conf. I have
5 > changed the values that define the real external server that I sync
6 > with. My guess is you are missing the "restrict default ignore" line in
7 > yours. My policy is for one machine to sync with the external world, but
8 > not to serve to the external world. Internally other machines sync
9 > against this machine. I do have firewall between the local ntp server
10 > that blocks all externally initiated traffic so maybe I have a bug in my
11 > config that has never been probed, but I have been using a variant of
12 > this for many years - pre-gentoo.
13 >
14 > server ntp.extern.server prefer #dmf 2004-08-17
15 > server 127.127.1.0 #local clock a la Fedora 2
16 > fudge 127.127.1.0 stratum 10 #a la Fedora 2
17 >
18 > driftfile /var/lib/ntp/ntp.drift
19 >
20 > restrict default ignore
21 >
22 > restrict 127.0.0.1 # allow local control
23 >
24 > restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap #allow local network machines to sync to us
25 > restrict 999.888.0.0 mask 255.255.0.0 nomodify #so we can sync with external server
26
27 Some suggestions, altho I'm not an expert and don't claim to be, and you
28 may have good reasons for your choices:
29
30 1 Check the docfile accopt.html (/usr/doc/ntp-ver/html/accopt.html) and
31 compare "nomodify" with "noquery". noquery is stricter and more secure,
32 unless you have reason to allow the servers you sync with to get info but
33 without allowing modification from your server, in which case nomodify is
34 correct.
35
36 2 Consider a stricter netmask on the sync-server (999.888 network above),
37 again, unless you have a specific reason not to. Here's the format of my
38 sync server entries, keeping everything in one place:
39
40 server host.sample.com
41 #location Anywhere, AA (that's the state, US based) #contact
42 support@××××××.com
43 #notify not req.
44 #server 000.000.000.000 (this was the IP address when I set it up)
45 restrict host.sample.com noquery
46
47 This as I said keeps everything in one place, including contact info and
48 whether notification was requested or not when I setup. However, the
49 thing to note here is that I'm specifically "unignoring" /only/ that
50 specific host, not an entire /16 subnet. Also note that depending on who
51 you are syncing from, the IP address can change while the domain name
52 remains the same, so the NTP docs suggest using the domain name. It
53 appears you do in the server entry, but not in the restrict entry, so it's
54 possible the IP address could change out from under you. Of course, if
55 it's someone you control or are in close enough contact with to get
56 notification if that happens, that's fine, but... . One exception to the
57 host-only restriction would be if that host resolves to a server farm of
58 several possible IP addresses. However, one hopes it should still be
59 possible to reduce the netmask to something smaller than a /16, perhaps a
60 /8 or smaller (unless it's the global ntp pool, in which case a /16 seems
61 incorrect). Of course, in that case it /would/ remain an IP subnet as
62 opposed to a domain address in the restrict, as there'd be little you
63 could do about it.
64
65 3 For failsafe, consider at least one additional secondary sync server,
66 assuming you aren't simply using pool.ntp. It's nice to have sync keep
67 working if a particular host goes dark. If you wish, set the stratem or
68 the prefer keyword such that your preferred server remains dominant, or
69 simply let ntpd decide on its own based on network conditions which one it
70 wishes to sync to -- it's designed to do this well. Ideally, choose your
71 backup sync server from someplace located rather far from your primary
72 sync server, both internet-wise (different IP space, ISP, and backbone)
73 and physically (different state or nation), so it's less likely that both
74 go down at once. The internet is designed to be fault tolerant, might as
75 well take advantage of that (realizing of course that the most likely
76 issue would be one's own connection, certainly for a home connection and
77 likely for a biz without redundant connectivity arranged, and the fault
78 tolerance of the general internet won't help in that case). Having three
79 sync servers in widely differing locations is good, but at least a primary
80 and a backup would be preferred over a single server, unless of course
81 it's the pool, in which case you would have had little reason to munge the
82 server line above.
83
84 ...
85
86 In reply to the OP, I too was worried about this, so did my own
87 investigation. I don't believe it's possible to set ntpd not to listen at
88 all on an interface (tho of course packets to it can be blocked by
89 netfilter or the like), only to ignore IPs and subnets, altho I'm open to
90 being proved wrong (and I've certainly learned from past exchanges, you
91 tend to know as much or more than I about a subject and this may be no
92 different, I'm no expert nor do I claim to be). The config file has
93 provisions for setting IP network ignores, but unfortunately, has no way
94 to tell it what interface(s) to listen on or not.
95
96 That isn't quite as bad as it sounds, because NTP is a UDP based protocol,
97 and UDP is connectionless. If ntpd is set to ignore IPs globally, set to
98 noquery for the specific hosts it syncs to, and set appropriately for the
99 hosts allowed to query or control, a UDP probe on the listening port from
100 anywhere else will be ignored due to that global setting, so there will be
101 no way for the prober to know there's even anything listening on that port
102 since UDP being connectionless wouldn't be expected to return an ACK/NACK
103 in any case. Proper routing should take care of IP spoofing of an IP on
104 other interfaces, so again, the probe wouldn't get a response and the
105 prober would have no way of knowing that the port was open
106
107 That said, for a network border machine, setting up appropriate
108 firewall/netfilter rules should prevent probe packets even getting to the
109 listening ntpd in the first place, and as you are already running the
110 machine as a firewall so should have a firewall configuration already
111 active, that shouldn't be difficult.
112
113 --
114 Duncan - List replies preferred. No HTML msgs.
115 "Every nonfree program has a lord, a master --
116 and if you use the program, he is your master." Richard Stallman in
117 http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
118
119
120 --
121 gentoo-amd64@g.o mailing list

Replies

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