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!
|
|
0
|
|
|
|
Reply
|
 Dennis
|
10/31/2006 8:58:21 PM |
|
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" <dhilberg@comcast.net> 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!
|
|
|
|
|
0
|
|
|
|
Reply
|
Dennis
|
10/31/2006 9:11:23 PM
|
|
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'.
|
|
|
0
|
|
|
|
Reply
|
wa6zvp
|
11/1/2006 3:20:28 AM
|
|
Have you seen http://ntp.isc.org/Support/AccessRestrictions ?
H
|
|
|
0
|
|
|
|
Reply
|
Harlan
|
11/1/2006 3:36:41 AM
|
|
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.
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/1/2006 4:46:11 AM
|
|
"Dennis Hilberg Jr" <dhilberg@comcast.net> 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 <R.Flood@noc.ulcc.ac.uk>
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)
|
|
|
0
|
|
|
|
Reply
|
Ronan
|
11/1/2006 1:59:19 PM
|
|
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" <dhilberg@comcast.net> 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!
> |
> |
>
>
|
|
|
0
|
|
|
|
Reply
|
user
|
11/1/2006 4:02:08 PM
|
|
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" <ronan@noc.ulcc.ac.uk> wrote in message news:eia97n$kn8$1@canard.ulcc.ac.uk...
| "Dennis Hilberg Jr" <dhilberg@comcast.net> 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 <R.Flood@noc.ulcc.ac.uk>
| 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)
|
|
|
0
|
|
|
|
Reply
|
Dennis
|
11/3/2006 6:27:01 AM
|
|
"Dennis Hilberg Jr" <dhilberg@comcast.net> 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
|
|
|
0
|
|
|
|
Reply
|
Maarten
|
11/3/2006 10:56:05 AM
|
|
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" <maarten@kittensandcats.net> wrote in message news:454b2048$0$323$e4fe514c@news.xs4all.nl...
| "Dennis Hilberg Jr" <dhilberg@comcast.net> 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
|
|
|
|
|
0
|
|
|
|
Reply
|
Dennis
|
11/3/2006 5:35:35 PM
|
|
Dennis Hilberg Jr wrote:
> 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.
>
<snip>
Show us the output of ntpq -p
You should not have more than five entries in the ntpq "banner". They
should be the servers you listed in your ntp.conf. I can't imagine
where the others are coming from!!
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/3/2006 5:57:38 PM
|
|
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"?
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/3/2006 6:30:24 PM
|
|
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" <rgilbert88@comcast.net> 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"?
|
|
|
|
0
|
|
|
|
Reply
|
Dennis
|
11/3/2006 7:12:53 PM
|
|
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"?
>
|
|
|
0
|
|
|
|
Reply
|
David
|
11/3/2006 7:43:23 PM
|
|
Can you easily try a more recent version of ntp?
H
|
|
|
0
|
|
|
|
Reply
|
Harlan
|
11/3/2006 7:51:06 PM
|
|
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" <rgilbert88@comcast.net> 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"?
> |
>
>
|
|
|
0
|
|
|
|
Reply
|
David
|
11/3/2006 8:21:36 PM
|
|
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@udel.edu> 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"?
| >
|
|
|
0
|
|
|
|
Reply
|
Dennis
|
11/4/2006 5:17:34 PM
|
|
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@udel.edu> 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"?
> | >
>
>
>
|
|
|
0
|
|
|
|
Reply
|
David
|
11/5/2006 12:13:04 AM
|
|
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.
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/5/2006 1:33:06 AM
|
|
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.
|
|
|
0
|
|
|
|
Reply
|
David
|
11/5/2006 5:17:03 AM
|
|
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.
<snip>
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/5/2006 1:52:24 PM
|
|
In article <NOadnekO3ZIEcdDYnZ2dnUVZ_h2dnZ2d@comcast.com>,
Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> "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!
I believe this constitutes symmetric active, when Dave Mills is
talking about symmetric passive, where only one side actually
has the association configured.
|
|
|
0
|
|
|
|
Reply
|
david
|
11/5/2006 4:41:34 PM
|
|
David Woolley wrote:
> In article <NOadnekO3ZIEcdDYnZ2dnUVZ_h2dnZ2d@comcast.com>,
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>
>
>>"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!
>
>
> I believe this constitutes symmetric active, when Dave Mills is
> talking about symmetric passive, where only one side actually
> has the association configured.
Is "symmetric passive" different from just saying, in ntp.conf:
"server sunblok iburst"? For the record, that works without problems too!
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/5/2006 5:14:52 PM
|
|
Richard,
As I said, the auth switch is enabled by default. See the documentation
for the definition of ephemeral association and persistent association.
Persistent associations are mobilized from the configuration file and
are not affected by the auth swithc. Ephemeral associations are
mobilized upon arrival of a broadcast or symmetric mode message and are
affected by the auth switch.
See the documentatino on the symmetric key and public key cryptography.
Symmetric key cryptography is not affected by address translation.
Public key cryptography requires the server and client to have the same
(interchanged) addresses.
I say again with emphasis. With the default configuration (no disable
auth) ephemeral associations cannot be mobilized unless authenticated,
symmetric or public. Earlier on this thread such associations were in
fact mobilized without authentication, suggesting somebody tampered with
the default auth setting. It is extremely important that the source of
this insult be identified; it represents a serious denial of service
vulnerability.
Dave
Richard B. Gilbert wrote:
> 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.
>
> <snip>
|
|
|
0
|
|
|
|
Reply
|
David
|
11/5/2006 6:06:06 PM
|
|
On 2006-11-05, David L. Mills <mills@udel.edu> wrote:
> 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.
For what it's worth, FreeBSD does not disable this switch.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
|
|
|
0
|
|
|
|
Reply
|
Ceri
|
11/5/2006 6:32:16 PM
|
|
"Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
> Is "symmetric passive" different from just saying, in ntp.conf:
> "server sunblok iburst"? For the record, that works without problems too!
"server xxx" establishes you as a client, "peer xxx" tries to establish
you as a peer. If ntp.conf on box A has "peer B" and ntp.conf on box B
has "peer A", that is symmetric-active: each actively requests to peer
with the other. If box A has "peer B" but box B has no reference to A,
then B can either treat A as a client (usual behaviour), or in the right
(or wrong!) circumstances can accept A as an unconfigured peer, and that
is symmetric-passive. That seems to be what's happening with the original
poster's setup, with all those extras listed in ntpq -p. Generally it is
not desirable ...
--
Ronan Flood <R.Flood@noc.ulcc.ac.uk>
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)
|
|
|
0
|
|
|
|
Reply
|
Ronan
|
11/6/2006 2:30:56 PM
|
|
On Sun, 05 Nov 2006 05:17:03 +0000, "David L. Mills" <mills@udel.edu> wrote:
> 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.
Also check that ntpd is not started with the -A option, which is another
way of disabling authentication.
--
Ronan Flood <R.Flood@noc.ulcc.ac.uk>
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)
|
|
|
0
|
|
|
|
Reply
|
Ronan
|
11/6/2006 2:43:24 PM
|
|
Dennis,
You are not reading my messages. Read them again; take them very
seriously. You are being hacked. Any entries shown in ntpq other than
those you configured are spurious and the result of tampering in the
sources that leave here. It's very important to track down how that
happened. Forget about the +, -, * issues; there are more important
things going on here.
Dave
Dennis Hilberg Jr wrote:
> 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" <ronan@noc.ulcc.ac.uk> wrote in message news:eia97n$kn8$1@canard.ulcc.ac.uk...
> | "Dennis Hilberg Jr" <dhilberg@comcast.net> 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 <R.Flood@noc.ulcc.ac.uk>
> | 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)
>
>
|
|
|
0
|
|
|
|
Reply
|
mills
|
11/6/2006 4:02:29 PM
|
|
That was my problem all along. My server is Mandriva 2007 Free, and I'm using the version of ntp that is included with the distro,
4.2.0@1.1161-r. In /etc/sysconfig/ntpd the -A option is enabled by default. I removed that and took out 'enable auth' in my
ntp.conf, restarted ntpd, and now everything works the way David Mills says it should.
Now the question...why would Mandriva disable authentication by default?? After what David Mills has said, and what I've been
dealing with, that seems rather insecure.
Thanks a lot Ronan for pointing this out. I feel embarrased for not noticing it was running with the -A option by default. I just
didn't pay attention. But hopefully this will help someone else out.
Thank you everyone for the help,
Dennis
"Ronan Flood" <ronan@noc.ulcc.ac.uk> wrote in message news:einhmc$6tm$1@canard.ulcc.ac.uk...
| On Sun, 05 Nov 2006 05:17:03 +0000, "David L. Mills" <mills@udel.edu> wrote:
|
| > 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.
|
| Also check that ntpd is not started with the -A option, which is another
| way of disabling authentication.
|
| --
| Ronan Flood <R.Flood@noc.ulcc.ac.uk>
| 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)
|
|
|
|
0
|
|
|
|
Reply
|
Dennis
|
11/6/2006 6:13:43 PM
|
|
"Dennis Hilberg Jr" <dhilberg@comcast.net> wrote in message
news:FO2dnVAu0ozF5tLYnZ2dnUVZ_oidnZ2d@comcast.com...
[...]
> Now the question...why would Mandriva disable authentication by default??
Welcome to the wonderful world of modern commodity computing. Where
a vendor will distribute a product with gaping holes in the default
setup, because it cuts down on support calls.
Horrified question: "They would do that?"
World-weary answer: "Every time."
Groetjes,
Maarten Wiltink
|
|
|
0
|
|
|
|
Reply
|
Maarten
|
11/6/2006 8:08:04 PM
|
|
Ronan Flood wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
>
>
>>Is "symmetric passive" different from just saying, in ntp.conf:
>>"server sunblok iburst"? For the record, that works without problems too!
>
>
> "server xxx" establishes you as a client, "peer xxx" tries to establish
> you as a peer. If ntp.conf on box A has "peer B" and ntp.conf on box B
> has "peer A", that is symmetric-active: each actively requests to peer
> with the other. If box A has "peer B" but box B has no reference to A,
> then B can either treat A as a client (usual behaviour), or in the right
> (or wrong!) circumstances can accept A as an unconfigured peer, and that
> is symmetric-passive. That seems to be what's happening with the original
> poster's setup, with all those extras listed in ntpq -p. Generally it is
> not desirable ...
>
Some of those lines in the ntpq -p banner were stratum two and could
have been peers. The rest were stratum three so I don't see how they
could have been peers; don't peers have be of equal strata?
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/6/2006 8:38:31 PM
|
|
On 2006-11-06, Dennis Hilberg Jr <dhilberg@comcast.net> wrote:
> That was my problem all along. My server is Mandriva 2007 Free,
> and I'm using the version of ntp that is included with the distro,
> 4.2.0@1.1161-r. In /etc/sysconfig/ntpd the -A option is enabled by
> default.
The logical thing to do is report this to Mandriva as a bug.
But there does not appear to be a public Bug Tracking System at
http://www.mandriva.com/
There are some mandrake / mandriva related Usenet (e.g.
alt.os.linux.mandrake) and Google (e.g. Mandriva Linux) news groups.
You may find more assistance there.
--
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/
|
|
|
0
|
|
|
|
Reply
|
Steve
|
11/6/2006 8:43:54 PM
|
|
>>> In article <NMedncm-NKfVANLYnZ2dnUVZ_umdnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
Richard> Some of those lines in the ntpq -p banner were stratum two and
Richard> could have been peers. The rest were stratum three so I don't see
Richard> how they could have been peers; don't peers have be of equal
Richard> strata?
No.
server/peer is independent of strata.
H
|
|
|
0
|
|
|
|
Reply
|
Harlan
|
11/6/2006 9:45:26 PM
|
|
Harlan Stenn wrote:
>>>>In article <NMedncm-NKfVANLYnZ2dnUVZ_umdnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
>
> Richard> Some of those lines in the ntpq -p banner were stratum two and
> Richard> could have been peers. The rest were stratum three so I don't see
> Richard> how they could have been peers; don't peers have be of equal
> Richard> strata?
>
> No.
>
> server/peer is independent of strata.
>
> H
But how can the relationship be symmetric if the strata are different?
If a stratum 2 and a stratum 3 server peered, the stratum 3 could get
time from the stratum 2 but the stratum 2 would never take time from the
stratum 3! I suppose there could be situations where the stratum of one
or both was variable. . . .
|
|
|
0
|
|
|
|
Reply
|
Richard
|
11/6/2006 10:41:02 PM
|
|
>But how can the relationship be symmetric if the strata are different?
>If a stratum 2 and a stratum 3 server peered, the stratum 3 could get
>time from the stratum 2 but the stratum 2 would never take time from the
>stratum 3! I suppose there could be situations where the stratum of one
>or both was variable. . . .
The stratum of a server isn't fixed. It changes as network links
break, servers come and go, or recursively as the stratum of a
server/peer changes.
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
|
|
|
0
|
|
|
|
Reply
|
hmurray
|
11/7/2006 12:45:28 AM
|
|
Richard,
A symmetric active association "peer xxx" will cause the authenticated
peer to mobilize a symmetric passive association no matter what the
stratum is. The selection algorithm will treat a symmetric passive
associaiton in the same way as client associations. either or both the
symmetric associations lose or gain outside sources or each other, they
will reconfigure as expected by the particular stratum assignments.
I would think most configurations intended for mutual backup would use
explicit symmetric active configurations and avoid symmetric passive as
a fallback mode.
Dave
Richard B. Gilbert wrote:
> Ronan Flood wrote:
>
>> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:
>>
>>
>>> Is "symmetric passive" different from just saying, in ntp.conf:
>>> "server sunblok iburst"? For the record, that works without
>>> problems too!
>>
>>
>>
>> "server xxx" establishes you as a client, "peer xxx" tries to establish
>> you as a peer. If ntp.conf on box A has "peer B" and ntp.conf on box B
>> has "peer A", that is symmetric-active: each actively requests to peer
>> with the other. If box A has "peer B" but box B has no reference to A,
>> then B can either treat A as a client (usual behaviour), or in the right
>> (or wrong!) circumstances can accept A as an unconfigured peer, and that
>> is symmetric-passive. That seems to be what's happening with the
>> original
>> poster's setup, with all those extras listed in ntpq -p. Generally it is
>> not desirable ...
>>
>
> Some of those lines in the ntpq -p banner were stratum two and could
> have been peers. The rest were stratum three so I don't see how they
> could have been peers; don't peers have be of equal strata?
>
|
|
|
0
|
|
|
|
Reply
|
mills
|
11/8/2006 4:56:59 PM
|
|
I reported this to Mandriva as a bug. Their bug tracking system is located at http://qa.mandriva.com. The bug is #27079,
http://qa.mandriva.com/show_bug.cgi?id=27079.
Hopefully they will get it taken care of as it seems like a pretty significant security issue to me after having this discussion.
Dennis
"Steve Kostecke" <kostecke@ntp.isc.org> wrote in message news:slrnekv7ka.mft.kostecke@stasis.kostecke.net...
| On 2006-11-06, Dennis Hilberg Jr <dhilberg@comcast.net> wrote:
|
| > That was my problem all along. My server is Mandriva 2007 Free,
| > and I'm using the version of ntp that is included with the distro,
| > 4.2.0@1.1161-r. In /etc/sysconfig/ntpd the -A option is enabled by
| > default.
|
| The logical thing to do is report this to Mandriva as a bug.
| But there does not appear to be a public Bug Tracking System at
| http://www.mandriva.com/
|
| There are some mandrake / mandriva related Usenet (e.g.
| alt.os.linux.mandrake) and Google (e.g. Mandriva Linux) news groups.
| You may find more assistance there.
|
| --
| Steve Kostecke <kostecke@ntp.isc.org>
| NTP Public Services Project - http://ntp.isc.org/
|
|
|
0
|
|
|
|
Reply
|
Dennis
|
11/10/2006 9:12:16 AM
|
|
I have seen behavior identical to what Dennis described with a
pre-built Solaris 8 version of the 4.2.0@1.1161-r daemon that is
available from Community Software (CSW), http://www.blastwave.org/ if
your interested. I have "restrict default nopeer" configured. With
authorization disabled, all of the systems on our network that peered
my server showed up in its ntpq -p output. With authorization enabled,
only the systems I had configured on that server showed up. I plopped
a version 4.2.2p3@1.1577-o daemon that was build from the official
source, disabled authorization and it behaved normally, no additional
spurious output from ntpq -p. Something perculiar with 4.2.0@1.1161-r?
Regardless, this was enough to steer me away from anything pre-built
and back to the genuine article.
Bill McGovern
General Dynamics
|
|
|
0
|
|
|
|
Reply
|
ntplist
|
11/14/2006 11:46:41 PM
|
|
Bill,
In your network the clients should be using server, not peer, unless
they intend to mobilize a symmetric association. However, without
notrust they get served anyway, but an association is not mobilized. I
did that for the original Windows XP client that was using symmetric
active mode in error. It's hard to figure out how the dominos should
fall under all kinds of misconfigured clients.
Dave
ntplist@gmail.com wrote:
> I have seen behavior identical to what Dennis described with a
> pre-built Solaris 8 version of the 4.2.0@1.1161-r daemon that is
> available from Community Software (CSW), http://www.blastwave.org/ if
> your interested. I have "restrict default nopeer" configured. With
> authorization disabled, all of the systems on our network that peered
> my server showed up in its ntpq -p output. With authorization enabled,
> only the systems I had configured on that server showed up. I plopped
> a version 4.2.2p3@1.1577-o daemon that was build from the official
> source, disabled authorization and it behaved normally, no additional
> spurious output from ntpq -p. Something perculiar with 4.2.0@1.1161-r?
>
> Regardless, this was enough to steer me away from anything pre-built
> and back to the genuine article.
>
> Bill McGovern
> General Dynamics
>
|
|
|
0
|
|
|
|
Reply
|
David
|
11/15/2006 4:29:22 AM
|
|
Dave,
Yes, the clients should definitely have been configured with server
statements, but config files were simply copied in this case, cleanup
is imminent. My point was to illustrate that with "restrict default
nopeer" and "disable auth" configured on the server, there is a
difference in behavior between a built-from-source 4.2.2p3 daemon and
these (questionable heritage) prebuilt 4.2.0 daemons (CSW and
Mandrake).
Bill
David L. Mills wrote:
> Bill,
>
> In your network the clients should be using server, not peer, unless
> they intend to mobilize a symmetric association. However, without
> notrust they get served anyway, but an association is not mobilized. I
> did that for the original Windows XP client that was using symmetric
> active mode in error. It's hard to figure out how the dominos should
> fall under all kinds of misconfigured clients.
>
> Dave
|
|
|
0
|
|
|
|
Reply
|
ntplist
|
11/15/2006 6:23:48 PM
|
|
|
39 Replies
131 Views
(page loaded in 0.296 seconds)
|
Search |
Post Question |
Groups |
Stream |
About |
Register
4288 articles. 
2 followers. 