server 0.nl.pool.ntp.org
server 1.nl.pool.ntp.org
server 2.nl.pool.ntp.org
server 3.nl.pool.ntp.org
Or for Africa
server 0.za.pool.ntp.org
server 1.za.pool.ntp.org
server 2.za.pool.ntp.org
server 3.za.pool.ntp.org
Matthew
I have a bunch of servers all over Europe I’d prefer not to touch if this is just a transient issue. I was speaking about Europe. There is no problem in Africa. Mark.
I am not sure why it would be inserted into DNS answers for a worldwide pool like 0.freebsd as it clearly does have connectivity issues from some of the pool project’s own sensors.
-andreas
You might consider setting up your own GPS-based NTP network. Commercial Ethernet GPS-sourced NTP servers, such as the Time Machines, TM1000A, are as little as $400. Or you can roll your own using a Raspberry Pi or similar nano computer with a GPS module and antenna. We use these exclusively in data centers now rather than depending on Internet NTP servers, primarily for security, because financial transactions in e-commerce can be sensitive to false time information. There are also a variety of NTP-based Internet attacks, so if you can block NTP at your border you’ve eliminated another attack surface.
If the path has simmetric one way latencies you don’t have to pick a lower latency faulty one. Perhaps creating a selection at startup and then using that collection ?
GPS time is monitored (and when necessary, adjusted) from the U.S.
Naval Observatory Master Clock, which is -the- authoritative time
source for the United States. The USNO also provides an NTP time
source from the same master clock:
You -should not- just point your servers there, but it's useful to
point a few servers each at one of them in order to serve as your
network stratum 2 sources that keep the rest of your machines in sync
with each other.
That last point is key. You don't want your servers in sync with
random Internet time sources. You want them in sync with each other.
There are also replay and Man in the middle attacks (MITM) which can corrupt local NTP servers’ time basis. Worse, security flaws in NTP make others security protocols, such as SSL, vulnerable.
That still leaves you open to NTP attacks. The USNO accuracy and monitoring is worthless if you suffer, for example, an NTP DDoS attack.
Hi Mel,
From what I can tell, a fairly simple firewall policy of allow UDP 123
from known NTP clients and established connections (I sent them a UDP
packet recently) stops every one of those attacks (that's actually an
NTP attack and not something else like a DNS attack) except for
upstream address hijack that happens to coincide with your system
boot. And it still depends on the attacker executing an additional
sophisticated attack to do more than cause you a denial of service.
The links you sent are very interesting, at least in an academic
sense, but they don't cause me to be unduly concerned about employing
NTP.
if you can eliminate such security problems for $400, I say it’s cheap at twice the price.
Except you can't. Redundancy is required for any critical service. At
the $400 price point, your approach has multiple
single-points-of-failure. The device itself of course. Your ability to
receive continuous non-jammed GPS signals at the location where you're
able to place an antenna. And in your plan you'll need one of these in
every discontiguous network where you have equipment since you're not
doing NTP over the Internet.
Not to mention the operations cost. Keeping track of a six inch brick
with a wall wart and an antenna installed at a remote site is... not
entirely abnormal but it's a one-off that consumes manpower.
And then you're only vulnerable to the litany of Internet attacks
which don't involve NTP. Yay!
Don't get me wrong: the Time Machines TM1000A you recommended looks
like a cool little device well worth checking into. As a supplement to
Internet NTP, not a replacement.
Due to flaws in the NTP protocol, a simple UDP filter is not enough. These flaws make it trivial to spoof NTP packets, and many firewalls have no specific protection against this. in one attack the malefactor simply fires a continuous stream of NTP packets with invalid time at your firewall. When your NTP client queries the spoofed server, the malicious packet is the one you likely receive.
That’s just one attack vector. There are several others, and all have complex remediation. Why should people bother being exposed to the risk at all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve already described. Having suffered through such attacks more than once, I can say from personal experience that you don’t want to risk it.
A carefully selected set of stratum 0 sources for a set of stratum 1 servers is the heart of good NTP source design. With at least four “local” stratum 1 servers, Dr. Mills algorithm is excellent at distinguishing truechimers from falsetickers and providing a reliable source of monotonic time. DOS is a separate problem.
My NTP network deployment experience for a major auto manufacturer, among others, is in agreement with William Herin. A GPS NTP source is a valid Stratum 0 source, but relying on a single instance for local time is not exceedingly better than querying time.apple.com or a similar source.
Respectfully, that Wikipedia article (which is mostly about legit but unauthorized clients overwhelming a given peer) and your cites don’t seem to cover what I was responding to - the “don’t peer with public NTP because someone can flood your firewall and spoof the responses” problem. I just want to make sure that I’m understanding the distinction betwen this class and other classes of attack.
Wouldn’t a robust implementation of peering - say, seven peers, with the NTP algorithm handily selecting a subset to peer with for each cycle - require an attacker to know and overwhelm not just one, but a majority of the peer IPs?
This is not to say that I’m advocating against maintaining local stratum 0s as part of a proper operator-grade NTP mesh. (My definition of “robust implementation” would include both local stratum 0 and a healthy serving of Internet stratum 1s). I’m just suggesting “don’t peer with public servers” seems draconian given the deliberate design choices of the protocol.
For this audience, this would recommend a tiered system where multiple mixed-stratum internal stratrum 0+1s would peer with each other, and maintain internal-facing consensus for all other downstream internal devices - such that the vast majority of internal peers would indeed not be talking to the public Internet (but the “parent” peers would, and have the mesh and mix that I describe).
And I’m well aware of who I’m saying this to … so I expect to find out where I’m wrong, as I keep digging.
This entirely discounts the fact that bcp-38 and bcp-84 which, more or less, eliminate this “problem space” entirely.
I find it hard to believe ntp reflection is actually a problem in the year 2023, assuming you’re not running a ridiculously old ntp client and have taken really simple steps to protect your network.
… isn’t robust diversity of NTP peering a reasonable mitigation for this, as designed?