notrust alternative? - NTP

This is a discussion on notrust alternative? - NTP ; On one instance I noticed that in the output of 'ntpq -p' one of my server's clients was flagged with the '+'. notrust under version 4.2 and later now means "Ignore all NTP packets that are not cryptographically authenticated" instead ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 39

Thread: notrust alternative?

  1. notrust alternative?

    On one instance I noticed that in the output of 'ntpq -p' one of my server's
    clients was flagged with the '+'. notrust under version 4.2 and later now
    means "Ignore all NTP packets that are not cryptographically authenticated"
    instead of the 4.1 and earlier versions where it meant "Don't trust this
    host/subnet for time." How do I specify with version 4.2 and later that I
    only want the five server entries in the ntp.conf to be trusted for
    synchronization? Or is this automatic, and that particular 'ntpq -p' output
    a fluke?

    Thanks!



  2. Re: notrust alternative?

    I forgot to include my ntp.conf. Here it is:


    # Default restriction.

    restrict default kod nomodify notrap nopeer noquery

    # Allow free access to localhost.

    restrict 127.0.0.1

    # Allow the local network access with the following modified restrictions.

    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer

    # Synchronization servers. Include at least three, but no more than five.

    server bigben.cac.washington.edu iburst
    server montpelier.ilan.caltech.edu iburst
    server tick.ucla.edu iburst
    server clock.xmission.com iburst
    server clepsydra.dec.com iburst

    # Drift file location

    driftfile /etc/ntp/drift

    # Location of the log file

    logfile /var/log/ntp/ntp.log

    # NTP monitoring parameters

    statsdir /var/log/ntp/
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable

    # Authentication parameters

    #keys /etc/ntp/keys
    #trustedkey 2 3 4
    #controlkey 3 # To access the ntpq utility
    #requestkey 2 # To access the ntpdc utility


    "Dennis Hilberg Jr" wrote in message
    news:UZOdnQLLdJhzJdrYnZ2dnUVZ_sqdnZ2d@comcast.com. ..
    | On one instance I noticed that in the output of 'ntpq -p' one of my
    server's
    | clients was flagged with the '+'. notrust under version 4.2 and later now
    | means "Ignore all NTP packets that are not cryptographically
    authenticated"
    | instead of the 4.1 and earlier versions where it meant "Don't trust this
    | host/subnet for time." How do I specify with version 4.2 and later that I
    | only want the five server entries in the ntp.conf to be trusted for
    | synchronization? Or is this automatic, and that particular 'ntpq -p'
    output
    | a fluke?
    |
    | Thanks!
    |
    |



  3. Re: notrust alternative?


    Dennis Hilberg Jr wrote:
    > On one instance I noticed that in the output of 'ntpq -p' one of my server's
    > clients was flagged with the '+'. notrust under version 4.2 and later now
    > means "Ignore all NTP packets that are not cryptographically authenticated"
    > instead of the 4.1 and earlier versions where it meant "Don't trust this
    > host/subnet for time." How do I specify with version 4.2 and later that I
    > only want the five server entries in the ntp.conf to be trusted for
    > synchronization? Or is this automatic, and that particular 'ntpq -p' output
    > a fluke?
    >
    > Thanks!


    Dennis,
    I'm not sure how you are tying '+' flags and authentication together
    at all. If you are referring to a leading '+' sign in the billboard
    output like this:

    +time-C.timefreq .ACTS. 1 u 41 64 377 67.66 0.791
    0.96

    ^^ This plus indicates that this timeserver has been selected as
    candidate for syncronization. This is a good thing. One of my primary
    stratum 2 timeservers has 4 different ones flagged this way, which make
    them all candidates for assuming the role of syncronization. You would
    (should) always see one flagged with a ' * ' which is the currently
    selected source.

    Your server will _only_ attempt to sync to the servers you have
    specifically listed in your config file. With five of them, you should
    be in good shape.

    Roger
    Harvey Mudd College, one of the 'new ivies'.


  4. Re: notrust alternative?


  5. Re: notrust alternative?

    Dennis Hilberg Jr wrote:

    > On one instance I noticed that in the output of 'ntpq -p' one of my server's
    > clients was flagged with the '+'. notrust under version 4.2 and later now
    > means "Ignore all NTP packets that are not cryptographically authenticated"
    > instead of the 4.1 and earlier versions where it meant "Don't trust this
    > host/subnet for time." How do I specify with version 4.2 and later that I
    > only want the five server entries in the ntp.conf to be trusted for
    > synchronization? Or is this automatic, and that particular 'ntpq -p' output
    > a fluke?
    >
    > Thanks!
    >
    >


    By naming a system in the server statement you are telling ntpd to get
    time from that system and effectively telling ntpd to trust that system.
    Authentication is supposed to guarantee that the server that is telling
    you the time really is the server that you named in the server
    statement. To name a server and then tell ntpd not to trust it seems a
    pointless exercise.

    If your server's ntpq -p "banner" lists a client with a "+" something is
    very wrong somewhere! NTP is hierarchical and servers do not get time
    from clients!! Now two systems can be declared as "peers" and get time
    from each other but that is a different relationship than client and
    server.

  6. Re: notrust alternative?

    "Dennis Hilberg Jr" wrote:

    > On one instance I noticed that in the output of 'ntpq -p' one of my server's
    > clients was flagged with the '+'. notrust under version 4.2 and later now
    > means "Ignore all NTP packets that are not cryptographically authenticated"
    > instead of the 4.1 and earlier versions where it meant "Don't trust this
    > host/subnet for time." How do I specify with version 4.2 and later that I
    > only want the five server entries in the ntp.conf to be trusted for
    > synchronization? Or is this automatic, and that particular 'ntpq -p' output
    > a fluke?


    'nopeer' should prevent a client establishing a symmetric-passive
    association on your server, so the ntp.conf you show in your later
    message should be working. Post the output of 'ntpq -p' showing
    your client listed (with or without '+') and 'ntpq -classoc',
    and 'ntpq "-crv nnn"' where nnn is the number of the association
    (assID) for your client in the lassoc output.

    Hmm, "ntpdc -ncreslist" will show the active restrictions, so check
    that matches your ntp.conf.

    --
    Ronan Flood
    working for but not speaking for
    Network Services, University of London Computer Centre
    (which means: don't bother ULCC if I've said something you don't like)

  7. Re: notrust alternative?

    Dennis,

    There is a fundamental misunderstanding of the notrust option,
    understandable because the documentation is buggy. The notrust option
    applies to clients attempting to retrieve time from your server. The
    options are to supply time whether or not authenticated or to require
    authentication. This is done primarily to discourage unwanted traffic
    and is intended for use by the national labs.

    What you want is the nopeer option, which prevents broadcast, manycast
    and symmetric peers to mobilize associations and potentially synchronize
    your clock. By preventing mobilization, this prevents any attempt to
    synchronize your clock by any outside source. The misunderstanding is in
    both NTPv3 (xntpd) and NTPv4 (ntpd). The current documentation at
    ntp.org accurately describes these options.

    Dave

    Dennis Hilberg Jr wrote:
    > I forgot to include my ntp.conf. Here it is:
    >
    >
    > # Default restriction.
    >
    > restrict default kod nomodify notrap nopeer noquery
    >
    > # Allow free access to localhost.
    >
    > restrict 127.0.0.1
    >
    > # Allow the local network access with the following modified restrictions.
    >
    > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
    >
    > # Synchronization servers. Include at least three, but no more than five.
    >
    > server bigben.cac.washington.edu iburst
    > server montpelier.ilan.caltech.edu iburst
    > server tick.ucla.edu iburst
    > server clock.xmission.com iburst
    > server clepsydra.dec.com iburst
    >
    > # Drift file location
    >
    > driftfile /etc/ntp/drift
    >
    > # Location of the log file
    >
    > logfile /var/log/ntp/ntp.log
    >
    > # NTP monitoring parameters
    >
    > statsdir /var/log/ntp/
    > statistics loopstats peerstats clockstats
    > filegen loopstats file loopstats type day enable
    > filegen peerstats file peerstats type day enable
    > filegen clockstats file clockstats type day enable
    >
    > # Authentication parameters
    >
    > #keys /etc/ntp/keys
    > #trustedkey 2 3 4
    > #controlkey 3 # To access the ntpq utility
    > #requestkey 2 # To access the ntpdc utility
    >
    >
    > "Dennis Hilberg Jr" wrote in message
    > news:UZOdnQLLdJhzJdrYnZ2dnUVZ_sqdnZ2d@comcast.com. ..
    > | On one instance I noticed that in the output of 'ntpq -p' one of my
    > server's
    > | clients was flagged with the '+'. notrust under version 4.2 and later now
    > | means "Ignore all NTP packets that are not cryptographically
    > authenticated"
    > | instead of the 4.1 and earlier versions where it meant "Don't trust this
    > | host/subnet for time." How do I specify with version 4.2 and later that I
    > | only want the five server entries in the ntp.conf to be trusted for
    > | synchronization? Or is this automatic, and that particular 'ntpq -p'
    > output
    > | a fluke?
    > |
    > | Thanks!
    > |
    > |
    >
    >


  8. Re: notrust alternative?

    Maybe I'm misunderstanding the output of 'ntpq -p'. When I use this command, a large list is printed to the screen (sometimes 60 or
    more entries in length), of which, the first five of the entries are the servers I have listed in my ntp.conf and the rest I'm
    assuming are clients, or systems using my server's clock as a synchronization source. Am I correct on that? Most of the time those
    five servers are the ones that have +, -, or * next to them. Of those five, there's always a * and usually two +. On occasion
    though, some of the systems in the 'ntpq -p' output OTHER than my five servers have a + next to them. Is this normal, based on my
    ntp.conf? My concern is that my server might be using systems other than the five I have listed in my ntp.conf as a synchronization
    source. Perhaps I should have worded my initial post this way, as some replies indicate that I might have failed to explain my
    situation properly.

    Here is my ntp.conf again:


    # Default restriction.

    restrict default kod nomodify notrap nopeer noquery

    # Allow free access to localhost.

    restrict 127.0.0.1

    # Allow the local network access with the following modified restrictions.

    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer

    # Synchronization servers. Include at least three, but no more than five.

    server bigben.cac.washington.edu iburst
    server montpelier.ilan.caltech.edu iburst
    server tick.ucla.edu iburst
    server clock.xmission.com iburst
    server clepsydra.dec.com iburst

    # Drift file location

    driftfile /etc/ntp/drift

    # Location of the log file

    logfile /var/log/ntp/ntp.log

    # NTP monitoring parameters

    statsdir /var/log/ntp/
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable

    # Authentication parameters

    #keys /etc/ntp/keys
    #trustedkey 2 3 4
    #controlkey 3 # To access the ntpq utility
    #requestkey 2 # To access the ntpdc utility

    Thanks for all the help.

    Dennis.

    "Ronan Flood" wrote in message news:eia97n$kn8$1@canard.ulcc.ac.uk...
    | "Dennis Hilberg Jr" wrote:
    |
    | > On one instance I noticed that in the output of 'ntpq -p' one of my server's
    | > clients was flagged with the '+'. notrust under version 4.2 and later now
    | > means "Ignore all NTP packets that are not cryptographically authenticated"
    | > instead of the 4.1 and earlier versions where it meant "Don't trust this
    | > host/subnet for time." How do I specify with version 4.2 and later that I
    | > only want the five server entries in the ntp.conf to be trusted for
    | > synchronization? Or is this automatic, and that particular 'ntpq -p' output
    | > a fluke?
    |
    | 'nopeer' should prevent a client establishing a symmetric-passive
    | association on your server, so the ntp.conf you show in your later
    | message should be working. Post the output of 'ntpq -p' showing
    | your client listed (with or without '+') and 'ntpq -classoc',
    | and 'ntpq "-crv nnn"' where nnn is the number of the association
    | (assID) for your client in the lassoc output.
    |
    | Hmm, "ntpdc -ncreslist" will show the active restrictions, so check
    | that matches your ntp.conf.
    |
    | --
    | Ronan Flood
    | working for but not speaking for
    | Network Services, University of London Computer Centre
    | (which means: don't bother ULCC if I've said something you don't like)



  9. Re: notrust alternative?

    "Dennis Hilberg Jr" wrote in message
    news:FfCdndxmLpKrfNfYnZ2dnUVZ_oGdnZ2d@comcast.com. ..
    > Maybe I'm misunderstanding the output of 'ntpq -p'. When I use
    > this command, a large list is printed to the screen (sometimes
    > 60 or more entries in length), of which, the first five of the
    > entries are the servers I have listed in my ntp.conf and the rest
    > I'm assuming are clients, or systems using my server's clock as a
    > synchronization source.


    That's definitely very, very wrong.

    Ntpdc's monlist command gives you a list of clients. Ntpq's peer
    command gives you a list of servers/peers (from your (snipped)
    configuration file, it appears that you should have no peers).

    What does the list look like?

    Groetjes,
    Maarten Wiltink



  10. Re: notrust alternative?

    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?

    Thanks again for any help.

    Dennis

    "Maarten Wiltink" wrote in message news:454b2048$0$323$e4fe514c@news.xs4all.nl...
    | "Dennis Hilberg Jr" wrote in message
    | news:FfCdndxmLpKrfNfYnZ2dnUVZ_oGdnZ2d@comcast.com. ..
    | > Maybe I'm misunderstanding the output of 'ntpq -p'. When I use
    | > this command, a large list is printed to the screen (sometimes
    | > 60 or more entries in length), of which, the first five of the
    | > entries are the servers I have listed in my ntp.conf and the rest
    | > I'm assuming are clients, or systems using my server's clock as a
    | > synchronization source.
    |
    | That's definitely very, very wrong.
    |
    | Ntpdc's monlist command gives you a list of clients. Ntpq's peer
    | command gives you a list of servers/peers (from your (snipped)
    | configuration file, it appears that you should have no peers).
    |
    | What does the list look like?
    |
    | Groetjes,
    | Maarten Wiltink
    |
    |



  11. Re: notrust alternative?

    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"?


  12. Re: notrust alternative?

    No, I do not think I've been hacked, but I guess it's possible. The server is behind a router, with only the ssh, smtp, and ntp
    ports open.

    My system is Mandriva 2007 Free on x86. No xwindows, command line only. 'ntpq -c version' returns:

    saturn:# ntpq -c version
    ntpq 4.2.0@1.1161-r Sat Sep 30 08:43:12 MDT 2006 (1)


    'ntpcd -ncreslist' returns:

    saturn:# ntpdc -ncreslist
    address mask count flags
    ================================================== ===================
    0.0.0.0 0.0.0.0 93063 noquery, nomodify, nopeer, notrap, kod
    127.0.0.1 255.255.255.255 1675 none
    127.0.0.1 255.255.255.255 0 ntpport, interface, ignore
    192.168.1.0 255.255.255.0 19 nomodify, nopeer, notrap
    192.168.1.102 255.255.255.255 0 ntpport, interface, ignore
    :: :: 0 none

    My ntp.conf:


    # Default restriction.

    restrict default kod nomodify notrap nopeer noquery

    # Allow free access to localhost.

    restrict 127.0.0.1

    # Allow the local network access with the following modified restrictions.

    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer

    # Synchronization servers. Include at least three, but no more than five.

    server bigben.cac.washington.edu iburst # University of Washington, Seattle, WA
    server montpelier.ilan.caltech.edu iburst # California Institute of Technology, Pasadena, CA
    server tick.ucla.edu iburst # UCLA, Los Angeles, CA
    server clock.xmission.com iburst # XMission Internet, Salt Lake City, Utah
    server clepsydra.dec.com iburst # HP Western Research Laboratory, Palo Alto, CA

    # Drift file location

    driftfile /etc/ntp/drift

    # Location of the log file

    logfile /var/log/ntp/ntp.log

    # NTP monitoring parameters

    statsdir /var/log/ntp/
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable

    # Authentication parameters

    #keys /etc/ntp/keys
    #trustedkey 2 3 4
    #controlkey 3 # To access the ntpq utility
    #requestkey 2 # To access the ntpdc utility

    Do I have my access restrictions set up properly? Am I missing anything?

    Dennis


    "Richard B. Gilbert" wrote in message news:l6ydnTpageZdF9bYnZ2dnUVZ_qCdnZ2d@comcast.com. ..
    | 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"?
    |



  13. Re: notrust alternative?

    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"?
    >


  14. Re: notrust alternative?

    Can you easily try a more recent version of ntp?

    H

  15. Re: notrust alternative?

    Dennis,

    I set up a likely scenario similar to yours and confirmed the default
    behavior, even with no restrictions, is to resist mobilizing a peer
    association as apparently happened to you. There was a code groom late
    last year, which might have produced a bug, but the groom was thoroughly
    checked specifically to resist apparent attacks like yours. In spite of
    that, the default behavior for many years before that is to resist
    mobilizing anything if authentication is not explicitly turned off.

    What makes me even mor suspicious is all those 16s for the peer poll
    interval. That is not credible, unless spoofed. Apparently, the spoofer
    is trying to heat up your wires and force you to consume memory and
    network bandwidth.

    I may have done something evil in allowing a symmetric active peer to
    obtain service while not allowing an association to be mobilized. That
    was done because the original Windows client used symmetric active mode
    when it should have used client mode. If the notrust bit is set, the
    perp will not get any response at all. However, the problem remains that
    those spoofed assocations should never have been mobilized in the first
    place.

    If you can recreate the scenario, run ntpq and rv for one or more of
    those voodoo associations, then send the results. I'd like to see the
    peer poll interval and the modes.

    Dave

    Dennis Hilberg Jr wrote:
    > No, I do not think I've been hacked, but I guess it's possible. The server is behind a router, with only the ssh, smtp, and ntp
    > ports open.
    >
    > My system is Mandriva 2007 Free on x86. No xwindows, command line only. 'ntpq -c version' returns:
    >
    > saturn:# ntpq -c version
    > ntpq 4.2.0@1.1161-r Sat Sep 30 08:43:12 MDT 2006 (1)
    >
    >
    > 'ntpcd -ncreslist' returns:
    >
    > saturn:# ntpdc -ncreslist
    > address mask count flags
    > ================================================== ===================
    > 0.0.0.0 0.0.0.0 93063 noquery, nomodify, nopeer, notrap, kod
    > 127.0.0.1 255.255.255.255 1675 none
    > 127.0.0.1 255.255.255.255 0 ntpport, interface, ignore
    > 192.168.1.0 255.255.255.0 19 nomodify, nopeer, notrap
    > 192.168.1.102 255.255.255.255 0 ntpport, interface, ignore
    > :: :: 0 none
    >
    > My ntp.conf:
    >
    >
    > # Default restriction.
    >
    > restrict default kod nomodify notrap nopeer noquery
    >
    > # Allow free access to localhost.
    >
    > restrict 127.0.0.1
    >
    > # Allow the local network access with the following modified restrictions.
    >
    > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
    >
    > # Synchronization servers. Include at least three, but no more than five.
    >
    > server bigben.cac.washington.edu iburst # University of Washington, Seattle, WA
    > server montpelier.ilan.caltech.edu iburst # California Institute of Technology, Pasadena, CA
    > server tick.ucla.edu iburst # UCLA, Los Angeles, CA
    > server clock.xmission.com iburst # XMission Internet, Salt Lake City, Utah
    > server clepsydra.dec.com iburst # HP Western Research Laboratory, Palo Alto, CA
    >
    > # Drift file location
    >
    > driftfile /etc/ntp/drift
    >
    > # Location of the log file
    >
    > logfile /var/log/ntp/ntp.log
    >
    > # NTP monitoring parameters
    >
    > statsdir /var/log/ntp/
    > statistics loopstats peerstats clockstats
    > filegen loopstats file loopstats type day enable
    > filegen peerstats file peerstats type day enable
    > filegen clockstats file clockstats type day enable
    >
    > # Authentication parameters
    >
    > #keys /etc/ntp/keys
    > #trustedkey 2 3 4
    > #controlkey 3 # To access the ntpq utility
    > #requestkey 2 # To access the ntpdc utility
    >
    > Do I have my access restrictions set up properly? Am I missing anything?
    >
    > Dennis
    >
    >
    > "Richard B. Gilbert" wrote in message news:l6ydnTpageZdF9bYnZ2dnUVZ_qCdnZ2d@comcast.com. ..
    > | 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"?
    > |
    >
    >


  16. Re: notrust alternative?

    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" wrote in message news:eig64u$d9p$1@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"?
    | >




  17. Re: notrust alternative?

    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" wrote in message news:eig64u$d9p$1@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"?
    > | >
    >
    >
    >


  18. Re: notrust alternative?

    David L. Mills wrote:
    > 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.


    David,

    Something is very wrong here else I fail completely to understand what
    you just said! I have never used authentication yet I have managed to
    operate a stratum 1 server with a GPS reference clock, and five
    upstream internet servers. I have peered this server with another
    stratum 1 server I operate using a Traconex WWV receiver as a reference.
    I never bothered with authentication. I have had no problem mobilizing
    a symmetric association (peer) nor the normal client server associations
    with my internet servers. I have not disabled authentication but I have
    never configured it between any of my local systems or between my local
    systems and my upstream servers.

  19. Re: notrust alternative?

    Richard,

    You may have misunderstood what the enable/disable auth does. It has
    nothing to do with the autentication method or lack of it. If the switch
    is enabled (enable auth), then associations cannot be mobilized unless
    authentication parameters have been configured and the symmetric active
    or broadcast client is correctly authenticated. If it is disabled
    (disable auth), then mobilization is allowed without requiring
    authentication. This is very bad and apparently led to what evidently is
    a memory clogging attack.

    All users: Don't put "disable auth" in your configuration file unless
    you understand the resulting vulnerability and your network cannot be
    connected to the public Internet under any circumstances. Also, make
    sure the Linux and FreeBSD and others do not provide NTP software with
    that switch disabled.

    Explicit statements on the interplay between the various option is at
    line 516 et seq in the ntp_proto.c file in the current distribution.

    Dave

    Richard B. Gilbert wrote:
    > David L. Mills wrote:
    >
    >> 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.

    >
    >
    > David,
    >
    > Something is very wrong here else I fail completely to understand what
    > you just said! I have never used authentication yet I have managed to
    > operate a stratum 1 server with a GPS reference clock, and five
    > upstream internet servers. I have peered this server with another
    > stratum 1 server I operate using a Traconex WWV receiver as a reference.
    > I never bothered with authentication. I have had no problem mobilizing
    > a symmetric association (peer) nor the normal client server associations
    > with my internet servers. I have not disabled authentication but I have
    > never configured it between any of my local systems or between my local
    > systems and my upstream servers.


  20. Re: notrust alternative?

    David L. Mills wrote:
    > Richard,
    >
    > You may have misunderstood what the enable/disable auth does. It has
    > nothing to do with the autentication method or lack of it. If the switch
    > is enabled (enable auth), then associations cannot be mobilized unless
    > authentication parameters have been configured and the symmetric active
    > or broadcast client is correctly authenticated.


    I think I'm still missing something! I don't have disable auth nor
    enable auth. Therefore it defaults to "enable auth".

    Correct so far?

    I have an NTP keys file with symmetric keys that I use only to access
    the privileged functions of ntpq and ntpdc. I do not authenticate any
    server! I am, apparently, able to mobilize associations! But if I
    understand you, I should not be able to mobilize associations.
    "sunblok" and "sunburn" are two servers on my local network. On
    "sunblok" I can say "peer sunburn" and on "sunburn" I can say "peer
    sunblok". It works!

    Since I am behind a NAT router/firewall on an RFC-1918 private network,
    my understanding is that your public key authentication scheme cannot be
    used because the IP address of my machine is not the address seen
    externally and the IP address of the machine is part of the
    authentication scheme.



+ Reply to Thread
Page 1 of 2 1 2 LastLast