Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: ntpd configuration question
Date: Thu, 23 Mar 2006 08:59:43 -0700
David Fellows posted <200603230252.k2N2qG8r017703@...>,
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@...
#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:
Re: Re: ntpd configuration question
-- P.V.Anthony
Re: ntpd configuration question
-- Steve Herber
References:
ntpd configuration question
-- Peter Humphrey
Re: ntpd configuration question
-- David Fellows
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: ntpd configuration question
Next by thread:
Re: ntpd configuration question
Previous by date:
help needed.
Next by date:
Re: ntpd configuration question


Updated Jun 17, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.