ntp config tech note

Mailman List Mirror (Read Only)
21

C. Jon Larsen wrote:
[snip]

Its interesting to hear what other folks are doing. I had assumed folks normally don't run ntpd on each and every server and that ntpdate + cron was much preferred; maybe I am off-base.

After the last "big" xntpd vulnerability a few years ago, I went through
and made sure that I had the permissions set appropriately,

restrict <server1> noquery nomodify
restrict <server2> noquery nomodify
...
restrict 127.0.0.1 nomodify
restrict default ignore

On UNIXen servers. Of course, I upgraded my daemons where possible, but
the vulnerability occurred late enough in the message processing that the
approprate restrictions prevented exploit (the packet was dropped before
the vulernable code was reached).

Of course, there still is the potential for vulnerabilities very, very early
in message processing, or in spoofed query responses if someone knows what
servers I use and is behind the firewall. But overall, I like it much better
than what the UNIX admin here used to do,

   0 2 * * * rdate timehost

22

My personal feeling was that for most systems its better to not have the
daemon running - i.e. the benefit of smaller more frequent clock
adjustments does not outweigh the cost of another service running,
especially as root or even as a jailed non-root user.

Well, present NTP drops to a nonroot user after it sets the time &
proprer use of the very flexable ACL lists in your ntp.conf should help
midigate
non-local NTP exploits, ie, don't offer NTP service to the world or anyone
else
for that matter.

I need better than one second resolution for syslog and other loging info to
be useful
in debugging problems across multiple hosts.

23

Hi John:

John Kristoff wrote:

I run two stratum-1 servers and a few stratum-2s and I provide time via multicast (224.0.0.1), but I don't use it for my servers, except for

Presumably you meant 224.0.1.1.

Yep, sorry.

testing and verification. I am also providing anycast ntp, and, if the belt and suspenders weren't enough, I am experimenting with manycast.

Noting that NTP uses more than a reply response message exchange. No
concerns about session breakage? SNTP would certainly be a very
viable candidate for anycast.

Yes it is. Session breakage doesn't seem to be a problem, as long as you're per-flow traffic sharing for equal-cost routes across your backbone. I can see where per-packet switching would make a mess of things, but that's true with any anycast service. Also, if the flow table entry ages out before the next NTP poll, I can see how a client running a full-blown ntpd would probably perceive an otherwise transparent switch back and forth between two servers as excess jitter. If you're worried about this, then one way around it would be to adjust the costs of your injected routes so that one server is always preferred over another. In that case, you're not buying load-distribution across servers, but backup for clients where ease of configuration is more important that accuracy, but where reliability (ability to poll at least one server all the time) is still important, and multicast may or may not provide the level of reliability that you need. (I am a fan of multicast, BTW.)

In our case it's useful, as you note, for pointing an increasing number of SNTP clients (including network equipment) to one address that's reliable and redundant.

I know there are others who have experience in doing NTP anycast, at least within an enterprise, and perhaps as service provider, who can probably comment.

Except in the extreme case such as wisc.edu's unfortunate experience,
does multicast buy much? Traffic loads for properly running clients
and distributed servers tend to be relatively low in my experience.

Yes. The main "buy" is ease of configuration, and that holds for multicast, manycast, and anycast. I get a lot of requests for providing NTP in such a way that sysadmins and users can use a really simple bootstrap configuration in clients that they can replicate across their enterprise. I'll also note that some OS vendors ship a stock multicast config for their (x)ntpd.

I have found that load can get higher when you start hammering servers with thousands of SNTP clients; it can be something of an issue considering that NTP servers tend to be hand-me-down hardware. (BTW: Is rackety.udel.edu still a Sun IPC?) So, my "problem" is, how can I properly distribute the load across servers, increase reliability, and still give users simplicity in their configuration? Each of the three solutions has its own set of pros and cons:

manycast - probably the best solution; solves authentication and possible session issues with anycast, more accurate than multicast, since true associations are established with (hopefully) several participating servers. Downside is that it's only supported in v4, which not all vendor OSes have as their stock daemon; doesn't work with SNTP.

anycast - probably best solution for SNTP clients, may also be useful for not v4 clients that can't do manycast. May break authentication, depending on how keys are managed, but I haven't actually tested this. (If all anycast servers have the same key pair, will authentication break if a client switches servers due to a routing change? I haven't tested this yet.)

multicast - Still a good solution for v3 clients that want simple configuration. A lot of people still *ask* about multicast NTP, since that's the config some OS vendors ship.

Then of course, there's the good old configure-4+-ntp-servers-manually, which is good for important boxes that really need good time. (I have one box that does all three of the above, plus has manually configured servers.)

Any thoughts or comments on the advantages and disadvantages of the above techniques are welcome, as well as corrections.

michael

24

I would be very worried about forcing an unchecked clock sync against a single
time source in this way.. if your source is broken you can break a lot..

i think the limit is 1000s so you shouldnt be slipping by that much unless
something is broken?

Steve

25

It needs to be set of trusted time sources that is as reliable as you feel is necessary.

If you're feeling extremely paranoid, then you can use the -g flag to peer with a number
of your private stratum 1 sources and then let the sanity checking do its job to
avoid any bogochimers.

Tony

26

you ask do folk run ntpd on every server.

i wonder if folk run ntpd on every router. i did and do.

We use ntp on every router for setting time. We don't run ntpd on every
server due to security concerns based on the idea that you can't have a
hole in a daemon you aren't running. This is relatively unnecessary I
suppose since ntpd is probably most commonly configured nowdays not to
listen on an exposed port by default.

Just out of curiosity... do you run bind on every server?

Mike.
ps. We run dedicated ntp boxes that don't have hard drives (thanx for the
recommendation a few years ago), again with the idea somebody can't
install a rootkit on box that doesn't have a hard drive. It's not perfect
or even necessary, just an optional precaution.

+----------------- H U R R I C A N E - E L E C T R I C -----------------+