I'm trying to help a company I work for to pass an audit, and we've
been told we need trusted NTP sources (RedHat doesn't cut it). Being
located in Nigeria, Africa, I'm not very knowledgeable about trusted
Please can anyone help with sources that wouldn't mind letting us sync
given that you trust the US-government (well, ...) you might use your own stratum 1 server using a Raspberry Pi with GPS.
here is a well done how-to:
I still need some spare time to get it running, all parts are here, but within my office location I have a bad GPS signal reception, so I have to do it at home.
So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), off from these servers build 2 or more stratum 2 timeservers for redistribution to offload your stratum 1 servers.
http://clepsydratime.com/Products/Time-Server-NTS3000 is a cool alternative. They are located in Poland, IIRC. And this box sells for less than 2,000 euros (this price is 2 years old). And it gives you GPS (USA), Glonass (Russia) and DCF77 (land based).
One of the best Timeservers are sold by meinberg.de
just my 2 euro-cents.
> I'm trying to help a company I work for to pass an audit, and we've
> been told we need trusted NTP sources (RedHat doesn't cut it). Being
> located in Nigeria, Africa,
So build your own stratum 1 server (maybe a second one with DCF77 or
whatever you can use for redundancy),
I don't think DCF77 is going to reach Nigeria.
The OP had a question about standards compliance, not about something that
made technical sense and would deliver a superior service. The two things
aren't incompatible, but they're not especially closely related either.
Raspberries! Not common currency here either, but let's see!
grateful for all the input and responses, this list is amazing as usual.
PCI DSS only requires that all clocks be synchronized; It doesn't
If you have servers getting time from external sources (authenticated
always a plus) and peering with each other internally, then you comply
with PCI DSS 2.0 (3.0 has no changes to this that I'm aware of).
OTOH, I'm surprised nobody has mentioned
If you read requirement 10.4 more carefully, you will find that it Does
require that time
be synchronized from an INDUSTRY ACCEPTED external time source.
The GPS reference clock, a radio timecode receiver, receiving NIST or USNO,
Microsoft's time source (time.windows.com),
Redhat's time source, various univerisities and other public time servers
listed on NTP.org,
the NIST time servers listed here:
Are among the INDUSTRY ACCEPTED external time sources.
This is not an exhaustive enumeration of industry-accepted external time
While I would be using a Pi if I were doing it now, a few years ago I put
together a circuit that used a <$100 outdoor mast-mount GPS receiver* with a
PPS out, to feed an RS232 connection to 3 FreeBSD 8.1 systems compiled with:
options PPS_SYNC #
I don't know if that is still required in 10.0, and I understand Linux has
since fixed the kernel time resolution issues it was having, so research
into current OS configuration is required. To make the local time reference
preferred over external references, in ntp conf:
server 127.127.20.1 mode 8 minpoll 4 maxpoll 4 prefer
The diagram is at http://tndh.net/~tony/GPS-PPS-5v-ttl_232-box.pdf
While there is 'some assembly required', the components to feed existing
servers may be easier to come by than a Pi, and an outdoor receiver will
have better reception than the Adafruit one stuck inside a datacenter.
As others have said, several external references help protect against any
one source having a bad day, but you should also be aware that network
asymmetry WILL impact your results so factor topology into your source
selection. Using this setup and OWAMP** I was able to track down a ~20ms
"peering asymmetry" between HE & Comcast "inside the Seattle Westin colo",
which still persists.*** It would appear from the time delay that one of
their intermediaries is not really present in the building, but using a
fiber loop to a city about 400 miles away (Boise, or Medford ??). I am not
aware of the specific topology, other than traceroute shows different
intermediaries in each direction at one IP hop, with one taking 20ms longer
than the other to move between the same HE & Comcast routers inside that
colo. What I can see is the impact it has of showing the IPv6 connected NTP
peers as ~10ms off of the local IPv4 ones & the GPS receiver.
** OWAMP >>> http://software.internet2.edu/owamp/
*** >ntpq -p
remote refid st t when poll reach delay offset