In message <51444.1395430...@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <20140321122701.ac6d411a9...@rock.dv.isc.org>, > Mark Andrews <ma...@isc.org> wrote: > > >In message <45158.1395348...@server1.tristatelogic.com>, "Ronald F. Guilmett > e" > >writes: > >> I'm no expert, but I'll go out on a limb here anyway and say that the choi > ce > >> to make NTP outbound queries always use source port 123 is, as far as I ca > n > >> see, really really ill-advised. Did we learn nothing from all of the bruh > aha > >> a couple of years ago about DNS amplification attacks and the ways that > >> were finally settled on to effectively thwart them (most specifically the > >> randomization of query source ports)? > > > >Well for DNS the source port randomisation was to prevent cache > >poisoning so no *you* didn't learn anything from port randomisation > >in DNS. > > OK. You're right. I stand corrected and retract my earlier ill-considered > comment. > > >For time you want to reduce the variabilty in code paths taken as > >much as posible so no you don't want to be opening up a new socket > >every time. > > Perhaps you and I could debate this specific argument at greater length > off-list. For the moment I'll just say that, for me at least, it doesn't > seem like a terribly compelling argument. (Obviously, and as I'm sure you > well know, BIND has made this work for some time now, and doesn't seem > particularly the worse for it.)
When you are trying to keep and serve accurate time it is very much a argument. Opening new sockets is expensive for BIND. It significantly affects the number of recursive requests a server can make. It requires lots of extra management. > >Now if you are not running as a server or peer you can > >use a different port but that prevents local tools reaching ntpd > >to find out how ntpd is doing. > > There is no other way via which local tools could communicate with a local > ntpd?? > > I may be mis-remembering, but isn't there a sort-of (entirely separate) > control port for BIND that is implemented via a local UNIX domain socket? > > >NTP does have the ability to work out which commands it will accept > >and from whom. This stops NTP being used as a amplifier. The built > >in configuration has already been changed to make this the default > >behaviour. > > OK, please bear with me...I just want to verify... > > I have just added the following single line to the end of my /etc/ntp.conf > file: > > disable monitor > > That's all there is to it? > > >You can run a stateless firewall with on a NTP client and it is no > >longer a reflector which can be directed at any ip address in the > >world if you care to. > > Could you elaborate please? > > I -believe- that I understand what you just said, but I'd like to be 100% > sure that I did. > > > Regards, > rfg > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
