2000-04-22 18:51:59 +04:00
|
|
|
<HTML><HEAD><TITLE>
|
|
|
|
|
Access Control Options
|
|
|
|
|
</TITLE></HEAD><BODY><H3>
|
|
|
|
|
Access Control Options
|
|
|
|
|
</H3><HR>
|
|
|
|
|
|
|
|
|
|
<H4>Access Control Support</H4>
|
|
|
|
|
|
|
|
|
|
<TT>ntpd</TT> 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 <A HREF="notes.htm">Notes on Configuring
|
|
|
|
|
NTP and Setting up a NTP Subnet </A>page.
|
|
|
|
|
|
|
|
|
|
<P>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.
|
|
|
|
|
|
|
|
|
|
<H4>Access Control Commands</H4>
|
2000-03-29 16:38:44 +04:00
|
|
|
|
|
|
|
|
<DL>
|
2000-04-22 18:51:59 +04:00
|
|
|
|
|
|
|
|
<DT><TT>restrict <I>numeric_address</I> [mask <I>numeric_mask</I>]
|
|
|
|
|
[<I>flag</I>][...]</TT></DT>
|
|
|
|
|
<DD>The <I><TT>numeric_address</TT></I> argument, expressed in dotted-
|
|
|
|
|
quad form, is the address of an host or network. The
|
|
|
|
|
<I><TT>mask</TT></I> argument, also expressed in dotted-quad form,
|
|
|
|
|
defaults to <TT>255.255.255.255</TT>, meaning that the
|
|
|
|
|
<I><TT>numeric_address</TT></I> is treated as the address of an
|
|
|
|
|
individual host. A default entry (address <TT>0.0.0.0</TT>, mask
|
2000-03-29 16:38:44 +04:00
|
|
|
<TT>0.0.0.0</TT>) is always included and, given the sort algorithm, is
|
2000-04-22 18:51:59 +04:00
|
|
|
always the first entry in the list. Note that, while
|
|
|
|
|
<I><TT>numeric_address</TT></I> is normally given in dotted-quad format,
|
|
|
|
|
the text string <TT>default</TT>, with no mask option, may be used to
|
|
|
|
|
indicate the default entry.</DD>
|
|
|
|
|
|
|
|
|
|
<DD>In the current implementation, <I><TT>flag</TT></I> 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:</DD>
|
2000-03-29 16:38:44 +04:00
|
|
|
|
|
|
|
|
<DL>
|
|
|
|
|
|
2000-04-22 18:51:59 +04:00
|
|
|
<DT><TT>ignore</TT></DT>
|
|
|
|
|
<DD>Ignore all packets from hosts which match this entry. If this flag
|
|
|
|
|
is specified neither queries nor time server polls will be responded
|
|
|
|
|
to.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>noquery</TT></DT>
|
|
|
|
|
<DD>Ignore all NTP mode 6 and 7 packets (i.e. information queries and
|
|
|
|
|
configuration requests) from the source. Time service is not
|
|
|
|
|
affected.</DD>
|
|
|
|
|
<DT><TT>nomodify</TT></DT>
|
|
|
|
|
<DD>Ignore all NTP mode 6 and 7 packets which attempt to modify the
|
|
|
|
|
state of the server (i.e. run time reconfiguration). Queries which
|
|
|
|
|
return information are permitted.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>notrap</TT></DT>
|
|
|
|
|
<DD>Decline to provide mode 6 control message trap service to matching
|
|
|
|
|
hosts. The trap service is a subsystem of the mode 6 control message
|
|
|
|
|
protocol which is intended for use by remote event logging
|
|
|
|
|
programs.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>lowpriotrap</TT></DT>
|
|
|
|
|
<DD>Declare traps set by matching hosts to be low priority. The number
|
|
|
|
|
of traps a server can maintain is limited (the current limit is 3).
|
|
|
|
|
Traps are usually assigned on a first come, first served basis, with
|
|
|
|
|
later trap requestors being denied service. This flag modifies the
|
|
|
|
|
assignment algorithm by allowing low priority traps to be overridden by
|
|
|
|
|
later requests for normal priority traps.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>noserve</TT></DT>
|
|
|
|
|
<DD>Ignore NTP packets whose mode is other than 6 or 7. In effect, time
|
|
|
|
|
service is denied, though queries may still be permitted.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>nopeer</TT></DT>
|
|
|
|
|
<DD>Provide stateless time service to polling hosts, but do not allocate
|
|
|
|
|
peer memory resources to these hosts even if they otherwise might be
|
|
|
|
|
considered useful as future synchronization partners.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>notrust</TT></DT>
|
|
|
|
|
<DD>Treat these hosts normally in other respects, but never use them as
|
|
|
|
|
synchronization sources.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>limited</TT></DT>
|
|
|
|
|
<DD>These hosts are subject to limitation of number of clients from the
|
|
|
|
|
same net. Net in this context refers to the IP notion of net (class A,
|
|
|
|
|
class B, class C, etc.). Only the first <TT>client_limit</TT> hosts that
|
|
|
|
|
have shown up at the server and that have been active during the last
|
|
|
|
|
<TT>client_limit_period</TT> 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 <TT>ntpq</TT> and
|
|
|
|
|
<TT>ntpdc</TT> programs are not subject to these limits. A history of
|
|
|
|
|
clients is kept using the monitoring capability of <TT>ntpd</TT>. Thus,
|
|
|
|
|
monitoring is always active as long as there is a restriction entry with
|
|
|
|
|
the <TT>limited</TT> flag.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>ntpport</TT></DT>
|
|
|
|
|
<DD>This is actually a match algorithm modifier, rather than a
|
|
|
|
|
restriction flag. Its presence causes the restriction entry to be
|
|
|
|
|
matched only if the source port in the packet is the standard NTP UDP
|
|
|
|
|
port (123). Both <TT>ntpport</TT> and <TT>non-ntpport</TT> may be
|
|
|
|
|
specified. The <TT>ntpport</TT> is considered more specific and is
|
|
|
|
|
sorted later in the list.</DD>
|
2000-03-29 16:38:44 +04:00
|
|
|
|
|
|
|
|
</DL>
|
|
|
|
|
|
2000-04-22 18:51:59 +04:00
|
|
|
<DD>Default restriction list entries, with the flags <TT>ignore,
|
|
|
|
|
ntpport</TT>, 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).</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>clientlimit <I>limit</I></TT></DT>
|
|
|
|
|
<DD>Set the <TT>client_limit</TT> variable, which limits the number of
|
|
|
|
|
simultaneous access-controlled clients. The default value for this
|
|
|
|
|
variable is 3.</DD>
|
|
|
|
|
|
|
|
|
|
<DT><TT>clientperiod <I>period</I></TT></DT>
|
|
|
|
|
<DD>Set the <TT>client_limit_period</TT> 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.</DD>
|
2000-03-29 16:38:44 +04:00
|
|
|
|
|
|
|
|
</DL>
|
|
|
|
|
|
2000-04-22 18:51:59 +04:00
|
|
|
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
|
|
|
|
|
href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
|
|
|
|
|
</address></a></body></html>
|
