Re: [Fed-Talk] OS X as NTP Server
Re: [Fed-Talk] OS X as NTP Server
- Subject: Re: [Fed-Talk] OS X as NTP Server
- From: Michael Kluskens <email@hidden>
- Date: Mon, 15 May 2006 07:52:36 -0400
After studying the problem I discovered the problem is that the
standard OS X NTP configuration does not free run well at all so all
the machines I was pointing at my OS X machines had 127.127.1.0
(local clock) at a high enough stratum that they totally rejected the
OS X NTP servers.
My understanding is that I'll have to rewrite my OS X ntp.conf file
from time to time as OS X overwrites it. I had to add the following
to my OS X ntp.config files:
server 127.127.1.0
fudge 127.127.1.0 stratum 13
And bump all my Unix & Linux boxes down to:
server 127.127.1.0
fudge 127.127.1.0 stratum 20
I like the comments about the last NTP security hole. The issue is
not that it was easily blocked via ntp.config, the issue is that past
history has proven that holes are usually exploited for quite some
time before becoming known to more then a select few. I have
followed and managed Unix security for more then ten years and I can
guarantee you that not all security holes are disclosed--a number of
years ago I discovered one in X login authorization that bypassed all
host restrictions, lets say you configured a machine to permit X
logins from only your subnet, that's nice but one of the subroutines
enforcing that was empty, of course I'm assuming the issue has been
fixed--if you think this was a minor issue, well the DOD HPCC system
people didn't, a screen capture of a X login screen took them quite a
while to believe because it was impossible and that was for people
that were very skilled in configuring their systems securely.
Back to NTP, at least one vendor of a Linux/Unix machines ships a
ntp.conf in a unsecure configuration--a reading of a different
system's ntp.conf points out not to do that (good thing those systems
aren't connected to the internet). Being able to remotely interfere
with a system's clock is only one part of any number of different
attacks or denial of service attacks, including the resulting court
case if you get that far.
Thanks,
Michael
On May 11, 2006, at 7:25 PM, Rex Sanders wrote:
I'm not an expert, but I have played with NTP on Unix for many years.
- Make sure you have "Network Time" enabled in the Mac OS X built-
in firewall:
System Preferences > Sharing > Firewall >
Check the "Network Time" box.
And make sure you aren't blocking UDP in the Options.
- My desktop Mac OS X 10.4.6 is an open NTP server by default. I
can get
time from it, no authentication required. For example, using the Sun
server down the hall:
9* ntpdate -q -u 192.168.1.71
server 192.168.1.71, stratum 16, offset 2.381722, delay 0.02579
11 May 15:40:45 ntpdate[19555]: no server suitable for
synchronization found
which means my Mac is about 2.3 seconds off. Terrible by NTP
standards!
I don't have access to Mac OS X server, hope they have better ntp
performance.
- Debugging NTP problems almost always requires looking at the full
/etc/ntp.conf file. You can obfuscate DNS names and IP addresses
if you
are worried about security. Here's the /etc/ntp.conf file from my
desktop
Mac:
server tttttt.usgs.gov minpoll 12 maxpoll 17
Definitely a non-standard server (tttttt is a local NTP server);
most Macs
default point to "time.apple.com".
On NTP security:
- Just one NTP security hole was reported in the past 10 years, and
that
was easily blocked with changes to ntp.conf before the patch came out.
- NTP can "leak" information if not properly configured. But the
leaked
information is not that useful.
- NTP authentication *only* helps ensure you are getting time from the
correct servers, and doesn't solve any other general security
problems.
Firewalls can still be your friend or enemy.
- Generally, we have much worse security problems to worry about than
anything related to NTP. Like today's Apple Security Update!
NTP protocols and software are finely tuned by world-class
engineers, and
NTP has many tunable-but-very-obscure parameters, but nobody's
written a
"dummy's guide" to NTP yet, and it's not easy to figure out from the
existing docs. Apple has hidden most NTP mysteries in Mac OS X to
improve
the user experience.
The "official" NTP web site is www.ntp.org , though much of the
content is
hosted at www.eecis.udel.edu.
Hope this helps.
-- Rex
At 5:37 PM -0400 5/11/06, Brian Raymond wrote:
How did you configure the NTP servers on OSX? I took a quick look
at the man
page and it states by default authentication is enabled for ntpd,
given that
other clients will not be able to connect unless they
authenticate. There
are three modes of authentication supported but nothing is called
out in
ntp.conf. I assume you would either need to turn off
authentication, or
broadcast/multicast/manycast the time to clients.
This site has good documentation on it.
http://www.eecis.udel.edu/~ntp/ntp_spool/html/ntpd.html
- Brian
On 5/10/06 10:34 AM, "Michael Kluskens" <email@hidden> wrote:
Trying to configure two different OS X machines as NTP servers (one
is OS X 10.4.6 and the other is OS X 10.3.9 Server, on different
networks isolated from the outside world).
ntpd is running just fine on the machines but my other machines
(Linux & Unix) can't seem to see the OS X ntpd server but they can
see a Linux ntpd server just fine (I check the standard firewall
issues, no problems there).
I've done a lot of reading and searching for info about ntpd and all
I can find is how important it is to restrict access to your ntpd
server.
*** In theory all ntpd's run as client and server by default, did
Apple disable the server part in their built of ntpd?
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden