NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p18 was released on 25 May 2024 and addresses 40 bugs and provides 40 improvements.

Please see the NTP 4.2.8p18 Changelog for details.

Bug 1568 - server and pool config lines should automatically do a restrict-allow
Summary: server and pool config lines should automatically do a restrict-allow
Status: CONFIRMED
Alias: None
Product: ntp
Classification: Unclassified
Component: ntpd (show other bugs)
Version: 4.2.7
Hardware: All N/A
: P5 normal
Assignee: Harlan Stenn
URL:
Depends on:
Blocks:
 
Reported: 2010-06-03 23:13 UTC by Hal Murray
Modified: 2012-08-02 11:19 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hal Murray 2010-06-03 23:13:05 UTC
If you setup a server by IP address, you can add the corresponding restrict line to let that IP address through your filters.  (It's ugly/verbose, but at least possible.)

That's hard or impossible if you setup a server by DNS name and worse if you are using the pool.

When it sets up a server, either through the server command or the pool command, ntpd needs to automatically patch the restrict list with a slot to allow this IP Address through.  (If this works for servers specified by IP Address as well as DNS, that would slightly simplify setting up the restrict lines.)


Note that there is a potentially nasty case.  Suppose I really don't want to trust the time from some CIDR block but they might run a pool server or some server I'm using by DNS name might move to their IP Space.  I think this needs another option to the restrict command (perhaps "noserver").  The idea is that those restrict slots would be checked by the pool/server code before setting up an IP Address to be used as a server.
Comment 1 Dave Hart 2010-06-04 00:14:03 UTC
ntp-dev has "restrict source" which is very much along the lines of what you propose.  If I use

restrict default ignore
restrict source
restrict localhost

then all IP addresses fall under an "ignore" restriction except localhost and every source IP, whether from a server command, pool command, or broad/multi/manycast.  Restrictions are removed when associations go away.

The major difference from your proposal is there is no default "restrict source" restriction -- you have to invoke it in ntp.conf.  Is that enough?
Comment 2 Harlan Stenn 2012-08-02 10:26:35 UTC
Dave,

Should 'restrict source' be the default for 4.2.8?

Just asking...

Hal, does 'restrict source' work for you?
Comment 3 Dave Hart 2012-08-02 11:19:27 UTC
(In reply to comment #2)
> Dave,
> 
> Should 'restrict source' be the default for 4.2.8?

I don't see how it can be.  'restrict source ...' declares the restrictions to dynamically add for each time source address as part of spinning the association.  Without any qualifiers, it means add a fully-unrestricted restriction for each source address, which would not make sense absent expressed user intent.  More generally, there's no set of restriction bits one could use as defaults for "restrict source" as doing so would change the meaning of existing restrict setups in the wild -- source addresses would get other-than-'restrict default' restrictions operators can reasonably expect.