Changing the access defaults

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > Out of the box, ntpd ships with anyone on the net able to do anything on the
> > to your server - query it, KOD it, peer with it, modify its configuration
> > with ntpq, etc. 
> 
> No.
> 
> It makes sense to let people query your server by default.  (but see below)
> 
> I think the peer stuff needs a password by default.  There is a way to 
> disable that.  I'll look it up if you can't find it.
> 
> It takes a password to modify the config and such.  There is something 
> similar to "trusted" that tells it which password(s?) is/are valid to use for 
> that.
> 
> The real reason for all the restrict stuff was ntpd was used to DDoS other 
> systems.  Really old systems made great amplifiers.  I think the current code 
> is OK.  It's UDP, so you can use it to redirect attacks, but I don't think a 
> default no-restrict system can do much amplification.

Ah, I didn't grasp that the code makes a distinction between accepting
request packets and executing the requests, aned that the restrict keywords
block the *former*, not the latter.

If that is not the correct interpretation of what you are telling me, please
correct me.

(Thinking of what I know about the code, I probably should have deduced this
sooner from where in the protocol machine the restrict tests are done.)

> It might make sense for the default configuration to not answer any 
> unsolicited packets.  That would prevent any use as a DDoS redirector and 
> would work fine on most client-only setups at the cost of making things 
> harder to monitor and debug.

I think that is probably the right thing to do in today's environment.
If operators fail to configure correctly we need ntpd to fail closed rather
than open.

So, forgetting my previous confusion about packet filtering vs. execution, 
my proposal becomes: shall we change the filtering defaults to correspond
to the standard boilerplate?

restrict -4 default nomodify nopeer noquery
restrict -6 default nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

It sounds like you are basically agreeing with this.

> > 2. We could drop that boilerplate from the configs we ship.  That's a good
> > thing, it means less to explain in our HOWTOs and less detail for newbies to
> > be confused by. 
> 
> No, you still have to explain that stuff.  You are just explaining different 
> things to different people.

Well, yes.  But if less explanation to newbies is bought by an equal amount
more of explanation to the more technically clueful, that is a net win, because
processing explanations is easier for the latter group.

> The default config would have to have a commented out restrict line that 
> turned it back into a server and a comment saying uncomment the next line if 
> you want this system to be a server.

That too would be a net win.  A commented-out line that is not needed
for normal operation is better than 4 which will, if omitted, allow the
server to be exploited.

But either you've made a minor error or I'm misundertanding you.  Right
now ntpd functions as a server with the default boilerplate.  So if we
move that boilerplate into code, why should it need another line
to undo anything?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>