NTP Patches Flaws That Enable DDoS
threatpost.com
threatpost.com
I'm on a home cablemodem connection. All internal NTP traffic is redirected to my OpenBSD firewall, which is a client of 6 different NTP servers (including time.apple.com and some from us.pool.ntp.org).
Right now my firewall's offset to the 6 servers is in the range of -6 ms to +8 ms. The delay to them varies between 26 ms and 95 ms.
All in all, works great for me, and for many other people. And with a much lower attack surface than the reference NTP implementation.
It's good to have alternatives.
Has your computer ever selected one of the apple servers to be the truechimer? I always thought the apple servers were kind of crappy.
The OpenBSD ntpd implementation doesn't strive for perfection, rather for "good enough". So its selection algorithm might not meet with Mills' approval.
OpenBSD frequently selects one of the Apple servers. Previously I've seen about 12 or 14 different Apple NTP servers being returned by DNS, including places like Singapore and London. Recently, Apple has changed this and now presents about 4 or 5 different servers. As of this moment, my firewall in Oregon is using an Apple NTP server in NYC as its truechimer: 17.253.14.253.
The delay to some of the far-flung Apple servers is well over 100 ms, but the jitter to them is usually quite low, often below about 3 ms. I would agree that delay isn't that relevant, but it intertwines with jitter. In this case, whatever the network topologies that are involved, the jitter usually stays low. Apple's network/peering with Comcast is pretty good in that regard.
As for Microsoft NTP servers (someone responded to you about that), I've previously had bad luck with them. time.windows.com resolves to something at Akamai, and it has been very hit or miss. Often not responding. Often being 100 ms off from other servers. I don't keep time.windows.com in my ntpd config file even though I use Microsoft software and thereby am somewhat "entitled" to use it. I don't know if Akamai has upped its game in recent years.
Recently I've seen 131.107.13.100 show up as part of the US NTP pool. This is time-nw.nist.gov, which is a stratum 1 hosted by Microsoft in Redmond. My experience is that server is almost invariably running about +8 ms from most other servers I'm using. This despite the latency being very low, usually around 20 ms. I'm happy to keep using it as part of the pool, but I don't see how it is any better than the other servers out there.
The first time I saw this was fairly recently but I've seen a few more instances since then, which may be an indication that this will become more widely used in the future.
Ensure that you've disabled unnecessary services and put a (default deny) firewall in front of your servers, for fuck's sake!
Please ensure that packets with spoofed source can not leave your network.
If you don't know _exactly_ why you need ntpd, the default should be openntpd.
Triangular routing is a use case which becomes lost. As does the the ability to easily set up certain kinds of peering/multihoming connectivity.
The larger and more complex a network gets, the harder it can become to determine if a source IP is "correct".
On the low end (small ISPs with zero or a handful of downstream ASes), people aren't aware or are too lazy to implement egress ACLs. Complicating this: A surprising number of small ISPs and telcos don't actually staff for internet routing skills (e.g. can work with BGP & have heard of a BCP). They'll bring on a consultant to "turn up my new circuit" and move on. If the first consultant sets up egress ACLs and they get a new netblock chances are the next consultant will just remove the ACL instead of updating it...
Medium to large ISPs: IRRs are supposed to solve this but implementation is spotty / OMG scripting changes on routers / etc. http://www.irr.net/docs/list.html
High end: I've heard that some providers have so many customers landing on a given aggregation router that the ACLs from IRRs end up too large for the router.
Cogent's approach is to require a LOA for the subnets that you are announcing and filter out everything else. This seems reasonable, though it gets annoying when you have a downstream AS that has downstream ASes (BUT that's fairly uncommon).
I use egress ACLs that allow my RIR-issued and downstream customer blocs and drop everything else. I have a friend that runs a slightly larger ISP (5x more downstream ASes) that does automation with IRRs.