Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.sai.msu.su/~er/xntp/accopt.html
Дата изменения: Unknown Дата индексирования: Sat Dec 22 01:46:09 2007 Кодировка: Поисковые слова: meteor shower |
xntpd
implements a general purpose address-and-mask
based restriction list. The list is sorted by address and by mask, and
the list is searched in this order for matches, with the last match
found defining the restriction flags associated with the incoming
packets. The source address of incoming packets is used for the match,
with the 32-bit address being and'ed with the mask associated with the
restriction entry and then compared with the entry's address (which has
also been and'ed with the mask) to look for a match. Additional
information and examples can be found in the
Notes on Configuring NTP and Setting up a NTP Subnet page.
The restriction facility was implemented in conformance with the access policies for the original NSFnet backbone time servers. While this facility may be otherwise useful for keeping unwanted or broken remote time servers from affecting your own, it should not be considered an alternative to the standard NTP authentication facility. Source address based restrictions are easily circumvented by a determined cracker.
restrict numeric_address [ mask numeric_mask
] [ flag ] [ ... ]
numeric_address
argument, expressed in
dotted-quad form, is the address of an host or network. The
mask
argument, also expressed in dotted-quad form,
defaults to 255.255.255.255
, meaning that the
numeric_address
is treated as the address of an
individual host. A default entry (address 0.0.0.0
, mask
0.0.0.0
) is always included and, given the sort algorithm,
is always the first entry in the list. Note that, while
numeric_address
is normally given in dotted-quad
format, the text string default
, with no mask option, may
be used to indicate the default entry.
flag
always
restricts access, i.e., an entry with no flags indicates that free
access to the server is to be given. The flags are not orthogonal, in
that more restrictive flags will often make less restrictive ones
redundant. The flags can generally be classed into two catagories, those
which restrict time service and those which restrict informational
queries and attempts to do run-time reconfiguration of the server. One
or more of the following flags may be specified:
ignore
noquery
nomodify
notrap
lowpriotrap
noserve
nopeer
notrust
limited
client_limit
hosts
that have shown up at the server and that have been active during the
last client_limit_period
seconds are accepted. Requests
from other clients from the same net are rejected. Only time request
packets are taken into account. Query packets sent by the
ntpq
and xntpdc
programs are not subject to
these limits. A history of clients is kept using the monitoring
capability of xntpd
. Thus, monitoring is always active as
long as there is a restriction entry with the limited
flag.
ntpport
ntpport
and non-ntpport
may
be specified. The ntpport
is considered more specific and
is sorted later in the list.
ignore,
ntpport
, for each of the local host's interface addresses are
inserted into the table at startup to prevent the server from attempting
to synchronize to its own time. A default entry is also always present,
though if it is otherwise unconfigured; no flags are associated with the
default entry (i.e., everything besides your own NTP server is
unrestricted).
clientlimit limit
client_limit
variable, which limits the number
of simultaneous access-controlled clients. The default value for this
variable is 3.
clientperiod period
client_limit_period
variable, which specifies
the number of seconds after which a client is considered inactive and
thus no longer is counted for client limit restriction. The default
value for this variable is 3600 seconds.