[ntp:questions] notrust alternative?

David L. Mills mills at udel.edu
Sun Nov 5 00:13:04 UTC 2006


Dennis,

I checked and rechecked, both in the current code and by actual 
experiment. Authentication is enabled by default and associations cannot 
be mobilized unless cryptographically authenticated. If no 
authentication parameters have been configured, then mobilization is not 
possible at all. This is the case in the software that leaves here 
(ntp.org), which is why I insist the "official" distribution comes 
directly from here and is not staged anywhere else.

If you got the distribution from here and it behaves as you describe, 
something very evil is going on. Obviously, there are cloggers lurking 
in the swamp and they wouldn't go to the trouble unless they know that 
authentication can be disabled by deceit.

Note to all users: in ntp_proto.c the variable sys_authenticate should 
be set nonzero (1) in the init_proto() routine. If anybody reports 
otherwise, this should be reported to CERT along with the circumstances 
where and how the distribution was obtained. It's equally important to 
check the Linux and FreeBSD and any other place where the official 
distribution might have been modified.

Dave

Dennis Hilberg Jr wrote:
> Even though you said that auth is enabled by default, out of curiosity I set 'enable auth' in my ntp.conf and restarted ntpd.  Now 
> when I execute 'ntpq -p' only the five servers I have listed in my ntp.conf show up.  This is the way it should be correct?  After 
> letting it run overnight, still only the five servers are listed in the 'ntpq -p' banner, traffic to the server has dropped 
> dramatically and when I run 'ntpdc -c monlist' the number of entries has increased to 600.  My pool stats have increased (they had 
> been decreasing due to lots of traffic to the server, clogging up the connection like you said) and my offset spikes have minimized.
> 
> Even though I now have auth enabled I do not have any authentication parameters set up.  This will not cause any trouble for clients 
> to connect would it?  I removed my local network restrictions so that I would have the same restrictions as any client  would, and I 
> can sync off my server with no problem.  I just wanted to double-check with more knowledgeable folks to make sure that I wasn't 
> essentially changing my ntp server from a public to a private one.
> 
> If you think everything is fine, then I think we've solved the problem.
> 
> Thanks a lot!
> 
> Dennis
> 
> "David L. Mills" <mills at udel.edu> wrote in message news:eig64u$d9p$1 at scrotar.nss.udel.edu...
> | Dennis,
> |
> | Note that most of the apparent intruders have poll interval 16 s, which
> | is not very likely and suggests you may be victim of a clogging attack.
> | If authentication is turned off (explicit disable auth) you are victim
> | of some spoofer. The ntpq lines are the result of a mobilized symmetric
> | passive association, as the t field is u (unicast). If that field is b
> | or m, you would be victim of broadcast or multicast.
> |
> | If you have not explicitly turned off authentication, the default case
> | is to refuse to mobilize anything unless authenticated. If this is the
> | case, you might have exposed a bug. In any case, a restrict default
> | nopeer should outsmart the bugger no matter what.
> |
> | Dave
> |
> | Richard B. Gilbert wrote:
> | > Dennis Hilberg Jr wrote:
> | >
> | >> Here is the result of 'ntpq -p' on my system:
> | >>
> | >> saturn:# ntpq -p
> | >>      remote           refid      st t when poll reach   delay
> | >> offset  jitter
> | >> ==============================================================================
> | >>
> | >> -bigben.cac.wash .USNO.           1 u   28   64  377   18.567
> | >> 2.213   1.438
> | >> +montpelier.ilan .USNO.           1 u   31   64  377   48.057
> | >> 0.342   2.201
> | >> +tick.ucla.edu   .PSC.            1 u   27   64  377   46.799
> | >> -0.404   2.485
> | >> +clock.xmission. .GPS.            1 u   26   64  377   52.507
> | >> 0.491   1.587
> | >> *clepsydra.dec.c .GPS.            1 u   24   64  377   32.168
> | >> 0.275   2.075
> | >>  bdsl.66.13.214. 141.156.108.23   2 u    -   16  377    0.001  5384.58
> | >> 124.872
> | >> -71.216.67.53    63.119.46.3      2 u   16   16  373  131.452
> | >> 21.951   6.855
> | >>  host98.liberto. 216.52.237.153   3 u   15   16  377  100.925
> | >> -5344.6  40.603
> | >>  cpe-65-186-213- 71.237.179.90    3 u   30   16  377   78.722
> | >> -386.14   5.327
> | >>  i-195-137-59-20 192.245.169.15   2 u   15   16  277   43.804  7099.33
> | >> 236.967
> | >>  46.Red-80-38-9. 208.99.207.109   3 u   13   16  377  287.516
> | >> -3020.5  60.778
> | >>  72.15.196.228   216.52.237.153   3 u   13   16  377    0.001  30573.1
> | >> 142.754
> | >>  213-84-173-46.a 192.245.169.15   2 u   10   16  377  1468.85
> | >> -11042.  11.560
> | >>  70.150.125.170  71.237.179.90    3 u    9   16  377   85.168
> | >> -40.077   6.857
> | >> -adsl-68-255-97- 64.81.199.165    2 u    8   16  377  106.531
> | >> -12.162   2.902
> | >>  65.5.127.231    71.237.179.90    3 u    8   16  377   88.479
> | >> -59.875   9.769
> | >>  mail.thamesself 71.237.179.90    3 u    7   16  377  172.238
> | >> -23.748  13.801
> | >>  217-116-10-20.r 66.92.77.98      3 u    8   16  377  731.425
> | >> -1245.1  42.582
> | >>  70.150.30.72    71.237.179.90    3 u    6   16  377  101.407
> | >> 968.326   4.586
> | >> -adsl-158-64-228 141.156.108.23   2 u   98   16  374  109.658
> | >> 3.006   2.807
> | >>  S01060011d8dcef 216.165.129.244  2 u    5   16  277   52.252
> | >> 2650.47  33.139
> | >>  neu67-4-88-160- 209.132.176.4    2 u    5   16  377   71.208  29201.2
> | >> 102.426
> | >>  host204-64-dyna 192.245.169.15   2 u  356   16  300   49.252
> | >> 4497.48  43.638
> | >>  227-33.netwurx. 71.237.179.90    3 u    4   16  357  123.479
> | >> -59.126   9.594
> | >>  226.Red-83-41-1 81.169.139.140   3 u    2   16  177  284.796
> | >> 539.697  34.158
> | >>  adsl-212-42-174 209.132.176.4    2 u    9   16  327  204.512
> | >> 95.673  62.616
> | >>  cpe-24-24-123-2 80.127.4.179     2 u    2   16  377    0.001  11796.3
> | >> 115.867
> | >> -70-89-23-210-ph 216.52.237.153   3 u   11   16  176   83.227
> | >> -18.373   1.094
> | >>  65.5.122.162    72.3.133.147     3 u  261  256    4   99.722
> | >> 1.725   0.001
> | >> #194.150.135.94  81.169.152.214   3 u   10   16   76  293.509
> | >> -14.045   7.274
> | >>  host114-244-dyn 192.245.169.15   2 u  212   16   30    0.001  4720.98
> | >> 126.715
> | >>  bdsl.66.13.227. 63.119.46.3      2 u   72  256    7  117.779
> | >> -4.601   4.494
> | >> -mail.getmedium. 63.119.46.3      2 u   16   16   16  125.852
> | >> 16.342   2.413
> | >>  host119-247-dyn 192.245.169.15   2 u    4   16    5    0.001  5061.93
> | >> 236.150
> | >>  64.184.118.233  216.106.191.180  3 u  117   16    2    0.001
> | >> -100239   0.001
> | >>  host134.209.113 63.119.46.3      2 u   34  128    3    0.001  -603.10
> | >> 859.203
> | >> -157.199.7.146   198.60.22.240    2 u    1   16    3   84.881
> | >> -21.815   1.294
> | >>  d54C3CA72.acces 192.245.169.15   2 u    5   16    3  169.735
> | >> -375.17   1.819
> | >>  ACaen-251-1-63- 81.169.152.214   3 u    4   16    2  441.105
> | >> 68.311  24.742
> | >> #ip-207-145-35-7 65.19.139.44     3 u    4   16    3  144.620
> | >> 22.869   6.186
> | >>  mulder.f5.com   216.52.237.153   3 u   66   16    2    5.431
> | >> -14.845   0.001
> | >>  65.107.178.178. 141.156.108.23   2 u   16   16    2   98.225
> | >> -3365.3   2.504
> | >>  wsip-68-14-240- 63.119.46.3      2 u   15   16    1   46.460
> | >> -24.621   1.612
> | >>  c-67-166-119-12 71.237.179.90    3 u   10   16    1    0.001
> | >> 1149.46   4.429
> | >>  cpe-24-209-208- 66.92.68.11      2 u    9   16    1    0.001
> | >> -777.07  22.086
> | >>  foreman.heartla 75.13.24.211     2 u    8   16    1  172.065
> | >> -68.752   1.445
> | >>  cpe-65-27-168-2 141.156.108.23   2 u   22   64    1   87.519
> | >> 124.139   0.001
> | >>
> | >> The first five servers listed above are the same ones listed in my
> | >> ntp.conf as synchronization sources.  What are the rest of them?
> | >>
> | >> 'ntpdc -c monlist' returns 384 entries.  Is that typical?
> | >>
> | >
> | > If you are operating a server, 384 clients does not seem unreasonable.
> | > For clients to show up on the ntpq banner like that, they would almost
> | > have to be "peers".  From the looks of things, you would not want most
> | > of them as peers; they seem to be clueless about what time it is
> | > (assuming that your server is correct).  Actually, about half of them
> | > could not even be peers because they are at stratum 3 and your server
> | > would appear to be at stratum 2.
> | >
> | > I would study the "restrict" statement and add restrict statements that
> | > would prevent anyone from peering with my server (at least any of THAT
> | > crowd)!!!  I might even scrub my hands with disinfectant when I
> | > finished!!!!!!   YUCK!!!!!!!!!!!!!!!
> | >
> | > FWIW, I tried a couple of those addresses with "ping", "ntpq", and
> | > "ntpdate" and got no response.  I tried one with nslookup and got no
> | > translation.  I'd say it's a pretty "ripe" collection!!
> | >
> | > What platform are you running on?  Which O/S?  What version?  Do you
> | > have a firewall?  Is it possible that your system has been "hacked"?
> | >
> 
> 
> 




More information about the questions mailing list