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 |